Parrot 3.4.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 17 May 2011.
dalek rrot-gmp: 62416a1 | bubaflub++ | TODO.md:
Merge remote branch 'origin/master'
 00:03
rrot-gmp: b753e7a | bubaflub++ | gmph2ncidef.pl:
add a blacklist of functions

these functions are either too complicated to be auto-generated or require functionality outside the current scope of this project
rrot-gmp: 9351ba7 | bubaflub++ | gmph2ncidef.pl:
update mappings

this should cover the GMP.h file
rrot-gmp: 73ecbad | bubaflub++ | gmph2ncidef.pl:
more regex magic

some functions are prefixed with an underscore remove the __gmp_const macro from our processing
lucian whiteknight: i've set up hg to push to both bb and gh 00:09
good night
00:09 lucian left
whiteknight lucian++ 00:12
00:29 whiteknight left 00:42 whiteknight joined 00:47 theory left, whiteknight left 01:01 whiteknight joined 01:03 gbacon joined 01:04 kid51 joined 01:08 whiteknight left 01:11 whiteknight joined
whiteknight anybody mind a commit bomb? 01:12
dalek sella/gh-pages: 941ba33 | Whiteknight++ | libraries/filesystem.md:
expand docs for filesystem and add a few code examples
 01:14
sella/gh-pages: 82baead | Whiteknight++ | libraries/core.md:
mention the global registry in core.md
sella: 967f0ba | Whiteknight++ | / (5 files):
Add an ability to register library-globals. Use this to register an OS PMC instance for the FileSystem library, so we can replace that at runtime for testing purposes
sella: 3dcd4cf | Whiteknight++ | / (5 files):
Fix various FileSystem tests to all pass
sella: 76dbb71 | Whiteknight++ | / (4 files):
use mockobject to fill in some tests for Directory. We can use the global instance registry to override the OS PMC instance with a mock
sella: 39cb600 | Whiteknight++ | / (2 files):
Add tests for File, using mockobject magic
sella: ee2051a | Whiteknight++ | t/filesystem/ (2 files):
Add stub test methods to Visitor.t
sella: a84ee76 | Whiteknight++ | src/unstable/filesystem/Visitor.winxed:
Cleanup Visitor and add more docs
sella: 577180f | Whiteknight++ | / (4 files):
Add stub test files for subclasses of Visitor
sella: ad71a15 | Whiteknight++ | t/ (4 files):
Add some tests for mocking method calls with named arguments
sella: 2cbfc28 | Whiteknight++ | / (2 files):
update Container.default_container to use the new global registry
sella: cfd6b94 | Whiteknight++ | src/core/Globals.winxed:
+some docs about globals
sella: 54404eb | Whiteknight++ | t/filesystem/ (4 files):
Mark FileSystem.Visitor tests as unimplemented
sella: 2b49deb | Whiteknight++ | src/mockobject/ (3 files):
Update docs for MockObject
cotto oh my
saying whiteknight++ would be redundant, so I won't 01:15
whiteknight cotto: thanks for the restraint
cotto whiteknight, np 01:17
I can avoid saying whiteknight++ with the best of them.
soh_cah_toa if i have a function in src/foo.c that i wanna call from src/runcore/cores.c, how do i do that? don't i need to change the rule for src/runcore/cores.o in the Makefile? 01:19
b/c i'm looking at it now and it doesn't have src/debug.c as a dependency yet runops_debugger_core() does use function defined in src/debug.c 01:20
cotto soh_cah_toa, the makefile rules only say what needs to be build in what order
runops_debugger_core is called as a function pointer of the runcore struct, not directly
soh_cah_toa well, i meant that runops_debugger_core() uses functions defined in src/debug.c but i don't see a recipe in the Makefile like gcc -o cores.o cores.c debug.c 01:22
which is what i thought is what's needed
cotto it all gets linked into libparrot
soh_cah_toa so if i have something i wanna call from src/runcore/cores.c that's in src/hbdb.c, what do i do? i don't know where to add src/hbdb.c in the Makefile 01:23
cotto let me look at your branch 01:24
soh_cah_toa sure
cotto I think the solution is to make sure that src/hbdb.o gets linked into libparrot. let me verify 01:25
soh_cah_toa, what's the function?
I don't see a src/hbdb.c 01:26
soh_cah_toa test() in src/hbdb.c. i'm just trying to get the behavior down first before i bug you about what really needs to be in that funciton. try looking again b/c i just pushed a few seconds ago
cotto is it checked in? 01:27
ah
that does it. add src/hbdb$(O) to INTERP_O_FILES in config/gen/makefiles/root.in 01:29
soh_cah_toa ok. do i need a rules for it too or will it use an implicit one? 01:30
cotto the implicit rule will be fine unless you're doing something funky
so far you're not
soh_cah_toa alright
wow, i'm getting a really strange error: 01:37
/usr/lib/gcc/i686-redhat-linux/4.4.5/../../../crt1.o: In function `_start': 01:38
(.text+0x18): undefined reference to `main'
whiteknight ...lolwat? 01:41
cotto "test" is probably a bad function name to use.
whiteknight actually, I'll have to backscroll. it's time for bed now 01:42
goodnight
cotto try something more uniquer
01:42 whiteknight left
cotto whiteknight, 'night 01:42
soh_cah_toa i changed it to hbdb_test() for that reason
cotto nice error 01:45
how did you get that?
soh_cah_toa 'make hbdb'
cotto I can get it too. What a great party. 01:46
soh_cah_toa wonderful
does it matter that i added src/hbdb.c after the #IF(i386_has_gcc_cmpxchg)? i don't know if that's just a commented out "if" or some make directive i've never heard of but anything after it looks like it's commented. i just added src/hbdb.c to the line above src/debug.c figuring if src/debug.c was there, then it was an ok place to add it. am i wrong maybe? 01:47
cotto src/hbdb$(0) \\
soh_cah_toa yeah, that's what i meant
cotto look closely at that 01:48
soh_cah_toa i know, multiline
cotto nope
0 != O
soh_cah_toa agh
wtf? why'd i do that?
cotto soh_cah_toa, easy. to get an awesome error message
soh_cah_toa we have compilation. wow, that's such a minor difference 0/O i'm surprised you caught that 01:50
cotto soh_cah_toa, that's fine. The #IF() only has an effect on that line in root.in
soh_cah_toa oh, is that a thing for the configure script like @ld_out@ is?
cotto soh_cah_toa, it helps to have a good font. If you don't have one that makes 0 different from O, I recommend finding one.
inconsolata is my personal favorite 01:51
soh_cah_toa i don't think i change change the font in vim though
*can change
cotto soh_cah_toa, if it's gvim you can. If it's on the cli, you can change the font that your terminal emulator uses.
soh_cah_toa i'd like to use gvim but for some reason the key mappings i have only work in the cli version 01:52
it's weird, i gotta research it 01:53
anyway, what's the INTERP_O_FILES for? why did that fix it?
cotto That's one of a list of object files that get built into libparrot
there are other *_O_FILES variables for different subsystems 01:54
soh_cah_toa does that mean i can call any function in src/* files from any other src/* file so long as they're included in the INTERP_O_FILES variable? 01:55
cotto any non-static function, yes
soh_cah_toa right
cotto it's a good idea to add headerizer directives and a header file when you add a new file. You can find the right magic by looking at existing C files and headers. 01:56
soh_cah_toa oh right, that's what i wanted to ask about...headerizer 01:57
01:57 davidfetter joined
cotto what about it? 01:57
soh_cah_toa well, if i run 'make headerizer' it will scan all c files? 01:58
or do i have to specify which file to "headerize"?
pretty much what i want to know is...if i run headerizer, where will the declarations for the functions defined in src/hbdb.c go? 01:59
non-static ones, that is
cotto you can specify which one to scan by passing the .o file to headerizer (yes, it's odd) or you can run make headerizer and it'll rebuild everything.
you have to add some headerizer comments to hbdb.c and to a new hbdb.h file in include/parrot
src/pmc.c is a good example 02:00
look for something like /* HEADERIZER HFILE: include/parrot/pmc.h */
soh_cah_toa oh ok. i thought those were auto-generated by headerizer
cotto nope. Those are added by hand so that headerizer knows where to put its generated declarations 02:01
soh_cah_toa oh and another thing, not terribly important but i've always wondered...in the declarations generated by headerizer i see things like __attribute__nonnull__(1). however, i thought attributes where of the form: __attribute__((nonnull (1))). are these not gnu function attributes then? 02:05
cotto those get macroized into something platform-appropriate 02:06
soh_cah_toa so they're not the gnu attributes i'm thinking of? 02:07
cotto include/parrot/compiler.h makes them dtrt 02:09
soh_cah_toa ok 02:10
btw, remember the other i asked you if there was an easier way besides 'git grep' to find function definitions/declarations? well, have you ever used ctags? 02:13
*the other day
cotto soh_cah_toa, I played with it a bit 02:14
soh_cah_toa it's incredible. life changing. especially w/ the taglist.vim plugin
though you're a parrot master so you probably already know the location of...everything :) 02:15
cotto I can guess well.
02:18 kid51 left
cotto btw, you can do make tags-vi 02:19
02:19 theory joined
soh_cah_toa you mean the ex commands? like :ta? 02:21
cotto I don't know. It sounded like it might be relevant. 02:22
bubaflub incoming
dalek rrot-gmp: 6648faa | bubaflub++ | gmph2ncidef.pl:
formatting fixes
rrot-gmp: ea7f82b | bubaflub++ | gmph2ncidef.pl:
wrap that bad boy in a function
rrot-gmp: dd02c80 | bubaflub++ | src/GMP/template.nci:
blank template for NCI output
rrot-gmp: 7404bc1 | bubaflub++ | gmph2ncidef.pl:
these really should be 'i' types
rrot-gmp: 1ca2124 | bubaflub++ | gmph2ncidef.pl:
use a hash ref instead of a hash
rrot-gmp: defed52 | bubaflub++ | gmph2ncidef.pl:
print function

this function will print out the functions in a format appropriate for ncidef2.pl
this should be appended (>>) into the template file
rrot-gmp: 1ff96c3 | bubaflub++ | src/GMP/raw.nci:
NCI signatures for GMPz functions

this is the ncidef2pir input file generated from gmph2ncidef.pl
rrot-gmp: 0581b30 | bubaflub++ | src/def.pir:
usable PIR NCI file

this is the first output for the GMPz functions from the ncidef2pir.pl script
soh_cah_toa oh great! i just realized that now if i see a function i wanna use in a .c file, all i need to do to find out which header file to #include is look at the "HEADERIZER HFILE" comment. nice. though a one-to-one correlation would be nice. i ain't complaining though. this makes me happy now 02:30
cotto I'm happy when you're happy.
02:32 Kulag left
soh_cah_toa alright, now that i understand runops_*_core a little better, i see that i can call a function from there that checks if there a breakpoint that should be acknowledged. i can put that code in src/hbdb.c and call it from runops_hbdb_core(). that means i'm getting closer. 02:37
but i'm still a little stumped. i know that process must go: prompt, store line #, execute code, if entered line # == current line #, stop, back to prompt. one of the things i don't know is how do i check the line number?
02:39 Kulag joined
cotto that's tricky because imcc often produces inaccurate line numbers 02:45
02:45 Kulag left
cotto I suspect that src/runcore/profiling.c solves a few of the problems you'll run into. 02:46
02:46 Drossel joined
soh_cah_toa long ago, whiteknight recommended that i use packfile line annotations. is that not the best way then? are annotations encoded into the opcode? i mean, i only dealing w/ the opcode that pc points to so is there something like pc->line? 02:48
cotto packfile annotations are used with hll code. If you want to debug pir, you'll need to get your information the same way the profiling runcore does. 02:50
hbdb should eventually support both
soh_cah_toa i do want hll support though
yeah
02:52 Drossel left
soh_cah_toa agh, i need to use Parrot_Context. i still haven't gotten my head rapped around those yet... :\\ 02:58
benabik 'good even
cotto dukeleto, ping 02:59
hio benabik
benabik cotto: Been away for the weekend. Did I miss anything interesting/ 03:00
cotto benabik, me too
benabik cotto: Oh, well then at least we can be confused together.
cotto benabik, I'm always good at that. 03:01
or at least when I'm not I can't figure out why, so it sorts itself out
03:02 Kulag joined
dalek website: bubaflub++ | Parrot-GMP: Step #1 complete 03:03
website: www.parrot.org/content/parrot-gmp-s...1-complete
03:07 Kulag left 03:14 Kulag joined
soh_cah_toa could somebody try and clarify what a "context" is? i'm looking at the perldoc for get_line_num_from_cache() in src/runcore/profiling.c and it says that it returns the "line number for the current context." 03:15
from what i've been reading about continuations and coroutines, i'm guessing that a "context" refers to the current coninuation? the current state of the program? am i close?
cotto That refers to the CallContext PMC. 03:20
interp->ctx
soh_cah_toa right, but then still...what's a context? 03:21
cotto it keeps track of interesting bits of state from a sub call 03:24
soh_cah_toa ok, that's kinda what i though. but isn't that what a continuation is? i was wondering if maybe a "context" was a special kind of continuation 03:26
cotto a Continuation PMC has a pointer to a CallSignature 03:28
dalek rrot-gmp: c60d017 | bubaflub++ | TODO.md:
another one bites the dust
 03:29
rrot-gmp: fa8a1ff | bubaflub++ | src/GMP.winxed:
first shot at a Winxed class - mostly empty for now
03:30 bubaflub left
soh_cah_toa i'll just worry about it later. but if a context contains state information about a function, how can the profiling core use it to get the line #? to me, those two things are completely unrelated. how is a line # associated w/ a subroutine's state? 03:31
cotto you can get the line number from the pc 03:32
soh_cah_toa yeah, i think i just found it: Parrot_sub_get_line_from_pc() 03:33
cotto that's the one 03:34
soh_cah_toa i'll work w/ it for know but that's the pir line #, i don't know how i'll be able to use that for hll line #'s
*now
cotto no. for that you'll have to dig into annotations and hope that the hll provides them 03:37
soh_cah_toa well, at what point in my work do i start concerning myself w/ hll support? 03:39
cotto dukeleto, ping
soh_cah_toa, I'd worry about getting PIR support first.
it's more fundamental and probably easier to test
soh_cah_toa right, i just wanna make sure that i don't end up throwing away a bunch of stuff in the future 03:40
cotto soh_cah_toa, even if you do, you'll have learned a lot just from writing it. 03:41
(and I don't think you will)
soh_cah_toa i suppose you're right
cotto I love the idea of writing the first implementation of something with the intent of throwing it away. 03:42
soh_cah_toa right, b/c i'm the one writing it ;) 03:43
cotto you know how to do it correctly the second time, or at least you have a better idea
soh_cah_toa true
cotto github's getting close to 1000000 gists. 03:44
I wonder who the lucky nerd will be.
soh_cah_toa btw, at what point should i begin writing some tests? once i'm actually able to set breakpoints? that's the first piece of functionality i'll have so that seems like the first place to start. am i right? 03:54
cotto soh_cah_toa, yesterday 03:55
I really like writing tests before I write functionality.
soh_cah_toa oh yeah
cotto If you can't time-travel, today is good too.
03:57 gbacon left 04:07 davidfetter left
cotto incoming? 04:23
dalek rrot/m0-spec: ee1d81a | cotto++ | docs/pdds/draft/pdd32_m0.pod:
"contexts" are now known as "call frames"
rrot/m0-spec: 0883e9d | cotto++ | docs/pdds/draft/pdd32_m0.pod:
promote alloc/free to permanent ops, add gc_alloc, add note about ffi
rrot/m0-spec: 30476c1 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
the variables table is now the constants table, plus lots of related changes
rrot/m0-spec: ccdaec4 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add a section on register spilling
rrot/m0-spec: ce6e783 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
minor consistency changes
rrot/m0-spec: 2579f57 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add set_imm and deref, various cleanups
soh_cah_toa call frames is much nicer. makes me think of stack frames which is what i've been relating contexts to 04:25
cotto except there's no stack 04:28
I'm glad it's easier to understand. That was the goal.
dukeleto cotto: pong 04:36
dalek rrot/m0-spec: af0180b | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add numbers to the new op set
 04:38
rrot/m0-spec: 5f21f46 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
The disclaimer that this section is no longer current is no longer current.
04:39 benabik left 04:40 Kulag left
cotto dukeleto, I think that I can get M0 to do everything we want by changing a couple ops. Can you take a look at gist.github.com/999825 and tell me if it looks workable? 04:40
I'd like to run the idea by someone before I start updating all our example M0 code. 04:42
04:47 soh_cah_toa left 04:48 kuku joined, kuku is now known as birdwindupbird
dalek rrot: 00bdcb5 | petdance++ | src/hash.c:
const a pointer
 04:52
dukeleto cotto: what is SPILLCF? 04:54
04:54 baest joined
dukeleto cotto: why are these new ops needed? 04:55
cotto dukeleto, SPILLCF is the overflow call frame for register spilling
dukeleto, the new ops are needed because they do necessary things that the previous ops couldn't
namely the examples in the gist 04:56
dukeleto cotto: i am reading the recent changes to the m0 spec and understanding more 05:00
cotto: i see you you removed EX 05:02
cotto dukeleto, yup. That came up at yapc::or
05:03 hudnix left
dukeleto cotto: where does that data live? inside the call frame? 05:04
cotto which data? 05:05
dukeleto, SPILLCF is a pointer to the overflow call frame. Is that what you meant?
dukeleto cotto: what used to be in EX
cotto: also, i am on board. the new ops seem necessary 05:06
cotto dukeleto, it was the currently active exception. 05:07
it'll get passed around as an argument and doesn't need a dedicated register
dukeleto cotto: wfm 05:11
dalek rrot/m0-spec: 819c3bc | cotto++ | docs/pdds/draft/pdd32_m0.pod:
rename CONST to CONSTS
 05:28
05:30 theory left
dalek rrot/m0-prototype: bffc1ff | cotto++ | / (8 files):
move the m0 interp and assembler to a language-specific dir under src/m0
 05:41
rrot/m0-prototype: fa293b4 | cotto++ | .gitignore:
update .gitignore with .m0b files
rrot/m0-prototype: c118e24 | cotto++ | src/m0/perl5/m0_assembler.pl:
update the M0 assembler with recent changes to the spec
rrot/m0-prototype: e1c3035 | cotto++ | src/m0/perl5/m0_assembler.pl:
update variable names in assembler to refer to the constants table
rrot/m0-prototype: 579e3b2 | cotto++ | src/m0/perl5/m0_interp.pl:
update m0 interp code to be less inconsistent with recent spec changes
rrot/m0-prototype: dbf8970 | cotto++ | src/m0/perl5/m0_assembler.pl:
update name of CONST register to CONSTS
rrot/m0-prototype: ca60461 | cotto++ | src/m0/perl5/m0_interp.pl:
add stub implementations of new ops, various minor fixes
rrot/m0-prototype: 0eea614 | cotto++ | src/m0/perl5/m0_interp.pl:
implement all the ops I trust myself to implement
dukeleto leto.net/perl/2011/05/what-is-m0.html 05:44
05:46 woosley joined
cotto Part of me wishes set_var didn't get removed, since every .m0 file we have uses it. 05:47
dukeleto, "There will be a Parrot hackathon at YAPC::NA 2 this year," 05:48
dukeleto, what's the 2?
dalek rrot/m0-prototype: 8b5dfb4 | cotto++ | t/m0/ (12 files):
update all test files to use ".constants" instead of ".variables"

many are still broken because they use set_op, which went away
cotto dukeleto, you're welcome to fill out the m0 spec on exceptions and exception handlers. 05:49
I didn't meet my goal of banging out M0 fib, but it's still been a good day. 05:50
dukeleto, we also need a return PC register if you have the tuits. I'm off to bed rsn. 05:53
time for sleep 06:00
'night
tadzik good night cotto 06:02
and good morning #parrot
dukeleto: excellent blag toast
dukeleto tadzik: thanks! 06:12
tadzik insightful 06:14
I'm looking forward to spying the code of the C tools
dalek p: 5658834 | pmichaud++ | tools/ (3 files):
First version of tools/build/gen_parrot.pl and NQP::Config library.
 06:23
p: c5c081b | pmichaud++ | .gitignore:
Update .gitignore for new install location, config.status.
p: f412826 | pmichaud++ | / (2 files):
Move Makefile.in to tools/build.
p: 290d603 | pmichaud++ | / (7 files):
Refactor build/gen_how_pm.pl and build/gen_setting.pl into tools/build/gen-cat.pl. Update to shiny new Configure.pl.
p: ac7720e | pmichaud++ | build/ (6 files):
Remove outdated build tools and directory.
p: 7e4531a | pmichaud++ | Configure.pl:
Restore checks for files needed to build NQP.
p: 6e0ebf3 | pmichaud++ | STATUS:
Remove way outdated STATUS file.
p: ba0fe9d | pmichaud++ | docs/6model/ (2 files):
Merge branch 'master' of github.com:perl6/nqp
06:24 he_ joined 06:36 fperrad joined 06:38 plobsing left, SHODAN joined 07:16 mj41 joined 07:42 lucian joined 07:44 lucian_ joined
lucian_ 'morning 07:47
07:49 lucian left
moritz good morning lucian_. How is GSoC going? 07:50
lucian_ moritz: alright, i guess 07:51
07:54 elmex joined
lucian_ moritz: i have a compiler that can add numbers and an incomplete object system 07:55
moritz lucian_: that's a start... is that written in python and emitting PIR? 07:56
lucian_ and i'm starting to hate the things people have been hating around here for a while (PIR, imcc, Object/Class)
moritz: yes, the compile is PIR. object system is winxed
moritz cool
lucian_ you can have a look at it on either bitbucket or github, lucian1900/puffin
08:01 lucian__ joined 08:03 wagle left 08:05 wagle joined, lucian_ left 08:16 lucian_ joined 08:19 lucian joined 08:20 lucian__ left 08:23 lucian_ left 08:29 ligne left 08:35 lucian left
dalek p: af48f8f | pmichaud++ | src/HLL/Compiler.pm:
Switch local %config hash to be a package-scoped %parrot_config shared by all HLL::Compilers.
 08:38
p: 8dd1944 | pmichaud++ | src/HLL/Compiler.pm:
Add per-compiler configuration hash, --show-config option.
p: 3599a33 | pmichaud++ | / (4 files):
Tools to add version configuration information (based on git-describe)
p: bc9df6c | pmichaud++ | src/HLL/Compiler.pm:
Move HLL::Compiler version string out of BUILD and into version() method. Eliminate $!version attribute.
08:42 lucian joined
lucian i'm trying to figure out if winxed has a for-each statement 08:44
ah, for(var i in iterable) works, as in js 08:47
dalek p: ed47aba | pmichaud++ | Configure.pl:
Fix output when Configure.pl invoked with no options and parrot_config
 08:51
08:54 lucian_ joined 08:59 lucian left 09:25 lucian_ is now known as lucian
lucian allison: ping 09:25
allison lucian: pong 09:27
lucian allison: if you have time, i'd like a second opinion on puffin's object system 09:28
allison lucian: I was just checking in quickly before falling asleep, drop me an email with the details and I'll look at it in the morning?
lucian: (have to be up for meetings again in 4 hours) 09:29
lucian allison: ah, sure. sleep well
allison lucian: have a good day :)
09:31 cotto left 09:37 cotto joined 09:42 woosley left 10:01 birdwindupbird left 10:06 lucian_ joined 10:08 Kulag joined 10:10 lucian left 10:13 Kulag left, contingencyplan left 10:32 lucian_ is now known as lucian
lucian <3 hg-git 10:32
10:34 Kulag joined 10:37 lucian_ joined 10:41 lucian left 10:42 lucian_ is now known as lucian
lucian how should i reference/include other files in winxed? 10:42
10:54 lucian_ joined 10:57 lucian__ joined 10:58 ambs joined 10:59 lucian left 11:02 lucian_ left 11:03 lucian_ joined 11:06 lucian__ left 11:07 cotto left 11:11 ligne joined, cotto joined 11:49 Kulag left 12:05 whiteknight joined
whiteknight good morning, #parrot 12:16
12:18 lucian_ is now known as lucian
lucian whiteknight: 'morning 12:18
whiteknight good morning, lucian. how's the hacking going? 12:22
lucian whiteknight: pretty well, i've pretty much boostrapped python's object msyste
it's a slight approximation so far, since it has no metaclasses 12:23
but otherwise, it's just correct, just incomplete
whiteknight wow. That still seems to be going rather quickly
lucian shrugs
python's object system is exceedingly simple
whiteknight "the great and mighty lucian always works this fast!"
lucian it is true that i had 2-3 days to just work on this 12:24
whiteknight still, it's not trivial to get such a fundamental piece working well enough to support the rest of your project
lucian i'll lay off later today to study for my last exam (tomorrow)
it's a little mindbending, but once you get over it it's obvious
also, i'm mostly ignoring parrot's object system
whiteknight I recommend you do two things: 1) think hard about a friendly interface, so later when 6model or another shiney object model infrastructure rolls around, you can reimplement without untangling a lot of garbage 12:25
and 2) Test the crap out of it
lucian for 1), python's interface to it is pretty clear, which is why this is so easy in the first place
for 2), i need tuples for proper function calls first, then tests
whiteknight because when you do go to optimize or reimplement, you're sure as hell going to want to have a lot of tests around to make sure that works 12:26
lucian yes
although it pains me a little to have to do the tests in winxed
whiteknight Okay, but I would be hesitant to go too long without testability.
lucian i'd prefer to do then from python
well, i have some tests for the basics
whiteknight right, but if you don't get to that point for a few weeks, you end up in very shakey territory
lucian just a handful
whiteknight ok
any tests are better than none
lucian i guess i'll give rosella's test a try 12:27
testing the object system separately from the compiler is a good idea, i just slightly dread it
whiteknight yeah, I know what you mean
lucian btw, i've put it in github as well
12:27 mtk joined
whiteknight yes, I saw that last night. Thanks 12:28
Like I said, I wouldn't be against an exception, but not having to make the exception is always the easiest
lucian with hg-git it's really easy, when i do 'hg push' it pushes to both bitbucket and github 12:29
whiteknight that is convenient
lucian if you're curious, my functional test is objects.winxed:main 12:31
12:35 hudnix joined 12:38 lucian_ joined 12:39 lucian_ left 12:40 lucian_ joined
lucian_ whiteknight: how can i get the length of an array in winxed? 12:41
whiteknight elements(array) 12:42
12:42 lucian left
whiteknight or, if you like inline pir, ${ elements cnt, array } 12:42
lucian_ i'd used inline pir, but i prefer expressions
whiteknight everybody prefers expressions 12:43
NotFound had to add in inline PIR for a variety of reasons, but he purposefully made it a little bit less friendly to disuade people from using it too much
There is a pretty big list of built-in functions which are basically just wrappers around PIR ops
if you search around the winxedst1.winxed file for "Predef" you'll stumble on them eventually 12:44
lucian_ whiteknight: ah, i asee. thanks
12:44 bubaflub joined
jnthn__ lucian_: I checked in some more 6model docs last night, but I'm going to add a couple more tonight/tomorrow that actually are walk throughs of doing a class based object system and a prototype object system. 12:50
whiteknight: ^^ also :)
lucian_ jnthn__: thanks, i'll have a look
whiteknight jnthn__++
jnthn__: where at, perl6/nqp/?
jnthn__ perl6/nqp/docs/6model/
overview, and then a tiny FAQ. Feel free to commit/suggest more Qs. :)
whiteknight awesome 12:51
jnthn__ Overview has an initial tiny example.
I'll do two "fuller" ones.
Gradually I want to build up something maybe cookbook style
Recepies for certain language features. 12:52
er, certain OO language features...though that said, a similar thing for the compiler toolkit stuff in general could be good also :)
lucian_ jnthn__: cool, 6model is much less confusing now 12:59
i have a question: is it straightforward to expose the implementation to the language? 13:00
in python, you can access obj.__class__, obj.__bases__ and even obj.__dict__ (which is the hash backing all attributes)
and all of this at app-level
13:01 JimmyZ joined
jnthn__ Yes. NQP does that sort of stuff in its meta-objects too. 13:01
13:02 JimmyZ_ joined
lucian_ nice 13:02
jnthn__ Circularity issues can get evil, that's all.
whiteknight wants 6model in parrot really really really really badly
jnthn__ :)
lucian_ jnthn__: i think it's not that evil, you can special-case your attribute getters/setters 13:03
whiteknight The ability to specify the representation in a parrot language, and have those details exposed at runtime without extra bullshit is so amazingly important
lucian_ nods
jnthn__: so one would write the meta-object in nqp, primarily
jnthn__ lucian_: Yes, true.
lucian_ ok
jnthn__ lucian_: It's not too bad, it can just get a bit loopy in places. 13:04
lucian_ jnthn__: i've never used it, so i guess i'll see
jnthn__ lucian_: Well, Perl 6 is probably nastier than most languages on these kinds of issues.
lucian_ really? how so? 13:05
jnthn__ Things like, inheritance relies on multi-dispatch (for traits) which in turn relies on inheritance...
atrodo Turtles all the way down 13:06
jnthn__ There's quite a few little circularities like that.
lucian_ jnthn__: i'm not sure perl6 is special in that regard
jnthn__ lucian_: Maybe not. :)
PerlJam atrodo: but are any of them snapping turtles?
jnthn__ It's just the one I've got my head full of at the moment :)
lucian_ yeah, sure
atrodo PerlJam> Probably 13:07
PerlJam reads jnthn's docs
13:07 JimmyZ left, JimmyZ_ is now known as JimmyZ
lucian_ for example, in python obj.__class__ is an attribute on an object, which is resolved with obj.__getattribute__, which is found with obj.__dict__['__getattribute__'] 13:07
whiteknight fun fun, silly-willy 13:08
lucian_ jnthn__: yeah, 6model is very similar to what i've been doing
whiteknight so obj.__dict__['__getattribute__']['__class__']
?
lucian_ whiteknight: technically, yes
whiteknight that looks less than efficient 13:09
hence the need for very good JIT
jnthn__ JIT will only help so much here
lucian_ whiteknight: and a call is obj.__dict__['__getattribute__']('func_name').__dict__['__getattribute__']('__call__')() 13:10
but it's not so bad in reality, it gets short-cirtuited earlier
and __class__, __call__ etc are special-cased
jnthn__ (short-circuited) yeah, there's some mechanisms in 6model for that (the method cache, for example)
lucian_ is there an attribute location cache? 13:11
jnthn__ Not any kind of generic one - it's too REPR-specific.
lucian_ right
so instead of nqp objects, i use winxed (parrot) objects
python types are parrot class instances 13:12
very similar to 6model indeed
apparently the terminology had confused me a lot earlier
jnthn__ Yeah, apart from 6model hasn't really got a class equivalent.
meta-objects are just objects
lucian_ nods
oh well, it appears i've already re-invented a wheel 13:13
whiteknight I would love to do some 6model-related stuff in Winxed, maybe with Rosella. Some of the sublibraries I think would be particularly well suited to its benefits 13:14
lucian_ whiteknight: just write a better object model for winxed :)
whiteknight my proxy library for instance is an evil kludge, but with a custom REPR it could be quite nice
13:15 mikehh left 13:20 bluescreen joined
lucian_ is building nqp 13:20
13:20 lucian_ is now known as lucian
lucian oh, nqp's building a regex engine? 13:24
whiteknight nqp has something of a regex engine already
that's the big grammar portion of it
moritz it's good enough to parse itself :-)
tadzik real languages parse themselves!
moritz and the actual engine is pretty much language agnostic 13:25
lucian hmm. i guess i, too, really want to 6model into parrot
moritz you can compile python regexes to PAST::Regex nodes (or whatever they are called)
lucian since i'm not using PCT, this is slow for no good reason
moritz: why?
i don't see the connection between regexes and parsing
moritz lucian: why not? :-)
whiteknight does python use pcre?
moritz ah
lucian whiteknight: no
moritz lucian: nqp parses itself with Perl 6 regexes + grammars 13:26
lucian moritz: so it lexes with regexes, then parses with grammar?
moritz lucian: grammars are really just classes where the methods are regexes
lucian: so the distinction between lexing and parsing blurs
lucian: github.com/perl6/nqp/blob/master/s...Grammar.pm 13:27
lucian that looks scary
moritz only the stuff at the top
lucian hmm, odd 13:28
those regexes don't appear to be regular, but i may be mistaken
moritz note that part of the parsinig is delegated to an operate precedence parser, which is set up around lines 606..714
jnthn__ They're not regular. :) 13:29
regex is maybe a bad name for them :)
moritz lucian: that's why we call them "regex", or not "regular expression" or "Chomsky-0" or so :-)
s/or/ant/
*and
argl
jnthn__ :P
lucian :)
regex is a bad name, yes :) 13:30
jnthn__ lucian: I've found it really pleasant to work with Perl 6 grammars, fwiw.
There was a learning curve of course. :)
moritz it takes some time getting used to, like all powerfull tools
PerlJam no, regex is a good name. It give homage to their developmental history
lucian jnthn__: perhaps my disgust with perl5 is colouring my view of perl6's syntax
jnthn__ lucian: How far Perl 6 makes things better for you probably depends on what it was about Perl 5 that disgusted you. :-) 13:31
lucian jnthn__: if i read about perl6, it sounds very nice. i find the syntax bonkers, but that's subjective 13:32
jnthn__: what i hate most about perl5 is the ridiculous inconsistency. also the whale guts
PerlJam jnthn__: is there some reason that nqp's Configure.pl doesn't look for parrot_config is /usr/local/bin or /usr/bin/ ? 13:33
jnthn__ PerlJam: That's true in a sense. I suspect it's the same battle I fight with TDD. People think it's all about testing, when it's actually about much more than that.
PerlJam: pmichaud just re-did nqp's Configure, so he's probably the person to ask that. :)
ask *about* that
PerlJam ah.
jnthn__: re TDD, well the word "test" is first, so it must be the most important concept, right? ;) 13:35
jnthn__: seriously though, I bet if you reformulated the phrasing of the name, people might understand that TDD isn't just about testing.
I don't know what you'd call it though
lucian invent the word spectest 13:36
13:36 mikehh joined
moritz "stepwise code iteration backed up by testing" 13:36
but that's not as fancy
PerlJam moritz: now just make it concise
moritz and scibubt is hard to pronounce :-)
jnthn__ Well, some folks figured calling it BDD may help. :-) 13:37
And yes, TDD is very explainable if you go through the name carefully with folks. It just doesn't always lead to people making the right first guess about what it's really about. 13:38
And I like it when names make things obvious. :) 13:39
PerlJam jnthn__: like "regex" :)
13:40 JimmyZ left
lucian is there a vim plugin for nqp? 13:41
PerlJam lucian: just use the perl6 one
lucian or should i just try to use perl5 syntax
ah
PerlJam lucian: btw, what do you find "ridiculously inconsistent" in Perl 5? 13:42
moritz has lots of examples
PerlJam: just think of all the things that Perl 6 fixed :-)
PerlJam moritz: I'm fishing for things Perl 6 may have missed. 13:43
lucian PerlJam: things like arrays
PerlJam: the way the nest is silly
PerlJam: and the syntax in general, i varies wildly for no good reason 13:44
moritz hates the dereferncing syntax
@{$a->{foo}}
tadzik push, grep? I may have gotten better in 5.14
lucian i don't really know perl5 well enough to bash it effectively, but while i respect if for having a vision (unlike php), i think it's just nuts 13:45
moritz last I tried (with 5.14) it didn't throw a syntax error when I omitted the @{ ... }, but didn't autovivify either
13:47 rohit_nsit08 joined
Infinoid moritz: I do wish @$$a{foo} worked 13:49
Somehow it stuck in my brain in such a way that $$a{foo} seems much more consistent than $a->{foo}, though 13:50
moritz why three sigils?
@$a{foo} would kinda make sense to me
but @$$a{foo} not
13:51 SHODAN left
Infinoid if %h is a hash, and $s{foo} accesses the field, and $s is a reference to the hash, then $$s{foo} and $h{foo} are interchangeable 13:52
So the second one is to dereference the hash ref
The third is to dereference the list ref
oops
meant to say "$h{foo} accesses the field"
moritz no wonder non-perl people call us crazy :-)
whiteknight Infinoid: howdy! 13:53
Infinoid It's consistent, it's just picky about what to be consistent with. :P
whiteknight: hai
moritz finds p6's $h<foo>.list to be much saner
Infinoid It does look a lot cleaner 13:55
lucian so that syntax is for a list in a hash?
moritz for a list in a hash in a scalar
if you have a hash %h, it's %h<foo>.list 13:56
lucian very odd 13:57
jnthn__ odd? :)
lucian to me, at least 13:58
jnthn__ The Perl 6 one, or the Perl 5 one? :)
lucian but i find sigils in general a ba didea
jnthn__ finds the Perl 5 one odd :)
moritz only odd if you expect lists to never flatten
cotto ~~
lucian i find both odd, to be honest. perl6 one less so
jnthn__ sigils are just noun markers. :) 13:59
jnthn__ was amused to discover that C# "supports" the @ sigil recently :)
You can use it to disambiguate a keyword from a variable of the same name... :) 14:00
moritz remembers the discussion
lucian jnthn__: yes, very bad :)
doesn't matter, we won't convince each other of anything
jnthn__ :)
lucian i'd say that for disambiguation quoting is much better
whiteknight I think it's better still not to be trying to use reserved words as variable names 14:03
in the C# case, anyway
lucian heh, i finally have ints 14:04
i guess now i can retarget the compiler to use the object model
14:09 PacoLinux joined
cotto PHP "supports" @ too. 14:10
It's called the shut up operator and suppresses error messages from a function call. 14:11
such a lovely language
jnthn__ :@
cotto jnthn++
14:17 hercynium joined
whiteknight it suppresses error messages from built-in functions. I don't think it can be used with user-defined functions 14:18
atrodo Aye, the mark of a great language. The ability to ignore errors, fatal or otherwise 14:19
whiteknight the first time I saw that operator was in a code example about decoding user input from query strings 14:20
I was flabbergasted at the time, because you shouldn't want to be ignoring errors when decoding user input
Infinoid In an example, no less 14:21
whiteknight I guess since PHP doesn't run on the web and doesn't have to worry about malicious users, it's not so big a deal
oh, wait... 14:22
cotto whiteknight, right. I realized that after I typed it.
14:22 benabik joined, fperrad left
arnsholt PHP belongs to the "if it compiles, it's probably right" school of program design, unfortunately >.< 14:22
benabik ~~
whiteknight good morning, benabik 14:27
benabik whiteknight! What's happening?
14:28 rohit_nsit08 left
whiteknight benabik: nothing really, not so early in the morning 14:28
benabik whiteknight: Just recovering from the holiday weekend? 14:29
14:29 lucian left
dalek rrot/m0-spec: fb75076 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add exceptions and handlers

This section is probably a bit raw and will need a couple sets of eyeballs before it should be considered final. What's there now is essentially what was talked about on Saturday without a lot of explanation.		 14:29
cotto whiteknight, do you mind eyeballing that? 14:30
whiteknight sure thing
cotto thanks
cotto goes to ork
14:30 lucian joined
whiteknight cotto: I don't know if I like the separation of responsibilities here 14:31
the Exception is in charge of finding a handler, but the handler is responsible to find other handlers if it can't handle it?
it seems like a better way would be to pass the exception to an exception dispatcher somewhere, and have that dispatcher handle all the dispatch logic 14:32
or pass it on to some other neutral third party, like the Context. Right now, it's a combination of Context and Scheduler
a dispatcher could use MMD, so instead of asking handlers what types they accept, we simply MMDispatch based on the Exception type 14:33
atrodo whiteknight> It probably needs to be user definable
whiteknight atrodo: That's why I say to put it into a single object. It's easier to override a single dispatcher object somewhere then to override similar logic on multiple types 14:35
atrodo whiteknight> That makes sense
whiteknight if a Context contains a reference to an ExceptionDispatcher, and each new Context inherits the one from it's caller (:outer, or whereever), the user can set the ExceptionDispatcher at program entry and have it percolate throughout 14:36
or if we store it somewhere global, even better
I say attach it to the Context so we can use a native one when we call into a library written in a different HLL
atrodo That seems to make the most sense for interop 14:37
whiteknight cotto: I do like the idea of chainable exceptions, but I don't think the ExceptionHandler itself should be responsible for finding the next candidate 14:41
14:44 rohit_nsit08 joined
lucian exceptions are something i've been thinking of 14:49
so far for python, i was thinking of nesting its exception hierarchy in PythonException
or something to that effect
jnthn__: if you have time, i'd appreciate a more complex example for 6model, or an API reference of some sort 14:50
14:52 he_ left, JimmyZ joined
jnthn__ lucian: Yes, doing a more complete class one and a more complete prototype one are on my todo list for the next couple of days. 14:53
14:53 theory joined
lucian jnthn__: cool. i plan to finish the winxed object system and then try to rewrite it with 6model 14:53
jnthn__ nice :) 14:54
jnthn__ -> home
15:13 theory left 15:20 rohit_nsit08 left
cotto_work ~~ 15:25
whiteknight: interesting idea. 15:42
15:42 bluescreen left
whiteknight cotto: I just don't like the idea of breaking it up. Either the Exception should be searching for handlers or something else should be searching 15:42
Handlers shouldn't be searching amongst themselves
cotto_work I'm not married to any approach. 15:43
yet
whiteknight I also don't like the idea of Exceptions doing the searching, particularly. Whoever is storing the list of active handlers (the Context) should be doing the searching or delegating it
although it seems like yet more baggage for the Context to be doing that 15:44
cotto_work Having exceptions do the searching also doesn't strike me as a proper separation of concerns.
whiteknight Exception is basically an error message, a payload, and a backtrace.
cotto_work "call frame" is the new context
whiteknight A handler is basically just an invokable that expects to only take an Exception argument
cotto_work allison thought that would be clearer and more consistent with existing literature. 15:45
whiteknight that's fine. Terminology doesn't concern me as much
cotto_work Having an exception dispatcher makes some sense. 15:48
the exception invokes the dispatcher and the dispatcher dtrt
whiteknight I'm trying to look forward to a future where Classes are less expensive and we would be willing to create more of them for particular purposes 15:49
benabik +1
cotto_work I hope that future isn't too far off. Getting 6model in core will become fairly important as we get closer to putting m0 in core. 15:54
benabik 6model+M0 = awesome Parrot
cotto_work srsly
whiteknight that's my sincere hope 15:55
There are a pretty big number of optimization opportunities with that combination 15:56
16:06 theory joined
dukeleto ~~ 16:36
cotto_work hio dukeleto
dukeleto has been informed that our old JIT worked on x86, ppc and hppa, at least
cotto_work: 'ello
dukeleto updates the m0 blog post
16:36 rohit_nsit08 joined 16:42 ShaneC joined
cotto_work is proudly displaying his copy of Modern Perl at $dayjob 16:46
16:47 ShaneC left 16:50 davidfetter joined
Coke_ . 16:52
dukeleto: old jit never worked on ppc. 16:53
(at least not on darwin ppc)
atrodo maybe it "worked"
Coke_ to the best of my recollection, anyway. maybe it got fixed before it was kilt.
16:57 mj41 left, hercynium_ joined
dukeleto Coke_: rafl++ informed me that it worked on x86, ppc and hppa. I don't care to attempt to verify that :) 16:57
i suspect it "worked" for some definition of "worked"
Coke_ I would buy "linux ppc". 16:58
dukeleto Coke_: yeah, that sounds about right.
Coke_ eagerly awaits m0.
dukeleto we may want to look into using this in Parrot's configure subsystem: github.com/barbie/devel-platform-info 16:59
17:02 hercynium left, hercynium_ is now known as hercynium
dukeleto actually, that seems to just be a wrapper around %Config, but I can't tell quite yet 17:04
17:04 hercynium_ joined
dukeleto actually, it isn't. It actually runs uname/et al on the machine to get the info 17:05
17:08 hercynium left, hercynium_ is now known as hercynium 17:09 JimmyZ left
cotto_work #ps today (for those of you who had Monday off and might forget) 17:15
whiteknight cotto_work: One topic I would like to see brought up today: I would like to see Winxed snapshotted into the Parrot repo 17:25
It's becoming a necessity since several of our GSoC students and many of our regular hackers are using it
I won't be at the meeting today, as usual. But as expect, the proposal gets a big +1 from me 17:26
atrodo whiteknight> I agree. It's a great candidate to include by default 17:27
whiteknight atrodo: I see it as a candidate to eventually replace PIR all together 17:28
atrodo I agree. PIR to too highlevel to be good as "asm", and too low level to be sane
whiteknight atrodo: are you sure you're not secretly me in disguise? 17:29
atrodo whiteknight> Pretty sure. But dang, you're handsome!
whiteknight :)
17:30 atrodo is now known as no_srsly_not_whitek
no_srsly_not_whitek shoot. I think I've blown my cover 17:30
hmmm, apparently there's character limit on nicks
17:30 no_srsly_not_whitek is now known as atrodo
whiteknight oh crap, I thought that was me for a second. But then who am I? 17:31
atrodo who are any of us? 17:32
cotto_work I'm a duck. 17:34
whiteknight anyway, the point is that PIR is T3H FAILZ, and Winxed is T#H M4J0R R0XX0RS
at least, if my English-To-Internet dictionary has anything to say about the subject 17:35
my stragegy with PIR is that Winxed should pwn the n00b with a BANG HEADSHOT
atrodo Uh oh, looks like the whiteknight program has gotten corrupted 17:36
whiteknight I've been rewritten in LOLCODE! OH NOES!
cotto_work Whatever happens, PIR will be with us in some form for a long time. 17:39
whiteknight no question, but I think a reasonable "end" is closer than we might expect
if benabik's project works out and we have POST -> PBC generation happening later this year, we could write a backend for Winxed that turns the parse tree into POST 17:40
then we have Winxed -> PBC without POR
PIR
and since Winxed itself is written in Winxed, bootstrapped from C++ without any PIR there, we have a pretty good PIR-less ecosystem available
I strongly suspect that if we give people two options for writing code, Winxed and PIR, they won't choose PIR 17:41
cotto_work I wouldn't.
whiteknight and luckily, we have more than two options
we have NQP in the mix as well, which will benefit from the POST upgrades faster than Winxed will
lucian i think any writing of assembly should be strongly discouraged
whiteknight although NQP programs tend to have more inline PIR blocks than Winxed code does
cotto_work but we also have a number of existing large codebases that depend on PIR, namely Lua, Partcl, Rakudo and nqp*
whiteknight Rakudo won't use PIR in the future if it doesn't have to. They don't like PIR and are looking to minimize it. Hence all the upgrades to NQP 17:42
NQP already bootstraps nicely, all they need is a PIR file checked in to start the cycle
lucian but i'm pretty sure PIR will have to remain for backwards compatibility
whiteknight so long as humans aren't writing PIR by hand, that's still a victory
cotto_work yes 17:43
lucian i think an announcement "PIR is hereby deprecated" might help :)
benabik The problem is that PBC doesn't seem stable enough to use checked in PBC for bootstrapping.
whiteknight lucian: Sure, but we can rename it ImStupid, move it into a separate repo, and force developers to "include 'ImStupid'" in their legacy programs
atrodo whiteknight++
whiteknight benabik: exactly
benabik: it's better than it once was, thanks to efforts from plobsing, cotto, and others 17:44
benabik: but still nowhere near stable enough
lucian i'd much rather use pbc for my compiler too, but i have to use pir ...
whiteknight lucian: it's a temporary matter, most likely
lucian retargeting a compiler isn't a big deal
as long as no one writes PIR by hand from this moment on, it's fine
lucian brb 17:45
17:45 lucian left, lucian joined
benabik Using pir:: from NQP isn't as much of a problem as Q:PIR blocks. 17:45
whiteknight PIR isn't terrible as a machine-generated interchange format. It's the hand-writing of PIR that sucks 17:46
because so long as people are writing PIR, it is going to need to keep all the trappings of human ease-of-use
atrodo PIR has too much magic in it for my liking 17:47
whiteknight macros, heredocs, directives, syntactic sugar, etc
lucian whiteknight: it's still rather bad, it assumes some semantics
whiteknight lucian: right, but it's not horrible
lucian sure
benabik Do we need to resurrect PASM?
lucian it'll do for now if there's an upgrade path, which is what i think you meant
whiteknight lucian: and if the only thing generating PIR are code generators, we can start ripping out the shit that humans rely on
lucian i thought m0 was the upgrade path
whiteknight lucian: right, we don't have an upgrade path yet
lucian i'd assumed PIR was supposed to output m0 17:48
instead of pbc
cotto_work lucian: that's pretty close to the plan today. I'll be blogging about what I think the roadmap will look like this week once I have the M0 tests passing again. 17:50
dukeleto benabik: M0 is the new PASM 17:52
cotto_work whiteknight: what are your thoughts on 6model in core, especially what it'll take to get it in there.
istr you blag about it
whiteknight cotto_work: good question. My first thought is "DO WANT"
cotto_work I'm glad to hear that. Things you want tend to happen. 17:53
lucian i also like 6model, it's very similar to what i'd been building
cotto_work whiteknight: have you thought about a roadmap at all? I want to make sure I know who's doing what.
whiteknight What I think we want to do is get 6model in place in parallel to the current object model
cotto_work: yeah, I've talked with jnthn about it a little 17:54
if we put it into Parrot along with Object/Class, we can start refactoring the later system to be defined in terms of 6model
So Object/Class becomes something of the default offering of 6model, but we would also need to have tools for easily creating alterantes 17:55
alternates
lucian whiteknight: i think Object/Class is too deficient to be a default, but of course i agree it should be there for compatibility 17:56
whiteknight lucian: it will make incremental changes over time
it won't be the same garbage we have now
we can change the internals much more quickly than we can change the external interface, but both will have to change
and users should want both to change
cotto_work We won't get anywhere if we don't somehow support backwards compatibility.
whiteknight Class PMC does have a number of important methods which will form the core of the new object model 17:57
.add_method, .remove_method, .add_attribute, .remove_attribute, .add_vtable_override, etc
I want to seriously overhaul vtables at the same time. Anything which is covered by 6model (find_method, etc) should be pulled out of the vtable and relegated to the REPR 17:58
And if all objects use a PBC-based find_method implementation, we can cut out the inner runloop there and turn the find_method op into an invoke-alike 17:59
lucian whiteknight: i'd like to see vtables deprecated instead, i guess
whiteknight get/set attributes too
lucian: we do need a certain fundamental set of functionality, but anything 6model provides immediately makes the counterparts in the vtable redundant 18:00
lucian would they be necessary for anything, assuming 6model were implememted
?
whiteknight lucian: 6model has some slots for invokables, but not nearly so many as the vtable has
it handles important ones like method lookup, attribute get/set, etc. Many of the rest of the vtable can be looked at with some suspicion
Keeping in mind how inefficient crossing the C<->PIR boundary is, we can start seriously considering rewriting some fundamental types in a Parrot language instead of in C 18:01
And anything that we're writing in a parrot language can be reduced to a method, since many operations (i_add_num, etc) are extremely specialized and only used on one or two built-in types 18:02
it's hugely wasteful for CallContext or Env or ResizableStringArray or almost any type to have to hold an empty slot for i_add_num
that's just one example 18:03
er, maybe it's called i_add_float
cotto_work It'd be an interesting exercise to find out how many slots are empty in core PMCs.
whiteknight cotto_work: My best guess: "The vast majority"
lucian memory usage is gigantic in parrot, indeed
whiteknight lucian: the vtables only make up a very small portion of that, but they do set the tone for us saying that memory consumption isn't important 18:04
lucian i suppose i don't understand parrot well enough, but assuming 6model, i still don't see why anything would be needed C-side
just enough to boostrap m0 and 6model
whiteknight if Integer PMC were just a thin wrapper around an INTVAL REPR, we gain a certain economy and subclassability
lucian: There are some things where C is a legitimate performance necessity 18:05
I don't care what PyPy is doing, GC is probably going to be written in C for a long time
JIT too. And the runcores
and the frontend.
lucian whiteknight: and those require such data structures? i see 18:06
cotto_work whiteknight: speaking of the GC, currently the only interaction between GC and M0 is a gc_alloc op that'll take some flags. What else do you think will be needed?
18:07 arnsholt left
whiteknight cotto_work: that's more or less what we have now. As long as we have the ability to separate out data which is object-like (and might have destructors or pointers to other gcables) we should be fine 18:08
dalek website: benabik++ | GSoC 2: Keeping Up the Pace
website: www.parrot.org/content/gsoc-2-keeping-pace
whiteknight cotto_work: Right now we do get a non-negligible speed boost in GC sweep by having all PMCs allocated from the same arena, for instance 18:09
so we would like to continue that 18:10
actually, I just had an idea that might make our GC sweep have fewer cache misses
cotto_work whiteknight: sure. That"s what the flags would be for>
whiteknight okay, just making sure 18:11
cotto_work: I imagine you're also going to want a flag for specifying memory that the user will explicitly manage, and then a gc_free op to return that memory 18:13
that's especially important for embedding, where something like a string reference might be kept in memory outside Parrot 18:14
or in data we hang on a PMC, and is freed during PMC_destroy
cotto_work whiteknight: way ahead of you. there's sys_alloc and sys_free for that
whiteknight oh, fun 18:15
my work here is done
18:16 hercynium left
cotto_work whiteknight: what about blocking the gc? 18:18
whiteknight ah, that's a good question
GC block level is basically just an integer on the interp. If that was exposed we could just do inc/dec on it
although that seems...messy
but at the M0 level we can make the assumption that error-prone humans aren't generating the code anyway 18:19
lucian with a moving gc, how would pinning work? a flag at allocation? 18:20
18:22 arnsholt joined 18:25 pmichaud left
whiteknight we don't have a copying/compacting GC right now, so that's almost a moot point 18:26
but if we do have it in the future we are going to want that feature, you're right 18:27
18:28 ambs left, arnsholt left 18:31 contingencyplan joined 18:36 fperrad joined 18:45 dodathome joined, arnsholt joined, hercynium joined
benabik jnthn__++ # 6model documentation 18:53
whiteknight jnthn__++ indeed 18:54
NotFound Note that winxed stage 0 can't generate post because it runs out of parrot. 18:58
lucian NotFound: that's also the case for my python compiler 19:01
whiteknight NotFound: yes, but something like stage 2 could do POST 19:02
NotFound And I'm completely sure that I'll never like to generate PBC or any other binary format from external tools.
whiteknight NotFound: or, if the backend was pluggable, we could create a new driver that injects a POST backend in instead of the current Emitter
19:03 wesjdj joined
whiteknight NotFound: I would happily help to write such a backend 19:03
I suspect it would not be hard. Winxed has all the necessary information. At this point all we need is to generate POST
NotFound whiteknight: for stage 1 it will be relatively easy to use any tool parrot provide in the future, but stage 0 is a different beast.
lucian i believe a PAST textual format was suggested at some point
whiteknight lucian: yeah, but that really doesn't appeal to me
I mean, I guess we could use json and use the existing json compiler or a subclass of it, but that seems like a step in the wrong direction 19:04
NotFound Not a big deal anyway, an external PIR compiler will be enough for bootstraping.
wesjdj join /android
19:05 wesjdj left
benabik whiteknight: It would be for bootstrapping and not much else. 19:05
19:05 wesjdj joined, wesjdj left, mj41 joined
lucian NotFound: i've been wondering if stage0 is even still needed at this point 19:06
whiteknight NotFound: If the emitter was pluggable, we could also start testing running winxed on 6model, by changing the way we output class definitions
that would be extremely interesting for me
benabik I'm having a late lunch. Will try to be back before #ps
whiteknight benabik: your "WILL DO" Section is cut off. I assume there was something in that section? 19:09
NotFound whiteknight: well, if you want winxed in the repo to make easier to people to hack with it, I want 6model in the repo for the same ;) 19:11
lucian NotFound: sounds good :) 19:12
whiteknight NotFound: we want the same things
lucian i'd also like a winxed API for 6model, but that's likely far off 19:13
NotFound lucian: stage 0 is not really needed now, but I want to keep a working way to bootstrap from ground zero.
whiteknight yes, a REPR { } defintion syntax in winxed would be the best
whiteknight dreams a dream
NotFound Well, winxed was a dream less than two years ago. 19:15
benabik whiteknight: Shoot. Ran off too fast. Did it eventually appear or should I redo it from phone? 19:16
lucian regardless, the preferred way of interfacing with 6model will likely stay NQP. i better learn it 19:17
benabik loves the Colloquy bouncer.
whiteknight benabik: never appeared 19:21
benabik: you can post it later if you want
lucian: yes, bite the bullet for now
NotFound Uh... if 6model will become the basis of parrot object models there must not be a preferred way. 19:22
whiteknight for now. It's not in Parrot yet
eventually, it will all be easy and pretty and will make waffles for you
benabik whiteknight: It showed up in the backlog on my phone. Copy/paste fixes everything!
whiteknight benabik++
19:24 lucian left 19:27 linge joined 19:39 fperrad left
cotto_work benabik: in your blog you mentioned that you were having trouble finding time talking with me. 19:50
benabik: did you mean bacek? 19:51
benabik cotto_work: Blarg. Yes.
cotto_work: Was reading you talking on IRC while writing blog.
cotto_work benabik: ok
funny how that works 19:52
benabik cotto_work: Fixed 19:53
cotto_work bacek's a lot tricker to get a hold of than I am, especially if you live in the US. 19:54
benabik We had planned to catch up this weekend, but I guess something came up. Havent seen him 19:56
cotto_work Fortunately there are others who can help. Unfortunately most of us aren't magical coding robots. 19:59
20:00 lucian joined
benabik cotto_work: I'm not blocking on it. Just was looking to get a look over and help putting it parrot main repo. 20:01
20:01 soh_cah_toa joined
cotto_work soh_cah_toa: have you sent in a cla? 20:05
20:05 pjcj left, pjcj joined
soh_cah_toa cotto_work: yeah, several weeks ago actually 20:05
cotto_work soh_cah_toa: ok
seen kid51 20:14
aloha kid51 was last seen in #parrot 19 hours 10 mins ago joining the channel.
20:14 ambs joined
cotto_work #ps in 15 20:14
20:21 pjcj left, pjcj joined 20:24 pjcj left 20:25 pjcj joined
tcurtis Is there a convenient way to send the contents of a text file to a channel in irssi? 20:25
sorear maybe something with /exec 20:28
tcurtis Indeed. -out, somewhat confusingly, sends it to the channel. 20:29
20:30 rohitnsit08 joined
cotto_work #ps time in 0 minutes 20:31
20:39 dodathome left
dalek nxed: r1025 | NotFound++ | trunk/winxedst1.winxed:
look for functions in scope on non-declared symbols
 20:40
20:40 ambs left 20:41 ambs joined 20:48 dmalcolm joined 21:09 hercynium left, whiteknight left 21:28 rohitnsit08 left, rohit_nsit08 left 21:33 mj41 left 21:42 ambs left 21:46 Psyche^ joined
cotto_work dukeleto: whiteknight suggested that a better way to do M0 exceptions would be to have an exception dispatcher that took care of finding and invoking the correct exception handler, rather than making the exception handlers do the work. 21:49
dukeleto: thoughts?
21:51 Patterner left, Psyche^ is now known as Patterner
dukeleto cotto_work: seems reasonable. but does that introduce magic into M0? 21:53
lucian are exceptions implemented underneath or on top of M0? 21:56
cotto_work lucian: exception handlers have a limited form of support in M0, but it's all userspace on top of that so far 21:58
fsvo "user"
dukeleto: that's my concern too 21:59
lucian: the only support for exceptions in M0 is "here's a register to put your handler" 22:00
lucian i understand whiteknight's motivation, to make app-leve exceptions first-class
but i'm not sure i dislike nesting all app-level exceptions for a particular language in one first-class exception (as is done now, mostly)
hmm, winxed appears particularly tolerant with using keywords as names 22:31
benabik lucian: You can use keywords as names, or it just doesn't error if you try? 22:32
lucian benabik: apparently the first
22:40 kid51 joined
NotFound lucian: the reason is simple: there are no keywords at all. 22:51
lucian NotFound: how so?
NotFound lucian: the keyword meaning is only looked in the appropiate context, otherwise they are just identifiers. 22:52
lucian NotFound: i see. interesting
NotFound Of course, to protect yourself against future changes, you should avoid that feature. 22:55
lucian and to save sanity :)
class int { var var; is very odd :) 22:56
NotFound I remember some old basic where you can write things like if if then then=else
else else=then 22:57
lucian heh
cotto_work ow 22:58
though today we have the starry obfuscation
( perlgeek.de/blog-en/perl-6/dissecti...-obfu.html ) 22:59
tcurtis I am slightly amused that in Python (2, at least), True/False are actual variables.
lucian tcurtis: yes, you can do fun things with that. not in 3, though
cotto_work tcl apparently does that too 23:02
NotFound In winxed true and false are constants at root namespace scope, you can have some fun redefiining them in other scopes.
tcurtis wonders if Python programmers ever used "while True:" loops. 23:03
NotFound I prefer: for (;;)
lucian tcurtis: yes 23:04
tcurtis is tempted to run the tests for random Python libraries with True and False set to objects with a __nonzero__(that's the method "if" calls, right?) method that returns randomly. 23:07
NotFound You can combine that with the random function from xkcd. 23:08
lucian tcurtis: i don't think if calls __nonzero__ on them, let me check :)
tcurtis: uh, can't even find a __nonzero__ 23:09
NotFound xkcd.com/221/
lucian tcurtis: and i checked, you're right. adding __nonzero__ would affect truthiness 23:10
it overrides the default 23:11
23:12 lucian_ joined 23:17 lucian left, kid51 is now known as kid51_at_dinner
jnthn__ Arrgh. 23:20
Parrot_pcc_invoke_from_sig_object sucks
Rather than blacklisting the NCI PMC as a case where it should *not* call runops after an invoke (cheap), it instead does a bunch of other checks that cost and mean I need to put a stupid hack in.
See do_run_ops in pcc.c 23:21
Please can somebody fix this? 23:22
cotto_work jnthn__: I'm looking at the code now. 23:26
jnthn__ cotto_work: thanks.
cotto_work: It'll be a sanity win and a (minor) speed win if fixed :) 23:27
cotto_work jnthn__: are you saying that do_ops_run should explicitly return 0 for an nci PMC?
jnthn__ cotto_work: The comment says: 23:28
Check should we run ops.
PIR Subs need runops to run their opcodes. Methods and NCI subs don't.
It'd be better to just look for the Method and NCI case and return 0, and return 1 otherwise.
Those are the weird cases. The common case is we do need to runops. 23:29
cotto_work jnthn__: I'll play with that and make sure you know when it's in master.
jnthn__ Right now if I've got an object that is meant to be invokable, I have to go and add a hack does vtable.
23:29 preflex left
cotto_work jnthn__: ok. That makes the problem much clearer. Thanks. 23:30
jnthn__ cotto_work: Thanks! :) 23:31
cotto_work jnthn__: do you have a test case?
23:32 preflex joined
jnthn__ cotto_work: Will soon. 23:32
dalek p: 970ebe2 | jonathan++ | src/pmc/sixmodelobject.pmc:
Add a (hopefully quite temporary) workaround for Parrot's Parrot_pcc_invoke_from_sig_object sucks.
 23:33
jnthn__ ^^ That patch is the workaround that should be removable.
Still working on the thing that hit it.
cotto_work jnthn__: I'll have to wait until a little later this evening to fully understand that bit of code. 23:40
It's part of the code I'll need to understand pretty well for the coming 6modelpocalypse though, so this'll be a good excuse. 23:41
jnthn__ cotto_work: OK. On latest Rakudo nom branch, if you can run gist.github.com/1001495 and it works with the nqp hack I just committed above removed, then the issue is resolved. :) 23:42
cotto_work jnthn__: perfet
*perfect
and the irony is not lost on em
iF;srglhgkjlshnkgjlhakl;
(trying to get all my typos out at once)
jnthn__ :)
sorear hey, seven digit gists 23:43
\\o/
cotto_work that was fast
I guess a bunch of people tried to get 1000000
lucian_ NotFound: 223 loc for an almost correct python object system :) 23:47
NotFound: it's missing metaclasses, exceptions and a lot of checks
23:47 lucian_ is now known as lucian
cotto_work lucian: nice 23:48
lucian cotto_work: i think i've almost reimplemented 6model :) 23:50
cotto_work heads home 23:52
tcurtis lucian: wrong version of Perl. ;)
lucian tcurtis: yeah, has different letters two, not just numbers :) 23:53
23:54 baest left

Powered by Cro and the Raku® Programming Language.

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

Thank you!