[perl #47926] problem with non-existing Protoobject.pbc
Marking ticket as resolved, thanks! Pm
Re: [perl #47926] problem with non-existing Protoobject.pbc
On Nov 29, 2007 6:18 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > > On Wed, Nov 28, 2007 at 11:22:30AM -0800, James Fuller wrote: > > # New Ticket Created by "James Fuller" > > # Please include the string: [perl #47926] > > # in the subject line of all future correspondence about this issue. > > # http://rt.perl.org/rt3/Ticket/Display.html?id=47926 > > > > > > > after building parrot (and doing a make realclean to ensure all is > > well) having a problem running parrot with perl6. > > > > building latest trunk if parrot on Mac OSX 10.4.9 > > > > when I run with perl6 > > > > >parrot perl6.pbc > > > > "load_bytecode" couldn't find file 'Protoobject.pbc' > > current instr.: 'parrot;PGE::Match;__onload' pc 0 > > (compilers/pge/PGE/Match.pir:14) > > called from Sub 'parrot;Perl6::Compiler;__onload' pc 0 (perl6.pir:30) > > called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) > > > > build does not seem to be making Protoobject.pbc > > Very strange. Out of curiosity, is there perhaps another > installation of Parrot on the system (perhaps from a previous > 'make install')? This sounds suspiciously like the parrot command > is an old version looking in the wrong place. very interesting is right, I did have another installation but I never installed it via macports; it seemed to have its own ideas. > Also, perhaps you could try using an explicit path for parrot, > just to make sure we really are running the right one. For example: > > ../../parrot perl6.pbc > > If neither of those help, could you see if there's a Protoobject.pir > and Protoobject.pbc in the runtime/parrot/library/ directory? > > Thanks! can confirm that I have operation now on mac osx. thx for debugging help. now for the fun bit ;) cheers, Jim
prototype-based language under parrot
hi folks, i want to write a compiler for a small prototype-based language that should target parrot. as a reminder: prototype-based means that i have objects, and objects are cloned from other objects, but i have no classes. objects consist of methods and variables that are only accessible to methods on the same object. my question is: how should such code look on pir level? has anyone done something like it before? my current solution is to have a namespace for each object, with methods in it: .namespace [ "Foo" ] .sub _meth :method print "in meth\n" .end .sub _other_meth :method print "in other_meth\n" .end and to store the variables in some hash and access them via a C callback. does not look right to me. so i am looking for suggestions or pointers on how to implement such a language in PIR, any help welcome! thanks robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
[perl #47992] [RFE] 'parrot foo' automatically finds and invokes foo.pbc
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #47992] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=47992 > I just recently committed examples/sdl/blue_rect.pl as an example of exercising the SDL library using NQP. At the beginning of the file the instructions read: To run this file, execute the following command from the Parrot directory: $ ./parrot compilers/nqp/nqp.pbc examples/sdl/blue_rect.pl Typing in that pathname is a bit of a pain -- what I'd really like to be able to say is $ ./parrot nqp examples/sdl/blue_rect.pl and then since parrot can't immediately find anything called 'nqp' to execute, it looks for nqp.pbc in a standard location or locations and invokes that. Similarly $ ./parrot perl6 blue_rect.pl $ ./parrot tgc --output=gen.pir PASTGrammar.tg $ ./parrot abc $ ./parrot tcl xyz.tcl $ ./parrot pynie hello.py etc. Before we get too far, let me point out what I'm *not* asking for. Specifically, I'm *not* asking for parrot to automatically select an appropriate compiler based on a file's signature or magic, as discussed in RT#32374. In other words, I'm *not* asking that $ ./parrot examples/sdl/blue_rect.pl be able to automatically determine an appropriate compiler and invoke it on the script. While this is a very worthy and important goal, at the moment there seem to be so many issues around "how does Parrot register compilers and figure out which one to use" that I fear it will be a while before this gets implemented. I want something sooner than that. I'm also explicitly *not* asking to try to handle or resolve things based on Unix shebang lines, so that a file starting with #!/path/to/parrot nqp will automatically be executed with nqp. Again, it's something we will eventually want to consider, but given the vagaries of dealing with shebangs in so many different languages and platforms it's not what I'm aiming to get from this ticket. All I'm really looking is to be able to place the .pbc file for a compiler or other application into a standard location where it can be invoked from Parrot without having to give a complete path to the .pbc file. This could also have the benefit of simplifying Makefiles as well. For example, when I moved nqp from languages/ to compilers/ , I had to change the Makefile from $(PARROT) $(PARROT)/languages/nqp/nqp.pbc to $(PARROT) $(PARROT)/compilers/nqp/nqp.pbc ... While it was easy to do for this one case -- imagine if we had 10 or 20 applications that were using nqp as part of the build process. With the approach proposed here, the Makefile can have $(PARROT) nqp ... and it all just works. I would also be willing to accept an option-based version of this, such as (pick an appropriate option name or letter): $ ./parrot --prog=nqp blue_rect.pl Comments, suggestions, and (most importantly) implementations welcomed. Thanks, Pm
Re: [svn:parrot] r23284 - trunk/docs
On Friday 30 November 2007 07:45:42 [EMAIL PROTECTED] wrote: > +If you embedded a Parrot in your C file and you want to invoke another > function > +in that same C file, you should pass a null string to loadlib. Do This only works if the dlopen()-like implementation on the platform follows POSIX guidelines. Mac OS X 10.2 and earlier do not. I don't know about other less-Unixy platforms. I imagine that this is fixable (and that we may want to support it), but currently it won't work on every platform I know about. -- c
Re: [perl #47980] [Pynie] using invalid attribute syntax...
chromatic wrote: On Thursday 29 November 2007 20:54:13 Will Coleda wrote: $ svn diff Index: src/parser/indent.pir === --- src/parser/indent.pir (revision 23256) +++ src/parser/indent.pir (working copy) @@ -17,7 +17,7 @@ .local pmc optable, ws optable = get_global '$optable' ws = get_global 'ws' -setattribute optable, "PGE::OPTable\x0&!ws", ws +setattribute optable, "&!ws", ws .return () .end Allison knows better than I do, but that patch looks correct. I did something similar in a lot of code on the pdd15oo branch, way back when. Aye, it's correct. The old line was using the old syntax to access an inherited attribute from a particular parent. The new line works because it just directly sets the inherited attribute in the child's data storage. If you really needed to access data storage for the parent separate from the child (which isn't necessary here), you would use the new keyed attribute syntax, where the key specifies the desired parent: setattribute optable, ["PGE::OPTable"], "&!ws", ws Allison
Re: prototype-based language under parrot
Robert Lemmen schrieb: hi folks, i want to write a compiler for a small prototype-based language that should target parrot. as a reminder: prototype-based means that i have objects, and objects are cloned from other objects, but i have no classes. objects consist of methods and variables that are only accessible to methods on the same object. my question is: how should such code look on pir level? has anyone done something like it before? my current solution is to have a namespace for each object, with methods in it: I have no answer for that. My suggestion is to look how it is solved in PJS, http://users.fulladsl.be/spb1622/pjs/. Regards, Bernhard
Re: xml and perl 6
By the time this got written, I see James has bowed out of the
discussion with some words about 'architectural break points'. Even so,
my two-penniworth:
JF gave some examples of how he would like xml to be 'a part of core'.
For clarity, I use xml and I have designed a language to describe
financial scoring models as xml. To process the language _in perl_ I
looked at a variety of processing approaches before deciding on
XML-Twig. Note there were different approaches and they are
fundamentally different. I choose the one that suited me and the problem
space best.
Hence the design philosophy underlying perl6 encourages this
flexibility. So despite my own current preferrence for xml as a data
description methodology, I absolutely agree with the perl6 design.
Some more analysis:
first a few assumptions;
we will probably never want to 'address' xml in perl ... e.g. perl
format will never become declarative markup and there is no reason to
start wanting to somehow mix code/data lisp style in perl
a) why is this true? The flexibility in perl6 with its ability to morph
its own input grammar makes it entirely possible to consider
interspersing output markup with processing commands. "Consider" is the
important word. Whether such an approach would be aesthetically pleasing
is entirely another question. I do find php to be quite ugly. However,
suppose someone comes up with a nice way of doing it, great ...
another thing to admit is that an XML type would probably just be an
XML document well formed and adhering to the rules of XML v1.0
going beyond that and stating it must be an XML Infoset is going
too far.
b) Why a document? and look at the snippits below, they are not
documents, unless my understanding of what a document is differs from
that being implied in this posting.
c) For me, xml means a way of encapsulating data in a clear cut way.
---
Here are some examples of psuedo syntax I would find useful (which I
have borrowed from things like XQuery, e4X, etc);
-
declaring some xml in one's perl program;
-
my $sales =
;
d) My problem with this snippit is that there is no context in the sense
of a problem space that is being tackled. What is the whole script
trying to do? Why is it so important to loose the bracketing syntax of
quotation marks that would identify the right hand side as a normal user
defined object?
e) It would seem from the entire xml email thread that JF equates xml
fragments with integers and strings. But look at the xml fragment above.
"4" is an integer, "peas" is a string. In other words, the xml fragment
is itself built up from more fundamental data types. Hence xml is not so
really fundamental or "core", but rather as a common method of
aggregating data. Perl6 is designed to allow for the creation of objects
that aggregate data.
f) From what I understand about Perl6 is that the fragment given about
could easily be a part of a Perl6 script. However, a "use
XML-Scripting;" statement would need to be included that would introduce
the appropriate grammar rules so that i) the xml fragments are correctly
parsed and assigned, and ii) all the other parts of the script would
parse correctly and unambiguously.
g) Given the length of time it has taken to develop Perl6 (FAR TOO
LONG!!!, I would humbly suggest as a user who wants to see Perl6 in
real life), and the careful discussions that have gone into all aspects
of syntax and grammar, it is by far not obvious to me that creating a
module that handles xml as above would be trivial.
no surrounding quotes seems about right.
however this leads to some 'other thoughts, like how does perl and xml
play nice together
h) Perl6 and xml would play nicely together if some talented programmer
creates a nice playground, viz. an elegant and unified syntax that
excludes the other ambiguities of the real world.
what about;
my $html =
{ $sometitlevar }
i) If you like this type of scripting - and I really dont - I can see no
reason why you cant design a module to do this with perl6.
j) By the way, all of these snippets are html not xml, or rather there
are no xml examples here that are not html. JF, do you work with xml or
with html?
{
loop ($counter = 1; $counter < 20; $counter++) {
Try to count electric sheep . . . ;
}
}
I have eschewed with explicitly having a print statement, as a
syntactic shortcut.
k) But why? Create an 'XML-Scripting' module and I would imagine it to
be possible for perl6 to export any value that is of type xml directly
to an output stream.
when it comes to manipulating XML, there are a few axioms...
-
How to Address parts of an XML document variable ?
-
It is common to want to address a portion of an XML document
my $select_li
Re: xml and perl 6
On 11/29/07, James Fuller wrote:
well, if my previous posts didn't attract flames this post
certainly will ;)
Nah, this is getting into the interesting language part!
(Technically, it should be perl6+xml-language... but then the goal of
perl6 is to be infinitely flexible, so I guess it is on topic!)
but you did say 'from a users perspective' ... so I will play 'make
believe' with some syntax
I mentioned in my previous message that there is a technical side to
the issue of standards. That involves questions about what makes for
a "good" XML (etc.) module (which raises the question, "Good for
*what*?" -- a practical answer is, what's good for a lot of the
people a lot of the time. Maybe there's no single answer even to
that question, so perhaps there are multiple standards in some cases;
that's fine. And of course, there will always be de facto standards
based on whatever "most people" happen to be using at any given time.
That's fine too.)
But one of the obvious things that makes a module technically good --
and the one that's most relevant here -- is what its "dialect' is
like, how its syntax works, how perlish it is; in other words, how
well it fits in with design goals of perl6 as a language. We've all
seen modules that worked but didn't feel very perly (and a good
Python XML module might look very different from a good Perl one).
So I think what a P6 XML module would look like (as opposed to how it
works) is certainly worth discussing here. (Or indeed, any other
module, as far as its linguistic aspects go.) The first thing that
caught my eye about James's examples was the way he plunked XML (that
looked like XML) in the middle of Perl (that looked like Perl).
my $sales =
;
no surrounding quotes seems about right.
Having just been admiring Aurdrey's XML::Literal module the other
day, I was wondering whether it could work in Perl6. P6 already
works the angles pretty hard -- you couldn't make them quote a piece
of XML without giving up their standard string-quoting function. But
hey, maybe that's worth it if you're doing a lot of XML. Could P6
still recognise a hash-key quoted %like as a special non-XML
case? (Should it? Would XML-keys be particularly useful?) Or is it
better to pick some other characters as the XML-quoters and have the
code "almost" look like XML?
Having your XML look like XML carries definite advantages, and having
things look like what they are is definitely part of Perl's
philosophy. But on the other hand, XML is kind of bulky and awkward,
so maybe the Perly thing to do would be to translate it into
something that looks like how it works: XML documents are trees, so
maybe they ought to look more like ordinary hashes.
(E.g. on 11/29/07, Patrick R. Michaud wrote:
my $doc = Document.new;
$doc = 'here';
-- much better than a here-doc, which wouldn't provide you with
syntax-checking, syntax-colouring, or syntax-anything-else.)
[...]I like my 'scanability' to be in xpath form ala:
my $select_li_elements = $html[/html/body/span/ul/li];
and then u have the expressive power of xpath inside of these brackets.
Perl would more likely use something like $html (or even
$html), since square brackets mean ordinal indices
(though you could make that work too). You could have
$html and $html.html.body both work. Perhaps more
interesting is to consider something like:
my $select_li_elements = /$html/body/span/ul/li;
Hm...
( as an aside, is there any concept of the native types, Scalar,
Array, Hash being in a different namespace then all the other
symbols e.g. could I override Scalar type ?)
I guess the idea would be to have unspecified scalars default to the
XML type (instead of type Any)? Sure! (I don't know exactly how, I
just know P6 lets you do anything you want.) Of course, if you have
special quotes, there might be no need: if Perl knows that is
XML data, then "my $f=" will do the right thing.
This would replace text context node of
$html[/html/body/[EMAIL PROTECTED]'mydivid'] ] = "new text value";
$html:id = "new text value"; ?
I am unsure of what an append scenario would look like.
push? ~=? .append()?
Perhaps one would like to be able to decide if this xml must be
checked for validaty against some schema technology (DTD and relaxNG
as basic) are there any 'adjectives when declaring a type ... I
guess I am suggesting a new sigil enforcing an XML context ;0
That wouldn't be a new sigil (despite Perl6 letting you do anything,
I think this is one area where it would look the other way and
pretend not to hear you unless you got really insistent); probably
you'd say:
my XML::Doc $foo is validated($dtd);
should print out the value of each div contained in html
for $myxmlvar[/html/body/div]]{
print; # prints $_, the current loop variable
}
Yup (although I think that should be: for =$myxmlvar[etc...]).
I will stop her
Standards bearers (was "Re: xml and perl 6")
On 11/29/07, James Fuller wrote: but by making some fundamental xml processing available by the core (like file access, regex, and a host of other fundamental bits n bobs), u do promote a common and systematic approach to working with XML in all perl modules. As everyone else and his dog has pointed out, the "core" thing is pretty much irrelevant, but I think this gets at the real point here: what's *standard* is the important thing. (In P5, many standards were determined by what was included in the core modules, hence the confusion.) Not being locked in to one way, or not being able to predict the future, etc., are all excellent points, but at the same time clear and easily recognisable standards are very important also. So what's the "standard" P6 module for XML (or anything else)? Perl6 will make some of this moot: one problem with "official" modules in P5 is maintenance; once a module enters the CORE(TM), it has to be maintained forever so that people can rely on its being available. I expect P6 will make availability transparent (or mostly so, if you have Internet access and haven't blocked CPAN or something). P6 doesn't need a core to make stuff available -- whatever is out there will be at your fingertips. In some ways, "standard" isn't any better or more meaningful a word than "core", but it is important to be able to find a "good" module without being an expert. (Of course, it's for that very reason that it can't be an issue of the language itself, because Larry -- or even @Larry -- isn't an expert in everything. (Actually, I suspect Larry could do very well in deciding everything from the best XML module to the best knitting module (Purl6--coming soon to a CPAN mirror near you!)... but maybe he doesn't *want* to!)) Part of a solution is search.cpan.org -- if you can figure out which of the 870 XML modules will be useful to you. Another part is asking on newsgroups or lists -- if you can figure out which of the 870 opinions offered is knowledgeable. I think things like the CPAN ratings and reviews will become increasingly important. Of course, this is all a community issue (rather than a technical issue), and questions about handling reputation are certainly not limited to Perl or CPAN. Maybe some kind of "Advisory Board" would help, where people (who might be experts in various ways) can offer informed recommendations on what modules make a good fit for what circumstances. Ultimately, if this is something we want, somebody needs to volunteer to organise something. (Or volunteer to figure out exactly what it is that would need organising) The other side to this problem is coming up with good modules so there's something to recommend. But that is a technical issue and something for a separate post. -David
Re: Seeking Comments on a Variety of RT Tickets
> https://rt.perl.org/rt3/Ticket/Display.html?id=46539 > [BUG] compilers/pirc/new/pir.l failing t/codingstd/cppcomments.t > Coke commented on this on Oct 21, but ticket has not been resolved. > Spot check of smoke tests suggests it may now be passing on all OSes. compilers/pirc/new/pir.l is exempt from the coding standards tests. This has been fixed for a while and AFAIK the ticket can be closed. Paul
Re: [perl #47972] [DEPRECATED] getclass opcode
Patrick R. Michaud wrote:
The problem isn't so much with ParrotIO as it is with the way that
'say' is implemented. Say expects to be able to get the ParrotIO
class object and invoke the 'say' method on it -- but this is no
longer valid under pdd15 objects, where the class methods are no
longer available via the class object.
$P0 = getclass 'ParrotIO'
$P0.'say'('hello')# works
$P1 = get_class 'ParrotIO'# actually gets a ProxyPMC
$P1.'say'('hello')# fails
Ah! I only had 5 minutes to look at it before running out the door to an
all-day meeting. Then the code could just change to:
$P1 = new 'ParrotIO'
$P1.'say'('hello')
and make the default ParrotIO object use STDOUT.
But, I'm still in favor of making 'say' an opcode instead. The I/O
subsystem is far too full of "special" solutions, so I'd like to
standardize it with the rest of Parrot wherever possible.
If I'm reading this correctly, I'm guessing that means that there
would be pre-defined objects somewhere for stdout, stdin, stderr.
If that's the case, this would seem to argue for approach #2, or
something like it -- i.e., grab the object corresponding to stdout
and do something with it.
There already are predefined objects, they're retrieved by the
getstdout, getstdin, and getstderr opcodes. (Which internally call
_PIO_STDOUT(interp), etc...)
Mainly I meant that I/O will use PMC inheritance and compile-time
composition instead of its current "layers".
The 'say' opcode is incredibly useful, and I use it a lot.
I raise both my hands in favor of keeping it.
Two votes is good enough for me. It stays.
As far as my opinions to the four items in Coke's list... I like
#1 the least and #3 the best. There's also a fifth option,
which would be something like:
5) Have every class automatically create a protoobject and let
'say' and the other similar opcodes be able to access methods
via the protoobject. We might even introduce a new opcode:
$P0 = get_proto 'ParrotIO'
$P0.'say'('hello')
But I'd venture to wait for other tools to mature a bit before
committing to protoobjects in the parrot core. So, even with
option #5, I think I'd prefer to go with something like #3 for
the time being.
Agreed. Avoid the "special" solutions until they're absolutely necessary.
IMO the majority of the other builtins aren't
important enough for their own opcode syntax -- we can just
use the method syntax instead.
If they aren't worthy of their own opcode, are they worthy of the
builtin syntactic sugar?
Allison
Re: Standards bearers (was "Re: xml and perl 6")
On Nov 30, 2007 10:57 AM, David Green <[EMAIL PROTECTED]> wrote: > Maybe some kind of "Advisory Board" would help, where people (who > might be experts in various ways) can offer informed recommendations > on what modules make a good fit for what circumstances. Ultimately, > if this is something we want, somebody needs to volunteer to organise > something. (Or volunteer to figure out exactly what it is that would > need organising) Step 1: Form a committee to decide whether the formation of a Organization Committee for the Advisory Board would be advantageous. Step 2: Allow time for the committee to decide. Step 3: If the organization committee is formed, allow it time to organize the board. Step 4: By this time, Perl 7 will have been released, and the board is closed with a Job Well Done. Alternative Step 4: Determining whether this step will ever be reached is equivalent to the halting problem. Luke
reference books for Parrot design and development?
Besides the obvious _Perl6 and Parrot Essentials_, are there any other books that one could use to get a good background for Parrot development? I'm wondering if there are any references that people developing Parrot are using. Thanks, Jerry
[perl #46539] [BUG] compilers/pirc/new/pir.l failing t/codingstd/cppcomments.t
On Nov 30 2007, ptc wrote: > > https://rt.perl.org/rt3/Ticket/Display.html?id=46539 > > [BUG] compilers/pirc/new/pir.l failing t/codingstd/cppcomments.t > > Coke commented on this on Oct 21, but ticket has not been resolved. > > Spot check of smoke tests suggests it may now be passing on all OSes. compilers/pirc/new/pir.l is exempt from the coding standards tests. This has been fixed for a while and AFAIK the ticket can be closed. Paul Resolving ticket. Thanks, Paul.
Re: reference books for Parrot design and development?
Hi Jerry, > Besides the obvious _Perl6 and Parrot Essentials_, are there any > other books that one could use to get a good background for Parrot > development? I'm wondering if there are any references that people > developing Parrot are using. AFAIK Perl6 and Parrot Essentials isn't very up to date with the current Parrot status. There is, however, a large body of documentation available which (I hope!) can help you, namely: http://www.parrotcode.org/docs/. The docs/ directory within the Parrot svn repository also contains a lot of information. There are also lots of nice people who hang out on the #parrot irc channel (try irc.perl.org for instance) who I'm sure will be all too happy to answer any questions you have :-). You also might want to check out the archives for this mailing list at http://www.nntp.perl.org/group/perl.perl6.internals/ I hope that helps to some degree, and welcome! Paul
[perl #47996] [BUG] pge - regex adverbs don't accept leading space
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #47996] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=47996 > PGE seems to have trouble with [ :sigspace(0) this is not spaced ] # fails versus [:sigspace(0) this is not spaced ] # works Pm
