Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
I gave the talk at OSSBarcamp in Dublin last weekend and it went well. My sincere thanks to everyone who contributed. The slides are available at: http://www.slideshare.net/Tim.Bunce/perl-myths-200909 The graphs and stats charting the continuing growth of perl and the perl community were surprising (and delighting) even to me. The presentation was even featured on the slideshare.net home page for a while. Yeah! I'll be giving the talk again at HighLoad++ in Moscow in a couple of weeks time, and possibly again at IPW09 in Pisa later in October (though it's not been scheduled yet). So I'd be grateful for any feedback on the talk. Corrections, improvements, extra data etc. Thanks again! Tim. p.s. I've already fixed the suprious reference to CPANTS.
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
On Tue, Sep 15, 2009 at 12:15:10PM -0400, Nathan Gray wrote: On Mon, Sep 14, 2009 at 12:15:05PM +0100, Tim Bunce wrote: You can find my current draft at http://files.me.com/tim.bunce/65oikg (2.3MB PDF) page 73 - Haskell should be spelled with two Ls Thank you! I kept wondering if that was spelt right but never got round to checking. (The Mac's spell checker wan't to change it to Hassle :) Tim.
Looking for help updating Perl 6 and Parrot part of Perl Myths talk
I'm working on an update to my Perl - Baseless Myths and Startling Realities talk. (Which I'll be giving in Dublin, Moscow and Pisa in the few weeks!) I got great help on the Perl 5 portion of the talk when I asked via my blog http://blog.timbunce.org/2009/08/13/help-me-update-my-perl-myths-talk-for-2009/ but I've not had any input for the later slides on Perl 6 and Parrot. You can find my current draft at http://files.me.com/tim.bunce/65oikg (2.3MB PDF) It's worth reading just to see the great health and vigour of the Perl community. The updated CPAN graphs are quite amazing in themselves. I'd be grateful for feedback on any of the slides, but I'm especially interested in updates for: page 73 - Perl 6 implementations I've added Mildew, with links, to the SMOP line anything I should add / change / remove? What's the status of KindaPerl6? page 77 - quantity of code writen in Perl 6 are there any other significant perl6 codebases? page 80 - graph of parrot commits and releases I don't have a url for that graph. Do you? Is it maintained? Can anyone update it for me? Can anyone produce a similar one for rakudo? page 81 - size of parrot test suite I can update the basic number myself, but how many runcores are considered useful? page 85 - Rakudo test progress I've just updated this to the latest myself. Anything else I should add, change or remove? I'm especially interested in verifyable metrics showing effort, progress, or use. Ideally graphical. Any interesting nuggets that fit with the theme will be most welcome. Thanks! Tim.
Concurrency Features in JDK 7 (Work-Stealing)
These seem interesting and relevant here: http://www.ddj.com/go-parallel/blog/archives/2009/04/java_7_will_evo.html http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-5515.pdf http://www.infoq.com/news/2007/07/concurrency-java-se-7 Tim.
Re: For your encouragement
On Fri, Dec 05, 2008 at 11:11:30AM -0800, Geoffrey Broadwell wrote: On Fri, 2008-12-05 at 09:10 -0600, Andy Lester wrote: On Dec 5, 2008, at 4:13 AM, Simon Cozens wrote: I just ran this code, which worked with the expected results: Beautiful. Posted to Perlbuzz. http://perlbuzz.com/2008/12/database-access-in-perl-6-is-coming-along-nicely.html Someone needs to reply to the comments from readers who have confused DBI and DBDI, and have thus decided we are turning Perl into Java. I've just posted this as a comment... ---snip--- Re I think thats because DBI 2.0 uses JDBC as its API - that's not quite right in two ways. DBI 2.0 doesn't exist anywhere other than in my head and, so far, I've been unsuccessful in making time to actually work on it. JDBC as its API is a little misleading - DBI 2.0 uses JDBC as the *driver* API, i.e., the interface between the DBI and the underlying driver (DBD), not the interface between applications and the DBI. That's why Simon's example looks like Java JDBC, and that's a very good thing. It means that he doesn't need me, or anyone else, to agree on the API or semantics. They're all specified in great detail in the JDBC docs and the JDBC test suite. Anyone wanting to follow Simon's example can work to the same well defined standard API. There are two main areas of concern though: 1. There may be subtle issues in how data types and calling conventions translate between Java and Parrot/Perl6. 2. JDBC is a big API, effort should be made to factor out as much code as possible into modules that can be shrface between applications and the DBI. The [EMAIL PROTECTED] (note the 'i' in dbdi) mailing list is a good place to discuss these and related issues. Email [EMAIL PROTECTED] to subscribe. ---snip--- There's an archive at http://www.mail-archive.com/[EMAIL PROTECTED]/index.html which shows almost no activity since Feb 2004. It would be great to get some life into it. Tim.
SquirrelFish (was: Dynamic Languages Strike Back)
On Tue, May 27, 2008 at 08:51:24AM +0200, François Perrad wrote: FYI a recent talk http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html Which ties in nicely with the announcement of SquirrelFish yesterday: http://webkit.org/blog/189/announcing-squirrelfish/ ---snip--- What Is SquirrelFish? SquirrelFish is a register-based, direct-threaded, high-level bytecode engine, with a sliding register window calling convention. It lazily generates bytecodes from a syntax tree, using a simple one-pass compiler with built-in copy propagation. SquirrelFish owes a lot of its design to some of the latest research in the field of efficient virtual machines, including research done by Professor M. Anton Ertl, et al, Professor David Gregg, et al, and the developers of the Lua programming language. Some great introductory reading on these topics includes: The Structure and Performance of Efficient Interpreters http://citeseer.ist.psu.edu/cache/papers/cs/32018/http:zSzzSzwww.jilp.orgzSzvol5zSzv5paper12.pdf/ertl03structure.pdf (Introduces the fundamentals of virtual machine design and explains the importance of direct threading) Virtual Machine Showdown: Stack Versus Registers http://www.sagecertification.org/events/vee05/full_papers/p153-yunhe.pdf (Details the benefits of register machines, and the importance of copy propagation) The Implementation of Lua 5.0 http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/jucs05.pdf (Outlines the implementation of a real-world register-based bytecode engine, with a sliding register window calling consign to ---snip--- I'd guess there's some useful ideas in there. Tim.
Re: parrot benchmarking
On Wed, Apr 16, 2008 at 12:10:54AM +0200, Leopold Toetsch wrote: Am Freitag, 11. April 2008 21:02 schrieb Nuno 'smash' Carvalho: Greetings all, I just posted a little Parrot benchmark in my use.perl's journal Just a reminder: Please don't use unoptimzed builds for benchmarking. I agree with Geoffrey that optimized builds should be the default. For example, chromatic posted a blog recently that said: (http://www.oreillynet.com/onlamp/blog/2008/04/multiple_dispatch_now_please.html) Download the new Parrot release next Tuesday, 15 April 2008, then type: $ perl Configure.pl $ make $ make perl6 ... and you too can play with this in your own code. Anyone doing that is likely to get a poor impression of performance. I'd suggest a simpler approach than Geoffrey's: The default 'make' target could default to a reasonably safe portable optimized target, but be overridable by an env var. That way curious end-users and benchmarkers get good performance by default. Possibly not the ultimate, but far better than now. Developers working on parrot (wanting unoptimized/debug quick builds) would just need to set an env var in their .profile, for example, and carry on as now. No changes in their procedures, and no changes in the docs (other than to mention the env var). Then chromatic's recipie works well for all. Tim.
Re: Status of docs/embed.pod and Parrot::Embed?
On Mon, Dec 10, 2007 at 04:37:31PM +0200, Allison Randal wrote: Tim Bunce wrote: I meant docs/pdds/draft/pdd10_embedding.pod I could trying hacking on it to at least mention all the functions in embed.h with a few words on each. I'd be fumbling in the dark mostly but it would at least push the document along for others to review later. This was a partial first draft written by chromatic. The extending/embedding PDD's aren't on the core list of milestones, so I don't have a specific date when I'm planning to work on it. It probably makes the most sense to repeat the group drafting strategy we're using with the PIR PDD. You and others can help pull together the draft PDD, and I'll review/revise/approve it as it reaches a relatively solid state. We can also also talk back and forth about ideas on the mailing list as it solidifies. There are two parts of the group drafting task: documenting how the system works now, and documenting how you would like it to work. Documenting the functions in embed.h is a great place to start. At the moment, chromatic or I would start exactly where you'll be starting: sitting down with the code, extracting a list of current functions/features, and at the same time keeping an eye out for missing features, misfeatures, or other places in need of improvement. So, if you or others are willing to take a first stab at it, it would be enormously helpful. (It's also a great way to gain experience with parrot.) Sounds good. I added a tool to check the coverage of the embed.h API: $ perl tools/check_embed_coverage.pl ../../include/parrot/embed.h Embed.xs 20 out of 25 Parrot_* functions in ../../include/parrot/embed.h not used in Embed.xs: Parrot_clear_debug Parrot_clear_flag Parrot_clear_trace Parrot_debug Parrot_disassemble Parrot_exit Parrot_init_stacktop Parrot_run_native Parrot_runcode Parrot_set_config_hash Parrot_set_debug Parrot_set_flag Parrot_set_run_core Parrot_set_trace Parrot_setup_argv Parrot_setup_opt Parrot_setwarnings Parrot_test_debug Parrot_test_flag Parrot_test_trace I'd appreciate some guidance on what interfaces are most stable / least likely to change / most useful so I can prioritise my time. Similarly it may help Jeff prioritise work on PDD10 as more spec detail would help me write some tests. Meanwhile there's some housekeeping I can be getting on with. Like fixing the broken Makefile.PL (seems best to make it a wrapper for the working Build.PL) Actually, what we'd like to do is eliminate the Module::Build dependency, and integrate the build process for Parrot::Embed into Parrot's build process (which is all Makefiles). chromatic wrote Parrot::Embed as an independent CPAN module, but with the need to always have a version of Parrot::Embed that's compatible with the version of Parrot you have installed, we'll ship them together. (It may also be dual-life'd on CPAN, that's one of the open design questions.) So should I just delete the Build related files? Tim.
Re: Status of docs/embed.pod and Parrot::Embed?
On Tue, Dec 11, 2007 at 11:20:39AM +0200, Allison Randal wrote: Andy Armstrong wrote: Where might a volunteer start? I also promised Yuval that I'd refactor Test::TAP::Model to use Test::Harness 3.00 - so to some extent I've answered my own question - but I'd like to get my hands dirty with Parrot proper too. There's a tricky spot at the very beginning where you need to learn just enough about the internals to solve one problem/accomplish one task. From there, it's just a matter of expanding your knowledge outward to accomplish the next task. We don't have an exact science for getting new contributors through that first bit. Even excellent documentation (which we don't have yet), isn't quite enough to carry contributors from thinking to doing. What seems to work the best is if you pick a task or problem that's interesting to you, for whatever reason. The interest and curiosity keeps you motivated through the first task. Everyone's different, so the tasks that interest you won't be the same as the tasks that interest me or the next new contributor. Sometimes at hackathons I've gone through the ticket queue with new contributors until I see their eyes light up at a particular task. I know that's where they should start. Perhaps new contributors could make notes about stumblings blocks encountered along the way, so we know where to put signposts for others who follow. Tim.
Re: Status of docs/embed.pod and Parrot::Embed?
On Mon, Dec 10, 2007 at 09:59:40AM +, Tim Bunce wrote: Also, what's the status of docs/embed.pod? It seems out of date and/or imcomplete (no mention of Parrot_call_sub, for example). I meant docs/pdds/draft/pdd10_embedding.pod I could trying hacking on it to at least mention all the functions in embed.h with a few words on each. I'd be fumbling in the dark mostly but it would at least push the document along for others to review later. Tim.
Status of docs/embed.pod and Parrot::Embed?
I'm interested in doing some work on Parrot::Embed. So I'm wondering what state it's in and if there are any short term plans for it. Any good reason it's not part of the normal build/test cycle? Also, what's the status of docs/embed.pod? It seems out of date and/or imcomplete (no mention of Parrot_call_sub, for example). I'm very much a novice with parrot. So my preferred approach for now would be for someone more knowledgeable (Allison, chromatic, ...) to lead the way by updating/expanding the docs/embed.pod specification. I'll update/expand Parrot::Embed in sync and address the items in the TODO file along the way. Sound okay? Meanwhile there's some housekeeping I can be getting on with. Like fixing the broken Makefile.PL (seems best to make it a wrapper for the working Build.PL) Tim.
Interfacing parrot with the new Java Scripting API
Could someone familar with parrot take a look at the Java Scripting API (aka JSR223) and let us know how much work would be involved in adding support for it to parrot? See https://scripting.dev.java.net/ and http://java.sun.com/javase/6/docs/technotes/guides/scripting/index.html Something to watch out for is that many of the examples assume the scripting language is itself implemented in Java. That's true of most of the scripting engines listed on https://scripting.dev.java.net but it's not essential. The most relevant example for parrot is probably http://jepp.sourceforge.net/ - Jepp embeds CPython in Java The detailed JSR223 specs, for users and implementors, can be found here: http://jcp.org/aboutJava/communityprocess/final/jsr223/index.html It would be an understatement for me to say I think integration with Java could be very beneficial for parrot. Think JDBC for a start. Tim.
Re: Perl 6 Microgrants. Now accepting proposals.
On Wed, Mar 21, 2007 at 11:04:29PM -0400, Jesse Vincent wrote: I'm pleased to announce the inaugural Perl 6 Microgrants program. Best Practical Solutions (my company) has donated USD5,000 to The Perl Foundation to help support Perl 6 Development. Leon Brocard, representing The Perl Foundation's grants committee, will work with me to select proposals and evaluate project success. We'll be making USD500 grants to worthy Perl 6 related efforts. We're hoping to fund a range of Perl 6-related projects over the life of the grant program. Accepted grants might be for coding, documentation, testing or even writing articles about Perl 6. The program isn't tied to any one implementation of Perl 6 -- We're interested in seeing proposals related to Pugs, Perl 6 on Parrot, Perl 6 on Perl 5 or any other Perl 6 implementation. Generally, we're interested in seeing projects that can be completed in 4-6 calendar weeks. Submitting a grant proposal --- To submit a grant proposal, please email us at perl6- [EMAIL PROTECTED] with the following information: * A two to three paragraph summary of the work you intend to do * A quick bio - Who are you? Is there opensource work you've done that we should have a look at? * A brief description of what success will mean for your project - How will we know you're done? * Where (if anywhere) you've discussed your project in the past * Where you'll be blogging about your progress. (Twice-weekly blog posts are a requirement for getting your grant money) We'll be accepting proposals on a rolling schedule. We expect to pay out these first 10 grants over the course of the summer. Depending on how things go, we'll then either find more money for more grant programs or we'll wind up the program and move on to other endeavors. We're really excited to get rolling. Submit your proposals early and often. Don't let somebody else beat you to the punch ;) I'd like to suggest an idea for *someone else* to submit a proposal for: As part of the work on DBI2 I want to create a Perl API that closely matches the JDBC API. I need a tool that can parse the java .h files that that define the JDBC API, e.g., http://gcc.gnu.org/viewcvs/trunk/libjava/java/sql/Statement.h?revision=120621view=markup and generate roughly equivalent Perl 6 (roles etc). Some knowledge of Java would be helpful to get a reasonable initial mapping of concepts from Java to Perl, but that's bound to evolve over time - hence the need for a tool to do, and redo, the translation. [ I'd probably then use the tool to also generate implementation code that bridges the Perl6 JDBC with the Perl5 JDBC module on CPAN. That would give Perl6 a working JDBC API. (The next step might be to parse the Java code of the JDBC test suite and translate that to Perl6...) ] There are two parts to this: a Java parser (good enough for at least the JDBC .h files), and a Perl6 code (role) generator. They could be combined, but I'd like the Java parser to be reusable by others. Here's a related idea: write a tool that reads BNF grammar, such as http://java.sun.com/docs/books/jls/third_edition/html/syntax.html http://java.sun.com/docs/books/jls/third_edition/html/grammars.html and writes a parser in Perl 6 for that grammar. Anyone interested in those ideas? Tim. p.s. The .h files for JDBC can be found here http://gcc.gnu.org/viewcvs/trunk/libjava/java/sql/ http://gcc.gnu.org/viewcvs/trunk/libjava/javax/sql/ p.p.s. The funding for these could come from the DBI Development fund (which hasn't been used for anything yet) and so not impact the donation from Best Practical Solutions.
Re: PDD 22 - I/O release candidate 1
On Tue, Sep 26, 2006 at 04:44:53PM -0700, Allison Randal wrote: I've committed an updated I/O PDD. I'm close to pronouncing this ready to implement, so get in your comments now. One piece that is currently missing is a discussion of which lightweight concurrency model we're going to use for the asynchronous operations. I've had ongoing back-channel conversations with various people, but I need to congeal them. Pitch in your own 2 cents. Also, any reactions to the distinction that async ops return status objects while sync ops return integer error codes? Sync opcodes could have 2 signatures, one with an integer return type (int error code) and one with a PMC return type (status object). What's the relative cost of creating a PMC vs passing one in? I assume passing one in is significantly faster. If so, then perhaps speed-sensitive ops that are likely to be used in loops can be given the PMC to (re)use. Tim.
Re: [perl #39255] Revision 12862 fails tests on OS X
On Fri, Jun 02, 2006 at 09:35:00AM -0400, Will Coleda wrote: Per leo, As of r12867 this is fixed. Fixed for me. Thanks Leo! Tim. On Jun 2, 2006, at 8:24 AM, Will Coleda wrote: Known failures. Per Leo, failing tests were committed for these features to encourage development. We've tried to let head be usable for this long, we should probably have some kind of procedure for dealing with this this sort of development to avoid this sort of confusion. Thanks for the report! On Jun 1, 2006, at 11:56 AM, Tim Bunce (via RT) wrote: # New Ticket Created by Tim Bunce # Please include the string: [perl #39255] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39255 --- osname= darwin osvers= 8.0 arch= darwin-thread-multi-2level cc= cc --- Flags: category=core severity=critical ack=no --- Failed Test Stat Wstat Total Fail List of Failed - -- t/pmc/mmd.t2 512382 37-38 t/pmc/sub.t1 256491 47 t/pmc/mmdok 33/38 # Failed test (t/pmc/mmd.t at line 1228) # got: 'Called wrong multi # ' # expected: 'Called multi for class # ' t/pmc/mmdNOK 37 t/pmc/mmdNOK 38# Failed test (t/ pmc/mmd.t at line 1254) # got: 'error:imcc:The opcode 'invokecc_' (invokecc1) was not found. Check the type and number of the arguments # in file '/Users/timbo/perl/parrot/t/pmc/mmd_38.pir' line 15 # ' # expected: 'String:what # Int:23 # ' # './parrot --gc-debug /Users/timbo/perl/parrot/t/pmc/ mmd_38.pir' failed with exit code 18 # Looks like you failed 2 tests of 38. t/pmc/subok 37/49 # Failed test (t/pmc/sub.t at line 1178) # got: 'error:imcc:The opcode 'invokecc_' (invokecc1) was not found. Check the type and number of the arguments # in file '/Users/timbo/perl/parrot/t/pmc/sub_47.pir' line 7 # ' # expected: 'ok # ' # './parrot --gc-debug /Users/timbo/perl/parrot/t/pmc/ sub_47.pir' failed with exit code 18 --- Summary of my parrot 0.4.4 (r12862) configuration: configdate='Thu Jun 1 16:08:34 2006' Platform: osname=darwin, archname=darwin-thread-multi-2level jitcapable=1, jitarchname=i386-darwin, jitosname=DARWIN, jitcpuarch=i386 execcapable=1 perl=perl Compiler: cc='cc', ccflags='-fno-common -no-cpp-precomp -DDEBUGGING - pipe -I/usr/local/include -I/opt/local/include -pipe -fno-common - Wno-long-double ', Linker and Libraries: ld='c++', ldflags=' -L/usr/local/lib -L/opt/local/lib - flat_namespace ', cc_ldflags='', libs='-lm' Dynamic Linking: share_ext='.dylib', ld_share_flags='-dynamiclib -undefined suppress', load_ext='.bundle', ld_load_flags='-bundle -undefined suppress' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8 --- Environment: DYLD_LIBRARY_PATHHOMELANGLANGUAGE LD_LIBRARY_PATHLOGDIRPATHPERL5LIBPERLCRITIC PERLTIDYSHELL -- Will Coke Coleda [EMAIL PROTECTED] -- Will Coke Coleda [EMAIL PROTECTED]
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
Rare failure of t/dynoplibs/myops alarm sequence
FYI I saw this once but haven't been able to repeat it: t/dynoplibs/myopsok 6/7 # Failed test (t/dynoplibs/myops.t at line 107) # got: '1 # alarm1 # 2 # alarm2 # 3 # alarm3 # alarm1 # alarm3 # alarm3 # 4 # alarm3 # alarm3 # 5 # done. t/dynoplibs/myopsNOK 7# ' # expected: '1 # alarm1 # 2 # alarm2 # 3 # alarm3 # alarm1 # alarm3 # 4 # alarm3 # alarm3 # alarm3 # 5 # done. # ' # Looks like you failed 1 test of 7. t/dynoplibs/myopsdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 7 Failed 1/7 tests, 85.71% okay Tim [using r11741]
Re: NCI 'v' vs '' in function parameter signatures
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 c p c pi -c v d# t/pmc/nci.t d d d JOd # Parrot builtins I JOS S JOS # ParrotIO.readline -d v I JI # Parrot_is_char_* v JOSP # String.trans v JOS # String.reverse @@ -83,7 +81,6 @@ f# t/pmc/nci.t f ff # t/pmc/nci.t f is -f v i i b# t/pmc/nci.t @@ -148,7 +145,6 @@ i i t i ti -i v i 4 i 4i i 42p @@ -160,7 +156,6 @@ l pi l pii l p33l -l v l 33l P Ji # Needed for parrot threads @@ -185,10 +180,8 @@ p t p tpp p ttt -p v s # t/pmc/nci.t -s v t # t/pmc/nci.t t i @@ -200,7 +193,6 @@ t t t tl4 t t4 -t v v v Jiiip# examples/japh/japh11.pasm @@ -215,7 +207,6 @@ v p v pl v pp -v v # These are needed for parrotio.pmc i JP @@ -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 *mysql, const char *user, const char *passwd, const char *db) +p piti # MYSQL * mysql_real_connect(MYSQL *mysql, const char *host, const char *user
Re: Rare failure of t/dynoplibs/myops alarm sequence
On Tue, Feb 28, 2006 at 03:37:23PM +0100, Leopold Toetsch wrote: On Feb 28, 2006, at 14:59, Tim Bunce wrote: FYI I saw this once but haven't been able to repeat it: t/dynoplibs/myopsok 6/7 This can happen if the machine is busy. Okay. Can't the test be made more robust? Or emit a warning note? (Not a big issue, just wondering if there's some reason for it. I might look at it myself if there isn't a reason it can't be fixed.) Ti.
Re: NCI 'v' vs '' in function parameter signatures
On Tue, Feb 14, 2006 at 02:48:41PM +0100, Leopold Toetsch wrote:
Tim Bunce wrote:
What's the difference between 'v' and '' for NCI function parameters?
There isn't any, except the extra 'v' char.
I ask because both 'fv' and 'f' are in src/call_list.txt
Yeah.
In fact there are several 'duplicated' signatures:
[ ... ]
I'd say, we should drop all the '?v' variants. The extra 'v' doesn't
cover any information, it's just causing an init call to the argument
passing code.
Those warnings come from a version of tools/build/nativecall.pl I've
modified to 'normalize' the signatures to use 'v' and detect duplicates.
(As a side effect the nci.o file dropped from 354K to 347K.)
Good. But as said, I'd prefer the shorter signature.
Also, what's the protocol for adding signatures to call_list.txt?
I've at least one I want to add ('p itl' for mysql_real_connect)
and may have more soon. Should I just post a patch here?
Yep.
Tim.
Thanks for looking into this,
I'll aim to work up a patch this week.
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?
Tim.
NCI 'v' vs '' in function parameter signatures
What's the difference between 'v' and '' for NCI function parameters?
Here, for example, is the code for 'fv' and 'f':
static void
pcf_f_v(Interp *interpreter, PMC *self)
{
typedef float (*func_t)(void);
func_t pointer;
struct call_state st;
float return_data;
Parrot_init_arg_nci(interpreter, st, v);
pointer = (func_t)D2FPTR(PMC_struct_val(self));
return_data = (float)(*pointer)();
set_nci_N(interpreter, st, return_data);
}
static void
pcf_f(Interp *interpreter, PMC *self)
{
float (*pointer)(void);
float return_data;
struct call_state st;
pointer = (float (*)(void))D2FPTR(PMC_struct_val(self));
return_data = (float)(*pointer)();
set_nci_N(interpreter, st, return_data);
}
The code is a little different but it's not clear (to me) if there's any
practical difference.
I ask because both 'fv' and 'f' are in src/call_list.txt
In fact there are several 'duplicated' signatures:
Ignored signature 'cv' on line 52 (previously seen on line 49)
Ignored signature 'dv' on line 58 (previously seen on line 54)
Ignored signature 'fv' on line 85 (previously seen on line 82)
Ignored signature 'iv' on line 150 (previously seen on line 87)
Ignored signature 'lv' on line 162 (previously seen on line 155)
Ignored signature 'pv' on line 187 (previously seen on line 170)
Ignored signature 'sv' on line 190 (previously seen on line 189)
Ignored signature 'tv' on line 202 (previously seen on line 192)
Ignored signature 'vv' on line 217 (previously seen on line 204)
Those warnings come from a version of tools/build/nativecall.pl I've
modified to 'normalize' the signatures to use 'v' and detect duplicates.
(As a side effect the nci.o file dropped from 354K to 347K.)
Also, what's the protocol for adding signatures to call_list.txt?
I've at least one I want to add ('p itl' for mysql_real_connect)
and may have more soon. Should I just post a patch here?
Tim.
ncidef2pasm - generate PIR?
In runtime/parrot/library/ I see ncurses.declarations ncurses.pasm ncurses.pbc ncurses.pir and I see tools/utils/ncidef2pasm.pl that'll convert ncurses.declarations into ncurses.pasm. But where did ncurses.pir come from? (Originally ncurses.imc?) ncidef2pasm.pl can't generate pir, though I see that being suggested by chromatic in http://www.nntp.perl.org/group/perl.perl6.internals/21353 Was it written by hand, or is there some utility I'm missing? Tim.
Re: HLL Namespace Design
On Mon, Sep 05, 2005 at 01:43:20PM -0400, Matt Diephouse wrote: In order to help finish Parrot's HLL namespace support, I've compiled a list of features and information that I believe is necessary to support the target languages. I've done so after doing a survey of these languages. I may have missed something or misunderstood something: please check that this information matches what you know about these languages. It is my intent that this be merely a factual document. I want to begin on the implementation details only after we have a clear specification. Naming Strategies and Storage Different languages store their variables and subroutines/methods in different ways and places. Parrot must support all of these and, if possible, allow interoperability. Types 1. Python: Variable and subroutine/method names overlap; you cannot have two items that share the same name. 2. Ruby, Tcl: Variable and subroutine/method names do *not* overlap. 3. Perl 5: Globs prevent overlap. 4. Perl 6: Sigils prevent name collisions. Default Namespaces Python: __main__ Ruby: main Tcl: :: Perl5:main Perl6:::*Main I think it would be worth mentioning if the namespace is hierarchical (nested) or flat (the delimiters are part of the name). Another issue is whether there's an underlying hierarchy that can be accessed (at leaf and/or non-leaf nodes) to do things like namespace aliasing: *Short:: = \%Very::Long::Name::; # (possibly incorrect p5 syntax :) Namespace Capabilities - Importing Items must be imported from one namespace to another. Tcl requires that this be a snapshot - meaning that changes in the original namespace do not affect the imported items - while other languages use aliases. Items can be specified by tags (:all, :default), by patterns (c*), or by names. How items are specified for import/export seems to me a HLL-private issue and not one that need to be part of this specification. - Exporting Not all items can be exported; a list must be kept of which items can be. These items can also be specified by tags, patterns, and names. Patterns are not expanded until the time of the import (which may occur more than once). Same here. (I'm just trying to keep focused on the Parrot-relevant issues.) I think it would be a bad idea to try to implement direct support for specific HLL behaviours in Parrot. Better to distill a set of primitives that HLLs can use as a foundation. Perhaps you're more focused on the HLL issues because of the need for interoperability. I'd argue that interoperability doesn't need to be easy, it just needs to be a) possible, and b) encapsulate-able. Given those then easy can be implemented via add-on modules that encapsulate the messy details. To give a more concrete example: Parrot itself shouldn't have to understand the semantics of the Perl5 Exporter module in order for a Python module to import symbols from a Perl5 module. That kind of understanding belongs in a separate module. It may help to think of the HLLs as objects with methods that handle HLL-specific details. Perhaps HLL_specific subclasses of a Namespace PMC. Something vaguely like: $python_namespace-foreign_import( $perl5_namespace-foreign_export(...) ) The issues then become: what gets passed between them, and what few basic underlying parrot primitives are needed to support them. The same applies to unimporting and querying. --- Having said all that, I don't think it's worth worrying about inter-language issues until more fundamental namespace co-existance issues are more settled. Will a Python module clash with a Perl6 module of the same name? (That way lies insanity so I certainly hope not.) If not then separate namespace hierarchies are required. The most natural way to do that is to give each HLL its own 'virtual root' near the top of a shared namespace hierarchy. See this thread, especially message 16 (and then 13,14,15 :) http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/678fbfc5a14813b5 How close is Parrot to supporting that functionality now? (Please excuse me and point me to the docs if this is already settled.) Tim.
Re: HLL Namespace Design
On Tue, Sep 06, 2005 at 02:22:23PM +0100, Jonathan Worthington wrote: Tim Bunce [EMAIL PROTECTED] wrote: Having said all that, I don't think it's worth worrying about inter-language issues until more fundamental namespace co-existance issues are more settled. Will a Python module clash with a Perl6 module of the same name? (That way lies insanity so I certainly hope not.) If not then separate namespace hierarchies are required. The most natural way to do that is to give each HLL its own 'virtual root' near the top of a shared namespace hierarchy. It seems to me that this would mean that to use a module we always have to care about what language it is written in. Not a great hardship, and probably even important for non-trivial cases. Yes, I agree that we don't want clashes and it's for sure that some languages we support will have clashing name spaces even in their standard libraries. So something like what is suggested here is very much needed. At the same time, glancing at the .NET platform, if I remember correctly you don't have to care what language another class was implemented in to use it - you just go ahead and use it - which is nice. .NET started with a clean slate. We don't have that luxury. (It means, for example, that the Perl 5 module that a Python program was using, on conversion to Perl 6, doesn't break the Python program because it's still looking in the Perl 5 namespace.) That ought to be a one line change (and here I'm ignoring the same heap of practical difficulties that you are :-). Having said that, it's possible that perl5 and perl6 could share the same namespace. But maybe look everywhere by default is the wrong behaviour and could create all kinds of confusion. So maybe (assuming we're writing in P6):- use perl5:What::Ever; # Only look in the Perl 5 namespace. use What::Ever;# Only look in the Perl 6 namespace. use *:What::Ever; # Look in any name space - not sure * will work though. Perl6 will have a layer of indirection between the short module name in the code and the long module name that gets loaded. So there's flexibility that can be used to get the behaviour you desire. I can think some stuff up on a Parrot level for this, if anyone believes this idea worth considering. This is certainly an area that needs more thought. Tim.
Re: Call for B0rked
On Wed, Aug 31, 2005 at 04:04:45PM -0700, chromatic wrote: Hi all, In a recent discussion with Chip and Leo, the idea came up to ask for a list of very specific TODO items -- specifically things that should work but don't. Not very specific, but: whatever Ponie needs most. I'm sure Nicholas can come up with something more specific! Tim.
Re: Perl 6 Summary for 2005-08-15 through 2005-08-22
On Mon, Aug 22, 2005 at 09:43:41PM -0400, Matt Fowles wrote: Java on Parrot Tim Bunce asked some preliminary questions about Java on Parrot. I provide preliminary answers, and Nattfodd and Autrijus posted links to related work. The important question of what it should be called remained unraised. I vote for Jot. http://xrl.us/g8b9 For the record, my interest isn't so much Java ON Parrot as Java WITH Parrot. Bidirectional interface between the Parrot VM and a linked-in Java VM. Tim.
Re: Parrot - Java integration
On Tue, Aug 16, 2005 at 04:39:06PM +0200, Nattfodd wrote: Tim Bunce wrote: Anyone given any thought to Parrot - Java integration? Possible? Practical? How much would would be involved? Tim. If I'm not mistaken, it's even one of the summer of code projects (see http://www.perlfoundation.org/gc/grants/2005-googlesoc.html and http://www.perlfoundation.org/news/2005/socperljavaintegration.html). I'd looked at that and it's certainly interesting, but it's focused on Perl 5, like Inline::Java. May be should you drag David Rusek to p6i :) I've CC David, and also Patrick LeBoutillier, author of Inline::Java. Hi Dave. Any news on progress? (The last blog update was several weeks ago and the code repository's isn't available yet.) Hello Patrick. Would you be interested in working on Parrot - Java integration? Tim.
t/dynclass/gdbmhash.t failures
Configure.pl said Determining if your platform supports gdbm.yes. But t/dynclass/gdbmhash.t fails completely: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/dynclass/gdbmhash.t 13 332813 13 100.00% 1-13 with errors like: t/dynclass/gdbmhashNOK 1 # Failed test (t/dynclass/gdbmhash.t at line 43) # got: 'no extension: file 'libgdbm' # ' # expected: 'GDBMHash # ' # './parrot --gc-debug /Users/timbo/perl/parrot/t/dynclass/gdbmhash_1.pir' failed with exit code 42 t/dynclass/gdbmhashNOK 2 # Failed test (t/dynclass/gdbmhash.t at line 56) # got: 'no extension: file 'libgdbm' # ' # expected: '0 # 1 # 0 # ' The compiler complained about gdbmhash.c but didn't fail: cc -c -fno-common -no-cpp-precomp -DDEBUGGING -pipe -I/opt/local/include -pipe -fno-common -Wno-long-double-g -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization -falign-functions=16 -Wno-shadow -DHAS_JIT -DPPC -DHAVE_COMPUTED_GOTO -o gdbmhash.o -I/Users/timbo/perl/parrot/include -I/Users/timbo/perl/parrot/classes gdbmhash.c In file included from gdbmhash.pmc:49: /opt/local/include/gdbm.h:85: warning: function declaration isn't a prototype gdbmhash.pmc: In function `Parrot_GDBMHash_get_integer': gdbmhash.pmc:145: warning: function call has aggregate value gdbmhash.pmc:147: warning: function call has aggregate value gdbmhash.pmc: In function `Parrot_GDBMHash_get_string_keyed': gdbmhash.pmc:229: warning: function call has aggregate value gdbmhash.pmc: In function `Parrot_GDBMHash_get_bool': gdbmhash.pmc:171: warning: function call has aggregate value /opt/local/include/gdbm.h:85 reads: extern GDBM_FILE gdbm_open __P((char *, int, int, int, void (*)())); This is on OSX 10.4 with a recent svn update: Last Changed Rev: 8966 Last Changed Date: 2005-08-15 04:57:58 +0100 (Mon, 15 Aug 2005) Tim.
Parrot - Java integration
Anyone given any thought to Parrot - Java integration? Possible? Practical? How much would would be involved? Tim.
Re: Test failures on OSX
On Thu, May 12, 2005 at 10:31:06PM +0200, Leopold Toetsch wrote: Tim wrote: Fresh (and first) checkout and build of parrot (#8075) first???\ :-) I know, I know. Real life, real work and all that. I've been watching from afar though at all this great work. I still won't have much time but figured I ought to do *something*! Fixed - rev 8082. leo Thanks Leo. Tim.
Re: Dynamic Perl, Part 1 [IMCC]
On Thu, Apr 07, 2005 at 11:35:46PM -0400, William Coleda wrote: There are two open tickets about removing the core's dependance on Perl* PMCs, and instead, making them dynamically loadable and using the language agnostic PMCs for internal use. Talking about this with Leo on IRC, he expressed an interest in getting these changes in chunks to make them a little more digestable. Attached, find the first trivial chunk, which removes as much Perl* from IMCC internals and tests as possible without writing actually writing any new PMC code. PerlArray is going to be the hardest to pull out, as there is no other Array-style pmc that does everything it does. (or, at least, I can't find one. =-) Does the core need everything it does? If there was another Array-style pmc that does everything it does then could PerlArray be an 'empty subclass' of it? If the answer the first question is yes, then couldn't you just rename PerlArray to something without Perl in it? Is the taxonomy of PMCs and what functionality they have, written out somewhere? If not then that seems like the best place to start. Tim. p.s. Forgive me if these are dumb questions - I'm still only a distant observer.
Re: [off topic] an amusing side note
On Wed, Nov 24, 2004 at 06:30:29PM -0500, Felix Gallo wrote: 2. perl 6 is a lot cleaner than perl 5. It's also much, much larger than an already very large language. I've been programming and evangelizing Perl in organizations small and gigantic since 4.03x, and my eyes just glaze over at all the unnecessarily surfaced complexity bound to make reading other people's programs finally, at last, literally impossible: http://www.ozonehouse.com/mark/blog/code/PeriodicTable.html I'm not going to use perl 6. I doubt anyone will. We'll all be using subsets. Of course the subset that I use will probably be different from the subset used by the authors of the modules I'll be using. That's a potential headache but not a huge problem. I predict a burst of wild creativity from authors enjoying the exploration of all the wonderful tools in the perl6 toolbox. Then, after a year or three of fun, sawn off limbs, and bloodied fingers (and after a few good books get published) most of us will converge towards a common subset of accepted good practice. But we'll know that our new toolbox of choice is far deeper than our old one and will cope with a far wider range of projects. Tim.
Re: Intellectual Property
On Sun, Nov 21, 2004 at 06:41:26PM -0500, Dan Sugalski wrote: At 9:47 PM + 11/21/04, Tim Bunce wrote: What steps are being taken to ensure that patches/code donations to Parrot are free from potential intellectual property concerns? At the moment we're relying on the integrity of the people submitting patches, with the assumption that people submitting understand the policies and abide by them. TPF is working up Real Paperwork for contributors so we can have everything official and as lawyer-proof as we can manage. I'm glad it's being worked on. It's rapidly becoming a major issue. Here's a comment I got from IBM about an early draft of the DBI roadmap: ---snip--- I can suggest one important addition to the Roadmap: A structure for vetting contributions against IP/Legal entanglements. Without getting too specific, I can tell you this is a concern internally at IBM and that major focus is being placed on understanding and tracking the pedigree behind all third-party open-source software. At a minimum, it would be helpful to collect statements from all contributors to the effect that: a) Code written on employers time has been approved for contribution by the latter and contains no proprietary or encumbered aspects. b) All code is represented to be the original work of the person submitting it and that he/she has the right to contribute it. c) Perhaps other related factors known only to IP Lawyers g. I know that Linus has been forced by recent events to begin tracking some of these notions in the Linux kernel development process. To make any headway in the world where folks might be inclined to write a check, these issues cannot be ignored - particularly under the US Legal System. ---snip--- It's boring but important to get procedures in place before the backlog of unvetted contributions becomes too great. Tim.
Intellectual Property
What steps are being taken to ensure that patches/code donations to Parrot are free from potential intellectual property concerns? Tim.
Re: Exceptions, sub cleanup, and scope exit
On Thu, Nov 18, 2004 at 11:37:54AM -0800, chromatic wrote: On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote: I'd like pushing exception handlers to remain simple -- the current system is almost OK. What I'd like it to change to is: push_eh label with popping the top exception handler being: pop_eh I'm up for better names, too. The push_ is okay but eh is meh. push_handler seems better, though handler is terribly generic. If the documentation and comments use it consistently only for exceptions, though, it could work. Throwcatch, so push_catcher ? I guess the HLL compiler needs to ensure that for every push the control flow will always pass through a matching pop. Otherwise that'll be another hard to debug situation. Couldn't (doesn't) parrot have a stronger concept of a 'scope' (as in perl5's scope.c) so that scope-exit cleanup can be automated and reliable? Tim [ignore me if I'm talking nonsense]
Re: Namespaces, part 2
On Mon, Oct 04, 2004 at 11:25:47AM -0400, Dan Sugalski wrote: Okay, since we've got the *basic* semantics down (unified namespace, namespace entries get a post-pended null character) it's time for the ops to handle them, as well as some extended semantics. I agree with Larry when he said But I really don't care so much what the flag is, as long as it's visible on printout. I think even / would be better than \0. But if you _really_ want to go with a null, Larry also had a point when he said Well, I'd prepend the null just to reduce confusion (or rather, to force the confusion earlier). What I want to keep is: $Px = find_global 'name' $Px = find_global [key; key; key], 'name' These load [...] from the current namespace and the specified namespace respectively. How do you define current? Compile-time, load-time, run-time, run-time for each sub? From what you say later I'm guessing you mean run-time for each sub. So current namespace is an attribute of the sub? If so, then how is that represented within the interpreter struct when it enters an anonymous subroutine via a continuation? I ask partly because I'm (still) not paying enough attention, and because once you add... Next I want to add in the op variants: $Px = find_global [key; key] $Px = find_global $Px, [key; key] $Px = find_global $Py, 'name' Then $Px = find_global 'name' could be changed by the compiler (or byteloader?) into $Px = find_global $Py, 'name' where $Py is the register, or pseudo register, holding the current namespace. The case where the namespace is specified by string I think should go away. (And this'll impact me quite a bit, but it's still the right thing to do) I agree. to fetch out namespace PMCs and work with fetched namespace PMCs. $P0 = find_global ['Foo'] $P1 = find_global $P0, ['Bar'; 'Baz'] $P2 = find_global $P1, 'xyzzy' That is, if we don't specify the name of the thing in the namespace we get the namespace PMC itself, which we can then go look things up in. This is handy since it means code can cache the namespace PMC so if there are a dozen variables to go fetch out, we don't have to do the multi-level hash lookup each time. (That'd be nasty) Yeap. Right *now* I'm not inclined to have a store_global variant to do this, but if we want to completely hide all namespace operations behind ops I'm OK with that. The issue here is the postpending of a null to indicate a namespace? If the application does it then it's breaking the encapsulation of that concept? Yeap, that's bad and should be avoided. By the way, you said: store_global 'name', $Px store_global [key; key; key], $Px but shouldn't that be:? store_global 'name', $Px store_global [key; key; key], 'name', $Px# 'name' was missing Then a store_global variant without the name param would be how you'd store a namespace: store_global [key1; key2; key3], $Px I think that's worth adding up front. Other random thoughts: I presume that store_global will auto-vivify namespace in the list. You'll may need to define a way to explicitly get the root namespace. I think some minimal top-level namespace policy needs to be set now to limit the risk of confusion and/or polution later. I'd suggest: * Every Language gets a top-level namespace named after the language. So the Perl compiler adds 'Perl'; to all the namespace lookups (or something equivalent to that in effect). * Every Language namespace uses ParrotRoot as the way to access the root namespace (so find_global ['Perl'; 'ParrotRoot'] returns the root namespace). That way any number of languages can coexist within Parrot at runtime with no risk of clashing. The only polution is the single ParrotRoot name. The Python language root namespace, for example, would be visible to all other languages as ParrotRoot.Python. Now, with that out of the way, let's talk about overlaid namespaces. I don't think I ever read a description of what the purpose of this was. I get the what but not the why. Without the why it's hard to critique the how. The namespace specification has always allowed for multiple overlapping namespaces. What this is supposed to allow you do to is have two or more full namespace trees available at once, with lookups and stores automatically running through each of the namespaces until the appropriate thing is found. I understand that, but... (And the fact that we want to do this, and do it sorta-kinda lexically, is a reason for the namespace ops) ... not that. But let's ignore that for now. I'll come back to it below. For this, we're going to add the ops: overlay_namespace $Px overlay_namespace $Px, $Iy remove_namespace $Px remove_namespace $Ix The first two add the namespace $Px to the current search list There's that current word again. Same confusion in my mind. Unless current can be explained *really simply* I'd suggest it's
Re: Namespaces
On Tue, Sep 07, 2004 at 09:26:14AM -0400, Dan Sugalski wrote: Time to nail this. We need namespaces. Duh. We talked about this in the past. I've reordered these to put the simple/fundamental things first: *) Namespaces are hierarchical *) The top-level namespace [__INTERNAL] is taken. *) Each language has its own private second-level namespace. *) Parrot's base library goes into [_INTERNAL; Parrot] I presume you've looked at this thread again: http://groups.google.com/groups?hl=enlr=ie=UTF-8safe=offthreadm=20040116110746.GA38383%40dansat.data-plan.com Anything you disagree with there? I think a filesystem analogy is a very helpful one. Many of the issues are similar and there's a lot of experience with how to address them in creative ways. I'd suggest adding: *) Each interpreter has a current root namespace from which namespace searches start. (Analogous to chroot() in unix.) Apart from enabling functionality analogous to chroot() in unix, it also avoids having to prepend [_INTERNAL; language] to all namespace lookups and avoids the overhead of then traversing through those two levels. *) ...something here about namespace objects and how namespace traversal is performed (methods/vtable foo)... *) Namespaces and sub-spaces can be overlaid or aliased So code can, for example, throw a layer over the ['foo'; 'bar'; 'baz'] part of the namespace that gets looked at first when searching for something. These layers can be scoped and shifted in and out, which means its possible to have two or more [IO] namespaces that have completely (or partially) different contents depending on which space is in use. I'd be interest to know your thoughts on how that that might be implemented. Seems like you'd need a 'sparse tree' of proxy namespace objects that you'd start searching first and that would fallback to the corresponding real namespace object at the point no match was found. But it doesn't seem worthwhile going into much detail till the namespace traversal bullet above is filled out. (I'm reminded of the translucent filesystem (TFS), but it's effect is globally visible.) It's also possible to hoist a sub-space up a few levels, so that the [IO] space and the [__INTERNAL; Perl5, IO] namespace are the same thing Not actually move, but make visible at? Like a symbolic or hardlink in a filesystem. Tim.
Re: Functions for embedders to override
On Wed, Aug 11, 2004 at 01:10:42AM -0400, Dan Sugalski wrote: A good place to look at for the complete list is Perl 5's system abstraction layer. Yeah. If you've got time to get a list I'd very much appreciate it. http://search.cpan.org/src/NWCLARK/perl-5.8.5/iperlsys.h Tim.
Re: Python builtin namespace
On Fri, Jul 16, 2004 at 12:02:15AM -0400, Dan Sugalski wrote: At 10:17 PM + 7/15/04, Steve Peters wrote: On Friday 16 July 2004 02:46 am, Dan Sugalski wrote: And language builtin namespaces in general. We need a standard, and now's as good a time as any, so... All language-specific builtin functions go into the _core_Language namespace. (So for Python it's _core_Python, Perl 5 is _core_Perl5, and so on) Just as a side question, will these language specific namespaces be available to other languages? Yes. And, as my addled brain churns on this some more, we had a standard we semi-hashed-out a while back for the proper way to do this with hierarchical namespaces. Yeap. This one http://groups.google.com/groups?hl=enlr=ie=UTF-8safe=offthreadm=20040116110746.GA38383%40dansat.data-plan.comrnum=1prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26selm%3D20040116110746.GA38383%2540dansat.data-plan.com We can re-hash that in August and nail it down, at which time I'll redo the translator program for python bytecode. (Because, bizarrely, I'd actually like this to morph into something production-worthy. Go figure) :) Tim.
Re: Events (I think we need a new name)
On Wed, May 12, 2004 at 12:08:08PM -0400, Dan Sugalski wrote: Okay, so I'm working on redoing the events document based on the critiques from folks so far. (Which have been quite helpful) I should have a second draft of the thing soon. It does, though, sound like we might want an alternate name for this stuff. While event is the right thing in some places it isn't in others (like the whole attribute/property mess) we may be well-served choosing another name. I'm open to suggestions here... I suggest hap.http://dictionary.reference.com/search?q=hap Tim. 7 entries found for hap. hap( P ) Pronunciation Key (hp) n. 1. Fortune; chance. 2. A happening; an occurrence. intr.v. happed, hap·ping, haps To happen. [Middle English, from Old Norse happ. See kob- in Indo-European Roots.] Source: The American Heritage® Dictionary of the English Language, Fourth Edition hap \Hap\, v. t. [OE. happen.] To clothe; to wrap. The surgeon happed her up carefully. --Dr. J. Brown. Source: Webster's Revised Unabridged Dictionary, © 1996, 1998 MICRA, Inc. hap \Hap\, n. [Cf. Hap to clothe.] A cloak or plaid. [O. Eng. Scot.] Source: Webster's Revised Unabridged Dictionary, © 1996, 1998 MICRA, Inc. hap \Hap\, n. [Icel. happ unexpected good luck. [root]39.] That which happens or comes suddenly or unexpectedly; also, the manner of occurrence or taking place; chance; fortune; accident; casual event; fate; luck; lot. --Chaucer. Whether art it was or heedless hap. --Spenser. Cursed be good haps, and cursed be they that build Their hopes on haps. --Sir P. Sidney. Loving goes by haps: Some Cupid kills with arrows, some with traps. --Shak. Source: Webster's Revised Unabridged Dictionary, © 1996, 1998 MICRA, Inc. hap \Hap\, v. i. [OE. happen. See Hap chance, and cf. Happen.] To happen; to befall; to chance. --Chaucer. Sends word of all that haps in Tyre. --Shak. Source: Webster's Revised Unabridged Dictionary, © 1996, 1998 MICRA, Inc. hap n : an accidental happening; he recorded all the little haps and mishaps of his life v : come to pass; occur: What is happening?; The meeting took place off without an incidence; Nothing occurred that seemed important [syn: happen, go on, pass off, occur, pass, come about, take place] Source: WordNet ® 1.6, © 1997 Princeton University
Re: IO opinions -- lines vs records vs streams
On Sat, May 08, 2004 at 04:59:52PM -0700, Jeff Clites wrote: On May 8, 2004, at 10:30 AM, Dan Sugalski wrote: Do we want to make a distinction between record reads and just plain read me X (bytes|codepoints|graphemes) requests on filehandles and, if so, do we think it's worth distinguishing between fake records (line-oriented things) and real records (where there's a fixed record size or absolute record marker)? I'd say that there's no need to distinguish. C's stdlib tries to be record-oriented, and I've never found it to be useful. Trying to be record-oriented (for what people today want from records) at the IO level seems awkward--and it's easy to write (at the user level) a give me the next token interface on top of a byte-source or a character-source, and there's not a lot of benefit to modeling this as IO. (Note that, regardless of anything else, we do need to separate out stream IO and record IO, both for layer filtering reasons and for pure practicality as there still are some pure-record filehandles (UDP sockets and such) even on a Unix system) On Unix, record-oriented IO is specific to sockets only (not filehandles in general). Not sure what you mean by layer filtering. If I write to a filehandle for a file opened in append mode I want (to be able to make) that write still be atomic when it gets to the operating system (ie not broken up into multiple writes, or merged with previous data). Tim.
Re: [perl #29200] [NCI Feature Request] Handle Out Parameters
On Wed, Apr 28, 2004 at 10:36:00PM -0700, chromatic wrote: Or, we forget about these special cased pointer to int and pass a managed struct. That's cleaner from the C side, but it's enough of a pain to set up managed structs on the calling side that I'd rather do it only when it's absolutely necessary. Provided we pick a convention that makes sense (that is, out parameters go in I5, I6, ... In, and then the actual returned value goes at the end of the list in In+1) and stick with it, I like option A a little better. Is there a good reason not to put the returned value first? Makes more sense to me. Tim.
Re: new libraries
On Sat, Apr 10, 2004 at 01:49:37PM +0300, Jarkko Hietaniemi wrote: (We've learnt the hard way with Perl5 modules names that more words are good. And more words that mean something... Data ranks right up there as the worst possible names for anything. (Nah, Sys and System are at the top of the list :) Anyone wanting to act as a guiding light for Perl6 module naming is very welcome. I've been there and done that once. For ten years. My time is up. Tim.
Re: new libraries
On Fri, Apr 09, 2004 at 03:02:00PM +0200, Jens Rieks wrote: Hi, On Thursday 08 April 2004 23:49, Tim Bunce wrote: On Thu, Apr 08, 2004 at 08:28:49PM +0200, Jens Rieks wrote: Data::Replace replaces every occurrence of one PMC in a nested data structure with another PMC. I'm not sure what that means, but Data::Replace seems too vague. What is it? if you have a data structure [A, B, [C, D, E], C, D, E], where each letter represents a PMC. With Data::Replace, you can for example replace each D PMC with another PMC value. Do you have a better name for it? Perhaps Data::DeepReplacePMC (We've learnt the hard way with Perl5 modules names that more words are good. Keeping module names very short is a false economy.) Data::Escape contains a function String that escapes the string. Wouldn't escape_string be better? What would be redundant, the namespace already contains Escape. You're assuming that the name will always be seen in the context of it defining module. That may not be the case in the future. (And I wonder how different languages escape strings, and if there's a common subset that'll work for all/most of them.) Its C and PIR like escaping, it relaces some ASCII code with \n, \t, \r and replaces ' with \' in strings quoted with ', and with \ in strings quoted with . escape_string_cstyle perhaps Tim. Tim [wearing a tired old namespace police hat] :-) jens
Re: new libraries
On Thu, Apr 08, 2004 at 08:28:49PM +0200, Jens Rieks wrote: Data::Replace replaces every occurrence of one PMC in a nested data structure with another PMC. I'm not sure what that means, but Data::Replace seems too vague. What is it? Data::Escape contains a function String that escapes the string. Wouldn't escape_string be better? (And I wonder how different languages escape strings, and if there's a common subset that'll work for all/most of them.) Tim [wearing a tired old namespace police hat]
Re: Initializers, finalizers, and fallbacks
On Wed, Apr 07, 2004 at 08:15:03AM +0100, Andy Wardley wrote: Dan wrote: Should be FINALIZE. Although some in the non-US English speaking world might say it should be FINALISE. FYI: FINALIZE is the spelling used by the Oxford English Dictionary. See http://www.askoxford.com/asktheexperts/faq/aboutspelling/ize reproduced below. Tim. Frequently Asked Questions Spelling Are spellings like 'privatize' and 'organize' Americanisms? No, not really. British spelling has always recognized the existence of variant spellings using the suffix -ize/-ise. When American spelling was standardized during the 19th century (mainly through the efforts of the great American lexicographer Noah Webster), the consistent use of -ize was one of the conventions that became established. However, since then, the -ise spellings have become more popular in Britain (and in other English-speaking countries such as Australia), perhaps partly as a reaction against the American custom. Spellings such as organisation would have struck many older British writers as rather French-looking. The Oxford English Dictionary favoured -ize, partly on the linguistic basis that the suffix derives from the Greek suffix -izo, and this was also the style of Encyclopedia Britannica (even before it was American-owned) and formerly of the Times newspaper. The main advantage of the modern -ise habit? Lazy spellers do not have to remember that there are several important words which cannot properly be spelt with -ize. These include words which are not formed by the addition of the -ize prefix to a stem, but by some other root which happens to end in the same syllable, such as -vise (as in televise), -cise (as in incise), and -prise (as in comprise). The American system resulted in the creeping of z into some other words where it did not originally belong. Writers of American English should be aware of some spellings that are regarded as incorrect in the UK, notably analyze.
Re: New SDL Parrot Bindings Underway
On Mon, Apr 05, 2004 at 09:33:15PM -0700, chromatic wrote: On Mon, 2004-03-29 at 23:33, chromatic wrote: With the improved object system in place, I've been porting the existing SDL Parrot bindings. Here's a quick status update. With helpful suggestions from Jens and Allison, I've just finished porting the existing files in examples/sdl to the new libraries. They're a lot nicer. This is probably a (dumb) parrot question rather than SDL, but I'd have expected these: find_type app_type, 'SDL::App' .namespace [ 'MoveLogo::EventHandler' ] to be more like find_type app_type, 'SDL', 'App' or: find_type app_type, [ 'SDL', 'App' ] .namespace [ 'MoveLogo', 'EventHandler' ] Would either/both of those work and you're just opting to have double colons 'inside' a non-nested namespace name, or am I misunderstanding how nested namespaces do/should/will work? Tim.
Re: Points of focus
On Wed, Mar 31, 2004 at 01:42:30PM -0500, Dan Sugalski wrote: Or something equally manager-speaky. It's time to be looking towards a 0.1.1 release. There's been some overhaul of the internals and fleshing out of some features, so I think we're well-warranted to be thinking about another point release. What I'd like to do this time is: *) Get continuations all nailed down. There seems to be some lingering problems in the system I'd like identified with tests and fixed *) Get lexical pad operations spec'd out and possibly working *) Fix hash.c. (Though it may not be broken. Signs are good, though) *) MMD vtable ops in bytecode *) ICU building, if Jeff gets things integrated in time Standard doc updates and bug fixes are in order too, I think. Is IMCC method call syntax spec'd, implemented, and reasonably stable? Tim.
UNO (Universal Network Objects) interface for Parrot?
Has anyone looked at what's needed to plug Parrot into UNO? --- snip --- http://udk.openoffice.org/ UNO (Universal Network Objects) is the interface-based component model of OpenOffice.org. UNO offers interoperability between different programming languages, different object models, different machine architectures and different processes; either in a local network or even via the internet. UNO components can be implemented in and accessed from any programming language for which a UNO language binding exists. Currently there are complete UNO language bindings for: - C - C++ (compiler dependent, please see http://porting.openoffice.org for a list of supported platforms) - Java - Python Additionally, there are bindings that allow to access UNO components, but do not support the development of new UNO components: - OpenOffice.org Basic - Object Linking and Embedding (OLE) Automation - Common Language Infrastructure (CLI). Note: The Microsoft .NET framework is an implementation of this standard. The language binding does NOT have the status final yet. Therefore do NOT use it (and programs based on it) in a production environment. --- snip --- Just a thought. Tim.
Re: Parrot hijacks SIGINT
On Tue, Mar 16, 2004 at 08:43:11AM +, Arthur Bergman wrote: On 16 Mar 2004, at 06:36, Leopold Toetsch wrote: But - as Dan did say - the plan for Parrot is to install signal handlers by default. We should distinguish between the Parrot core and the parrot executable command. The parrot executable command can use the extension interface to indicate that it wants signal handlers to be installed. Embedding parrot is an important goal. It seems inappropriate for the parrot core to alter the state of the process, like installing signal handlers, without providing some way for that to be disabled. [1] BTW: Why does Ponie use the rather limited extension interface? Because Dan said so, and because doing an include parrot.h in perl leads to one million or so cpp and gcc errors. And because it's a good way to push the extension interface so it's sufficiently capable to being used to embed Parrot anywhere. Web servers and database servers being obvious examples. Tim. p.s. I suspect there are valuable lessons to be learnt from the work Sarathy and ActiveState did on embedding Perl. http://search.cpan.org/src/NWCLARK/perl-5.8.3/iperlsys.h
Re: newbie question....
On Fri, Mar 12, 2004 at 10:03:19AM -0500, Dan Sugalski wrote: At 6:06 PM -0500 3/11/04, Matt Greenwood wrote: Hi all, I have a newbie question. If the answer exists in a doc, just point the way (I browsed the docs directory). What is the design rationale for so many opcodes in parrot? What are the criteria for adding/deleting them? Whether we have a lot or not actually depends on how you count. (Last Is someone tracking the mailing list and adding questions and (good) answers into the FAQ? Tim.
IMCC and objects/methods
First off, congratulations to Dan, Leo and everyone else involved in Parrot 0.1.0. Great work. Can someone give me a summary on where we stand with IMCC and objects/methods? (I looked in a bunch of places in the CVS tree but couldn't find an answer.) Am I right in thinking that IMCC v1 doesn't support objects/methods currently? And that IMCC v2 will, obviously, but IMCC v2 isn't usable yet? If so, is there any estimate of when v2 would be usable, or when v1 might be patched to support objects/methods in the meantime? Tim.
Re: Tetris
On Mon, Feb 23, 2004 at 08:03:02PM +0100, Leopold Toetsch wrote: Jens Rieks [EMAIL PROTECTED] wrote: Hi, Am Montag, 23. Februar 2004 17:09 schrieb Leopold Toetsch: WRT feature freeze: I'd say: Starting from Tue, 24th 8.00 GMT no more feature patches *should* go in, *except* objects. can/should go the tetris example go in? If its running yes. I've to admit that I didn't test it. And examples aren't that critical. They aren't really features :) If you squint a little you could pretend they're tests :) Tim.
Re: PDD status
Did you forget to add Volunteers wanted for each of these ? Tim. On Thu, Feb 19, 2004 at 08:17:50PM -0500, Simon Glover wrote: PDD 0 (intro. to PDDs): Very, very out of date; I think it actually pre-dates Parrot PDD 1 (overview of Parrot): Not obviously out-of-date, but could use some text on IMCC and on the JIT PDD 2 (vtable functions): Needs documentation on freeze, thaw and share from somebody who actually understands what they do. We also need to figure out which of the functions described in it are simply waiting to be implemented and which are never going to be implemented PDD 4 (datatypes): The bigint/bignum stuff is completely out-of-date. We also need to figure out if there are any other internal datatypes that we should be documenting. PDD 5 (opfuncs): Very, very out-of-date. Needs a significant rewrite. PDD 6 (PASM): Missing a lot of ops. Also includes some ops that don't exist. (An easy task for the interested would be to put together a list of each). PDD 7 (coding standards): OK, as far as I know. PDD 8 (keys): This is quite old, so we need to check if it accurately describes the current system. PDD 9 (GC): Doesn't discuss any of the recent changes, such as the early DOD stuff PDD 10 (embedding): Empty. (Although we do have embed.pod) PDD 11 (extending): Empty. (But see extend.pod) PDD 12 (assembly): Empty and obsolete. PDD 13 (bytecode): Empty. (But see parrotbyte.pod) PDD 14 (bignums): Bignums are unimplemented, so all of this may change in the future. PDD 3 (calling conventions): PDD 15 (objects): Dan's handling these. PDD 16 (NCI): Needs looking over by somebody who understands the NCI system.
Re: Alignment Issues with *ManagedStruct?
On Thu, Feb 05, 2004 at 11:04:40AM +0100, Jens Rieks wrote: I thought of that too. A Perl script that takes a C struct and emits an *ManagedStruct initializer. WRT align: as such struct initializers are in library code and used by different machines, I'd rather have the alignment calculation inside the unmanagedstruct.pmc. I'am currently writing a simple C-parser in imc. My plan is to extract all structs, enums, unions and typedefs in order to create ManagedStructs automatically. If one goes even a step further, it should even be possible to create pasm/imc wrapper for C functions automatically. The tokeniser is already working, but the token processing is of course not very simple, but I think I will have a first working alpha version within the next few days. Have you looked at http://search.cpan.org/~grichter/ExtUtils-XSBuilder/ ? Tim.
Re: PIR version of Data::Dumper
On Thu, Feb 05, 2004 at 02:35:38PM +0100, Leopold Toetsch wrote: Jens Rieks [EMAIL PROTECTED] wrote: Here is a first version of a Data::Dumper i've written to be able to dump the AST of my C parser. Wow, fine. A dumpertest.imc is included, which shows the dumper in action. s/included/missing/ :) I'am sorry, but I have no idea how to convert this to a test. Test::More provides Cis_deeply to compare structures. ... BTW, is the order of the hash elements guaranteed to be equal across platforms? Just the opposite, its guaranteed to be not the same even on one platform, albeit a srand() like call is still missing to get really random key order. So it would be really nice to have a Data::Dumper be able to sort the keys, like the Perl one now can. Tim.
Re: Some minor decisions and timetables
On Tue, Feb 03, 2004 at 09:27:31PM +, Harry Jackson wrote: Dan Sugalski wrote: *) I'll try and patch up the docs, and I'll concentrate on the PDDs, but any help on them is greatly appreciated. *Especially* IMCC docs. Do we need an NCI section in the IMCC.faq. If the vote is yes I do not mind knocking something up. I'd vote yes! Thanks. Tim.
Re: Docs and releases
On Tue, Feb 03, 2004 at 09:23:58AM +0100, Leopold Toetsch wrote: Tim Bunce [EMAIL PROTECTED] wrote: Yeah, I think getting the docs better will be an aggressive goal for the next release. How's this all looking now we're in Feb? There is still a lot of outdated (or unimplemented?) stuff in assembly related docs. WRT release :) ,--[ p6i ]- | The low-level object design will be done by Jan 30th. | -- Dan 2004.01.12 `-- Great. The DBDI project is basically stalled till then. (See my other email about that.) Tim.
Re: First DBDI draft
On Tue, Feb 03, 2004 at 04:35:46PM +, Harry Jackson wrote: [... ] Question: Since Dan has said that objects are nearly finished is there any point spending too much time working on this. Would our time be better spent helping to get objects finished pronto. I think so. It's basically a (considerable) waste of time trying to come up with ways around the current, and hopefully short term, limitations. I had thought Parrot was a little further along than it seems to be. Sadly I think it's best to consider the DBDI project shelved until Parrot and IMCC get reasonably usable objects and method calls. I *really* hope that can happen for the February release. I'm CC'ing this to [EMAIL PROTECTED] in the hope that it'll spur on development. Tim. p.s. I just saw Leo quoting Dan as saying The low-level object design will be done by Jan 30th. so hopefully it won't be long now, and hopefully IMCC won't be far behind.
Re: Docs and releases
On Mon, Jan 12, 2004 at 09:33:57AM -0500, Dan Sugalski wrote: At 11:52 AM + 1/12/04, Tim Bunce wrote: Has a date been set for the next release? Nope. I suppose we could shoot for another holiday release, if someone's got a good february one. Are the docs (especially the PDDs) upto date on best practices? Alas not, no. If not, will that be a goal for the next release? Yeah, I think getting the docs better will be an aggressive goal for the next release. How's this all looking now we're in Feb? Tim. p.s. Apart from docs I'd *really* like to see a clean way to make method calls as it's a fundamental part of the DBDI API.
Re: Some namespace notes
On Mon, Feb 02, 2004 at 12:40:45PM -0800, Larry Wall wrote: On Fri, Jan 30, 2004 at 06:16:06PM +, Tim Bunce wrote: : In Java you would write java.lang.String, naturally, and in Perl : you'd write parrot::java::java.lang.String. That's okay if it's a string being interpreted by the appropriate code, but as a Perl 6 name it won't wash. That's gonna try to call the .lang method on the parrot::java::java class, and the String method on the result of that. (Unless, of course, you define a parrot::java::java macro to mangle subsequent Perl 6 syntax. But that seems awfully hackish. And the parrot::java namespace might not let you define the macro there in the first place...) Ah, no, it was simply a typo, I meant: parrot::java::java::lang::String Tim.
Re: [DOCS] Updated documentation in src
Great, thanks. Tim. On Sat, Jan 31, 2004 at 01:05:02AM +0100, Michael Scott wrote: I haven't ruled out something like that in the long term, but what I'm trying achieve at the moment is just to see some pod everywhere. This has the merit that I visit every file and ensure that some basic information gets provided for the newbies - my target audience. In a sense I'm following the time honoured tradition of throwing one away, namely the Getting Started Guide on the wiki. I'm shifting pod from there into the files. At the moment I'm just building a big index.html list and using the default html formatting from Pod-Simple, but this will change soon. I think the trick is to model the project with perl modules so that it's straightforward to extract and compose information. I already have the basis for this, which I'll check in any day now. Mike On 30 Jan 2004, at 19:23, Tim Bunce wrote: Would doxygen be of use here? http://www.doxygen.org/ Here's an example use http://www.speex.org/API/refman/speex__bits_8h.html#a2 Follow the links, including to the annotated source file. Tim. On Thu, Jan 29, 2004 at 07:20:50PM +0100, Michael Scott wrote: I've add inline docs to everything in src (except for malloc.c and malloc-trace.c). At times I wondered whether this was the right thing to do. For example, in mmd.c, where Dan had already created a mmd.pod, I ended up duplicating information. At other times I reckoned that what was needed was an autodoc. Other times the best I could do was rephrase the function name. All issues to address in phase 2. Next I think, for a bit of light relief, I'll do the examples. For those who want to browse: http://homepage.mac.com/michael_scott/Parrot/docs/html/ Mike
Re: [DOCS] Updated documentation in src
Would doxygen be of use here? http://www.doxygen.org/ Here's an example use http://www.speex.org/API/refman/speex__bits_8h.html#a2 Follow the links, including to the annotated source file. Tim. On Thu, Jan 29, 2004 at 07:20:50PM +0100, Michael Scott wrote: I've add inline docs to everything in src (except for malloc.c and malloc-trace.c). At times I wondered whether this was the right thing to do. For example, in mmd.c, where Dan had already created a mmd.pod, I ended up duplicating information. At other times I reckoned that what was needed was an autodoc. Other times the best I could do was rephrase the function name. All issues to address in phase 2. Next I think, for a bit of light relief, I'll do the examples. For those who want to browse: http://homepage.mac.com/michael_scott/Parrot/docs/html/ Mike
Re: Some namespace notes
On Thu, Jan 29, 2004 at 09:16:33AM -0800, Jeff Clites wrote: Then the question becomes, What about namespace clashes?, which Tim has already addressed. We could certainly do some sort of language-specific prefixing, as Tim suggested, but it seems that we are then going to trouble to unify, only to immediately de-unify. Certainly, a random Java programmer shouldn't have to worry about naming a class so that it doesn't conflict with any class in any other language in the world--that's silly, especially since this Java programmer may not even know about parrot. I think you missed the part where I said that each language has it's own root which is actually below the root of the unified namespace. The namespaces of other languages are reached via a backlink/symlink kind of thing so they appear to be within the namespace of the language being used. it seems natural to instead just use that class name as I would expect it to be written--java.lang.String for Java, for example. In Java you would write java.lang.String, naturally, and in Perl you'd write parrot::java::java.lang.String. As per the example I gave previously. Take another look. Tim.
Parrot DBDI - Announcement and Firmly Anticipated Questions
development effort on a common database infrastructure Ibelow the DBI level. =head2 What about Drivers? I anticipate that drivers will be implemented using the Parrot Native Call Interface (NCI) to interface with the underlying database API. This has the significant advantage, if it works well, that drivers shouldn't need to be compiled on each platform. =head2 Links to database interfaces for various HLLs Ruby: http://ruby-dbi.sourceforge.net/ Python: http://www.python.org/topics/database/ Perl: http://dbi.perl.org/ PHP: http://freshmeat.net/projects/php-dbi/ (Please let me know about any other similar database interface projects for languages that may target Parrot.) =head2 Developers Harry Jackson [EMAIL PROTECTED] has volunteered to lead the development effort with design input from me, Tim Bunce. We're hoping that others interested in database interfaces for Parrot will join us and contribute. I expect a public code repository will be established soon. =head2 Mailing List The [EMAIL PROTECTED] mailing list has been created for this project. Archives can be found at http://www.mail-archive.com/[EMAIL PROTECTED]/ Send email to [EMAIL PROTECTED] to subscribe. =cut
Re: [RESEND] Q: Array vs SArray
On Fri, Jan 23, 2004 at 02:19:37PM +0100, Michael Scott wrote: Is there a reason why the names have to be so terse? Mutable is not a bad word for able-to-change. (Cribbed from Cocoa, though there the immutability is absolute). *) Array - fixed-size, mixed-type array *) MutablePArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) MutableSArray - variable-sized string array *) SArray - fixed-size string array By mutable you mean size but others might read it as the types or contents or some other aspect. Here's my preference: *) ArrayFLenMixed - fixed-size, mixed-type array *) ArrayVLenPMC- variable-sized PMC array *) ArrayFLenPMC- fixed-size PMC array *) ArrayVLenString - variable-sized string array *) ArrayFLenString - fixed-size string array (Of course VLen/FLen could be VSize/FSize if preferred, and Mixed seemed better than Any as I recall it's not truly any type.) The general scheme is container typequalifierscontained type Tim. Mike On 22 Jan 2004, at 19:24, Dan Sugalski wrote: At 2:15 PM -0500 1/21/04, Matt Fowles wrote: All~ So, lets do the classes as: *) Array - fixed-size, mixed-type array *) vPArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) vSArray - variable-sized string array *) SArray - fixed-size string array I suggest using Array to mean fixed size and Vector to mean variable size. I'd rather not. Vector, for me at least, has some specific connotations (from physics) that don't really match what we're talking about here. They're more vectors in the mathematical sense, but they won't behave like mathematical vectors so I don't think that's a good idea either. Array, while mundane (and a bit annoying with the prefix stuff tacked on) is at least accurate. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: how to subclass dynamic PMCs?
On Thu, Jan 22, 2004 at 07:56:51AM -0500, Michal Wallace wrote: I did something like this: $ make -C dynclasses $ cp dynclasses/pisequence.so blib/lib/libpisequence.so Aha! I was trying to figure out how to do -lpisequence. It didn't occur to me to just RENAME it. :) Perhaps all such .so's should be generated with lib at the start of the name. Tim.
Re: Some namespace notes
Here's my proposal:
* Basics:
Parrot uses nested hashes for namespaces (like perl does).
The high-level language splits namespace strings using whatever
its separator is ('::', '.' etc) to generate an array of strings
for the namespace lookup.
* Relative roots:
Namespace lookup starts from a 'root' namespace (think root directory).
Here the P2 argument holds the root namespace to start the lookup from:
find_global P1, P2, ['global', 'namespace', 'hierarchy'], thingname
If it's null then the interpreters default root namespace is used.
This scheme allows chroot() style shifting of the effective root.
(It's a key part of how the perl Safe module works, for example.)
* Per-language root:
Each HLL could use a 'root' that's one level down from the true root.
Using a directory tree for illustration:
/perl/Carp/carp perl sees Carp at top level
/java/java/lang/... java sees java at top level
* Backlinks:
/perl/main -.main points back to perls own root
^--'(so $main::main::main::foo works as it should)
/perl/parrot -. parrot points back to true root
^-'
* Accessing namespace of other languages:
Given the above, accessing the namespace of other languages is as simple as:
/perl/parrot/java/java/lang/String/...
eg $parrot::java::java::lang::String::CASE_INSENSITIVE_ORDER for perl
and parrot.perl.Carp.carp for Java (perhaps, I don't claim to know any Java)
* Summary:
- Nested hashes allow chroot() style shifting of the root.
- That requires the 'effective root' to be passed to find_global.
- Each HLL could have it's own 'root' to avoid name clashes.
- Backlinks can be used to provide access to other HLL namespaces.
- This combination of unification (all in one tree) and isolation
(each HLL has a separate root) offers the best of all worlds.
Tim.
Re: Optimization brainstorm: variable clusters
On Thu, Jan 15, 2004 at 06:27:52PM -0500, Melvin Smith wrote: At 06:13 PM 1/15/2004 -0500, Melvin Smith wrote: At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote: At 15:51 -0500 1/15/04, Melvin Smith wrote: Comments questions welcome. Why am I thinking of the register keyword in C? I have no idea and I can't see the relationship. :) I just realized my response sounded crass, and wasn't meant to be. I welcome comments, I just didn't understand what relation you were getting at. Feel free to point it out to me. The context: Jonathan was asking about importing constants at runtime and/or constant namespaces. Dan and I were discussing the issues and how routines with lots of package globals or constants would spend a significant part of their time retrieving symbols. Jonathan did not want compile time constants, Dan did not want importable constants that mutate the bytecode at runtime, so I was trying to come up with a compromise, ugly as it may be. Aren't constant strings going to be saved in a way that lets the address of the saved string be used to avoid string comparisons? (As is done for hash keys in perl5.) Perhaps that's already done. Then bytecode could 'declare' all the string constants it contains. The byteloader could merge them into the global saved strings pool and 'fixup' references to them in the bytecode. If the namespace lookup code knew when it was being given saved string pointers it could avoid the string compares as it walks the namespace tree. Maybe all that's been done. Here's an idea that builds on that: Perhaps a variant of a hash that worked with large integers (pointers) as keys could be of some use here. The namespace could be a tree of these 'integer hashes'. Most namespace lookups use constants which can be 'registered' in the unique string pool at byteloader time. To lookup a non-constant string you just need to check if it's in the unique string pool and get that pointer if it is. If it's not then you know it doesn't exist anywhere. If it is you do the lookup using the address of the string in the pool. The JudyL functions (http://judy.sourceforge.net/) provide a very efficient 'integer hash'. Tim.
Re: nci
On Mon, Jan 12, 2004 at 01:01:58PM -0600, Garrett Goebel wrote: Tim Bunce wrote: Tim Bunce wrote: I see Dan says in his blog Yeah, I know, we should use libffi, and we may as a fallback, if we don't just give in and build up the function headers everywhere. I'm not familiar with libffi so this may be a dumb question, but why the apparent reluctance to use it? In http://www.nntp.perl.org/group/perl.perl6.internals/253 I see Garrett Goebel quotes Bruno Haible saying I could agree to the LGPL license. Perl could then use ffcall as a shared library (linked or via dlopen) And I see http://www.parrotcode.org/docs/faq.pod.html says Code accepted into the core interpreter must fall under the same terms as parrot. Library code (for example the ICU library we're using for Unicode) we link into the interpreter can be covered by other licenses so long as their terms don't prohibit this. So it seems there's no licensing issue preventing parrot using libffi. Is that right? Are there any others? My bad. In my comments on Dan's blog, I confused libffi with ffcall. Both do roughly the same thing... The libffi was originally produced by Cygnus, but is now part of GCC. http://sources.redhat.com/libffi/ http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/LICENSE ffcall was produced by Bruno Haibel as part of his CLISP package. http://www.haible.de/bruno/packages-ffcall.html ffcall used to be considered more mature/stable, but since libffi was included in GCC the general impression true or not is that libffi is more actively maintained. From mailing lists and csv logs, it looks like both are actively maintained... And since it seems both are usable for parrot from a licencing perspective we're free to use whichever suits best on a given platform - assuming someone implements the relevant interface code. Tim.
Re: Mr Parrot's Neighborhood
On Tue, Jan 13, 2004 at 10:01:32AM +0100, Leopold Toetsch wrote: Michal Wallace [EMAIL PROTECTED] wrote: Here's my guess: [lots of good stuff from leo] Is there a Parrot Architecture Overview document that summarises this kind of high-level view with links to the deeper docs? If not it would be great to have. Tim.
Docs and releases
Has a date been set for the next release? Are the docs (especially the PDDs) upto date on best practices? If not, will that be a goal for the next release? Tim.
Re: nci
On Sat, Jan 10, 2004 at 09:42:14PM +, Tim Bunce wrote: On Sat, Jan 10, 2004 at 08:31:21PM +0100, Leopold Toetsch wrote: Jeff Clites [EMAIL PROTECTED] wrote: I assume the plan is to get on-the-fly building of NCI stubs working everywhere. Platforms where that works don't need the functions generated by build_nativecall.pl, but right now that's only i386; it's a JIT-like and pretty difficult piece of code to write, but it should eventually work on every platform which supports JIT, at least. It looks like, that we can't get each possible permutation of signatures built statically. This would also boost executable size beyond any reasonable limits. I'ts a JIT-like code but its not too difficult to implement and indpendent of JIT is implemented. It just needs a bit of knowledge of the architectures ABI (how functions get their params and return these) and of course how to implement that. I'm really not an assembly code hacker, but JITted NIC for i386 was implemented really quickly. I see Dan says in his blog Yeah, I know, we should use libffi, and we may as a fallback, if we don't just give in and build up the function headers everywhere. I'm not familiar with libffi so this may be a dumb question, but why the apparent reluctance to use it? In http://www.nntp.perl.org/group/perl.perl6.internals/253 I see Garrett Goebel quotes Bruno Haible saying I could agree to the LGPL license. Perl could then use ffcall as a shared library (linked or via dlopen) And I see http://www.parrotcode.org/docs/faq.pod.html says Code accepted into the core interpreter must fall under the same terms as parrot. Library code (for example the ICU library we're using for Unicode) we link into the interpreter can be covered by other licenses so long as their terms don't prohibit this. So it seems there's no licensing issue preventing parrot using libffi. Is that right? Are there any others? Tim.
Re: nci
On Sat, Jan 10, 2004 at 08:31:21PM +0100, Leopold Toetsch wrote: Jeff Clites [EMAIL PROTECTED] wrote: I assume the plan is to get on-the-fly building of NCI stubs working everywhere. Platforms where that works don't need the functions generated by build_nativecall.pl, but right now that's only i386; it's a JIT-like and pretty difficult piece of code to write, but it should eventually work on every platform which supports JIT, at least. It looks like, that we can't get each possible permutation of signatures built statically. This would also boost executable size beyond any reasonable limits. I'ts a JIT-like code but its not too difficult to implement and indpendent of JIT is implemented. It just needs a bit of knowledge of the architectures ABI (how functions get their params and return these) and of course how to implement that. I'm really not an assembly code hacker, but JITted NIC for i386 was implemented really quickly. I see Dan says in his blog Yeah, I know, we should use libffi, and we may as a fallback, if we don't just give in and build up the function headers everywhere. I'm not familiar with libffi so this may be a dumb question, but why the apparent reluctance to use it? Tim.
Re: More object stuff
On Sat, Dec 27, 2003 at 01:02:34PM +, Harry Jackson wrote: Dan Sugalski wrote: Dunno if I replied, but... Next step is a higher level wrapper, if you're up for fiddling with Postgres itself. Stuff like a single call to connect (right now you have to make the connect call and poll over and over again), I did some benchmarks using your original library a few weeks ago and I did find the polling business a bit odd. I replied a while back asking asking if anyone had any pointers or examples on where to start this no matter how simple but I think Warnock's Dilema #2 may have kicked in. Being fairly new to parrot and probably naive I can see a few different ways of doing this. A C wrapper ie: parrot/classes/parrotdbi.pmc etc A C wrapper ie: parrot/dynclasses/parrotdbi.pmc etc A loadable pasm function library that uses the current libpq/(other libs) and available available ops. Please avoid using dbi and dbd in names for now. getting back a full row as an array, getting back a full row as a hash, and stuff like that. Nothing fancy, and nothing that high-level, but enough to work the basics without quite as manual work as the current libpg requires. This'll probably be the basis for the DB driver interface for Parrot's DBI library, so this is your chance to make a mark. :) Cheers for the opportunity. Best wishes. Tim.
Re: [CVS ci] object stuff
On Wed, Dec 10, 2003 at 01:37:22AM -0700, Luke Palmer wrote:
I think a heirarchy is a good idea for namespacing in general. I've
always wanted to be able to tie namespaces in Perl 5. It would only
make sense that if I tie Foo::, that Foo::anything:: would also go
through that tie to get the anything:: stash.
That's a good point.
Another related one include any perl code that
manipulates/introspects/iterates over a package.
Package aliasing (something like *{Bar::} = \*{Foo::}) might
not work well in Perl 5 but I think Perl 6 is meant to be able to
do things along those lines.
But there may be some misunderstanding here (perhaps just on my part :)
Given
package Foo::Bar::Baz;
$var = 1;
In perl5 the var variable is stored something like this (excuse the
probably imprecise syntax, but you'll get the idea):
*{Foo::}-{Bar::}-{Baz::}-{var};
For parrot I'm not sure if Dan was proposing
*{Foo\0Bar\0Baz}-{var};
or
*{Foo\0Bar\0Baz\0var};
The first just flattens the package name but keeps the contents of
the package as distinct elements within the package 'object'.
The second flattens both the package name and the name of the item
within the package into a single key.
I think Dan was proposing the first and that's fine.
I think the second would be a mistake.
Tim.
Re: [CVS ci] object stuff
On Wed, Dec 10, 2003 at 12:26:04PM -0500, Melvin Smith wrote:
At 12:16 PM 12/10/2003 +, Tim Bunce wrote:
*{Foo\0Bar\0Baz}-{var};
or
*{Foo\0Bar\0Baz\0var};
[snip]
I think Dan was proposing the first and that's fine.
I think the second would be a mistake.
Using a character that won't collide with HLL has a disadvantage [...]
I should clarify that I wasn't suggesting \0 itself was good, just the
principle that package names are stored as a single string and the names
of package contents don't include the package name.
I've no strong view about \0 vs other (presumably utf8) byte sequences.
Tim.
Re: Calling conventions. Again
Does C++ style 'name mangling' have any relevance here? I also had some half-baked thought that a HLL could generate two entry points for a prototyped sub... one with the mangled name encoding the expected arguments and types (p/s/i) for high-speed no-questions-asked-nothing-checked use, and... also generate a non-mangled entry point that would check/massage the params and then call the name-mangled entry point. Am I totally mad? Tim [ducking]
Re: More interface files
On Tue, Oct 07, 2003 at 03:57:54PM -0400, Dan Sugalski wrote: While I'm having a heck of a time getting anything besides a connection to happen with it... I've checked in library/postgres.pasm. It's an interface to Posgres 7.3's libpq (the C interface to postgres) library. On a vagely related note, is anyone looking into using the header files parsing abilities of ExtUtils::XSBuilder and extending it to generate pasm? Tim.
Re: Notifications
On Thu, Aug 28, 2003 at 07:26:25PM -0400, Dan Sugalski wrote: How does it work? Simple. When a watched resource does what we're watching for (it changes, an entry is deleted, an entry is added [...] Only after the action being watched is performed I presume. Any implementation details? (maybe I missed them) Will it be implemented via vtable changes, proxy objects, or ...? we post an event to the event queue. When that event is processed, whatever notification routines were registered are run. Very simple. The async nature of this approach needs to be kept in mind. It will often be important that the 'thread' handling the event queue runs at a high priority. (Perhaps it would help to have a simple flag on each watch to say if a yield() should be performed after posting an event for that watch.) Because there's all sorts of stuff we need to watch for performance reasons. The big thing the engine will use this for is class changes--for example when a class adds or deletes an attribute, all objects of that class or its subclasses needs to change. The easiest way to do this is have each subclass register a notification on its parent classes. What happens, or could happen, between the event being queued and it being actioned? What does this have to do with weak references? Weak references are just references that aren't part of the root set and have a destruction notification pending on the thing they weakly refer to. When that thing is destroyed, the notification the weak ref PMC has registered will get run and invalidate the weak reference. And what happens if the weak ref is used between the thing it refers to being destroyed and the notification event being acted on? Tim.
Re: What the heck is: timely destruction
On Sun, Aug 24, 2003 at 10:48:02AM -0700, Steve Fink wrote: It would probably make discussion easier if people switched to using better terminology. I prefer using destruction to mean the memory for an object actually getting freed, and finalization for whatever cleanup actions an object performs at some point after it is no longer accessible. So timely destruction is not very important, because destruction only needs to be timely enough to avoid running out of memory. Timely finalization is what we spend much time talking and worrying about. In Perl5, if you didn't think about it too hard then you could get away with thinking of them as being the same thing, even though they never really were. I guess you could think of the lifecycle of an individual object as being controlled by a few significant life events: 1. birth 2. the last reference disappearing 3. finalization 4. destruction That's a nice idea, but I suspect most people are thinking in perl5 terms of Timely DESTROY, so destruction is bound to be more commonly used. Tim.
Re: String API
On Tue, Aug 19, 2003 at 12:07:22AM -0400, Benjamin Goldberg wrote: There are a number of shortcomings in the API, which I'd like to address here, and propose improvments for. Just to be sure people are keeping it in mind, I'll repost this from Larry: On Wed, Jan 30, 2002 at 10:47:36AM -0800, Larry Wall wrote: For various reasons, some of which relate to the sequence-of-integer abstraction, and some of which relate to infinite strings and arrays, I think Perl 6 strings are likely to be represented by a list of chunks, where each chunk is a sequence of integers of the same size or representation, but different chunks can have different integer sizes or representations. The abstract string interface must hide this from any module that wishes to work at the abstract string level. In particular, it must hide this from the regex engine, which works on pure sequences in the abstract. Tim.
Re: async i/o (was Re: This week's summary)
On Thu, Jul 03, 2003 at 05:10:23PM -0400, Uri Guttman wrote: AB == Alan Burlison [EMAIL PROTECTED] writes: AB Dan Sugalski wrote: The more I think about this the more I want to punt on the whole idea. Cross-platform async IO is just one big swamp. AB Agreed. Glug, glug, glug ;-) who here will be at oscon (or yapc::eu)? i would like to get a small BOF going on this subject. i agree it is a morass but i have some ideas and i know dan has plenty. but we had better learn to swim these swamps and not get eaten by the gators. we can drain them, convert them to dry deserts and make them safe for camel caravans. :) Has any other language learnt to swim well in these swamps? Tim.
Re: The Judy algorithm
On Mon, Mar 10, 2003 at 03:33:38PM +0100, Elizabeth Mattijsen wrote: At 10:37 + 3/10/03, Tim Bunce wrote: I think this might be interesting to some of you... Judy is a general purpose dynamic array implemented as a C callable library. Judy's speed and memory usage are typically better than other data storage models and improves with very large data sets. http://judy.sourceforge.net/application/10minutes.htm http://judy.sourceforge.net/application/ http://sourceforge.net/projects/judy I've appended a few extracts from the 10minutes.htm url given above. This looks very interesting (particularly for a project I'm working on now, which was the reason I looked into this right now), but the project really seems quite silent if not dead. I emailed Doug [CC'd] with your concerns. Here's his reply. Tim. From: [EMAIL PROTECTED] Subject: Re: (Fwd) Re: The Judy algorithm Date: Mon, 10 Mar 2003 22:40:25 Tim: I will try to reply to your concerns below. Doug, I've just flagged Judy to the perl6-internals list (who are developing the 'parrot' virtual machine) and they've raised some concerns (below). Could you tell me about the status of the Judy code. Is it being maintained? Yes, but I am not much of a process person. The versions that install and compile other platforms are prelimary and need more testing. They are available in http://judy.sourceforge.net/downloads (see README). Tim. - Forwarded message from Elizabeth Mattijsen lt;[EMAIL PROTECTED]gt; - Delivered-To: [EMAIL PROTECTED] In-Reply-To: lt;[EMAIL PROTECTED]gt; Date: Mon, 10 Mar 2003 15:33:38 +0100 To: Tim Bunce lt;[EMAIL PROTECTED]gt;, [EMAIL PROTECTED] From: Elizabeth Mattijsen lt;[EMAIL PROTECTED]gt; Subject: Re: The Judy algorithm At 10:37 + 3/10/03, Tim Bunce wrote: gt;I think this might be interesting to some of you... gt; Judy is a general purpose dynamic array implemented as a C callable gt; library. Judy's speed and memory usage are typically better than gt; other data storage models and improves with very large data sets. gt; gt;http://judy.sourceforge.net/application/10minutes.htm gt;http://judy.sourceforge.net/application/ gt;http://sourceforge.net/projects/judy gt;I've appended a few extracts from the 10minutes.htm url given above. This looks very interesting (particularly for a project I'm working on now, which was the reason I looked into this right now), but the project really seems quite silent if not dead. Some more info: Only HP-UX and Linux seem to be supported out of the box (only tried Linux and Mac OS X). I adapted the indexSL program to just be a filter and piped /usr/share/dict/words through it. Then let it run with Valgrind. That reports: ==11948== LEAK SUMMARY: ==11948==definitely lost: 11 bytes in 1 blocks. ==11948==possibly lost: 26 bytes in 2 blocks. ==11948==still reachable: 0 bytes in 0 blocks. Not a whole lot of leakage, but still. I agree any leakage is unacceptable. However, Judy is tested carefully to not have leakage. Memory usage (from malloc()) is kept internally to the structure and must subtract (free()) to exactly zero when the last element is deleted from the array. Perhaps there is a problem in the measurement. I would like to know more about the measurement to be certain that the problem is not in Judy. JudyL and Judy1 only allocate blocks in multiples of 4 bytes. I got the configure script into believing that MacOS X is really Linux. Compilation then halts on byteswap.h being missing. I didn't look any further then. The versions in the download directory (mentioned above) should solve this problem. However, I think it requires gmake. The forum seems to be missing answers from the primary (only) developer. Bug reports with patches have not been applied (such as trivial bashisms in the configure script). The application directory contains some nice examples that might be applicable to Parrot: especially the best of both worlds approach in which Judy arrays are used to handle hash value collisions on a rather small (256 or 64K keys) hash. If a hashing scheme (of strings) is able to solve your problem (just store and retrieves) then I suggest using JudyL inplace of your normal hash table. This makes a very scalable hashing method. The performance is better than any known tree method (including JudySL). Just my 2 eurocents worth (which appear to be worth more than 2.1 US$ cents nowadays ;-) Liz - End forwarded message - I will be available for your questions and comments. Doug Baskins [EMAIL PROTECTED]
The Judy algorithm
I think this might be interesting to some of you... Judy is a general purpose dynamic array implemented as a C callable library. Judy's speed and memory usage are typically better than other data storage models and improves with very large data sets. http://judy.sourceforge.net/application/10minutes.htm http://judy.sourceforge.net/application/ http://sourceforge.net/projects/judy I've appended a few extracts from the 10minutes.htm url given above. Tim. A (CPU) cache-line fill is additional time required to do a read reference from RAM when a word is not found in cache. In today's computers the time for a cache-line fill is in the range of 50..2000 machine instructions. Therefore a cache-line fill should be avoided when fewer than 50 instructions can do the same job. (Modern machines tend to pipeline writes to RAM. They often take no additional time in the Judy design.) Some of the reasons Judy outperforms binary trees, b-trees, and skip-lists: * Judy rarely compromises speed/space performance for simplicity (Judy will never be called simple except at the API). * Judy is designed to avoid cache-line fills wherever possible. (This is the main design criteria for Judy.) * A b-tree requires a search of each node (branch), resulting in more cache-line fills. * A binary-tree has many more levels (about 8X), resulting in more cache-line fills. * A skip-list is roughly equivalent to a degree-4 (4-ary) tree, resulting in more cache-line fills From a speed point of view Judy is chiefly a 256-ary digital tree or trie (per D. Knuth Volume 3 definitions). A degree of 256-ary is a somewhat magic N-ary for a variety of reasons -- but mostly because a byte (the least addressable memory unit) is 8 bits. Also a higher degree means reduced cache-line fills per access. You see the theme here -- avoid cache-line fills like the plague. The presence of a CPU cache in modern machines has changed many of the ways to write a performance algorithm. To take advantage of a cache, it is important to leverage as much as possible. In a Judy tree, the presence of a cache results in 1..3 (or more) fewer cache-line fills per lookup than would be possible without a cache. Judy adapts efficiently to a wide range of populations and data set densities. Since the Judy data structure is a tree of trees, each sub-tree is a static expanse that is optimized to match the character or density of the keys it contains. Notice that to insert or delete a key is almost as simple as setting or clearing a bit.
Re: Copyright notices and license stuff
On Tue, Oct 29, 2002 at 05:18:53AM -0800, James Michael DuPont wrote: The gcc interface project has been offically restarted. http://gcc.gnu.org/ml/gcc/2002-10/msg00806.html Congratulations. I think it's an important project. Tim.
Re: Would a getting started guide help
On Wed, Oct 02, 2002 at 12:28:57PM -0400, Dan Sugalski wrote: At 12:15 PM +0100 10/2/02, Tim Bunce wrote: On a related note, are there any good tools for static code analysis around? The usual cross-reference stuff would be handy, but ideally something that goes further. If someone wants to build some and there are things that parrot doesn't provide that would make it easier, speak up--while I won't promise we'll design in things for it, we certainly can't if we don't know. Seeing my post mentioned 'in brief' in Leon's summary made me think I should at least do some googling of my own... I turned up this one: http://www.gnu.org/software/gcc/news/egcs-vcg.html http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html Tim.
Re: Would a getting started guide help
On a related note, are there any good tools for static code analysis around? The usual cross-reference stuff would be handy, but ideally something that goes further. Graphical would be good, interactive better (or at least cooler :). Perhaps something like www.kartoo.com (needs flash) or http://www.touchgraph.com/TGGoogleBrowser.html (needs java) that lets you explore the relationships between things. And, in case you're not familar with it, the ID database is a very useful tool (quite old and alomost lost in the mists of time): http://www.math.utah.edu/docs/info/mkid_toc.html I highly recommend it. Tim. On Sat, Sep 28, 2002 at 10:46:36PM -0400, Erik Lechak wrote: Hello All, I hope this is the correct place for my post. I have not seen many (or any) newbie parrot questions on this group. Please direct me to the correct group and forgive my intrusion if this message is misposted. I would like to start helping in the development of parrot. I have read the documentation, the design docs, and went over the source, but I am still a little lost. I would eventually like to help with the coding, but it appears that there may be a pressing need for a document helping newbie developers figure out how to get started. I would be willing to take on this task (Well at least until I learn enough so that I can code.) 1)If you would like me to do it, who would I send the document and its updates to? 2)I am a diagram oriented person. If I include diagrams (gifs, png ...) in the document, how would you want me to do this (html, ref the image file ...)? Any prefs in the image format? 3)Do I have to use pod? No offense, but I can't stand pod. The pdd design document states that pod is the ...documentation language for All Things Perl, but this is Parrot not Perl. And this document would not be a design doc. If Parrot is supposed to be a cross language VM, why do people need to know pod to read (or write) the docs? I know that it is easy to convert pod to an easy to read format, but would a developer with little perl experience know that? Parrot is trying to encourage developers from areas other than perl, so why discourage them by introducing them to parrot with pod documents. Could there possibly be a parrot comment style? It could be used instead of other comment styles internal to parrot. Use it in the c-code, the perl code, the parrot assembly code, and to write the documentation. Then a (perl) preprocessor could strip it out before it is compiled or run. Normally I would not suggest such a thing, but there is a lot of code generation and manipulation going on anyway. It could allow for document generation of all the parrot source, assembly, tests, and documents into a javadoc-like html reference. Or maybe I'm just dreaming. Please go easy on me for not liking pod. Thanks, Erik Lechak
Re: Perl5 humor
On Mon, Jun 24, 2002 at 05:58:23PM -0500, Dan Sugalski wrote: At 9:50 PM +0100 6/23/02, Tim Bunce wrote: On Mon, Jun 17, 2002 at 07:59:33PM -0400, David J. Goehrig wrote: qw/ who is praying for parrot to support XS code, cause he doesn't want to rewrite SDL_perl's 11,000 lines /; I'm sure that's not going to happen. Much more likely is some kind of wrapper that manages a simple perl5-like run-time environment (stacks, marks, gimme, symboltable etc) plus source-code compatibility support (macros, functions etc) that's just sufficient to keep old XS code happy. Right. Parrot's not going to have XS as an interface--that'd be insane. I'd like to have at least a partially compatible interface that can be used to help the transition. Plain SV type things (getting/setting values), and some of the AV/HV things should be doable as well. Simple sub calling and suchlike things ought to also be doable with a thunking layer of some sort. I don't expect most of the stuff in perlguts, most of which is nasty to deal with, to be provided, though. If someone wants to start a list of *sensible* entries in perl 5's API that should be provided, we can work from there. Perhaps start with a perl script that reads extension source code (xs|c|h) and spits out details of what perlapi/guts have been used. Feed it N popular extensions, sort the results by frequency and we'd get a (self maintaining) list of what we'd need to support. Tim.
Re: Perl5 humor
On Tue, Jun 25, 2002 at 11:35:20AM +0100, Dave Mitchell wrote: On Tue, Jun 25, 2002 at 11:08:53AM +0100, Tim Bunce wrote: On Tue, Jun 25, 2002 at 12:23:34AM +0100, Dave Mitchell wrote: Of course, another approach is to embed the existing Perl5 interpreter within the Perl 6 interpreter; Perl6 subs call glue which calls Perl subs which calls perl5 XS. How would you deal with passing references? (wild hand waving follows) a perl6 reference is substituted with a perl5 scalar that has attached magic that 'does the right thing'. I don't think that'll fly. Tim.
Re: Perl5 humor
On Tue, Jun 25, 2002 at 05:17:56PM +0100, Dave Mitchell wrote: On Tue, Jun 25, 2002 at 04:45:37PM +0100, Tim Bunce wrote: On Tue, Jun 25, 2002 at 11:35:20AM +0100, Dave Mitchell wrote: On Tue, Jun 25, 2002 at 11:08:53AM +0100, Tim Bunce wrote: On Tue, Jun 25, 2002 at 12:23:34AM +0100, Dave Mitchell wrote: Of course, another approach is to embed the existing Perl5 interpreter within the Perl 6 interpreter; Perl6 subs call glue which calls Perl subs which calls perl5 XS. How would you deal with passing references? (wild hand waving follows) a perl6 reference is substituted with a perl5 scalar that has attached magic that 'does the right thing'. I don't think that'll fly. Quite possibly not. But Larry's reply to one of my postings on p6l led me to belive that was the direction we were going to head in. I may have misunderstood him: There's more than one way to do it :) Having a perl5 interpreter (or parts of one) embeded in perl6 may be useful for some things. But the reference passing problem makes me think it's not going to be practical for XS. But we might not know for sure till we try. Tim. From: Larry Wall [EMAIL PROTECTED] To: Dave Mitchell [EMAIL PROTECTED] cc: Simon Cozens [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Tue, 4 Jun 2002 10:06:44 -0700 (PDT) Subject: Re: Half measures all round On Tue, 4 Jun 2002, Dave Mitchell wrote: Having said that, I have real, real doubts that Perl 6 will ever be able to execute Perl 5 code natively. Its not just a case a writing a new parser and some P5-specific ops; P5 has so many special features, boundary conditions and pecularies, that to get P6 to execute P5 is a task equivalent to reimplementing P5 from scratch. I'm wondering if instead, we continue to maintain the P5 src tree, and embed P5 within P6 (embed in the sense of Apache and Mod_perl). Sick and ugly, but maybe more practical than the alternatives. It also means that the P6 src doesn't have to be saddled with knowing (much) about P5. Eventually of course the P5 bit would have to be thrown away. That's exactly what I've been arguing for all along. Grr And that's why I see the package hack and the new :p5 modifier as having the weight of two features, not the weight of an entire re-implementation of Perl 5. It's really not that difficult to run two interpreters in the same process. I already made Perl and Java run together nicely. If anything the impedence mismatch between Perl 5 and Perl 6 will be even less. Scaffolding is supposed to be ugly. You wouldn't believe how ugly the transitional form between Perl 4 and Perl 5 was, when half the opcodes were interpreted by the old stacked interpreter, and half by the new stackless one. Larry -- In England there is a special word which means the last sunshine of the summer. That word is spring.
Re: Perl5 humor
On Mon, Jun 17, 2002 at 07:59:33PM -0400, David J. Goehrig wrote: qw/ who is praying for parrot to support XS code, cause he doesn't want to rewrite SDL_perl's 11,000 lines /; I'm sure that's not going to happen. Much more likely is some kind of wrapper that manages a simple perl5-like run-time environment (stacks, marks, gimme, symboltable etc) plus source-code compatibility support (macros, functions etc) that's just sufficient to keep old XS code happy. If someone wants to champion that work I'll certainly contribute. Tim [who doesn't want to rewrite the DBI's ~4000 lines or tell the many DBD authors that they have to rewrite their drivers].
Re: [COMMIT] inc/dec/add ops and new PMC methods
On Sun, May 19, 2002 at 06:01:56PM +0100, Nicholas Clark wrote: Seriously though - is it possible to automate testing how many ops don't have tests? That way we could have a test that looked for untested ops, and failed if any weren't tested. I guess it couldn't easily be very sophisticated, in that it would really only have to verify that all ops were mentioned somewhere in the body of a test, but I think it could be quite useful. Or looking at it from the other end... automated coverage analysis of executed code would be a useful addition. Post processing the results could yield per-op, or at least per pmc, coverage value. I know coverage analysis isn't perfect but for ops in particular the devil is in the details and the edge cases are important. Tim.
Re: gcc backend
On Wed, May 01, 2002 at 10:09:11AM -0400, Jeff wrote: Nick Glencross wrote: Has anyone given any thought to a gcc backend for generating parrot assembler? Even with a partial implementation in place, it would be presumably be possible to use much of core C, with the benefits of register allocation, optimiser etc. Obviously it wouldn't be able to use much of parrot's powerful string handling or PMCs though, as C cannot convey these concepts. Of course, these could probably be hacked in as pseudo-function calls. Any thoughts? Anyone tried? Hi, Nick. I think that question is covered in the Parrot FAQs. Try http://www.parrotcode.org/faq/#why aren't you using external tool or library x for more information. I don't think licening issues should prevent any particular avenue being explored by anyone interested in it, so long as they understand the implications (in terms of what would/wouldn't be accepted into the Parrot distribution). The FAQ should probably say as much. I'm not sure what the licening issues would be in this case anyway. Being able to target any gcc suported language to parrot sure seems like a good idea to me. In theory at least. If only for random experimentaion and stress testing of parrot. Tim.
Re: Subroutines...
[ I'm playing devils advocate for a while longer as I'm not 100% convinced ] On Mon, Apr 29, 2002 at 10:53:40AM -0400, Dan Sugalski wrote: At 9:50 AM +1000 4/29/02, Andrew J Bromage wrote: G'day all. On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote: We're going caller-save. I think I made this declaration before, but now it's backed up with pure PDD goodness. :) The first thing to realise is that this violates the principle of callee does everything important to it. :-) Sure, but saving registers isn't something the callee finds important. The saved registers aren't important to it. I don't think that's a good argument. It should be a good citizen. Not write on memory it shouldn't and not mess with a (non scratchpad) register without saving it. Yup, caller save doesn't necessarily favor code like this. On the other hand, it does favor recursive code I don't think that's a good argument. Not enough recursive code to matter. and code with heavier-weight bodies. that don't make lots of calls to leaf code (little methods etc). As the 'weight' of the code body increases the register saving becomes insignificant anyway - unless the code is making lots of calls. It's always a toss-up. Nothing's free, and all decisions have consequences of some sort. Sure. Maybe half a dozen registers used in each one at the most. A caller is obliged to save _all_ its registers in order to call these trivial subs. Nope, just the registers it needs preserved across calls. It needs to save the data that *is* relevant, where on callee save the data that *might* be relevant needs saving. If the caller knows what registers it's using and thus need saving, why can't the callee also know what registers it is going to use and thus need saving? Isn't compiler convienience a (the?) major issue here? The question, of course, is whether there's as much potentially relevant data as actually relevant data. Assuming that the caller and callee spend about the same amount of time saving data (An assumption that's a bit dodgy there, as it's based on the coding style the language encourages) caller-save is ultimately a bit less expensive, as making tail calls avoids a push/pop pair, which callee-save can't avoid. How common do you expect tail calls to be? (Got practical examples?) Seems to me like compiler convienience and tail call efficiency are the main issues. Tim.
Re: Please rename 'but' to 'has'.
On Fri, Apr 26, 2002 at 11:33:06AM -0400, Dan Sugalski wrote: At 2:26 PM +0100 4/26/02, Nicholas Clark wrote: On Tue, Apr 23, 2002 at 01:25:15PM -0400, Dan Sugalski wrote: At 12:36 PM -0400 4/23/02, Buddha Buck wrote: OK, but that limits you to the, um, 24 standard levels of precedence. What do you do if you don't think that that's enough Internally precedence is going to be stored as a floating-point number. Dunno how it'll be exposed at the language level, but at least there'll be more than just 20 or so levels. Why store precedence as floating point rather than integer? [Or did I miss a design document} Because, while you may run into problems fitting something in between 1.001 and 1.002, it's not a problem to fit something between 3 and 4. Floating point precedence is a problem at the edge, but integer precedence makes things potentially difficult for user-added operators if you want to fit things between the standard operators. Is it worth it? For perl at least I thought Larry has said that you'll be able to create new ops but only give them the same precedence as any one of the existing ops. Why not use a 16 bit int and specify that languages should use default precedence levels spread through the range but keeping the bottom 8 bits all zero. That gives 255 levels between '3' and '4'. Seems like enough to me! Floating point seems like over-egging the omelette. Tim. p.s. I missed the start of this thread so I'm not sure why this is a parrot issue rather than a language one. I also probably don't know what I'm talking about :)
Re: Subroutines...
On Mon, Apr 22, 2002 at 01:52:30PM -0700, Brent Dax wrote: How about we instead declare that all subs have One True Entry Point, and the sub does whatever is needed there? Normal subs can just set up scoping and jump to the beginning of the sub's body; coroutines retrieve their context object and use it; XS and JIT call enternative; etc. That way we only pay for the overhead on subs that need it. I agree. I've no strong opinions on how it's done, but I do believe that it's *very* important that subroutine calls be as fast as possible (and significantly faster than perl5). This must be a priority. To my mind that means that a subroutine should be responsible for setting up whatever _it_ needs (and ideally only what it knows it needs). Then the sub code is encapsulated and can be changed at runtime. Tim.
Re: [PATCH] Re: Is there a way to turn GC completely off?
On Mon, Apr 15, 2002 at 01:05:41AM -0400, Mike Lambert wrote: As a follow-up, I found one bug. Rather odd it is. The symptom is loading a program, doing a LIST and seeing only part of the code. Dumping the string-which-contains-the-code you can see the entire program in it (unlike the earlier described bug). The problem was in here: Clint, in terms of getting things in Parrot fixed, I think it's better if you can provide a way to generate the bug, no matter how complex the case is. Non-simple test cases are better than no test cases at all, imo. This is hugely important. A regression test suite is an invaluable comodity. Bug fixing should nearly always start with creating and submitting a new test for the test suite that triggers the bug. That's the best way to ensure the bug doesn't reappear N days, weeks, or months later (and cost some other poor developers hours or days of wasted time). Tim.
Re: Multimethod dispatch for parrot?
On Thu, Mar 07, 2002 at 01:48:49PM -0500, Dan Sugalski wrote: First, there are basic native types such as num, int, and string, which I'm perfectly fine with. But what bothers me is the fact that bigint's and bignum's are being given a special place in the vtable. Why? They're base types, really. I'd like to add in support for complex numbers too, but I've not yet gone that far. Might next week, you never know. Why? Why should complex numbers be base types? Why should bigint's and bignum's be given special treatment? (I understand Brent's point that you want to overflow to bigint's and bignum's, but that doesn't require special treatment, only that they be available for creation.) If parrot is supposed to be fully extensible then let it eat it's own dog food. It should use the extensibility it offers to others to implement it's own extensions. Any special treatment of extra internal types implies that that special treatment isn't available to types added at runtime. Tim [not really paying attention so possibly ranting needlessly]
Re: Extensions
On Fri, Mar 01, 2002 at 05:17:28AM -0800, Brent Dax wrote: After banging my head against a wall for a few hours with Perl 5's XS, I have an idea for how Parrot can do it better I'm not sure about Parrot, but for Perl 6 Larry has specifically said that he intends to extend to Perl sub declarations to enable them to contain all the information required to link to external libraries But that might have to wait for Apocalypse 21 Also, on a tangent, I hope someone is pondering, or planning to ponder, the practicallity of some kind of perl5 XS to perl6 interface that would enable perl5 extensions to be ported to perl6 with less effort than a complete rewrite It needn't be clean, elegant, or fast, but I think there's too much good work on CPAN to ignore Tim
