[perl #26888] [PATCH] Minor doc patch for imcc/docs/macros.pod
# New Ticket Created by Ilya Martynov # Please include the string: [perl #26888] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=26888 Index: imcc/docs/macros.pod === RCS file: /cvs/public/parrot/imcc/docs/macros.pod,v retrieving revision 1.7 diff -u -d -r1.7 macros.pod --- imcc/docs/macros.pod23 Oct 2003 17:02:54 - 1.7 +++ imcc/docs/macros.pod19 Feb 2004 09:54:20 - @@ -44,7 +44,7 @@ .endm Include this macro as many times as you like, and the branch statement should -do the right thing every time. To use a global label, just as you usually do. +do the right thing every time. To use a global label, do just as you usually do. Constants are new, and the syntax looks like: -- Ilya Martynov, [EMAIL PROTECTED] CTO IPonWEB (UK) Ltd Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net Personal website - http://martynov.org
Re: [PATCH] Re: [perl #25239] Platform-specific files not granular enough
Adam Thomason wrote: Hopefully in time to make the feature freeze, here's an effort at solving this problem. Looks really good. I've applied it here (with little tweaks in Configure/Step.pm) and it works fine. Testing very much requested, most especially on Darwin and Win32. Yeah. Anyway, I'll apply it if no one hollers. If something will break on these platforms, it should be fixable easily. BTW what is aix.s doing? Could you add some comments please. Adam Thanks for this big patch, leo
RE: [PATCH] Re: [perl #25239] Platform-specific files not granular enough
-Original Message- From: Leopold Toetsch [mailto:[EMAIL PROTECTED] Sent: Thursday, February 19, 2004 1:00 AM To: Adam Thomason Cc: [EMAIL PROTECTED] Subject: Re: [PATCH] Re: [perl #25239] Platform-specific files not granular enough BTW what is aix.s doing? Could you add some comments please. It's one of the fixups for JIT under AIX (not actually relevant to this patch, whoops). Two asm functions (ppc_sync and ppc_dcbf) are required to guarantee cache goodness. The extra stabs and other junk are from -g. I'll try to clean it up and document it for the forthcoming AIX patch. ATM it does nothing since these funcs aren't called in functional scenarios, i.e. no harm in omitting it for now. Adam
Another todo: Forth as compiler
While the actual compiler code is evil, doing all sorts of things it ought not do with absolute addresses (and therefore non-JITtable), the forth compiler does work, and will compile things. It ought, actually, to be able to be integrated in as a compiler. Your task, if you're interested, is to thump it such that forth.pasm *can* be loaded in as a compiler module such that you can do: compile P5, ForthCompiler, 1 2 + . and have 3 print out. Should be easy, relatively speaking. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Another todo: Forth as compiler
Dan Sugalski [EMAIL PROTECTED] wrote: While the actual compiler code is evil, doing all sorts of things it ought not do with absolute addresses (and therefore non-JITtable), the forth compiler does work, and will compile things. It ought, actually, to be able to be integrated in as a compiler. Your task, if you're interested, is to thump it such that forth.pasm *can* be loaded in as a compiler module such that you can do: compile P5, ForthCompiler, 1 2 + . and have 3 print out. Should be easy, relatively speaking. Three Notes WRT that: 1) examples/assembly/nano_forth2.pasm uses PCC to implement such a compiler. No address hacks, but likely a bit slower. 2) I've checked in the compreg Sx, Py opcode, where Py is a Parrot Sub. 3) I'll check in an example soon, how to load and run a compiler written in C and residing in a shared lib. I'm just waiting for some ok WRT the platform patch, which I've pending too. leo
Re: [PATCH] Re: [perl #25239] Platform-specific files not granular enough
Adam Thomason [EMAIL PROTECTED] wrote: [ big patch ] Thanks, applied. leo
Re: [PATCH] IO fixes for Win32
--- Dan Sugalski [EMAIL PROTECTED] wrote: At 12:40 AM +0300 2/18/04, Vladimir Lipsky wrote: From: Goplat [EMAIL PROTECTED] --- Vladimir Lipsky [EMAIL PROTECTED] wrote: From: Goplat [EMAIL PROTECTED] flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is not supported in win98 A fix for that should be windows version specific and needs support of the config subsystem. If you did that, a version compiled on NT wouldn't work on 9x. I'd say most 9x users don't compile perl themself, they just download a binary from ActiveState (who use NT)... Then there should be different binaries for different versions Yeah, I'm actually coming to that conclusion. Yes, it's sort of easier to keep a single binary around from a packaging standpoint, it's a hassle for everyone else because of it. Where is the hassle? It's just a few lines of code to check windows version. It's easier to code that than to make another configure option. __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
[PATCH] Re: [perl #25239] Platform-specific files not granular enough
At 8:01 PM + 2/18/04, Adam Thomason via RT wrote: Attached patch is tested on Linux, AIX, and OpenBSD. It does twiddle the order of includes and declarations, so there might still be problems. Testing very much requested, most especially on Darwin and Win32. I've applied this locally and it's building in the background -- it looks darned good, and I'm happy to get it applied. If it breaks Win32 (and I'd bet not) then we can fix it. Definitely gets us in a really good position, though. Thanks! -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] IO fixes for Win32
At 09:27 AM 2/19/2004 -0800, Goplat wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 12:40 AM +0300 2/18/04, Vladimir Lipsky wrote: From: Goplat [EMAIL PROTECTED] --- Vladimir Lipsky [EMAIL PROTECTED] wrote: From: Goplat [EMAIL PROTECTED] flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is not supported in win98 A fix for that should be windows version specific and needs support of the config subsystem. If you did that, a version compiled on NT wouldn't work on 9x. I'd say most 9x users don't compile perl themself, they just download a binary from ActiveState (who use NT)... Then there should be different binaries for different versions Yeah, I'm actually coming to that conclusion. Yes, it's sort of easier to keep a single binary around from a packaging standpoint, it's a hassle for everyone else because of it. Where is the hassle? It's just a few lines of code to check windows version. It's easier to code that than to make another configure option. Then submit a patch. I have no problem with that scenario. The code in question is mine, but I don't have the ability to play with older versions of Windows. I develop on XP, 2000, Linux and Solaris, and I really don't claim to be much of a Windows programmer, outside of Winsock. -Melvin
Re: Objects: Now or forever (well, for a while) hold your peace
At 7:30 PM -0500 2/18/04, Simon Glover wrote: One really pedantic comment: wouldn't it make sense to rename the fetchmethod op to fetchmeth, for consistency with callmeth, tailcallmeth etc? Good point. I'll change that, then. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] Re: [perl #25239] Platform-specific files not granular enough
- Original Message - From: Dan Sugalski [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, February 19, 2004 3:10 PM Subject: [PATCH] Re: [perl #25239] Platform-specific files not granular enough At 8:01 PM + 2/18/04, Adam Thomason via RT wrote: Attached patch is tested on Linux, AIX, and OpenBSD. It does twiddle the order of includes and declarations, so there might still be problems. Testing very much requested, most especially on Darwin and Win32. I've applied this locally and it's building in the background -- it looks darned good, and I'm happy to get it applied. If it breaks Win32 (and I'd bet not) then we can fix it. Definitely gets us in a really good position, though. Thanks! The good news (for Dan) is that he didn't place any money on his bet about this breaking on Win32. The bad news is that it does break Win32... src\exceptions.c exceptions.c c:\documents and settings\jonathan\desktop\pow\parrot\src\exceptions.c(125) : error C2065: 'SIGQUIT' : undeclared identifier NMAKE : fatal error U1077: 'F:\Perl\bin\perl.exe' : return code '0x2' Stop. I'll try and take a look later tonight. Jonathan
Re: [PATCH] IO fixes for Win32
--- Melvin Smith [EMAIL PROTECTED] wrote:
At 09:27 AM 2/19/2004 -0800, Goplat wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 12:40 AM +0300 2/18/04, Vladimir Lipsky wrote:
From: Goplat [EMAIL PROTECTED]
--- Vladimir Lipsky [EMAIL PROTECTED] wrote:
From: Goplat [EMAIL PROTECTED]
flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is
not supported in win98
A fix for that should be windows version specific and needs
support of the config subsystem.
If you did that, a version compiled on NT wouldn't work on 9x. I'd
say most 9x users don't compile perl themself, they just download a
binary from ActiveState (who use NT)...
Then there should be different binaries for different versions
Yeah, I'm actually coming to that conclusion. Yes, it's sort of
easier to keep a single binary around from a packaging standpoint,
it's a hassle for everyone else because of it.
Where is the hassle? It's just a few lines of code to check windows
version. It's easier to code that than to make another configure option.
Then submit a patch.
Okay. (attached)
__
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools--- io/io_win32.c~ Wed Feb 4 07:46:48 2004
+++ io/io_win32.c Tue Feb 17 08:21:16 2004
@@ -84,6 +84,20 @@
flags_to_win32(INTVAL flags, DWORD * fdwAccess,
DWORD * fdwShareMode, DWORD * fdwCreate)
{
+static DWORD dwDefaultShareMode;
+if (!dwDefaultShareMode) {
+OSVERSIONINFO osvi;
+osvi.dwOSVersionInfoSize = sizeof(osvi);
+GetVersionEx(osvi);
+if (osvi.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS) {
+dwDefaultShareMode = FILE_SHARE_READ | FILE_SHARE_WRITE;
+}
+else {
+dwDefaultShareMode =
+FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE;
+}
+}
+
if ((flags (PIO_F_WRITE | PIO_F_READ)) == (PIO_F_WRITE | PIO_F_READ)) {
*fdwAccess = GENERIC_WRITE | GENERIC_READ;
if (flags PIO_F_TRUNC)
@@ -103,7 +117,7 @@
*fdwCreate = OPEN_EXISTING;
}
-*fdwShareMode = FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE;
+*fdwShareMode = dwDefaultShareMode;
if (flags PIO_F_APPEND) {
/* dealt with specially in _write and _puts */
}
--- t/src/io.t~ Mon Feb 9 01:10:46 2004
+++ t/src/io.t Mon Feb 16 11:00:26 2004
@@ -11,6 +11,7 @@
my $content = @_ ? shift : This is a test\n;
open(FILE, $name) or die Failed to create $name;
+ binmode FILE;
print FILE $content;
close(FILE);
@@ -69,7 +70,7 @@
the_test(struct Parrot_Interp *interpreter,
opcode_t *cur_op, opcode_t *start)
{
-ParrotIO *io;
+PMC *io;
char *p;
io = PIO_STDOUT(interpreter);
@@ -100,15 +101,15 @@
the_test(struct Parrot_Interp *interpreter,
opcode_t *cur_op, opcode_t *start)
{
-ParrotIO *io;
+PMC *io;
char buf[1024];
-UINTVAL len;
+INTVAL len;
io = PIO_open(interpreter, NULL, temp.file, );
len = PIO_read(interpreter, io, buf, sizeof(buf)-1);
PIO_close(interpreter, io);
-buf[len] = '\0';
+buf[len 0 ? 0 : len] = '\0';
PIO_printf(interpreter, %s, buf);
io = PIO_open(interpreter, NULL, temp.file, );
@@ -117,8 +118,8 @@
do {
len = PIO_read(interpreter, io, buf, 3);
-buf[len] = '\0';
- /* dont write trailing spaces */
+buf[len 0 ? 0 : len] = '\0';
+/* don't write trailing spaces */
PIO_printf(interpreter, %d: %s\n, len, len ? buf : EOF);
} while (len 0);
@@ -142,7 +143,7 @@
the_test(struct Parrot_Interp *interpreter,
opcode_t *cur_op, opcode_t *start)
{
-ParrotIO *io;
+PMC *io;
io = PIO_open(interpreter, NULL, temp.file, );
PIO_write(interpreter, io, Parrot flies.\n, 14);
@@ -166,8 +167,8 @@
the_test(struct Parrot_Interp *interpreter,
opcode_t *cur_op, opcode_t *start)
{
-ParrotIO *io;
-size_t len;
+PMC *io;
+INTVAL len;
char buf[1024];
io = PIO_open(interpreter, NULL, temp.file, );
@@ -175,7 +176,7 @@
do {
len = PIO_read(interpreter, io, buf, sizeof(buf)-1);
-buf[len] = '\0';
+buf[len 0 ? 0 : len] = '\0';
PIO_printf(interpreter, %d: %s, len, len ? buf : EOF);
} while (len 0);
Re: Objects: Now or forever (well, for a while) hold your peace
On Feb-19, Dan Sugalski wrote: At 7:30 PM -0500 2/18/04, Simon Glover wrote: One really pedantic comment: wouldn't it make sense to rename the fetchmethod op to fetchmeth, for consistency with callmeth, tailcallmeth etc? Good point. I'll change that, then. D yo reall wan t repea C's infamou creat (mis)spellin? Admittedl, i i no ver ambiguou i thi cas, becaus ther ar alread s man letter, bu stil, tw extr letter i a smal pric t pa...
Re: Objects: Now or forever (well, for a while) hold your peace
At 10:21 AM -0800 2/19/04, Steve Fink wrote: On Feb-19, Dan Sugalski wrote: At 7:30 PM -0500 2/18/04, Simon Glover wrote: One really pedantic comment: wouldn't it make sense to rename the fetchmethod op to fetchmeth, for consistency with callmeth, tailcallmeth etc? Good point. I'll change that, then. D yo reall wan t repea C's infamou creat (mis)spellin? Admittedl, i i no ver ambiguou i thi cas, becaus ther ar alread s man letter, bu stil, tw extr letter i a smal pric t pa... Ok, Ok, point well taken. :) I'll go for the longer version all around. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[CVS ci] new japhs and compiler examples
I've checked in a bunch of JaPH examples. japh15 uses a compiler written in PASM to compile a program emitting the famous words. japh16 does the same by loading a shared lib with the compiler. The former scheme still has some problems with register saving, i.e. the PASM compiler doesn't preserve registers as compilers writen in C use to do. Have fun, leo
Re: [NEW] library/sdl.imc
chromatic wrote: On Fri, 2004-02-13 at 09:57, Jens Rieks wrote: here is an easy to use (with PIR code) wrapper of the SDL library. It tries to hide all internals of the wrapper and makes the most important SDL functions directly available in PIR code. Overall this looks good. [snip] Then, will it be checked in? I really dislike having to .include sdl.imc in a sub to .include the other outside... Jérôme -- [EMAIL PROTECTED]
Re: [PATCH] IO fixes for Win32
At 10:02 AM 2/19/2004 -0800, Goplat wrote: --- Melvin Smith [EMAIL PROTECTED] wrote: Where is the hassle? It's just a few lines of code to check windows version. It's easier to code that than to make another configure option. Then submit a patch. Okay. (attached) Very good, thank you sir. I see you also addressed another outstanding issue with the negative return val to read (into an unsigned). Did you run the test suite and get successes? If so, I will apply. -Melvin
Re: Objects: Now or forever (well, for a while) hold your peace
At 01:34 PM 2/19/2004 -0500, Dan Sugalski wrote: At 10:21 AM -0800 2/19/04, Steve Fink wrote: On Feb-19, Dan Sugalski wrote: At 7:30 PM -0500 2/18/04, Simon Glover wrote: One really pedantic comment: wouldn't it make sense to rename the fetchmethod op to fetchmeth, for consistency with callmeth, tailcallmeth etc? Good point. I'll change that, then. D yo reall wan t repea C's infamou creat (mis)spellin? Admittedl, i i no ver ambiguou i thi cas, becaus ther ar alread s man letter, bu stil, tw extr letter i a smal pric t pa... Ok, Ok, point well taken. :) I'll go for the longer version all around. I'm tossing you both in a lake ASAP. -Melvin
Re: [PATCH] Re: [perl #25239] Platform-specific files not granular enough
Jonathan Worthington [EMAIL PROTECTED] wrote: src\exceptions.c exceptions.c c:\documents and settings\jonathan\desktop\pow\parrot\src\exceptions.c(125) : error C2065: 'SIGQUIT' : undeclared identifier Seems that dumpcore is used from generic/signal.h You could try to create an empty win32/signal.h or insert #undef dumpcore in a file, that is included after signal.h's code. Jonathan leo
Release doc tasks
Mike's been doing an amazing job getting the docs in order, which is really cool. Things are looking good. There are, however, some big doc jobs that need tackling, and I'd like to get someone (or several someones) to dig into them. I'm working on PDD 15, which should be done soon, and I'll give PDD 3 another going-over to make sure it's right. The rest of the PDDs need a look-over to see where they fall down. (Several are pretty out of date, and others (like the NCI one) need more work) We need to get the IMCC /PIR docs significantly beefed up, so someone can take a look at things and actually generate code without too much head-scratching. The stuff in the docs/ directory needs looking over to see where things are out of date or need thumping. If someone wants to put together a skeleton plan for docs that really ought be in the tarball, we can use that to start filling in docs. And if everyone'd take a look at the intro docs to see where they need fixing, that'd be really great too. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [NEW] library/sdl.imc
On Thu, 2004-02-19 at 10:20, Jerome Quelin wrote: I really dislike having to .include sdl.imc in a sub to .include the other outside... Me too. There's supposed to be a magic initialization sub of some kind called on library load. I'm inclined to stick it in there, but it's not there yet. One downside of making sdl.imc smarter (changing it from sdl.pasm) is that we can no longer use build_tools/build_nativecall.pl as is. That may be an argument for making the tool smarter. Dan, Leo? -- c
Re: [PATCH] IO fixes for Win32
--- Melvin Smith [EMAIL PROTECTED] wrote: At 10:02 AM 2/19/2004 -0800, Goplat wrote: --- Melvin Smith [EMAIL PROTECTED] wrote: Where is the hassle? It's just a few lines of code to check windows version. It's easier to code that than to make another configure option. Then submit a patch. Okay. (attached) Very good, thank you sir. I see you also addressed another outstanding issue with the negative return val to read (into an unsigned). Did you run the test suite and get successes? If so, I will apply. Failed Test Stat Wstat Total Fail Failed List of Failed imcc/t/syn/file.t1 256121 8.33% 11 t/pmc/env.t 3 768 63 50.00% 3 5-6 t/pmc/perlarray.t1 256261 3.85% 26 t/pmc/sub.t 3 768493 6.12% 36-38 t/pmc/tqueue.t 2 512 52 40.00% 2-3 2 tests and 69 subtests skipped. Failed 5/94 test scripts, 94.68% okay. 10/1320 subtests failed, 99.24% okay. Not exactly success, but it's just the same failures I got before applying it. At least the IO stuff succeeded this time (imcc/t/syn/file.t fails because of shell issues). __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
Re: Release doc tasks
Re. obsolete docs: parrot_assembly.pod is a really old version of pdd06, and should probably just be dumped (the last patch to it was 16 months ago, the last non-trivial patch about 2 years ago) embed.pod should probably be reworked as a proper PDD (since pdd10_embedding.pod is empty right now) pdd12_assembly.pod -- what was the intent of this? (i.e. is there stuff that isn't covered in pdd06_pasm.pod that should go in here, or can we just dump this and recycle the number?) Simon
Re: [PATCH] IO fixes for Win32
At 11:57 AM 2/19/2004 -0800, Goplat wrote: Failed Test Stat Wstat Total Fail Failed List of Failed imcc/t/syn/file.t1 256121 8.33% 11 t/pmc/env.t 3 768 63 50.00% 3 5-6 t/pmc/perlarray.t1 256261 3.85% 26 t/pmc/sub.t 3 768493 6.12% 36-38 t/pmc/tqueue.t 2 512 52 40.00% 2-3 2 tests and 69 subtests skipped. Failed 5/94 test scripts, 94.68% okay. 10/1320 subtests failed, 99.24% okay. Not exactly success, but it's just the same failures I got before applying it. At least the IO stuff succeeded this time (imcc/t/syn/file.t fails because of shell issues). Works for me, applied, thanks. -Melvin
Re: Objects: Now or forever (well, for a while) hold your peace
On Thu, 19 Feb 2004, Dan Sugalski wrote: I tried to unify attributes and properties--I really did. The problem is that they're horribly semantically different. Attributes are class private and guaranteed across all objects of a class, while properties are ad hoc and can be thrown on anything. Python attributes, since they're really done per-object, correspond to our properties. I don't want to force things to be one or the other, because then you'd be in the unpleasant position of not being able to add pythonic attributes to a non-python object. Hey Dan, Thanks for taking the time to respond. What you're doing makes a lot more sense now. Not being able to do both would definitely suck. So keeping them separate solves that problem. However, I think there's an alternate solution that would work for both of us. First of all, in recent versions of python you CAN create classes that have fixed slots: class Fixed(object): __slots__=[foo] An instance of this class will demonstrate the problem you're worried about: f = Fixed() f.foo = 5 # no problem f.bar = 6 # big trouble Traceback (most recent call last): File stdin, line 1, in ? AttributeError: 'Fixed' object has no attribute 'bar' But that's EXACTLY what SHOULD happen if I try to set .bar on one of these objects, or on any java/perl6/ruby/whatever instance that doesn't have a .bar slot. However, in rare cases I might just need to do stick something extra on that object. If you don't mind a LITTLE kool-ade, you can use the Decorator design pattern to solve this without having to change the class at all: class PropDecorator(object): This class lets you add properties to something that wouldn't normally allow it. def __init__(self, other): super(PropDecorator, self).__setattr__(other, other) def __getattr__(self, name): try: return super(PropDecorator, self).__getattr__(name) except AttributeError: return getattr(self.other, name) def __setattr__(self, name, value): try: setattr(self.other, name, value) except AttributeError: super(PropDecorator, self).__setattr__(name, value) Now you have it both ways: p = PropDecorator(f) assert p.foo == 5 p.foo = 2 assert p.foo == 2 assert f.foo == 2 p.bar = 6 assert p.bar == 6 The nice thing about this is that you only have to incur the overhead of checking both attributes and properties when you're actually dealing with both. The compiler doesn't have to emit anything to check... It just emits getprop, and the PMC does the right thing. Unfortunately the semantics of the two systems don't have any overlap, at least no overlap that I can tease out. To me, the semantics are exactly the same. I have a thing, and I want to record some information about it. Now some types of things might have their own ideas about what I can know about them, and that's cool. Just because I have a box doesn't mean I get to open it. I suppose python code could see all properties and all attributes as fully-qualified names, with anything new going into the property list, but that's kinda nasty too. Plus there's the issue of python code easily seeing attributes that, arguably, it ought not see since they're supposed to be mostly class-private. This is definitely something to think about. The python attitude is like perl 5's... You can do whatever you want with an object. But just because you CAN, doesn't mean you SHOULD. To me, privacy rules are like the law of the land. An American object can't legally smoke marijuana... But if you send it over to Amsterdam, then it's okay. :) I think it should be the compiler's job to enforce the correct access privileges. But in any case, this problem exists regardless of whether you call the opcode setprop or setattr... I'm tempted to punt this one to Guido for his opinion. For callmeth, callmethcc, and tailcallmeth... I can understand the versions with the string... It looks up the method off of the PMC in P2, right? But what good is the version without the string? One of the string registers is the name of the sub or method being called. The no-string version is supposed to use that. I need to document that better. I also need to add in the redispatch ops, which I forgot. Right. I understood that's what you meant. I'm just saying that that's equivalent to invoke. So what good is it? :) It's nice to have something that finds the right method, but since the same work has to be done (move the object into P2, find the method, invoke it)... Why not leave the syntactic sugar up to imcc? Again, I'm wary of the separate interface for object stuff. Well... on the one hand I agree, on the other, method and sub dispatch really are very different things. (That might just be the dislike of the OO
Re: [NEW] library/sdl.imc
Chromatic [EMAIL PROTECTED] wrote: Me too. There's supposed to be a magic initialization sub of some kind called on library load. I'm inclined to stick it in there, but it's not there yet. I'll have a look at that _init call tomorrow - albeit _init (it was that name IIRC) could be a too commonly used label. _library_init or such could be better. One downside of making sdl.imc smarter (changing it from sdl.pasm) is that we can no longer use build_tools/build_nativecall.pl as is. That may be an argument for making the tool smarter. Why? -- c leo
Re: [NEW] library/sdl.imc
Hi, Am Donnerstag, 19. Februar 2004 05:54 schrieb chromatic: On Fri, 2004-02-13 at 09:57, Jens Rieks wrote: here is an easy to use (with PIR code) wrapper of the SDL library. It tries to hide all internals of the wrapper and makes the most important SDL functions directly available in PIR code. Overall this looks good. I am not sure if it is better to define flags as constants or to do something like this: I tried to make a 1:1 mapping of the SDL C functions to PIR subs, the arguments are by intention the same as in there C counterparts. .sym pmc flags new flags, .PerlHash set flags['double_buffered'], 1 set flags['full_screen'], 1 .sym pmc screen screen = _SDL_SetVideoMode( 320, 200, 0, flags ) Then only _SDL_SetVideoMode has to care about the flags. It is an idea anyway. Another idea is to pass similar arguments into _SDL_init_flags() and receive back an integer. I prefer to hide that in _SDL_SetVideoMode() though. A high(er) level API should IMHO use other names, just SetVideoMode for example. It would be confusing is someone knows the C functions and then has to figure out the the function names are equal, but that the parameters are different. -- c jens
Parrot day at the Austrian Perl Workshop
Hi!
At the Austrian Perl Workshop (see Call for Papers / Participation further
down) there will be a day devoted to Parrot.
Leo Toetsch will do a tutorial (in english or german, depending on the
number of non-german speeking attendees). The tutorial will be followed by a
hopefully productive hacking session.
So if you're interested in some f2f Parrot stuff, visit us in Vienna!
And if you're also interested in general Perl issues, or even want to do a
talk on one topic or the other, even better!
Call for Papers / Participation
***
From 20th to 22th May 2004 vienna.pm presents the first Austrian Perl
Workshop.
The workshop offers Perl users of all experiences (from newbie to
pumpking):
* the opertunity to learn, teach and chat.
* contact to Austrian and international Perl developers.
* insights in methods and practices of other programmers.
* interesting, amusing and instructive talks.
* a few nice days in the centre of Vienna.
* and all the other amenities of real-live meetings.
Programme / Topics
**
The programm is still work in progress. But we've got this topics:
20.5.: Perl Culture - The Culture of Perl
Perl employed in cultural projects, Perl culture, obfuscations,
generative art, ..
21.5.: Perl in daily use
Diverse applications from small to large, CPAN modules, etc.
22.5.: Parrot / Perl6
Leo Toetsch is giving a Parrot Tutorial, to be followed by general
hacking!
A provisional registration from is available here:
http://vienna.pm.org/en_ws_anmelden.html
Talks
*
In order to have a workshop at all, we need talks. A talk should be
between 5 and 60 minutes long, and preferably cover one of the
workshop's topics. Presentations about non-professional topics are
interesting and desired, too, so don't be shy
Send talk ideas either to domm AT zsi.at or use the form provided
under
http://vienna.pm.org/en_ws_talk.html
until 31. March 2004. The more the merrier.!
If possible (i.e. Sponsors) there will be a speakers' dinner.
Presentations may be in German or English.
Further information
***
You can find further information on this website:
http://vienna.pm.org/en_workshop.html
There is a mailing list: to subscribe, send a mail to
[EMAIL PROTECTED] with the subject 'subscribe'.
The workshop takes place at quartier21 (Freiraum) in the
MuseumsQuartier Wien:
http://quartier21.mqw.at/
Leo Toetsch (the parrot patchmonster) donates a signed copy of Perl6
Essentials to the person comming from furthest away.
In cooperation with Linuxwochen:
http://www.linuxwochen.at
The workshop takes place as part of the Coded Culture Congress:
http://5uper.net
See you!
Thomas Klausner
vienna.pm
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Release doc tasks
On 19 Feb 2004, at 20:59, Simon Glover wrote: pdd12_assembly.pod -- what was the intent of this? (i.e. is there stuff that isn't covered in pdd06_pasm.pod that should go in here, or can we just dump this and recycle the number?) Yes it should go. It's just an earlier version of pdd06. I'm almost done with the PMCs, though what I'm doing is fairly minimal. I've had to take a sort of head-down approach to working on the docs. Building inline stuff up to a certain level, before moving on to integration and coherence (will not be for this release). What I do hope to achieve for the Extra Day release is to get hyperlinks working for the html docs. I'll work on that this weekend. Once that's done I'll join in the get-it-up-to-date frenzy. One thing that would help is if people ran perl tools/docs/write_docs.pl -d -s on various platforms and told me if it works - or what they did to make it work - because I only have access to Mac OS X 10.3.2 here. Run it after running make, because it will die looking for docs/packfile-c.pod otherwise. BTW on a personal note, my CFT expires on the 1st May - back to a job in London - so in my head that's deadline I'm working towards. I want to have a decent documentation system set up by then. Mike
Re: Release doc tasks
On Thu, 2004-02-19 at 16:34, Michael Scott wrote:
One thing that would help is if people ran
perl tools/docs/write_docs.pl -d -s
on various platforms and told me if it works - or what they did to make
it work - because I only have access to Mac OS X 10.3.2 here.
It choked here on Linux with Failed to process lib/Parrot/Pmc.pm.
teasingModern filesystems understand both upper and lower
case./teasing
With the applied patch, there's only one warning:
Use of uninitialized value in substitution (s///) at
lib/Pod/Simple/HTML.pm line 344.
-- c
Index: lib/Parrot/Docs/Section/Perl.pm
===
RCS file: /cvs/public/parrot/lib/Parrot/Docs/Section/Perl.pm,v
retrieving revision 1.1
diff -u -u -r1.1 Perl.pm
--- lib/Parrot/Docs/Section/Perl.pm 6 Feb 2004 22:53:24 - 1.1
+++ lib/Parrot/Docs/Section/Perl.pm 20 Feb 2004 00:57:24 -
@@ -50,7 +50,7 @@
$self-item('', 'lib/Parrot/String.pm'),
),
$self-group('PMCs', '',
- $self-item('', 'lib/Parrot/Pmc.pm'),
+ $self-item('', 'lib/Parrot/PMC.pm'),
$self-item('', 'lib/Parrot/Pmc2c.pm'),
$self-item('', 'lib/Parrot/Vtable.pm'),
),
PDD status
PDD 0 (intro. to PDDs): Very, very out of date; I think it actually pre-dates Parrot PDD 1 (overview of Parrot): Not obviously out-of-date, but could use some text on IMCC and on the JIT PDD 2 (vtable functions): Needs documentation on freeze, thaw and share from somebody who actually understands what they do. We also need to figure out which of the functions described in it are simply waiting to be implemented and which are never going to be implemented PDD 4 (datatypes): The bigint/bignum stuff is completely out-of-date. We also need to figure out if there are any other internal datatypes that we should be documenting. PDD 5 (opfuncs): Very, very out-of-date. Needs a significant rewrite. PDD 6 (PASM): Missing a lot of ops. Also includes some ops that don't exist. (An easy task for the interested would be to put together a list of each). PDD 7 (coding standards): OK, as far as I know. PDD 8 (keys): This is quite old, so we need to check if it accurately describes the current system. PDD 9 (GC): Doesn't discuss any of the recent changes, such as the early DOD stuff PDD 10 (embedding): Empty. (Although we do have embed.pod) PDD 11 (extending): Empty. (But see extend.pod) PDD 12 (assembly): Empty and obsolete. PDD 13 (bytecode): Empty. (But see parrotbyte.pod) PDD 14 (bignums): Bignums are unimplemented, so all of this may change in the future. PDD 3 (calling conventions): PDD 15 (objects): Dan's handling these. PDD 16 (NCI): Needs looking over by somebody who understands the NCI system.
Error during CVS checkout (at docs/resources/)
When I tried to checkout parrot from CVS today, I've got the following error over docs/resources/up.gif docs/resources/parrot.small.png cvs checkout: invalid RCS expansion flags Valid flags are one of: tText file (default) bBinary file (merges not allowed). uUnicode (UCS-2) file. Followed by any of: kSubstitute keyword. vSubstiture value. lGenerate lockers name. oDon't change keywords. LGenerate Unix line endings on checkout. (Specify the --help global option for a list of other help options) cvs server: internal error: unsupported substitution string -kCOPY Should I upgrade my CVS client or is there something wrong with these files? (Currently using WinCVS 1.3.13.1, cvs 1-10.) Adriano. -- Adriano R. Ferreira Oasis Comunicacao e Tecnologia Ltda.
Re: [NEW] library/sdl.imc
Hi, Am Donnerstag, 19. Februar 2004 23:39 schrieb Leopold Toetsch: Chromatic [EMAIL PROTECTED] wrote: Me too. There's supposed to be a magic initialization sub of some kind called on library load. I'm inclined to stick it in there, but it's not there yet. I'll have a look at that _init call tomorrow - albeit _init (it was that name IIRC) could be a too commonly used label. _library_init or such could be better. That sounds reasonable. _library_unload might also be practical. One downside of making sdl.imc smarter (changing it from sdl.pasm) is that we can no longer use build_tools/build_nativecall.pl as is. That may be an argument for making the tool smarter. Why? Sorry if its a stupid question, but what has build_tools/build_nativecall.pl todo with sdl.pasm? I have to admin that I only have touched the NCI stuff cursorily. Has anyone tested parrot/sdl on Windows? As far as I kown, SDL needs some DirectX init calls on Windows, which is normally done in SDL's own main function; SDL_main.h contains some information about that. -- c leo jens
Re: [PATCH] library/sdl_types.imc #2
Hi, Am Donnerstag, 19. Februar 2004 05:45 schrieb chromatic: On Fri, 2004-02-13 at 09:21, Jens Rieks wrote: This patch fixes _SDL_WaitEvent a bit; SDL_WaitEvent returns an integer and not a SDL_Event. It also introduces _SDL_PollEvent which is mostly a copy of _SDL_WaitEvent. Finally, _SDL_loop is modified to allow an idle event entry that gets called if no events are pending. If such an event is defined, _SDL_PollEvent is used to check whether events are pending. The idle callback is made every 50ms, timer callback might be a better name. Thanks, applied with a few tweaks. Their is a branch _poll missing after the _idle block. Without it, _SDL_WaitEvent is called after the first idle call. A patch is attached. We can figure out a slightly nicer interface as we start to use it in real PIR programs -- and from higher level languages. It is also necessary to add code for SDL_PollEvent to library/sdl.pasm. Done. I propose to rename this file to sdl_init.pasm; I'am working on a sdl.imc file that makes it much easier to use SDL with PIR, because it hides much of the 'internals'. I will send the file to the list in a few minutes (the documentation if not yet sufficient at the moment). I'm not sure of the best way to organize these. Maybe we should wait until object support improves. On the other hand, I would like to see how Perl 6 or Pirate would call these libraries before commiting one way or the other. -- c jens Index: sdl_types.imc === RCS file: /cvs/public/parrot/library/sdl_types.imc,v retrieving revision 1.7 diff -u -w -r1.7 sdl_types.imc --- sdl_types.imc 19 Feb 2004 04:42:02 - 1.7 +++ sdl_types.imc 20 Feb 2004 01:35:15 - @@ -441,6 +441,7 @@ time nexttime add nexttime, 0.05 + branch _poll _wait: event = _SDL_WaitEvent()
Parrot Tetris with SDL bindings
Hi all, here is a first alpha version of my upcoming tetris example for parrot. It is a good demonstration that parrot is already very powerful. It uses a semi-object orientated style, I will modify it to use parrot objects as soon as they are working. Just unpack the attached tgz file into you parrot root, it contains the following files: tetris.pbc - hopefully an instant tetris ;-) examples/sdl/tetris.imc examples/sdl/tetris/app.imc examples/sdl/tetris/block.imc examples/sdl/tetris/blockdata.imc examples/sdl/tetris/board.imc examples/sdl/tetris/boarddata.imc examples/sdl/tetris/debug.imc examples/sdl/tetris/keyboard.imc examples/sdl/tetris/misc.imc You need the latest CVS version of parrot, as well as the outstanding patches for: library/sdl_types.imc and library/sdl.imc Assembling the sources to a single tetris.pasm seems to not work, parrot tetris.pasm then quits with error:imcc:Label '@pcc_sub_call_86' already defined in file 'tetris.pasm' line 1330 Am I doing something wrong, or is it a bug? back to tetris: It is playable, you can use you left/right keys to move the block, up/down rotates it. Pressing space will let the block fall down fast (not yet animated). Q and escape quits the game, N starts a new game. some other remarks: - the 1 - 7 keys select a specific block (debug aid), - rotating a block near the left and right border is still a bit buggy - I started to implement a draw optimisation, but its disabled at the moment; everything is redrawn every frame which consumes more CPU time than necessary. - there is no end of game detection yet Comments welcome :-) Have fun, jens tetris.tgz Description: application/tgz
Re: Parrot Tetris with SDL bindings
At 04:07 AM 2/20/2004 +0100, Jens Rieks wrote: Hi all, here is a first alpha version of my upcoming tetris example for parrot. It is a good demonstration that parrot is already very powerful. Very cool. Great work. Assembling the sources to a single tetris.pasm seems to not work, parrot tetris.pasm then quits with error:imcc:Label '@pcc_sub_call_86' already defined in file 'tetris.pasm' line 1330 Am I doing something wrong, or is it a bug? imcc incorrectly uses line numbers to generate labels. Try this and see if it fixes your problem (its a temporary hack, it will cause incorrect line number error reporting, but should give you unique labels throughout). -Melvin Index: imcc.l === RCS file: /cvs/public/parrot/imcc/imcc.l,v retrieving revision 1.84 diff -u -r1.84 imcc.l --- imcc.l 9 Jan 2004 08:53:07 - 1.84 +++ imcc.l 20 Feb 2004 04:43:20 - @@ -797,7 +797,7 @@ frames = frame; /* XXX: Switch the filename */ -line = 1; +/*line = 1;*/ yy_switch_to_buffer(yy_create_buffer(file, YY_BUF_SIZE)); }
util/ncidev2pasm.pl
On Thu, 2004-02-19 at 17:54, Jens Rieks wrote: One downside of making sdl.imc smarter (changing it from sdl.pasm) is that we can no longer use build_tools/build_nativecall.pl as is. That may be an argument for making the tool smarter. Why? Sorry if its a stupid question, but what has build_tools/build_nativecall.pl todo with sdl.pasm? I have to admin that I only have touched the NCI stuff cursorily. Oops, I meant util/ncidef2pasm.pl. The easiest way to build up a set of NCI calls is to write a declarations file and process it with util/ncidef2pasm.pl. The original SDL declarations file was: [package] SDL [lib] libSDL.so [defs] # from SDL.h i SDL_Init i p SDL_SetVideoMode iiil v SDL_Quit i SDL_FillRect ppl v SDL_UpdateRect p Run that through the tool and it spits out several lines of pasm. It's not hard to write that code by hand, but it's a little tedious. Of course, with various patches and plans, I've been updating it by hand. Maybe it's worth updating to spit out PIR. Maybe not. I've attached a patch that makes it a little bit smarter about register saving though. -- c Index: util/ncidef2pasm.pl === RCS file: /cvs/public/parrot/util/ncidef2pasm.pl,v retrieving revision 1.1 diff -u -u -r1.1 ncidef2pasm.pl --- util/ncidef2pasm.pl 23 Sep 2003 14:42:18 - 1.1 +++ util/ncidef2pasm.pl 20 Feb 2004 03:44:31 - @@ -152,8 +152,8 @@ open INPUT, $from_file or die Can't open up $from_file, error $!; open OUTPUT, $to_file or die Can't open up $to_file, error $!; -# To start, save all the registers, just in case -print OUTPUT saveall\n; +# To start, save the two registers we use, just in case +print OUTPUT save P1\nsave P2\n; my @libs; @@ -187,7 +187,7 @@ } # Put the registers back and end -print OUTPUT restoreall\n; +print OUTPUT restore P1\nrestore P2\n; print OUTPUT end\n; close OUTPUT;
