Re: Alignment Issues with *ManagedStruct?
Chromatic [EMAIL PROTECTED] wrote: set layout['member'], .DATATYPE_INT push layout, 0 push layout, 0 Pushing zero as offset should do The Right Thing, that is proper aligning the item. Tighter packed structures can be achieved with explicit offset parameters. Its basically an one-liner in unmanagedstruct.pmc:205 if (offs == 0 toff % data_size) advance (offs, toff) to data_size alignment Is this one for the TODO list, or did I catch a pumpking in good humours? Takers wanted :) -- c leo
Re: [perl #25948] IMCC doesn't trace lifetimes properly
Dan Sugalski [EMAIL PROTECTED] wrote: the following code trips up IMCC's temp lifetime tracing: Fix committed. leo
Re: Some minor decisions and timetables
On Tue, Feb 03, 2004 at 09:27:31PM +, Harry Jackson wrote: Dan Sugalski wrote: *) I'll try and patch up the docs, and I'll concentrate on the PDDs, but any help on them is greatly appreciated. *Especially* IMCC docs. Do we need an NCI section in the IMCC.faq. If the vote is yes I do not mind knocking something up. I'd vote yes! Thanks. Tim.
[perl #25960] [PATCH] COWed stack bug (was IMCC - PerlArray getting trounced)
# New Ticket Created by Matt Fowles
# Please include the string: [perl #25960]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=25960
All~
This patch make the problem case submitted by Jeff Clites work. All
tests pass, and his sample has been added to the tests.
While I am not certain that this is the correct way to solve the
problem, it seems good to me.
Matt
Index: imcc/t/syn/pcc.t
===
RCS file: /cvs/public/parrot/imcc/t/syn/pcc.t,v
retrieving revision 1.31
diff -u -r1.31 pcc.t
--- imcc/t/syn/pcc.t 20 Jan 2004 01:50:47 - 1.31
+++ imcc/t/syn/pcc.t 4 Feb 2004 02:55:11 -
@@ -1,6 +1,6 @@
#!perl
use strict;
-use TestCompiler tests = 34;
+use TestCompiler tests = 35;
##
# Parrot Calling Conventions
@@ -1389,3 +1389,30 @@
42.00
OUT
}
+
+output_is('CODE', 'OUT', COW handling on register stacks);
+.pcc_sub _main prototyped
+ $P1 = new PerlUndef
+ print $P1
+ print :
+ _outer()
+ print $P1
+ print \n
+ end
+.end
+.pcc_sub _outer prototyped
+ _inner()
+ .pcc_begin_return
+ .pcc_end_return
+.end
+.pcc_sub _inner prototyped
+ newsub $P1, .Exception_Handler, _ignore
+ .pcc_begin_return
+ .pcc_end_return
+.end
+.sub _ignore
+ noop
+.end
+CODE
+:
+OUT
Index: src/register.c
===
RCS file: /cvs/public/parrot/src/register.c,v
retrieving revision 1.41
diff -u -r1.41 register.c
--- src/register.c 25 Jan 2004 19:33:27 - 1.41
+++ src/register.c 4 Feb 2004 02:55:13 -
@@ -292,11 +292,11 @@
{
struct RegisterChunkBuf* top = stack-top;
if (top-used 1) {
+top-used--;
/* Before we change anything, is this a read-only stack? */
if (PObj_COW_TEST((PObj*)top))
top = stack-top =
regstack_copy_chunk(interpreter, stack-top, stack);
-top-used--;
}
else {
/* XXX: If this isn't marked COW, we should keep it around to
Parrot Embedding Questions
Hi, I would like to add Parrot as a scripting engine for a software project. Embedding it is no problem, but I was wondering if the current implementation supports the embedder to provide functions to the Parrot bytecode applications? The idea is that I would like to access C functions the embedder provides in Perl(5/6) or any other language that will become Parrot bytecode. Is that possible in the present state or will something like that be implemented in the future? Looking at the way Parrot works it doesn't seem possible, but I might have missed something. Thanks in advance. -- Mattias Nordstrom Partner, Systems Design Realnode Ltd [EMAIL PROTECTED] http://www.realnode.com/
Re: OO inheritance in a hacker style
Joseph Ryan writes:
It's surely possible by modifying that class's DISPATCH.
Whether it should actually be in the language is up for debate. I'd say
that if you need to do this with any frequency whatsoever, you're not
thinking about roles right. A good example might be in order... :-)
Well, what if the two classes you want to inherit from weren't
designed with roles in mind? For instance, there might be two
CPAN modules that each have a dozen methods that you want to
inherit, but they each have 1 that overlap whose conflict you
want to easily resolve.
Cforget doesn't help you there. That would presumably forget Iboth
methods, leaving you with none. That doesn't sound too useful. If you
could add a SomeClass:: on the front of the method, like:
class Foo is Bar is Baz {
forget Bar::frobnicate;
}
That looks backwards. It would certainly make more sense to specify
which method you want to use, as opposed to specifying all the methods
but the one you want to use.
A syntax that is the opposite of forget -- one that lets you specify
which method to use without typing that parameter list twice -- might be
useful, but it's trivial enough to, er, forget for now. I wonder
whether it's possible to say:
class Foo is Bar is Baz {
method frobnicate := Baz::frobnicate;
}
I know my syntax there isn't right quite. :-)
Besides, the user is not thinking about XXX right sounds like we
need to give a ++ to the pythonometer ;)
Let's say someone came on here and asked how to use regexes to make a
socket connection. Surely the user is not thinking about regexes
right... or sockets.
Luke
Re: [perl #25960] [PATCH] COWed stack bug (was IMCC - PerlArray getting trounced)
Matt Fowles [EMAIL PROTECTED] wrote:
This patch make the problem case submitted by Jeff Clites work. All
tests pass, and his sample has been added to the tests.
struct RegisterChunkBuf* top = stack-top;
if (top-used 1) {
+top-used--;
Thanks for the patch *but*:
That's changing the COWed copy. It does the right thing for the test
case but is still wrong.
As already stated:
- COWed buffers need distinct buffer headers pointing to the same
buffer memory
- unCOWing (regstack_copy_chunk) allocates new buffer memory and
resets the COW flag
Its like string.c: make_COW_reference() and unmake_COW()
This is needed for the register stacks and for stacks.c too.
leo
Re: Some minor decisions and timetables
Dan Sugalski [EMAIL PROTECTED] wrote: Okay, here's a quick scoop and status. *) I'd like to shoot for a Feb 14th release. Names wanted. (I'm partial to the bleeding heart release, but not that partial) I had planned towards Feb 29th. A nice dated too this year. *) Namespaces are going to use the: find_global Px, [key; key; key], final_name_string format. I may add in a dummy: find_global Px, Pn[key], final_name in the mean time just to make things work out. Pn will get ignored. If you have the key and leave out the element, it returns a PMC that represents that piece of the namespace. Yes, I know there are objections, but it's a matter of taste and space savings. We'll cope. I'd add some syntax additions and some notes: - Pn above is a NameSpace PMC, derived from Hash - an interpreter has a current namespace - located in the context, so that its restored after sub calls getinterp P2 find_global Pn, P2[.] # get current NS find_global Pz, P2[..] # get parent NS set Pz, Pn[..] # same find_global Py, P2[/] # get root of namespaces find_global Px, Pn[Foo; Bar] # NS of Module Foo::Bar find_global Pv, Pn[Foo; Bar], baz # $Foo::Bar::baz var find_global Pv, Pn[Foo; Bar; baz ] # same set P2[.], Px # switch current NS to Foo::Bar find_global Pv, Pn[/; java; some; glob ] # /java.some.glob *) Just constant keys for names right now. We'll work on dynamic keys later, if we don't already have 'em in. Dynamic keys are (still) working ;) *) I like Tim's namespace idea (prepending the language) and we'll put that in, though probably for the next release. That's not really difficult, if the namespace PMC handles above directory-like traversal keys. leo
Re: Some minor decisions and timetables
Leopold Toetsch writes: I'd add some syntax additions and some notes: - Pn above is a NameSpace PMC, derived from Hash - an interpreter has a current namespace - located in the context, so that its restored after sub calls getinterp P2 find_global Pn, P2[.] # get current NS find_global Pz, P2[..] # get parent NS set Pz, Pn[..] # same find_global Py, P2[/] # get root of namespaces find_global Px, Pn[Foo; Bar] # NS of Module Foo::Bar find_global Pv, Pn[Foo; Bar], baz # $Foo::Bar::baz var find_global Pv, Pn[Foo; Bar; baz ] # same set P2[.], Px # switch current NS to Foo::Bar find_global Pv, Pn[/; java; some; glob ] # /java.some.glob Me gusta mucho! This system allows neato things like anonymous namespaces, too. I was thinking of something similar for classes. An object holds a reference to a class PMC which is used to fetch its methods. This allows different metaclasses (which are, again, required for Perl 6[1]). Maybe said class PMC is, by default, just an anonymous namespace PMC. Luke
crash in HEAD
Hey,
The following PIR crashes CVS head:
.sub _main
$P0 = new PerlUndef
.sym PerlUndef i
i = new PerlUndef
i = 0
L0:
$I0 = 0
$P1 = new PerlUndef
$P1 = 10
unless i $P1 goto L3
$I0 = 1
L3:
if $I0 goto L1
goto L2
L1:
print hello\n
$P0 = i
i = i + 1
goto L0
L2:
.end
Which is the php code generation of a for loop:
for ($i = 0; $i 10; $i++) {
echo hello\n;
}
This has previously worked - do any changes need to be applied to the
code in order to have it working again? Is this just a current parrot
bug?
(doesn't matter if you run this with the slowcore or the jit btw)
-Sterling
--
Reductionists like to take things apart. The rest of us are
just trying to get it together.
- Larry Wall, Programming Perl, 3rd Edition
Re: RT Cleanup
On Feb-02, Andrew Dougherty wrote: [EMAIL PROTECTED] 19184 languages/perl6/t/rx/call test error 1 years Keep this one open. The tests still fail. How recently did you check? I committed a reimplementation of perl6 regexes about a week ago. The above test still failed, but only due to a parrot memory corruption bug, and I committed something else the next day that coincidentally sidestepped the bug on my machine. I would find it easy to believe that it is still happening on other machines. Could you give it a try and let me know? All perl6 tests should be passing right now.
Re: OO inheritance in a hacker style
On Wed, Feb 04, 2004 at 01:30:44AM -0500, Joseph Ryan wrote:
Whether it should actually be in the language is up for debate. I'd say
that if you need to do this with any frequency whatsoever, you're not
thinking about roles right. A good example might be in order... :-)
Well, what if the two classes you want to inherit from weren't
designed with roles in mind? For instance, there might be two
CPAN modules that each have a dozen methods that you want to
inherit, but they each have 1 that overlap whose conflict you
want to easily resolve.
Same way you do it now.
package Foo;
use base qw(This That);
sub conflicting_inherited_method {
goto {That-can(conflicting_inherited_method)};
}
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
Cheating is often more efficient.
- Seven of Nine
Re: Alignment Issues with *ManagedStruct?
On Wed, 2004-02-04 at 00:52, Leopold Toetsch wrote:
Pushing zero as offset should do The Right Thing, that is proper
aligning the item. Tighter packed structures can be achieved with
explicit offset parameters.
In this case, it doesn't, as the struct I'm emulating is:
typedef struct {
Uint8 type; /* SDL_KEYDOWN or SDL_KEYUP */
Uint8 which;/* The keyboard device index */
Uint8 state;/* SDL_PRESSED or SDL_RELEASED */
SDL_keysym keysym;
} SDL_KeyboardEvent;
SDL_keysym itself is a struct:
typedef struct {
Uint8 scancode; /* hardware specific */
SDLKey sym; /* SDL virtual keysym */
SDLMod mod; /* current key modifiers */
Uint16 unicode; /* translated character */
} SDL_keysym;
SDLKey and SDLMod are both enums.
As I understand it (and correct me if I'm wrong), SDL_keysym needs a
byte of padding on my architecture within SDL_KeyboardEvent. I can add
that padding manually, but I'm not convinced that'll be portable to
different architectures.
That's the kind of padding I'd like unmanagedstruct.pmc to be able to do
for me.
Is this one for the TODO list, or did I catch a pumpking in good
humours?
Takers wanted :)
I'm happy to submit this as a TODO if I have the story straight.
-- c
Re: RT Cleanup
On Wed, 4 Feb 2004, Steve Fink wrote: On Feb-02, Andrew Dougherty wrote: [EMAIL PROTECTED] 19184 languages/perl6/t/rx/call test error 1 years Keep this one open. The tests still fail. How recently did you check? I committed a reimplementation of perl6 regexes about a week ago. The above test still failed, but only due to a parrot memory corruption bug, and I committed something else the next day that coincidentally sidestepped the bug on my machine. It's probably a different bug than #19184, but here's what I just got for cd languages/perl6 make test (This is for perl5.00503, Solaris 8/SPARC, Sun Workshop compiler) Failed Test Status Wstat Total Fail Failed List of failed --- t/rx/basic.t 8 2048 88 100.00% 1-8 t/rx/call.t 2 512 22 100.00% 1-2 t/rx/special.t2 512 22 100.00% 1-2 All of the test failures look basically like this: t/rx/basic..Read on closed filehandle PASM at P6C/TestCompiler.pm line 71. Use of uninitialized value at ../../lib/Parrot/Test.pm line 87. # Failed test (t/rx/basic.t at line 7) # got: 'error:imcc:main: Error reading source file t/rx/basic_1.pasm. # ' # expected: 'ok 1 # ok 2 # ok 3 # ok 4 # ok 5 # ok 6 # ok 7 # ok 8 # ok 9 # ' Finally, is it just me, or do these tests take a long time for everyone? Today, it took 21 minutes to run the perl6 test suite. While I appreciate the value of a comprehensive test suite, I wonder if there might be some way to speed things up a bit (apart from buying a faster machine, of course!) -- Andy Dougherty [EMAIL PROTECTED]
Re: Alignment Issues with *ManagedStruct?
Chromatic [EMAIL PROTECTED] wrote:
In this case, it doesn't, as the struct I'm emulating is:
typedef struct {
Uint8 type; /* SDL_KEYDOWN or SDL_KEYUP */
Uint8 which;/* The keyboard device index */
Uint8 state;/* SDL_PRESSED or SDL_RELEASED */
SDL_keysym keysym;
} SDL_KeyboardEvent;
SDL_keysym itself is a struct:
typedef struct {
Uint8 scancode; /* hardware specific */
SDLKey sym; /* SDL virtual keysym */
SDLMod mod; /* current key modifiers */
Uint16 unicode; /* translated character */
} SDL_keysym;
SDLKey and SDLMod are both enums.
As I understand it (and correct me if I'm wrong), SDL_keysym needs a
byte of padding on my architecture within SDL_KeyboardEvent.
Brr. I don't know. I've to ask my debugger for that :) If you have
SDL_keysym alone, that needs 3 bytes additional alignment. But don't ask
me about the combined structure.
But I'd say that there are four adjacent Uint8 taking one word, then is
another word (SDLkey sym). Or a structure starts aligned ...
We don't have a notion of nested structures. They could go just inline,
i.e. without extra syntax. Pointers to structures are of course missing
too, that's a different thingy.
I can add
that padding manually, but I'm not convinced that'll be portable to
different architectures.
Automatic alignment based on the data type sizes is for sure better.
-- c
leo
[CVS ci] new errors{on,off} opcodes
This ... .include errors.pasm errorsoff .PARROT_ERRORS_GLOBALS_FLAG find_global P1, no_such_global defined I0, P1 ... allows working around current exception handler (COW) bug and is more perlish then the default pie-thonish behavior, which is: just throw an exception (the default still). leo
Re: Alignment Issues with *ManagedStruct?
c == chromatic [EMAIL PROTECTED] writes:
c I ran this program in lieu of the debugger:
i recall an old trick i learned to get offsets into structs which would
be easier to read than hex addresses:
c int main ()
c {
c SDL_KeyboardEvent kbevent;
c printf( 0x%08X event\n, kbevent );
c printf( 0x%08X event.type\n, kbevent.type );
untested
printf( %d event.type\n, (char *)kbevent.type ) - (char *)kbevent ;
it can be made into a macro IIRC for ease of use.
that could be done with a perl script for any structure and it could
generate an offset map for the given environment. that map could be used
by parrot to access members in a portable way.
so the script would parse a structure, generate a set of those prints
(with the right format output) and compile it with the same tools as
parrot. run that little c program and save the output in a file. parrot
reads that file and uses it as a name to offset map for that structure.
want me to hack up this little script and c generation stuff? the hard
part is parsing the struct so i would have to assume some simple format
and not full c for the moment. the only thing needed by the parser is
all the member names.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: perl6-internals Re: RT Cleanup
Andrew Dougherty wrote: On Wed, 4 Feb 2004, Steve Fink wrote: On Feb-02, Andrew Dougherty wrote: [EMAIL PROTECTED] 19184 languages/perl6/t/rx/call test error 1 years Keep this one open. The tests still fail. How recently did you check? I committed a reimplementation of perl6 regexes about a week ago. The above test still failed, but only due to a parrot memory corruption bug, and I committed something else the next day that coincidentally sidestepped the bug on my machine. It's probably a different bug than #19184, but here's what I just got for cd languages/perl6 make test (This is for perl5.00503, Solaris 8/SPARC, Sun Workshop compiler) Try cd languages/perl6 ./perl6 --force-grammar -e 1 # don't worry if it fails make test Except I never do 'make test' because, as you noticed, it takes forever to run. Use ./perl6 --test instead. (Or, in this case, maybe just ./perl6 --test t/rx/*.t) The slowest part of the perl6 compiler is simply loading in the Parse::RecDescent parser. That line loads it in once and reuses it for all the tests. I think nobody ever changed 'make test' to use it because if one test kills the process, then all remaining tests fail too. But perhaps I should have make test print at the very end: Hey, that took forever, didn't it? Maybe you should try using ./perl6 --test instead, as documented in [I forget where, and can't look it up right now]. t/rx/basic..Read on closed filehandle PASM at P6C/TestCompiler.pm line 71. Use of uninitialized value at ../../lib/Parrot/Test.pm line 87. # Failed test (t/rx/basic.t at line 7) # got: 'error:imcc:main: Error reading source file t/rx/basic_1.pasm. # ' # expected: 'ok 1 # ok 2 # ok 3 # ok 4 # ok 5 # ok 6 # ok 7 # ok 8 # ok 9 # ' Odd... I'll take a look tonight, thanks. Finally, is it just me, or do these tests take a long time for everyone? Today, it took 21 minutes to run the perl6 test suite. While I appreciate the value of a comprehensive test suite, I wonder if there might be some way to speed things up a bit (apart from buying a faster machine, of course!) Oh, and the perl6 test suite is *far* from comprehensive. It's just slow.
[DOCS] Documentation tools
I've added the Perl modules for the docs tools to lib/Parrot/IO and lib/Parrot/Docs. I've also added Pod-Simple (2.05) and Pod-Escapes (1.03) which they use. Running perl tools/docs/write_docs.pl should build the html tree in docs/html. I'd be interested to know of any problems encountered. On the updating front, I finished examples and did the other *.c file directories (chartypes, encodings, io, pf, types). Now I think I'll look at classes. Mike
Re: [DOCS] Documentation tools
I've added the Perl modules for the docs tools to lib/Parrot/IO and lib/Parrot/Docs. I've also added Pod-Simple (2.05) and Pod-Escapes (1.03) which they use. I probably blinked.. but why are we including CPAN modules that we are not likely to change into the parrot repository? -R
