Parrot 2.1.1 Released! | parrot.org/ | Tasks: PCC deprecations branch, HLL subclassing and MMD branch
Set by moderator on 19 February 2010.
Coke Whiteknight: yes? 00:00
plobsing_: IANACP.
darbelo My brief passage through Solaris was mostly uneventful, back then when they weren't trying to dress it up as a linux distribituion.
Coke (I am not a c programmer)
I'm just trying to straighten up the build. =-)
darbelo Coke: And we love you for it ;)
Whiteknight Coke: which platform are you on? 00:01
chromatic o/~ Call Mr. Clean / yes, that's my name / that name again / is Mr. Clean. o/~
Coke Whiteknight: some linux variant on feather. 00:04
Whiteknight Coke: compiler? GCC?
Coke yes.
why? 00:05
NotFound char *(* func_t)()' to be 'char *(* func_t)(void)' aren't the same.
(In C)
dalek rrot: r44482 | coke++ | branches/rm_cflags (4 files):
make compilers/imcc/Rules.mak a generated file.

add -Wno-unused back to the default gcc warnings;
   this is how it was with trunk.		 00:06
rrot: r44483 | coke++ | branches/rm_cflags (3 files):
Ignore this new generated makefile file and remove it on realclean.
NotFound (void) takes no arguments, () takes any number of parameters.
Whiteknight NotFound: that's not true. (...) takes any number of arguments 00:07
() is the same as (void)
NotFound Whiteknight: In C++
Whiteknight NotFound: I would love to see an example of that 00:08
otherwise I declare BS
NotFound Whiteknight: int main() 00:09
purl int main() is probably especially K&R-ish, since they were working on Unix.
plobsing_ NotFound: r44484 should either fix parrot_nci_thunk_gen or at least cause an assertion to fail much earlier
darbelo Whiteknight: it's a leftover from K&R C
Whiteknight NotFound: int main() is a special case for compatibility. Doesn't work for other functions
NotFound plobsing_: going to try
kurahaupo1 Before C89, function params weren't declared between the brackets (so you used empty params regardless of the params).
Coke note that this with gcc's -strict-prototypes. 00:11
er, -Wstrict-prototypes
japhb Not looking having it in front of my at the moment ... what is the actual *intent* of the code in question? Because if the intent is that there be no arguments, this is all moot.
Whiteknight japhb: the question could inform us later
plobsing_ japhb: the intent is no arguments. it's in the generated nci thunks code 00:12
darbelo Whiteknight: nopaste.snit.ch/19785 00:13
That works, and won't even warn unless you pass gcc an option. 00:14
Whiteknight well, I'll be damned 00:16
plobsing_ C tries but fails to stfu and dwim. it's nice when it works though. 00:17
Whiteknight just lost a little bit more respect for C 00:18
what the hell good does it do to have a static type system in the first place?
darbelo It's a backwards-compatibility thing.
And you bitch about *our* deprecation policy ;)
NotFound Whiteknight: a nicely designed and written compiler will never fit the machines it was developed for. 00:19
Whiteknight darbelo: I'm seeing that most deprecation policies are shittackular 00:20
NotFound plobsing_: still fails with r44484
plobsing_ same way? 00:21
NotFound plobsing_: yeah
dalek rrot: r44484 | plobsing++ | trunk (5 files):
add PF_size_strlen() function to get the storage size of a string without having allocated the string
 00:22
plobsing_ hmmm
rrot: r44485 | jkeenan++ | branches/rm_cflags/t/steps/auto/warnings-01.t:
Delete tests which pertained to internal methods deleted within past two days.
plobsing_ NotFound: do files prior to pmc_nci_thunk_gen throw warnings about PackFile_unpack? 00:23
NotFound plobsing_: no 00:24
00:25 particle joined
NotFound plobsing_: packfile.winxed parrot_nci_thunk_gen_pbc gives me exactly the same error. The pbc just fails to be loaded. 00:25
plobsing_ hmmm... maybe the constant storing code is messing up somehow. AFAIK, this is the first attempt to put a large, nested aggregate into a constant. 00:26
NotFound pbc_disassemble shows some thing good, then segfaults. 00:27
darbelo NotFound: pbc_dissasemble often segfaults on prefectly good pbcs. 00:28
NotFound But it seems fully to dump the const table.
plobsing_ that's the only unusual thing that tools/dev/nci_thunk_gen.pir does that I can think of 00:29
NotFound Oh, and it also shows the error messages before starting to dump.
Same for pbc_dump 00:30
All tools agree that the pbc has some problem.
plobsing_: I don't know if there is other tool that loads bytecode inside an immediate 00:32
(talking about unusual) 00:33
plobsing_ NotFound: I do that because it complains about data_json.pbc not being found after installation
and I don't actually need it at runtime
dalek tracwiki: v5 | cotto++ | LoritoPrimitives 00:34
tracwiki: add min: and max:
tracwiki: trac.parrot.org/parrot/wiki/LoritoP...ction=diff
NotFound plobsing_: I don't discuss his usefulnes, just don't know if is a well proven way.
plobsing_ hmmm... not sure. wfm, but maybe I should consult an imcc guru. 00:35
Whiteknight cotto: min and max? I doth protest 00:36
NotFound plobsing_: my intuition is that the packfile segments aren't merging well, and thus the wtitten pbc gets wrong values. 00:37
The pbc_dump results looks like that. 00:38
plobsing_ merging?
purl merging is slow
dalek rrot: r44486 | coke++ | branches/rm_cflags (19 files):
merge latest changes from trunk.
 00:39
NotFound plobsing_: the load_bytecode merging the loaded bytecode with the one being compiled.
rrot: r44487 | plobsing++ | trunk (2 files):
make function prototypes default to (void) not ()
japhb Whiteknight, well, min: and max: are indeed Squeak prims, as the header of that page says 00:40
plobsing_ NotFound: that has to do with imcc making use of interp->initial_pf right?
japhb And actually, they are primitives on some processors.
Whiteknight japhb: Okay, I didn't realize that was the list of squeak ops. That said, let me register my official protest against "min" and "max" ops for when the time comes 00:41
NotFound plobsing_: something like that, the packfile code isn't very clear,
plobsing_ why don't we have a separate PF for every independantly loaded/generated piece of code? 00:42
NotFound plobsing_: I have wondered that sometimes. 00:43
Maybe is just an imcc peculiarity, don't know. 00:44
plobsing_ NotFound: part of the answer is that all PF's after the first will have their constant's rudely garbage collected from under them.
but that can't be all of it 00:45
NotFound plobsing_: if that is the only problem, can be easily solved.
plobsing_ NotFound: please explain how to fix that. It might fix TT 1142. 00:46
NotFound plobsing_: adding a list, a vector or whatever or loaded modules in the interpreter and marking it. 00:47
Well, and the not easy part of changing imcc way o work.
And probably the packfile loader. 00:48
The "easily" was just for that part of the answer. 00:49
Whiteknight plobsing_: If that's the case, it should be trivial to add a mark routine to keep those constants viable
NotFound Looking again at the dump... the pbc directory has 13 segments. 00:50
Whiteknight If we get rid of the raw Packfile structures, and use PMCs for everything, and if each PMC type has a working mark routine, this all becomes trivial 00:51
NotFound And several of them have type 'DIRECTORY'
Looks very odd.
My provisional conclusion is that loading bytecode while imcc is working mess a lot of things, 00:53
plobsing_ So to get it working, I guess I'll have to refactor to do that parsing at runtime. 00:55
NotFound plobsing_: I think that will be faster way to get the thing working, yes. 00:56
Whiteknight So when Parrot loads a new .pbc file, it merges the two packfiles? 00:57
plobsing_ I'm willing to cede correctness for expedience
at least for now
Whiteknight: that's how I understand it
NotFound Whiteknight: not very sure about what it exactly does, but when I looked at some parts looks like that. 00:58
Maybe it just merge the directory, but that's enough to interfere with imcc already working on it. 01:01
Whiteknight now, if we had just one Packfile, but it could contain any arbitrary number of segments, including segments of multiple types, that would be fine too 01:05
plobsing_ Whiteknight: that's fine, but then we shouldn't expose them as part of the interface
chromatic Maybe we can do the merge only after we close the packfile for further modification.
Whiteknight chromatic: yeah, like an optimization pass that compresses the packfile 01:06
... among other optimizations
dalek rrot: r44488 | plobsing++ | trunk/tools/dev/nci_thunk_gen.pir:
change :anon :immediate back to global variable. imcc--
 01:12
purl dalek: that doesn't look right
nopaste "coke" at 72.228.52.192 pasted "remaining warnings in rm_cflags" (16 lines) at nopaste.snit.ch/19786
plobsing_ NotFound: does that fix it? 01:13
Whiteknight I feel like there is such an amazing dearth of discussion and design information from the earlier days of Parrot 01:25
of course, unless somebody goes digging through IRC logs, the same will probably said about this time from people later
cotto_work There's Squaks of the Parrot.
Whiteknight cotto_work: yes, and I've read every single one of those posts
but that was a rare gem
cotto_work but you're right that that's the exception 01:26
Austin Why is the P6metaclass.register operation replacing my namespace with an empty one?
Whiteknight Austin: because it knows better than you
Austin Hmm.. I want to believe that, I really do. But now I have no methods.. :(
Hmm.. I want to believe that, I really do. But now I have no methods.. :( 01:27
ww
Huh! It really is a different namespace. 01:28
Whiteknight Austin: what do you mean, "replacing my namespace"?
Austin I do P6metaclass.register('Key');
The address of the namespace object returned by get_hll_namespace 'Key' is ...96 before I call register, and ...60 after.
After the register, dumping the namespace shows no methods. Before the register, there were like 20. 01:29
pmichaud afaik p6object doesn't do any replacing of namespaces 01:30
it must be something happening beneath p6object
Austin Sure, blame the internals... 01:31
pmichaud sure, why not? ;-)
Austin I think the big effect is causing a proxy to be created, or something, yes?
cxreg tries to build parrot for webos
pmichaud well, yes, anytime you call 'get_class' on a PMC type a proxy ends up getting created 01:32
cxreg d'oh: Can't exec "cc": No such file or directory at lib/Parrot/Configure/Utils.pm line 86.
pmichaud Austin: afaict, there's no 'Key' namespace to begin with. 01:35
chromatic The good news is we need to build proxies to store methods anyway and we can cache them this way.
Austin Well, there was something there - I put a bunch of methods into it.
pmichaud via .namespace ['Key'] and :method ? 01:36
Austin via module Key; our method new ...
pmichaud oh, from nqp?
Austin Natch. Almost everything I'm doing (for Kakapo, at least) is in NQP. 01:37
Except for a couple of dozen lines of pir to get :main and friends.
pmichaud guess I'd need to see the code 01:38
nopaste "Austin" at 68.37.46.53 pasted "output showing namespace change" (54 lines) at nopaste.snit.ch/19787 01:42
"Austin" at 68.37.46.53 pasted "code registering Key" (25 lines) at nopaste.snit.ch/19788
Austin That code is in the middle of a setup routine, but the call to register is right there at the top of the loop, and its effect is immediate. 01:43
pmichaud okay, testing. 01:45
purl testing is the best thing ever ZOMG
Coke does src/main.c:480 /need/ a cast? if I remove the cast, warning goes away. does that look right? 01:46
cxreg: ... trouble building parrot? 01:47
pmichaud Austin: how/where is Parrot::get_hll_namespace defined?
chromatic Coke, if that's the anonymous enum warning, the C++ build needs it.
particle coke: it may ... chromatic++ 01:48
Austin gitorious.org/kakapo/kakapo/blobs/m...Parrot.nqp line 195 01:49
nopaste "pmichaud" at 66.25.31.29 pasted "P6metaclass.register('Key') doesn't affect namespaces for me (for Austin++)" (31 lines) at nopaste.snit.ch/19789
Coke chromatic: it is. wonder if I can shut up gcc. 01:50
chromatic Without a switch statement? I doubt it. 01:51
pmichaud Austin: I'm guessing that $pmc_type isn't a string, or Parrot::get_hll_namespace is somehow grabbing the wrong namespace 01:53
Austin If it weren't producing exactly the right output above register, and the wrong output below it ...
pmichaud (which makes me suspicious of key_(), fwiw)
my nopaste shows that register isn't having any effect 01:54
Austin Yeah.
pmichaud try the form of dump that I used via Q:PIR
Austin I'm doing that now.
nopaste "Austin" at 68.37.46.53 pasted "Things got worse." (58 lines) at nopaste.snit.ch/19790 01:57
Coke is annoyed that the build isn't going to be warnings clean. :P
Whiteknight Coke: We'll fix those warnings over time 02:00
Coke: what warnings specifically? I can probably get them to shut up
pmichaud Austin: "VAR1" => null 02:04
where is that coming from?
Austin That's the second pir -based dump
(get_hll_namespace ['Key']
) 02:05
pmichaud what type is $pmc_type ?
Austin string
pmichaud ...are you sure? ;-)
Whiteknight Coke: warning fixed
Austin No.
How do I use sprintf opcode?
$S0 = sprintf "%X", $P1 02:06
doesn't seem to work
pmichaud just try say(pir::typeof__SP($pmc_type));
or even say(pir::typeof__PP($pmc_type));
Austin I'm running that now. 02:07
Whiteknight r44489
Austin Okay.
How do I use sprintf opcode?
pmichaud it wants a format and an aggregate (like an array)
Austin Ahh.
Aggregate.
purl aggregate is array or hash.
pmichaud in nqp, I suspect one can do pir::sprintf__SSP($fmt, [$values, $to, $print]);
Austin Aggregate.
purl aggregate is array or hash.
Austin ww 02:08
pmichaud you might also try forcing $pmc_type to a string: P6metaclass.register(~$pmc_type);
Whiteknight the cyclomatic complexity of that parseflags function is mind-bogglingly high
Austin Yeah, I was just looking at that.
chromatic Welcome to Getoptsville, population The Damned.
Austin It's saying String. 02:09
But now I don't believe it.
Whiteknight I don't even know of any good programs to calculate the complexity of C source
Austin Because I had a hash problem with this thing earlier.
pmichaud it might be that .register(...) has trouble if passed a String PMC
pmichaud tries that 02:10
japhb Whiteknight, what complexity measure are you looking for?
pmichaud no, works for me with a String PMC
Whiteknight japhb: cyclomatic complexity, mostly
but any complexity measuring tool would be nice
Austin No change when I '' ~ $pmc_type
pmichaud Austin: very strange. it's working just fine here. 02:11
Austin :-$
Coke Whiteknight: thanks for that fix. 02:12
however. now it's complaining under g++:
Whiteknight really? damnit
pmichaud oh, don't do '' ~ $pmctype
Whiteknight let me take a gander
pmichaud just ~$pmc_type
Austin Why not?
pmichaud (shouldn't matter, but ~$pmc_type results in a string register, definitely) 02:13
Coke src/main.c: In function 'const char* parseflags(parrot_interp_t*, int*, char***, Parrot_Run_core_t*, Parrot_trace_flags*)':
Austin Okay.
Coke src/main.c:440: warning: cast from type 'char**' to type 'const char**' casts away constness
Austin I tried that, too, but neither one changed anything.
:(
Whiteknight Coke: okay, that's a different line. I'll fix that too
pmichaud Austin: I'm stumped, then.
Austin: is it only Key where it's losing the namespace? 02:14
Austin It seems that way.
pmichaud I'm stumped. 02:15
Austin Me too. I'm calling register('Key') now, moving the whole code block up and up and up.
Aha! 02:16
I'm registering it twice.
pmichaud hmmm, maybe .register should detect that :-S 02:17
Austin It does for normal classes.
Maybe not for PMC types?
dalek rrot: r44489 | whiteknight++ | trunk/src/main.c:
fix a build warning in src/main.c pointed out by Coke++. GCC doesn't like directly casting the output of a function. Instead, we break it up onto multiple lines, storing the return value THEN casting it.
Austin Yeah, it's upgefucht after the second register. 02:19
brb
Whiteknight Coke: fixed. r44490 02:21
like a goddamned sniper 02:22
japhb Whiteknight, www.chris-lott.org/resources/cmetrics/ 02:23
Austin pmichaud++ Thanks for the help. (Ticket coming.) 02:24
Coke Whiteknight++
pmichaud Austin: sure thing -- glad to "help" :) 02:25
Austin TT#1481
Now to go rip all that diagnostic code out. 02:26
Whiteknight Coke: any other warnings you need to have killed?
Coke I think the rest of the warnings are in generated code from imcc that I can hide. 02:27
cotto has dalek stopped watching the wiki?
02:28 eternaleye joined
dalek tracwiki: v48 | cotto++ | ParrotQuotes 02:31
tracwiki: whiteknight takes things a bit too far
tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff
TT #1481 created by Austin_Hastings++: P6metaclass.register does not catch second registration of PMC Class 02:33
rrot: r44490 | whiteknight++ | trunk/src/main.c:
fix another warning that appears in g++ because we cast directly from char** to const char**. If we explicitly break type-safety for a bit, we can shut up the warning. Plus, argv here is highly unlikely to be affected by even the most aggressive optimizers, so we don't need to worry about this breaking anything.
 02:34
cotto Whiteknight, what about min and max do you protest? The Smalltalk operations are just a starting point. 02:37
Whiteknight cotto: they're operations that are infrequently used and unnecessary for the operation of the VM
cotto They do seem a little odd. 02:38
Whiteknight now, I don't know how squeak uses them, maybe they are an integral part of their internal algorithms 02:39
but they aren't important for Parrot
Anyway, I'm out for the night. Later. 02:40
cotto The squeak VM ops seem strangely bloated for a minimal set. 02:52
cotto wanders off to the next thing
japhb cotto, the surrounding text explains that they are bloated up in a few places either to expose hardware or to improve efficiency of really common operations 02:53
parrot would probably have different bloat for the same reasons. :-) 02:54
Austin Also, keep in mind that there's a big graphics primitive they need to implement.
Wow. Here's me trying to get back to the one trivial test case I started this whole adventure with... 02:55
japhb Sometimes it can be hard to push through the crowd of newly shaved yaks .... 02:57
Austin heh
dalek tracwiki: v6 | cotto++ | LoritoPrimitives 03:04
tracwiki: fill in some more descriptions, remove Lorito name field
tracwiki: trac.parrot.org/parrot/wiki/LoritoP...ction=diff
03:35 janus joined
cxreg Coke: yeah, i tried both setting CC and --cc but it still defaults to /usr/bin/cc 03:49
it might be scratchbox's fault, but i'm not sure
dalek kudo/master: 8df8ad7 | (Solomon Foster)++ | src/core/Any-str.pm:
Try to handle the .substr cases where $start is outside the length of the string.
 03:55
kudo/master: 403afe0 | (Solomon Foster)++ | t/spectest.data:
Turn on substr.t.
rrot: r44491 | plobsing++ | branches/tt1477:
creating branch to attempt solution to TT 1477
04:02 estrabd joined 05:22 silug_ joined 05:25 kthakore joined 06:07 Khisanth joined 06:29 iblechbot joined
cotto bacek_at_work, it looks like some files are missing from opsc 06:44
06:57 uniejo joined
cotto Interesting. The fifth entry when searching for git-svn is one of our Trac wiki pages. 07:10
must be because it's awesome 07:12
07:16 parthm joined 07:37 chromatic joined 07:53 parthm left 08:21 mikehh joined 08:35 fperrad joined 08:39 jan joined
fperrad ttbot ? 09:10
purl ttbot is TapTinder build bot owned by mj41 and reporting tt.ro.vutbr.cz/buildstatus/pr-Parrot/rp-trunk build errors. or a master of timing.
09:12 AndyA joined
dalek rrot: r44492 | mikehh++ | trunk/src/packfile/pf_items.c:
correct C function docs
 09:23
09:47 kthakore_mp joined
kthakore_mp hi 09:47
purl hey, kthakore_mp.
09:51 kthakore_mp left 09:53 bacek joined 10:03 lucian joined 10:22 barney joined
dalek rrot: r44493 | bacek++ | branches/ops_pct/compilers/opsc/t/02-parse-all-ops.t:
Update test
 10:28
rrot: r44494 | bacek++ | branches/ops_pct/compilers/opsc/compiler/compiler.pm:
Add missing compiler.pm. cotto++
10:35 lucian joined 11:56 ruoso joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32399), fulltest) at r44492 - Ubuntu 9.10 amd64 (gcc with --optimize) 12:01
forgot to post that
12:07 PacoLinux joined 12:10 parthm joined 12:20 Whiteknight joined
Whiteknight good morning #parrot 12:29
12:36 ruoso joined
Austin Mmm...xkcd.org 12:37
lorito?
purl it has been said that lorito is "little parrot" in spanish or examples/embed/lorito.c
12:38 darbelo joined
Austin purl, lorito is also xkcd.org/707/ 12:38
purl okay, Austin.
Austin botsnack
purl :)
Austin lorito?
purl lorito is "little parrot" in spanish or examples/embed/lorito.c or xkcd.org/707/
12:40 parthm left 12:45 parthm joined
Coke cxreg: if you specify --cc=/path/to/other/cc, it should never use /usr/bin/cc - can you file a bug report via trac? if possible, run Configure.pl with the --verbose option. 13:03
13:13 payload joined
Coke wonders where everyone is today. 13:25
13:27 bacek joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32403), fulltest) at r44494 - Ubuntu 9.10 amd64 (g++ with --optimize) 13:30
13:30 lichtkind joined
Whiteknight Coke: we're all here 13:33
darbelo Except me, I'm over there. 13:35
bacek And me. I'm in other hemisphere. 13:36
Coke It's not just quiet here. also on other chats, at work. it is /friday/, right? =-) 13:38
darbelo
.oO( Why is everyone else upside down? )
bacek Coke, nope. It's Saturday already. 13:40
clock
darbelo Lucky bastard.
13:41 parthm left
darbelo It's not even *noon* here. 13:41
bacek Hey! Your Friday night ahead! And mine is passed already... 13:42
.oO( Where is our annoying girl? )
darbelo purl: You alive?
purl darbelo: wish i knew
darbelo clock? 13:43
purl darbelo: LAX: Fri 5:43am PST / CHI: Fri 7:43am CST / NYC: Fri 8:43am EST / LON: Fri 1:43pm GMT / BER: Fri 2:43pm CET / IND: Fri 7:13pm IST / TOK: Fri 10:43pm JST / SYD: Sat 12:43am EST /
bacek ah... missed '?'
13:43 tetragon joined
darbelo Yeah, purl is smart like that. 13:43
bacek purl, are you smart? 13:44
purl bacek: bugger all, i dunno
bacek nope, she isn't
darbelo Maybe she's trying to be modest...
But I doubt it.
bacek purl, are you modest? 13:46
purl wish i knew, bacek
13:59 uniejo joined 14:19 AndyA joined
Coke purl, modesty? 14:23
purl modesty is, like, actually something I'm not very good at
nopaste "coke" at 65.91.151.194 pasted "this code generates a warning. Help?" (18 lines) at nopaste.snit.ch/19793 14:24
dalek kudo/master: d588cd2 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 215 files, 24575 (68.7% of 35754) pass, 1 fail

S02-whitespace_and_comments/one-pass-parsing.t 1 - can parse non-backslashed curly and right bracket in cclass		 14:25
kudo/master: 4fc3af7 | (Solomon Foster)++ | src/core/Any-str.pm:
Add protos for uc, lc, ucfirst, and lcfirst.
bacek Coke, is it on trunk or your branch?
Coke it's the same code. warning is probably hidden on branch. 14:26
but you can see the warning on branch easily.
ah. wonder if it's the function prototypes.
bacek gcc probably want explicit cast from NULL
Coke also some void/char mismatches going on. 14:27
bacek may be
But NULLs are definitely causing useless warnings. 14:28
Coke bacek - note that the second warning there has no nulls in it.
bacek second one is () vs (void) 14:29
(afaiu)
Coke are you hacking or just diagnosing?
bacek hang on,
purl hang on, is BOFHcam Ben the same as the PFY stories Ben?
bacek second can't be () vs (void) 14:30
(just diagnosing, I can't hack at 1:30am) 14:31
14:32 cognominal joined
Coke should I have to cast the NULL? really? 14:33
bacek Coke, can you try to remove SHIM around args and rerun headerizer?
(NULL) "But NULLs are definitely causing useless warnings."
Coke yes, I know you said that, I'm merely incredulous. 14:34
if I remove the shim, I'll get a warning about unused parameters. =-) 14:35
bacek you can put UNUSED(arg) inside function body :)
Coke fair enough. I'm at DAYJOB so cannot devote too much brainpower here. =-) 14:37
dalek rrot: r44495 | coke++ | branches/rm_cflags (15 files):
merge latest changes from trunk
 14:51
Coke bacek: why would removing the SHIM() help? 14:52
(because it seems to.) 14:53
nopaste "pmichaud" at 66.25.31.29 pasted "odd bug with index op" (12 lines) at nopaste.snit.ch/19794 14:54
Coke pmichaud: which encoding is unicode? utf8? 16? 14:57
pmichaud utf8, I believe. 15:02
oh dear, it gets worse...
Coke hurm. trying to strip that down more, but can't.
nopaste "pmichaud" at 66.25.31.29 pasted "odd bug with index op #2, simplified" (11 lines) at nopaste.snit.ch/19795 15:03
Coke if you change the last buc to bu or bub, it works. 15:05
pmichaud ?
well, yes
because then it finds it immediately 15:06
pmichaud files TT
Coke I'm wondering if the Parrot_str_byte_length in Parrot_str_find_index is to blame. 15:07
15:08 iblechbot joined
Coke (nope) 15:09
real work done in mixed_cs_index... 15:10
dalek TT #1482 created by pmichaud++: index op failure 15:13
Coke pmichaud: I think I found the thinko. 15:22
the bubuc vs buc - the buc gets us to the second b... but then the next match attempted is against 'uc', not 'ubuc'. 15:23
(the search function doesn't properly reset the position in $S1.) 15:26
15:26 bubaflub joined
PerlJam Coke++ 15:31
Coke woot, fixed locally. 15:38
ripping out debug output, retsting...
... fencepost..
15:40 cognominal joined
PerlJam Coke: I just looked at mixed_cs_index. Did you do something like src_iter.set_position(interp, &src_iter, start+1) before resetting start = -1 ? 15:44
Coke something like that. 15:45
15:45 Psyche^ joined
Coke (I actually used another variable to track it.) 15:45
PerlJam Seems like mixed_cs_index could use some Boyer Moore goodness too :)
Coke no doubt. 15:46
pmichaud: fixed. Thanks for the report. 15:48
PerlJam Coke++ again!
Coke this also fixes the original bug that had real unicode in it. 15:49
(it now reports '2' here.)
pmichaud 2 is correct. 15:50
Coke then woot. 15:51
dukeleto 'ello 15:53
Coke 'i 'ukeleto. 'ow 're 'ou?
(mine are actually glottal stops.) 15:54
dukeleto attempts to make a klicking noise
Coke: doing well 15:55
Coke pmichaud: was that driven by RT#73122 ?
pmichaud Coke: yes. 15:56
dalek rrot: r44496 | coke++ | trunk (2 files):
Fix TT #1482

string's iterator, causing a potential match further down the string to be ignored.
  pmichaud++ for the test.
16:00 ruoso joined 16:02 theory joined
dalek TT #1482 closed by coke++: index op failure 16:03
16:07 cotto joined
cotto good morning non-purl 16:07
Austin Hmm.. 16:11
Suppose I have a test that sometimes fails, sometimes passes. I can't mark it todo, I can't mark it ok. What do I do? 16:12
16:14 mls joined
mls Coke, your mixed_cs_index patch calls set_position for every char not matched, isn't that very expensive? 16:14
It seems to me that doing it only when found_at != -1 would be cheaper
dukeleto Austin: does your test pass by itself but fail in the full suite, or vice versa? 16:17
Austin: you can mark it as todo, and it will occasionally pass, which won't break your build 16:18
Austin: but if you don't mark it as todo, it occasionally will break your build
Austin I thought that todo tests broke when they passed?
dukeleto Austin: i would go for marking todo until you figure out what is going on
Austin: not in perl-land
16:18 Andy joined
dukeleto Austin: a passing todo test usually generates a small message like "TODO passed" or somesuch 16:19
Austin And in pir land?
dukeleto Austin: for testing purposes, parrot-land =~ perl-land
Austin The tests are a set of chi-square analyses of the randomness of the pir random range generator.
Sometimes, thanks to whiteknight++, they now pass. Frequently, even.
But the underlying RNG code is insufficiently random, it seems. And so they often fail, due to a lack of randomness. 16:20
When I run a series of ranges, probably 10% of the tests fail. But it's not always the same 10%. 16:21
dukeleto Austin: where are these tests?
Austin See file attached to TT# 1479
Okay, I marked them all as todo. 16:24
NotFound Austin: maybe just the test is too strict for the quality of the generator? 16:25
Austin NotFound: obviously true.
NotFound Austin: I mean, it hasn't an adjustable parameter that can be relaxed? 16:26
dalek kudo/master: fad9447 | pmichaud++ | src/Perl6/Actions.pm:
Fix bug where < a > would improperly produce ' a ' instead of 'a' (RT #73136).
Austin Yes. 16:27
NotFound Then relax ;)
Austin Which is to say, "the random number generator is not very random." 16:28
NotFound Then we need to fix it instead of worrying about to hide the test failures. 16:29
dalek rrot: r44497 | Austin_Hastings++ | trunk/t/dynoplibs/random-range.t:
See TT#1479
Austin Sure. Hence "todo"
cotto Austin++ #nice test 16:33
Austin Time to go shovel the global warming off my driveway.. 16:34
dukeleto msg Austin you might want to take a look at en.wikipedia.org/wiki/Diehard_tests 16:36
purl Message for austin stored.
dalek p-rx: 0d1e1b5 | pmichaud++ | (2 files):
Better handling of single-angle items with spaces (e.g., < a > becomes 'a'
 16:37
Coke mls quite possibly. I'll check. 16:38
dukeleto Austin++ # very nice RNG tests 16:40
nopaste "coke" at 65.91.151.194 pasted "mls, how about this?" (21 lines) at nopaste.snit.ch/19796 16:43
16:44 lucian joined
mls coke: yes, looks good to me. Thanks. 16:50
pmichaud mls++ # thanks for catching that, rakudo, nqp, and pge all make heavy use of the index op 16:51
mls If it's really that time critical it would make sense to change the code so that the first character of the search string (c2) is not always fetched 16:55
pmichaud I don't think it's quite that critical.
but it is a frequent operation
particle but premature optimization is *fun*! 16:56
dukeleto slaps particle on the wrist 16:57
17:01 whiteknight joined
cotto_work good morning whiteknight 17:01
whiteknight top o' the mornin cotto_workl
dalek rrot: r44498 | coke++ | trunk/src/string/charset/ascii.c:
Only reset the iterator when we have to.
 17:02
mls Btw, shouldn't index return 0 instead of -1 if the search string is empty?
whiteknight mls: no, if zero the index would be the start of the string 17:04
mls But "" is at the start of every string
The "strstr" manpage seems to agree (at least on linux) 17:05
17:06 patspam joined
mls (maybe a should have written "the string to be searched for is empty) 17:07
darbelo mls: strstr on the empty string should return the begining of the other string
mls strstr("foo", "") should IMHO return the beginning of "foo" 17:08
darbelo strstr(string, "") returns string, yes.
mls Parrot_str_find_index contains: if (!Parrot_str_byte_length(interp, s2)) return -1;
cotto_work how often is the randomness test expected to fail? 17:10
darbelo I wonder what would break if we removed that check... 17:11
cotto_work I'm running it a bunch and haven't seen a failure
darbelo cotto_work: would a better RNG 'fix' the test? 17:12
cotto_work afaict untotoding would "fix" it 17:13
17:14 ruoso joined 17:15 jan joined
darbelo Hm. Maybe Austin's system lacks sufficient entropy. 17:15
cotto_work That's quite possible.
darbelo I think he was running some sort of pseudovirtualized linux-on-windows thing. 17:16
whiteknight cotto_work: which randomness test?
cotto_work the recently added one, t/dynoplibs/random-range.t
darbelo whiteknight: A different one on every run. It's random, you see. 17:17
;)
whiteknight cotto_work: let me look at it.
dukeleto cotto_work: the way/frequency that the RNG tests fail are probably OS/architecture dependent
cotto_work: run it a 1000 times
17:22 lichtkind joined
lichtkind Coke: ping 17:23
cotto_work odd 17:24
bash: t/dynoplibs/random-range.t: Permission denied
17:28 mikehh joined 17:31 davidfetter joined
dalek rrot: r44499 | pmichaud++ | failed to fetch changeset:
[nqp-rx]: Update nqp-rx with < ... > and root_new fixes.
 17:35
nopaste "mls" at 195.135.221.2 pasted "optimized mixed_cs_index code" (36 lines) at nopaste.snit.ch/19797 17:40
17:41 riffraff joined
mls coke: I couldn't resist and optimized index a bit. The main difference is that it calculates c2first only once. I also think it's more readable (at least to me ;-) ) 17:42
dukeleto mls: are there any benchmarks that show it is faster? 17:43
17:44 Hunger joined
dukeleto sudddenly has a bout of hunger 17:44
lichtkind dukeleto: i deleted your second page
hope you dont mind that 17:45
mls no, I didn't benchmark it. But it should be twice as fast for complex utf-8 strings, as it decodes only one char instead of two for earch search position 17:46
NotFound I fail to understand that string pseudo-iterator design. What's the point in using a iterator and checking the length of the iterated-on things at the same time? 17:47
cotto_work mls, can you post in the form of a patch?
NotFound And worse, mixing the byte lengths and the character lengths in several functions. 17:48
dukeleto lichtkind: some use.perl person was linking to that instead
lichtkind: could you maybe provide a "go here instead" ? 17:49
lichtkind: it isn't that big of a deal
lichtkind dukeleto: allright there /wasare severeal such pages
18:03 payload joined
nopaste "mls" at 195.135.221.2 pasted "mixed_cs_index optimization as patch" (70 lines) at nopaste.snit.ch/19798 18:10
18:12 bubaflub left, bubaflub joined
nopaste "mls" at 195.135.221.2 pasted "optimized mixed_cs_index function" (39 lines) at nopaste.snit.ch/19799 18:13
18:13 chromatic joined
mls (Please ignore the nopaste.snit.ch/19797 version) 18:16
cotto_work dukeleto, how many times out of 1000 would you expect the test to fail? 18:17
darbelo A random amount ;)
cotto_work shuts up yuo
chromatic msg Whiteknight we need to add a core Ļ‡ opcode, can you get on that? 18:19
purl Message for whiteknight stored.
whiteknight we need a what now?
chromatic For doing the statistical analysis of the rand op.
Coke lichtkind: pong.
darbelo 'GREEK SMALL LETTER CHI' 18:20
Coke 'INDIAN HOT TEA CHAI'
whiteknight chromatic: Sure thing, I'll just add it all...the...way...down...at...the...end...of...my...todo...list... 18:21
lichtkind Coke: great
NotFound It wasn't SMALL?
Coke mls: that looks reasonable to me, but my brain is at $DAYJOB right now, can you submit a patch via trac or convince someone else here? =-) 18:22
lichtkind Coke: as you may read im collecting infos what who has done for the tpf wiki, please just write me about your evolvement in most details as possible
darbelo 'GREEK CAPITAL LETTER CHI' is \\u03A7
Mostly the same, just a bit diffrent. 18:23
NotFound Greek Capital isn't Athens? 18:24
cotto_work You could make a Ļ‡ method on FIA.
darbelo NotFound: Not in unicode, AFAICT. 18:26
Maybe it is if you build with ICU or something.
dukeleto cotto_work: i don't know, but running something 1000 times is good if you think you have an intermitten test failure
NotFound darbelo: well, unicode is universal so maybe it doesn't care about state capitals. 18:27
cotto_work What's the capital of the universe?
NotFound Krypton?
Coruscant?
bubaflub knowing our luck, probably a super-massive black hole 18:29
NotFound Eventually. 18:30
The ideal for some politicians: no one can see what the government does from the outside. 18:31
cotto_work looks like MANIFEST needs regeneration 18:32
dalek TT #1483 created by mls++: optimization for mixed_cs_index
NotFound cotto_work: done 18:34
cotto_work NotFound++
Coke msg mls Thanks! 18:40
purl Message for mls stored.
dalek rrot: r44500 | plobsing++ | trunk/src/pmc_freeze.c:
remove debugging code
 18:41
rrot: r44501 | NotFound++ | trunk/MANIFEST:
update MANIFEST
cotto_work there are also some t/codingstd/trailing_space.t t/codingstd/pir_code_coda.t and t/distro/file_metadata.t failures if you're bored 18:42
otherwise I'm sure mikehh will get them
Coke lichtkind: no, haven't heard about that. 18:52
lichtkind: I can tell you that I don't think I'm on the language design team. =-) 18:54
18:55 shockwave joined 18:57 TiMBuS joined
shockwave In my programming language, I'm trying to code: object() == object() -- In this case, object() is analogous to Java's or C#'s object. My object class is a custom class. I'm overriding the is_equal vtable method. But I'm stuck at that. 18:57
What is a method to compare if two objects are the same object?
Austin_away Ask java.
Austin Use a rudimentary is_equal, and let others override it. 18:58
shockwave At first, I added a method to my object class, '%get_self', which returns the 'self' object. Then, i called the '%get_self' from the passed in object, and compared it the self of the object that is overriding is_equal. That causes infinite recursion. 18:59
Austin, your method would not work. 19:01
bubaflub cotto_work: i can fix some of those failures real quick
Austin okay
lichtkind Coke: its also about implementors, writers, all the stuff that helps
Coke the short version that's there is substantially accurate. 19:04
shockwave I suppose the way I'll have to implement that is to create an internal unique id for each object created, and compare those ids. Is it possible to have static variables in PIR? 19:06
19:07 riffraff joined
whiteknight that's a good question. Can we do static variables? 19:07
I suspect the answer is "no", but I think it may be possible through some kind of trickery
Coke No. there are globals, though. 19:08
shockwave Coke, are those globals thread safe?
dalek kudo/master: 459e001 | pmichaud++ | src/builtins/Parcel.pir:
Remove a flatten property fossil.
 19:09
Coke shockwave: I'm not sure anything in parrot is thread safe.
shockwave lol, alright.
19:09 spinclad joined
Coke (note: not a real technical answer, only a snarky one.) 19:09
Austin A global variable in a particular namespace will do what you want, static-wise.
shockwave Thanks, all. 19:11
pmichaud how about the issame opcode? 19:12
that's the common mechanism for deciding if two PMCs are in fact the same.
shockwave pmichaud, that sounds like what I'm looking for.
I'll give it a try.
dalek rrot: r44502 | bubaflub++ | trunk/t/dynoplibs/random-range.t:
[codingstd] trailing white space fix
 19:14
rrot: r44503 | bubaflub++ | trunk/t/dynoplibs/random-range.t:
[codingstd] pir coda
rrot: r44504 | bubaflub++ | trunk/t/dynoplibs/random-range.t:
[codingstd] set svn properties
shockwave pmichaud, You da man!
That worked wonderfully. 19:15
19:17 iblechbot joined
lichtkind Coke: what did you on parrot? 19:20
dalek kudo/master: 06437e6 | pmichaud++ | t/spectest.data:
Comment out one-pass-parsing.t from t/spectest.data until we pass its test.
kudo/master: 8faa503 | pmichaud++ | src/core/operators.pm:
Remove some unneeded pir::boxing.
kudo/master: 0b8098e | (Solomon Foster)++ | t/spectest.data:
Turn on capitalize.t.
 19:37
kudo/master: b9b14f9 | (Solomon Foster)++ | src/core/Any-str.pm:
Slightly awkward but functional implementation of capitalize.
 19:38
19:43 lucian_ joined, hercynium joined, lucian__ joined
Coke just ran out of memory trying to build rakudo. 19:44
davidfetter i know those APPLE ][s are fun to work with, but maybe a different machine is in order... 19:47
cotto_work Coke, using a Parrot with the GC bug? 19:48
shockwave is object comparison agains null plan for a future release? as in: $I0 = $P1 == null ?
s/plan/planned
chromatic isnull
shockwave I know isnull exist. Thanks, though. 19:49
I'm asking specifically for the version mentioned above.
lichtkind Coke: did you write on parrot?
NotFound shockwave: do you mean pir sugar or something else? 19:50
shockwave sugar
19:50 riffraff joined
NotFound shockwave: some of us think imcc actually has too much sugar. 19:51
Coke lichtkind: yes. I've been with parrot since 2001. I don't have time now to write up a mini CV on this, but will add it to my stack for when I update my resume. 19:52
cotto_work: /the/ GC bug?
oh, no, this is trunk.
shockwave: yes, that is NOT planned.
NotFound Coke: 2001? You wrote the HAL-9000 port?
lichtkind Coke: thanks telling would be enough i can make formating, but later is fine too 19:53
Coke lichtkind: again, "VP of parrot foundation." is fine.
lichtkind allright 19:54
Coke src/core/gen.pm is 3125 lines of perl6... no wonder it choked. =-) 19:55
19:58 ruoso joined 20:03 payload joined 20:07 joeri joined
shockwave I noticed there are operators like: istrue, isfalse, issame, isntsame. But there is no isntnull. One of those would be helpful. 20:21
20:27 hercynium joined
lichtkind dukeleto: still there? 20:31
purl there is a bug
pmichaud shockwave: there's if_null and unless_null, I believe. 20:36
but yes, I don't recall a isntnull 20:37
dalek kudo/master: c495888 | pmichaud++ | src/builtins/ (2 files):
Switch untyped variables to default to Any instead of Mu.
 20:40
kudo/master: 94a6c44 | pmichaud++ | (2 files):
Merge branch 'master' of git@github.com:rakudo/rakudo
particle isnull 20:41
isn't there?
purl isn't there is probably a failing test though?
cotto_work forget isn't there 20:42
purl cotto_work: I forgot isn't there
20:42 lucian joined
cotto_work now isn't there isn't there 20:42
Austin heh 20:43
shockwave pmichaud, the benefit of having a isntnull is that code like this doesn't create a special case (HLL): someObj != nil 20:50
This version: someObj == nil -- maps to one opcode.
The != version maps to many.
NotFound I was thinking about the same some days ago. isntnull may be helpful 20:54
cotto_work question: once Lorito is in place, will PIR op bloat become a non-issue?
NotFound cotto_work: I'm not sure about what will be that place. 20:55
shockwave cotto_work, I know this may be difficult to answer, but do you think there could be a Lorito version within the next 6 months? 20:56
cotto_work That really depends on how many people feel like working on the definition and implementation. 20:57
shockwave true
20:57 kurahaupo joined
NotFound cotto_work: if pbc are supposed to contain current style opcodes, is a big issue. If they will contain lorito opcodes, may become irrelevant. 20:58
cotto_work The idea is that pbc would contain Lorito ops and PIR would be translated to Lorito. 20:59
(and nqp and close and winxed and ...)
afk
NotFound cotto_work: in that case I don't care much about pir, if the ideas about direct code generation land. 21:00
In such sceneario pir becomes an imcc detail.
Unless, of course, code generation helpers keep using the current opcode system. 21:02
In short: everything is still open.
shockwave I don't get it. pbc's will contain Lorito code?
But, then, PBCs would not be portable.
Where is the 'Just In Time'? 21:03
I thought that PBCs would contain whatever they contain now, and they would be translated prior to execution.
plobsing_ shockwave: my understanding of the model is "Lorito Code" => "JIT" => "native code"
NotFound shockwave: no need to be less portable than the current way.
shockwave ah 21:04
NotFound Is not inconceivable a mixed way, where pbc can contain bytecode segments and loritocode segments.
shockwave So, for someone like myself (a Parrot user), Lorito code may as well be PIR opcodes? 21:05
I mean, would I have to do something different to make use of Lorito, or is it all transparent?
21:05 riffraff joined
shockwave NVM. I got lost for a second, but I'm found again. 21:06
NotFound shockwave: I think the initial idea is that you generate pir code, wich is compiled/translated in some way, but the current ideas about direct code generation can change that plan. 21:07
But the way through pir must remain open anyway. 21:08
shockwave I see.
21:09 japhb joined
dalek rrot: r44505 | plobsing++ | trunk/src (2 files):
move nci thunk loading into global_setup
 21:11
kapo: 2c8599f | austin++ | :
review: gitorious.org/kakapo/kakapo/commit/...de98beaadf		 21:20
kapo: 4bb7a2e | austin++ | (18 files):
Refactored Program->Library
shockwave Although I'm only about 10-15 percent through code generation, it seems like, by far, the most difficult aspect of it is breaking complex expressions into the proper sequence. 21:21
NotFound shockwave: that depends, the parser can broke it an send only simple expressions to the next steps. 21:28
shockwave NotFound, but the time of code generation, the parsing phase is long over, and so is the semantic analysis phase. 21:29
NotFound shockwave: yes, but you work with the results the parser gives. 21:30
shockwave The AST, yes.
That's what I'm refering to. Breaking up the AST of complex expressions into the proper PIR sequence is, as of now, my most challenging part.
darbelo You might want to do an intermediate transform on your AST. Lower it to a more 'PIR friendly' representation. 21:32
shockwave darbelo, that is true. It didn't occur to me to transform the AST. Currently, I'm iterating over it and spitting out code. 21:33
I'm going to look into it. Thanks.
darbelo The parrot compiler tools do just that, PAST is made of 'syntaxy' stuff and POST is a more 'opcody' representation. 21:34
shockwave darbelo, I'm gonna have to come up with my own version, because I'm using a custom lexer/parser/analyser/ast, written in C++. 21:35
Damn. Just the thought of it makes me sad. I already have a bunch of code written generating PIR. But, I know it's the right thing to do :( 21:37
darbelo Comparing the output of "--target=past" and "--target=post" in Parrot compiler might still prove useful.
Coke (lorito) I still have yet to see a lorito plan that isn't handwaving. but it may just be that I don't understand any of it. 21:38
chromatic Which parts sound handwavey to you?
21:39 japhb joined
NotFound What's about the plan of writing a draft version via dynops? 21:39
Coke chromatic: what is the current state of the art lorito proposal that I can review ? 21:40
trac.parrot.org/parrot/wiki/Lorito ?
darbelo NotFound: That should be easy enough. Most of the smalltalk primitives are a single line of c code.
chromatic I wrote something somewhere about a five-step plan where we use PCT/NQP to translate ops, for example, to Lorito. 21:41
cotto_work L1?
purl i heard L1 was a hypothetical language that would be used to implement PMCs and PIR-visible ops so that they could all be easily jitted. or irclog.perlgeek.de/parrot/2009-04-21#i_1083550 or rt.perl.org/rt3/Ticket/Display.html...txn-471982 or magical unicorns and flying puppies.
chromatic I'm also interested in working on the dynops. I'm just not quite sure how to integrate them into the current runloop system.
Coke chromatic: ... don't we already have a way to integrate dynops into the current runloop?
(magical unicorns) see, that's the lorito I remember. =-) 21:42
chromatic We do, but if we start re-implementing existing ops in terms of dynops....
NotFound Coke: I think that now magical unicorns are called iPads.
Coke chromatic: trac.parrot.org/parrot/wiki/L1Recap ?? 21:44
chromatic That looks right, Coke. 21:46
Coke so, "next steps" ? 21:47
(also, having that under l1recap if we're now calling it lorito is confusing. =-)
chromatic Next step: revive the PCT-based ops compiler. 21:48
Rewrite to NQP. Whichever
Coke ok. what is the pct based ops compiler?
cotto_work That 21:49
s the ops_pct branch, which will be rewritten using nqp-rx in the very near future.
Coke ... EBOOTSTRAPRECURSION.
cotto_work We can check in generated code to deal with that. 21:50
Coke ok. if reviving the PCT-based ops compiler is part of the plan, it would be nice to see a plan of which it was a part. 21:51
cotto_work True. The plan on the wiki doesn't mention that. 21:52
The page needs some love.
21:54 bacek joined
cotto_work Coke, can you rename a wiki page? 21:58
21:58 shockwave left
Coke no clue. 21:59
cotto_work I can't see anything, but trac is goofy sometimes.
Coke looks like the trac project is working on this as of 2-3 days ago. 22:00
trac.edgewall.org/ticket/1106
22:04 lucian joined 22:10 mikehh joined
dalek rrot: r44506 | NotFound++ | trunk/src/pmc/oplib.pmc:
method oplib.ops_by_shortname
 22:17
22:22 Whiteknight joined
NotFound Whiteknight: just in time. Please take a look at trac.parrot.org/parrot/changeset/44506/ 22:22
cotto_work why not just return an empty array and simplify your code a bit? 22:25
NotFound cotto_work: just a habit, I suppose. 22:26
cotto_work NotFound, do you have some code testing that method? 22:32
Whiteknight NotFound: very nice. I contemplated something very similar to that in the past
inefficient implementation however. I think the oplib is setup as a skip list, so should be able to traverse it in log n time
NotFound cotto_work: In winxed. I was waiting opnions about the name before translating to pit and commiting.
Whiteknight: yes, but while in experimental stage I don't care. 22:33
Whiteknight fair enough
cotto_work Hopefully it becomes worth optimizing soon.
NotFound Opinions about the name? 22:34
Whiteknight "op_family" 22:35
but, not a strong opinion
NotFound I like that 22:36
cotto_work Whiteknight, have you thought about adding an API to oplib to allow new ops to be added?
Whiteknight cotto_work, yeah, I've pondered it 22:37
not sure how we would make it work though 22:38
would they be PIR-based "ops"?
or NCI-based "ops"?
or both, maybe?
we could certainly have a method that does the same job that loadlib does
cotto_work I was thinking in terms of Lorito, i.e. define new ops in terms of Lorito ops (but that's some time away). 22:39
Whiteknight actually, an ability to add an op with a PIR backend is quite intriguing
NotFound Wow, 73 set variants 22:40
Whiteknight oi! 22:42
cotto_work does that exclude set_returns_* and friends?
NotFound cotto_work: yes, just plain set
cotto_work One question about Lorito is how to handle INSP types. 22:50
NotFound cotto_work: with care 22:53
cotto_work I'll definitely be editing that L1Recap page tonight. 22:54
Whiteknight cotto_work: I think we're obviously going to want to provide those types preferential treatment, since most of our computations will involve them
cotto_work For a given Lorito 3-arg op foo, do we want separate code for all permutations of args similar to what we have now with PIR? 22:56
plobsing_ does a P type make sense in Lorito given that we can't treat PMCs as opaque?
cotto_work I was just thinking about that.
PMCs may be above what Lorito cares about. 22:57
plobsing_ If we're looking to cut down on the number of ops, can we have a separate 'load-constant' op and ditch all the constant/non-constant permutations? 22:58
Whiteknight cotto_work: we don't need all permutations. Optimize for the common cases
plobsing_: great idea 22:59
load_constant_i, *_s, *_p, and *_n would be great
cotto_work Would that be worth the extra expense needed to work with constant though?
chromatic I can't imagine Lorito level one caring about const/non-const arguments. 23:03
dalek rrot: r44507 | NotFound++ | trunk (2 files):
rename oplib method ops_by_shortname to op_family and add some tests
 23:06
23:09 kid51 joined
Whiteknight chromatic: if we're needing to fetch them from the packfile stream, we will need to care 23:13
23:13 lucian joined
Whiteknight unless we take pointers and just do pointer arithmetic 23:13
plobsing_ does Lorito have raw pointers? 23:14
chromatic Exactly.
Whiteknight A language with all the capabilties of C will be able to be translated into machine language very easily 23:19
23:20 paco joined
NotFound We may need to have a pointer to the constant segment in the context to do that. 23:21
23:25 bacek joined 23:31 paco left
bacek aloha 23:35
cotto, watch out! 23:36
dalek rrot: r44508 | bacek++ | branches/ops_pct/compilers/opsc/ops/oplib.pm:
Update OpLib to load num and skip file from proper location.
 23:39
rrot: r44509 | bacek++ | branches/ops_pct/compilers/opsc/t/04-oplib_BUILD.t:
Update test
rrot: r44510 | bacek++ | branches/ops_pct/compilers/opsc/t/04-oplib_parse_ops.t:
Update test
rrot: r44511 | bacek++ | branches/ops_pct/compilers/opsc/ops/oplib.pm:
Change load_num_file to use grammar.
 23:40
purl dalek: that doesn't look right
rrot: r44512 | bacek++ | branches/ops_pct/compilers/opsc/ops/oplib.pm:
Switch load_skip_file to use grammar
rrot: r44513 | bacek++ | branches/ops_pct/compilers/opsc/t/03-past.t:
Update test
rrot: r44514 | bacek++ | branches/ops_pct/compilers/opsc/builtins.pir:
Add "say" builtin
kudo/master: 4ab4b82 | pmichaud++ | src/Perl6/Actions.pm:
Fix subroutine lookup for &-sigiled barewords to use 'find_sub_not_null'.
23:43 snarkyboojum joined 23:44 ruoso joined
dalek kudo/master: 7680ab4 | pmichaud++ | src/core/Seq.pm:
Since we can now refer to &infix:<cmp> directly, do that instead
 23:46
bacek pmichaud, ping 23:54

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!