Re: [COMMIT] IMCC changes
Melvin Smith [EMAIL PROTECTED] wrote: * Add check for 0 arguments in PCC subs to skip code generate for proto/nonproto argument checking if there are no args. (Leo check this if it is the right thing to do?) Looks good, but might not be compliant with Dan's runtime check philosophy. Or, its ok for the we don't check case and not for the paranoid one. Cheers, -Melvin leo
Re: IMCC problems with library loading
Jeff Clites [EMAIL PROTECTED] wrote: I've run into a couple of issue with library loading which have their origin down inside the IMCC code: 1) External libraries are being loaded at parse time. Inside of INS() in imcc/parser_util.c, Parrot_load_lib() is called at parse-time when loadlib is encountered. This is causing libraries to be loaded twice (once at parse-time and once at run-time), which is a problem in its own right, but it also just seems like generally the wrong behavior. If the library registers itself correctly, its loaded once only. E.g. a PMC library calls pmc_register() so that the classname is known. 2) Code which tries to instantiate a dynamically-loaded PMC fails to parse. Code such as this: loadlib P1, foo new P0, .Foo How does foo look like? dynclasses/dynfoo.pasm has an example of loading dynamic classes (and it works here). JEff leo
Re: Review of a book about VM
On Sat, Nov 15, 2003 at 02:10:35PM -, Peter Cooper wrote: Stéphane Payrard [EMAIL PROTECTED] wrote: You posted your mini-review to London.pm: Thanks for that, that demonstrates my memory! snip on virtual machines: No, there's suprisingly little out there on virtual machine design and development. This question isn't entirely directed at you, but.. is this something that people, as a community, would be interested in developing? I tend to like doing things on my own, but as you'll have seen I've only been studying the topic for 18 months! ;-) An open approach to developing an online wealth of knowledge about virtual machines would allow the gurus to share knowledge as they find the time. I've been involved with Wikipedia lately, and seen how major collaborative works in the content realm can work (as long as there's a modicum of structure to keep it all together). I personally believe virtual machines are ever increasing in importance in the realm of computer science, and such a resource may allow more people to 'migrate' from other disciplines more easily. Of course, this may all be pie in the sky, but I thought it worthwhile to throw the idea out there. I don't think it is wise to multiplicated resources but wiser to squat existing ones. Probably this work can start as part of the existing parrot wiki even if VM is in a sense a subject larger than Parrot: http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/WebHome Or it can be even be part of the regular wikipedia. I have been amazed at the quality of the wikipedia material, some of it contributed by our own Dominus. BTW: I suspect that his fake entry Goat rectum stuffed with garlic is good way for him to find his wikipedia homepage with Google. :) I don't feel competent enough to write on the VM subject but would be happy to translate it to make it part of the French wikipedia. -- stef Regards, Peter
Re: Calling conventions
On Sun, 16 Nov 2003, Melvin Smith wrote: The situation we have now is: Parrot is a VM, and technically we could just punt the whole calling convention issue to a high level languages forum (parrot-languages if there was one) or something, but sadly that wouldn't work, because currently there aren't enough people to go around. Right, and we're looking to be efficient for our core language set, so it's in our interests to make sure that we're a good fit there. There, unfortunately, is a land of variable-length argument lists and named argument processing. Which we'll need to deal with shortly, but that's for Part 2, and'll live on top of the base conventions. But to snip wildly: b) Parrot Standard specifies what conventions are _available_, but not which to use. This is pretty much it. We mandate what the caller must provide, and under what circumstances, to conform to conventions. (And we're getting multi-layer conventions, in part because they'll make the low-level library code faster) Beyond that it's all up in the air--nobody's going to force any language compiler to use the provided information. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Calling conventions are in
Sync up with CVS and read the changes in PDD03. I'll be addressing some of the HLL issues (including validation and named parameter lists) soon, since getting those nailed down would be reasonably useful. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: IMCC problems with library loading
On Nov 17, 2003, at 1:59 AM, Leopold Toetsch wrote: Jeff Clites [EMAIL PROTECTED] wrote: I've run into a couple of issue with library loading which have their origin down inside the IMCC code: 1) External libraries are being loaded at parse time. Inside of INS() in imcc/parser_util.c, Parrot_load_lib() is called at parse-time when loadlib is encountered. This is causing libraries to be loaded twice (once at parse-time and once at run-time), which is a problem in its own right, but it also just seems like generally the wrong behavior. If the library registers itself correctly, its loaded once only. E.g. a PMC library calls pmc_register() so that the classname is known. Actually, Parrot_load_lib calls Parrot_dlopen (inside if the call to get_path), then later calls is_loaded and closes the library if it was already loaded before. This is loading the library twice, from the perspective of the operating system. But that's really a side issue. My main point is that you can't do conditional library loading. This code will try to load the doesnt_exist library, and I don't think it should: branch HERE loadlib P1, doesnt_exist HERE: end It's not because the branch fails--it's because the library is loaded before the script starts running. Or is this expected--that a loadlib instruction will cause a library to be loaded, even if the instruction is never reached? 2) Code which tries to instantiate a dynamically-loaded PMC fails to parse. Code such as this: loadlib P1, foo new P0, .Foo How does foo look like? dynclasses/dynfoo.pasm has an example of loading dynamic classes (and it works here). dynclasses/dynfoo.pasm is the example I was referring to. It actually works for me also--if I leave the code in imcc/parser_util.c which causes the parse-time library loading mentioned above. (I had commented that out.) But rearranging the assembly slightly so that the execution order is logically the same but the loadlib instruction is further down in the source causes it to fail. That is: null P0 branch one two: find_type I0, Foo print I0 print \n new P0, .Foo print ok 2\n branch three one: loadlib P1, foo print ok 1\n branch two three: set I0, P0 print I0 print \n end This again fails with the error: error:imcc:unknown macro '.Foo' This is because the parser is encountering .Foo before it has loaded the lib at parse-time. This brings me back to my original question of whether the parser should think .Foo is a macro at all, or if rather that's not legal macro syntax. JEff
Re: IMCC problems with library loading
Jeff Clites [EMAIL PROTECTED] wrote: My main point is that you can't do conditional library loading. This code will try to load the doesnt_exist library, and I don't think it should: branch HERE loadlib P1, doesnt_exist HERE: end It's not because the branch fails--it's because the library is loaded before the script starts running. It depends. When you run it immediately, you are right: The library is loaded at compile time. When you compile it as .pbc and run it, the lib isn't loaded ar runtime. *But*, when writing that stuff, one prelim was, that the compiler sees all libs in the same sequence as runtime does. So above code (or your second example) is illegal. dynclasses/dynfoo.pasm is the example I was referring to. It actually works for me also--if I leave the code in imcc/parser_util.c which causes the parse-time library loading mentioned above. (I had commented that out.) The parser needs the information, that the lib provides, e.g. the classname. We could have a new P0, className too, of course, where everything happens at runtime and the parser doesn't know anything about that class. This brings me back to my original question of whether the parser should think .Foo is a macro at all, or if rather that's not legal macro syntax. This doesn't change the problem per se. JEff leo
Proposal: parrot-compilers list
In the past couple of years we've seen several sub-projects pop-up and subsequently fizzle out (maybe due to Parrot slow progress or maybe due to lack of critical mass). I propose creating 'parrot-compilers' as a general purpose list for any and all language development (until an appropriate time where said language outgrows the list maybe...). This might allow many small projects to feed off the collective energy of other small projects. I also volunteer to maintain and mail the FAQ out monthly, which is something I always liked about comp.compilers. The list would center around IMCC and higher up the compiler stack with the addition of various other topics that might not be specific to Parrot. Also it would, by namesake, be language neutral and might bring more people in from non-Perl camps as well as give some of us compiler enthusiasts a place to have our long drawn out spam^H^H^H^Hdiscussions without drowning the mailboxes of the general VM population. -Melvin
Re: Proposal: parrot-compilers list
Melvin Smith wrote: In the past couple of years we've seen several sub-projects pop-up and subsequently fizzle out (maybe due to Parrot slow progress or maybe due to lack of critical mass). I propose creating 'parrot-compilers' as a general purpose list for any and all language development (until an appropriate time where said language outgrows the list maybe...). This might allow many small projects to feed off the collective energy of other small projects. I also volunteer to maintain and mail the FAQ out monthly, which is something I always liked about comp.compilers. The list would center around IMCC and higher up the compiler stack with the addition of various other topics that might not be specific to Parrot. Also it would, by namesake, be language neutral and might bring more people in from non-Perl camps as well as give some of us compiler enthusiasts a place to have our long drawn out spam^H^H^H^Hdiscussions without drowning the mailboxes of the general VM population. I think this would be a *very* cool thing. -Sterling
configure on windows
Hi, I've only just installed perl. Running Configure.pl on a windows box, I got 'bad command or file name' because line 12 of config\init\hints.pl is: my $hints = config/init/hints/ . lc($^O) . .pl; I had to change it to: my $hints = perl config/init/hints/ . lc($^O) . .pl; I'll carry on editing lines by hand, just though I should mention it. Pete
Re: Proposal: parrot-compilers list
On Mon, 17 Nov 2003 11:35:51 -0800, Sterling Hughes [EMAIL PROTECTED] wrote: I think this would be a *very* cool thing. What he said. Pete Pete http://palacebuilders.pwp.blueyonder.co.uk/euphoria.html
Re: configure on windows
On Mon, 17 Nov 2003 20:46:32 +, Pete Lomax [EMAIL PROTECTED] wrote: I got 'bad command or file name' because line 12 of config\init\hints.pl is: my $hints = config/init/hints/ . lc($^O) . .pl; PS: that was the dos error, shouldn't there be an and/or die thing somewhere near it? Pete http://palacebuilders.pwp.blueyonder.co.uk/euphoria.html
Re: configure on windows
- Original Message - From: Pete Lomax [EMAIL PROTECTED] To: Pete Lomax [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 17, 2003 10:20 PM Subject: Re: configure on windows On Mon, 17 Nov 2003 20:46:32 +, Pete Lomax [EMAIL PROTECTED] wrote: I got 'bad command or file name' because line 12 of config\init\hints.pl is: my $hints = config/init/hints/ . lc($^O) . .pl; PS: that was the dos error, shouldn't there be an and/or die thing somewhere near it? My first guess is that perl or your compiler is not in your path (where your system looks for stuff to execute). If the problem is that perl isn't there, a reboot may be needed if you haven't done one since the install - paths are sometimes not re-evaluated until a reboot. If that doesn't do it, you'll need to add it to the path environment variable manually. Doing your change just appears to cause the win32 hints file not to be loaded - which causes configure to fail later. You can check this by putting monkey instead of perl before the filename and seeing if you get the same effect. The DOS error you get is most likely due to something done in the mswin32.pl hint file, or something that happens later. If you're still having fun, three things that'll help me find the cause are:- 1) Without your changes, do:- perl Configure.pl And post the output. 2) Type:- perl What happens? 3) What compiler are you planning to use? Type each of the following:- cl bcc32 gcc If all three of them give Bad Command Or File Name error then the reason is that you haven't got a C compiler in your system path. Thanks, Jonathan
Win32 Build Problem
Hi, When building under Win32:- imclexer.c imcc/imclexer.c(13) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory NMAKE : fatal error U1077: 'F:\Perl\bin\perl.exe' : return code '0x2' Stop. Changing the line:- #include unistd.h In imclexer.c to:- #include stdlib.h Allows parrot to build successfully. Jonathan
Parrot Documentation Review
1) What is Parrot documentation? It seems to me that the problem presented by information about Parrot is that it exists in different layers and contexts. The presence of the docs directory in CVS is deceptive. It suggests that it's contents are in some way definitive. But, in practice, the docs directory is really only there to provide basic information on a standalone machine equipped with nothing but a text editor. In fact, information about Parrot is in various places: On www.parrotcode.org there are FAQ, documents, links. In the distribution there are: - the various ALLCAPS files (plus ChangeLog) in the root directory - the POD documentation in the docs directory - the inline documentation in code files On the Wiki there is search, comment, explanation, suggestions. There's all the discussion on perl6.internals, searchable on Google. And, last but not least, there are the CVS checkin comments. 2) Who uses Parrot documentation? a) First time visitor A first time visitor needs an effective introductory experience with the minimum of frustration so that, hopefully, they will want to get involved with Parrot and become a regular contributor. What happens at the moment? - The new user visits www.parrotcode.org, downloads the latest distribution from CPAN, and reads the README. The README provides the necessary quick start, and seems to be complemented by NEWS, KNOWN_ISSUES, etc. But, these plain text files are prone to brevity and neglect, and the ALLCAPS naming convention doesn't really indicate a coherent category of documents. RELEASE_INSTRUCTIONS is of little relevance to a beginner. So, the user proceeds to the docs directory, armed with a simple text editor, and following the structure provided by parrot.pod and the various subdirectories, skips or reads through the various files according to their interest. There is, however, sufficient explicit mention of things being out-of-date that the authority of the documentation becomes tainted with doubt. Also, the text format prevents the inclusion of anything more visual than an ASCII diagram. Dissatisfied with this documentation the user resorts to inspecting the source code. Inline documentation is directly addressed to the developer but it is patchy. Often the only way to get a definitive answer is to search or post to the mailing list. Discovering the existence of the wiki, our potential Parrot contributor discovers editable hypertext with images. POD can be read reformated in HTML. A lot of additional information is provided. As one user put it: This is more like what I was after. All the docs in one location and with a decent interface for browsing through them. b) Regular user A regular user of the documentation is probably a contributing developer who needs the a speedy look-up for definitive information. What happens at the moment? - In the absence of comprehensive API documentation, the developer has to resort to searching, either by importing Parrot into a development environment, or by resorting to some form of grep. Repeated searching can be time consuming because of the guesswork involved. The wiki also provides search, but only usefully to those with good Internet connections. This is a problem for online documentation too. Therefore we need comprehensive API documentation in HTML in the distribution. Some of it can be autogenerated, not all of it need reside in CVS. All that is needed is for there to be a clearly defined process ensuring that each release one way or another has all the necessary documentation. 3) Where is the primary location for Parrot documentation? Ideally, version 1.0 will be released with complete and adequate documentation as part of the distribution. We should continue to improve the contents of docs until it provides the necessary minimal documentation for Parrot. But, each release is only a snapshot of a continuous process, and it is this real world process that the documentation primarily serves. Given the presence of www.parrotcode.org and the wiki (proposed by Robert to be wiki.parrotcode.org), the information included in a release is always really only relevant in the context of a standalone machine. The effective primary location for Parrot documentation will always be *.parrotcode.org. What goes into the distribution should therefore be derived from - or at least closely reflect - the content there. 4) Why would anyone volunteer to be responsible for Parrot documentation? I would not be involved in Parrot if it were not for Piers and his weekly summaries [1]. They gave me the sense that what seemed opaque could become clear with some attention and effort. How many potential contributors have been lost to Parrot simply because they lacked the time to get over the initial learning curve? Frustrated by the state of the documentation they lost interest. That's the problem I want to solve. 5) Parrot documentation person
Re: Proposal: parrot-compilers list
Pete Lomax wrote: On Mon, 17 Nov 2003 11:35:51 -0800, Sterling Hughes [EMAIL PROTECTED] wrote: I think this would be a *very* cool thing. What he said. Ditto. - Joe
