Re: Raising exceptions
Cory Spencer <[EMAIL PROTECTED]> wrote: > I've been hard pressed to find any examples of proper exception-raising > with Parrot t/pmc/exception.t > ... has this > been at least semi-completed? Yes. leo
Re: cvs commit: parrot/config/gen/makefiles root.in
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> Sorry, I guess I should have been more explicit. What folks apparently do
> is have the sources on an NFS server mounted read-only. They then build a
> symlink tree onto a local read-write filesystem and run the build there.
> Thus they can create all the new files they want, but they can't touch or
> change the source files.
That works except for the imc{parser,lexer} generated files. But we
could remove touching these files. When Configure.pl --maintainer was
run, you probably have the tools to create these files.
leo
Re: Segfault on Win32, The
Vladimir Lipsky <[EMAIL PROTECTED]> wrote: > From: "Leopold Toetsch" <[EMAIL PROTECTED]> > Sent: Monday, December 01, 2003 5:47 PM >>Which child interpreter? Parrot_destroy_vtable() is called after >>free_unused_pobjects(). > Well you know test 61 in t/pmc/pmc.t causes a segfault. Its pmc_62 labeled "PMC type check". And yes, it does double free the vtable. Fixed. leo
Re: [RfC] disable unused vtable entries
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> OTOH I'm thinking of adding _keyed_str variants to used _keyed vtables.
> We are already constructing too much temporary key PMCs from a string
> just to pass a string to an hash lookup. Object ops and functions do
> this all over the place repeatedly.
And here is a profile timing comparison for doing 1E6 findclass ops [1]:
CODE OP FULL NAMECALLS TOTAL TIME AVG T. ms
- --- -- --
743 findclass_i_sc1001.356876 0.0014
-3 DOD 10580.211712 0.2001
...
- --- -- --
1130010661.666512 0.0006
Doing the same with a direct hash_get() [2]:
1257 findclass_str_i_sc1000.462577 0.0005
...
- --- -- --
113090.564461 0.0002
This is 3 times faster and saves ~1000 DOD runs.
[1]
newclass P1, "Foo"
loadlib P2, "myops_ops"
set I0, 100
time N0
loop:
findclass I1, "Foo" # or findclass_str in myops.ops
dec I0
if I0, loop
time N1
sub N1, N0
print N1
print "\n"
end
unoptimized build, Athlon 800.
[2] Of course calling hash_get() directly isn't the way to go, but
VTABLE_exists_keyed_str() is just one vtable call slower, which isn't
much.
# from dynoplibs/myops.ops
# make -C dynoblibs clean all
inline op findclass_str(out INT, in STR) {
Hash *h = (Hash*)PMC_ptr1v(interpreter->class_hash);
if (hash_get(interpreter, h, $2)) {
$1 = 1;
} else {
$1 = 0;
}
goto NEXT();
}
leo
RE: Properties
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Hodges, Paul writes:
> >
> > sub setvals ($o, [EMAIL PROTECTED]) {
> > $o but= $_;
> > $o.$_ = true;
> > }
>
> Y'all seem to be missing a C somewhere :-)
>
> sub setvals ($o, [EMAIL PROTECTED]) {
> $o but= $_ for @t;
> }
LOL!!! I can't believe I missed that! =o)
You're obviously right, tho.
> I think that should work, as the right side of C should
> always be a property, so a property reference ought be interpreted
correctly.
>
> > One thing, though could I do this? >=o}
> >
> > my property (foo,bar,baz) ^is true;
> > $thingy ^but= (foo,baz);
>
> No, but you might be able to if you used proper vectorizing syntax ;-)
>
> my property (foo,bar,baz) is sometrait; # is automatically
distributes
> $thingy Âbut=Â (foo,baz);
Didn't know "is" would do that. Good to know!
And in my meager defense, I did reference MikeL's operator synopsis as of
3/25/03, which said ^[op] might be a synonym for <<>> or >><< (Sorry, no
fancy chars here. :)
> C doesn't seem like a trait you would put on a property. C
> is a run-time property, and I think it would be awfully confusing to
> make it a trait as well. If you're talking about some kind of
> initialization, you might use:
>
> my property (foo,bar,baz) is first(1);
>
> Or C might be correct if you're -- somehow -- deriving these
> properties from the C property. But I don't think that was the
> intent.
Was just initializing. Don't remember "is first(whatever)", though it seems
a bit familiar.
> > I'm pretty sure that syntax is way wonky -- would "is" be a
> > vectorizable operator? Does it even qualify as an operator at all?
>
> C is definitely an operator, much in the same way C is an
> operator. Whether it's vectorizable is questionable, because in all
> cases I've seen the vectorization is implicit. That is, if it has a
> non-vector meaning, the meaning of:
>
> my ($a,$b,$c) is foo;
>
> is a little fuzzy. What's C applying to if it's not
> applying to all of $a, $b, and $c?
I hadn't seen it done that way...at least not recently enough that I
remembered it.
Last I recall, someone was thinking it would be
my ($a is foo, $b is foo, $c is foo);
Which really sux. I'm glad that was cleaned up.
> > > > then write allow() to build roles for each value passed in,
> > > > maybe taking an arg to say whether they should be truly global,
> > > > or built in the caller's namespace
> > >
> > > Isn't that what my, our, Exporter, and the globalifying * are
> > > all about?
> >
> > Probably, though I haven't seen anything yet about how the
> > P6 version of the Exporter is going to handle things like specifying
> > exportation of my() vars &co.
>
> I'm pretty sure that the interface to Exporter can be cleaned
> up quite a bit in Perl 6. For now, though, I think it's fine to assume it
works
> exactly like Perl 5's.
Which is why I was building an allow(), which would let you specify property
names to create in the use() statement of the module. I have *NO* clue how
you would use the current Exporter to create roles on-the-fly, but I think I
could build something that would do its own exporting to whatever level it
was told. Maybe level 0 is make them but don't export, 1 is export them into
the calling namespace, and 2 is truly global:
use MyRoles export => 0, <>;
my $whatsit but= MyRoles.foodiddly; # above line made this acceptable
$whatsit.foodiddly = 1;
but could I instead say
my $whatsit but= MyRoles.foodiddly(1);
or something like that?
*
"The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers.61"
Re: 'Core' Language Philosophy
Michael Lazzaro <[EMAIL PROTECTED]> writes: > On Wednesday, November 26, 2003, at 12:29 PM, Larry Wall wrote: >> If you contrast it with an explicit try block, sure, it looks >> better. But >> that's not what I compare it with. I compare it with Perl 5's: >> >> $opus.write_to_file($file) or die "Couldn't write to $file: $!"; >> >> That has some known problems with false positives, er, negatives, >> which Perl 6 addresses with things like: >> >> $opus.write_to_file($file) err fail "Couldn't write to $file: $!"; >> >> But if we're going to talk about philosophy, we should talk about >> Perl's notion of not forcing people to escalate all the way to >> exceptions when a lesser form of undefinedness or falseness will do. >> Perl 6 doesn't back off from this. In fact, it takes it further >> by allowing you to return unthrown exceptions as "undef". And by >> providing a "fail" that either returns or throws the exception >> depending on the preferences of the caller. > > Well, yes, hmm, har, but... > > Speaking only for myself, my own (database-heavy) code already makes > pretty extensive use of the differences between "false", > "unknown/undefined/NULL", and "worthy of exception" -- all three of > those conditions may exist at various times, and no two of them can > reasonably be lumped together as being logically identical. So implement a *real* NULL instead of trying to force 'undef' somewhere it doesn't want to go.
>>OP<< [was: Re: Properties]
On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote: Didn't know "is" would do that. Good to know! And in my meager defense, I did reference MikeL's operator synopsis as of 3/25/03, which said ^[op] might be a synonym for <<>> or >><< (Sorry, no fancy chars here. :) Hey, that was *March*! ;-) The fossil records from that time are fragmentary, at best. I don't think I ever saw any further reference to the ^[op] syntax staying alive; I assume that means it's dead. Last I heard, which was admittedly around the same time frame, we'd have the non-Unicode-using >>op<<, and a Unicode synonym »op«, and that's it. There were also vaguely threatening proposals to have <> and >>op<< do slightly different things. I assume that is also dead, and that <> is (typically) a syntax error. If anyone in the know knows otherwise, plz verify for Piers' summary and the future fossil record. MikeL
Re: >>OP<< [was: Re: Properties]
Michael Lazzaro writes:
>
> On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
> >Didn't know "is" would do that. Good to know!
> >And in my meager defense, I did reference MikeL's operator synopsis as
> >of
> >3/25/03, which said ^[op] might be a synonym for <<>> or >><< (Sorry,
> >no
> >fancy chars here. :)
>
> Hey, that was *March*! ;-) The fossil records from that time are
> fragmentary, at best.
>
> I don't think I ever saw any further reference to the ^[op] syntax
> staying alive; I assume that means it's dead. Last I heard, which was
> admittedly around the same time frame, we'd have the non-Unicode-using
> >>op<<, and a Unicode synonym æopæ, and that's it.
>
> There were also vaguely threatening proposals to have <> and >>op<<
> do slightly different things. I assume that is also dead, and that
> <> is (typically) a syntax error.
Ack. No, slightly different things would be a very bad idea.
At the moment, as most of you probably know, they do *very* different
things. >>op<< vectorizes the operator, and <> is
equivalent to qw{some stuff}.
And as far as I know, << and >> are exactly equivalent to æ and æ in all
cases.
Luke
> If anyone in the know knows otherwise, plz verify for Piers' summary
> and the future fossil record.
>
> MikeL
>
Re: >>OP<< [was: Re: Properties]
Luke Palmer writes: > And as far as I know, << and >> are exactly equivalent to æ and æ in all > cases. By which I mean  and Â, of course. :-/ (mutt is kind of a pain in this area) Luke Ã
Re: [RfC] Fix assigned PMC enum_class_xxx
On Dec 1, 2003, at 9:01 PM, Melvin Smith wrote: At 10:40 AM 11/28/2003 +0100, Leopold Toetsch wrote: As outlined some time ago, when ops.num made it into the core, we need fix assigned PMC class enums too. (Changed class enums invalidate existing PBC files). 1) lib/Parrot/PMC.pm is the canonical source of PMC class => enum mapping. 2) the class enums should be numbered so that "base" classes come first and dependent classes later. 3) If we keep the current scheme for Const$class generation and switching, we have to use this numbering scheme: default ... implicitely #0 odd enums ... plain class even enums ... Const variant of class 4) Where config/* now have $pmc_names, %pmc_types is used. 5) Adding a new class starts with editing PMC.pm. If the current numbering can not be kept, PBC_COMPAT gets an entry too and thus invalidates existing PBCs. 6) The interactive step of selecting PMCs is IMHO unneeded. Its error prone, rarely used PMCs can be dynamically loaded. 7) We probably have to reserve some slots for Perl5-classes Comments welcome An additional thought. I feel there is no need to expose the enumerated values to user-code (bytecode or native methods). Looking up PMCs isn't really any different than looking up other symbols and could be fixed up at load time. This does away with any ordering or numeric range reservation issues. If I recall, Java stores class references as UTF encoded strings of the full path to the class [java/lang/foo] Yes, ObjC does something similar. At compile-time, class names in the code become references into a per-library lookup table (stored in a separate segment alongside the constant string segment), and that lookup table is filled in a library-load-time with a reference to the actual class object (or a unique int representing it). (This is roughly the approach, at least.) So 3 attractive options here for parrot for PMCs (and also for methods and classes) are (1) do the same thing, or (2) at compile-time represent PMC names as strings in the bytecode, and do a fixup run to replace these with ints (or whatever) at load time, or (3) have an op which does the lookup by name, and which morphs itself into an op which holds a direct reference, the first time it is called. To me, the 1 -> 2 -> 3 progression is very much like the evolution of predereferencing. JEff
Re: Why are .sub and compilation unit one and the same thing?
At 8:10 PM -0700 12/1/03, Cory Spencer wrote:
> However, if giving up IMCC's register allocator is worth gaining
the extra control of PASM, by all means do it, however I'm all ears
on suggestions for IMCC for features. *hint*
In that case, I don't suppose it would be possible for IMCC to allow
function calls in an "if expr goto LABEL" statement, ie:
...
if _some_test() goto LABEL
...
...
I for one would find that particularly useful. ;)
I'll veto that one. Much as I'd love it, along with compound
expressions ("1 + (3 * 5) / FOO" type things) and a few other things,
I think it's a bit past where an intermediate language should be
living.
Might be a good thing to put into cola. (hint, hint :)
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Object stuff
At 2:05 AM +0300 12/2/03, Vladimir Lipsky wrote: From: "Dan Sugalski" <[EMAIL PROTECTED]> Sent: Monday, December 01, 2003 9:53 PM *) I've made the Parrot_base_vtable array movable again, as it needs to be resized. This is a temporary hack, since there are horrible threading issues here. (Not to mention the fact that this table is global and really ought not be, or we need a per-interpreter-family version that's actually used) Is actually used? D'oh. I didn't notice that today. Yeah, in a number of places. It's where the interpreter fetches the PMC vtable when instantiating new PMCs of some particular type. The PMC number is the index into this table. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Some PIR "How do I?" questions
At 10:28 PM -0500 12/1/03, Melvin Smith wrote: 2) printf/sprintf - we do need it (and implemented in C) since it is a staple and is the reasonable hook for HLL implementors to do interpolation without having to write a special native method or PMC for each language. Okay, once I get the object stuff finished I think this is the next thing to tackle. The one question is whether we should make the lead-in character for sequences settable at runtime, as not all languages will want to use % for interpolation. (I am, however, perfectly fine with choosing something otherwise unused and forcing languages to translate from their exposed form to our internal form) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RfC] Fix assigned PMC enum_class_xxx
At 12:01 AM -0500 12/2/03, Melvin Smith wrote: At 10:40 AM 11/28/2003 +0100, Leopold Toetsch wrote: As outlined some time ago, when ops.num made it into the core, we need fix assigned PMC class enums too. (Changed class enums invalidate existing PBC files). 1) lib/Parrot/PMC.pm is the canonical source of PMC class => enum mapping. 2) the class enums should be numbered so that "base" classes come first and dependent classes later. 3) If we keep the current scheme for Const$class generation and switching, we have to use this numbering scheme: default ... implicitely #0 odd enums ... plain class even enums ... Const variant of class 4) Where config/* now have $pmc_names, %pmc_types is used. 5) Adding a new class starts with editing PMC.pm. If the current numbering can not be kept, PBC_COMPAT gets an entry too and thus invalidates existing PBCs. 6) The interactive step of selecting PMCs is IMHO unneeded. Its error prone, rarely used PMCs can be dynamically loaded. 7) We probably have to reserve some slots for Perl5-classes Comments welcome An additional thought. I feel there is no need to expose the enumerated values to user-code (bytecode or native methods). Looking up PMCs isn't really any different than looking up other symbols and could be fixed up at load time. Except... if we leave the PMC numbers in the bytecode it means one fewer level of indirection when instantiating base Parrot PMCs. The current scheme allows for two ways to instantiate a new PMC: 1) Via a direct integer constant, which is only valid for PMCs that were in the interpreter when it was built. (And should be usable only for core PMCs we guarantee to be available) 2) Via an integer register. The register can be filled in by looking up the type by name at runtime. I'd prefer to leave the scheme as is. I'm fine with leaving a small number of PMCs built in as "core" -- I'd be OK going so far as to say that the *only* PMCs available this way are ones that are required for Parrot to operate. (continuations, closures, pads, ordered hashes, and suchlike things) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: cvs commit: parrot/config/gen/makefiles root.in
At 10:32 AM +0100 12/2/03, Leopold Toetsch wrote:
Andy Dougherty <[EMAIL PROTECTED]> wrote:
Sorry, I guess I should have been more explicit. What folks apparently do
is have the sources on an NFS server mounted read-only. They then build a
symlink tree onto a local read-write filesystem and run the build there.
Thus they can create all the new files they want, but they can't touch or
change the source files.
That works except for the imc{parser,lexer} generated files. But we
could remove touching these files. When Configure.pl --maintainer was
run, you probably have the tools to create these files.
Woohoo, yay delegation! :)
Seriously, I think this is a fine idea (building entirely outside the
source tree, or using a symlink nest with all the base source files
read-only) and I expect we're going to get requests for it, so we
might as well handle it now.
I'm assuming that Andy's not got sufficient time to make this happen,
so if other folks are willing to step up that'd be great.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Segfault on Win32, The
At 1:52 AM +0300 12/2/03, Vladimir Lipsky wrote: I'm done with it for now and I'm not the dan to say which way is the parrot way to fix this bug Well, bah. I'll disable the table freeing for now and that should take care of the bug at the moment, though it certainly won't cure the underlying memory leak. Arguably, and this is getting into the realm of embedding, since this is something that's set up by the global initialization, it should stay in existence until the embedder calls the global destruction code, since it's possible (though I'm not sure we want to support it) that after destroying all the extant interpreters that the embedding program will want to create another one. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RfC] disable unused vtable entries
At 12:14 PM +0100 12/2/03, Leopold Toetsch wrote: Leopold Toetsch <[EMAIL PROTECTED]> wrote: OTOH I'm thinking of adding _keyed_str variants to used _keyed vtables. We are already constructing too much temporary key PMCs from a string just to pass a string to an hash lookup. Object ops and functions do this all over the place repeatedly. And here is a profile timing comparison for doing 1E6 findclass ops [1]: CODE OP FULL NAMECALLS TOTAL TIME AVG T. ms - --- -- -- 743 findclass_i_sc1001.356876 0.0014 -3 DOD 10580.211712 0.2001 ... - --- -- -- 1130010661.666512 0.0006 Doing the same with a direct hash_get() [2]: 1257 findclass_str_i_sc1000.462577 0.0005 ... - --- -- -- 113090.564461 0.0002 This is 3 times faster and saves ~1000 DOD runs. Wow. Okay. Go for it. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Objects!
Well, objects-ish, at least. Single-inheritance objects seem to be done. The code can use a lot of abuse and cleanup, and we need actual tests to make sure that it functions as it should, but they're in. Here's the technical scoop. When you create a ParrotClass-based class (which is to say, you use the class creation ops that we provide) you get a class PMC that's got all the class information hanging off it. This stuff's documented at the top of classes/parrotclass.pmc though better docs are definitely in order. Since creating the class is handled by the code in objects.c rather than in the class vtable, we get to play a number of games: Games we play: == *) The class code knows its dealing with parrot classes (there's a flag to tell us) and it cheats. Not too badly, but some. Probably should cheat more, but I'm up for getting it working before doing Horribly Evil Things. *) Creating new objects involves calling the ->init vtable entry *on the class*. Because of this each class gets a custom vtable where the init method has been swapped out for one (from objects.c) that creates a new object instead. But it seems to work out. Slowly (no method cache definitely hurts) but still, works is good. The PMC that the class ->init method hands back is a ParrotObject, rather than a ParrotClass, which is good as it's an object and all. The vtable on the object is currently the base ParrotObject vtable which, as you can probably see, doesn't do a whole lot besides method calls. Still to do: *) Multiple inheritance *) Runtime inheritance changes *) Runtime attribute changes *) Metadata support for class creation *) Tests to make sure it actually, y'know, works. *) Delegation of vtable methods to methods in the class *) fallback method finding Happy "Abuse the Objects" day, everyone. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: cvs commit: parrot/config/gen/makefiles root.in
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Andy Dougherty <[EMAIL PROTECTED]> wrote:
>
> > Sorry, I guess I should have been more explicit. What folks apparently do
> > is have the sources on an NFS server mounted read-only. They then build a
> > symlink tree onto a local read-write filesystem and run the build there.
> > Thus they can create all the new files they want, but they can't touch or
> > change the source files.
>
> That works except for the imc{parser,lexer} generated files. But we
> could remove touching these files. When Configure.pl --maintainer was
> run, you probably have the tools to create these files.
Some different idea:
Rename imc{parser,lexer}.[ch] files in CVS to
imc{parser,lexer}_c.generated. In non--maintainer mode these files are
simply copied, wheras in --maintainer mode the files are regenerated
from the sources imcc.[ly]. I think gcc uses something similar.
I don't think we even need to preserve the history
imc{parser,lexer}.[ch]; they are generated files anyway.
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [perl #24576] Some new targets in makefiles/root.in
Bernhard Schmalhofer (via RT) <[EMAIL PROTECTED]> writes: > languages.in: > - add $(MAKE_C) befunge clean in target 'clean' > > root.in: > - add target 'help': This should give a basic overview of what can be done > with the Makefile > - add target 'languages-clean': I needed that for testing > - add target 'docs-clean': This seems to be consistent > - add a '@' in 'flags-dummy': "Compiling with" should be printed only once > - add target 'patch': generate a patch, when there are diffs to CVS, seems > to be useful to me All these items are good. > I also did some reformating of lists in 'root.in'. This is of course a > matter of taste. > I don't like tabs in lists. As tabs have a defined meaning in targets, I > find it confusing to see them in macro assignments. This change touches many lines. This will invalidate many outstanding patches, which often need to change root.in. Anyway I think you are right, tabs don't belong in list definitions, and I also like the convention using a single line per item; this makes future diffs simpler. If nobody objects to this I will apply this patch in 3 days (I think this is a reasonable time) bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Raising exceptions
> > I've been hard pressed to find any examples of proper exception-raising > > with Parrot > > t/pmc/exception.t Excellent, thank you.
More object stuff
Now that objects at least limp along a bit (albeit in a crashy, hackish way) it's time to look forward a bit. The code definitely needs some looking at and cleanup. It's not perfect and I expect it's flawed in a number of places. I'm just happy to get the damn stuff into the repository so the bytecode tests can start. Implementation can always change as long as the bytecode interface stays constant. If someone'd like to take a shot at making a nice OO wrapper for Postgres, especially if they'd like to upgrade the postgres interface to 7.4, I would very much appreciate it. It'd be a nice demo, and a good start on a DBI module for us. (And yeah, there's an element of "do my job for me" here. Sorry 'bout that) If we get objects hammered on and functional, we've met a requirement for a .1 release. Scary, but true. For the record, the point release criteria are: *) Objects *) Objects with multiple inheritance *) Exceptions we're happy with *) Events *) Fully functional IO *) Working module system we're happy with There are more, I expect, but we'll deal with that when we get there. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #24584] [PATCH] 'in macro' vs. 'in file' in some imclexer.c error messages
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #24584] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=24584 > This patch concers a few error messages generated in 'imclexer.c'. When playing around with 'pcre.imc' for 'Parrot m4', I got a strange error message: -- error:imcc:parse error, unexpected IDENTIFIER in file '.PCRE_DOLLAR' line 53 included from 't/regex/001_pcre_2.imc' sub '_main' line 23 - The cause of the error was in my code, but the strange thing is that '.PCRE_DOLLAR' is a macro. The error message can be switched to 'in macro' by telling the 'frames' pointer earlier, that the current frame is a macro, not a file. I think the 'imclexer.c' is generated from 'imcc.l' during maintainance. So I made the patch in both files. I also added two test cases in 'imcc/t/syn/macro.t'. The last test case fails without the patch in 'imclexer.c'. CU, Bernhard -- /* [EMAIL PROTECTED] */ -- +++ GMX - die erste Adresse fÃr Mail, Message, More +++ Neu: Preissenkung fÃr MMS und FreeMMS! http://www.gmx.net imcc_l_20031202.patch Description: Binary data
Re: configure on windows
On 02 Dec 2003 18:37:15 +0100, Juergen Boemmels
<[EMAIL PROTECTED]> wrote:
>Pete Lomax <[EMAIL PROTECTED]> writes:
>
>> Command line used was:
>> $ perl -e "open STDERR,'>&STDOUT'; exec qq{$^X Configure.pl --cc=gcc
>> --cgoto=0 --jitcapable=0 --verbose}" > conf.out
>>
>> Output file is attached
>
>[...]
>
>Ok, I looked through this things.
Many thanks, Configure.pl is now running without any warnings or
errors.
However (gulp), make fails with:
Can't use an undefined value as an ARRAY reference at
lib/Parrot/OpsFile.pm line 432.
make: *** [include/parrot/oplib/core_ops.h] Error 255
Any idea what that means?
Regards,
Pete
[RFC] IMCC pending changes request for comments
In an effort to improve its error reporting ability and internal maintainability, I'm considering the following changes; well number (1) is already decided, but I need feedback from compiler maintainers before doing so. 1) Currently typenames are not checked except with 'new ' C<.local identifier> and C<.param identifier> both assume that anything for type other than (int|float|string) is a PMC. This was not intended to be permanent behaviour, but I never added the proper checking. Patching my local copy has uncovered a few places where people have used the undocumented "feature". The downside to the "feature" is lazy error checking and confusing messages from IMCC that have nothing to do with the error. New hackers write ".local integer i" and then waste time wondering why IMCC keeps saying "unknown parrot op foo_p_p" because integer really isn't a type, what they meant was (int). I see in a lot of tests the use of C and C as types in IMC code. I believe Jako and Perl6 compilers use C as well. I'm ok with just adding those 2 as aliases for C register, but I only want to add aliases that are appropriate. The feature of defaulting to PMC is going away, so get your requests in now. I also want to keep the aliases to a minimum. From now on any declarations in IMCC will require either an IMC register type or a predefined classname or PMC. Else, just use C to mean generic. Comments from the compiler maintainers (especially the Perl, Forth & Jako guys)? 2) In the absence of some sort of return instruction, subs currently just run off the end of their code and continue merrily. This feature really isn't useful as far as I can see because it is not supported to assume any ordering between compilation unit, which a sub _is_. It is easier to just assume a sub returns by the active convention. I'd like to just be able to write void subs as: .sub _foo print "hello\n" .end 3) Strict prototyping mode shortcut (backwards compatible of course): As usual, shortcuts are for hand-hackers, but its easier to debug either way. .sub _baz (pmc p, int i) ... .end Same as: .sub _baz protoyped .param pmc p .param int i ... .end 4) No implicit global labels with the label :== IDENTIFIER COLON syntax. Currently labels beginning in _ are global. I'd like to remove the implicit aspect of it. sub definitions will create global labels, as might other directives, but there will no longer be a requirement that subs start with _ in order to get the correct behaviour. We might still want global labels declarable, somehow, so I'm open to suggestions, but I don't see the need, really. A couple of these suggestions might seem uncalled for. Honestly I am trying to tighten up things and officialize IMCC behaviour so expect more soon. Some changes might cause minor breakage to existing compilers but that is just growing pain. -Melvin
Re: >>OP<< [was: Re: Properties]
On Tuesday, December 2, 2003, at 12:37 PM, Luke Palmer wrote:
Michael Lazzaro writes:
There were also vaguely threatening proposals to have <> and
>>op<<
do slightly different things. I assume that is also dead, and that
<> is (typically) a syntax error.
Ack. No, slightly different things would be a very bad idea.
At the moment, as most of you probably know, they do *very* different
things. >>op<< vectorizes the operator, and <> is
equivalent to qw{some stuff}.
Sorry, right.
I therefore deduce that the proposal to have, for example, <<+>> mean a
different flavor of vectorization than >>+<<, e.g. for these to do
different things:
@a >>+<< @b;
@a <<+>> @b;
is quite soundly and completely dead.
Excellent. Let us not speak of it again.
MikeL
Re: >>OP<< [was: Re: Properties]
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote: > > On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote: > > Didn't know "is" would do that. Good to know! > > And in my meager defense, I did reference MikeL's operator > > synopsis as of 3/25/03, which said ^[op] might be a synonym > > for <<>> or >><< (Sorry, no fancy chars here. :) > > Hey, that was *March*! ;-) The fossil records from that time are > fragmentary, at best. lol... and I've been a little out of the loop lately, too. > I don't think I ever saw any further reference to the ^[op] syntax > staying alive; I assume that means it's dead. Last I heard, which > was admittedly around the same time frame, we'd have the > non-Unicode-using >>op<<, and a Unicode synonym »op«, and that's it. I think I saw a few of those in passing. Been a while. :) > There were also vaguely threatening proposals to have <> and > >>op<< do slightly different things. I assume that is also dead, > and that <> is (typically) a syntax error. Which is probably a good idea. We have any/all/one/none, and not *everything* needs a punctuation-type version. I'd actually rather *not* have alternate versions of those, unless they do something different, like they way "or" has a lower precedence than "||". Likewise, if we're going to use <<>> as P6's version of P5's qw//, then never mind the complexity of making the parser able to figure out that a given case of <<+>> means I've deleted all other items from the list, rather than wanting a distributive addition Yes, I could figure it out, but there are currently enough contextually dependent items in the language that the importance of that one doesn't strike me as 'core' necessary, if you know what I mean. :o) > If anyone in the know knows otherwise, plz verify for Piers' summary > and the future fossil record. > MikeL Could we get a synopsis posted somewhere? Maybe something that inticates the current state of this particular onion? __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Re: >>OP<< [was: Re: Properties] [OT]
> And as far as I know, << and >> are exactly equivalent to æ?? and æ?? > in all cases. lol I get the idea, but I foresee these unicode bits as becoming an occasional sharp spot in my metaphorical seat of consciousness. :) I am not seeing unicode. __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Re: Objects!
At 10:52 AM 12/2/2003 -0500, Dan Sugalski wrote: Single-inheritance objects seem to be done. The code can use a lot of abuse and cleanup, and we need actual tests to make sure that it functions as it should, but they're in. Let me start the abuse. *(cough)* examples would be nice ;) Ok, abuse over. I am just happy we are moving again. *) Creating new objects involves calling the ->init vtable entry *on the class*. Because of this each class gets a custom vtable where the init method has been swapped out for one (from objects.c) that creates a new object instead. So do you want an init op added to object.ops or is there something I am missing. I did toss in 'isa', although the implementation is wrong as you said. -Melvin
Re: Objects!
At 10:09 PM -0500 12/2/03, Melvin Smith wrote: At 10:52 AM 12/2/2003 -0500, Dan Sugalski wrote: Single-inheritance objects seem to be done. The code can use a lot of abuse and cleanup, and we need actual tests to make sure that it functions as it should, but they're in. Let me start the abuse. *(cough)* examples would be nice ;) Examples? We don' need no steenkin' examples! :-P *) Creating new objects involves calling the ->init vtable entry *on the class*. Because of this each class gets a custom vtable where the init method has been swapped out for one (from objects.c) that creates a new object instead. So do you want an init op added to object.ops or is there something I am missing. I did toss in 'isa', although the implementation is wrong as you said. Nah. new works just fine for objects, as it ought. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RFC] IMCC pending changes request for comments
On Dec-02, Melvin Smith wrote: > > 1) Currently typenames are not checked except with 'new ' I would vote for no aliases at all. I propagated the existing uses of ".local object" in the Perl6 compiler and introduced several more uses, but that was only because I wasn't sure at the time whether it was intended to (now or in the future) have slightly different semantics. It wasn't, I'm pretty sure. So I'll switch Perl to using 'pmc' if you make the change. > 2) In the absence of some sort of return instruction, subs > currently just > run off the end of their code and continue merrily. This > feature really > isn't useful as far as I can see because it is not supported to > assume > any ordering between compilation unit, which a sub _is_. > > It is easier to just assume a sub returns by the active > convention. > > I'd like to just be able to write void subs as: > > .sub _foo >print "hello\n" > .end Do you really want to generate the extra unused code at the end of all the subroutines? I don't think you want to autodetect whether the code is guaranteed to return. How about adding a return value specification if you want this generated automatically: .sub _gorble () returns (int r) r = 5 .end .sub _foo () returns void print "hello\n" .end (This assumes you're creating implicit locals for return values as well as parameters, as you described in #3.) > 3) Strict prototyping mode shortcut (backwards compatible of > course): > As usual, shortcuts are for hand-hackers, but its easier to > debug either way. > >.sub _baz (pmc p, int i) > ... >.end > >Same as: > >.sub _baz protoyped > .param pmc p > .param int i > ... >.end Sounds good to me; debugging the Perl6 sub calling stuff would have been easier if I didn't have to read so much code to figure out what was going on.
Re: [RFC] IMCC pending changes request for comments
At 07:59 PM 12/2/2003 -0800, Steve Fink wrote: On Dec-02, Melvin Smith wrote: > > 1) Currently typenames are not checked except with 'new ' I would vote for no aliases at all. I propagated the existing uses of ".local object" in the Perl6 compiler and introduced several more uses, but that was only because I wasn't sure at the time whether it was intended to (now or in the future) have slightly different That would be my fault for not providing documentation with the compiler. Do you really want to generate the extra unused code at the end of all the subroutines? I don't think you want to autodetect whether the code is guaranteed to return. Good point. Its easy to detect returns if the code uses high level IMC directives, but in cases where it is all low-level PASM, it could get a little troublesome. It would also add a few dead instructions here and there. Nix that idea. .sub _gorble () returns (int r) r = 5 .end We may need something like this anyway for prototyped subs. Currently we are only prototyping the parameters, not the returns; not quite orthogonal. Thanks for the comments, -Melvin
This week's summary
The Perl 6 summary for the week ending 20031130
Welcome back to the weekly Perl 6 Summary, which I'm hoping to keep on a
weekly cycle for the foreseeable future.
It's been a relatively low volume week this week, I'm assuming that
Thanksgiving had something to do with it (I hope those of you who
celebrate it had a jolly good extended weekend), and for the first time
in ages perl6-language saw almost as much traffic as perl6-internals.
We're still going to start with perl6-internals though.
Some PIR "How do I?" questions
Last week Dan put up a list of questions about IMCC, intending it as a
bit of grit. This week Melvin Smith added a couple of layers of nacre by
checking in an initial IMCC FAQ (you'll find it at imcc/docs/imcfaq.pod
in your parrot directory if you're following with CVS). After an initial
flurry of work on adding to the FAQ, the discussion seems to have
drifted off into discussions of bike shed pigmentation. Yes, the FAQ may
need to be split eventually, but splitting an FAQ into sub documents is
trivial compared to actually answering the questions. Ahem. Editorial
ends.
http://groups.google.com/[EMAIL PROTECTED]
http://www.parrotcode.org/faq/imcc -- The FAQ
PIO_eof
Vladimir Lipsky had a few questions about how the Parrot IO subsystem
(PIO) handles error conditions. This sparked a discussion of whether the
various PIO functions should make some assertions up front about their
arguments. Consensus said "yes", they help with debugging, and the
performance 'hit' is minuscule.
http://groups.google.com/[EMAIL PROTECTED]
Freezing and Thawing
Discussion of the details of object serialization continued this week.
Judging by the amount of clarification traffic that's been going on in
this thread (and others), I find myself wondering if the time has come
for some generous benefactor to sponsor the principals to get together
in a conference room with copious whiteboard acreage. Sponsors welcome.
http://groups.google.com/[EMAIL PROTECTED]
Segfault warning boxes
Consider a system of test machines, all of them happily running in
unattended mode, constantly checking out the latest version of parrot,
compiling everything, running the tests and reporting the results to
some central webserver that displays a status report for all to see.
It's not just a good idea, it's the Parrot tinderbox.
Now, consider an operating system that takes it upon itself to throw up
a modal dialog box when a program segfaults.
The two don't sit well together do they? Which is why Dan has committed
a patch to disable the "Your program has crashed, want to send a report
to Microsoft?" box that pops up on Win32 when Parrot segfaults. Still,
at least it can be disabled.
Dan asked for opinions on whether the (non tinderbox) default should be
to put up a dialog box or not. And it appears that, if you disable the
dialog box, there's no other notification (apart from the failed test,
obviously) that there was a segfault. I am sure I'm not alone in
boggling at this, but it looks like the default will be to display the
dialog.
http://groups.google.com/[EMAIL PROTECTED]
Perl 6 updated
Allison Randal sent in a patch to update the Perl 6 compiler to use the
right operators ("^+" becomes ">>+<<", "~~" (meant xor)
becomes "^^", making way for "=~" to become "~~"). She's still working
on other tweaks to get the semantics of what's already been implemented
right, and claims to be sufficiently annoyed by the failing regex tests
that she might have to go and make them work to remove the annoyance.
Which would be good. (I'm afraid that the tantalizing code I mentioned
last week has actually been there for ages, as I feared it had). That
capital fellow, chromatic applied the patch.
http://groups.google.com/[EMAIL PROTECTED]
String formatting and transformation
Dan got around to specifying some details about string formatting and
transformation. Essentially there will be various case changing
transformations and a couple of different formatting approaches, one
"sprintf" like and another more like traditional COBOL style formatting.
Dan's not sure yet whether these formatters will get ops or simply be
implemented in the standard library.
http://groups.google.com/[EMAIL PROTECTED]
AUTOLOAD anyone?
Someone calling itself ibotty wondered if there would be a default PMC
method that gets automagically called whenever a method call isn't
found. To which the answer is "Yes, when it's done".
http://groups.google.com/[EMAIL PROTECTED]
erl.org
Determining PMC memory addresses
Cory Spencer wanted to know if there was a PASM way of finding whether
two PMCs share the same memory address. "Not yet", said Leo Tötsch, "but
there are entries in the v
Re: tesing exceptions of Error.pm
On Thu, Nov 27, 2003 at 10:02:10PM +0200, Gabor Szabo wrote:
> How am I going to test this ?
> I came up with the following in the test script:
>
>
> use Error qw(:try);
>
>
> my $ex;
> try {
>f();
> }
> catch MyError with {
> $ex = shift;
> };
> like($ex, qr/Bad thing happened/, 'successfully tested bad thing');
>
>
> Now $ex is global but I think I cannot test within the catch block.
Why not?
catch MyError with {
like( $ex, qr/Bad thing/ );
};
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
Good tidings, my native American Indian friend! America will soon again
be yours! Please accept 5th Avenue as an initial return!
Re: T::H 2.38
prove begins with #!/usr/bin/perl and prove-switches.t runs it with my @actual = qx/$prove -Ifirst -D -I second -Ithird -Tvdb/; A $^X should be inserted here. (in bleadperl, the shebang line of prove is fixed when installed.) What should be in prove's shebang? xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
