[perl #19031] [PATCH] befunge's Makefile autogenerated by configure
# New Ticket Created by Jerome Quelin
# Please include the string: [perl #19031]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19031 >
Thanks to bf's example, I'm now writing Befunge Makefile while
configuring Parrot. I hope that I did not miss sthg important. Please
note that $PARROT/languages/befunge/Makefile should go (the patch only
empties it AFAICT) - and I removed it from MANIFEST.
Jerome
--
[EMAIL PROTECTED]
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/44730/35353/797778/befunge_makefile_autogen.patch
diff -urbN parrot.old/config/gen/makefiles/befunge.in parrot/config/gen/makefiles/befunge.in
--- parrot.old/config/gen/makefiles/befunge.in 1970-01-01 01:00:00.0 +0100
+++ parrot/config/gen/makefiles/befunge.in 2002-12-11 09:19:27.0 +0100
@@ -0,0 +1,16 @@
+RM_F = ${rm_f}
+PERL = ${perl}
+
+ASSEMBLE=$(PERL) ../../assemble.pl
+PARROT=../../parrot
+
+all: build
+
+test: build
+ $(PARROT) befunge.pbc test.bef
+
+build: befunge.pasm debug.pasm flow.pasm io.pasm load.pasm maths.pasm stack.pasm
+ $(ASSEMBLE) befunge.pasm > befunge.pbc
+
+clean:
+ $(RM_F) core *.pbc *~
diff -urbN parrot.old/config/gen/makefiles.pl parrot/config/gen/makefiles.pl
--- parrot.old/config/gen/makefiles.pl 2002-12-11 09:16:59.0 +0100
+++ parrot/config/gen/makefiles.pl 2002-12-11 09:18:09.0 +0100
@@ -29,6 +29,8 @@
commentType => '#');
genfile('config/gen/makefiles/bf.in','languages/bf/Makefile',
commentType => '#');
+ genfile('config/gen/makefiles/befunge.in', 'languages/befunge/Makefile',
+ commentType => '#');
}
1;
diff -urbN parrot.old/languages/befunge/Makefile parrot/languages/befunge/Makefile
--- parrot.old/languages/befunge/Makefile 2002-12-11 09:17:13.0 +0100
+++ parrot/languages/befunge/Makefile 1970-01-01 01:00:00.0 +0100
@@ -1,17 +0,0 @@
-ASSEMBLE=perl ../../assemble.pl
-PARROT=../../parrot
-
-test: build
- $(PARROT) befunge.pbc test.bef
-
-build: befunge.pasm flow.pasm io.pasm load.pasm maths.pasm stack.pasm
- $(ASSEMBLE) befunge.pasm > befunge.pbc
-
-clean:
- rm -f core *.pbc *~
-
-dist: clean
- rm -f befunge.tgz
- ( cd .. ; tar cvf befunge.tar Befunge-93 )
- gzip ../befunge.tar
- mv ../befunge.tar.gz befunge.tgz
diff -urbN parrot.old/MANIFEST parrot/MANIFEST
--- parrot.old/MANIFEST 2002-12-11 09:16:59.0 +0100
+++ parrot/MANIFEST 2002-12-11 09:17:33.0 +0100
@@ -1289,7 +1289,6 @@
languages/BASIC/tokenize.pasm
languages/BASIC/wumpus.bas
languages/befunge/Changes
-languages/befunge/Makefile
languages/befunge/README
languages/befunge/befunge.pasm
languages/befunge/debug.pasm
This week's summary
The Perl 6 Summary for the week ending 20021208 Another Monday evening. Another summary to write. Starting, as is becoming tediously predictable, with perl6-internals. Another JIT discussion Toward the end of the previous week, Leopold Tötsch posted something about the latest round of changes to the JIT core. Daniel Grunblatt was concerned that the current JIT wasn't doing the right thing when it came hardware register allocation and wanted to remove a some conditional logic. Leo didn't agree at first, but became convinced and Daniel's requested change was applied. http://makeashorterlink.com/?P4AB24AB2 Fun with IMCC Lots of things happened with IMCC this week: * David Robins posted a list of minor niggles (For instance, it turns out you can't "ret" early from a ".sub") and suggested some remedies. Leo Tötsch mentioned that the IMCC Cabal (which would consist of Melvin Smith, Sean O'Rourke, Angel Faus and Leo if there were a Cabal. But, as everyone knows, There Is No Cabal) have been discussing several of these issues. http://makeashorterlink.com/?Q1BB22AB2 http://makeashorterlink.com/?W1CB43AB2 * Art Haas had problems building IMCC, apparently bison didn't like the imcc.y file. Leo tracked down the problem (at the second time of asking, I think he might be slipping) and checked in a working fix. * Leo Tötsch made a pile of changes to IMCC to eliminate clashes between Parrot's PASM language and IMCC's PIR syntax, which had made it hard to mix the two. Full details of the changes are in his post. Gopal V wondered if there was any way of feeding code to IMCC beyond simply writing to a file and running IMCC. He'd had to make a bunch of changes to the IMCC files that he used, and wondered if there was a Better Way. Actually he didn't so much wonder as propose the aforementioned Better Way, lifting ideas from DotGNU's treecc. He and Leo discussed things, worked out an interface and Gopal went off to implement something (Yay Gopal!) http://makeashorterlink.com/?Y1DB21AB2 http://makeashorterlink.com/?A6EB42AB2 * Steve Fink posted a patch implementing a first cut at namespace support in IMCC. He wasn't at all sure that what he'd implemented was the Right Thing, but it supplied what he needed for the time being (if that makes sense) in the regex engine. Leo reckoned that it looked okay, and promised to apply it if nobody hollered. He also pointed out some problems with the current regex implementation to do with reentrancy and memory leakage. It turns out that Steve was working on languages/regex rather than the "rx_*" ops, which are the ones that have the problems. http://makeashorterlink.com/?P2FB16AB2 * Gregor N. Purdy had some problems with IMCC's syntax, a fragment of code that he thought should work fell over in a heap. Both Mr. Nobody and Leo pointed out that IMCC expects subroutines, and you should wrap your code in a ".sub"/".end" pair. Once Gregor had that straight he posted a Jako program and the IMCC code he thought the Jako compiler should generate from it and asked for any feedback before he went to change the compiler. Leo Tötsch provided some (I assume) useful feedback. A little later Gregor posted again, he was still having problems with IMCC not quite behaving as he wanted for the Jako compiler. He and Leo thrashed it out over a few messages and, to cut a long story short, IMCC looks like it won't be changing. I'm not sure whether Gregor is happy about this... http://makeashorterlink.com/?X30C22AB2 http://makeashorterlink.com/?J51C32AB2 * Mr Nobody posted a patch to get IMCC to compile under windows. Apparently the "OUT" label clashes with something in the windows header files. The patch got applied. * Gregor N. Purdy got a little confused by how IMCC generates PASM code, and posted some sample code, interspersed with questions. Which Leo answered. It's worth looking at this; it shows off the kind of optimization that IMCC gets up to. http://makeashorterlink.com/?E22C25AB2 http://makeashorterlink.com/?Y53C22AB2 PMCs are the thing Dan announced that he's finally stopped waffling and frozen the PMC structures `modulo the odd twiddling to it.' He's added a pmc.ops file, and has started adding in ops to manipulate PMC internals. Leo asked for some clarifications, got some, and then wondered what the final 'Parrot Object' will look like. http://makeashorterlink.com/?Z34C23AB2 "logical_not" issue David Robins is having fun with "logical_not" and Ruby. The issue is t
Re: [INFO] Buffer/PMC unification
Changes #6. - PMC_*_FLAGs are history. - I did remove the bogus looking, unused, untested and superfluous from core.ops All access to PMC/Buffer->flags has to be done via the accessor macros in pobj.h. If some are missing, please add them, when needed. Next will be hiding other Buffer/PMC structure members that might conflict, like buffer and buflen. leo
Re: Parrot v0.0.9 code freeze
I'm still not sure what the problem is...but if you turn --gc-debug off, then the array diminsions are correct...e.g., 10 for the first dimension. Therefore, the calculation of the array index is performed correctly. However, with --gc-debug on, the array dimension is correct for the first dimension (0,0 - 0,20) as well as the first element of the first dimension...(1,0). But it is wrong for all of the others. It becomes 1 instead of 10. I have no clue yet why...still looking into it. However, all tests pass on Tru64 if --gc-debug is off. - Original Message - From: "Tanton Gibbs" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 10, 2002 7:13 PM Subject: Re: Parrot v0.0.9 code freeze > I'm looking at the Tru64 problem. > > The manifest problem is trivial: > languages/jako/docs/jako.pod needs to be added to the MANIFEST > > The multiarray problem only occurs if you turn on --gc-debug...still looking > at it > > Tanton > - Original Message - > From: "Steve Fink" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, December 10, 2002 4:45 PM > Subject: Parrot v0.0.9 code freeze > > > > Heads up. The weather report indicates a feature freeze on Sat > > 2002-Dec-14 at 20:00 GMT (12:00 PST, 15:00 EST, 21:00 CET), leading to > > a release on Wed 2002-Dec-18. So if you have any feature changes that > > you want to get into 0.0.9 (and it isn't too destabilizing), please > > commit them before Saturday. > > > > Sometime between now and then, I'll compile a list of changes since > > 0.0.8. > > > > This release will go out even if the tinderbox isn't completely green, > > because I don't want to delay it any further, but I would greatly > > appreciate any improvements in that area. Feel free to use > > http://foxglove.dnsalias.org/parrot/ to get a snapshot view of what > > tests are failing. > > > > > > >
[INFO] Buffer/PMC unification - #7 and finito for now
Done. Buffers and PMCs are Parrot Objects now, sharing a common header, PObj. The struct members: - buffer - buflen - cache - version (for GC_DEBUG) are actually #defines now. This implies that the usage of these names is forbidden in the whole parrot tree. This rule will last until the final structures are fixed, and somone changes all usage of above data members to the real thing. Finally I was to lazy to change all ->flags in keys.c and list.c, a macro in these files is used to access flags directly. make quickfulltest doesn't show any error, nor do perl6 tests. After the feature freeze/release, we can have a look at DOD/GC & Buffer/PMC memory management functions to look, what can be simplified then. Please do a "make clean" after checkout. Have fun, leo
Re: Curses Life
On Tue, Dec 10, 2002 at 06:04:44PM +, Piers Cawley wrote: > Dan Sugalski <[EMAIL PROTECTED]> writes: > > > At 4:45 PM + 12/5/02, Leon Brocard wrote: > >>Leon Brocard sent the following bits through the ether: > >>Ah, well, I gave up on SDL as it was a little complicated. Instead, I > >>played with curses. Please find attached a cute little curses life > >>program loading and calling curses at runtime with dlfunc. > >> > >>Oh, and I made the shape a small spaceship as it's more interesting. > > > > Leon, you're really scary, y'know that? :) > > I've suggested he work on getting Readline working next. Then, once > he's done the zmachine loader and got a zmachine opcode set up and > running... and then all get digressed into playing http://astray.com/Bookshop.z5 (see http://london.pm.org/pipermail/london.pm/Week-of-Mon-20010924/005441.html ) Nicholas Clark
Re: Naiive .const directive for imcc
[EMAIL PROTECTED] wrote: Leo -- I tried my hand at adding a naiive (that is, incorrect) version of .const = I'll implement such a thing based on your patch and on the recent lexical changes. Constants declared like above will be real constants without register usage. Syntax will be like in your patch. leo
Re: Parrot v0.0.9 code freeze
On Tue, 10 Dec 2002, Tanton Gibbs wrote: > I'm looking at the Tru64 problem. > > The manifest problem is trivial: > languages/jako/docs/jako.pod needs to be added to the MANIFEST Implicit patch applied, thanks. Simon
Jako and Native Calls
Dan -- We were talking earlier about Jako supporting native calls. I have looked at PDD 6 and PDD 3, and here's what I think so far... I don't think I can get the native call stuff working until I have IMCC support for PDD 3. IMCC is totally in charge of what goes into each register, and I like it that way. I think I'd need something like this: .pcall .parg ... .parg ... call _whatever .pend (prefix "P" for Parrot standard convention). The .pcall directive resets any IMCC bookkeeping about any previous calls and what registers were in use. The .parg directives plop things where they go and increment the counters. The .pend directive means done with this call. Free up registers for other stuff, since I've got what I need. This would be enough, I think, for me to create Jako calls out to native stuff. Assuming the native stuff plops its return value according to PDD 6, then we'll need the IMCC support for that, too. It might be handy for the entire (1) set up args (2) call out (3) deal with returned values sequence to be wrapped between .pcall and .pend: loadlib $P38, "libsdl" dlfunc $P39, $P38, "SDL_BlitSurface", "i" .pcall .parg $P33 .parg $P34 .parg $P35 .parg $P36 invoke $P39 .pres $I100 .pend jakoc would have to know what virtual register types to use for this to work out. It would probably look something like this in Jako: sub int SDL_BlitSurface : "libsdl:SDL_BlitSurface:i" (obj src, obj, srcrect, obj dst, obj dstrect); Where the third colon-separated field is redundant in this case and can become the empty string. Or possibly (a call without a previous declaration): var int foo = SDL_BlitSurface : "libsdl:SDL_BlitSurface:i" (a, b, c, d); (although please don't hold me to these syntax ideas -- they are only my first ones). Things that would make this nice: * Multiple loadlibs for the same lib don't cause trouble and are fast. * Same for multiple dlfunc calls for the same thing. Anyway, more thinking and talking is probably in order. I'd love to see an imcc implementation of PDD 3 like or better than the above sketch, so I can rely on IMCC to keep all the register stuff straight. After that, I don't think the incremental effort in jakoc creates a high barrier. Regards, -- Gregor
Properties
Are in. You can now get, set, delete, and get a hash of PMC properties. (Hopefully) Alas, no tests. Working on that, but if someone wants to beat me to it, feel free. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Properties
On Wed, 11 Dec 2002, Dan Sugalski wrote: > Are in. You can now get, set, delete, and get a hash of PMC > properties. (Hopefully) > > Alas, no tests. Working on that, but if someone wants to beat me to > it, feel free. I would expect this: new P0, .PerlInt new P1, .PerlInt set S0, "Brown" set P0, "Yes" setprop P1, S0, P0 set S0, "Black" set P0, "No" setprop P1, S0, P0 new P2, .PerlString getprop P2, "Brown", P1 print P2 print "\n" getprop P2, "Black", P1 print P2 print "\n" end to print: Yes No In fact, it prints: No No Is this a bug, or am I misunderstanding how properties are supposed to work? Simon
Re: Properties
On Wed, 11 Dec 2002, Simon Glover wrote: > > Is this a bug, or am I misunderstanding how properties are supposed to > work? Well, there's definitely a bug somewhere, as the previously posted example causes a segfault if run with --gc-debug. Backtrace follows: #0 0x08075bb1 in hash_lookup (interpreter=0x813a8f0, hash=0x0, key=0x813d528) at hash.c:355 #1 0x08075bff in hash_get (interpreter=0x813a8f0, hash=0x0, key=0x813d528) at hash.c:363 #2 0x080d8ff8 in Parrot_PerlHash_get_pmc_keyed (interpreter=0x813a8f0, pmc=0x8147928, key=0x81479dc) at perlhash.pmc:181 #3 0x080d30a1 in Parrot_default_getprop (interpreter=0x813a8f0, pmc=0x8147970, key=0x813d528) at default.pmc:54 #4 0x080bc0ee in cg_core () at core.ops:3873 #5 0x08074144 in runops_cgoto_core (interpreter=0x813a8f0, pc=0x813f618) at runops_cores.c:52 #6 0x08049730 in runops_generic (core=0x8074130 , interpreter=0x813a8f0, pc=0x813f618) at interpreter.c:46 #7 0x08049e45 in runops (interpreter=0x813a8f0, code=0x813ac88, offset=0) at interpreter.c:372 #8 0x080a63b5 in Parrot_runcode (interpreter=0x813a8f0, argc=1, argv=0xbfffe4bc) at embed.c:308 #9 0x080e217e in main (argc=1, argv=0xbfffe4bc) at test_main.c:51 #10 0x400b4647 in __libc_start_main (main=0x80e20e8 , argc=3, ubp_av=0xbfffe4b4, init=0x8048f78 <_init>, fini=0x80e2790 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbfffe4ac) Simon
[perl #19059] [PATCH] jako.in portability
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #19059]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19059 >
Attached, please find a patch that makes jako's makefile slightly more
portable. It adds in the appropriate ${exe}, and removes the dependency
on "ln -s" to have a local copy of the executable. Tested, works on
cygwin. If it doesn't break gregor
Perhaps now I can get around to seeing why jako's "make test" is dying...
Enjoy.
--
Will "Coke" Coleda
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/44940/35429/90428e/jako.in.patch
--- jako.in Wed Dec 11 18:53:52 2002
+++ jako.in_new Wed Dec 11 20:36:17 2002
@@ -10,7 +10,7 @@
DIR=languages/jako
TOOL_DIR=../..
ASM=$(PERL) -I ../../lib ../../assemble.pl
-IMCC=imcc
+IMCC=../imcc/imcc${exe}
JAKOC=$(PERL) -I lib jakoc
INTERP=../../${test_prog}
@@ -64,11 +64,8 @@
.imc.pasm:
$(IMCC) -o $@ $< || (rm -f $@ && false)
-../imcc/imcc:
- @cd ../imcc make
-
-imcc: ../imcc/imcc
- ln -s ../imcc/imcc imcc
+imcc: ../imcc/imcc${exe}
+ @cd ../imcc && make
examples/bench.pasm: examples/bench.imc imcc
examples/euclid.pasm: examples/euclid.imc imcc
@@ -110,7 +107,7 @@
#
clean:
- $(RM_F) imcc examples/*.imc examples/*.pasm examples/*.list examples/*.pbc
+ $(RM_F) examples/*.imc examples/*.pasm examples/*.list examples/*.pbc
over:
@$(MAKE) clean
Re: Parrot v0.0.9 code freeze
On Dec-10, Tanton Gibbs wrote: > I'm looking at the Tru64 problem. Yay! Thank you.
Re: Parrot v0.0.9 code freeze
On Dec-11, Tanton Gibbs wrote: > I'm still not sure what the problem is...but if you turn --gc-debug > off, then the array diminsions are correct...e.g., 10 for the first > dimension. Therefore, the calculation of the array index is > performed correctly. However, with --gc-debug on, the array > dimension is correct for the first dimension (0,0 - 0,20) as well as > the first element of the first dimension...(1,0). But it is wrong > for all of the others. It becomes 1 instead of 10. I have no clue > yet why...still looking into it. However, all tests pass on Tru64 if > --gc-debug is off. Are the Tru64 registers scanned for live PMCs/Buffers? I don't know what things would typically get missed that way, but it's a known problem for most architectures (or was until recently? What's the status on this?) Does Tru64 have hardware breakpoints? They're nice for this sort of thing -- find a value that eventually becomes incorrect, take the address of it at a point when it is still correct, then watch what it points to: (gdb) p interpreter->ctx.pmc_reg.registers[0]->cache.int_val $6 = 1 (gdb) p &interpreter->ctx.pmc_reg.registers[0]->cache.int_val $7 = (INTVAL *) 0x810c904 (gdb) watch *$7 Hardware watchpoint 2: *$7 (gdb) continue . . . Except that the garbage collector tends to move stuff around, which can defeat this scheme. I doubt any of this was useful, but just in case...
