Re: [perl #48365] get_string() on Fresh Key PMC Causes Infinite Loop
On Saturday 08 December 2007 18:45:28 chromatic wrote: My favorite option so far is to check if the Key PMC has any flags set and call key_string() if so. Otherwise, it returns the empty string. All coretests pass without infinite loops with this patch applied. Thanks, applied as r23693. You're completely awesome. -- c
Re: [ANN] SF parrot win32
Andrew Shitov wrote: I have no personal web site, so I create the project parrotwin32 on sourceforge : http://parrotwin32.sourceforge.net/ Cool, and I also promoted it at http://perl6.ru/parrotwin32/. But an attempt to run perl6.pbc faied: C:\Program Files\parrot-0.5.0-develbin/parrot.exe languages/perl6/perl6.pbc load_bytecode couldn't find file 'PGE.pbc' current instr.: 'parrot;Perl6::Compiler;__onload' pc 0 (perl6.pir:30) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) Probably setup.exe have to update an environment also? I've found the problem. Don't install Parrot in C:\Program Files\parrot-0.5.0-devel (the proposed path). You must install Parrot in C:\usr\local\parrot-0.5.0 (the letter drive could be change). I've generated Parrot with prefix=/usr/local/parrot-0.5.0. François. -- Andrew Shitov __ [EMAIL PROTECTED] | http://www.shitov.ru
Re: [ANN] SF parrot win32
Xiao Yafeng wrote: Cool! But if it could include doc would be better. Many doc are available in share/doc/parrot/docs (POD format). François. On Dec 5, 2007 11:38 PM, François Perrad [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I have no personal web site, so I create the project parrotwin32 on sourceforge : http://parrotwin32.sourceforge.net/ This project supplies only binaries for Windows ( setup.exe form) of the monthly releases. I hope that help Parrot end-users (on Windows) and promote the use of Parrot. François Perrad.
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.
Re: Standards bearers (was Re: xml and perl 6)
Why thank you Mr. Chromatic! In between all my other activities, I have been trolling along this list from its inception, and followed eagerly every Appocalpse, Exegisis and Synopsis as soon as they came on line. I download pugs and parrot from SVN repositories, written tests - one of which still hangs the compilation of pugs. Indeed the test I wrote for pugs concerned the ability of pugs to use existing CPAN modules. I have tried parrot with SDL and the tests fail. My aim was to write a P6 GUI module so that from the start it would be easy for P6 users to generate UI interfaces easily. Unfortunately, despite my eagerness, I am not a professional programmer with the time or the skill to fix the problems. Where I can contribute is to express a view about how P6 might best be developed. Moreover, I do think that sketching out the way modules should (at least initially) be written, and skteching out which modules should be written as soon as possible, are as much a part of the language design as deciding how best to use the colon. Moreover, consider the development of pugs. The first modules to be developed were Test and Test::Harness. Vital for the development of the language. Not a part of the core. Equally, Something to replace CGI or DBI will be essential to the uptake of P6. I would far prefer to have a skilled and resourceful professional, such as yourself or Damian Conway write these modules than leave it to enthusiastic amateurs such as myself. And as for singularities, I appreciate Larry's idea of language development as being akin to a strange attractor (expressed in answer to a question I posed on this list nearly a year ago about when P6 would be complete), but I also fear that the orbits that describe solutions to some strange attractors have a great deal of volatility and it is never possible to define at any time exactly what the orbit is - a bit like not being able to define all aspects of an electron due to Heisenberg's uncertainty principle. But if that is the case with P6 (and why should it not given the wholly new areas of programming that P6 is defining?) where does that leave people like me? Does it mean that we must abandon P6 to the professionals, just as strange attractors and quantum physics are the domain of professional scientists? Does it mean that I must, as it now seems to be the case, move my own programming and the main language of my firm's IT department to Python? I realise that @Larry have their own priorities, their own pressures, their own limited resources. I would like to help, yet there are limits to what I can do. And I am sure what is true for me is true for many others trolling on this list. You are doing a fine and wonderful job. Your efforts - I sincerely believe - should be applauded and appreciated. My impatience is due to a heightened expectation and desire to use P6 that in fact is a result of the fantastic achievements I have already seen. Richard chromatic wrote: On Saturday 08 December 2007 06:50:48 Richard Hainsworth wrote: Surely, some concentrated thought by the inventive and resouceful minds of who lead this project should go into language utilisation and popularisation. My goodness, @Larry's pretty darn busy trying to build the core kernel of Perl 6 in such a way that the rest of the world can build beautiful and useful things around that kernel much in the same way that the CPAN as a whole is the shining gem of Perl 5. You, Mr. Hainsworth, and every other person reading this message from December 2007 through the singularity (aka Perl 7) officially have my permission to think about this yourself and pitch in! (Fixing the mixed metaphor in my first paragraph is a good start. Reading S11 is step two.) No one ever needed permission, but if it makes anyone feel better, there it is. -- c
[svn:parrot-pdd] r23695 - trunk/docs/pdds
Author: allison Date: Mon Dec 10 05:15:46 2007 New Revision: 23695 Modified: trunk/docs/pdds/pdd25_concurrency.pod Log: [pdd] Adding interface methods for event/exception handlers to concurrency PDD. Modified: trunk/docs/pdds/pdd25_concurrency.pod == --- trunk/docs/pdds/pdd25_concurrency.pod (original) +++ trunk/docs/pdds/pdd25_concurrency.pod Mon Dec 10 05:15:46 2007 @@ -43,14 +43,13 @@ =head1 DEFINITIONS -Concurrency is a parallel execution of units of code (on -multiprocessor machines), or a flexible ordering of units of code (on -single processor machines). For certain problem spaces, concurrency -offers significant speed gains by parceling out processor-intensive -activity or by ensuring that a wait for input or system resources -doesn't hold up the entire application. +Concurrency is a parallel execution of units of code (on multiprocessor +machines), or a flexible ordering of serial units of code (on single processor +machines). For certain problem spaces, concurrency offers significant speed +gains by parceling out processor-intensive activity or by ensuring that a wait +for input or system resources doesn't hold up the entire application. -A task is a unit of code that can be executed in parallel. +A task is a unit of code that can be executed concurrently. =head1 IMPLEMENTATION @@ -269,6 +268,25 @@ =back +=head3 Methods + +=over 4 + +=item add_handler + +$P1.add_handler($P2) + +Add an event or exception handler to the scheduler's list of handlers. + +=item find_handler + +$P1 = $P2.find_handler($P3) + +Search for an event or exception handler $P1, in scheduler $P2, for the task +$P3. Returns a null PMC if an appropriate handler is not found. + +=back + =head2 Task PMC API The interface of the Task PMC is also the minimum required interface for all
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.
Re: [ANN] SF parrot win32
You must install Parrot in C:\usr\local\parrot-0.5.0 (the letter drive could be change). C:\usr\local\parrot-0.5.0bin/parrot languages/perl6/perl6.pbc load_bytecode couldn't find file 'Protoobject.pbc' current instr.: 'parrot;PGE::Match;__onload' pc 0 (compilers/pge/PGE/Match.pir:14) called from Sub 'parrot;Perl6::Compiler;__onload' pc 0 (perl6.pir:30) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) Should some PATH be set before? (and there is no file Protoobject.pbc in the dist). -- Andrew Shitov __ [EMAIL PROTECTED] | http://www.shitov.ru
Re: Switch/Given and English, Was perl 6 grammar
snip I've never said that switch ... case was better than given ... when or that switch ... case was even a good construct. I have said that given ... when sounds weird as a construct (not mentionning the use of past participle and on top of that of an irregular verb). I understand the meaning and I can get over it but is proliferation of English idioms, words a good idea? There're bunch of words that could describe the same idea in a sligtly different manner. Perhaps writting a la smallTalk could be the solution. getting rid off all shortcuts and change them into explicit description entities and write english sentences, not programs. This could be nice but I will first have to learn English. Anyway, I will write my own 'Lingua::Given::Francais' with avec ... lorsque^^: (well, if I can - ^^; xx 1000 ) And that for me is the power of P6 - the fact that you WILL be able easily to write such a module. In fact, why not write a module Lingua::Francais that maps all the P6 constructs into French, thus making it much more accessible to the vast number of people whose primary and major secondary language is French. Ditto, Chinese, Russian and Spanish. Indeed, if that is done at the start of the utilisation of P6, it would ensure that P6 is used across the globe, and probably be the teaching language of choice for computer science in most non-English countries. The difficulty will be - unfortunately - that in some languages the logic will not map exactly because some human languages have different logical constructs. Hence there is the likelihood that some of the programming in other languages might still be awkward. However, I think that will be a minor consideration for student programmers who are not forced into learning a pigeon form of English in order to code their programs.
Re: CONST_STRING vs string_from_literal ?
chromatic wrote: It doesn't *always* work. For example, I think CONST_STRING() doesn't work in PCCMETHODs in PMCs for some reason I can't explain, and it doesn't work in other source files. If you want to use CONST_STRING in other source files, you need to #include the corresponding .str file in the source code, since the CONST_STRING macro and the constant strings are defined in the .str file. See src/objects.c and src/objects.str for an example. I haven't tested whether this works for regular functions declared in .pmc files yet (the other place the problem occurs most frequently). Allison
Parrot Bug Summary
Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Dec 10 14:00:02 2007 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- Numbers Ticket Counts: 91 new + 731 open = 822 Created this week: 62 Closed this week: 15 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 48034 [BUG] examples/streams/Bytes.pir runtime error 48024 [DEPRECATED] type ids 48016 [DEPRECATED] store_global opcode 47996 [BUG] pge - regex adverbs don't accept leading space 47992 [RFE] 'parrot foo' automatically finds and invokes foo.pbc 47978 [C99] [IMCC] double free 47974 [DOCS] What are valid characteristics for 'inspect_str' vtable 47966 [DOCS] pdd23 doesn't list exception;death as a standard exception 47940 [CAGE] mk_native_pbc stale 47930 [RFC] Remove comma separated keys [a,b] 47894 [BUG] Non-existent lexical throws exception 47888 [TODO] gc - possibly merge gmc branch back into trunk 2 - 3 weeks old 47822 [Cola] - uses old 'float' type. 47764 [TODO] COW for one or all users of a modified string 3 - 4 weeks old 4 - 5 weeks old 5 - 6 weeks old 47153 [PATCH][Review] Proposed change from PMC_IS_NULL to PMC_is_null 47141 [PDD19] Line directive 47109 [CAGE] wrap macro args in parens inside macro bodies 6 - 7 weeks old 46971 [DEPRECATED] newfrom sub/method in PGE 46933 [PATCH] [RFE] Change behavior of Data::Dumper wrt Undef 46925 [TODO] [C] Call pmc slicing functions from PackFiles thaw() 46923 [TODO] [C] Check flags of parrot_range object in elements() method Slice PMC 46761 Dynpmcs and ParrotLibrary Global Destruction 46757 [BUG] Segfault in Parrot_TclString_nci_get_list 7 - 8 weeks old 46597 wrong NOTNULL in Parrot_init_arg_indexes_and_sig_pmc 46593 [PATCH] better documentation on parameter passing 46479 Remove rt.saved.search from tools/util/release.json? 46457 [BUG][IMCC] long sub invocation with named parameters 8 - 9 weeks old 46437 refactor interpreter cloning so it doesn't redundantly reinsert subs 46295 [CAGE] [pdd15oo] Review the docs w.r.t. the new OO implementation 9 - 10 weeks old 10 - 11 weeks old 45857 [IMCC][RFC] #line vs .line 11 - 12 weeks old 45659 Tcl - [string is double .1] returns wrong value 45503 one test in 't/op/string.t' is failling for jit runcore 12 - 13 weeks old 13 - 14 weeks old 14 - 15 weeks old 15 - 16 weeks old 44979 [BUG] TGE reports an error, but won't say which line it's on. 16 - 17 weeks old 44765 [PATCH] Don't reuse interpreter argument on stack 17 - 18 weeks old 44471 [PATCH] :vtable is ignored when :anon 18 - 19 weeks old 19 - 20 weeks old 44139 opcodes, warnings, and exceptions 20 - 21 weeks old --- Overview of Open Issues PlatformSeverity Tag Lang aix0abandoned 0 5005threads 0 Amber0 All3fatal 3 bounce0 BASIC0 bsdos 0High 0 Bug 70 bc 0 cygwin 4low 1 compiler 0 befunge 0 cygwin_nt 0medium0 configure 0 bf 0 darwin 4none 1 core 2 cola 1 dec_osf0Normal1 dailybuild0 forth0 dgux 0unknown 0 docs 2 jako 0 dos0Wishlist 3 duplicate 0 Lisp 0 dynixptx 0 install 1 m4 0 freebsd8 library 0 ook 0 generic0 notabug 0 perl61 gnu0 notok 0 plot 0 HPUX 2 ok0 punie0 irix 0 Patch49 pynie2 irix64 0 regex 2 python 0 Linux 3 sendToCPAN0 ruby 0 lynxos 0 Todo491 scheme 0 mac0 unknown 0 tcl 72 machten0 utilities 0 urm 0 macos 0 wontfix 0 Zcode0 MacOS X2 mswin320 netbsd 1 next 0 openbsd2 os20 os390 0 other 0 powerux0 qnx0 riscos 0 sco0 Solaris4 sunos 1 svr4 0 svr5 0 sysv 0 unicos 0 unicosmk 0 unix 0 unknown0 uts0 vms0 VOS0 Win32 10
Re: Status of docs/embed.pod and Parrot::Embed?
Tim Bunce wrote: I'm interested in doing some work on Parrot::Embed. Great! 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? Only that it's incomplete. 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. 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. 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. 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.) I'll update/expand Parrot::Embed in sync and address the items in the TODO file along the way. Sound okay? Sounds good. 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.) Allison
Re: Status of docs/embed.pod and Parrot::Embed?
Jeff Horwitz wrote: I can take a stab at this, as I've done enough Parrot embedding to write a short novel. Looks like PDD10 could use some updating as well -- were there any plans for that? Maybe we should start there? Great! Please merge docs/embed.pod into PDD 10. Allison
Re: CONST_STRING vs string_from_literal ?
On Monday 10 December 2007 05:52:59 Allison Randal wrote: chromatic wrote: It doesn't *always* work. For example, I think CONST_STRING() doesn't work in PCCMETHODs in PMCs for some reason I can't explain, and it doesn't work in other source files. If you want to use CONST_STRING in other source files, you need to #include the corresponding .str file in the source code, since the CONST_STRING macro and the constant strings are defined in the .str file. See src/objects.c and src/objects.str for an example. Yep. There's one piece I don't remember at the moment, and that's where to add the filename so that the Makefile generates the .str file appropriately. I think it's just the root Makefile template. I haven't tested whether this works for regular functions declared in .pmc files yet (the other place the problem occurs most frequently). It works now. I fixed that a couple of weeks ago. -- c
Re: CONST_STRING vs string_from_literal ?
chromatic wrote: Yep. There's one piece I don't remember at the moment, and that's where to add the filename so that the Makefile generates the .str file appropriately. I think it's just the root Makefile template. Aye, config/gen/makefiles/root.in, add it to STR_FILES. I haven't tested whether this works for regular functions declared in .pmc files yet (the other place the problem occurs most frequently). It works now. I fixed that a couple of weeks ago. Great! Allison
[PROPOSAL] Remove Absolute PASM registers from PIR. (was: Re: [BUG] imcc register allocation does not consider PASM register usage)
In order to draw attention to this point, I changed the subject. On Dec 9, 2007 10:10 PM, Allison Randal [EMAIL PROTECTED] wrote: Klaas-Jan wrote: There is of course the option of taking the current behavior as correct, effectively forgetting about this piece of the specification. I can, however, imagine a situation in which someone would want to do manual register allocation (writing Parrot assembly) for certain cases. I'm not sure whether this manual allocation would be disregarded by IMCC which then does its own reg. allocation. That part of the spec/documentation was generally a caution against using the low-level registers, because they aren't guaranteed to do what you expect. Really, I'd be okay with disallowing the $-less register variables in PIR. Allison Is there anybody who thinks the removal from PIR of $-less registers (absolute or PASM registers) should not be done? kjs
[BUG] headerizer can't handle new file src/atomic/gcc_x86.c
When I try to run 'make headerizer' I get the following error: -- can't find HEADERIZER HFILE directive in 'src/atomic/gcc_x86.c' at tools/build/headerizer.pl line 335. -- But when I add the HFILE directive: /* HEADERIZER HFILE: include/parrot/atomic/gcc_x86.h */ I then get the error: -- Couldn't handle PARROT_INLINE void *parrot_i386_cmpxchg(void *volatile *ptr, void *expect, void *update) at tools/build/headerizer.pl line 169. -- I can't spare the brain bandwidth to dig into this further at the moment, so posting for others. Allison
Re: [BUG] headerizer can't handle new file src/atomic/gcc_x86.c
On Dec 10, 2007, at 11:59 AM, Allison Randal wrote: Couldn't handle PARROT_INLINE void *parrot_i386_cmpxchg(void *volatile *ptr, void *expect, void *update) at tools/build/headerizer.pl line 169. Turn that into: PARROT_INLINE void * parrot_i386_cmpxchg(void *volatile *ptr, void *expect, void *update) -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [BUG] headerizer can't handle new file src/atomic/gcc_x86.c
I can't spare the brain bandwidth to dig into this further at the moment, so posting for others. BTW I have other headerizer stuff to update, like updating all the comments automagically so that the function declaration always matches the POD. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Status of docs/embed.pod and Parrot::Embed?
On Monday 10 December 2007 01:59:40 Tim Bunce wrote: 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) I've just run it successfully on x86 Ubuntu; what's broken for you and where? -- c
Re: [BUG] headerizer can't handle new file src/atomic/gcc_x86.c
Andy Lester wrote: PARROT_INLINE void * parrot_i386_cmpxchg(void *volatile *ptr, void *expect, void *update) Righto. Resolved in r23708. Allison
Re: Standards bearers (was Re: xml and perl 6)
At 9:04 AM +0300 12/10/07, Richard Hainsworth wrote: Equally, Something to replace CGI or DBI will be essential to the uptake of P6. I would far prefer to have a skilled and resourceful professional, such as yourself or Damian Conway write these modules than leave it to enthusiastic amateurs such as myself. I for one can assert that both of these are being produced right now. Also that neither is part of the Perl 6 kernal, though the kernal may enhanced over time to better support them. -- Darren Duncan
Re: Status of docs/embed.pod and Parrot::Embed?
Tim Bunce wrote: p.s. How do I get a commit bit? Or should I just post patches for now? Start with patches. - Mail/fax in a contribution agreement. http://www.perlfoundation.org/attachment/legal/cla.pdf (I thought we had one for you for Perl 5, but apparently not.) - Committers are voted in by the core dev team, based on the sanity of prior contributions. You've been contributing since at least 2003 (first post I found), if not earlier, which gives you a longer history than our average new committer. :) Allison
[perl #48445] [TODO] nqp - report undeclared variable usage
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #48445] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=48445 When an NQP program uses a variable that hasn't been previously declared, it should report a useful error message: Use of undeclared variable '$x' at ... Pm
Re: Status of docs/embed.pod and Parrot::Embed?
On 10 Dec 2007, at 19:44, Allison Randal wrote: Start with patches. ObHelping: I see a lot of items here: http://www.parrotcode.org/todo.html - but no obvious priorities. 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. -- Andy Armstrong, Hexten
Re: Status of docs/embed.pod and Parrot::Embed?
On Monday 10 December 2007 15:44:22 Tim Bunce wrote:
$ perl M*PL
Unrecognized argument in LIBS ignored: '501'
Unrecognized argument in LIBS ignored: '80'
Unrecognized argument in LIBS ignored: '79'
Unrecognized argument in LIBS ignored: '81'
Unrecognized argument in LIBS ignored: '501LIBPARROT_STATIC)'
Writing Makefile for Parrot::Embed
Due to $( on line 20 in Makefile.PL:
$config{ALL_PARROT_LIBS} = $(LIBPARROT_STATIC) $config{C_LIBS};
I see Makefile.PL isn't in subversion so I presume it's generated
somewhere. (I'm not familar with the parrot build system yet.)
Configure.pl builds it from config/gen/makefiles/parrot_embed.in. The line
there which generates the problem line for you is:
#INVERSE_CONDITIONED_LINE(win32):$config{ALL_PARROT_LIBS}
= @libparrot_ldflags@ $config{C_LIBS};
Apparently whatever your configuration options, you're getting something in
ALL_PARROT_LIBS which I never expected. Would you mind sending along the
root-level Makefile?
-- c
VMs in the news
Rubinus (new Ruby runtime) http://www.infoq.com/news/2007/12/engine-yard-bets-big-rubinius C--: a portable assembly language that supports garbage collection http://research.microsoft.com/~simonpj/Papers/c--/c--gc.htm Everybody's at it :) -- Andy Armstrong, Hexten
Re: Status of docs/embed.pod and Parrot::Embed?
On Mon, 10 Dec 2007, 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'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 can take a stab at this, as I've done enough Parrot embedding to write a short novel. Looks like PDD10 could use some updating as well -- were there any plans for that? Maybe we should start there? -jeff
[perl #48439] [TODO] [configure] compiling Parrot with LLVM
# New Ticket Created by Allison Randal
# Please include the string: [perl #48439]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=48439
Marton Papp has successfully compiled Parrot with LLVM on Windows with
mingw-make (it's failing 18 tests, which is impressively low for a first
run on a new compiler). Below is his summary of the steps he followed.
I'd like to extract the changes he made for the configuration system.
Original Message
Subject: Re: hi! LLVM and parrot
Date: Mon, 10 Dec 2007 14:33:46 +0100
From: [EMAIL PROTECTED]
[...]
I used this file to compile it
set path=%path%;c:\mingw\bin;D:\extracted\icu2\icu\bin
e:
cd e:\extracted\parrot-0.5.0\bin
perl configure.pl --cc=E:\llvm\bin\llvm-gcc.exe
--cxx=E:\llvm\bin\llvm-g++.exe --link=E:\llvm\bin\llvm-gcc.exe
--ld=E:\llvm\bin\llvm-gcc.exe
I changed the makefile in the directory
where there is line CUR_DIR = .
I changed it for full path of the current directory.
(Otherwise ./mini_parrot caused in error)
In my case,
It became CUR_DIR = E:\extracted\parrot-0.5.0
and ran mingw-make
Then make stopped.
I moved into the directory, it just left.
Changed these files/
In dynpmc.pl
I changed last line of partial_link_cmd.
return
$LD .
'-o ' . $target . .
join( , map {$PATHQUOTE$_$PATHQUOTE} @$sources) .
$PATHQUOTE$LIBPARROT$PATHQUOTE $liblist $LDFLAGS $LD_LOAD_FLAGS ;
and changed this:our $LIBPARROT = q[]; for our $LIBPARROT = q[-lparrot]
continued make by mingw-make...
The make failed again , then
I changed parrot-0.5.0\tools\build\dynoplibs.pl
I inserted these lines (copied them from tools\build\dynpmc.pl) :
# Also note that we may need to look in the Parrot blib directory.
if ($CC =~ /gcc/i) {
$liblist .= qq{ -Wl,-L E:/extracted/parrot-0.5.0/blib/lib};
}
else {
$liblist .= qq{ /LIBPATH:E:/extracted/parrot-0.5.0/blib/lib};
}
I changed last lines of partial_link_cmd in dynpmc.pl
(something similar to this)
return
$LD .
'-o ' . $target . .
join( , map {$PATHQUOTE$_$PATHQUOTE} @$sources) .
$liblist $LDFLAGS $LD_LOAD_FLAGS ;
The explanation: remove $PATHQUOTE$LIBPARROT$PATHQUOTE so that
unreferenced symbol do not occur..
I did something similar in the code it is not worth duplicating it here.
I changed $extraLibs in dynoplibs.pl inpartial_link_cmd
for $extraLibs = '-lparrot ..
I added -lparrot at the beginning
I went into directory just failed. I ran make.
Then I want back to the main make.
I ran it.
Marton Papp
Re: Status of docs/embed.pod and Parrot::Embed?
On Mon, Dec 10, 2007 at 04:37:31PM +0200, Allison Randal wrote: s[...]. 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.) I'm delighted that Jeff's offered to help. Jeff, how do you want to proceed? 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). Okay. Will do. Tim. p.s. How do I get a commit bit? Or should I just post patches for now?
Re: Status of docs/embed.pod and Parrot::Embed?
On Mon, Dec 10, 2007 at 10:57:05AM -0800, chromatic wrote:
On Monday 10 December 2007 01:59:40 Tim Bunce wrote:
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)
I've just run it successfully on x86 Ubuntu; what's broken for you and where?
$ perl M*PL
Unrecognized argument in LIBS ignored: '501'
Unrecognized argument in LIBS ignored: '80'
Unrecognized argument in LIBS ignored: '79'
Unrecognized argument in LIBS ignored: '81'
Unrecognized argument in LIBS ignored: '501LIBPARROT_STATIC)'
Writing Makefile for Parrot::Embed
Due to $( on line 20 in Makefile.PL:
$config{ALL_PARROT_LIBS} = $(LIBPARROT_STATIC) $config{C_LIBS};
I see Makefile.PL isn't in subversion so I presume it's generated
somewhere. (I'm not familar with the parrot build system yet.)
Tim.
Release Managers wanted for 2008
We'd like to continue with our monthly release schedule for 2008. Volunteers needed! At the moment, commit bits and an eye to detail are the only real prereqs... A PAUSE ID for uploading to CPAN will be necessary at some point. I'd like to get at least six volunteers: if you're already on the list from 2007, or if you've responded to a previous ping, please re-up if you can; I know availabilty changes a lot. I'd like to have the releases scheduled out through June of 2008 by year's end, so please respond (privately ok) asap. Thanks in advance! -- Will Coke Coleda On Dec 10, 2007, at 10:00 AM, [EMAIL PROTECTED] wrote: Author: coke Date: Mon Dec 10 07:00:20 2007 New Revision: 23697 Modified: trunk/docs/project/release_manager_guide.pod Log: [docs] Update release schedule to reflect reality for previous and upcoming release; Now is a good time to volunteer for 2008... Modified: trunk/docs/project/release_manager_guide.pod === === === = --- trunk/docs/project/release_manager_guide.pod(original) +++ trunk/docs/project/release_manager_guide.podMon Dec 10 07:00:20 2007 @@ -264,9 +264,8 @@ Planned releases in 2007. To make a monthly release schedule possible, we're spreading the burden -of releases across multiple release managers. Each release manager takes -one release in a 6 month rotation. Releases are scheduled for the 3rd -Tuesday of the month. +of releases across multiple release managers. Releases are scheduled for +the 3rd Tuesday of the month. - Jan 16th (0.4.8) Jerry Gay (particle) - Feb 20th (0.4.9) Patrick Michaud (pmichaud) @@ -278,7 +277,7 @@ - Aug 21st (0.4.15) Patrick Michaud (pmichaud) - Sep 18th (0.4.16) Jerry Gay (particle) - Oct 16th (0.4.17) Will Coleda (Coke) - - Nov 20th, chromatic - - Dec 18th, Allison Randal + - Nov 20th (0.5.0) chromatic + - Dec 18th (0.5.1) Will Coleda (Coke) =cut
[perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 config steps
# New Ticket Created by James Keenan
# Please include the string: [perl #48459]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=48459
The patch attached proposes to refactor Parrot configuration step
class inter::progs into two classes: inter::compiler and inter::progs.
inter::compiler will search for a C compiler, process any --cc option
set on the command line and, if interactive configuration has been
requested via command-line option --ask, prompt the user for the
location of the desired C compiler. It will then conduct a basic
test of that compiler's functioning. If interactive configuration
has been requested, this step will print the introductory information
currently printed by inter::progs.
inter::progs will process all the other compiler-related settings
currently done in inter::progs. Only the --cc-related code and the
introductory explanation have been extracted.
inter::compiler has been refactored so that, in the two new test
files found in the patch, we can thoroughly test the Perl 5 aspects
of the code while steering clear of the test of the C compiler, which
is outside the scope of these tests.
This refactoring *may* get us closer to resolving the problem
reported by Andy Dougherty in https://rt.perl.org/rt3/Ticket/
Display.html?id=47393.
Please review. Thank you very much.
Index: MANIFEST
===
--- MANIFEST(revision 23722)
+++ MANIFEST(working copy)
@@ -1,7 +1,7 @@
# ex: set ro:
# $Id$
#
-# generated by tools/dev/mk_manifest_and_skip.pl Mon Dec 10 18:59:19 2007 UT
+# generated by tools/dev/mk_manifest_and_skip.pl Tue Dec 11 03:48:56 2007 UT
#
# See tools/dev/install_files.pl for documentation on the
# format of this file.
@@ -385,6 +385,7 @@
config/init/miniparrot.pm []
config/init/optimize.pm []
config/inter/charset.pm []
+config/inter/compiler.pm[]
config/inter/encoding.pm[]
config/inter/lex.pm []
config/inter/libparrot.pm []
@@ -3033,6 +3034,8 @@
t/configure/105-init_hints-03.t []
t/configure/105-init_hints-04.t []
t/configure/106-init_headers.t []
+t/configure/107-inter_compiler-01.t []
+t/configure/107-inter_compiler-02.t []
t/configure/107-inter_progs-01.t[]
t/configure/107-inter_progs-02.t[]
t/configure/107-inter_progs-03.t[]
Index: lib/Parrot/Configure/Step/List.pm
===
--- lib/Parrot/Configure/Step/List.pm (revision 23722)
+++ lib/Parrot/Configure/Step/List.pm (working copy)
@@ -14,6 +14,7 @@
init::miniparrot
init::hints
init::headers
+inter::compiler
inter::progs
inter::make
inter::lex
Index: t/configure/107-inter_progs-03.t
===
--- t/configure/107-inter_progs-03.t(revision 23722)
+++ t/configure/107-inter_progs-03.t(working copy)
@@ -58,7 +58,6 @@
my ( @prompts, $object );
foreach my $p (
qw|
-cc
link
ld
ccflags
Index: t/configure/107-inter_progs-04.t
===
--- t/configure/107-inter_progs-04.t(revision 23722)
+++ t/configure/107-inter_progs-04.t(working copy)
@@ -58,7 +58,6 @@
my ( @prompts, $object );
foreach my $p (
qw|
-cc
link
ld
ccflags
Index: t/configure/107-inter_progs-01.t
===
--- t/configure/107-inter_progs-01.t(revision 23722)
+++ t/configure/107-inter_progs-01.t(working copy)
@@ -59,7 +59,6 @@
my ( @prompts, $object );
foreach my $p (
qw|
-cc
link
ld
ccflags
Index: t/configure/107-inter_compiler-01.t
===
--- t/configure/107-inter_compiler-01.t (revision 0)
+++ t/configure/107-inter_compiler-01.t (revision 0)
@@ -0,0 +1,135 @@
+#! perl
+# Copyright (C) 2007, The Perl Foundation.
+# $Id$
+# 107-inter_compiler-01.t
+
+use strict;
+use warnings;
+
+use Test::More tests = 24;
+use Carp;
+use Data::Dumper;
+use lib qw( lib t/configure/testlib );
+use_ok('config::init::defaults');
+use_ok('config::init::install');
+use_ok('config::init::hints');
+use_ok('config::inter::compiler');
+use Parrot::Configure;
+use Parrot::Configure::Options qw( process_options );
+use Parrot::Configure::Test qw( test_step_thru_runstep);
+use Parrot::IO::Capture::Mini;
+
+my $args =
Re: VMs in the news
Andy == Andy Armstrong [EMAIL PROTECTED] writes: Andy Rubinus (new Ruby runtime) Andy http://www.infoq.com/news/2007/12/engine-yard-bets-big-rubinius I'm trying to figure out why Rubinous is building a squeak-like vm when squeak already has a vm. They would have been done faster had they generated Squeak bytecodes. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
memory checking I've been working on
Now that I've got all but one function headerized, I'm running splint.
One of the things that splint is good at, and the reason I did all the
PARROT_CAN(NOT)_RETUN_NULL flags, is it'll keep track of when something
could be NULL or not. So splint complains here:
char * const p = malloc(n);
p-foo = ...
and not here
char * const p = mem_sys_allocate(n);
p-foo = ...
because mem_sys_allocate() is marked as PARROT_CANNOT_RETURN_NULL.
So I can do this in PackFile_new:
Index: src/packfile.c
===
--- src/packfile.c (revision 23681)
+++ src/packfile.c (working copy)
@@ -1119,24 +1119,14 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
-PARROT_CAN_RETURN_NULL
+PARROT_CANNOT_RETURN_NULL
PackFile *
PackFile_new(PARROT_INTERP, INTVAL is_mapped)
{
PackFile * const pf = mem_allocate_zeroed_typed(PackFile);
-if (!pf) {
-PIO_eprintf(NULL, PackFile_new: Unable to allocate!\n);
-return NULL;
-}
pf-is_mmap_ped = is_mapped;
-
pf-header = mem_allocate_zeroed_typed(PackFile_Header);
-if (!pf-header) {
-PIO_eprintf(NULL, PackFile_new: Unable to allocate header!
\n);
-PackFile_destroy(interp, pf);
-return NULL;
-}
/*
* fill header with system specific data
*/
Index: include/parrot/packfile.h
===
--- include/parrot/packfile.h (revision 23681)
+++ include/parrot/packfile.h (working copy)
@@ -453,7 +453,7 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
-PARROT_CAN_RETURN_NULL
+PARROT_CANNOT_RETURN_NULL
PackFile * PackFile_new(PARROT_INTERP, INTVAL is_mapped)
__attribute__nonnull__(1);
The other thing to come out of this instrumentation is when splint tells
us that we can be dereferencing NULL, as in here:
intlist_get(PARROT_INTERP, NOTNULL(IntList *list), INTVAL idx)
{
/* XXX list_get can return NULL RT #48367 */
void * const ret = list_get(interp, (List *)list, idx,
enum_type_INTVAL);
const INTVAL retval = ret == (void *)-1 ? 0 : *(INTVAL *)ret;
ret could be NULL, but we're not checking that, so it's possible to
de-refernece a NULL.
So that's what I'm workin' on, running splint, fixing headerizations,
etc. Let me know if anything shakes loose, or looks crazy, or causes
problems with your specific compiler. I'd especially like it if someone
non-GCC has compiler options that we can put into
PARROT_CANNOT_RETURN_NULL and its brethren so we have more compilers
watching our backs.
xoxo,
Andy
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Standards bearers (was Re: xml and perl 6)
A great relief. Fantastic. Where should I be looking to see what is happening. Is there some form of coordination of this module writing activity? Darren Duncan wrote: At 9:04 AM +0300 12/10/07, Richard Hainsworth wrote: Equally, Something to replace CGI or DBI will be essential to the uptake of P6. I would far prefer to have a skilled and resourceful professional, such as yourself or Damian Conway write these modules than leave it to enthusiastic amateurs such as myself. I for one can assert that both of these are being produced right now. Also that neither is part of the Perl 6 kernal, though the kernal may enhanced over time to better support them. -- Darren Duncan
Re: [PROPOSAL] Remove Absolute PASM registers from PIR. (was: Re: [BUG] imcc register allocation does not consider PASM register usage)
On Dec 10, 2007, at 10:59 AM, Klaas-Jan Stol wrote: In order to draw attention to this point, I changed the subject. Is there anybody who thinks the removal from PIR of $-less registers (absolute or PASM registers) should not be done? kjs Parrot provides a calling convention, but does not, that I know of, mandate that calling convention. In any computer, there are multiple calling conventions used(often leading to a lack of interoperability, but nevertheless present). The system itself uses specific registers. Mixing absolute and relative registers in PIR does cause problems, but a program that solely used absolute registers and its own calling convention shouldn't be necessarily forbidden. Currently parrot has several ops that assist a different language/calling convention, such as bsr, and others of it's ilk. Mixing those ops and the standard calling convention ops together will probably cause massive problems, but they still exist(even if they're there more because they were long ago rather than need to be).
