Parrot 3.5.0 "Menelaus" released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 21 June 2011.
00:00 cotto joined
soh_cah_toa cotto: how should i organize my test files? should they all go in one file or separated somehow? 00:04
cotto soh_cah_toa, things that test similar parts of the code should go in the same file. 00:05
whiteknight dukeleto: ping 00:06
cotto soh_cah_toa, I'd put everything in one file for now and break it up later if it starts to sound like a good idea
soh_cah_toa ok
cotto soh_cah_toa, are you familiar with breaking Perl code into a module? 00:07
soh_cah_toa i've never done it before but i've read enough about it to try it w/ minimal obstacles 00:08
00:08 darbelo left
whiteknight msg dukeleto I want to remove all the PARROT_CALLIN_START and PARROT_CALLIN_END macros from src/extend.c They're useless for several reasons. Let me know what you think about it 00:09
aloha OK. I'll deliver the message.
00:10 cottoo joined
soh_cah_toa cotto: why? you think i should break it up into a separate module? 00:10
00:11 dmalcolm left
cottoo soh_cah_toa, you'll have to if you want to use more than one test file 00:11
soh_cah_toa cotto: ok. a separate HBDB::Test module or add it to Parrot::Test? 00:12
cottoo soh_cah_toa, probably something Parrot::Test::hbdb. Follow any patterns you find. 00:14
00:15 cotto left, cottoo is now known as cotto
soh_cah_toa sure. that'd be fun actually 00:15
00:16 lichtkind joined
lichtkind whiteknight: is it right that you are interested in 6model? 00:16
whiteknight yessir
lichtkind so it might land in parrot? 00:17
any time scale?
whiteknight I hope so, and soon
soh_cah_toa cotto: so i've gotten the ipc script to behave correctly except i still get the null pmc problem. i can catch it w/ Parrot_io_eof() but i realized, i don't know what i want it to do on eof :\\ 00:18
lichtkind whiteknight: is it for better rakudo interoperability or just to get a decent MOP? 00:19
whiteknight lichtkind: for a better MOP. our current one is T3H SUXX0RZ
lichtkind whiteknight: rumor said so 00:20
whiteknight 6model solves a lot of problems we have, and adds new features
lichtkind but i have no clue about that
im working mostly on GUI level
whiteknight okay 00:22
cotto soh_cah_toa, you'll have to decide that. 00:23
soh_cah_toa i just don't want it to crash
cotto crashing is probably not optimal
soh_cah_toa definitely no
lichtkind whiteknight: on which level you want to implement model 6 ? 00:24
whiteknight lichtkind: what do you mean?
soh_cah_toa cotto: i guess i'm confused b/c i don't understand why eof causes failure as it is 00:25
cotto whiteknight, I'd like to float a random idea by you. If we want the M0 and Parrot implementations of 6model to be used by all languages, should we give it a more neutral name?
lichtkind whiteknight: as part of PCT or PIR where exactly? 00:26
whiteknight cotto: yes, I think so. And we'll probably want to rename several artifacts in the code to use less p6 lingo
lichtkind: right inside Parrot, at the lowest level. We'll use it to implement all our core types and to build all objects on top of
cotto whiteknight, in some ways it's trivial, but it's important for marketing. 00:27
whiteknight cotto: yes, I agree. Plus, it becomes more hackable if you call something "metaclass" instead of "HOW"
people without a p6 background won't know what the heck a HOW is
and I see no reason to call something a REPR, when "representation" is much more clear 00:28
cotto right. We can steal ideas selectively.
00:28 jsut joined
lichtkind whiteknight: when did you decide that? 00:28
dalek rrot: 28b79f9 | Whiteknight++ | NEWS:
Update NEWS to cover the add_vtable_override change
rrot: 1c18f6f | Whiteknight++ | src/ (2 files):
Merge branch 'whiteknight/embed_refactor'
rrot: f406942 | Whiteknight++ | / (4 files):
Move Parrot_compile_string to inter_misc.c so it can live next to Parrot_compile_file. These both probably belong in a file dedicated to compiler-related routines
rrot: 942bad2 | Whiteknight++ | src/extend.c:
Several misc cleanups to src/extend.c. Add some TODO and DEPRECATED notes where necessary. Remove CALLIN macros where they are clearly not needed
whiteknight cotto: We love the implementation, just need to change some of the terminology 00:29
or, at least provide a handy glossary
cotto yes and yes
and double yes
whiteknight lichtkind: What do you mean? If we don't make 6model our base for our entire object system, we don't have a base for it
Our current MOP sucks too bad to build on top of
lichtkind its healthy if you admit it openly 00:32
cotto I was thinking something like cmop for "common meta-object protocol" (and cleaning), but that's just me.
00:33 jsut_ left
TimToady note that if you start renaming things, you should rename them correctly. .HOW is not a metaclass, but a metaobject 00:33
which might be an instance of a metaclass 00:34
lichtkind cotto: is that cmop name decided?
cotto lichtkind, no. I just thought of it on the drive down to OS Bridge.
lichtkind whiteknight: i mean is: when was it decided to implement 6model in Parrot? 00:35
whiteknight lichtkind: back when it was being developed. We liked what we saw, saw no other real alternatives, and decided to roll with it
cotto lichtkind, that's been the plan for a while
whiteknight TimToady: right, right. See? That terminology is clearly not clear enough 00:36
00:36 theory left
lichtkind i just ask you because that part i got not correct so far 00:41
i thought lorito was mainly about Mo
M0
sorear lichtkind: could you please stop calling it "model 6"? 00:43
dalek rrot/whiteknight/kill_CALLIN: 85781e9 | Whiteknight++ | / (4 files):
Remove PARROT_CALLIN_START and PARROT_CALLIN_END macros. The Extending API should not be called from a situation where GC has not been set up. Most functions used in an extending situation do not have these macros, so they are clearly not important.
 00:46
cotto lichtkind, lorito is M0 + 6model + some other ill-defined things
whiteknight msg dukeleto: proof of concept. Look at the whiteknight/kill_CALLIN branch on github. I've removed those macros and see no ill-effects here
aloha OK. I'll deliver the message.
sorear whiteknight: AIUI, the purpose of PARROT_CALLIN_START is to tell the GC about the portions of the stack which belong to Parrot and thus should be scanned 00:47
whiteknight sorear: sure, but that isn't necessary in an extending situation 00:48
sorear: Most functions used by extenders don't have those macros. I've written entire extension projects and never used any of these routines
If we need functionality for the user to specify a stack range for sweeping, we can do that. Implicitly setting ranges in some API functions but not in others is not a good way to do it
lichtkind sorear: my history tells me that I did just once recently 00:49
sorear lichtkind: you've done it before
lichtkind sounds like a crime :) 00:50
sorear no, it just bothers me
lichtkind that wasnt my intent, just mistype things sometime 00:51
whiteknight: are the any milestones for lorito? 00:52
cotto lichtkind, that's something we need to work on hammering out 00:53
lichtkind so you are in earling planning stage 00:54
cotto planning stage, yes. early, perhaps
bubaflub whiteknight: is their a convenient way in Rosella test to check if something is greater or less than a certain number? 01:18
perhaps self.assert.is_true($a > 1) ?
whiteknight bubaflub: that's what I would do. is_true combined with a comparison operator
bubaflub whiteknight: ok, great. thanks.
whiteknight I could try to add comparison assertions like that,but then what do I do if the user passes in a string? or some arbitrary PMC type that doesn't implement get_integer? 01:19
bubaflub yeah, that's true - there are too many types to handle
Coke yawns. 01:21
lichtkind thank you for your patience 01:47
dalek sella: 4dd87c8 | Whiteknight++ | src/filesystem/Directory.winxed:
Fix a stupid mistake in Directory so it works and runs tests again
 01:48
01:59 whiteknight left
bubaflub incoming 02:07
dalek rrot-gmp: da0747f | bubaflub++ | t/integer/cmp/01-cmp.t:
add tests for cmp

this covers mpz_cmp and mpz_cmp_d
rrot-gmp: 8bbf39c | bubaflub++ | t/integer/cmp/02-cmp.t:
add tests for cmp

this covers mpz_cmpabs, mpz_cmpabs_d, and mpz_cmpabs_ui
rrot-gmp: 7aa5680 | bubaflub++ | t/integer/and.t:
add tests for and

this covers mpz_and
rrot-gmp: 1165bdc | bubaflub++ | t/integer/ior.t:
add tests for ior

this covers mpz_ior
rrot-gmp: 7814fb6 | bubaflub++ | t/integer/xor.t:
add tests for xor

this covers mpz_xor
rrot-gmp: 5f087ce | bubaflub++ | t/integer/com.t:
add tests for com

this covers mpz_com
rrot-gmp: 422d1d6 | bubaflub++ | t/integer/popcount.t:
add tests for popcount

this covers mpz_popcount
rrot-gmp: 4314323 | bubaflub++ | t/integer/hamdist.t:
add tests for hamdist

this covers mpz_hamdist
rrot-gmp: 9227653 | bubaflub++ | t/integer/scan.t:
add tests for scan functions

this covers mpz_scan0 and mpz_scan1
rrot-gmp: 02d060b | bubaflub++ | t/integer/bit.t:
add tests for bit functions

this covers mpz_setbit, mpz_clrbit, mpz_combit and mpz_tstbit		 02:08
02:15 theory joined 02:23 woosley joined 02:34 rurban_ joined 02:37 rurban left, rurban_ is now known as rurban 02:46 lichtkind left 03:05 pjcj left 03:36 daniel-s joined 03:50 cotto left 04:00 daniel-s left 04:07 cotto joined
dalek rrot/soh-cah-toa/hbdb: 4905678 | soh_cah_toa++ | include/parrot/hbdb.h:
Hex values for status and condition flags were wrong
 04:32
rrot/soh-cah-toa/hbdb: ca2a5d4 | soh_cah_toa++ | / (2 files):
Created the Parrot::Test::HBDB module so tests can be run from multiple files
 04:33
cotto soh_cah_toa++ 04:34
dalek rrot: 19bbdee | petdance++ | lib/Parrot/Pmc2c/P (3 files):
Remove unused inclusion of Text::Balanced
soh_cah_toa cotto: i knew you'd be happy :)
cotto you knew right 04:35
though to be fair I haven't looked at the commit yet
soh_cah_toa it's not a bad start 04:36
cotto soh_cah_toa, you shouldn't skip tests if hbdb doesn't exist. Running the tests without hbdb should cause a failure.
though that's a minor point
soh_cah_toa i just did that b/c that's what pbc_disassemble does 04:37
i figured that's standard practice around here for non-essential embeddings/extensions 04:38
cotto I wish I could hack on the ipc script, but technology has not yet progressed to the point that my talk for tomorrow will write itself. 04:39
soh_cah_toa the ipc thing is actually ok i think. it's just the eof nonsense that's preventing it from becoming tap-able 04:40
i think i have an idea though 04:42
i noticed that for gdb, entering ^D causes it to execute the quit which would be easy for my i could just do if(Parrot_io_eof(stdinput) interp->hbdb->current_command = "quit"; 04:43
cotto That'd be reasonable. 04:44
soh_cah_toa i could still write the test but it wouldn't pass (which i know is ok) b/c i still don't have command recognition :(
cotto don't let that stop you 04:45
soh_cah_toa i know
cotto the do ;]
*then
soh_cah_toa that's tomorrow's first task and i don't see it taking too long 04:46
cotto perfect
soh_cah_toa and on that note, i must depart 04:48
see ya later
04:48 soh_cah_toa left 05:11 fperrad joined 05:23 cotto left 05:34 theory left 05:37 lue joined
lue Hello. I've tried to compile Parrot as a part of Rakudo on my own machine for the first time (been doing it on a remote server for all my work so far), and it won't compile anything on make because it doesn't recognize the "-march" option. Why is Parrot having problems here? 05:40
06:05 lue left 06:53 contingencyplan left, woosley left 06:55 woosley joined 07:13 pjcj joined 07:15 Eclesia joined
Eclesia hi 07:15
sorear hi
07:40 mj41 joined 07:45 benabik_ joined 07:47 benabik left, benabik_ is now known as benabik 08:09 jjore left 08:15 daniel-s joined 08:48 ligne left 08:50 mikehh left 09:41 Kulag left 09:45 Kulag joined 09:51 jjore joined, Kulag left, Kulag joined 10:02 Kulag left, Kulag joined 10:03 particle joined 10:07 particle1 left 10:08 woosley left 10:10 Kulag left 10:11 Kulag joined 10:12 daniel-s left 10:22 Kulag left, Kulag joined 10:23 dodathome joined
dalek p: 5a7d782 | moritz++ | src/PAST/NQP.pir:
add missing mod_n opcode, kboga++
 10:24
10:34 rurban_ joined 10:37 rurban left, rurban_ is now known as rurban 10:51 lg_quassel joined 10:53 losinggeneration left 10:56 ambs joined 11:19 Eclesia left 11:33 AzureSto_ joined 11:36 AzureStone left 11:47 AzureSto_ left, AzureStone joined 12:21 PacoLinux joined 12:41 SHODAN joined, bluescreen joined 12:45 KaeseEs left 12:46 AzureSto_ joined 12:48 AzureStone left 12:49 bluescreen left
atrodo =~ 12:54
12:54 whiteknight joined
whiteknight good morning, #parrot 12:55
12:56 cotto joined 12:58 mtk left 13:04 bluescreen joined 13:05 fperrad left
bubaflub ~ 13:11
13:15 fperrad joined 13:19 daniel-s joined
dukeleto ~~ 13:21
bubaflub morning dukeleto 13:36
whiteknight good morning dukeleto, bubaflub 13:37
bubaflub morning whiteknight 13:38
13:40 fperrad left
whiteknight bubaflub: how is the project going? 13:42
bubaflub whiteknight: not bad... trying to get 100% test coverage revealed a few bugs and other unexpected surprises 13:43
whiteknight: for example, before i call functions to generate psuedo-random numbers, i have to call initialization functions which i don't have bindings for and also need another struct (and hence StructView)
but all in all, it's going very well
whiteknight bubaflub: 100% test coverage can be something of a red herring. Don't chase it around too much. 13:45
Get enough coverage to feel confident that what you are doing is correct, then move on to the next thing
bubaflub whiteknight: yeah, what i mean by "100%" is that all the functions that i have bindings for have at least two tests 13:46
whiteknight Adding new features may start to expose new usage patterns that your tests don't cover, or may find new bugs. Or, new features may cause old code (and, the related tests) to change
bubaflub so maybe "complete" is a better word
whiteknight ok
bubaflub whiteknight: right - when i start adding more vtable overrides i'll need to make sure those are all working as i expect
whiteknight definitely. vtable overrides are both tricky to get right, and are likely to change semantically in the future 13:55
so tests are double-plus-good for those
13:58 SHODAN left 14:05 darbelo joined
dukeleto bubaflub: whiteknight++ is giving you some good advice 14:12
whiteknight: if you say that the CALLIN macros in src/extend.c are useless, feel free to remove them all. Please update the comments about them too :) 14:16
whiteknight: i was mostly cargo-culting and following the comments in that file
14:22 tcurtis left
cotto ~ 14:27
14:40 hercynium joined
whiteknight dukeleto: Okay, I started a branch to remove them and saw no problems. I want to get some more testing to make sure, but I think it will be safe to merge 14:40
I removed those macros and updated comments about them
14:43 cotto left 14:47 hercynium left 14:50 hercynium joined 14:51 theory joined 15:01 cotto joined 15:03 darbelo left, daniel-s left
benabik Morning, #parrot! 15:03
15:06 tcurtis joined
bubaflub morning benabik. how goes the project? 15:10
benabik bubaflub: Pretty decent. bacek suggested I back-burner killing the last few chunks of PIR and move on with things. :-)
bubaflub: Which puts me into the "figure out what I'm doing next stage", so no code for me for a day or two. 15:11
bubaflub interesting. how has the PIR -> NQP conversion been - pretty straightforward?
benabik Mostly... NQP doesn't seem to handle multiple return, which is a little sad. 15:12
And I kept hitting odd infinite loops where it would sit and start eating all my memory. Never quite figured out why that kept happening.
Probably was building too many PAST nodes.
*POST 15:13
bubaflub so i'm kinda confused about all the terminology - what exactly is the difference between PAST and POST? are they both abstract representations of compiled code? 15:14
benabik PAST is an abstract syntax tree that has things like statements, blocks and expressions. 15:15
POST is much more a list of operations, very close to PIR/PASM/PBC
bubaflub ok, and the goal is to be able to compile to PBC without having to go through the PIR layer, right? 15:16
benabik PAST::Compiler is responsible for turning a tree like (+ 1 ( * 2 3)) into "$I0 = mul 2, 3 ; $I0 = add 2, $I0"
(Well, a list of POST::Ops that represents that, anyway).
15:18 ligne_work left
benabik Yes, the goal is to avoid PIR. Bacek wrote a new POST library that can do it, but the current PAST::Compiler doesn't use the new classes. I'm currently poking through newPOST to determine what changes have to be made. 15:23
15:24 cotto left
whiteknight PAST nodes represent the input. POST nodes typically represent the output 15:27
they're both tree forms, but with different jobs 15:28
benabik POST is a very very flat tree though.
bubaflub ok, that makes sense 15:29
whiteknight basically, your parser turns your source code into PAST. PAST generates POST from itself. POST generates output, PIR or PBC whichever the case may be 15:30
but yes, the terminology here is unnecessarily dense 15:31
benabik (Currently, only PIR. Sadface.)
bubaflub and isn't there the tree-optimizations project to do some manipulation of P[AO]ST? 15:32
benabik I think it's about as dense as it needs to be. There are several layers of code, each doing a separate task.
15:32 tcurtis_ joined, tcurtis left
benabik Yes, but AFAICT, there are no written optimizations, just a set of classes that could be used to write some. 15:32
15:33 mikehh joined 15:34 theory left
whiteknight yes, we need to dust off that project and get it working well 15:35
the tree optimizations one
we need to write some optimizations for it, etc
benabik I'm very tempted to spend some time with LLVM's optimizations and what's useful to steal. 15:36
Although this may involve creating some variety of SSA POST form. :-/
atrodo beware of the ratholes 15:38
benabik Ratholes? 15:39
whiteknight holes. With rats. 15:40
15:40 estrabd left 15:44 estrabd joined 15:49 cotto joined
cotto ~~ 15:49
dukeleto, ping
15:55 mj41 left 16:10 theory joined
alester I had this crazy hope that removing "use Text::Balanced" from three different lib/Parrot/*.pm files would make the build significantly faster. 16:17
Not a REALISTIC hope, of course. 16:18
dalek p: 1572977 | moritz++ | src/ (2 files):
a few simple pir:: to nqp:: changes, and remove trailing whitespace
 16:26
17:03 fperrad joined 17:24 Kulag left, Kulag joined
dukeleto ~~ 17:28
cotto: pong
17:30 Drossel joined 17:32 Kulag left 17:34 Drossel left 17:36 Kulag joined 17:41 dmalcolm joined 17:54 Drossel joined 17:57 Kulag left 18:02 Drossel left, Kulag joined 18:06 fperrad left, cotto left 18:10 davidfetter left 18:11 Drossel joined 18:12 ambs left 18:13 Kulag left 18:17 Kulag joined, cotto joined 18:18 Drossel left, contingencyplan joined
dalek p: ba48021 | pmichaud++ | / (3 files):
Add some more nqp:: ops and tests.
 18:21
18:24 Kulag left, Kulag joined 18:35 rurban_ joined 18:36 Kulag left 18:37 rurban left, rurban_ is now known as rurban
dalek p: be6433c | pmichaud++ | t/nqp/59-nqpop.t:
Add more nqp:: list/iterator tests.
 18:38
18:49 masak joined
masak o/ 18:49
I'm glad that Parrot has an ncurses library, but I'm saddened that the example file isn't maintained. 18:50
trac.parrot.org/parrot/ticket/2130
if someone were to fix this, I might be motivated to whip up a Rakudo wrapper module.
bubaflub masak: i can fix this 18:51
masak \\o/
someone is bound to have thought of this, but I'll say it anyway: it would be nice to have some kind of testing in place so that the files in examples/ don't bitrot. 18:52
bubaflub masak: i'm also working on getting PDD16 (the NCI docs) up to date; it looks like 2/3/4 and t signatures are still in there. i'll remove them from the docs.
masak: agreed.
masak it kinda looks like you don't care, and I know you do.
bubaflub "you" in the previous sentence is plural, i take it 18:53
masak yes. "y'all".
bubaflub *phew*
masak :P
in fact, I should probably be more involved myself. 18:54
bubaflub masak: i won't have time to get to it until later tonight, but it looks relatively straightforward.
masak nodnod
there's no great hurry.
PerlJam masak: prodding others to do the things you mayn't have enough time to do is better than nothing. 18:55
masak yes. I'll sharpen my prod sticks and lie in wait, then. :)
18:56 cotto left
dalek p: 68ed28c | pmichaud++ | / (2 files):
Fix nqp::cmp_{i|n|s} opcodes, add tests.
 18:59
19:00 Kulag joined
whiteknight I'm not sure how we would go about testing the ncurses example, besides compiling it to verify syntax 19:02
or, executing it to verify it doesn't throw any unhandled exceptions maybe 19:03
masak compiling it would be a good start. 19:04
whiteknight is the current ncurses example having a syntax error?
bubaflub whiteknight: yeah, it's using the NCI signatures 2 3 and 4 which were deprecated 19:05
also, i'm seeing some 't' in there which is deprecated
whiteknight okay, so a test that only compiled this wouldn't have caught it
bubaflub whiteknight: no, i don't think so. i think we'd actually have to try to call these functions to see the dlfunc fail 19:06
whiteknight okay 19:07
pmichaud the 't' can be handled by using NCI::Utils 19:09
NCI::Utils::ncifunc is meant to be a compatible-replacement for the old dlfunc opcode
(compatible at least as far as the 't' goes... doesn't have some of the other parameter types anymore) 19:10
bubaflub pmichaud: ah, call_with_cstring. i might use that in my project. 19:12
pmichaud maybe. ncifunc handles it better, imho
call_with_cstring is a bit more convoluted. 19:13
also, ncifunc has tests in t/library/nciutils.t -- the other functions don't have any tests. :( 19:14
19:14 hercynium_ joined
bubaflub pmichaud: so should i add 1,2,3 and 4 types to ncifunc (even though they are deprecated) or should i fix the ncurses to not 1,2,3 and 4? 19:15
pmichaud I think the latter would be preferable
whiteknight bubaflub: either way, we should fix the example to not use deprecated items
but fixing the compatibility library to support them is not a bad idea either
bubaflub whiteknight: ok, here's what i'm thinking: 1 19:16
19:16 hercynium__ joined, jevin joined
pmichaud I don't think ncifunc should be strictly a compatibility library, fwiw. 19:16
I think ncifunc should be the standard API to dlfunc.
bubaflub fix ncurses example to compile, get masak happy. 2) add more mojo to ncifunc. 3) add tests for NCI::Utils.
pmichaud ncifunc does provide compatibility for the 't' parameter type, but that's not really its primary purpose 19:17
its primary purpose is so that we can have an abstraction layer between the dlfunc opcode and whatever API we really want to support.
so, if the 1/2/3/4 parameter types were deprecated, let's not reintroduce them via ncifunc unless we really feel like they're needed.
't' was "reintroduced" because it's a very common use case that is actually needed. 19:18
not just to provide backwards compatibility.
19:19 davidfetter joined, autark left, autark joined 19:20 hercynium left, hercynium__ is now known as hercynium
bubaflub pmichaud: ok, so then just two steps - 1) fix ncurses 2) add tests for NCI::Func 19:20
19:20 hercynium_ left
pmichaud that's what I'd prefer to see, yes. 19:20
bubaflub as well as investigate any other examples that are broken
ok, that sounds do-able 19:21
pmichaud: also, while i got you here - is there any interest in Rakudo-land for GMP bindings? it's my GSoC project.
pmichaud we're hugely interested.
like, I really want to see it working.
colomon++ (one of the rakudo contributors) played with gmp some earlier in the year, but was having trouble getting it to compile on macos, which made it kind of a blocker for using it with rakudo. 19:22
so, we're very eagerly following your progress. apologies if you weren't aware of that. :-) 19:23
bubaflub pmichaud: no problem. is the Winxed convenience class helpful? or would y'all like to see something done in NQP?
pmichaud as soon as gmp bindings are available, we'll likely start experimenting with bignum support in nqp. 19:24
we haven't completely figured out how bignum should fit into Perl 6, 6model, and NQP. But that's also partially because we haven't had anything usable that we can experiment with.
19:24 hercynium_ joined
pmichaud put another way, as you have things that we could start using/evaluating, I suspect I could start trying it out with nqp and providing feedback. 19:25
(modulo the fact that I'm already spending 16+ hrs/day hacking on other stuff for nqp and rakudo-nom :)
bubaflub pmichaud: any feedback is welcome. i've still got a 1.5 months or so left and will probably have some extra time in the project.
pmichaud: beyond docs and examples, lemme know what y'all would like to see 19:26
pmichaud examples and docs are best for me, by far
is there a parrot branch we can build against?
19:26 cotto joined
cotto ~~~ 19:26
bubaflub pmichaud: it's in a separate project right now and there is no setup.pir or anything like that, but by midterm i'd like to have it on plumage 19:27
pmichaud pass me urls and documentation and examples as soon as you can :) 19:28
bubaflub pmichaud: github.com/bubaflub/parrot-gmp, a basic Winxed example lives under examples/basic.winxed :-) 19:29
19:30 hercynium left, davidfetter left
bubaflub realizes i haven't updated the README in ever. 19:31
pmichaud bubaflub++ 19:32
19:32 hercynium_ left
whiteknight bubaflub++ indeed. I didn't realize you had such a large test suite already 19:34
bubaflub whiteknight: heh. i'm glad i didn't add the Rational and Float functions as well.
pmichaud bubaflub: can you give me an idea of the GMP interface at a lower level? e.g., from pir? The winxed example looks too abstracted for me to know what it's doing. 19:35
bubaflub pmichaud: certainly. you can perldoc src/GMP/Integer.winxed to look up specific functions. i kept the same function signatures as the C library so it's a one-to-one mapping there. 19:36
pmichaud bubaflub: perfect, I'll look there. 19:37
whiteknight bubaflub: are you going to be adding a higher-level interface, or just thin wrappers around the GMP structures and functions?
pmichaud low-level interface is probably what we prefer, fwiw. 19:38
bubaflub pmichaud: the Winxed constructor just hides a StructView (to hold the GMP Integer guts) and a call to mpz_init() which initializes the space for that. all other functions usually take an integer (an mpz_t) as the first parameter rather than returning a new integer. if you see 'rop' as the first parameter that's what that is.
whiteknight: i plan on adding some vtable overrides so you can do things like x + y intelligently.
whiteknight: is that what you are talking about?
whiteknight bubaflub: yeah, that seems nice enough
bubaflub whiteknight and pmichaud: i'm open to suggestions, especially in the form of GitHub issues. 19:39
pmichaud: last thing - most of the code there is generated from gmp.h and the docs, but i've included the results of that generation in PIR so you technically don't need Winxed for anything. just parrot -o to .pbc and use away. 19:40
pmichaud bubaflub: that sounds perfect
whiteknight I really like that approach. That's what Rosella does for releases
pmichaud awesome, even. bubaflub++ bubaflub++
I'll definitely see about giving it a try in the next week or so.
whiteknight Although, if Parrot ships with winxed now, that might be a little bit less necessary
bubaflub pmichaud: the PIR bindings are super-lowlevel. no type checking or anything. the Winxed functions do some basic type checking and throw sane errors. 19:41
whiteknight bubaflub: so using a lot of the same kind of infrastructure, it should be pretty easy for you to auto-generate function stubs for the float functions too?
pmichaud we don't really need type checking at our low-level
bubaflub pmichaud: exactly. Winxed is for convenience and prototyping algorithms and what not.
pmichaud I've also been toying with the notion of building a native calling interface directly into NQP instead of using Parrot's. 19:42
bubaflub whiteknight: yep. for example, i wrote a small script that reads the GMP docs in HTML and using Web::Scraper pulls the function signatures and docs out and dumps it in a big hash. from there i generate the Winxed.
pmichaud but we'll see how that progresses.
bubaflub whiteknight: theoretically i could have it generate something else if i use Template::Toolkit or something more sane.
whiteknight I know the biggest work expenditure is probably in writing all those tests 19:44
bubaflub whiteknight: yeah, i think a bit of it can be cleaned up with your vectorized / parameterized tests 19:45
whiteknight: both GMP and Math::GMPz come with test suites but i couldn't harvest them in a sane way. so for now i'm rolling my own.
plobsing pmichaud: fwiw, I think NQP is much better equipped to build an NCI layer than Parrot. To get a rich NCI layer (as opposed to the minimal approach taken by Parrot), you really need a type system (which is a luxury NQP has, but Parrot lacks).
whiteknight parrot will have it eventually 19:46
or, at least 6model
and I hope we build something nice on top of that
pmichaud plobsing: that's what I've been thinking also. Having seen the way zavolaj does its thing, I think NQP is much better equipped to handle it for us. 19:48
19:55 cotto left 20:07 cotto joined
Coke yawns 20:09
20:11 mtk joined 20:14 mtk left 20:15 mtk joined 20:20 cotto left
dalek rrot-gmp: 6a08506 | bubaflub++ | / (2 files):
updates to README and TODO
 20:20
rrot-gmp: e302457 | bubaflub++ | README.md:
markdown is a fickle wench
 20:22
bubaflub pmichaud: the README has been updated with hopefully some more useful information. lemme know if anything is unclear. 20:23
20:24 bluescreen left
whiteknight it seems like it would have been extremely helpful for GMP to include a list of exported functions in a YAML file somewhere, or something 20:39
20:40 mj41 joined, dodathome left
bubaflub whiteknight: agreed. would have saved me from hacking together those scripts. 20:41
whiteknight so basically your project is to hack together those scripts, and then write tests to verify that the output works? 20:44
bubaflub whiteknight: well, to get GMP bindings into parrot - those scripts were the laziest way to do it. 20:45
whiteknight: do you think the project should cover more? i'll probably have some extra time to expand the deliverables 20:56
whiteknight bubaflub: if you have lots of extra time, we should definitely talk about expanding the project. Let's not assume that everything is going to be smooth sailing though 20:57
that is, no need to plan for time we don't know if we're going to have
bubaflub whiteknight: towards the bottom of my proposal (www.google-melange.com/gsoc/proposa...ubaflub/1) i mention of few extras i could do if i have extra time; but those are mostly random thoughts. i'm open to doing what would be most useful. 20:58
whiteknight bubaflub: right. We have to see what would be most useful, as a function of what you get done (and what quality it is), how much time you have left, what kinds of experience you've generated, etc 21:01
When you start getting closer to the finish line, we'll meet up with dukeleto and chat about it 21:02
bubaflub sounds good.
whiteknight We'll put you to work in the salt mines if we have to 21:03
bubaflub hooray
whiteknight it's actually not as bad as it sounds 21:07
and hey, all the free salt you can eat!
bubaflub who doesn't love salt? 21:08
whiteknight my grandfather and his heart doctor 21:09
but other than that, nobody I'm aware of
bubaflub slugs
whiteknight yeah but they don't like beer either. I think they're just being picky 21:11
picky, slimey, and invertibrate
21:21 pjcj left 21:23 soh_cah_toa joined
soh_cah_toa ~~ 21:23
whiteknight hello soh_cah_toa
21:23 cotto joined
soh_cah_toa whiteknight: hey 21:23
whiteknight: i've heard you mention that the PARROT_CALLIN_* macros should be removed. what are they used for? are they similar to EMBED_API_CALLIN? i'm just curious 21:31
whiteknight soh_cah_toa: in theory, yes. The PARROT_CALLIN_START macro sets the stacktop pointer for the GC 21:35
the GC walks the stack looking for valid pointers. Since the stack grows linearly, you set a stack top pointer when you call in to Parrot, and when the GC runs it takes a pointer from where it is on the stack. Then, it traces between the two pointers 21:36
bubaflub and if your pc ever goes out of those bounds i guess you know something is screwy, right?
whiteknight the problem is, 99% of the extending API doesn't use those macros, so they are obviously not necessary
and if the stack top pointer isn't set, you probably shouldn't be using the extending API anyway. You are probably embedding 21:37
or, doing something else weird
soh_cah_toa is the "stack top pointer" kinda like %esp in x86 machines?
whiteknight the EMBED_API_CALLIN macros were originally modeled after PARROT_CALLIN_START. They also set the stack pointer 21:38
soh_cah_toa: exactly that, yes. Except we can't read ESP directly
soh_cah_toa ok
whiteknight so we create a variable on the stack, and do & address-of it
you're familiar with how the C system stack works?
soh_cah_toa yes 21:39
whiteknight okay, so it's all easy. Every time you call a function you push a new stack frame onto the stack. It's basically just a big array in memory
soh_cah_toa yeah
whiteknight so if you have a pointer on one side, and a pointer on the other side, you can loop over everything in between
soh_cah_toa right, between %ebp and %esp 21:40
whiteknight right, EBP and ESP define the stack frame for the current function
well, EBP, ESP, and some constants that the compiler generates
the frame basically goes from EBP to ESP+MAX_OFFSET 21:41
soh_cah_toa ah ok. didn't know about MAX_OFFSET
whiteknight er, no. I have that backwards
it is between EBP and ESP, right. ESP gets decremented to add space for locals
soh_cah_toa right 21:42
whiteknight Heh, I could talk about this forever. I've actually written a book about it :)
tadzik oh, assembly :)
whiteknight: what book?
soh_cah_toa o rly?
indeed, yes. what book?
whiteknight en.wikibooks.org/wiki/X86_Disassembly
that was several years ago, so I'm sure some of it has changed 21:43
tadzik looks for Kindle version
soh_cah_toa very nice. i love x86 assembly
tadzik that could help my potential C compiler :) 21:44
soh_cah_toa you sure do write an awful lot :) 21:45
whiteknight it's a disease
tadzik hm?
whiteknight back in college, I used to write wikibooks for all my notes. It was how I studied
every class I took, there was a corresponding wikibook for it 21:46
soh_cah_toa wow
whiteknight at one point, I had the most edits of anybody on the site. I'm sure people have passed my number though
Yeah, apparently I only had 47,480 edits. I'm sure that's been passed by now 21:47
21:47 Patterner left, PurityControl joined 21:48 PurityControl is now known as Patterner
soh_cah_toa so back to PARROT_CALLIN_*...what do you mean by "calling in to parrot"? 21:49
whiteknight soh_cah_toa: there are two environments. There's ordinary C code with ordinary C semantics, and Parrot-enabled C code with Parrot stuff 21:54
soh_cah_toa right
whiteknight in Parrot-land, we can throw and catch exceptions, we have CallContexts around which can hold data, we have a GC IN UR MEMORY, READIN UR DATAZ
etc
Moving from outside-parrot to inside Parrot is a "call in", and we need to set all that stuff up. 21:55
soh_cah_toa ah, i see
whiteknight the opposite direction is a "call out", and we need to tear all that stuff down
So every time you use the embedding API, we need to set up an exception handler of last resort, check that the interp isn't null, check that the stacktop pointer is set correctly, etc
check out the definitions of PARROT_EMBED_CALLIN in src/embed/something.h 21:56
I can't remember what it's called
soh_cah_toa ok
whiteknight maybe src/embed/private.h
anyway, I have to go catch a train. I'll be back on later tonight 21:57
soh_cah_toa sure
see ya later
21:57 whiteknight left 22:08 masak left 22:16 alester left
cotto slides for my talk at mksig.org/talks/osb11 22:27
bubaflub plobsing: ping
tadzik cotto: s/CLI/CLR/ on #14? 22:36
cotto tadzik, CLR is part of the CLI 22:38
I'm not 100% on the distinction though
showtime 22:39
tadzik I see
22:42 mj41 left 22:44 pjcj joined
sorear CLI is the entire offering, including libraries, an assembler and disassembler, not sure if the C# compiler is also counted 22:44
CLR is just the VM
plobsing bubaflub: pong 23:28
bubaflub plobsing: i've got two NCI questions if you've got a moment 23:29
plobsing ok shoot
bubaflub plobsing: first, the 1,2,3 and 4 signatures - were those int-types or pointer to int types? 23:30
plobsing they were pass-by-reference integer types
and there was never a '1' type
bubaflub plobsing: ok. so to replace them i can just use a StructView with one slot holding the correct item, right? 23:31
plobsing: and instead of a 2 or 4 it would just be a 'p' 23:32
plobsing bubaflub: you could, but that would be wasteful. better would be to use the DATATYPE_REF_FLAG pass-by-reference functionality
bubaflub plobsing: i've never heard of that; is there an example somewhere i can look at?
plobsing I used it in the PCRE bindings 23:33
bubaflub plobsing: ok, great.
plobsing: second question. in the GMP docs there are a few functions that appear to take any number of parameters, which i didn't think C could do. 23:35
plobsing: for example, Function: void mpz_inits (mpz_t x, ...) - Initialize a NULL-terminated list of mpz_t variables, and set their values to 0. 23:36
plobsing oh varargs. those are fun. 23:37
and by fun, I mean the opposite
bubaflub plobsing: ah, i reckon'd.
23:37 cotto left
bubaflub plobsing: does our NCI system handle varargs? 23:37
plobsing: it's not totally essential that it does, i'm just curious.
plobsing bubaflub: the magic of varargs is that you just call the function with the signature you want, and the callee is responsible for decoding it 23:38
so in one sense, NCI does not support varargs; but in another sense, varargs is supported by anything that supports the other aspects of the calling convention 23:39
bubaflub plobsing: ah, ok. so i'm thinking like a printf type thing - we just call it with whatever we want.
plobsing bubaflub: exactly. so you'd have to bind the function multiple times to get different signatures, but it is possible to call it. 23:40
bubaflub plobsing: ok, so we just do a dlfunc for a different signature each time
plobsing bubaflub: there are ways you could avoid the dlfunc (which may or may not be relatively costly)
$P0 = new ['NCI']; $P0[signature;of;fn] = ptr_to_fn; $P0(args) 23:41
23:42 losinggeneration joined
plobsing or something like that. it has to do with keys and pointers somehow. 23:42
23:42 cotto joined
bubaflub plobsing: ok, that makes sense. should some of this stuff go into NCI::Utils? 23:42
this stuff = var args helper
plobsing theres some docss on how it works in src/pmc/nci.pmc 23:43
cotto ~~
bubaflub plobsing: ok great.
plobsing: thanks, i need to run for now but i'll be pestering you again about NCI stuff.
23:44 lg_quassel left
plobsing bubaflub: if you come up with an easy way to handle varargs, yes, put it in the helper lib. also let the world know, because AFAIK, both the ruby and python FFI systems suck at varargs 23:44
in terms of ease of use
bubaflub plobsing: haha, will do.
23:44 whiteknight joined
whiteknight good afternoon, #parrot 23:47
23:54 cotto left 23:55 theory 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!