Parrot 2.5.0 Released! | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | Priorities: review experimental features for promotion or removal, fix 'make html' (talk to Coke), update tutorial (talk to tcurtis), pre-release testing.
Set by moderator on 13 July 2010.
00:06 wknight8111 joined, wknight8111 left
dalek rrot: r48085 | jonathan++ | trunk/DEPRECATED.pod:
Add back entry I accidentally removed, and fix eligible date.
 00:08
rrot: r48086 | jonathan++ | trunk/DEPRECATED.pod:
[DEPRECATED.pod] Switch eligile release to 2.7 instead.
00:17 donaldh_ joined 00:21 khairul joined 00:25 ruoso joined 00:59 plobsing joined
tcurtis Did throw once accept non-Exception operands? 01:07
01:21 wendar joined
wendar anybody know where darbelo lives? (I'm filling out my GSoC midterm evalutation) 01:22
cotto ~~ 01:32
tcurtis Did Squaak's throw statement ever work? Should I turn it into die? 01:35
sorear allison_: his irc connections come from Buenos Aires, AR 01:36
dunno if that's reliable enough
cotto sorear, that sounds right
allison_ sorear: okay, thanks 01:37
sorear with a name like Arrocha he's definitely from a spanish-speaking background
cotto English is his fourth language ;) 01:38
chromatic Where's "Rude Spanish" on that list? 01:40
cotto second 01:41
and I bet you can guess what's before and after it
02:49 Coke joined 03:03 cotto joined
cotto khairul, you around? 03:15
03:26 janus joined
khairul cotto: uh, yea, barely. give me a moment. 03:28
cotto no rush
03:30 hercynium joined
khairul cotto: back 03:33
see privmsg
cotto atrodo++ 04:21
dukeleto yes, a prototype of lorito is quite exciting 05:04
cotto atrodo, you around? 05:07
particle, ping 06:05
dalek tracwiki: v4 | dukeleto++ | ResolveExperimentals 06:07
tracwiki: trac.parrot.org/parrot/wiki/Resolve...ction=diff
06:11 uniejo joined 06:16 baest joined
cotto unping 06:26
time for sleep
08:03 spinclad joined 08:14 eternaleye joined 08:37 AndyA joined 08:49 TiMBuS joined
TiMBuS was the printerr op removed? 08:50
moritz TiMBuS: no, it's just a dynop 08:51
.loadlib 'io_ops'
purl .loadlib 'io_ops' is probably what you want
TiMBuS ah fair enough
in that case, i only use i once. would it be better to use getstderror/print 08:52
09:29 baest joined 10:42 clinton joined, lucian joined 12:00 whiteknight joined 12:03 bluescreen joined
whiteknight good morning, #parrot 12:04
bacek Morning??? There is no such thing! It's just 32-bits integer to represent point in timeline! 12:06
moritz bacek: then you're not y2038-safe :-) 12:08
bacek moritz, I hope I'll get new modern body in next 15-20 years :) 12:21
With new operating system implemented in Perl6 which is y2038 safe
12:22 ruoso joined
moritz akshually modern perl5 versions are also y2038 safe 12:22
dalek kudo: c8b6cf4 | moritz++ | src/core/Match.pm:
Match.Bool should be True for zero-width matches. moritz--
12:32 JimmyZ joined 12:37 bluescreen joined 13:07 gbacon joined 13:12 Essobi_ joined
TiMBuS bacek, what did you need to change in squaak to make it work with nqp-rx? i'm updating my language and it's getting the same error squaak had. 13:16
Method 'item' not found for invocant of class 'fun;Grammar'
atrodo whiteknight> it's actaully 1 byte for the opcode/register refrences and 4 bytes for an integer constant 13:21
s/1 byte/1 byte each/
13:28 fperrad joined 13:30 tcurtis joined 13:35 AzureStone joined
Coke msg dukeleto i reverted your deletion of an entry on the wiki. it's in the deprecated.pod, FBOW. 13:42
purl Message for dukeleto stored.
13:44 whiteknight joined
whiteknight ha, chromatic's book is really growing quite a large number of reported issues 13:48
atrodo: ping 13:49
atrodo whiteknight> pong
whiteknight atrodo: 1byte for registers is probably not enough, since Parrot is technically an "infinite" register machine
might want to consider a RISC-style mechanism with two formats: One format with a two-byte register and a 4-byte constant, and one format with three two-byte registers 13:50
(assuming two-byte opcode for each) 13:51
atrodo I thought you could reference an "infinite" number of registers, but there were only 32 actual registers a piece
tcurtis atrodo: many remotely complicated subs currently use hundreds of registers. 13:52
Of course, that's partially because IMCC essentially has no register allocator.
PerlJam atrodo: that's long since been changed.
whiteknight yeah, we truely don't bound the number of registers, and we don't spill to a store 13:53
atrodo My misunderstanding withstanding, even if that's true on the parrot side, that doesn't dictate it also be true on the lorito side 13:54
whiteknight atrodo: Lorito is really supposed to expose the inner workings of Parrot. There's no real reason why it should do something completely different from what Parrot does 13:56
especially since we don't do any register spilling or aliasing. If a person needs more than 256 registers, they are SOL 13:58
Coke whiteknight: but the only thing that has to be the similar is the parrot that ends up on top of lorito. not lorito itself. no?
whiteknight "on top of" is really misleading. Lorito is the language that the Parrot VM understands 14:00
No matter what changes, it doesn't make any sense for the Lorito language to not expose all the features that Parrot provides 14:01
otherwise, there's no reason for Parrot to provide them
If Parrot can allocate a virually infinite number of registers per context, Lorito should allow the user to address all of them 14:03
14:06 bubaflub joined
atrodo Then maybe I'm misunderstanding what lorito was meant to be 14:06
whiteknight as I understand it, Lorito is just the new assembly language and bytecode for Parrot 14:11
one that is supposed to be much better designed than PASM
Coke I would say "micro assembly", as there's expected to be opcodes on top of it.
tcurtis Microcode 14:12
purl i guess Microcode is faster
Coke (that is, we'll still have PIR, but it'll compile down to lorito instead of C
atrodo The way I understood it was that lorito would be the layer under parrot, the parrot bytecode and assembly would still exist
Coke that's my understanding. No?
atrodo Coke> that's how I basically understood it
whiteknight the exact wording is really not important. Microcode is really a term from CPU hardware design, it doesn't have any real relevance to VM design. We've used the term "Microcode" as an analogy for it's relationship to PASM/PIR 14:13
It's really just the native assembly language of Parrot. Anything we build on top of it is just another language built on top of it. PIR will become just another HLL that compiles down to Lorito
atrodo whiteknight> right. PASM/PIR still exist, but they get executed as a series of lorito ops
right? 14:14
14:14 plobsing joined
whiteknight atrodo: more importantly, PASM/PIR still exist until we get people to stop using them, because they suck. At that point, they no longer need to exist 14:14
like I said, they become just like any other HLL, except one that programmers don't like, and which don't serve any real purpose
atrodo That's a definite shift in how I was designing lorito 14:16
I also think I may need to give my project a codename, using lorito muddies up the waters even more 14:17
whiteknight Yeah, lorito is really two things: the new assembly language and the new bytecode format. Since the two are 1:1 correspondent, we can be vague when talking about it 14:18
Right now we have something like NQP -> PIR/PASM -> PBC
Next step is NQP -> PIR/PASM -> Lorito ASM -> Lorito BC 14:19
And eventually NQP -> Lorito BC
(where "NQP" is used as a stand-in for any HLL)
and from Lorito BC we can to JIT to get out native machine code if we want, or interpret it directly
jnthn whiteknight: I figure that'd actualy be kinda like NQP -> PAST -> LOST => Lorito BC or so? 14:20
whiteknight jnthn: yeah, lots of things happen inside the compiler. I'm just talking about compiler inputs/outputs, not internal representations
jnthn OK. :-)
atrodo So, where does the composable ops come in? 14:21
whiteknight but yes, PAST -> LOST inside the compiler is very likely
jnthn "The compiler has LOST it!"
atrodo :D
jnthn++
whiteknight atrodo: think of composable ops that I've talked about as basically macros. They get sorted out somewhere in the Lorito ASM -> Lorito BC translation
maybe we have a runcore smart enough to decode them on the fly to keep bytecode files smaller 14:22
atrodo That was actaully closer to my ultimate design
jnthn Are you planning to write an interpreter for Lorito or go straight to JIT? 14:23
TiMBuS is the jit still going to be llvm? i still support that
jnthn Or is that undecided?
Coke that seems to lose the potential for optimizing across composable ops, which i thought was desirable.
I think llvm was on our short list. I don't that list has been touched in any way in six months.
whiteknight if we say, for instance, that negative op numbers are macros we can do a simple bit test in the runcore and call into a sub-loop to decompose the op. That adds another check per op, if that's a cost we want to pay 14:24
jnthn: originally we'll want an interpreter, I think. That will be good and easy for testing
atrodo Right now, interpreter for Lorito, but it's low level enough that producing JIT will be easier
whiteknight in any case, we would ultimately like a trace-based JIT, so we will need an interpreter always
the huge benefit to Lorito is that each individual op is so low-level, converting them to LLVM opcodes will be easy 14:25
so our JIT becomes a table lookup to get the LLVM ops from each Lorito Op, then pass the LLVM op stream to LLVM, compile, run
atrodo Coke> yes, once you make the entire bytecode lorito, you lose all easy possibilities to optimize complex opcodes 14:26
Coke atrodo: ? no, that's backwards from what i was saying. =-)
tcurtis atrodo: I believe he was talking about if you decode complex ops at runtime.
atrodo Oh, misread
Coke If you keep everything in the composible opcodes, you lose possibilities for optimizing what would be the resulting lorito.
tcurtis atrodo: If they're just assembly/compile-time macros, you can optimize the code as if it was written in pure Lorito without having to worry about op boundaries. 14:27
Coke I can't imagine why we'd want to keep things in composible opcodes, would be like rendering out POST.
atrodo But you gain the possibility to take those composed opcodes and turn them into actual machine ops
Coke atrodo: composed == multiple lorito ops. 14:28
atrodo Take for instance a cosine composed op
if it stays packaged as "cosine" and the JIT knows the actual instruction on the actual machine, you create 1 machine instruction instead of a few dozen 14:29
if the JIT doesn't know about "cosine", then you have a working implementation
Coke atrodo: presumably at some point, the lorito "call" is going to call a C function for cosine.
moritz doesn't know any machines that have a cos opcode 14:30
Coke at which point, you have what smells to me like a better opportunity for jitting.
atrodo I'll double check, but i'm pretty sure x86 does
14:30 payload joined
jnthn Sounds a little like you just want the ability to call C functions from the bytecode? 14:30
Which JIT to exactly what a C call would. 14:31
TiMBuS FSINCOS
atrodo moritz> FCOS, and what TiMBuS said
My understanding was that sin/cos/tan are fairly common ops in floating point units 14:32
Coke> with composed ops the JIT can do optimizations on the "macro" level, and it can unroll everything and do optimizations on the "micro" level 14:34
tcurtis LLVM probably optimizes calls to the cos() C stdlib function to the FCOS op on x86, though.
Coke jnthn: we're going to have that, it's NCI. 14:36
tcurtis I know the LLVM docs say that "llvm treats calls to some functions with names and arguments that match the standard C99 library as being the C99 library functions, and may perform optimizations or generate code for them under that assumption." 14:37
Coke atrodo: I'll wait for the benchmarks, i guess. =-)
atrodo Coke> That's probably the best right now. It's all speculation 14:38
So, should I codename my project? suggestions? 14:39
particle would someone write up an nqp grammar for the proposed lorito syntax?
i have a feeling it'll be a good way to prototype it :) 14:40
atrodo particle> I don't have a nqp grammar, but I have a ebnf that I used in designing what I did: github.com/atrodo/lorito/blob/master/lasm.pl
14:43 snarkyboojum joined 15:02 dukeleto joined
cotto_work ~~\\ 15:10
15:23 patspam joined 15:26 cotto_work2 joined
cotto_work atrodo: have you considered prototyping Lorito with dynops instead of a separate project? 15:47
You wouldn't have as much control over the semantics, but you'd get a working interp and assembler for free. 15:49
atrodo cotto_work> I hadn't considered that 15:57
15:57 chromatic joined 16:04 theory joined
chromatic I'd considered the dynop strategy. allison talked me out of it. 16:15
atrodo So you were for the dynops until you spoke to allison? 16:16
cotto_work chromatic: what's the disadvantage if we're just prototyping? 16:17
chromatic Less flexibility of prototyping. 16:20
16:21 davidfetter joined 16:26 Chandon joined
NotFound "his only blocker is the surprisingly broken (and under-tested) state of the scheduler" - I'll call this the Law of the Underground Bugs: everything nobody uses is broken in the most bizarre ways. 16:29
moritz and, as allison_ wrote, it's not used because it's broken 16:31
cotto_work khairul's code uses it a little 16:32
Chandon NotFound: Similarly, if there aren't tests for something then it doesn't really exist.
moritz agreed 16:33
NotFound Chandon: last month I've found and fixed several bugs just by improving coverity. 16:35
whiteknight the scheduler is one of the most disappointing problems I've seen in Parrot in a while. It really didn't work at all like it is supposed to 16:37
NotFound Other law: things that are supposed to work don't X-)
whiteknight fortunately we have Chandon lookig at it, otherwise it would still be broken and nobody would know it
now, it's broken but at least one person is aware
and best of all, that one person has the mad skillz to make it fixed 16:39
chromatic Are the Coverity scans running again? 16:40
NotFound On the plus side, I'm happy with the opengl module. I've written a toy demo with a few hundred objects and it perfoms well. 16:41
japhb <rez>
whiteknight chromatic: I think it might be easier for you to just give pauloscustodio a commit bit :)
japhb NotFound, the Parrot one or the winxed one? (Or is there even a separate winxed module? Does it just directly use the parrot one?)
NotFound japhb: the parrot one, the winxed just uses it and hand-copy values for const because of the inhability to include pasm. 16:43
japhb >.<
I hate that there's no ability to handle constants well.
whiteknight is signing off for a bit, router needs maintenance
japhb NotFound, very happy to hear the Parrot OpenGL module is working well for you though. 16:44
When Parrot's NCI is rewritten, I guess I'll need to shuffle my life around a bit to spend some time on that.
chromatic We need a good way to handle constants in NCI somehow.
nopaste "NotFound" at 192.168.1.3 pasted "Fly - opengl winxed demo" (456 lines) at nopaste.snit.ch/22014
japhb chromatic, INDEED. 16:45
NotFound japhb: here is
japhb NotFound, very interesting! 16:48
japhb decides to go update Parrot and try it out
NotFound japhb: I've do some little fixes a few weeks ago to make this mechanic work. 16:49
japhb Oh?
NotFound japhb: don't remember what was exactly the problem, something in the call chain expected just subs, not other invokables. 16:50
japhb Ah.
NotFound Afer that fix, my nice callback objects works fine. 16:51
I don't like the way to make them "does invokable", though. 16:52
16:53 fperrad joined 17:07 knewt joined 17:38 bkuhn joined
japhb NotFound, OK, I have finally got Parrot updated and rebuilt. Is there a Plumage metadata file for winxed? 17:39
NotFound japhb: no, you need to use the svn repo. 17:40
japhb winxed? 17:41
purl hmmm... winxed is not javascript, just uses a familiar syntax. or code.google.com/p/winxed/ or winxed.org/
NotFound good bot
purl thanks NotFound :)
17:42 frodwith joined
japhb NotFound, what's the license? 17:49
(I'm making a Plumage JSON file for you. :-) 17:50
NotFound japhb: I'm waiting until having it load_language able. 17:51
License is Artistic/GPL
japhb ARtistic 1 or Artistic 2? 17:52
cotto_work 2 most likely
NotFound 2 17:53
cotto_work I don't think 1 is recommended for any use any longer
NotFound And GPL 2
moritz AL 2 is already GPL2 compatible, no?
NotFound I like to explicitly tell it, anyway.
17:54 AndyA joined 17:55 darbelo joined
NotFound japhb: BTW you don't need winxed to run it, providing the generated pir is enough, it doesn't use any runtime. 17:55
17:55 ash_ joined
japhb Nodnod 17:56
moritz thinks winxed is a cool idea, just like nqp 17:57
NotFound Thanks 17:58
17:59 theory joined
nopaste "NotFound" at 192.168.1.3 pasted "Fly - opengl winxed demo - generated pir" (1147 lines) at nopaste.snit.ch/22017 18:01
japhb Yay, got it built and tested with plumage, and glcubes.winxed works quite nicely. 18:02
NotFound, since you don't want it installable, I've made the plumage metadata error on install attempts. Do you mind if I commit the metadata to the Plumage repo? 18:03
NotFound Here is, in case someone wants to take a look.
18:03 hercynium joined
NotFound japhb: if you think it will be useful, no problem. 18:04
japhb Done, enjoy! 18:06
Can you commit fly.winxed to the winxed repo?
NotFound japhb: I'm waiting to have a better fly mechanic, current is just for testing. 18:07
japhb Fair enough. Let me know when it's there. :-)
NotFound Thinking better... "Release early..." I'll add it right now. 18:08
japhb :-)
dalek rrot-plumage: 536b826 | japhb++ | metadata/winxed.json:
[METADATA] New winxed.json metadata; thanks NotFound++ for permission
 18:12
nxed: r552 | NotFound++ | trunk/examples/fly.winxed:
new opengl example fly.winxed
 18:13
darbelo For the record: Buenos Aires, AR is my correct location, mostly.
cotto_work purl, darbelo? 18:14
purl cotto_work: bugger all, i dunno
particle misses BA
NotFound Don't cry for me Argentina...
darbelo Looks like I got forgotten.
I've also been offline for almost 3+ days due to power blackouts. 18:15
I'm catching up on the irclogs and email. Did I miss anything big? 18:16
NotFound darbelo: Spain won the FIFA world cup ;)
darbelo I noticed that one, yes. 18:17
darbelo makes a weak 'pulpo a la espaƱola' joke.
japhb NotFound, Nice little demo. You might want to turn on multisampling or somesuch, there's a lot of aliasing in the far away objects. :-) 18:18
NotFound japhb: my opengl skill are short.
japhb IIRC, Just add GLUT_MULTISAMPLE into your GLUT video mode, and glEnable(GL_MULTISAMPLE) 18:21
NotFound japhb: trying... 18:22
purl i think trying is just as important as succeeding sometimes. :)
japhb (The OpenGL programming guide explains how to test whether you actually have multisampling, but I don't recall if there's any actual error case if it's not available.)
NotFound japhb: I don't see any difference in my desktop, but is without direct context rendering. Will try on the laptop later. 18:27
japhb OK, fair enough.
dalek kudo: 32be7fb | (Radu Stoica)++ | src/core/Hash.pm:
Implement Hash.pick
 18:49
kudo: a8deb9a | moritz++ | src/core/Hash.pm:
fix Hash.pick for 0-values and absence of replacement
kudo: 22f2fc2 | moritz++ | src/core/Hash.pm:
simplify some code in Hash.pick
ash_ does nqp-rx do heredocs? 18:58
PerlJam ash_: doubtful. rakudo doesn't do heredocs and I'd think if nqp did them it wouldn't be too hard to port the implementation to rakudo 19:02
ash_ really? i never realized rakudo doesn't do them either
19:11 LoganLK joined
whiteknight does rakudo not do heredocs by design, or it just hasn't been implemented yet? 19:38
moritz NYI
19:43 AndyA joined
dalek nxed: r553 | NotFound++ | trunk/winxedst1.winxed:
fix silly mistake: is FloatArray, no NumberArray
 19:45
19:52 payload left
TimToady phone today? 20:00
chromatic yes 20:02
20:09 silug joined 20:19 AndyA joined
Coke returns from dayjob meetings. 20:32
atrodo Did they take all day?
20:34 joeri joined
Coke no, but did intrude on a phone call that I wanted to join on today. 20:39
dalek kudo: 4b3d76b | moritz++ | t/spectest.data:
regress on DateTime.t.

and only clutters up the test summary. Now we should have a PASSing spectest again, at least on sane platforms.		 20:40
20:44 AndyA_ joined 20:51 bluescreen joined 20:53 AndyA_ joined 20:56 whiteknight joined
dalek nxed: r554 | NotFound++ | trunk/winxedst1.winxed:
initial implementation of constructor calls, only for num of args > 1
 21:22
nxed: r555 | NotFound++ | trunk/examples/fly.winxed:
use constructor in example fly
 21:23
Coke gives up his evil plan of writing args handling for tcl procs in tcl, and tries to learn enough past to make this work.
cotto_work Could someone apply the parts of this patch that don't need discussion to trunk: (changes to core code from khairul's branch) 21:25
nopaste "cotto" at 192.168.1.3 pasted "khairul's changes to core Parrot code" (130 lines) at nopaste.snit.ch/22026
chromatic How slushy is trunk? 21:29
NotFound cotto_work: I don't see what's the reason for the addition in call.h It's value is set in a place, but it's not used.
Or is that the part that needs discussion? 21:31
cotto_work That's one part. 21:33
I'll chop those parts out.
21:33 theory joined
NotFound Don't worry, I'll add by hand the easy parts. 21:33
cotto_work thanks 21:34
21:36 tcurtis joined 21:38 snarkyboojum joined 21:39 davidfetter joined
darbelo Hm, does anyone here know what timezone allison's in? 21:40
cotto_work It varies. Last I knew she was in the UK. 21:41
darbelo Okay, does anyone here know what timezone the UK's in?
NotFound darbelo: Greenwich is in UK, you know? ;) 21:42
darbelo I gould guess GMT, but you can never tell with this brittons.
NotFound Daylight saving applies.
cotto_work: two nci tests fails 21:44
cotto_work sad face 21:45
NotFound Guess is the pointer.pmc change. Let me see...
It is. Testing again. 21:46
Coke ā˜¹ 21:48
cotto_work what Coke said
tcurtis clock? 21:49
purl tcurtis: LAX: Wed 2:49pm PDT / CHI: Wed 4:49pm CDT / NYC: Wed 5:49pm EDT / LON: Wed 10:49pm BST / BER: Wed 11:49pm CEST / IND: Thu 3:19am IST / TOK: Thu 6:49am JST / SYD: Thu 7:49am EST /
21:52 lucian_ joined
cotto_work sad face os<reply>ā˜¹ 21:54
sad face is <reply>ā˜¹
sad face
purl ā˜¹
darbelo Now we need a happy face too. 21:55
NotFound Commited the non conflicting parts.
cotto_work I bet our resident nfg hacker can handle that one. 21:56
darbelo msg purl happy face?
purl Message for purl stored.
cotto_work NotFound: thanks
happy face is <reply>ā˜ŗ 21:57
happy face
purl ā˜ŗ
chromatic Allison's in PDT last I saw her. 21:58
darbelo Heh. Still four hours, but in the other direction. 22:03
Coke finds an eatery with wifi. 22:08
(called... "the eatery") 22:09
darbelo How descriptive!
dalek rrot: r48087 | NotFound++ | trunk/src (3 files):
fixes from khairul++
 22:12
kudo: c3f5599 | jonathan++ | src/builtins/Routine.pir:
Start to unbreak .wrap and .unwrap. Certainly doesn't run all the tests yet, but
 22:14
ttbot Parrot trunk/ r48087 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/357298.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 22:15
cotto_work NotFound: looks like headerizer is needed 22:17
NotFound cotto_work: uh, forgot that. 22:18
dalek tracwiki: v26 | cotto++ | CottoTasklist 22:19
tracwiki: trac.parrot.org/parrot/wiki/CottoTa...ction=diff
rrot: r48088 | NotFound++ | trunk/include/parrot (2 files):
headerizing forgotten in r48087
 22:28
22:37 lucian joined
GeJ Bonjour everyone. 22:58
Coke need some PAST help. 22:59
sorear I only help with the FUTURE
Coke can someone explain why at github.com/partcl/partcl-nqp/blob/m...in.pm#L429 , it's pushing onto $block[0] ? what's the significance of the first element there? - that's a PAST::Block. I don't see anything in the docs about it being an arraytype, or why teh first element is important.
dalek rrot: r48089 | darbelo++ | branches/gsoc_nfg/src/string/encoding/nfg.c:
Make iteration of NFG string a codepoint-level operation.
 23:03
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#34894), fulltest) at r48088 - Ubuntu 10.04 amd64 (g++ with --optimize) 23:06
darbelo Hmm. Missed a commit. 23:07
Coke LTA error: i did PAST::Var.new( :scope<parameter>, :slurpy ) and got an error about a null <mumble> . no mention that slurpy was the culprit. 23:09
mikehh darbelo: dalek has his own priorities 23:13
Coke: re html_cleanup - do you me to do anything specific 23:15
dalek rrot: r48090 | darbelo++ | branches/gsoc_nfg/src/string/api.c:
Fix a typo in the encoding promotion logic for concatenations.
 23:19
Coke mikehh: not at the moment. sorry, about to wander off to social gathering. 23:31
hurm.
My next step was going to be making sure that the pod2html conversion on the individual pages was using the same code as the original 'make html' - doing a diff on trunk make html vs. the branch would be instructive in this regard. 23:32
msg coke - don't forget to start carving up 'make html' tasks tomorrow! 23:33
purl Message for coke stored.
mikehh Coke: 'k
23:44 cotto_work joined 23:56 Psyche^ joined

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!