Parrot 4.5.0 "Buff-faced Pygmy Parrot" | parrot.org/ | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 29 June 2012.
00:05 whiteknight joined 00:15 UncleFester6 joined
UncleFester6 Anyone happen to know if parrot release tar balls happen to be made under win32 or anything else special or unusual? 00:20
whiteknight good evening, #parrot 00:21
UncleFester6: the tarballs are made under linux
There's a separate packaging project for win32. I have to look it up
UncleFester6 whitenight: the ordering of some files looked off for linux but I am interested in your answer ... 00:22
whiteknight msg benabik Congratulations! Hope all is going well. Do your best to get any sleep you can get, and don't worry about parrot at all for a few days
aloha OK. I'll deliver the message.
UncleFester6 whiteknight: oh sorry - I don't need the packaging project for win32 - thanks anyway 00:23
whiteknight sourceforge.net/projects/parrotwin32/
There it is anyway
UncleFester6 pmichaud: the parrot tarball builds ok on cygwin and doesn't have the missing phony.exe problem. If they put it together under linux - wondering what they do right ... 00:26
00:53 kid51 joined 01:29 UncleFester6 left 03:07 bacek_at_work joined
bacek_at_work ~~ 03:08
03:36 fperrad joined
pmichaud I'm looking at updating the release guides for Rakudo, Rakudo Star, and NQP, and have a question about Parrot releases: 03:58
Is Parrot still doing the "supported" versus "developer" release policy in any real way? (more)
More directly, if a Rakudo release has a choice between a supported and developer release for its "minimum version", should it always choose the supported release, the earlier release, or the later one? 03:59
As a more concrete example, the 2012.06 release of Rakudo could build on either Parrot 4.4.0 or 4.5.0. Our traditional release policy has been to always bump our minimum release to the latest released Parrot (either supported or developer); I'm wondering if we should bump only if we really need a later version of Parrot. 04:01
suggestions and opinions welcomed.
07:04 brrt joined 07:56 lucian joined 10:19 Psyche^ joined 11:30 lucian joined 12:47 whiteknight joined 12:54 PacoAir joined
brrt oh, hey, andrew is awake 13:08
i'm so very near to fixing everything
please help me out :-)
moritz ooo, world peace in 10 minutes! :-) 13:09
brrt i need to wrap a Parrot_Hash into an appropriate Parrot_PMC
well, my own localized version if anyway
s/if/of it/
and i need it to /not/ use the Parrot_api_* functions 13:10
whiteknight good mornign, #parrot
hello brrt
brrt hello
whiteknight There is a Hash PMC which already wraps a HASH* 13:11
brrt ... yes
so
whiteknight or, Hash*, or whatever it's called
brrt how to make such a thing
whiteknight in winxed? var hash = {}; 13:12
brrt yes
whiteknight or var hash = new 'Hash'
brrt but, in C
w/o using parrot_api functions
as they are evil and clear my jumpbuf
whiteknight PMC * hash = Parrot_pmc_new(interp, enum_class_Hash);
brrt oh, that is so obvious
thanks
i suppose
whiteknight src/pmc.c contains functions for allocating them
the enum_class_* constants are generated and hard to find, but they follow a clear naming convention 13:13
moritz brrt: so you're using the embedding API by now?
whiteknight if you just want a Hash*, you can use Parrot_hash_new() or something like that from src/hash.c
brrt moritz: basically, i'm using the 'new' embedding api as far as i can
basically, i call an nci function which is supposed to return a PMC which contains a hash 13:14
whiteknight you use the embedding API in the embedding situation (Apache module calling into Parrot). Once you're in parrot, you use the normal internal subsystem apis
brrt right, what whiteknight++ said
moritz ok, then I think I've mixed up the two
I'm just familiar witth the internal subsystem apis (which nqp's and rakudo's C code uses) 13:15
whiteknight brrt: using NCI to call Parrot_pmc_new() to get a Hash is exactly the same (but a little slower) than just using var x = {};
moritz: yes, that's the "internal" API
brrt right, but it also has access to request_rec and apr_table_t and all that
w/o me mucking about
with a thousand NCI calls and structviews 13:16
whiteknight or, you're writing a C wrapper to do all that stuff?
brrt ehm, i think we're going babylonic here a bit
what I am doing:
moritz better babylonic than barbaric :-) 13:17
brrt * startup my handler
* create a parrot
* load my 'loader'
* wrap my request_rec as a pointer
* pass it
GO
so the point is to get all possible data from this request_rec structure
as far as IO is concerend
this works absolutely wonderfully 13:18
github.com/bdw/mod_parrot/blob/mas...che.winxed is how that works
however, i also need to get the request parameters
what i used to do is pre-make these into a Parrot-hash structure 13:19
ehm, Parrot_PMC with class hash
which gets fairly clunky pretty quickl
y
so, i wrapped those
these 'request parameter hashes' are constructed on demand 13:20
i.e., you call apache.input.headers() and it calls NCI to get down to my module and make that hash
however, what happens is that it used the Parrot_api_* functions, and as whiteknight explained, these functions are not reentrant 13:21
and moreover clear the api_jmp_buf value upon return
now, this last value is needed for the parrot embedding api to return correctly when an error occurs
moritz so now you segfault on error? :/ 13:22
brrt nope
that would have been somewhat better because in that case, I'd get a stack trace much more easily
it just exits with an error code (1)
however, if i avoid the 'external' api (and use the internal api) my api_jmp_buf is never cleared 13:23
my errors return to where they come from 13:24
and i can safely argue about world peace again
whiteknight the internal API is much richer and more full-featured anyway
brrt it is actually pretty nice
moritz aye; use it whenever you can
brrt just, large
whiteknight yes
that's why the embedding API can only ever be just a subset
brrt which is ok and i get that point
its really important in fact to keep it small 13:25
whiteknight basically, you're just after a way to read parameters from apache into a Parrot hash lazily 13:26
brrt yes 13:27
because (in theory)
not all requests need all of them
whiteknight right
brrt ... now that i do use the 'internal' api 13:28
whiteknight right
brrt interating over hashes becomes plausible too
(within C)
pandora's box is open so to speak
whiteknight right 13:29
what's the apache API function for extracting out one of those parameters? 13:30
13:34 bluescreen joined
brrt well, request_rec is a struct 13:35
but most of its values are structs
a 'Hash' in apr speak is an apr_table_t
whiteknight okay, so how do you read a value out of that? 13:36
brrt you get its values as an apr_array_header_t of apr_table_entry_t via apr_table_elts
whiteknight ok 13:37
brrt doing that all via NCI is possible - ish
whiteknight but it sounds like a huge waste of time
brrt yet
yes
especially as compared with the current solution
github.com/bdw/mod_parrot/blob/mas...t_io.c#L20 and 13:38
github.com/bdw/mod_parrot/blob/mas...t_io.c#L57
are both relatively simple
whiteknight NCI has a certain amount of overhead itself, so doing things lazily through NCI might not save you anything in terms of performance 13:40
I'm not saying it can't, but it's worth benchmarking if you really want to squeeze out performance
Coke wonders if the evil exiting parrot has an exception handler for dealing with the thrown exceptions. 13:41
whiteknight it exits when it has no handlers. That's the absolute last resort of the exceptions system 13:45
it looks for handlers. If none, it tries to jump back out to the API. If not, it exits
Assuming you're using the API correctly, it should never ever ever get to that third option 13:46
brrt yes, point it out 13:55
i'm not really looking for performance gains
what are a few 100 cycles w/o disk lookup to a modern processor 13:56
basically, of all the web servers of the world, fewer than .001% are cpubound
... thart might not be true considering how many servers google has 13:57
but for the internet outside of google
i think it holds
whiteknight yes 13:58
brrt so, in short 14:01
code easiness is much more important to me :-)
whiteknight it is a motivation I agree with 14:03
moritz ... until it becomes a hot path :-) 14:04
but yes, simplify first, optimize later
whiteknight well, sure. But having a good design helps refactoring later
moritz brrt: are your questions answers?
*answerd
whiteknight and having a good interface prevents those refactors from reaching out into other places
moritz *answered
brrt yes, answered 14:05
well, almost
but i need to experiment a bit for my next questions, if any at all 14:06
lucian allison: ping 14:18
14:25 dmalcolm joined 15:48 alester joined 16:03 brrt left 16:26 jashwanth joined
dalek kudo/nom: 58d9852 | pmichaud++ | src/core/IO.pm:
Update IO.s to return file size.
 17:12
17:12 davidfetter joined
17:34 lucian joined 17:43 contingencyplan joined 17:49 wagle_ joined
cotto ~~ 17:49
dalek kudo/nom: 6ec88fa | duff++ | src/core/Main.pm:
Set $PROCESS::ARGFILES after command line processing
 17:56
allison lucian: pong 18:10
lucian allison: hi. i need some references for a job. would you be willing to be one of my referrers? 18:12
allison lucian: absolutely! 18:13
lucian allison: thanks :) i've been made an offer and accepted, but apparently it's conditioned on satisfactory references. i don't know if that's common practice or not
allison lucian: let me know if you need any extra info
lucian: yeah, I've had that a few times 18:14
lucian: (I guess it's less trouble than checking the references on all the applicants)
lucian yeah, probably
allison: i'll just tell them your name, email and wikipedia page :) 18:15
allison: if they want more, i'll let you know. thanks!
18:48 nopaste joined 18:49 TonyC joined 19:29 Hunger joined 19:56 fperrad joined 20:02 brrt joined
brrt apparently 20:09
it works :-D
(where it means, making hashes with the internal api) 20:10
whiteknight nice! 20:16
brrt++
commit, push, and go grab a drink
brrt drink has been grabbed 20:17
dalek d_bart: 58c40f8 | (Bart Wiegmans)++ | / (5 files):
proof of concept for making hashes
 20:19
whiteknight and as soon as you're done the drink, move on to the next TODO item 20:21
no rest for the weary!
20:25 lucian joined
brrt :-) i've already found that todo item 20:35
20:38 fperrad joined
brrt is there a guide to writing correct c function type definitions? 20:41
oh, nm, google found it 20:42
.. you know what 21:19
iterating over hashes
is for suckers 21:20
brrt leaves & 21:26
21:26 brrt left 23:34 whiteknight joined
whiteknight good evening, #parrot 23:47

Powered by Cro and the Raku® Programming Language.

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

Thank you!