[svn:parrot-pdd] r32652 - in trunk: . compilers/imcc docs/pdds languages/dotnet/build languages/dotnet/src languages/dotnet/t languages/forth runtime/parrot/library t/compilers/imcc/syn t/library t/oo
Author: coke Date: Fri Nov 14 16:33:41 2008 New Revision: 32652 Modified: trunk/docs/pdds/pdd19_pir.pod Changes in other areas also in this revision: Modified: trunk/DEPRECATED.pod trunk/compilers/imcc/imcc.y trunk/compilers/imcc/imcparser.c trunk/languages/dotnet/build/builtins.pl trunk/languages/dotnet/build/translator.pl trunk/languages/dotnet/src/exception.pir trunk/languages/dotnet/src/field.pir trunk/languages/dotnet/src/method.pir trunk/languages/dotnet/src/net2pbc.pir trunk/languages/dotnet/src/signature.pir trunk/languages/dotnet/src/translator.pir trunk/languages/dotnet/src/typeinfo.pir trunk/languages/dotnet/t/staticfield.t trunk/languages/dotnet/t/staticmethod.t trunk/languages/forth/forth.pir trunk/languages/forth/tokenstream.pir trunk/languages/forth/variablestack.pir trunk/languages/forth/virtualstack.pir trunk/languages/forth/words.pir trunk/runtime/parrot/library/Range.pir trunk/t/compilers/imcc/syn/hll.t trunk/t/library/p6object.t trunk/t/oo/isa.t trunk/t/pmc/key.t trunk/t/pmc/multidispatch.t trunk/t/pmc/namespace.t trunk/t/pmc/parrotinterpreter.t trunk/t/pmc/threads.t Log: RT #57428; add new .HLL string syntax specified in PDD19, and update code to the new usage. This paves the way to rip out the old syntax next release. Modified: trunk/docs/pdds/pdd19_pir.pod == --- trunk/docs/pdds/pdd19_pir.pod (original) +++ trunk/docs/pdds/pdd19_pir.pod Fri Nov 14 16:33:41 2008 @@ -322,7 +322,7 @@ A library loaded this way is also available at runtime, as if it has been loaded again in C:load, so there is no need to call Cloadlib at runtime. -=item .HLL hll_name [unimplemented: RT #57426] +=item .HLL hll_name Define the HLL for the current file. Takes one string constant, the name of the HLL.
Re: [svn:parrot] r32110 - tags/RELEASE_0_8_0/runtime/parrot/library/PGE
If someone could untangle this inadvertent commit to a tag instead of trunk, I'd appreciate it. On Wed, Oct 22, 2008 at 1:40 PM, [EMAIL PROTECTED] wrote: Author: coke Date: Wed Oct 22 10:40:50 2008 New Revision: 32110 Modified: tags/RELEASE_0_8_0/runtime/parrot/library/PGE/Util.pir Log: [docs] note a dependency for this library. Modified: tags/RELEASE_0_8_0/runtime/parrot/library/PGE/Util.pir == --- tags/RELEASE_0_8_0/runtime/parrot/library/PGE/Util.pir (original) +++ tags/RELEASE_0_8_0/runtime/parrot/library/PGE/Util.pir Wed Oct 22 10:40:50 2008 @@ -5,7 +5,7 @@ =head1 DESCRIPTION This module defines a number of useful rules for various -parsing tasks using PGE. +parsing tasks using PGE. You must load PGE before this module. =head2 Functions -- Will Coke Coleda
Re: [svn:parrot] r31581 - in branches/hllmagic: runtime/parrot/library t/library
On Fri, Oct 03, 2008 at 01:23:14AM -0700, [EMAIL PROTECTED] wrote: +parrotclass = split '::', $S0 +$P0 = getinterp +$P0 = $P0['namespace';1] +$P0 = $P0.get_name() +$P0 = shift $P0 +unshift parrotclass, $P0 +parrotclass = get_root_namespace [parrotclass] The brackets in this last line look odd to me -- obtaining a namespace via an array of names is supposed to be (pdd21:377) $P1 = get_root_namespace $P2 Also, the p6object library tries to reserve the symbol name parrotclass for something that is actually an instance of (parrot) Class, which the array and namespace aren't. We should introduce another symbol here instead of re-using parrotclass. Pm
[svn:parrot-pdd] r25116 - in trunk: compilers/pct/src/PCT docs/pdds runtime/parrot/library/Parrot
Author: pmichaud Date: Mon Jan 21 18:32:45 2008 New Revision: 25116 Modified: trunk/docs/pdds/pdd26_ast.pod Changes in other areas also in this revision: Modified: trunk/compilers/pct/src/PCT/Node.pir trunk/runtime/parrot/library/Parrot/Capture_PIR.pir Log: [pct]: * Add shift and pop operations to PAST::Nodes. * Patch courtesy Stuart Jansen sjansen at gurulabs.com Modified: trunk/docs/pdds/pdd26_ast.pod == --- trunk/docs/pdds/pdd26_ast.pod (original) +++ trunk/docs/pdds/pdd26_ast.pod Mon Jan 21 18:32:45 2008 @@ -61,10 +61,20 @@ Add Cchild to the end of the node's array of children. +=item pop() + +Remove the last child from the node's array of children. +Returns the child. + =item unshift(child) Add Cchild to the beginning of the node's array of children. +=item shift() + +Remove the first child from the node's array of children. +Returns the child. + =item iterator( ) Return a newly initialized CIterator for the node's list
Should MANIFEST determine .pbc builds in runtime/parrot/library/ ?
I just spent about an hour trying to figure out how the files in runtime/parrot/library/ are automatically compiled into .pbc files when Parrot is built. It turns out that the list of files is computed from the MANIFEST, and I was searching through files in the config/ subdirectory (where most other configuration-like items tend to be placed). Is MANIFEST the correct file for determining which .pir files should automatically be converted to .pbc ? And if it is (or even if it isn't but we decide to keep it this way for some time), could/should there be a note in the generated root Makefile that indicates that GEN_LIBRARY is being generated from entries in the MANIFEST? Thanks, Pm
DISREGARD: Should MANIFEST determine .pbc builds in runtime/parrot/library/ ?
On Fri, Jun 29, 2007 at 11:55:28AM -0500, Patrick R. Michaud wrote: I just spent about an hour trying to figure out how the files in runtime/parrot/library/ are automatically compiled into .pbc files when Parrot is built. It turns out that the list of files is computed from the MANIFEST, and I was searching through files in the config/ subdirectory (where most other configuration-like items tend to be placed). Never mind, I finally figured it out. It's in config/gen/makefiles/root.in . I was doing ack HLLCompiler in the config directory (and other directories) to try to find the HLLCompiler.pbc target, but didn't realize that ack doesn't search root.in by default. I guess this is one of those 1% cases where I should've used grep -r instead, or learned about ack -a. Pm
Re: [svn:parrot] r17012 - in trunk: runtime/parrot/library/Parrot t/compilers/past-pm
Nicholas Clark wrote: If you're adding before or after an existing named stage, the ambiguity is to which one you mean. Except having now studied the PIR, I can see that there isn't ambiguity, because it's all of them. There's no test for this though. Hence why I didn't realise. Good point. Tests added, r17027. Thanks, Allison
Re: [svn:parrot] r17012 - in trunk: runtime/parrot/library/Parrot t/compilers/past-pm
On Thu, Feb 15, 2007 at 09:39:28AM -0800, [EMAIL PROTECTED] wrote: +=item addstage(string stagename [, option = value, ... ]) + +Add a stage to the compilation process queue. Takes either a before or +after named argument, which gives the relative ordering of the stage +to be added. If before and after aren't specified, the new stage is +inserted at the end of the queue. + +=cut + +.sub 'addstage' :method +.param string stagename +.param pmc adverbs :slurpy :named + +.local string position, target +.local pmc stages +stages = getattribute self, '@stages' + +$I0 = exists adverbs['before'] +unless $I0 goto next_test + position = 'before' What happens if you add a stage with the same name as an existing stage? Is ambiguity acceptable? Nicholas Clark
Re: [svn:parrot] r17012 - in trunk: runtime/parrot/library/Parrot t/compilers/past-pm
Nicholas Clark wrote: What happens if you add a stage with the same name as an existing stage? It gets added twice. You might repeat a stage like optimize_tree or display_benchmarks after each transformation. Is ambiguity acceptable? What kind of ambiguity? Allison
Re: [svn:parrot] r17012 - in trunk: runtime/parrot/library/Parrot t/compilers/past-pm
On Fri, Feb 16, 2007 at 12:42:24AM +0200, Allison Randal wrote: Nicholas Clark wrote: What happens if you add a stage with the same name as an existing stage? It gets added twice. You might repeat a stage like optimize_tree or display_benchmarks after each transformation. Is ambiguity acceptable? What kind of ambiguity? If you're adding before or after an existing named stage, the ambiguity is to which one you mean. Except having now studied the PIR, I can see that there isn't ambiguity, because it's all of them. There's no test for this though. Hence why I didn't realise. Nicholas Clark
Re: [svn:parrot] r16706 - in trunk: compilers/tge/TGE languages/tcl/config/makefiles languages/tcl/lib languages/tcl/src languages/tcl/t runtime/parrot/library/PGE src
Will, I'm really deeply sorry for reverting stuff with my last commit. Heh. Things happen. It's ok. Jerry did worse to tcl just before the release. =-) I appreciate the fix up. I was a certainly a little grumpy, but it's fixed, before I even had a chance to sit back down and look at the code. Good enough, thanks. =-) You did sound a bit grumpy ;-) Nevertheless, I'm trying to help, not hinder. You're a good bloke, thanks Will. Paul
Fwd: [svn:parrot] r16706 - in trunk: compilers/tge/TGE languages/tcl/config/makefiles languages/tcl/lib languages/tcl/src languages/tcl/t runtime/parrot/library/PGE src
Paul, did you mean to update all these tcl files with your patch with no commit message? If not, this isn't the first time you've reverted code elsewhere in the repository when doing your manual merges... (and it affected tcl last time, too.) - Please fix them. If so, please use *real* commit messages so we know what you're updating. In either case, we might want to review how you're using svk. Regards. Begin forwarded message: From: [EMAIL PROTECTED] Date: January 19, 2007 6:06:08 AM EST To: [EMAIL PROTECTED] Subject: [svn:parrot] r16706 - in trunk: compilers/tge/TGE languages/tcl/config/makefiles languages/tcl/lib languages/tcl/src languages/tcl/t runtime/parrot/library/PGE src Author: paultcochrane Date: Fri Jan 19 03:06:07 2007 New Revision: 16706 Modified: trunk/compilers/tge/TGE/Compiler.pir trunk/languages/tcl/config/makefiles/root.in trunk/languages/tcl/lib/skipped_tests.tcl trunk/languages/tcl/src/binary.c trunk/languages/tcl/t/cmd_binary.t trunk/runtime/parrot/library/PGE/Util.pir trunk/src/string.c -- Will Coke Coleda [EMAIL PROTECTED]
Re: [svn:parrot] r16706 - in trunk: compilers/tge/TGE languages/tcl/config/makefiles languages/tcl/lib languages/tcl/src languages/tcl/t runtime/parrot/library/PGE src
Will, I'm really deeply sorry for reverting stuff with my last commit. It's definitely not what I intended. I didn't even edit the tcl (and other) files, which is what is totally weird. I wanted to commit a line endings change to shootout.t in lua, but when I went 'svk push' I got an Empty commit message error again and the only way I know to fix this is to use 'svk merge -c revision_number //parrot/local/ //parrot/remote -m a non-empty commit message', then it seems to commit everything back. This time it threw up a whole lot of conflicts with files that I hadn't touched, and I just used the 'theirs' option when prompted to by svk (so it should leave it as-is right?). I have absolutely no idea why it keeps doing it to me. It makes me rather reticent to make any changes and commit them locally. Perhaps I should go back to svn, which would be really annoying for me, but less annoying for everyone else. Paul, did you mean to update all these tcl files with your patch with no commit message? No. I used the 'theirs' option when svk flagged conflicts, see above. If not, this isn't the first time you've reverted code elsewhere in the repository when doing your manual merges... (and it affected tcl last time, too.) - Please fix them. Ok, will do. Am very, very sorry for causing the inconvenience, both for this and the last time. If so, please use *real* commit messages so we know what you're updating. I try to use clear commit messages when making my normal changes. In either case, we might want to review how you're using svk. Agreed. If you have any advice or ideas (other than going back to svn) I would love to know. Unable to express how apologetic I am. Paul
Re: [svn:parrot] r16706 - in trunk: compilers/tge/TGE languages/tcl/config/makefiles languages/tcl/lib languages/tcl/src languages/tcl/t runtime/parrot/library/PGE src
On Friday 19 January 2007 04:46, Paul Cochrane wrote: I wanted to commit a line endings change to shootout.t in lua, but when I went 'svk push' I got an Empty commit message error again and the only way I know to fix this is to use 'svk merge -c revision_number //parrot/local/ //parrot/remote -m a non-empty commit message', then it seems to commit everything back. Do you do 'svk pull' *immediately* before you push? Are you working on a mirrored copy? -- c
Re: [svn:parrot] r16706 - in trunk: compilers/tge/TGE languages/tcl/config/makefiles languages/tcl/lib languages/tcl/src languages/tcl/t runtime/parrot/library/PGE src
On 1/19/07, chromatic [EMAIL PROTECTED] wrote: On Friday 19 January 2007 04:46, Paul Cochrane wrote: I wanted to commit a line endings change to shootout.t in lua, but when I went 'svk push' I got an Empty commit message error again and the only way I know to fix this is to use 'svk merge -c revision_number //parrot/local/ //parrot/remote -m a non-empty commit message', then it seems to commit everything back. Do you do 'svk pull' *immediately* before you push? Are you working on a mirrored copy? as chromatic hints at here, you should make sure you have the latest SVN::Mirror. i know we've seen problems with svk in the past with empty commit messages, and this was (part of)? the solution. ~jerry
Re: [svn:parrot] r16706 - in trunk: compilers/tge/TGE languages/tcl/config/makefiles languages/tcl/lib languages/tcl/src languages/tcl/t runtime/parrot/library/PGE src
I wanted to commit a line endings change to shootout.t in lua, but when I went 'svk push' I got an Empty commit message error again and the only way I know to fix this is to use 'svk merge -c revision_number //parrot/local/ //parrot/remote -m a non-empty commit message', then it seems to commit everything back. Do you do 'svk pull' *immediately* before you push? Are you working on a mirrored copy? I'm working from a mirrored copy, and my usual work cycle is: svk up -sm ... edit stuff ... svk commit files (svk smerge -C //parrot/local //parrot/remote) svk push (which used to be svk smerge -Il --verbatim //parrot/local //parrot/remote, until I had a discussion with Coke about svk and he said he only used svk push) The problems started occurring with empty commit messages when I was still using just smerge. This is what was recommended on the svk wiki. Paul
Re: [svn:parrot] r16706 - in trunk: compilers/tge/TGE languages/tcl/config/makefiles languages/tcl/lib languages/tcl/src languages/tcl/t runtime/parrot/library/PGE src
On 19/01/07, jerry gay [EMAIL PROTECTED] wrote: On 1/19/07, chromatic [EMAIL PROTECTED] wrote: On Friday 19 January 2007 04:46, Paul Cochrane wrote: I wanted to commit a line endings change to shootout.t in lua, but when I went 'svk push' I got an Empty commit message error again and the only way I know to fix this is to use 'svk merge -c revision_number //parrot/local/ //parrot/remote -m a non-empty commit message', then it seems to commit everything back. Do you do 'svk pull' *immediately* before you push? Are you working on a mirrored copy? as chromatic hints at here, you should make sure you have the latest SVN::Mirror. i know we've seen problems with svk in the past with empty commit messages, and this was (part of)? the solution. Hrm, my package manager (I'm using Gentoo) says version 0.72, but in /usr/lib/perl5/site-perl/5.8.8/SVN/Mirror.pm says 0.68. This could be the problem... I'll have a look and see if this keeps causing problems. Thanks to you both for your responses, Paul
Re: [svn:parrot] r16706 - in trunk: compilers/tge/TGE languages/tcl/config/makefiles languages/tcl/lib languages/tcl/src languages/tcl/t runtime/parrot/library/PGE src
Paul Cochrane wrote: Essentially you should svk pull before any commit or push operation, which helps avoid having to do conflict resolution. I'm adding in spots in all caps where you should do a svk pull. Kevin I'm working from a mirrored copy, and my usual work cycle is: svk up -sm looks pretty equivalent to a svk pull. SVK PULL svk up -sm ... edit stuff ... SVK PULL svk commit files SVK PULL ( this one can probably be ommitted if your commit is immediately followed by a push) (svk smerge -C //parrot/local //parrot/remote) svk push (which used to be svk smerge -Il --verbatim //parrot/local //parrot/remote, until I had a discussion with Coke about svk and he said he only used svk push) The problems started occurring with empty commit messages when I was still using just smerge. This is what was recommended on the svk wiki. Paul
Re: [svn:parrot] r16706 - in trunk: compilers/tge/TGE languages/tcl/config/makefiles languages/tcl/lib languages/tcl/src languages/tcl/t runtime/parrot/library/PGE src
On Jan 19, 2007, at 7:46 AM, Paul Cochrane wrote: Will, I'm really deeply sorry for reverting stuff with my last commit. Heh. Things happen. It's ok. Jerry did worse to tcl just before the release. =-) I appreciate the fix up. I was a certainly a little grumpy, but it's fixed, before I even had a chance to sit back down and look at the code. Good enough, thanks. =-) -- Will Coke Coleda [EMAIL PROTECTED]
Re: [svn:parrot] r16706 - in trunk: compilers/tge/TGE languages/tcl/config/makefiles languages/tcl/lib languages/tcl/src languages/tcl/t runtime/parrot/library/PGE src
as chromatic hints at here, you should make sure you have the latest SVN::Mirror. i know we've seen problems with svk in the past with empty commit messages, and this was (part of)? the solution. It seems I had two versions of SVN::Mirror floating around. Version 0.72 (the latest) was in /usr/lib/perl5/vendor_perl, but there was an old one in /usr/lib/perl5/site_perl (which I guess was probably being used instead). We'll see how I get on from now on. Many thanks for everyone's suggestions! Paul
Re: runtime/parrot/library
Jonathan Scott Duff wrote: Is there some reason that runtime/parrot/library isn't in the list of search paths for both include_paths and dynext_paths? Fixed. load_bytecode PGE.pbc# should work now i.e. load_bytecode searches now: - runtime/parrot/library/ - runtime/parrot/ - ./ currently prefixed by the directory parrot was built in. prefix path for an installed parrot will follow soon. -Scott leo
runtime/parrot/library
Is there some reason that runtime/parrot/library isn't in the list of search paths for both include_paths and dynext_paths? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: runtime/parrot/library
Jonathan Scott Duff [EMAIL PROTECTED] wrote: Is there some reason that runtime/parrot/library isn't in the list of search paths for both include_paths and dynext_paths? No. We have: load_bytecode = Parrot_load_bytecode *.pbc = PackFile_append.pbc = Parrot_readbc = Parrot_locate_runtime_file( ... PARROT_RUNTIME_FT_PBC) else = IMCC_compile_file = imcc_compile_file = Parrot_locate_runtime_file( ... PARROT_RUNTIME_FT_SOURCE) In Parrot_locate_runtime_file() there is no special case for these file types, they go along with the include paths, which isn't quite right. Therefore we'd need another default search path for these two file kinds. Takers wanted. -Scott leo
runtime/parrot/library/config.pbc
What generates runtime/parrot/library/config.pbc ?
It seems that make clean can remove it, and then any subsequent make fails:
$ make all
Compiling with:
xx.c
cc -DAPPLLIB_EXP=/usr/local/lib/perl5/5.6.1/BSDPAN -I/usr/local/include -g
-Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow
-Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return
-Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security
-Wpacked -Wdisabled-optimization -mno-accumulate-outgoing-args -Wno-shadow
-falign-functions=16 -I./include -I./blib/include -DHAS_JIT -DI386
-DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c
/usr/bin/perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? 8;' docs
/usr/bin/perl -e '-d or mkdir $_,0777 or die foreach @ARGV' ops
make: don't know how to make runtime/parrot/library/config.pbc. Stop
Nicholas Clark
Re: runtime/parrot/library/config.pbc
On Thu, Nov 11, 2004 at 02:49:24PM +0100, Leopold Toetsch wrote: Nicholas Clark wrote: What generates runtime/parrot/library/config.pbc ? It's an extension rule .imc.pbc. It seems that make clean can remove it, and then any subsequent make fails: No problem here, jsut tried it. Aha. Then it looks like it's a problem with the Makefile on FreeBSD make. time passes It seems that FreeBSD make wants .SUFFIXES above the first line that uses one of the suffixes. I committed a fix. Nicholas Clark
