Parrot 3.5.0 "Menelaus" released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 27 June 2011.
pmichaud back again 00:05
we decided some time ago that language interoperability was going to take place via methods on compiler objects
that's exactly what the p6regex.pbc provides 00:06
indeed, this is partly a reaction to the old (bad) way of doing things, where compilers were invokable subroutines instead of full-fledged objects 00:07
so, what we really want to have here then, is 00:08
NotFound Fine, but the example you've provided with a compiler object also needed global namespace search.
pmichaud I said it was going away.
several times.
I can't just fix it right now to be the way it should be -- that really needs a deprecation cycle. 00:09
NotFound And I asked for something that can be used now without fear of deperactions. A lilltle misunderstanding. 00:10
pmichaud actually, you asked how to use the regex engine from pir.
so yes, a misunderstanding. 00:11
NotFound <NotFound> It will be possible to write a regex library with an api designed to be easy to replace its internals later?
pmichaud yes, it's possible. I even described the API.
but it *will* be possible, not it *is possible today* 00:12
NotFound Looks like the word "easy" is the key today ;)
pmichaud I'm sorry that I can't just change P6Regex's .compile method to do the right thing today.
If I do that, I'll break an existing API.
dalek rrot/soh-cah-toa/hbdb: ea395de | soh_cah_toa++ | src/hbdb.c:
Fixed segfault and 'command_table' so that it doesn't generate any build warnings with g++ or gcc
 00:13
pmichaud I just don't see "look up compiler object", "invoke .compile method", as being "internals" 00:14
NotFound From my external point of view everything in nqp is internal and subject to change. 00:17
pmichaud Fair enough. I can say that the basic structure of "Obtain compiler object. Invoke .compile on that object" is going to be the basic interface to the regex library. (The other stuff about looking up things in a namespace will definitely disappear.) 00:19
I can add in a temporary method on the compiler object that does the wrapping for you and implements the longer-term API if you like, but it'll be temporary until the standard method can be fixed. 00:20
(which could be a longish period of time)
(i.e., the temporary api method could hang around for quite a while.)
just a sec
NotFound pmichaud: maybe not a bad idea, if the temporary will last some time for easy transistion. 00:21
00:21 whiteknight left, whiteknight joined
NotFound Also, will be good if the compreg name is not subject to change. 00:22
pmichaud I'm certain that it will change, but I have a good reason for that.
There's going to need to be a transition period between the regex engine that nqp-rx provides and the new one that comes with 6model
so, we're going to have to have two regex compilers available during that transition 00:23
that way people can decide when they're ready to switch over to the 6model version
and as part of that switch, they'll switch the name of the compiler to the 6model regex compiler.
the rest of the API can remain the same. 00:24
NotFound Well, if the engines are going to be different, I guess trying to hide the difference will be pointless. 00:25
whiteknight how does the performance of the new engine compare to what is in nqp-rx now?
pmichaud it's still under development, but initially I'm guessing about a 30% speed improvement. don't have a good benchmark.
after LTM is implemented, I'm guessing an 80% improvement in grammar parsing.
whiteknight okay, I will take an educated guess 00:26
oh wow
pmichaud yes, it should be a dramatic improvement.
whiteknight that's "hold on, let me pick my jaw up off the floor" better
pmichaud the new engine avoids a ton of method calls. Also, we have native types in objects so we can avoid a ton of boxing/unboxing that nqp-rx has to do now.
whiteknight yes, native types is a huge deal. Rosella for one could benefit a huge deal from that improvement alone 00:27
pmichaud LTM takes what is currently a recursive-descent sort of process and turns it into a finite-state-automata sort of process, at least for selection among alternatives.
00:30 theory left, daniel-s joined 00:32 Coke left 00:33 Coke joined
whiteknight plobsing: ping 00:41
dalek rrot/whiteknight/packfilewrapper: e489677 | Whiteknight++ | t/pmc/packfileview.t:
Add in some stub test code to test .trigger('init'), but it doesn't work and I don't know why
whiteknight I cannot figure out precisely what the differences are between PBC_MAIN and PBC_PBC, and when each should be used 00:47
it looks to me like PBC_PBC doesn't do anything 00:48
or maybe it does, but I can't figure out exactly what 00:49
we need to untangle this crap
soh_cah_toa couldn't agree more 00:50
whiteknight I don't understand why we don't just have a function that says "Give me a flag, and I'll go through the packfile and execute all the Subs with that flag"
but instead, we have the beauty of src/packfile/do_sub_pragmas, which is horrible 00:51
I am starting to suspect that we can remove PBC_PBC, especially after we added main_sub handling to PackFile* 00:52
cotto_work whiteknight: istr trying to rip it out, with hilarious results 00:53
whiteknight cotto_work: we've done a lot of detangling work
the biggest problem is the extremely tangled web of garbage semantics that have been attached to load_bytecode over the years 00:54
cotto_work whiteknight: I wouldn't miss it a bit.
whiteknight I'm going to file a deprecation ticket, and I'll start a branch eventually
Also, I want to deprecate Eval, and old PackFile API functions
since I couldn't get those mentioned at #ps, can I get a greenlight on those?
pmichaud fwiw, I want a function that says 00:55
"Give me a flag, and I'll go through the packfile and return all of the subs with that flag"
whiteknight TT #2140, #1969 00:56
pmichaud executing them should be up to me
whiteknight pmichaud: that's my thought exactly
pmichaud: and instead of having just :load, :init, and :main flags, I want to have :flag("arbitrary string")
pmichaud exactly.
whiteknight okay, it's good to see we are on the same page :)
pmichaud (we discussed this before; you just said "execute all of the Subs with that flag" above and I want to make sure it's "return me all of the Subs with that flag" instead) 00:57
whiteknight yes, I'm trying to take this in the right direction by baby steps
cotto_work The PackfileWrapper does that now.
whiteknight pmichaud: I don't know if you've seen the new PackfileView PMC I've been working on. It's like Eval plus a good interface and more features
cotto_work er, view
pmichaud haven't seen it yet, no. I look forward to seeing it though :)
cotto_work It's nice. 00:58
whiteknight cotto_work: PackfileView.trigger("init") doesn't work. I just tried testing it
cotto_work: hence my rant about PBC_PBC
cotto_work whiteknight: more tests
gotcha
whiteknight PackfileView.trigger("load") does work beautifully, but only works once
because....We magically and helpfully clear :load and :init flags after we've executed a sub 00:59
cotto_work sigh
pmichaud ouch ouch ouch
whiteknight and we have to do that because Parrot tries to magically execute subs automatically too often
pmichaud Bad Parrot. No cracker.
cotto_work double sign
*sigh
whiteknight tell me about it
load_bytecode is the single biggest culprit
I am going to add a new form of load_bytecode that performs ZERO magic, and returns a PackfileView PMC 01:00
then, PackfileView will have methods to return lists of subs by flag, and the user can do whatever
cotto_work load_bytecode_stupidly
whiteknight load_bytecode_the_right_way
also, load_bytecode should not compile non-bytecode
Compiler.compile() should do that 01:01
or whatever the interface is to your particular compiler object
cotto_work I laugh as a defensive mechanism.
dalek rrot: f7985d1 | pmichaud++ | ext/nqp-rx/src/stage0/ (3 files):
Bring in latest version of nqp-rx, including 'make_regex' method

should be available on all future regex compilers, at least for a while.
whiteknight cotto_work: you need more defense. This code might attack you in your sleep
whiteknight cotto_work: can I get a greenlight on those two deprecation items? I want to get notices in before 3.6 01:02
also, I should open a ticket now for load_bytecode. I want to warn people that it's going to change, even if I haven't developed the alternative yet
pmichaud NotFound: as of f7985d1: gist.github.com/1068710
cotto_work whiteknight: which ticket?
whiteknight cotto_work: TT #1969 for Eval PMC 01:03
TT #2140 for the PackFile_* API functions
01:03 kid51 joined
pmichaud NotFound: I'll continue to support that API for a while -- the only thing that may change is the name of the compiler being used. 01:03
whiteknight I'm going to clean that subsystem up if it's the last thing I do on this earth
pmichaud afk for a while 01:04
cotto_work whiteknight: is PackfileView the replacement for Eval? 01:05
whiteknight yes, I need to get more input from jnthn to make sure I support all the features, but as far as I can see it currently does everything Eval once did
and I've got a good upgrade path all set up 01:06
cotto_work whiteknight: perfect. +1 once you specify that in the right place.
whiteknight thanks! I'm going to add that to apy.yaml now
cotto_work replied to the ticket 01:08
whiteknight and the packfile API functions?
I was going to say that work fell under the same ticket as API func renaming, but I'm changing some of the signatures too, so I wanted to open a second ticket 01:09
basically, all functions named "PackFile_*" are being replaced with shiney new functions named "Parrot_pf_*"
cotto_work whiteknight: 2140?
whiteknight yeah, I think so
cotto_work whiteknight: +1, though something that sensible hardly needs approval. 01:10
whiteknight I just want to make sure. Like I said, I haven't had the chance to raise the issue at #ps 01:11
I was really hoping I would be there yesterday, but fail
cotto_work whiteknight: sad face. I trust you saw the time change. 01:13
whiteknight yes, I am extremely happy about that
cotto_work me too. You've been missed.
It's also nice how much better the name is. 01:15
whiteknight yea 01:16
soh_cah_toa cleaner and consistent names make me VERY happy
whiteknight srsly 01:18
What I like is the visual separation. We can take one look at a function and say "yes, this is an exported API function"
plobsing whiteknight: pong 01:19
soh_cah_toa exactly
whiteknight plobsing: I'm trying to get a handle on PBC_PBC. I'm not entirely certain that flag in do_sub_pragmas does anything
I want to try removing it in a branch, but I don't want to waste my time if there is some mysterious hidden purpose that we can't live without 01:20
plobsing I remember it doing much the same as another flag, but I cannot recall which. perhaps :main.
whiteknight yes, it's almost exactly identical to PBC_MAIN
plobsing let me check
whiteknight but it doesn't cause :init subs to execute. PBC_MAIN does
PBC_PBC does cause the :main sub to be set in the initial context, but I don't think we need that anymore, now that packfiles keep track of the mainsub 01:22
plobsing: also, I want to start removing all this pragma code, and replace it with a few special purpose functions: One to return an array of all :init Subs, and one to return an array of all :load subs 01:23
We expose those to the users, and let the user choose what and when to execute
plobsing that seems like a good objective
whiteknight instead of all this magic do_sub_pragmas magic, with that function getting called at all sorts of random times, and needing to clear flags so subs don't execute twice, etc
I'm passed the point of antacids. I need to eat boxes of chalk when I hack parrot 01:24
plobsing if PBC_PBC doesn't trigger :init subs, how does Parrot_pf_prepare_packfile_init work? 01:25
whiteknight It doesn't work 01:27
at least, I wrote up a test for it today, and it did nothing
hence my investigation
so either it's doing something subtle and magical that I can't figure out, or it's sarlac fodder 01:28
and if you can't figure anything out, I'll invest the tuits to try ripping it out
cotto_work I'm digging through ancient history to see if I can unearth anything of relevance. 01:31
plobsing pretty sure you can't rip it out. it seems to be used by a lot of important stuff.
it appears you could try to merge it with PBC_MAIN 01:32
cotto_work My guess is that it means a pbc file is being loaded directly. I have no idea if that holds up.
whiteknight At the very least, I want to get it documented 01:33
I'll play with it eventually
plobsing it provides the semantics underlying Parrot_pbc_read() which (while deprecated) is used *everywhere*
cotto_work s/loaded/run/ 01:34
That's the most sense I can make of it. 01:35
plobsing I think a concerted effort to merge PBC_MAIN and PBC_PBC would either be successful or give sufficient insight to sort out the difference.
cotto_work +1 01:36
unfortunately I don't have hacking time for ~3+ hours, but I'll be glad to jump in later.
cotto_work goes 01:40
dalek TT #2144 created by whiteknight++: Deprecate do_sub_pragmas 01:45
TT #2144: trac.parrot.org/parrot/ticket/2144
whiteknight opening up deprecation tickets makes me so very very happy 01:48
Parrot_pbc_read is actually not used in too many places. And there's a new function for reading in bytecode files exposed through the embedding API that doesn't use Parrot_pbc_load without issues 01:50
although, I think the embedding API function does do_sub_pragmas(PBC_PBC), so I need to see if that's necessary
I may have cargo-culted that part 01:55
anyway, I'm out for the night. Will stare at all this angrily tomorrow morning 01:56
01:57 whiteknight left
dalek rrot/soh-cah-toa/hbdb: ddbbfa9 | soh_cah_toa++ | src/hbdb.c:
Removed NUM_CMDS and a few unnecessary comments since it did not end up being used
 02:16
rrot/soh-cah-toa/hbdb: 7133cd9 | soh_cah_toa++ | frontend/parrot_debugger/main.c:
Made t/src/checkdepend.t pass by temporarily renaming frontend/parrot_debugger/main.c.

This was because I removed the Makefile target for 'parrot_debugger' a long time ago since I plan on nuking it once HBDB is a little more feature-full.
rrot/soh-cah-toa/hbdb: f54b5df | soh_cah_toa++ | frontend/parrot_debugger/main.c.REMOVEME:
Forgot to add renamed file from previous commit
 02:18
rrot/soh-cah-toa/hbdb: c8c63f0 | jkeenan++ | MANIFEST (2 files):
Run tools/dev/mk_manifest_and_skip.pl to update MANIFEST and MANFIEST.SKIP.
 02:22
soh_cah_toa kid51++: thank you 02:23
for that and your recent commits as well. much appreciated :)
kid51 soh_cah_toa: That's needed when you add/delete files from the repo.
soh_cah_toa right
kid51 I had to do it so that perl Configure.pl would complete without sounding warning
init::manifest is first step in Configure.pl 02:24
soh_cah_toa whoops
kid51 running a smolder right now
So the only file which currently has FAILs in that branch is t/tools/hbdb/cmds.t (as expected). smolder.parrot.org/app/projects/rep...ails/17111 02:31
kid51 must sleep
soh_cah_toa ok good. see ya
02:32 kid51 left 02:40 everbrew joined 02:54 Limbic_Region left
plobsing msg kid51 (re: TT #1652) the issue documented in the ticket is old, fairly well understood, and has a more-or-less reasonable workaround. Based on the current symptoms, I would posit that this is a separate issue, likely having to do with a bug in the maintenance of compiler state between 'units' (which usually correspond to .subs). 02:54
aloha OK. I'll deliver the message.
02:59 lichtkind left, everbrew left 03:05 everbrew joined 03:14 woosley joined, jay left 03:36 giwi left 03:41 soh_cah_toa left 04:13 giwi joined
dalek p: ebe6acb | pmichaud++ | src/core/NQPMu.pm:
Parrot's Data::Dumper apparently requires boxed arguments.
 04:18
cotto ~~
04:21 everbrew_ joined
bubaflub ~ 04:23
hey cotto, can i ask you a question about VTABLE overrides?
sorear bubaflub, does it have to be cotto? 04:24
bubaflub sorear: nope.
sorear jnthn and I know rather more than we ought to about those :/ 04:25
bubaflub sorear: does it make sense for me to implement the is_same override for GMP Integers?
sorear: i'm thinking i shouldn't / can't and probably will just stick with is_equal* and cmp*
04:28 everbrew_ left
cotto bubaflub, don't bother. The Default implementation will be fine unless you're implementing some fancy pants semantics. 04:28
sorear, nice to have you back.
(technical term) 04:29
pmclass gmp_int provides integer provides fancy_pants { ... } 04:34
bubaflub roger that 04:35
sorear ...is_same is a vtable? eeeeew 04:46
imo, you should never override is_same, ever
it means pointer equality
cotto sorear, it's only implemented by default, pmcproxy, null, pointer and (inexplicably) hash 04:47
sorear cotto: glad to be back.
cotto sorear, where are you in the world? 04:48
sorear now? san diego, ca, us
cotto is that where you live?
sorear yes
cotto good to know. I suppose it means you're probably not going to be at yapc::eu though. 04:49
seen zloyrusskiy 04:54
aloha zloyrusskiy was last seen in #parrot 5 hours 7 mins ago joining the channel.
cotto msg zloyrusskiy if cotto isn't online, his close relative cotto_work might be. ;) 04:55
aloha OK. I'll deliver the message.
bubaflub do we have 'eq' for string equality or is it just plain ole == ? 04:58
more specifically, in Winxed 04:59
cotto bubaflub, winxed seems to use == for strings in its test harness 05:03
bubaflub cotto: great, that's what i thought 05:04
cotto sorear, did you see anything about mole?
sorear What is mole? 05:07
cotto It's the yet unimplemented M0 overlay language.
The only form that exists is some files in a git repo describing what it needs to do and a possible syntax. 05:08
github.com/cotto/mole/blob/0b07b75...doc/syntax
bubaflub is there a built in string cmp or do i need to roll my own? 05:09
05:10 pjcj left
sorear cotto: ah, didn't think to check cotto on github, I was looking at google and wikipedia :D 05:10
I'll check it out.
cotto sorear, I'd like your thoughts. Just be aware that it's very embryonic. 05:11
sorear of course.
which best to read first?
cotto criteria and syntax are the more important ones. They're all pretty short. 05:12
sorear hmm 05:13
how do you want my thoughts? I've had a few of them
cotto sorear, here or you can fork and send a pull request
I'm not picky.
sorear ok. 05:15
what do you mean by "smaller" macros than C? 05:16
I can imagine a mole with some stripped down lispy macros (let's call them inline functions with optional call-by-name) 05:17
cotto sorear, they can't be anywhere the same way C's can.
sorear I can also imagine not have builtin macros and relying on M4
cotto: why not?
cotto sorear, simplicity
sorear I also remain unconvinced of "INSP" 05:18
cotto sorear, the names or the types themselves
sorear I'm rather fond of having u?int< 8 16 32 64 >_t all at my disposal
cotto sorear, how would you map those to M0? 05:20
sorear it's a (minor) gripe I have with M0, not really a mole thing as such 05:21
at the end of syntax, why does "init_cf" have a retpc_label argument? 05:22
oh nm
I think "composed ops" should be renamed "macros" 05:23
cotto: what does calling conventions(3) mean? 05:24
cotto: 05:25
cotto sorear, that means that the language only allows pre-defined calling conventions.
sorear that's not really all that radical :)
most languages only allow one of a few calling conventions
has the M0 spec settled for what call_chunk means? 05:26
cotto sorear, I think it has
sorear where does the m0spec live these days? 05:27
cotto sorear, I don't mean that the calling conventions would change willy-nilly, just that the code that's not relevant could be omitted by manually picking the right macro (or composed op).
m0-spec branch in docs/pdds/draft/pdd32-m0.pod
github.com/parrot/parrot/blob/m0-s...d32_m0.pod
m0 spec?
aloha, m0 spec? 05:28
aloha cotto: m0 spec is docs/pdds/drafts/pdd32-m0.pod in the m0-spec branch
cotto aloha, m0 spec is also github.com/parrot/parrot/blob/m0-s...d32_m0.pod
aloha cotto: Okay.
05:33 fperrad joined 05:34 rurban_ joined
sorear cotto: do we want mole to have "non-trivial value types"? 05:34
cotto sorear, elaborate?
sorear cotto: imagine "struct point { int x, y }" in C
cotto in that case, yes
sorear void foo(struct point p) { // p receives the same stack layout as if foo(int x, int y) 05:35
alternatively, we could mandate that structs are only ever accessed using pointers
if structs are always pointers, then we would have a nice property: every mole variable corresponds to exactly one m0 variable
allowing non-pointer structs means that "var point foo" causes "foo" to mean TWO m0 slots 05:36
05:36 rurban left 05:37 rurban_ is now known as rurban
sorear cotto: I don't see anything about call_chunk in the m0 spec. 05:38
cotto sorear, goto_chunk
sorear cotto: I do not see anything in the M0 spec which can change the "current callframe pointer" 05:39
cotto sorear, it's implicit. Changing CF does that.
sorear what.
cotto The VM implementations do need to be aware that that's possible. 05:40
sorear that makes no sense
the current callframe pointer needs to be outside the cf
cotto I have running code that says otherwise.
cf[CF] == cf
sorear I'd like to see this code for myself. 05:41
cotto m0-prototype branch, t/m0/integration/m0_poke_caller.m0
sorear gets a second Parrot checkout so ey can read m0-spec and m0-prototype at once 05:42
cotto github.com/parrot/parrot/blob/57ad..._caller.m0
It's a bit convoluted, but at least well-commented.
sorear cotto: the sense-making that I need to see to beleive is in the interpreter
cotto Ah. I have a special case for it. 05:43
sorear Do all registers correspond to specific offsets in the CF?
is perl5 or c/ the current m0?] 05:44
cotto yes
perl5 is the more complete prototype
chromatic's working on the C implementation 05:45
sorear ick ick ick ick ick
cotto I won't say it's elegant. 05:46
sorear Are you willing to add the following phrase to the M0 spec? "Modifying CF or PC by any instruction is erroneous, unless it is done using the "set" opcode."
maybe all special registers need to be like that 05:47
cotto i.e. don't do add_i PC, PC, 9 ?
sorear yes
I think it's completely insane to require an m0 interpreter on a register-rich architecture to continually refetch the pc, or check for 2 in all opcodes 05:48
cotto sorear, is there a reason to discourage that? I doesn't strike me as something that people would be especially tempted to do in the common case.
sorear cotto: we should be explicit about what corners implementations are allowed to cut 05:49
cotto "check for 2"?
sorear, that's true.
sorear numeric value of PC
cotto: did you come to a decision on whether non-pointerized structs should be allowed as types? 05:54
05:55 zby_home left
cotto thinking, but leaning toward no 05:56
sorear, I think it makes more sense to limit the special registers to being modified by the register ops (set, set_imm, set_ref, deref) and GC/memory ops (sys_alloc, gc_alloc, copy_mem), but it does make sense to limit them. 06:00
actually, most of those should still be done indirectly
sorear indirectly? 06:01
the other thing that gets on my nerves is the fact that every goto_chunk requires a string lookup[
cotto operate on a non-special register PX, the do set XX, PX 06:02
If it were numeric, there'd need to be a fixup when loading extra bytecode
sorear why? 06:05
I don't follow that 06:06
what do you mean by "extra bytecode"?
cotto m0's equivalent of load_library
which I don't think has been specified
If chunk are numeric and goto_chunk is based on that number, those numbers will need to be updated if more than one m0 file is loaded so that the chunk numbers remain unique. 06:11
sorear cotto: I still don't understand what loading extra bytecode has to do with indirect usage of sys_alloc... OH you mean goto_chunk, sorry.
cotto: still, it bothers me. in the future, when we're defining the Sub PMC, it would be really useful if Sub could contain a fast reference to a chunk 06:12
sorear is thinking hard about calling conventions now 06:13
cotto sorear, I'm open to suggestions. It's also not out of the question for implementations to cheat.
sorear cotto: do we want goto_chunk to be able to cross bytecode-file boundaries? 06:14
cotto sorear, if it doesn't, what will? 06:16
sorear I want to allow anonymous chunks 06:17
I think there should be a native M0 way to refer directly to a chunk 06:18
like how C has function pointers
*not* closures, mind
06:19 pjcj joined
sorear I have the following slight worry 06:19
cotto sorear, that's an interesting proposal 06:20
sorear m0 code that wants to call subs needs to know how to allocate CFs
which means that all m0 code is intimately tied to a GC
and possibly worse, to an object model 06:21
cotto yes. There's the possibility of optimizing the GC for that by having a dedicated cf pool.
How would it be tied to the object model? There isn't one yet.
06:22 giwi left 06:23 giwi joined
dalek rrot-gmp: 658b5e6 | bubaflub++ | / (9 files):
vtable overrides for cmp* and is_equal* with tests
 06:23
bubaflub msg dukeleto latest parrot-gmp commit finishes vtable overrides; next up is more docs and then nqp/rakudo examples. 06:24
aloha OK. I'll deliver the message.
dalek kudo/nom: b9db729 | jonathan++ | src/Perl6/Metamodel/ClassHOW.pm:
Fix .^isa bug spotted by tadzik++/pmichaud++; was missing decont, as guessed.
 06:36
06:48 pjcj left 06:55 pjcj joined
sorear cotto: allocating a callframe needs to leave a certain number of words at the beginning for the GC/object model to use for polymorphic access 07:03
somehow, the GC needs to know that this object is a callframe
and I presume we'll give callframes the PMC API 07:04
cotto sorear, I haven't been thinking of them as full-fledged objects.
sorear I just got back from thinking stuff. I'd like to try and write an implementation of mole, once I get done with last week's niecza complaints 07:05
cotto sorear, sweet. What tools are you thinking about using?
sorear perl 6 (niecza) is closest on my mind
but I could be convinced to use any language with a good parser generator and a GC 07:06
dalek p: 5c9cd12 | jonathan++ | src/ops/nqp.ops:
Add op for checking if an attr has been initialized, thus exposing one of the recent REPR additions.
cotto sorear, C or something that'll eventually target M0 is preferable. 07:09
It's important that it be fast. 07:10
sorear mm.
I'll dust off my yacc then.
cotto I was looking at lemon, but it's just a variant of the traditional bison/flex method.
sorear (really I'm more excited about an excuse to play with hygenic macro implementation than I am to do mole per se) 07:11
fork mole, or separate repo?
cotto not sure why that's exciting, but sure 07:13
better than C at least
sorear what are you caling better than C? 07:14
cotto sorear, whichever works better for you
hygienic macros
sorear hmm 07:17
cotto, it looks like "possibilities" and "syntax" are in conflict
do we or do we not want to have a new syntax?
cotto not terribly surprising
dalek kudo/nom: 8cb00d5 | jonathan++ | / (2 files):
Fix my ($a, $, $b) = 1,2,3;
 07:19
kudo/nom: 8de8d4b | jonathan++ | / (2 files):
Bump NQP_REVISION; chase 6model API update.
kudo/nom: 672c32a | jonathan++ | src/ (2 files):
Only use default attr init closure if the attribute is not otherwise initialized. Should work even if user provides their own BUILD.
kudo/nom: 9000c38 | jonathan++ | NOMMAP.markdown:
Update nommap.
cotto sorear, at the time I wrote that, it seemed more feasible to reuse existing compilers or toolkits than it does now. 07:20
I'm still not a fan of writing a new compiler before we can start go get work done on top of M0, but it does appear to be the best way forward that I've looked into. 07:21
winxed isn't easy to retarget and pmichaud says that PCT isn't designed to output something as low-level as M0.
sorear it generally seems to me like a given m0b code will generally be tied to one m0 implementation 07:23
cotto sorear, I explicitly don't want that to be the case. What gives you that idea?
sorear since it will rely on a specific procedure for allocating callframes, perhaps a specific layout of callframes, and a specific set of ffi calls to get anything interesting done
cotto The callframe layout is pretty well-defined. 07:24
ffi will be very important at first, then decreasingly so as we port existing C code. 07:25
I'm excited to see damian talk about Perl 6 at yapc::eu. 07:26
sorear how do you allocate a call frame in portable m0?
07:26 giwi left, giwi joined
sorear I don't understand m0 spec line 914 07:26
cotto In C, *x is the same as x[0]. In Perl, that doesn't apply. 07:27
sorear I don't understand how this is relevant to writing a m0 interpreter
cotto It means that $cf[CF] always points at $cf, and that if you change $cf[CF], $cf needs to be made to point at the updated value. 07:29
sorear C interprets *x as meaning x[0] 07:30
this is just syntax
it doesn't mean anything deep
cotto right
sorear so I'm very confused by that spec part
07:30 mj41 joined
sorear either it was written by somebody who doesn't get C, or maybe I'm just tired 07:30
cotto heh 07:31
That's probably a think-o on my part. 07:32
sorear the trip kinda messed up my sleeping
cotto there you go 07:33
dalek rrot/m0-spec: bbd578c | cotto++ | docs/pdds/draft/pdd32_m0.pod:
remove a confusing bit, add some safe assumptions about special registers
cotto I'm going to be Perl6'd out after yapc::eu. It'll be great. 07:34
sorear yeah. I'll be following it closely 07:35
cotto sorear, have you heard of or looked at lemon? 07:38
sorear no
cotto It's very popular not to have looked at it. 07:39
07:41 pjcj left
dalek kudo/nom: 2898945 | jonathan++ | src/Perl6/Metamodel/BOOTSTRAP.pm:
Add missing multi-dispatch cache invalidation.
 07:45
kudo/nom: 3279598 | jonathan++ | NOMMAP.markdown:
Remove now-resolved .Bool dispatch issue from nommap.
07:48 pjcj joined 08:31 Eclesia joined
Eclesia hi 08:32
dalek kudo/podparser: b9db729 | jonathan++ | src/Perl6/Metamodel/ClassHOW.pm:
Fix .^isa bug spotted by tadzik++/pmichaud++; was missing decont, as guessed.
 08:35
kudo/podparser: 8cb00d5 | jonathan++ | / (2 files):
Fix my ($a, $, $b) = 1,2,3;
kudo/podparser: 8de8d4b | jonathan++ | / (2 files):
Bump NQP_REVISION; chase 6model API update.
kudo/podparser: 672c32a | jonathan++ | src/ (2 files):
Only use default attr init closure if the attribute is not otherwise initialized. Should work even if user provides their own BUILD.
kudo/podparser: 9000c38 | jonathan++ | NOMMAP.markdown:
Update nommap.
kudo/podparser: 2898945 | jonathan++ | src/Perl6/Metamodel/BOOTSTRAP.pm:
Add missing multi-dispatch cache invalidation.
kudo/podparser: 3279598 | jonathan++ | NOMMAP.markdown:
Remove now-resolved .Bool dispatch issue from nommap.
kudo/podparser: 9cd2db4 | tadzik++ | / (13 files):
Merge branch 'nom' into podparser
 08:36
kudo/podparser: 9fb8447 | tadzik++ | t/pod/01-delimited.t:
Untodo a test thanks to isa fixes
kudo/podparser: 75c79fb | tadzik++ | tools/build/Makefile.in:
[Makefile] Add a podtest target
woosley Failed to compile parrot on Solaris :-( 08:37
Here is the build log: pastebin.com/2WJ1HeTk 08:38
tadzik oh 08:41
bubaflub woosley: 'Dead object found!' error is not Solaris specific - i think that's a GC bug 08:48
tadzik woosley: does that occur when you build with --gc=ms2?
woosley tadzik: no, I build parrot with no options 08:49
tadzik: perl Configure.PL && gmake
08:50 mj41 left
tadzik woosley: yes, but could you try with --gc=ms2 and see if the problem still occurs? 08:51
dalek kudo/nom: cc83922 | moritz++ | t/spectest.data:
6 more passing test files (now at 4.6k passing tests)
 08:52
woosley tadzik: oh right, building... 08:54
tadzik: build is success, thanks for the tip~~ 09:03
09:07 fperrad left 09:09 fperrad joined
dalek kudo/nom: 5c39eca | jonathan++ | / (3 files):
Should not compose subclasses before their parent classes (will support this later probably, but for now it's a no-no). Fixes WhateverCode ~~ Callable issue.
 09:14
09:17 pjcj left 09:25 fperrad left 09:36 fperrad joined 09:38 pjcj joined 09:56 jsut_ left 09:59 woosley left 10:03 mj41 joined 10:27 whiteknight joined
whiteknight good morning, #parrot 10:28
10:29 silug left
moritz good morning whiteknight 10:30
Eclesia hi whiteknight 10:37
whiteknight hello Eclesia, moritz. How are you two doing today?
moritz is quite relaxed 10:38
vaction-ish at my parents in law, hacking with a sleeping baby on my lap 10:39
Eclesia doing some java like every day 10:40
whiteknight moritz: yeah, a warm baby sleeping on you can have quite the calming effect 10:47
10:47 Mask joined 10:49 Eclesia left 10:56 Mask left 10:57 Mask joined
dalek kudo/nom: 1dc9308 | moritz++ | / (2 files):
Bool.Int, run tests
 10:57
kudo/nom: 32ab8d4 | moritz++ | src/core/BackTrace.pm:
change BackTrace handling a bit: collect all the information, and only filter on strintification
11:10 mj41 left 11:13 daniel-s left 11:14 ambs joined 11:17 Coke left, Coke joined 11:24 mj41 joined 11:29 Coke left, Coke joined 11:34 Mask left 11:54 giwi_ joined 11:55 jay joined 11:57 giwi__ joined 11:58 JimmyZ joined 11:59 giwi left 12:02 giwi_ left 12:06 lichtkind joined
dalek kudo/podparser: 13ce60f | tadzik++ | / (2 files):
Fix nested blocks, import more tests for that
 12:14
kudo/podparser: 587360f | tadzik++ | t/pod/01-delimited.t:
Import more pod tests. We now fully pass 01-delimited.t
12:29 silug joined
dalek kudo/podparser: 25cc743 | tadzik++ | / (3 files):
Parse paragraph and abbreviated blocks, import tests for those (everything passes)
 12:29
12:33 everbrew left
dalek kudo/nom: 8f7a4ec | pmichaud++ | src/core/Nil.pm:
Nil should stringify to '' without an "undefined" warning.
 12:38
kudo/podparser: 74bfbe4 | tadzik++ | / (3 files):
Fix END block handling, we now pass S02-whitespace_and_comments/end-pod.t
 12:44
kudo/nom: 1701cb2 | pmichaud++ | / (4 files):
Add Stringy role. prefix:<^> enforces numeric context. Another spectest file.
 13:08
13:09 fperrad left 13:10 fperrad joined
bubaflub ~ 13:15
jay Hello Parrot World
tadzik hello jay 13:17
jay GMorning, tadzik
Advice: I want to write a method for a 'for' type loop which iterates over elements of a vector, a. Do you recommend looping with an integer like a traditional C for loop, or using something like shift to work directly with the elements of a? Perhaps there would be side-effects of shifting (e.g. it would destroy a)? 13:21
Wow, that didn't work. Must have been a special character in there, sorry. 13:22
dalek kudo/nom: 0849b9d | pmichaud++ | t/spectest.data:
Some t/spectest.data note updates.
 13:25
p: 0108338 | pmichaud++ | src/core/NQPMu.pm:
Fix to .__dump for native attributes -- jnthn++.
Coke STR that we currently have no advisory board. yes?
jay; you could... use an iterator? 13:26
13:26 mj41 left
Coke if it's a array-like thing, you can manually iterate over the elements if they always go from 1 to elems-1, but an iterator is more generic. 13:26
in pir: $P2 = iter $P1 # get $P1's iterator 13:27
13:29 UltraDM joined
jay I'm looking at squaak's for() at the moment. It iterates in steps rather than over elements (NQP). But I do have a working PIR iterator example from a generic print() that I implemented. I think I can do this. 13:29
( early AM optimism with a cup of coffee... )
Coke github.com/partcl/partcl-nqp/blob/...ns.pm#L108
if you're in nqp, I think it's much easier. 13:30
whiteknight for @array -> $item { ... }
Coke ... yes, that. ;)
jay whiteknight: curious... is that Perl6 syntax, or something I never did in Perl5? 13:31
whiteknight that's perl6 syntax
moritz the perl5 equiv would be for my $item (@array) { ... }
Coke in perl5, that'd be for my $item (@array) { ... }
me lags.
jay Good... feeling better about my long-term memory. 13:32
By the way, is whiteknight++ shorthand for "applause" or "thanks"? Didn't ask yesterday.
Coke jay: I feel your pain. on parrot projects alone, I work with, what, about 10 different languages?
++ is karma.
karma whiteknight? 13:33
aloha whiteknight? has karma of 0.
Coke karma whiteknight
aloha whiteknight has karma of 1649.
Coke every ++ gets you a point. You can redeem them for... um...
jay karma jay
aloha jay has karma of 3.
Coke we haven't figured that part out yet.
jay interesting!
Coke karma Coke
aloha Coke has karma of 229.
atrodo Ask whiteknight, he has a prize of something at some level
jay jay--
karma jay
aloha jay has karma of 3.
Coke ah, aloha. You've clearly forgotten about all my old karma that purl had.
you can't karma yourself.
jay so you can't lose karma?
Coke jay--
jay karma jay 13:34
aloha jay has karma of 2.
jay Ah -- gotcha
13:34 rurban_ joined
Coke jay++ #offset 13:34
jay karma jay
aloha jay has karma of 3.
Coke jay: there's a lot of nqp-rx code out there. if you're looking for samples, rosella, partcl (github.com/partcl/partcl-nqp) both have a lot of it. 13:35
13:36 rurban left 13:37 rurban_ is now known as rurban
jay Thanks. I seem to be getting better at writing functions, say in Runtime.pm. I'm less confident with methods, because I'm never sure what is what and how I need to be interacting with the PAST. 13:38
whiteknight every 10,000 karma points earns you a donut 13:39
of course donuts only come in packs of 6, so you need 60,000 karma points to cash out effectively
jay And maybe 1,000 points for a Munchkin? Those I think come in boxes as small as 20. 13:41
Coke nope. 25.
though the last time I asked if I could less than that, I got one free.
*get 13:42
13:43 Eclesia joined
whiteknight is signing off for a while. will be back later 13:45
13:45 whiteknight left
dalek kudo/podparser: 12097c5 | tadzik++ | t/pod/04-code.t:
Handle code blocks properly, import 04-code.t
 13:48
kudo/podparser: 571755c | tadzik++ | / (3 files):
Handle code blocks properly, import 04-code.t
 13:49
13:51 giwi__ left
benabik ~~ 14:01
14:01 GodFather joined
tadzik hello benabik 14:01
NotFound Everytime you mention C++, C win karma. No justice ;) 14:04
tadzik maybe we should've named Perl6 Perl++ after all ;) 14:05
jay I just realized something: when I asked that question about a for-type of loop, the answers were about doing it in NQP-rx and PIR. This seems to be very different from building a language and writing new 'for' and 'for-init' actions. Writing actions for a new grammar really seems (to me) like a very different beast. 14:06
14:06 giwi joined
jay So I need to be more aware of my own questions. Sorry. 14:07
dalek kudo/podparser: 40859e6 | tadzik++ | / (2 files):
Fix comment block parsing, add tests
 14:08
Coke context is key, yes. 14:14
if you want your HLL to have a for loop, you could chec out, for example: 14:15
github.com/partcl/partcl-nqp/blob/...nds/for.pm # a runtime version written in nqp
... but you probably want a compile time version:
... which I cannot find at the moment. ;) 14:16
jay lol yes, compile-time version. Thanks. Let me struggle with this, though, I see PAST:Op.new with :pasttype('for') which seems to be iterating over elements of a child. Character-building. 14:17
14:20 hercynium joined
Coke (turns out partcl sucks as an example in a lot of cases, because the /grammar/ isn't like any other language. 14:21
jay Ooo.... I got something. Not the right answer, but at least it didn't barf! > >
for (i in c(1,2,3)) { print(i) }
1 2 3
>
NotFound jay++ 14:22
Eclesia think jay will have a hll language before me 14:23
14:23 JimmyZ_ joined
jay jay thinks his HLL language might do unpredictable things... like his old Perl5 code. 14:24
Coke jay - you're probably referring to the parent node instead of the child node. 14:25
dalek kudo/nom: 3aa3352 | moritz++ | t/spectest.data:
two more passing test files
14:27 jsut_ joined
jay Coke... I eliminated all squaak's step stuff, the defined loop in this way in place of all the while stuff: 14:28
my $loop := PAST::Op.new( $iter, $body, :pasttype('for'), :node($/) );
14:28 JimmyZ left 14:29 JimmyZ_ is now known as JimmyZ 14:36 mj41 joined
jay " Iterate over the first child in groups of elements given by arity (default 1). For each iteration, invoke the second child, passing the elements as parameters. " How does the body (the second child) access the parameters? 14:37
This is PAST::Op.new ... :pasttype('for')
as documented docs.parrot.org/parrot/devel/html/d...t.pod.html 14:38
jnthn__ jay: Same way as any block gets/accesses parameters
(PAST::Var with scope parameter) 14:40
Coke msg alester Have you seen the talk about compiler annotations on p5p? 14:41
aloha OK. I'll deliver the message.
14:44 mj41 left
jay jnthn__++ I'm getting there. 14:47
14:51 kuku joined
dalek kudo/nom: c12b7cc | pmichaud++ | src/core/List.pm:
Fix test for $!items in List.munch().
 14:52
kudo/nom: 5fac548 | pmichaud++ | src/core/operators.pm:
Improve list handling in sequence generator.
14:55 darbelo joined 15:01 kuku left 15:05 UltraDM left 15:08 daniel-s joined 15:10 JimmyZ_ joined 15:14 theory joined, JimmyZ__ joined, JimmyZ left 15:15 JimmyZ__ is now known as JimmyZ 15:17 JimmyZ_ left 15:23 logie joined
dalek kudo/podparser: 48ed49c | tadzik++ | src/Perl6/SymbolTable.pm:
[SymbolTable] Ignore undefined parameters in cache key, saves a lot of "Use of uninitialized value in string context" when passing :name(Mu)
 15:26
kudo/podparser: 3a828b7 | tadzik++ | / (4 files):
Parse lists properly, makes 06-lists.t
kudo/podparser: 0fda6ab | tadzik++ | t/pod/04-code.t:
Follow the decision about disallowing implicit code blocks in abbreviated and paragraph blocks in 04-code.t
15:30 theory left 15:33 fperrad left
dalek kudo/nom: ecc173b | pmichaud++ | NOMMAP.markdown:
Add NOMMAP note about $/ and $!.
 15:34
15:36 fperrad joined 15:37 daniel-s left 15:40 mj41 joined 15:44 GodFather left 15:46 JimmyZ_ joined 15:50 JimmyZ left 15:51 JimmyZ_ is now known as JimmyZ 16:00 theory joined 16:04 Eclesia left
dalek kudo/nom: 7d4d042 | pmichaud++ | / (3 files):
Initial implementation of Junction type.
 16:15
kudo/nom: 15ec618 | pmichaud++ | src/core/ (6 files):
Refactor .gist to more closely match the spec.
kudo/nom: b4d5e56 | pmichaud++ | src/core/Junction.pm:
Add Junction.ACCEPTS.
kudo/nom: 5f00dbc | pmichaud++ | NOMMAP.markdown:
Add Junction dispatch to NOMMAP.
16:20 JimmyZ left 16:24 mj41 left
cotto_work ~~ 16:28
jay If anyone is bored (!) and I just posted a note to parrot-users documenting the current state of my (failed) attempt to implement a new 'for' grammar/action. I think I must be close, but just don't handle the loop elements and parameters properly with the body. Off to lunch... gone crosseyed. 16:30
16:36 everbrew joined 16:40 lucian joined, rurban left 16:41 rurban joined
dalek kudo/nom: 1e4b69a | moritz++ | t/spectest.data:
three more passing test files
 16:47
16:48 jevin joined
dukeleto NotFound: ping 17:06
msg NotFound what is the license of Winxed? winxed.git doesn't have a license file. Since winxed is snapshotted into parrot.git, we need to be clear about licensing 17:07
aloha OK. I'll deliver the message.
cotto_work dukeleto: good catch
dukeleto cotto_work: i am working through a huge list of questions that is the application for the Software Freedom Conservancy
cotto_work dukeleto++ 17:10
NotFound dukeleto: 17:17
pong
Rigth, I forgot again to put a license file. 17:18
dukeleto NotFound: i can haz license? 17:25
NotFound: also, please put it into ext/winxed in parrot.git
dalek nxed: 0bcf37f | NotFound++ | LICENSE:
license
 17:31
rrot: 41fc268 | NotFound++ | ext/winxed/LICENSE:
winxed license
 17:33
NotFound Done 17:34
17:38 Eclesia joined
Eclesia hi 17:38
dukeleto NotFound++
Eclesia: how goes it?
Eclesia how goes what ? 17:39
dalek kudo/nom: a05e994 | pmichaud++ | src/core/Whatever.pm:
Let Whatever.gist return '*' instead of 'Whatever<...>'. Perhaps Whatever.Str should do something similar.
dukeleto Eclesia: it is just a saying. It means "hello!"
Eclesia gine then 17:40
fine*
NotFound What's up, doc?
dukeleto Eclesia: may I ask, what is your mother tongue?
Eclesia: i.e. native language
Eclesia dukeleto: from the country of smelly cheese :D 17:41
dukeleto: (france) 17:42
NotFound You know what's the problem on learning C? The lack of native teachers ;)
(But maybe the joke is older than C) 17:43
17:55 dmalcolm joined 18:02 mj41 joined
plobsing NotFound: the problem with learning human languages is that people tend to not like it when you try to dissect the interpreter to figure out what is really going on. 18:08
benabik The debugging interface for the natural language compiler needs work. 18:11
18:12 mj41 left
NotFound plobsing: that's the problem with closed source. 18:19
18:21 logie left 18:28 estrabd joined 18:34 whiteknight joined, giwi left 18:36 giwi joined
whiteknight good afternoon, #parrot 18:37
Eclesia good evening whiteknight 18:40
whiteknight hello Eclesia. How is the hacking going today? 18:43
Eclesia improving tokenizer
going fine
18:46 silug left
whiteknight so I haven't taken a lot of time to really study it. What is your Eria project about? 18:50
Eclesia whiteknight: some kind of multi-syntax model (extendable) and a default backend language (static typed, object oriented and with contracts). 18:53
whiteknight: also aiming to have it cross vm. make it a specification if possible. I'll implement it on apache harmony after parrot 18:54
whiteknight oh nice 18:55
Eclesia would like it to be on a 'public domain' vm ... but haven't found one :( 18:56
18:57 lucian left 18:58 logie joined
NotFound Eclesia: UCSD p-code? 19:04
atrodo NotFound> I wondered the same thing myself
19:05 preflex left 19:07 preflex joined
Eclesia NotFound: that looks nice. 19:14
whiteknight msg plobsing I removed all calls to Parrot_pf_prepare_packfile_init, and do_sub_pragmas(PBC_PBC). builds and all tests pass. 19:15
aloha OK. I'll deliver the message.
19:33 preflex left 19:36 jsut joined
whiteknight kid51: ping 19:36
19:36 preflex joined
whiteknight msg kid51 The whiteknight/packfilewrapper branch is mergible, as far as I am concerned. Represents feature additions, no real feature changes. I would like to merge it tonight if possible, but will wait till after the release if you prefer. Let me know 19:37
aloha OK. I'll deliver the message.
19:40 hercynium left
dalek kudo/nom: 51d0614 | pmichaud++ | src/core/Cool.pm:
Fix some copy-paste errors in Cool's string subs.
 19:40
19:40 jsut_ left
dalek nxed: 51fa079 | NotFound++ | winxedst1.winxed:
Indirect attribute access.
 19:43
kudo/nom: 49b4b78 | moritz++ | / (4 files):
roots and tests
NotFound whiteknight: ping 19:45
whiteknight pong
NotFound whiteknight: Do you think that feature will allow to get rid of the bulitin getattribute?
whiteknight probably, yes 19:46
NotFound Good
I'm going to keep it for some time, anyway.
whiteknight ok 19:47
dalek rrot/whiteknight/pbc_pbc: 820df60 | Whiteknight++ | / (4 files):
Remove PBC_PBC flag, with no apparent ill effects
 19:48
19:53 soh_cah_toa joined
dalek p: 7426748 | pmichaud++ | src/core/NQPMu.pm:
Remove extra boxing... turns out the .__dump issue was in NQP, not Parrot.
 19:57
20:07 pjcj left 20:28 pjcj joined, mj41 joined
cotto_work whiteknight: I'm quite surprised that so simple a patch works. 20:33
whiteknight cotto_work: I've got more work to do in that branch. I might be able to get *much* further along with a comprehensive refactor than I anticipated 20:34
it's turning out that we've done a heck of a lot to make all this code unnecessary 20:35
benabik Which code is this?
whiteknight especially our improved handling of main subs in PackFile*
benabik: pragma-related code in src/packfile/api.c
cotto_work: I think I can get rid of PBC_MAIN too, for that exact reason 20:36
cotto_work whiteknight: even better 20:39
20:44 silug joined
whiteknight We're going to have the system pmichaud and I were talking about last night, as early as 3.7. 20:44
You'll get back a PackfileView, you'll call pf.all_subs('init') and get back an array of those subs for you to execute at your leisure 20:45
and because you're executing them directly, not in a nested runloop, there are probably performance and stability wins
I'll add in a new load_bytecode variant with the new semantics, deprecate the old one too
bubaflub do we have a pbc migrator between versions? 20:46
whiteknight no 20:47
in fact, my system segfaulted just from you mentioning that
dalek rrot/whiteknight/pbc_pbc: 0f688ae | Whiteknight++ | src/ (3 files):
Remove most calls to Parrot_pf_prepare_packfile_init. That function now calls do_sub_pragmas(PBC_MAIN), which should do what PackfileView.trigger('init') expects
 20:48
rrot/whiteknight/pbc_pbc: d417058 | Whiteknight++ | t/pmc/packfileview.t:
Fix t/pmc/packfileview.t so that the test for .trigger('init') works as expected
plobsing bubaflub: the main problem with a PBC migrator is there are many things that can modify PBC between versions, the most obvious (and least common) of which is actual format changes. 20:50
there's also changes to how PMCs choose to serialize, changes to opcode libraries, changes to included constants, ...
20:52 Eclesia left
dalek rrot/whiteknight/packfilewrapper: acb29d9 | Whiteknight++ | api.yaml:
Add PackfileView to api.yaml as experimental
 20:53
cotto_work Maintaining perfect pbc compatibility would be very unpleasant.
plobsing it would be better if all those confounding issues didn't conspire to make it so 20:54
benabik We need an interchange format. The current one appears to be PIR, and I somewhat dislike that. 20:55
plobsing for example, if we didn't tie the core oplib version to parrot version (and also allowed other oplibs to be properly versioned)
benabik interchange isn't the right word... I mean version-to-version.
plobsing if PMCs had a notion of a PMC library, they too could be versioned like ops
whiteknight how hard would it be to add such a beast?
plobsing and constants... those are just a mess and someone needs to rethink how they work. textual inclusion is not the answer 20:56
whiteknight what needs to be rethought about constants?
plobsing whiteknight: pretty much everything. making them available through .pasm includes is a recipe for disaster. 20:57
whiteknight oh, you mean .const declarations?
cotto_work That's a decidedly crummy mechanism. I'd love to have a better one.
whiteknight I figured that was a compile-time thing
benabik Especially with .pasm being a mostly dead format.
Coke the long term goal was to have a pbc migrator, but we decided things were too volatile for now.
plobsing whiteknight: it is a compile-time thing, but they are used to expose things that should be properties of the executing VM (not necessarily the compiling VM) 20:58
which is why we need a separate mechanism which can operate at runtime, because the appropriate values are not available until then 20:59
whiteknight oh, you mean the automatic parsing of C-level enums into PASM constant files?
plobsing yes. I'm refering to the strategy as a whole, not the capability (which isn't too bad in and of itself).
whiteknight so let's start deprecating that mechanism and the PASM files that are the worst offenders 21:00
plobsing we need a replacement first 21:01
benabik plobsing++
plobsing given a well thought out replacement, the way forward is much more clear
whiteknight We can still use integer constants, just add a mechanism to look them up by string name from some common repo object 21:02
plobsing so then we need an implementation of this repo object
and the ability for 3rd parties to add to it somehow
or we should use multiple repo objects (I don't like registry-type solutions) 21:03
cotto_work ResizableStringArray attached to interp's iglobals array?
er, hash
dalek TT #2145 created by whiteknight++: Experimental PackfileView PMC
TT #2145: trac.parrot.org/parrot/ticket/2145
whiteknight I don't think it needs to be an actual hash 21:04
just some kind of object that uses a two-level key to look up constant values
$I0 = repo["cclasses"]["whitespace"]
or could be a method: $I0 = interp.constant("cclass", "whitespace") 21:05
cotto_work whiteknight: why two-level? 21:06
21:06 mj41 left
whiteknight to separate out the different types of constants we have 21:06
basically, like a namespacing consideration
cotto_work I mean, why say that there are exactly two levels?
whiteknight or, we have a single level: $I0 = interp.constant("cclass_whitespace") 21:07
plobsing I'm not liking the idea of a big global variable like that. It seems inelegant.
cotto_work Having an arbitrary number of levels is probably overengineering it.
whiteknight My thought is that it doesn't need to be a variable
plobsing so then what is it?
whiteknight I mean, the implementation is not nearly so important as a string-based interface
NotFound For interpreter constants, that may be work, but for libraries? 21:08
plobsing call it what you want, a registry such as that is global state
whiteknight okay. So, what else would you propose?
dalek rrot/whiteknight/packfilewrapper: fc25455 | Whiteknight++ | / (46 files):
resolve api.yaml conflict after merge from master
cotto_work Might this be a better place to put the tiny amount of configuration data that's actually useful? 21:09
whiteknight Alternative, maybe, would be to change is_cclass_i_i_s to is_cclass_i_s_s
and avoid the use of integer constants entirely
plobsing whiteknight: that just punts on this particular case. the ability for constants is still required elsewhere. if not in core, then in extensions. 21:10
dalek kudo/nom: 533cd63 | moritz++ | t/spectest.data:
run 4 more test files, pass 5.1k tests
whiteknight there are two issues: Avoiding the use of PASM files to represent enum constants from the C code, and providing nice interfaces to get access to constants
cotto_work There's no urgent need to get rid of our constants. We can take the time to think of something elegant. 21:11
whiteknight elegant smellegant
let's pull out the damned codehammer and smash a round peg into a square hole every once in a while
plobsing we could provide PBCs which contained serialized hashes 21:13
load_bytecode $P0, 'some_constants'; $P1 = $P0[0]; $I0 = $P1['constname']
whiteknight isn't that what our config hash is now? 21:16
plobsing yes, so there is precedent
whiteknight except it's built-in and it's filled with dozens of keys of useless, space-filling garbage
including duplicate garbage 21:17
plobsing PBC dedups
we might also consider a dbm-alike
tadzik seen dukeleto 21:18
aloha dukeleto was last seen in #parrot 3 hours 37 mins ago saying "Eclesia: i.e. native language".
plobsing there's plenty of solutions out there for kv stores
whiteknight yes, no question 21:19
if what we want is a key-value lookup to use string names to find the runtime values of particular integer constants, we have options
so, is it settled that we want to go that route? 21:20
plobsing that's the direction I'd like to see to resolve this issue, but this is a large issue with the potential to affect many if not all projects
whiteknight yeah 21:22
jay Sorry to interrupt, but I hit a wall on my 'for' actions and wanted to work on building a class into my HLL (again, essentially a modification of squaak). Best practices: where should the code go? src/Classes/classes.pir or something, which would then be referenced from setup.pir and/or src/nqr.pir? Or should I be writing NQP someplace? 21:25
whiteknight jay: write it in whatever language you are comfortable with. src/Classes/classes.nqp would be fine 21:26
jay And a related question: is there a "current" HLL which is "close" to squaak in some sense? I looked at winxed and partcl and they seem to be completely different beasts. Is the Octave/Matlab project still going? 21:27
whiteknight the tricky part may be figuring out how to add it to the build. I don't know what build mechanism the squaak tutorial was using 21:28
the Matlab/Octave project is defunct
jay < sigh >
whiteknight That language has some syntax and semantics that are...not pleasant
I may restart the project as a language subset, but I haven't finalized plans for that yet 21:29
jay From a computer science perspective, sure. For statisticians and data analysts, Matlab/Octave/R are quite appealing.
whiteknight I have a project Parrot-Linear-Algebra which provides bindings to BLAS for matrix types. I was going to use that as a big part of the runtime for my Matlab clone 21:30
I've been kicking around the idea of a Matlab subset language that would provide easy access to those matrix routines 21:31
jay If my work goes any further, this will be important and very interesting.
whiteknight github.com/Whiteknight/parrot-linear-algebra
jay is your old Matlab/Octave code still someplace? 21:32
whiteknight all the tests and examples for that are in NQP, if you want to borrow liberally
github.com/Whiteknight/matrixy
brb, need to cook dinner
jay whiteknight++
21:34 everbrew left 21:35 ambs left 21:46 telemachus joined, dmalcolm left, dmalcolm joined 21:47 Patterner left, Patterner joined 21:54 alester joined
dukeleto jay: seems like matrixy is very similar to what you are trying to accomplish 21:55
plobsing aren't R and matlab different languages? 21:56
jay Yes, but they share a similar syntax 21:57
Yes, matrixy seems in the ballpark. Ultimately, we'd like use work we've done elsewhere (C++ library for R) to use shared-memory and filebackings for massive matrices, perhaps with the BOOST interprocess library. So I'm just trying to get a stub of a language working, first. 21:59
R uses 4-byte integer indexing and has other design weaknesses that effectively prevent us from just forking R itself for this purpose. 22:00
whiteknight PLA uses integer indexing, but it would be system-defined integer size 22:02
of course, if you bumped up to a different storage format above a certain size, that won't be an issue
jay I'm guessing we would need to manage the data structure (fundamentally column-major arrays) in C++ and then provide methods in the Parrot HLL. Unless you want to discuss how I might hack your underlying memory allocation... at some point there has to be an mmap, right? 22:04
22:04 dmalcolm left
plobsing our allocator is a little simplilstic and weak 22:04
dukeleto jay: parrot has the concept of objects that get automatic memory management, and others where it is done manually
plobsing I'd like to see your use-case covered, but I don't think that will happen soon 22:05
dukeleto jay: ManagedStruct and UnmanagedStruct
jay Well, for our purpose we're interested in fixed-sized arrays (vectors) of floats. That's basically the fundamental object we statisticians need.
plobsing you only need an arbitrarily-lengthed array of floats? Ptr/StructView were made for that 22:06
dukeleto jay: we call that the FixedFloatArray PMC (FFA) in parrot world
whiteknight PLA manually allocates memory for matrices. Just wraps that up in the PMC lifecycle
jay BLAS-compatible objects, but allocated in a special way so with the filebackings we can exceed RAM. Again, BOOST is pretty cool in supporting this.
whiteknight Yes, I've heard good things about BOOST 22:07
plobsing dukeleto: FFA and friends won't work outside of Parrot because they use the FLOATVAL type. not very useful.
jay Yes, I was guessing that FFA was probably that.
whiteknight it was part of the motivation for my Rosella project
dukeleto plobsing: hmmm. i guess it is only useful if you want to use floats
whiteknight dukeleto: FLOATVAL != float 22:08
it could be float or double
jay I was about to ask about doubles. Should I be looking at Rosella? I'm overwhelmed at this point with the basics. Still learning to crawl, not even walking. I know where I'd like to fly, but don't understand the mechanics of flapping my wings. 22:10
dukeleto jay: Rosella already has many wheels you will want to build soon
jay: i would recommend using it for your test suite, as well as possibly using it for memoization, which is quite useful for deterministic math/stat functions 22:11
whiteknight jay: Rosella is to Parrot what BOOST is to C++. Adds a lot of building blocks. You probably don't need it yet, but I suspect you will want it for various purposes eventually
jay whiteknight++ that sort of overview is very helpful, thanks.
whiteknight it's not identical to BOOST, because some things BOOST provides are already built into Parrot. But, it's the same kind of concept 22:12
dukeleto whiteknight: very few people compile Parrot with FLOATVAL != float. Not one of our smokers does. How sure are you that it works correctly?
tadzik oh, dukeleto o/
whiteknight dukeleto: maybe not at all. I think there is a Configure.pl argument to redefine FLOATVAL
dukeleto tadzik: howdy
plobsing dukeleto: my FLOATVAL is double 22:13
dukeleto whiteknight: yes, but it sees extremely little use, so I worry that it is bitrot
tadzik dukeleto: how about some pandatalk, here or otherplace?
whiteknight only one way to find out
dukeleto plobsing: i think that is what I meant. the default for FLOATVAL is double
whiteknight tadzik: pandatalk?
dukeleto lulz
tadzik: i guess #perl6 is more appropriate
whiteknight: panda is perl6's plumage 22:14
tadzik whiteknight: it's a special kind of speech me and dukeleto are researching
dukeleto: ay, you ruined it!
whiteknight :)
dukeleto tadzik: well, I could have said we were presenting joint-research at a Furry convention, but then that would have been too odd.
whiteknight: modules.perl6.org/ <-- you get a panda badge if your perl 6 module has the newest metadata format that pandas like to chew on 22:16
we really need something like modules.perl6.org to show off Plumage data 22:18
bubaflub seen colomon 22:23
aloha colomon was last seen in #perl6 4 hours 20 mins ago saying "interesting....".
bubaflub msg colomon just noticed you have a Math::Prime perl6 module - i'd love to collaborate with you on that
aloha OK. I'll deliver the message.
22:24 bluescreen joined
dukeleto bubaflub: don't forget about Math::Primality ;) 22:24
ETOOMANYPROJECTS
whiteknight what's great about this new whiteknight/pbc_pbc branch is that I'm ripping out lots of unnecessary code without having to replace functionality yet 22:25
bubaflub dukeleto: how could i forget my first love... errrr... module
whiteknight so performance is only going to go up
cotto_work It's like Christmas!
bubaflub whiteknight: any chance it'll get merged before 3.6 hits?
dukeleto whiteknight++ # /me likes performance
cotto_work seen kid51
aloha kid51 was last seen in #parrot 19 hours 54 mins ago saying "So the only file which currently has FAILs in that branch is t/tools/hbdb/cmds.t (as expected). smolder.parrot.org/app/projects/rep...ls/17111".
whiteknight bubaflub: the whiteknight/packfilewrapper branch might, if kid51 gives the go-ahead
the new whiteknight/pbc_pbc branch will not. I'm still hacking and don't know where I'm going to end 22:26
before 3.7, certainly
bubaflub ok 22:30
22:30 bubaflub left
dalek TT #2137 closed by dukeleto++: t/src/embed.t fails when Parrot is configured with --without-libffi ... 22:41
TT #2137: trac.parrot.org/parrot/ticket/2137
22:42 darbelo left, kid51 joined 22:43 mtk left
kid51 cotto: ping 22:47
msg cotto Do you have opinions on either trac.parrot.org/parrot/ticket/1598 (Archive::Tar/Zip) or trac.parrot.org/parrot/ticket/1601 (parallelism PDD)? 22:50
aloha OK. I'll deliver the message.
kid51 msg cotto What are your feelings about merge soon of whiteknight/packfilewrapper branch?
aloha OK. I'll deliver the message.
22:51 estrabd left 22:52 whiteknight left
kid51 msg whiteknight re whiteknight/packfilewrapper branch: I'm going to run a smolder on it for linux/i386 and make fulltest; also smolder on darwin/ppc; after that point, if cotto greenlights, I'm okay with merge (all of this may take a couple of hours) 22:56
aloha OK. I'll deliver the message.
cotto_work kid51: back 22:58
22:59 bubaflub joined
jay pong 23:15
cotto_work jay: who are you ponging? 23:16
jay just seeing what it did
cotto_work ok. It's a convention we use to get someone's attention.
jay ah! thx. And ping? 23:17
unix-like?
dalek rrot/whiteknight/packfilewrapper: d98e956 | jkeenan++ | config/gen/makefiles/root.in:
Use Makefile variables already defined where possible.
rrot/whiteknight/packfilewrapper: 6784232 | jkeenan++ | src/pmc/packfileview.pmc:
Brand new file only needs copyright for current year.
cotto_work ping is to get someone's attention, pong is to indicate that the pingee is paying attention
kid51 jay: ping 23:18
jay pong
kid51 jay: I believe you have some kind of slide show you've been discussing with dukeleto. Correct? 23:19
About R, I think?
jay sorry, phone... brb 23:21
dalek rrot/whiteknight/packfilewrapper: 024e3ad | jkeenan++ | / (3 files):
Add copyright.
 23:23
kid51 msg whiteknight You have a codingstd failures in branch. I am trying to fix but will probably not catch all.
aloha OK. I'll deliver the message.
23:25 whiteknight joined 23:27 bubaflub left
whiteknight hello again, #parrot 23:29
damnit, I thought I caught all the codestd failures 23:30
kid51 I have some fixes I will push in a few minutes. 23:35
whiteknight thanks 23:36
I had some uncommitted changes from another branch I have to sort through first, then I'll hack on whiteknight/packfilewrapper 23:37
dalek rrot/whiteknight/packfilewrapper: 041cf3e | jkeenan++ | src/packfile/ (2 files):
[codingstd] Add coda for C code.
 23:38
rrot/whiteknight/packfilewrapper: d1f74b3 | jkeenan++ | src/pmc/packfileview.pmc:
[codingstd] Add ASSERT_ARGS.
rrot/whiteknight/packfilewrapper: 592d9ae | jkeenan++ | src/pmc/packfileview.pmc:
Revert previous codingstd, as it did not fix test.
rrot/whiteknight/packfilewrapper: 25d73ce | jkeenan++ | src/packfile/pf_private.h:
[codingstd] Add header guards. whiteknight, please check.
kid51 whiteknight: Can you add some (stub) documentation to src/pmc/packfileview.pmc for get_const_table()? There's also a c_args_assert failure there somewhere. 23:39
cotto_work kid51: ASSERT_ARGS() can't have a terminal ';'
kid51 cotto_work: But even if I delete the final semicolon, I still get the test failure. I don't know the fix there. 23:41
dalek rrot/whiteknight/pbc_pbc: c7572b6 | Whiteknight++ | src/packfile/api.c:
Use Parrot_pcc_invoke_sub_from_c_args instead of run_subs.:immediate

  :immediate subs are expected to return a value ->P. :load, :init, and :postcomp do not (->). We don't need to save/restore the runcore, because PCC does that
We don't need to set the current constants segment in most places, because Sub.invoke does that
whiteknight Let me look 23:42
23:43 fperrad left
whiteknight mumbles something about our codestd tests being pedantic 23:44
dalek rrot/whiteknight/packfilewrapper: 51929a0 | Whiteknight++ | src/pmc/packfileview.pmc:
fix c_arg_assert test failure
 23:46
rrot/whiteknight/packfilewrapper: c5b37d5 | jkeenan++ | src/packfile/segments.c:
[codingstd] POD formatting fixes.
 23:47
rrot/whiteknight/packfilewrapper: d7d3d34 | jkeenan++ | src/pmc/packfileview.pmc:
Merge branch 'whiteknight/packfilewrapper' of git@github.com:parrot/parrot into whiteknight/packfilewrapper
kid51 hears whiteknight's mumbling and correctly ignores him ;-) 23:48
jay ping kid51 23:51
kid51 jay pong
jay Back, sorry. Yes, to answer your question, I gave my slides to dukeleto and I think they went up on the devel list. Sort of the backstory to why I'm here stumbling around. 23:52
My HLL is NQR (for not quite R). It used to be Q, but you guys (Parrot) stole Q for internal use.
kid51 Is there a web site to which you could post those slides? And then write a post to parrot-dev containing that link? (The slides themselves exceed our default post size limits.) 23:53
jay Ah, sorry. Yes, I could do that. Just a sec. Take them with a grain of salt and a sense of humor, though.
kid51 jay: In fact, post a reply to the thread that's already started, once you have a link to a web site. 23:54
jay www.stat.yale.edu/~jay/NQR/ will post to the thread, too. 23:55
dalek rrot/whiteknight/packfilewrapper: 7f7d532 | jkeenan++ | src/pmc/packfileview.pmc:
[codingstd] No space between function and open parenthesis.
 23:56
kid51 Thank you very much.
whiteknight: We're down to failures here: t/codingstd/pmc_docs.t 23:57
whiteknight I'm almost done 23:58
kid51 k
whiteknight: The diff is very big. It would be nice if you could get a code review from cotto or equivalent. Once that's done, I would have no objection to a merge.
jay We (my recent grad student and I) are interested in statistical computing with massive (larger-than-RAM) data sets in scalable ways... we don't like the concept of different implementations of the same analytical procedure simply due to data size. We've used the BOOST interprocess library under our C++ packages for R, but couldn't just hack them into R's memory management (for a variety of reasons). 23:59
kid51 whiteknight Starting test on darwin/ppc now.
afk

Powered by Cro and the Raku® Programming Language.

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

Thank you!