|
»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'p6: say 3;' or /msg camelia p6: ... | irclog: irc.perl6.org or colabti.org/irclogger/irclogger_log/perl6 | UTF-8 is our friend! 🦋 Set by Zoffix on 25 July 2018. |
|||
|
00:02
bathtub_shark21 left
|
|||
| timotimo | anyone else seeing rather an increase in mail spam volume since about yesterday? | 00:03 | |
|
00:07
sauvin joined,
p6bannerbot sets mode: +v sauvin
|
|||
| geekosaur | I've been seeing it for several weeks | 00:18 | |
|
00:25
dct left
00:32
mindjuju29 joined,
p6bannerbot sets mode: +v mindjuju29
00:33
Guest3028 joined,
mindjuju29 left
00:34
p6bannerbot sets mode: +v Guest3028
00:35
Guest3028 left
00:50
pilottage joined
00:51
p6bannerbot sets mode: +v pilottage,
pilottage left
01:01
kardam left
01:16
atomicthumbs12 joined,
p6bannerbot sets mode: +v atomicthumbs12
01:18
atomicthumbs12 left
|
|||
| SmokeMachine | Is there a way to a Seq inform to a `race` or `hyper` method what is the best batch size to be used? | 01:36 | |
|
01:36
matsu joined
01:37
p6bannerbot sets mode: +v matsu
|
|||
| timotimo | the seq could implement its own race or hyper method that has different defaults for example | 01:41 | |
|
01:55
benjikun left
02:11
Raziel25 joined
02:12
p6bannerbot sets mode: +v Raziel25
|
|||
| SmokeMachine | timotimo: yes, that solves the problem, thanks! | 02:13 | |
|
02:14
Raziel25 left
02:45
c24 joined
02:46
p6bannerbot sets mode: +v c24
02:53
c24 left
03:12
jelly9 joined,
p6bannerbot sets mode: +v jelly9
03:15
jelly9 left
03:32
ophanim joined,
p6bannerbot sets mode: +v ophanim
03:33
ophanim left
04:00
[particle] joined
04:01
p6bannerbot sets mode: +v [particle],
[particle]1 left
04:08
[particle] left
04:13
[particle] joined
04:14
p6bannerbot sets mode: +v [particle]
04:27
matsu left
05:08
spycrab0 left
05:31
mdoep17 joined,
mdoep17 left
05:36
AlexDani` joined
05:37
p6bannerbot sets mode: +v AlexDani`
05:39
AlwaysHigh8 joined
05:40
p6bannerbot sets mode: +v AlwaysHigh8
05:41
AlexDaniel left
05:44
AlexDani` is now known as AlexDaniel,
AlexDaniel left,
AlexDaniel joined,
verne.freenode.net sets mode: +v AlexDaniel,
p6bannerbot sets mode: +v AlexDaniel
05:45
AlwaysHigh8 left
05:46
Affliction18 joined
05:47
p6bannerbot sets mode: +v Affliction18
05:48
weaksauce25 joined
05:49
Affliction18 left,
p6bannerbot sets mode: +v weaksauce25
05:51
weaksauce25 left
05:58
molaf joined,
p6bannerbot sets mode: +v molaf
06:01
vrurg left
06:10
troys left
06:26
domidumont joined,
[particle] left
06:27
p6bannerbot sets mode: +v domidumont
06:28
[particle] joined,
p6bannerbot sets mode: +v [particle]
06:30
domidumont left
06:31
domidumont joined,
p6bannerbot sets mode: +v domidumont
06:53
fireworks29 joined,
p6bannerbot sets mode: +v fireworks29
06:54
Blendify_i5 joined,
p6bannerbot sets mode: +v Blendify_i5
06:59
Blendify_i5 left
07:00
fireworks29 left
07:18
Techman6 joined
07:19
p6bannerbot sets mode: +v Techman6
07:27
hggdh27 joined,
hggdh27 left,
Techman6 left
07:49
patate6 joined
07:50
patate6 left
07:53
pokk24 joined
07:54
p6bannerbot sets mode: +v pokk24
07:55
pokk24 left,
andrzejek joined
07:56
p6bannerbot sets mode: +v andrzejek
|
|||
| andrzejek | araraloren: hi | 07:56 | |
|
08:18
domidumont left,
rindolf joined
08:19
p6bannerbot sets mode: +v rindolf
|
|||
| andrzejek | araraloren: nicht da | 08:34 | |
|
08:43
lizmat left
09:11
Ven` joined
09:12
p6bannerbot sets mode: +v Ven`,
rindolf left
09:16
Ven` left
09:27
rindolf joined
09:28
p6bannerbot sets mode: +v rindolf
09:39
Checking joined
09:40
Checking left
09:45
Cronus5 joined
09:46
p6bannerbot sets mode: +v Cronus5
09:47
Lumpi27 joined
09:48
Cronus5 left,
p6bannerbot sets mode: +v Lumpi27
09:51
Lumpi27 left
09:56
aborazmeh joined,
aborazmeh left,
aborazmeh joined,
p6bannerbot sets mode: +v aborazmeh
09:57
p6bannerbot sets mode: +v aborazmeh
10:00
andrzejek left
10:04
Dan_Bennett joined,
p6bannerbot sets mode: +v Dan_Bennett
10:05
Dan_Bennett left
10:15
lizmat joined,
p6bannerbot sets mode: +v lizmat
10:23
jmerelo joined,
Pixelz0 joined,
p6bannerbot sets mode: +v jmerelo
10:24
p6bannerbot sets mode: +v Pixelz0
|
|||
| jmerelo | releasable6: status | 10:24 | |
| releasable6 | jmerelo, Next release will happen when it's ready. 3 blockers. 447 out of 449 commits logged | ||
| jmerelo, Details: gist.github.com/2da3dba3caaa6841d7...a417b4479a | |||
|
10:25
Pixelz0 left
|
|||
| jmerelo | So, no release yet, right? | 10:31 | |
|
10:32
sotona joined
10:33
p6bannerbot sets mode: +v sotona
10:36
boredguy joined,
boredguy left
10:38
domidumont joined,
p6bannerbot sets mode: +v domidumont
10:39
LEI8 joined
10:40
p6bannerbot sets mode: +v LEI8,
LEI8 left
|
|||
| AlexDaniel | jmerelo: yeah, not yet | 10:42 | |
| jmerelo: but I'm pretty sure it'll happen next week | 10:43 | ||
| jmerelo: btw I made this list: github.com/perl6-community-modules...aster/wiki | |||
|
10:44
nwc10 left
|
|||
| jmerelo | AlexDaniel++ | 10:44 | |
| AlexDaniel | jmerelo: and today I toasted things once again, and it seems like there are some modules failing that were previously hidden because of native deps | ||
| jmerelo | AlexDaniel: great. So you install everything before toasting... | ||
| AlexDaniel | yeah | ||
| jmerelo | AlexDaniel: I still think there's an error that is similar to the intermitent error we get in perl6/doc travis | 10:45 | |
| AlexDaniel: I don't remember where I told zoffix about it, it wasn't an issue. Anyway, I think it's related to the number of compunits open or something like that. | |||
|
10:46
sena_kun joined
|
|||
| jmerelo | AlexDaniel: you see, for instance, here: toast.perl6.party/module?module=DB...4-g66aa689 | 10:46 | |
|
10:46
ZzZombo joined,
p6bannerbot sets mode: +v ZzZombo
10:47
p6bannerbot sets mode: +v sena_kun
|
|||
| jmerelo | AlexDaniel: it's this same error travis-ci.org/perl6/doc/jobs/415536136 | 10:47 | |
|
10:48
sotona left
10:52
spycrab0 joined,
p6bannerbot sets mode: +v spycrab0
|
|||
| jmerelo | AlexDaniel: which modules are failing? | 10:53 | |
|
10:58
sotona joined,
p6bannerbot sets mode: +v sotona
|
|||
| lizmat | weekly: perlhacks.com/2018/08/the-perl-con...n-glasgow/ | 11:03 | |
| notable6 | lizmat, Noted! | ||
|
11:03
sotona left
|
|||
| lizmat | weekly: perlmonks.org/?node_id=1220578 | 11:16 | |
| notable6 | lizmat, Noted! | ||
| lizmat | afk for some sighhtseeing& | 11:17 | |
| jmerelo | lizmat: you do that. Have fun! | ||
|
11:38
ZzZombo left
11:52
sotona joined
11:53
p6bannerbot sets mode: +v sotona,
domidumont left
11:55
KotH left
11:57
sotona left
12:11
kerframil joined,
p6bannerbot sets mode: +v kerframil
12:17
sotona joined,
p6bannerbot sets mode: +v sotona
12:27
jmerelo left
12:29
dct joined,
p6bannerbot sets mode: +v dct
12:30
aborazmeh left
12:49
sotona left
12:53
reportable6 left
12:54
reportable6 joined,
ChanServ sets mode: +v reportable6,
p6bannerbot sets mode: +v reportable6
12:59
marmor joined,
p6bannerbot sets mode: +v marmor
13:03
dct left
13:17
dct joined,
p6bannerbot sets mode: +v dct
13:23
dct left
13:36
sotona joined
13:37
p6bannerbot sets mode: +v sotona
13:41
sotona left,
domidumont joined,
p6bannerbot sets mode: +v domidumont
13:51
DarthGandalf left,
KotH joined,
DarthGandalf joined,
p6bannerbot sets mode: +v DarthGandalf
13:52
p6bannerbot sets mode: +v KotH
13:55
domidumont left
14:01
Metacity26 joined
14:02
p6bannerbot sets mode: +v Metacity26
14:05
Metacity26 left
14:14
itaipu joined,
dalek left,
p6bannerbot sets mode: +v itaipu
14:15
zakharyas joined
14:16
p6bannerbot sets mode: +v zakharyas,
marmor left
14:23
kybr left
14:26
Geth left
14:32
vrurg joined
14:33
p6bannerbot sets mode: +v vrurg
14:57
espadrine joined,
nikivi13 joined,
p6bannerbot sets mode: +v espadrine
14:58
p6bannerbot sets mode: +v nikivi13
15:01
nikivi13 left
15:05
ChoHag left,
Zombie26 joined
15:06
p6bannerbot sets mode: +v Zombie26
15:09
Zombie26 left
15:12
lizmat left
15:19
jpX joined
15:20
p6bannerbot sets mode: +v jpX,
jpX left
15:21
lizmat joined
15:22
p6bannerbot sets mode: +v lizmat
15:41
araraloren left,
KotH left
15:47
iownall55520 joined
15:48
p6bannerbot sets mode: +v iownall55520
15:49
iownall55520 left
15:55
fake_space_whale joined
15:56
p6bannerbot sets mode: +v fake_space_whale
16:18
lizmat left
16:19
damaxi joined
16:20
p6bannerbot sets mode: +v damaxi
16:21
DenSchub17 joined
16:22
p6bannerbot sets mode: +v DenSchub17
16:24
protium left,
aeruder_ left,
afresh1 left
16:25
markk joined,
nine_ joined,
tyil joined,
p6bannerbot sets mode: +v tyil,
aeruder joined,
rjbs joined,
Util joined,
masak joined,
eythian joined,
afresh1 joined,
japhb_ joined,
DenSchub17 left,
masak is now known as Guest85961,
p6bannerbot sets mode: +v markk,
p6bannerbot sets mode: +v nine_,
p6bannerbot sets mode: +v aeruder,
p6bannerbot sets mode: +v rjbs,
p6bannerbot sets mode: +v Util,
p6bannerbot sets mode: +v Guest85961,
p6bannerbot sets mode: +v eythian,
p6bannerbot sets mode: +v afresh1,
p6bannerbot sets mode: +v japhb_
16:26
eythian left,
eythian joined,
barjavel.freenode.net sets mode: +v eythian,
p6bannerbot sets mode: +v eythian,
perlbot_ joined,
benchable6 left
16:27
p6bannerbot sets mode: +v perlbot_,
committable6 left,
greppable6 left
16:28
shareable6 left,
statisfiable6 left,
bisectable6 left,
nativecallable6 left,
protium joined,
bhm left
16:29
bhm joined,
p6bannerbot sets mode: +v protium
16:30
p6bannerbot sets mode: +v bhm
16:50
damaxi left
17:14
committable6 joined
17:15
p6bannerbot sets mode: +v committable6
17:21
Turska-16 joined,
Turska-16 left
17:25
nativecallable6 joined,
bisectable6 joined,
p6bannerbot sets mode: +v nativecallable6,
p6bannerbot sets mode: +v bisectable6
17:38
zakharyas left
17:39
pmurias joined
17:40
p6bannerbot sets mode: +v pmurias
17:41
KotH joined
17:42
p6bannerbot sets mode: +v KotH,
damaxi joined
17:43
rindolf left,
p6bannerbot sets mode: +v damaxi
17:47
andries27 joined
17:48
p6bannerbot sets mode: +v andries27
17:52
andries27 left
17:53
rindolf joined
17:54
p6bannerbot sets mode: +v rindolf
18:01
aindilis left
18:02
aindilis joined,
p6bannerbot sets mode: +v aindilis
18:05
koto joined
18:06
p6bannerbot sets mode: +v koto
18:08
sena_kun left
18:10
perlbot_ left,
perlbot_ joined,
verne.freenode.net sets mode: +v perlbot_,
p6bannerbot sets mode: +v perlbot_,
perlbot_ is now known as perlbot
18:20
SCHAPiE left
18:21
Guest85961 is now known as masak
|
|||
| masak | what's the significant difference in Perl 6 between CATCH and CONTROL, and between exceptions and control exceptions? | 18:22 | |
| timotimo | control exceptions are normally resumed i guess? | ||
| masak | oh, there's a difference in semantics? interesting. | 18:23 | |
| timotimo | m: CONTROL { .say; say "controlled" }; say "hi"; warn "oh my"; say "bye"; warn "oh see ya" | ||
| camelia | hi oh my MoarVM panic: Trying to unwind over wrong handler |
||
| timotimo | hah | ||
|
18:23
greppable6 joined
|
|||
| timotimo | m: sub it { CONTROL { .say; say "controlled" }; say "hi"; warn "oh my"; say "bye"; warn "oh see ya" }; it | 18:23 | |
| camelia | hi oh my MoarVM panic: Trying to unwind over wrong handler |
||
| masak | that went well :P | ||
|
18:23
damaxi left,
greppable6 left
|
|||
| timotimo | yeah, not really | 18:23 | |
|
18:24
greppable6 joined,
SCHAPiE joined,
p6bannerbot sets mode: +v SCHAPiE
18:25
p6bannerbot sets mode: +v greppable6
18:27
benchable6 joined
18:28
sena_kun joined,
p6bannerbot sets mode: +v benchable6,
p6bannerbot sets mode: +v sena_kun
|
|||
| masak | besides, I can't really think of a control exception that's resumed | 18:30 | |
|
18:30
koto left
|
|||
| masak | if `next` and `last` are governed by control exceptions, it doesn't seem to me they are resumed | 18:30 | |
| today I got the crazy idea (for 007) that dynamic variables could be implemented using control exceptions :) | |||
| timotimo | mhh, i can imagine how that might work | 18:33 | |
| you throw the name of the variable and the first frame that "defines" it will catch, set the value to a container that was passed along, and resumes | |||
| stmuk | OpenSSL is broken on some non-linux systems (OS X and OpenBSD) :-( | 18:36 | |
| masak | it's like you're reading my mind :) | ||
|
18:37
realz joined,
damaxi joined,
realz is now known as Guest31344,
p6bannerbot sets mode: +v Guest31344,
p6bannerbot sets mode: +v damaxi
18:38
nativecallable6 left,
benchable6 left,
committable6 left,
bisectable6 left,
bloatable6 left,
reportable6 left,
squashable6 left,
greppable6 left,
coverable6 left,
undersightable6 left,
notable6 left,
domidumont joined
18:39
p6bannerbot sets mode: +v domidumont
|
|||
| timotimo | well, you've done all the thinking to pinpoint the idea, and then boiled it down to the key insight that would probably lead anyone to the same conclusion :) | 18:41 | |
|
18:42
Guest31344 left
|
|||
| jnthn | masak: `take` and `emit` and `warn` are all examples of resumable control exceptions | 18:44 | |
|
18:46
sena_kun left
|
|||
| jnthn | masak: The main reason CATCH doesn't catch control exceptions is because it'd be really awkward for the language user. There's nothing deeply different about control exceptions - the resolution machinery is the very same - it's just valuable to keep them distinct at the language level. | 18:46 | |
| You could in theory do dynamic variables with the exception system, but not all pretty unifications are performant unifications. :) | 18:47 | ||
|
18:54
sotona joined
18:55
p6bannerbot sets mode: +v sotona
|
|||
| timotimo | does the profiler work fine on a rakudo with all the specified revisions? | 18:58 | |
|
19:01
ilbelkyr17 joined,
p6bannerbot sets mode: +v ilbelkyr17
19:02
ilbelkyr17 left,
domidumont left
19:03
mfa29823 joined,
mfa29823 left
19:11
lgtaube joined
19:12
p6bannerbot sets mode: +v lgtaube
19:24
JustTheDoctor16 joined,
p6bannerbot sets mode: +v JustTheDoctor16
19:26
bloatable6 joined,
notable6 joined,
quotable6 joined,
nativecallable6 joined,
greppable6 joined,
ChanServ sets mode: +v quotable6,
ChanServ sets mode: +v nativecallable6,
ChanServ sets mode: +v greppable6,
committable6 joined,
ChanServ sets mode: +v committable6,
releasable6 joined,
coverable6 joined,
ChanServ sets mode: +v coverable6,
shareable6 joined,
ChanServ sets mode: +v shareable6,
bisectable6 joined,
reportable6 joined,
benchable6 joined,
squashable6 joined,
statisfiable6 joined,
ChanServ sets mode: +v statisfiable6,
p6bannerbot sets mode: +v bloatable6,
p6bannerbot sets mode: +v notable6
19:27
p6bannerbot sets mode: +v quotable6,
p6bannerbot left,
p6bannerbot joined
19:30
lookatme_q left,
JustTheDoctor16 left
|
|||
| robertle | can I check my understanding of Supplies? does the tap() block get executed by the thread that does the emit()? if I want multiple worker threads, I would have to do a start { ... } within the tap block? | 19:38 | |
|
19:39
damaxi left
|
|||
| timotimo | there's also a .start method on Supplies; it results in a supply of supplies that emit the single result value from the promise, though | 19:41 | |
| masak | jnthn: thank you for the explanation about user-level distinction. that's what I was looking for (and where I will continue my train of thought) | 19:44 | |
| jnthn: also, noted about pretty unifications ;) | |||
| robertle | hmm, my problem is that I have a single thread that creates events (async I/O), but many supplies (e.g. one per socket). I want to do stuff in parallel, but I do not want to execute two items from the same supply in parallel because then they could get reordered. currently I have a tap( ->$i { $!lock.lock; start { .... $!lock.unlock; } } ) | 19:45 | |
| this does what I want I think, but seems like a very C-like construct with the explicit locking and unlocking, also the fact that the lock() and unlock() happen in different threads... | |||
| there must be a cleaner way... | |||
|
19:45
sotona left
|
|||
| timotimo | react blocks have "only one thread in the block at one time" semantics | 19:46 | |
| they probably do what you want | |||
| so you don't have to fiddle with taps manually | |||
| robertle | timotimo: ok, but is that also true if there is only one thread calling emit() on the supply? | ||
|
19:46
RoBz9 joined
|
|||
| timotimo | not sure if i understand, but i think so? | 19:47 | |
| robertle | I will try, but I thought react is just syntactic sugar over act() | ||
|
19:48
RoBz9 left
|
|||
| robertle | well, perhaps a bit more in the sense that it could protect more than one supply | 19:48 | |
| but is the general assumption for tap() and act() correct that the tap()/act() block is executed by the thread that calls emit()? | |||
| timotimo | react is more than just act, it also does lots of super helpful subscription management for you | 19:50 | |
|
19:56
unicodable6 joined,
evalable6 joined,
ChanServ sets mode: +v unicodable6,
ChanServ sets mode: +v evalable6,
undersightable6 joined
|
|||
| jnthn | robertle: Yes, supplies are a mechanism primarily for concurrency control, not for introducing parallel processing | 20:02 | |
|
20:03
change joined
|
|||
| jnthn | The $supply.Channel.Supply idiom is one way to stick a Channel in as a buffer and have events handled on another thread | 20:04 | |
|
20:05
change left
|
|||
| robertle | jnthn: ok, that matches my observations. so if I do IO::Socket::Async.listen().tap(-> $client-socket { $client-socket.Supply(:bin).tap( -> $input { handle-input($input) }) }) | 20:06 | |
| then all calls to handle-input are run by the one thread dealing with async I/O, right? | 20:07 | ||
| jnthn | robertle: No | ||
| Because it inserts the events into the ThreadPoolScheduler's input queue | |||
| So you could have different threads handling different clients concurrently there | 20:08 | ||
| Of course, it'll only "do one accept" at a time and process one bit of input for a given client at a time | 20:09 | ||
| robertle | right, that would be fab. but it's not what I am seeing, let me golf this... | ||
| gist.github.com/robertlemmen/9d082...cb48f4ec8e | 20:15 | ||
| as I said, I have a way to work around it, but it seems ugly | |||
| jnthn | robertle: You're just not doing enough work to make it need more than one thread :) | 20:19 | |
| robertle | I did have sleeps in there before, but I guess they do not count as work? | 20:21 | |
| jnthn | I stuck a sleep 0.5 in there and I see stuff like: | ||
| input, handled in thread 19 | |||
| input, handled in thread 30 | |||
| robertle | interesting, my sleep was 0.1 and it did not trigger it! with 0.5 it does do things in parallel | 20:22 | |
| where is the logic that decides when to put work on the thread pool and when to do it directly? would be very interesting to have a look... | 20:24 | ||
| jnthn | It *never* does these directly | 20:25 | |
| The event loop thread never runs user code, it only ever puts stuff into the queue | 20:26 | ||
| But see src/core/ThreadPoolScheduler.pm6 for the place it decides how many threads | |||
| In particular, grep for affinity-worker or some such | |||
| robertle | hmm, when you run it with sleep(0.1), do you get execution on multiple threads? | 20:27 | |
| jnthn | No | ||
| It's a heuristic algorithm trying to start a sensible number of threads, so it's maybe that it wants a tweak in some cases | 20:28 | ||
| robertle | ah! I looked that that a while ago! | ||
| the heuristic is largely based on cpu utilisation! | |||
| jnthn | Ah :) | 20:29 | |
| So sleep is a pretty poor fake after all :) | |||
| Though being tuned for real apps rather than fakery is probably sensible :) | |||
| robertle | well, the reason I was remembering it is that I have apps at work that primarily shovel data around, so they do not sleep but would send onwards and wait for a response. they are not written in perl 6, but they also have the problem that they have low cpu utilistaion yet need more threads to handle the work | 20:31 | |
| without blocking I/O mind you, I think it's just the task switching that kills it | |||
|
20:36
kerframil left
|
|||
| robertle | weirdly if i remove the sleep and run it in a tight loop, I get about 125% cpu utilisation yet still only one thread that does the work. but perhaps it is now throttled by the accept() that always happens sequentially | 20:39 | |
| jnthn | Well, there's an event loop thread running in the background dispatching the work too | 20:41 | |
| robertle | I'll play some more with it. but you must have some benchmarks or real-world apps for cro, right? can you get more than a few hundred RQ/s through it? | 20:43 | |
| jnthn | I've seen 700+ in the past | 20:44 | |
| That's for the full HTTP/router stack | |||
| away for a bit | 20:46 | ||
| robertle | that's cool. I don't get any more than that for a really simple case | ||
| jnthn | Tested with ab also, fwiw | 20:47 | |
| robertle | I wish ab was able to do keepalive | ||
|
21:10
alphor16 joined,
alphor16 left
21:29
lizmat joined
21:30
varesa joined
21:33
varesa left
21:34
sotona joined
21:38
sotona left
21:43
msm7 joined,
pmurias left
21:52
msm7 left
21:58
Madkiss17 joined,
sotona joined
22:00
Rob___ left
22:05
Madkiss17 left,
Guest97826 joined
22:06
Guest97826 left
22:14
rindolf left
22:17
espadrine left
22:55
stmuk_ joined
22:57
stmuk left
23:15
sotona left
23:16
sotona joined
23:20
sotona left
|
|||
| Garland_g[m] | Say I declare an enum Color <Red Green Blue>. I don't want "Red" to become a symbol in the current scope, but want to only be able to access it with "Color::Red" instead. Is there a way to do this? | 23:31 | |
|
23:51
nolsen17 joined
|
|||
| timotimo | Garland_g[m]: try this: | 23:51 | |
| m: constant Color = do { enum Color <Red Green Blue>; Color }; say Color::Red | |||
| camelia | Red | ||
| timotimo | m: constant Color = do { enum Color <Red Green Blue>; Color }; say Red | ||
| camelia | Red | ||
| timotimo | oh damn | ||
| forget about this! | |||
|
23:52
nolsen17 left
|
|||
| Garland_g[m] | I tried something similar, and I was surprised that it escaped the block too. | 23:53 | |
|
23:56
dalek joined,
ChanServ sets mode: +v dalek,
sergot_ left,
p6lert_ joined,
Geth joined,
ChanServ sets mode: +v Geth,
synopsebot_ joined,
ChanServ sets mode: +v synopsebot_,
SourceBaby left,
synopsebot left,
p6lert left
|
|||