Re: NCI 'v' vs '' in function parameter signatures
Any news on this? Is it okay? Should I send it via parrotbug? Tim. On Tue, Feb 28, 2006 at 03:36:20PM +, Tim Bunce wrote: On Tue, Feb 14, 2006 at 10:04:59PM +0100, Leopold Toetsch wrote: On Feb 14, 2006, at 18:29, Tim Bunce wrote: The runtime dlfunc code will need to be altered to normalize away the trailing v so old code won't break. Should it warn about that? Yes, a warning please. Here's the patch. - removes 'v' argument entries from src/call_list.txt - adds mysqlclient signatures to src/call_list.txt [*] - tweaks docs/pdds/clip/pdd16_native_call.pod to match - adds list of definition files used into generated nci.c - adds sanity checking of return and argument sig chars - adds compile time warning for deprecated 'v' argument - adds optional duplicate signature warning (disabled) - adds runtime warning for deprecated 'v' argument Tim. [*] I'm planning a followup patch that splits src/call_list.txt into multiple files in a subdirectory. The mysqlclient defs would then be in their own file. With the current arrangement no one can safely remove a signature because there's no indication of what that signature exists for. The same ncidef file could then be used for both tools/build/nativecall.pl and tools/util/ncidef2pasm.pl (which I also plan to work on). Any objections or comments? Index: src/call_list.txt === --- src/call_list.txt (revision 11741) +++ src/call_list.txt (working copy) @@ -49,14 +49,12 @@ c# t/pmc/nci.t cp cpi -cv d# t/pmc/nci.t dd dJOd # Parrot builtins I JOS S JOS # ParrotIO.readline -dv IJI # Parrot_is_char_* v JOSP # String.trans v JOS # String.reverse @@ -83,7 +81,6 @@ f# t/pmc/nci.t fff # t/pmc/nci.t fis -fv i ib# t/pmc/nci.t @@ -148,7 +145,6 @@ i it iti -iv i4 i4i i42p @@ -160,7 +156,6 @@ lpi lpii lp33l -lv l33l PJi # Needed for parrot threads @@ -185,10 +180,8 @@ pt ptpp pttt -pv s # t/pmc/nci.t -sv t # t/pmc/nci.t ti @@ -200,7 +193,6 @@ tt ttl4 tt4 -tv v vJiiip# examples/japh/japh11.pasm @@ -215,7 +207,6 @@ vp vpl vpp -vv # These are needed for parrotio.pmc iJP @@ -343,3 +334,77 @@ # Make lua stop panic'ing. P JOI + + +# --- start mysqlclient library --- +# Created from mysql.h using the following manual method: +# Edited copy of mysql.h using vi by doing g/, *$/j (repeat) then g/\* *$/j (repeat) +# to get all functions on one line each. +# Extracted list of api func names from http://dev.mysql.com/doc/refman/4.1/en/c-api-functions.html +# and copied to a temporary file to clean up (mysql_api_names.txt) +# Stripped down to bare names and merged into one line separated by | +# then egrep -w `cat mysql_api_names.txt` mysql.h mysql_api.ncidef +# then edit mysql_api.ncidef in vi: %s/^/ # / +# to create space for nci signatures and to use original definition as a # comment. +# This method isn't ideal, I'm just noting it here in case it helps others. +# Ideally the process should be automated - but there be many dragons along # that path. +# +# long long values (my_ulonglong) aren't handled by nci - spec'd as just long for now +# +#MYSQL_FIELD and MYSQL_RES are structs +#typedef char **MYSQL_ROW; /* return data as array of strings */ +#typedef unsigned int MYSQL_FIELD_OFFSET; /* offset to current field */ +#typedef MYSQL_ROWS *MYSQL_ROW_OFFSET; /* offset to current row */ +# +l p #! my_ulonglong mysql_num_rows(MYSQL_RES *res) +i p # unsigned int mysql_num_fields(MYSQL_RES *res) +c p # my_bool mysql_eof(MYSQL_RES *res) +p pi # MYSQL_FIELD *mysql_fetch_field_direct(MYSQL_RES *res, unsigned int fieldnr) +p p # MYSQL_FIELD * mysql_fetch_fields(MYSQL_RES *res) +p p # MYSQL_ROW_OFFSET mysql_row_tell(MYSQL_RES *res) +i p # MYSQL_FIELD_OFFSET mysql_field_tell(MYSQL_RES *res) +i p # unsigned int mysql_field_count(MYSQL *mysql) +l p #! my_ulonglong mysql_affected_rows(MYSQL *mysql) +l p #! my_ulonglong mysql_insert_id(MYSQL *mysql) +i p # unsigned int mysql_errno(MYSQL *mysql) +t p # const char * mysql_error(MYSQL *mysql) +t p # const char * mysql_info(MYSQL *mysql) +l p # unsigned long mysql_thread_id(MYSQL *mysql) +t p # const char * mysql_character_set_name(MYSQL *mysql) +p p # MYSQL * mysql_init(MYSQL *mysql) +i pt # int mysql_ssl_set(MYSQL *mysql, const char *key, const char *cert, const char *ca, const char *capath, const char *cipher) +c pttt # my_bool mysql_change_user(MYSQL
early draft of I/O PDD
We're going to try something a little different. With Chip's blessing I've written a very early draft of the PDD for I/O (not numbered yet). The attached PDD isn't a completed document with Chip's seal of approval, it's a seed for discussion. What I need from you all is comments. What's missing? What's inaccurate? What's accurate for the current state of Parrot, but is something you always intended to write out later? What thoughts have you had on how the I/O subsystem should work? All contributions cheerfully welcomed, from a single sentence to several pages of text. Chip won't be making design decisions during the conversation. He may not even participate much, since part of the point is to split the work into parallel tasks so we can get more done than is humanly possible for one person. I'll use the discussion to write up a more complete PDD (probably with a few alternatives written in), and then work with Chip to review/revise it. Thanks, Allison pddXX_io.pod Description: Binary data
Re: NCI 'v' vs '' in function parameter signatures
On Friday 03 March 2006 02:41, Tim Bunce wrote: Any news on this? Is it okay? Should I send it via parrotbug? It looked good to me. I say check it in and see what the smokes do. -- c
Re: early draft of I/O PDD
How do you verify that a print succeeded? Currently there's no way to know. Throwing an exception if a global flag is set would suffice and wouldn't require constantly pushing exception handlers in case the program doesn't care enough (e.g. the run it and delete it variety). Plus using exceptions would probably make platform independence easier from PIR's standpoint as it won't need to know what the error code actually means, and the exception object can include a message saying so. As well, the lines of code can go straight from open to print to close without throwing in error checking after each opcode. Since that runs contrary to how most HLL's operate, I don't know how good of an idea it really is for parrot. The 'write' opcode does seem redundant, but what if it's changed to print to a user selected file stream? Just select the file stream with one opcode, and each write call after that will print to that instead of stdout. That's the best idea I can come up with to remove redundancy(without removing the opcode of course), even though I don't know if it'd be worth all the side effects. Concerning all the byte/character issues, all the string opcodes except bytelength work with characters. But the io subsystem currently only deals with bytes. I know there is the speed issue for things like reading with dealing with utf8, but something like 'peek' should probably be able to get the full character. Also, what's supposed to be the default encoding for all data read in from a stream where a layer's not added that explicitly states so? Ascii, binary? I don't think it's really been addressed, at least not recently, but what about IPv6? By the time perl6 becomes commonplace and used often(and thus, parrot), IPv6 will be common enough that problems could occur. Currently it's not speced or stated, aside from a comment in PIO_sockaddr_in. One more thing, what about specing directory handling? Nothing is speced yet for it. On Mar 3, 2006, at 1:27 PM, Allison Randal wrote: We're going to try something a little different. With Chip's blessing I've written a very early draft of the PDD for I/O (not numbered yet). The attached PDD isn't a completed document with Chip's seal of approval, it's a seed for discussion. What I need from you all is comments. What's missing? What's inaccurate? What's accurate for the current state of Parrot, but is something you always intended to write out later? What thoughts have you had on how the I/O subsystem should work? All contributions cheerfully welcomed, from a single sentence to several pages of text. Chip won't be making design decisions during the conversation. He may not even participate much, since part of the point is to split the work into parallel tasks so we can get more done than is humanly possible for one person. I'll use the discussion to write up a more complete PDD (probably with a few alternatives written in), and then work with Chip to review/revise it. Thanks, Allison pddXX_io.pod
Re: early draft of I/O PDD
With respect to async IO (regretfully I get to see a lot of this at $job): Each operation can be async, or sync, with a similar API. There should be enough hooks to be able to wait on a specific operation happenning on a stream, any operation on a stream, any operation on a group of streams, and any operation on any stream. The resulting set of operations should be optionally available, as this is one of the biggest sources of boilerplate in posix aio in C. aio_suspend (or a wrapper on top of it) should probably be the event loops default idle loop, and it should keep a flag raised such that if the aio event loop wrapper knows that an event that was not waited on finished, the user code can check on that easily. A possiblity for a unified AIO/SIO interface could be that each IO op returns an operation handle, and you can ask that handle about it's status (running, finished, error), get it's results from the handle, and also ask it to block. This could have a high overhead due to storage creation, but it's generally a pretty flexible and portable abstraction. On Fri, Mar 03, 2006 at 11:27:05 -0800, Allison Randal wrote: We're going to try something a little different. With Chip's blessing I've written a very early draft of the PDD for I/O (not numbered yet). The attached PDD isn't a completed document with Chip's seal of approval, it's a seed for discussion. What I need from you all is comments. What's missing? What's inaccurate? What's accurate for the current state of Parrot, but is something you always intended to write out later? What thoughts have you had on how the I/O subsystem should work? All contributions cheerfully welcomed, from a single sentence to several pages of text. Chip won't be making design decisions during the conversation. He may not even participate much, since part of the point is to split the work into parallel tasks so we can get more done than is humanly possible for one person. I'll use the discussion to write up a more complete PDD (probably with a few alternatives written in), and then work with Chip to review/revise it. Thanks, Allison -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me sushi-spin-kicks : neeyah pgpZFo6ugJnYZ.pgp Description: PGP signature
Fix for tailcall after newclosure
The tailcall op forces the old context to be recycled, which causes
mighty peculiar things to happen if the sub had created any closures,
since those closures still refer to the just-freed context. Sometimes
(but not always) the context is reused for the next call; when this
happens, it seems to lead to a situation where the context's outer_ctx
field points back to itself. This causes Parrot_find_pad to loop
without bound.
The attached PIR code illustrates the problem, if anyone cares to
check it out, but it may not work in other builds. Sometimes, small
changes to distant parts of this code prevent the context from being
reused immediately, forestalling the bug. Commenting out the assignment
to $P55 is one such change. But if you do try it, you may also want to
apply the src/sub.c part of the attached patch, since this prevents
unbounded looping. Enabling the ignored code also makes it clear what
is happening.
The src/sub.c fix is intended just for debugging, though. The
patch's minimal change [1] to src/ops/core.ops actually fixes the
problem, at the risk of possibly leaking memory, since I still don't
fully understand the life cycle of contexts. However, I would argue
that any such leaks are independent problems that also need fixing. If
there are no objections to this part of the patch, I will commit it
tomorrow.
I didn't turn the test case into a proper regression test because I
didn't think it would be reliable enough. Maybe a check that is
intermittent is better than none at all? On the other hand, changes to
the context allocator could render it permanently useless . . .
-- Bob Rogers
http://rgrjr.dyndns.org/
[1] Minimal even according to Shannon: It changes only a single bit in
the codebase. All that work for one lousy bit . . .
## Compiled by: $Id: mini-compiler.lisp,v 1.80 2006/02/26 23:02:55 rogers Exp $
.sub _main :main
debug 0x80
.lex MAIN-CONT, $P41
$I42 = 10
$P41 = new .Continuation
set_addr $P41, L2
goto L3
L2:
get_results '(0)', $P45
.return ($P45 :flat)
L3:
.const .Sub $P49 = ___internal_main_test_
newclosure $P48, $P49
.return _try_it($I42, $P48)
.end
.sub ___internal_main_test_ :outer('_main')
.param pmc arg1
print [in test]\n
find_lex $P41, MAIN-CONT
$P55 = new Undef
if arg1 != 3 goto L3
$P58 = arg1
$P59 = arg1
$P57 = n_mul $P58, $P59
set_args '(0)', $P57
tailcall $P41
L3:
print not
print arg1
print \n
.end
.sub _try_it
.param int n
.param pmc closure
$P42 = new Undef
$P42 = 0
goto L4
L2:
closure($P42)
$P42 = $P42 + 1
L4:
if $P42 n goto L2
.end
Index: src/ops/core.ops
===
--- src/ops/core.ops(revision 11783)
+++ src/ops/core.ops(working copy)
@@ -528,7 +528,7 @@
PObj_get_FLAGS(ccont) = ~SUB_FLAG_TAILCALL;
--ctx-recursion_depth;
ctx-caller_ctx = caller_ctx-caller_ctx;
- Parrot_free_context(interpreter, caller_ctx, 1);
+ Parrot_free_context(interpreter, caller_ctx, 0);
interpreter-current_args = NULL;
}
goto ADDRESS(pc);
Index: src/sub.c
===
--- src/sub.c (revision 11783)
+++ src/sub.c (working copy)
@@ -405,7 +405,12 @@
while (1) {
lex_pad = ctx-lex_pad;
outer = ctx-outer_ctx;
-if (!outer)
+#ifdef IGNORE
+fprintf(stderr, [Parrot_find_pad: looking in
+ctx %p pad %p for %p, outer %p]\n,
+ctx, lex_pad, lex_name, outer);
+#endif
+if (!outer || outer == ctx)
return lex_pad;
if (!PMC_IS_NULL(lex_pad)) {
if (VTABLE_exists_keyed_str(interpreter, lex_pad, lex_name))
