[perl #130532] [JVM] Failing tests for itemization of arguments with infix: after introduction of Rakudo::Internals.OneValueIterator
On Mon, 29 Jan 2018 03:54:38 -0800, pesc...@gmail.com wrote:
> On Sat, 14 Jan 2017 13:46:47 -0800, barto...@gmx.de wrote:
> > On Tue, 10 Jan 2017 12:46:48 -0800, barto...@gmx.de wrote:
> > > I managed to golf this a bit:
> > >
> > > $ ./perl6-j -e 'use nqp; class A { has Mu $!foo; method bar () {
> > > $!foo
> > > := nqp::null; say nqp::isnull($!foo) ?? "null" !! $!foo }
> > > }.new.bar'
> > > (Mu)
> >
> > As far as I understand, the problem is deep in nqp-j -- either in
> > bind_attribute_boxed (called here:
> > https://github.com/perl6/nqp/blob/7479ce662d6313c303cd684ebbbd56559cb82da3/src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java#L2913
> > ) or in get_attribute_boxed. The code for those methods is far above
> > my paygrade.
>
> As of Rakudo commit a9a9e1c97 neither t/spec/S03-metaops/zip.t nor the
> examples in this ticket actually using Z fail. The code snippet
> showing the conversion of nqp::null to Mu has not changed behavior,
> but considering this ticket is about zip and not NQP difference
> between moar and jvm I am not sure that qualifies as a reason to keep
> it open, and I'd request closing.
I agree. I've opened a rakudo issue about the NQP difference [1] and I'm
closing this ticket as 'resolved'.
[1] https://github.com/rakudo/rakudo/issues/1613
[perl #130532] [JVM] Failing tests for itemization of arguments with infix: after introduction of Rakudo::Internals.OneValueIterator
On Sat, 14 Jan 2017 13:46:47 -0800, barto...@gmx.de wrote:
> On Tue, 10 Jan 2017 12:46:48 -0800, barto...@gmx.de wrote:
> > I managed to golf this a bit:
> >
> > $ ./perl6-j -e 'use nqp; class A { has Mu $!foo; method bar () {
> > $!foo
> > := nqp::null; say nqp::isnull($!foo) ?? "null" !! $!foo } }.new.bar'
> > (Mu)
>
> As far as I understand, the problem is deep in nqp-j -- either in
> bind_attribute_boxed (called here:
> https://github.com/perl6/nqp/blob/7479ce662d6313c303cd684ebbbd56559cb82da3/src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java#L2913
> ) or in get_attribute_boxed. The code for those methods is far above
> my paygrade.
As of Rakudo commit a9a9e1c97 neither t/spec/S03-metaops/zip.t nor the examples
in this ticket actually using Z fail. The code snippet showing the conversion
of nqp::null to Mu has not changed behavior, but considering this ticket is
about zip and not NQP difference between moar and jvm I am not sure that
qualifies as a reason to keep it open, and I'd request closing.
[perl #130532] [JVM] Failing tests for itemization of arguments with infix: after introduction of Rakudo::Internals.OneValueIterator
On Sat, 14 Jan 2017 13:46:47 -0800, barto...@gmx.de wrote:
> On Tue, 10 Jan 2017 12:46:48 -0800, barto...@gmx.de wrote:
> > I managed to golf this a bit:
> >
> > $ ./perl6-j -e 'use nqp; class A { has Mu $!foo; method bar () {
> > $!foo
> > := nqp::null; say nqp::isnull($!foo) ?? "null" !! $!foo } }.new.bar'
> > (Mu)
>
> As far as I understand, the problem is deep in nqp-j -- either in
> bind_attribute_boxed (called here:
> https://github.com/perl6/nqp/blob/7479ce662d6313c303cd684ebbbd56559cb82da3/src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java#L2913
> ) or in get_attribute_boxed. The code for those methods is far above
> my paygrade.
As of Rakudo commit a9a9e1c97 neither t/spec/S03-metaops/zip.t nor the examples
in this ticket actually using Z fail. The code snippet showing the conversion
of nqp::null to Mu has not changed behavior, but considering this ticket is
about zip and not NQP difference between moar and jvm I am not sure that
qualifies as a reason to keep it open, and I'd request closing.
[perl #130532] [JVM] Failing tests for itemization of arguments with infix: after introduction of Rakudo::Internals.OneValueIterator
On Sun, 08 Jan 2017 23:31:11 -0800, barto...@gmx.de wrote:
> Since the new Rakudo::Internals.OneValueIterator is used in infix:
> (Rakudo commit c405f06724) there are four failing tests in
> S03-metaops/zip.t on rakudo-j.
>
> One example of failing code:
>
> $ ./perl6-j -e 'say $(1, 2) Z '
> (((1 2) a) ((Mu) b) ((Mu) c))
>
> $ ./perl6-m -e 'say $(1, 2) Z '
> (((1 2) a))
>
> I investigated a bit and it looks like $!value is Mu here on rakudo-j
> (instead of nqp::null on rakudo-m):
>
> https://github.com/rakudo/rakudo/blob/fbbe446c64fbf98f3fc7e64016e5213a3ee1f09f/src/core/Rakudo/Internals.pm#L1002
I managed to golf this a bit:
$ ./perl6-j -e 'use nqp; class A { has Mu $!foo; method bar () { $!foo :=
nqp::null; say nqp::isnull($!foo) ?? "null" !! $!foo } }.new.bar'
(Mu)
[perl #130532] [JVM] Failing tests for itemization of arguments with infix: after introduction of Rakudo::Internals.OneValueIterator
# New Ticket Created by Christian Bartolomaeus # Please include the string: [perl #130532] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=130532 > Since the new Rakudo::Internals.OneValueIterator is used in infix: (Rakudo commit c405f06724) there are four failing tests in S03-metaops/zip.t on rakudo-j. One example of failing code: $ ./perl6-j -e 'say $(1, 2) Z ' (((1 2) a) ((Mu) b) ((Mu) c)) $ ./perl6-m -e 'say $(1, 2) Z ' (((1 2) a)) I investigated a bit and it looks like $!value is Mu here on rakudo-j (instead of nqp::null on rakudo-m): https://github.com/rakudo/rakudo/blob/fbbe446c64fbf98f3fc7e64016e5213a3ee1f09f/src/core/Rakudo/Internals.pm#L1002 I didn't find the underlying reason, yet. I'll try to investigate further, but for now, I'm opening this ticket.
[perl6/specs] 33eaff: Update Supply introduction and method docs for ser...
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 33eaffeb784e1f2b61511b727ef614615df6bca8 https://github.com/perl6/specs/commit/33eaffeb784e1f2b61511b727ef614615df6bca8 Author: skids Date: 2016-02-25 (Thu, 25 Feb 2016) Changed paths: M S17-concurrency.pod Log Message: --- Update Supply introduction and method docs for serial supplies Also some Channel clarifications. Commit: cc534c403199b0804fe05bd5cb88676142a878a1 https://github.com/perl6/specs/commit/cc534c403199b0804fe05bd5cb88676142a878a1 Author: skids Date: 2016-02-26 (Fri, 26 Feb 2016) Changed paths: M S17-concurrency.pod Log Message: --- A start on design doc for react/supply blocks and whenever clauses This will need quite more work. Compare: https://github.com/perl6/specs/compare/b10af0c10726...cc534c403199
[perl6/specs] 6e8b79: Move introduction of outcome {} after Channel
Branch: refs/heads/master
Home: https://github.com/perl6/specs
Commit: 6e8b79ef06d6f6acb7a7a5324156405117f8bbc9
https://github.com/perl6/specs/commit/6e8b79ef06d6f6acb7a7a5324156405117f8bbc9
Author: Elizabeth Mattijsen
Date: 2014-04-06 (Sun, 06 Apr 2014)
Changed paths:
M S17-concurrency.pod
Log Message:
---
Move introduction of outcome {} after Channel
The way it was, we're starting to discuss Channels in the context of outcome
before we specced what a Channel is.
[perl6/specs] 70f396: Introduction of "supersedes" and "superseded_by"
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 70f396ae06de5bb859ac6d8ee8a87825446ffd3b https://github.com/perl6/specs/commit/70f396ae06de5bb859ac6d8ee8a87825446ffd3b Author: Elizabeth Mattijsen Date: 2014-03-15 (Sat, 15 Mar 2014) Changed paths: M S11-modules.pod Log Message: --- Introduction of "supersedes" and "superseded_by" And some other minor clarifications.
[perl6/specs] e3bc30: Mangle the introduction into a "real" S17 intro
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: e3bc30c8b2ec73cda8fe7b4bf45d1b7d1a90cf98 https://github.com/perl6/specs/commit/e3bc30c8b2ec73cda8fe7b4bf45d1b7d1a90cf98 Author: Elizabeth Mattijsen Date: 2013-11-03 (Sun, 03 Nov 2013) Changed paths: M S17-concurrency.pod Log Message: --- Mangle the introduction into a "real" S17 intro
Re: Introduction to Synopses
On 09/30/2013 02:16 AM, Patrick R. Michaud wrote: On Mon, Sep 30, 2013 at 02:03:43AM +0800, Richard Hainsworth wrote: Not wising to disagree with PM, but "|docs/feather/syn_index.html" states on line 1:| "The Synopsis documents are to be taken as the formal specification for Perl 6 implementations" What follows is just my opinion, there's plenty of room for reasonable disagreement. It would be useful at some stage to come to a consensus about how to describe Perl6. Over the last couple of years I've come to disagree with this statement in syn_index.html . Informally we often talk about the synopses as being "the official spec", and I'm as guilty of that as anyone else. Larry Wall's ideas about language development differ from the paradigm that existed before. In one of the paradigms, a language designer creates a specification (eg. C) and then an implementation is created. This leads to the necessity for very tedious and specific specs. As pointed out in Synopsis 1, it implies perfect knowledge before the language has been created. What's new here is the three different components all moving together, and also that the language is defined in terms of both the specification and the tests. In the "traditional" sense, the specification of Perl6 is the combination of Synopses and Test Suite. But the Synopses on their own do not define Perl6, as you have pointed out. What I have suggested is to use another word "describe" (or perhaps "define" might be better) instead of "specify". "Specification" has been used in the Perl6 community to mean the Synopses so I suggest keeping that identity. However, we use another word to describe the combination. Even the name of the repository holding the synopses is given as "specs". But as all of us know, some parts of the synopses are incredibly slushy, or even quite fluid, and so it's not something that people can really treat as truly "specification". And there are countless parts of the synopses that have radically changed as a result of lessons learned in implementation... (I can tell long stories about S05!). Thus it was recognized early on (in Synopsis 1) that acceptance tests provide a far more objective measure of specification conformance than an English description. There are likely things that need to be "spec" that cannot be fully captured by testing... but I still believe that the test suite should be paramount. Perl6 language development is a gradual change of specification, test suite and implementation until the specification is proven by implementations, which all pass the test suite, for some sense of 'proven' and some set of 'implementations'. A "version" of Perl6 is "described" by the combination of a "specification suite" and a "test suite". I'd prefer that versions of Perl 6 be captured solely by the test suite. I don't know how practical this is, though. I don't like the notion of "specification suite"... it feels too nebulous to me. A version of Perl6 is declared to be ready when there is at least one full implementation exists that generates code considered to be sufficiently fast and memory efficient. I also don't like the idea of defining "readiness" in the abstract. Something is "ready" when it is capable of solving the problem(s) to which it is being put. When is can a version of Perl6 be considered to have evolved? Rakudo is already being used to solve problems. I have used it to solve problems. Maybe not a vast range of problems, nor is the speed impressive. A language is in itself an abstract thing. Pm
Re: Introduction to Synopses
On Mon, Sep 30, 2013 at 02:03:43AM +0800, Richard Hainsworth wrote: > Not wising to disagree with PM, but "|docs/feather/syn_index.html" > states on line 1:| > "The Synopsis documents are to be taken as the formal specification > for Perl 6 implementations" What follows is just my opinion, there's plenty of room for reasonable disagreement. Over the last couple of years I've come to disagree with this statement in syn_index.html . Informally we often talk about the synopses as being "the official spec", and I'm as guilty of that as anyone else. Even the name of the repository holding the synopses is given as "specs". But as all of us know, some parts of the synopses are incredibly slushy, or even quite fluid, and so it's not something that people can really treat as truly "specification". And there are countless parts of the synopses that have radically changed as a result of lessons learned in implementation... (I can tell long stories about S05!). Thus it was recognized early on (in Synopsis 1) that acceptance tests provide a far more objective measure of specification conformance than an English description. There are likely things that need to be "spec" that cannot be fully captured by testing... but I still believe that the test suite should be paramount. > Perl6 language development is a gradual change of specification, > test suite and implementation until the specification is proven by > implementations, which all pass the test suite, for some sense of > 'proven' and some set of 'implementations'. > > A "version" of Perl6 is "described" by the combination of a > "specification suite" and a "test suite". I'd prefer that versions of Perl 6 be captured solely by the test suite. I don't know how practical this is, though. I don't like the notion of "specification suite"... it feels too nebulous to me. > A version of Perl6 is declared to be ready when there is at least > one full implementation exists that generates code considered to be > sufficiently fast and memory efficient. I also don't like the idea of defining "readiness" in the abstract. Something is "ready" when it is capable of solving the problem(s) to which it is being put. Pm
Re: Introduction to Synopses
Not wising to disagree with PM, but "|docs/feather/syn_index.html"
states on line 1:|
"The Synopsis documents are to be taken as the formal specification for
Perl 6 implementations"
I have seen elsewhere, can't remember where, that the parser written by
Larry is also considered a part of the specification. Is this correct?
From Synopsis 1:
"Perl 6 is anything that passes the official test suite"
"hacking on any implementation of Perl 6 to make it conform to the test
suite"
"... hacking on the test suite to make it reflect consensus of
specification"
"parts of the spec are already effectively frozen"
"...specced features ... not ... proven in an implementation ...
considered ... conjectural"
May I suggest we add the following language to Synopsis 1 to capture all
these statements?
Perl6 language development is a gradual change of specification, test
suite and implementation until the specification is proven by
implementations, which all pass the test suite, for some sense of
'proven' and some set of 'implementations'.
A "version" of Perl6 is "described" by the combination of a
"specification suite" and a "test suite".
The "specification suite" consists of the Synopses and the parser
written in Perl6
A "full" implementation generates code that passes the entire test suite.
A version of Perl6 is declared to be ready when there is at least one
full implementation exists that generates code considered to be
sufficiently fast and memory efficient.
On 09/29/2013 09:13 PM, Patrick R. Michaud wrote:
On Sun, Sep 29, 2013 at 01:28:48PM +0800, Richard Hainsworth wrote:
However, the Synopses are now primary specification and the
Apocalypses have only historical significance. Also there are more
Synopses than Apocalypses.
One correction: The test suite ("roast") is the primary specification
(see Synopsis 1).
To me, the Synopses are the English description of our understanding
of the specification / language, as well as a roadmap for growth in the
future.
Pm
Re: Introduction to Synopses
On Sun, Sep 29, 2013 at 01:28:48PM +0800, Richard Hainsworth wrote:
> However, the Synopses are now primary specification and the
> Apocalypses have only historical significance. Also there are more
> Synopses than Apocalypses.
One correction: The test suite ("roast") is the primary specification
(see Synopsis 1).
To me, the Synopses are the English description of our understanding
of the specification / language, as well as a roadmap for growth in the
future.
Pm
Re: Introduction to Synopses
Hi Richard, On 09/29/2013 07:28 AM, Richard Hainsworth wrote: > Some suggestions about documentation. > > Originally the Synopses were implementation oriented sumaries of the > previous description base Apocalypses. That meant that the Synopses were > derivative and secondary to the Apocalypses > > However, the Synopses are now primary specification and the Apocalypses > have only historical significance. Also there are more Synopses than > Apocalypses. > > I suggest the introductory paragraphs to the Synopses are changed to > reflect this. A good idea. Please do it! The page you're probably think of is in the perl6/mu repo on github in the file docs/feather/syn_index.html. If you have a github user name, please tell me, and I can give you commit access. Cheers, Moritz
Introduction to Synopses
Some suggestions about documentation. Originally the Synopses were implementation oriented sumaries of the previous description base Apocalypses. That meant that the Synopses were derivative and secondary to the Apocalypses However, the Synopses are now primary specification and the Apocalypses have only historical significance. Also there are more Synopses than Apocalypses. I suggest the introductory paragraphs to the Synopses are changed to reflect this. It might also be useful to have a Synopsis 0 or Synopsis - index that documents the historical progression and indexes the Synopses. For completeness of language specification, Synopsis 0 could list the other documents that form a part of the language definition, such as the test suite.
Introduction to Parrot Virtual Machine
Howdy, Here are various digital representations of my recent "Introduction to Parrot VM" talk that I gave to the Portland Perl Mongers (PDX.pm): mp3: http://pdxpm.podasp.com/archive.html?pname=meetings.xml video : http://www.ustream.tv/recorded/4630503 slides : http://docs.google.com/present/view?id=dk89d5g_193ngx26cw If you have further questions or want to get involved in any of the projects that I mentioned, feel free to contact me off-list. Enjoy! -- Jonathan "Duke" Leto jonat...@leto.net http://leto.net
[Parrot] New comment on Episode 1: Introduction.
Taweth has left a new comment on your post "Episode 1: Introduction": It seems that recent changes have altered the behaviour of the mk_language_shell script. If anyone else finds themselves without a Makefile once they run this, the fix is to run the command without the path on the end (eg: "perl tools/dev/mk_language_shell.pl Squaak") Posted by Taweth to Parrot at July 26, 2008 1:15 PM
Re: Introduction
On Fri, Dec 16, 2005 at 12:11:45AM -0800, David Romano ([EMAIL PROTECTED]) wrote: > progress: how > do I get a perl.org subversion account? Is that after the module > author accepts the proposal? I can set you up with the svn.perl.org access. You need an account on perl.org, and then you'll tell me what project you want set up. Let us know how it goes! We're glad to have you join us. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Introduction
Hi y'all, I signed up for this mailing list a few days ago with interest in participating in the Phalanx Project. I'm a part of SanDiego.pm and sent an e-mail yesterday to see if anyone else in San Diego wants to also help out. Anyway, I'm using the ContactTheAuthor template (from the kwiki) to construct the message below, and want some feedback on if it's adequate or not. Also, I noticed the template mention another mailing list for the module author to keep track of progress: how do I get a perl.org subversion account? Is that after the module author accepts the proposal? I've been sifting throught the archives of this mailing list, trying to get a bit more of a background of what's being done already. Should I start by doing something else initially? Anyway, if anyone could steer me in the right direction I'd appreciate it. Thanks, David -- Subject: Mail::Sendmail and the Phalanx Project Milivoj Ivkovic, My name is David Romano and I've joined the Phalanx project. The Phalanx project has three goals: 1. Strengthen CPAN's tests, coverage and documentation 2. Strengthen Perl's tests and coverage 3. Bring in newcomers to the Perl development process When Ponie was announced in July 2003, we knew that it would require a regression test suite larger than Perl had ever had before. Fortunately, with the CPAN, we have a huge selection to choose from. Based on the assumption that the 80/20 rule holds true for CPAN usage, we shifted it to the 98/2 rule. We're hoping that the 100 distributions we've selected, mostly on rough statistical analysis of usage, will cover a huge part of the CPAN that's used by the Perl community. http://qa.perl.org/phalanx/ As a member of the Phalanx Project, I want to work on Mail::Sendmail, a module you currently maintain. What does this mean for you? Free patches! Our goal is to bring your module's test coverage as close to 100% as possible. We'll be writing tests, fixing bugs as they're found, and documenting things as we go. We can send you patches as we make changes, or one big patch when we're done. It's completely up to you. If I get your okay, I'll start a group so that others can help out if they want to. If you would like to join in the fun, just let me know. We'll be coordinating efforts in our group's repository and mailing list. A second list has been set up for commit notices, so you can track what we're doing with a minimum of effort. I'll supply all the necessary information if you're interested. I look forward to hearing back from you. Thank you for maintaining Mail::Sendmail. On behalf of the Phalanx Project, I hope you'll accept our offer of assistance. David Romano
Re: introduction
Comrade Burnout wrote: I remember seeing that the list-joining thingie mentioned an introduction once someone joined, so here it is: I'm geektron on perlmonks, and Brian Clarkson IRL. I've talked a bit to Mr. Lester and Mr. Kinyon about tests, and decided that learning some good testing skills while doing something useful added up to joining this list and the Phalanx project. I'm not sure where to start other than this. So "hi" and stuff. Re: Phalanx: If you're interested in working on this in an F2F manner (other hoplites in the same room!), sign up on the HereToHelp page of the Phalanx kwiki (http://phalanx.kwiki.org/index.cgi?HereToHelp) and indicate what city or metro area you live in. Or hook up with one of the local Perlmonger groups listed on the kwiki home page if you're in one of those areas. Jim Keenan
Re: introduction
Comrade Burnout wrote: I'm not sure where to start other than this. So "hi" and stuff. Hi, Brian. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
introduction
I remember seeing that the list-joining thingie mentioned an introduction once someone joined, so here it is: I'm geektron on perlmonks, and Brian Clarkson IRL. I've talked a bit to Mr. Lester and Mr. Kinyon about tests, and decided that learning some good testing skills while doing something useful added up to joining this list and the Phalanx project. I'm not sure where to start other than this. So "hi" and stuff. Brian
[perl #19872] Fwd: Re: Introduction and cygwin results
# New Ticket Created by James Michael DuPont # Please include the string: [perl #19872] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19872 > Missing header file for cygwin --- James Michael DuPont <[EMAIL PROTECTED]> wrote: > From James Michael DuPont Fri Jan 3 11:01:39 2003 > Received: from [194.202.25.243] by web13307.mail.yahoo.com via HTTP; > Fri, 03 Jan 2003 11:01:39 PST > Date: Fri, 3 Jan 2003 11:01:39 -0800 (PST) > From: James Michael DuPont <[EMAIL PROTECTED]> > Subject: Re: Introduction and cygwin results > To: [EMAIL PROTECTED] > In-Reply-To: <[EMAIL PROTECTED]> > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Length: 978 > > > --- James Michael DuPont <[EMAIL PROTECTED]> wrote: > > Hi There! > > > [SECTION PACKDUMP] > > make packdump.exe > > packdump.c: In function `PackFile_Constant_dump': > > packdump.c:111: structure has no member named `flags' > > make: *** [packdump.o] Error 1 > > > > I have commented that out for now : > > /*PIO_printf(interpreter, "FLAGS=> > > 0x%04lx,\n", > >(long)self->string->flags); > > */ > > Oopps : more then that : > pdump.c: In function `main': > pdump.c:21: storage size of `file_stat' isn't known > pdump.c:37: `O_RDONLY' undeclared (first use in this function) > pdump.c:37: (Each undeclared identifier is reported only once > pdump.c:37: for each function it appears in.) > > under cygwin you need : > #include > > > mike > > > = > James Michael DuPont > http://introspector.sourceforge.net/ > > __ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
[perl #19871] Fwd: Introduction and cygwin results
# New Ticket Created by James Michael DuPont # Please include the string: [perl #19871] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19871 > Attached is the bug report and test results for parrot on cygwin. --- James Michael DuPont <[EMAIL PROTECTED]> wrote: > From James Michael DuPont Fri Jan 3 10:51:37 2003 > Received: from [194.202.25.243] by web13305.mail.yahoo.com via HTTP; > Fri, 03 Jan 2003 10:51:37 PST > Date: Fri, 3 Jan 2003 10:51:37 -0800 (PST) > From: James Michael DuPont <[EMAIL PROTECTED]> > Subject: Introduction and cygwin results > To: [EMAIL PROTECTED] > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Length: 2374 > > Hi There! > > My name is Mike, and I have decided to pick up on the parrot again. > You > seem to be making good progress, let me help you test this thing and > build some interfaces to other programs. > > Can someone tell me if anyone uses packdump from cvs? is that an > equivalent to ildasm in dotnet? It seems to be broken. > Can I dump an set of instructions from a program into a file, and > reassemble them? > If not, is there a way to dump a parrot program? > > Is there a way to capture the line number, and comments of a perl6 > program in parrot? What about high level type information? > > I am interested in building a interface from parrot into the > introspector, that will give you a way to convert your programs > internals into RDF/XML and visualize and manipulate them via the GUI. > > I am using the redland perl api, and would like to link that into > parrot. > > We are freezing the gcc interface soon, and because the introspector > is > mostly writtten in perl, I think that parrot would be the next step. > > I would be willing to port my code to the subset of perl/parrot that > is > currently supported, where I can i find that? > > Here is my first test results with parrot under cygwin : > [SECTION GCC -V] compiler version > [SECTION MAKE TEST] results of maketest > [SECTION PACKDUMP] compiling error in packdump > running examples : > [SECTION MOPS] > [SECTION LIFE] > > Mike > > [SECTION GCC -v] > gcc -v : > Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs > Configured with: /netrel/src/gcc-3.2-3/configure --enable > languages=c,c++,f77,java --enable-libgcj --enable-threads=posix > --with-system-zlib --enable-nls --without-included-gettext > --enable-interpreter --disable-sjlj-exceptions > --disable-version-specific-runtime-libs --enable-shared > --build=i686-pc-linux --host=i686-pc-cygwin --target=i686-pc-cygwin > --enable-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc > --libdir=/usr/lib --includedir=/nonexistent/include > --libexecdir=/usr/sbin > Thread model: posix > gcc version 3.2 20020927 (prerelease) > > [SECTION MAKE TEST] > perl t/harness --gc-debug --running-make-test > t/src/basic.ok > t/src/exit..ok > t/src/intlist...ok > t/src/list..ok > t/src/manifest..ok > t/src/sprintf...ok > t/op/basic..ok > t/op/bitwiseok > t/op/comp...ok > t/op/conv...ok > t/op/debuginfo..ok > t/op/gc.ok > t/op/globalsok > t/op/hacks..ok > t/op/ifunless...ok > t/op/jitok > t/op/jitn...ok > t/op/lexicals...ok > t/op/macro..ok, 1/15 skipped: Await exceptions > t/op/number.ok > t/op/rx.ok, 1/23 skipped: Pending some sort of > lowercasing > op > t/op/stacks.ok, 1/35 skipped: Await exceptions > t/op/string.ok > t/op/time...ok > t/op/trans..ok > t/op/types..ok > t/pmc/array.ok > t/pmc/boolean...ok > t/pmc/intlist...ok > t/pmc/multiarrayok > t/pmc/nci...ok, 11/11 skipped: needs jit/i386 and libnci.so > t/pmc/perlarray.ok > t/pmc/perlhash..ok > t/pmc/perlint...ok, 1/5 skipped: add_keyed: not yet > t/pmc/perlstringok, 1/8 skipped: Pending new version of > concat_p_p_s > t/pmc/pmc...ok 31/80# Failed test (t/pmc/pmc.t at line > 491) > # got: '2.70 > # ' > # expected: 'bar2.70 > # ' > t/pmc/pmc...ok 79/80# Looks like you failed 1 tests of 80. > t/pmc/pmc...dubious > Test returned status 1 (wstat 256, 0x100) > DIED. FAILED test 32 > Failed 1/80 tests, 98.75% okay (-2 skipped tests: 77 okay, > 96.25%) > t/pmc/prop..ok > t/pmc/scratchpadok > t/pmc/sub...ok > Failed Test Status Wstat Total Fail Failed List of Failed >
Re: Introduction and cygwin results
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:51 AM -0800 1/3/03, James Michael DuPont wrote:
> >Can someone tell me if anyone uses packdump from cvs? is that an
> >equivalent to ildasm in dotnet? It seems to be broken.
> >Can I dump an set of instructions from a program into a file, and
> >reassemble them?
> >If not, is there a way to dump a parrot program?
>
> Not that I know of, I think so, damn, you should be able to, and no
> no other way.
Here is my patch for pdump :
But the pdump does not disassemble... i have to look into
dissassemble.pl
Index: packdump.c
===
RCS file: /cvs/public/parrot/packdump.c,v
retrieving revision 1.6
diff -u -r1.6 packdump.c
--- packdump.c 2 Nov 2002 14:57:47 - 1.6
+++ packdump.c 4 Jan 2003 16:18:37 -
@@ -107,8 +107,13 @@
case PFC_STRING:
PIO_printf(interpreter, "[ 'PFC_STRING', {\n");
-PIO_printf(interpreter, "FLAGS=> 0x%04lx,\n",
+
+#ifdef HAS_parrot_string_t_flags
+
+PIO_printf(interpreter, "FLAGS=>
0x%04lx,\n",
(long)self->string->flags);
+#endif
+
PIO_printf(interpreter, "ENCODING => %s,\n",
self->string->encoding->name);
PIO_printf(interpreter, "TYPE => %s,\n",
Anyone working on cross compiling? I have a setup here for cross
compiling from debian to windows, but always use autoconf to do that.
Anyone have an idea?
>
> >Is there a way to capture the line number, and comments of a perl6
> >program in parrot? What about high level type information?
>
> Line number, yes. Comments, probably not, though it's possible that
> info can get embedded. What type of high-level info are you looking
> for? We've all sorts. :)
well as much as you can give me.
> Seriously, if you're looking for variable
> type info, it'll potentially be there, assuming that it's not been
> stripped out.
OK, that is good.
>
> >I would be willing to port my code to the subset of perl/parrot that
> is
> >currently supported, where I can i find that?
>
> Perl 6 is in languages/perl6, though I think that there's still some
> stuff missing.
Well, I will try that out. Thanks,
mike
=
James Michael DuPont
http://introspector.sourceforge.net/
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: Introduction and cygwin results
At 10:51 AM -0800 1/3/03, James Michael DuPont wrote: Can someone tell me if anyone uses packdump from cvs? is that an equivalent to ildasm in dotnet? It seems to be broken. Can I dump an set of instructions from a program into a file, and reassemble them? If not, is there a way to dump a parrot program? Not that I know of, I think so, damn, you should be able to, and no no other way. Is there a way to capture the line number, and comments of a perl6 program in parrot? What about high level type information? Line number, yes. Comments, probably not, though it's possible that info can get embedded. What type of high-level info are you looking for? We've all sorts. :) Seriously, if you're looking for variable type info, it'll potentially be there, assuming that it's not been stripped out. I would be willing to port my code to the subset of perl/parrot that is currently supported, where I can i find that? Perl 6 is in languages/perl6, though I think that there's still some stuff missing. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Introduction and cygwin results
--- James Michael DuPont <[EMAIL PROTECTED]> wrote: > Hi There! > [SECTION PACKDUMP] > make packdump.exe > packdump.c: In function `PackFile_Constant_dump': > packdump.c:111: structure has no member named `flags' > make: *** [packdump.o] Error 1 > > I have commented that out for now : > /*PIO_printf(interpreter, "FLAGS=> > 0x%04lx,\n", >(long)self->string->flags); > */ Oopps : more then that : pdump.c: In function `main': pdump.c:21: storage size of `file_stat' isn't known pdump.c:37: `O_RDONLY' undeclared (first use in this function) pdump.c:37: (Each undeclared identifier is reported only once pdump.c:37: for each function it appears in.) under cygwin you need : #include mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Introduction and cygwin results
Hi There! My name is Mike, and I have decided to pick up on the parrot again. You seem to be making good progress, let me help you test this thing and build some interfaces to other programs. Can someone tell me if anyone uses packdump from cvs? is that an equivalent to ildasm in dotnet? It seems to be broken. Can I dump an set of instructions from a program into a file, and reassemble them? If not, is there a way to dump a parrot program? Is there a way to capture the line number, and comments of a perl6 program in parrot? What about high level type information? I am interested in building a interface from parrot into the introspector, that will give you a way to convert your programs internals into RDF/XML and visualize and manipulate them via the GUI. I am using the redland perl api, and would like to link that into parrot. We are freezing the gcc interface soon, and because the introspector is mostly writtten in perl, I think that parrot would be the next step. I would be willing to port my code to the subset of perl/parrot that is currently supported, where I can i find that? Here is my first test results with parrot under cygwin : [SECTION GCC -V] compiler version [SECTION MAKE TEST] results of maketest [SECTION PACKDUMP] compiling error in packdump running examples : [SECTION MOPS] [SECTION LIFE] Mike [SECTION GCC -v] gcc -v : Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs Configured with: /netrel/src/gcc-3.2-3/configure --enable languages=c,c++,f77,java --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --without-included-gettext --enable-interpreter --disable-sjlj-exceptions --disable-version-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecdir=/usr/sbin Thread model: posix gcc version 3.2 20020927 (prerelease) [SECTION MAKE TEST] perl t/harness --gc-debug --running-make-test t/src/basic.ok t/src/exit..ok t/src/intlist...ok t/src/list..ok t/src/manifest..ok t/src/sprintf...ok t/op/basic..ok t/op/bitwiseok t/op/comp...ok t/op/conv...ok t/op/debuginfo..ok t/op/gc.ok t/op/globalsok t/op/hacks..ok t/op/ifunless...ok t/op/jitok t/op/jitn...ok t/op/lexicals...ok t/op/macro..ok, 1/15 skipped: Await exceptions t/op/number.ok t/op/rx.ok, 1/23 skipped: Pending some sort of lowercasing op t/op/stacks.ok, 1/35 skipped: Await exceptions t/op/string.ok t/op/time...ok t/op/trans..ok t/op/types..ok t/pmc/array.ok t/pmc/boolean...ok t/pmc/intlist...ok t/pmc/multiarrayok t/pmc/nci...ok, 11/11 skipped: needs jit/i386 and libnci.so t/pmc/perlarray.ok t/pmc/perlhash..ok t/pmc/perlint...ok, 1/5 skipped: add_keyed: not yet t/pmc/perlstringok, 1/8 skipped: Pending new version of concat_p_p_s t/pmc/pmc...ok 31/80# Failed test (t/pmc/pmc.t at line 491) # got: '2.70 # ' # expected: 'bar2.70 # ' t/pmc/pmc...ok 79/80# Looks like you failed 1 tests of 80. t/pmc/pmc...dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 32 Failed 1/80 tests, 98.75% okay (-2 skipped tests: 77 okay, 96.25%) t/pmc/prop..ok t/pmc/scratchpadok t/pmc/sub...ok Failed Test Status Wstat Total Fail Failed List of Failed --- t/pmc/pmc.t1 256801 1.25% 32 18 subtests skipped. Failed 1/42 test scripts, 97.62% okay. 1/584 subtests failed, 99.83% okay. make: *** [test_dummy] Error 2 [SECTION PACKDUMP] make packdump.exe packdump.c: In function `PackFile_Constant_dump': packdump.c:111: structure has no member named `flags' make: *** [packdump.o] Error 1 I have commented that out for now : /*PIO_printf(interpreter, "FLAGS=> 0x%04lx,\n", (long)self->string->flags); */ [SECTION MOPS] $ ./examples/mops/mops.exe Iterations:1 Estimated ops: 2 Elapsed time: 0.784000 M op/s:255.102028 [SECTION LIFE] $ examples/assembly/life.exe .. 5000 generations in 6.707000 seconds. 745.489785 generations/sec A total of 460064 bytes were allocated A total of 14 DOD runs were made A total of 93 collection runs were made Copying a total of 13534560 bytes There are 471 active Buffer structs There are 6400 total Buffer structs = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Introduction, I suppose.
Oops. ;-)) And I thought I was on a roll, contributing to the Perl 6 source core thingy... LOL Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote: > On Wed, Nov 15, 2000 at 11:55:27AM +, Simon Cozens wrote: > > On Wed, Nov 15, 2000 at 03:29:24AM +, David Grove wrote: > > > If this should be a PDD, I'll be happy to propose it that way, but I > will > > > need some slight help in the specific implementation of the C code that > > > does it. > > > > I may have misunderstood the purpose of this group, but it's *API*, which > > means we're not (yet) designing how the parser acts or is implemented, > but > > The parser acts and is implemented in a fast, compact, and clean way :-) > > > we're merely talking about how it communicates with the rest of Perl. So > I > > think we're expecting to see things along the lines of: > > OP* parse(SV *); /* Parse a piece of code, return op tree */ > > > > void parse_add_hook(int level, FPTR function, void* data); > > /* Add a hook (function) to be called at level (level) of parsing */ > > Yes, that's the kind of stuff we are after. > > -- > $jhi++; # http://www.iki.fi/jhi/ > # There is this special biologist word we use for 'stable'. > # It is 'dead'. -- Jack Cohen >
Re: Introduction, I suppose.
On Wed, Nov 15, 2000 at 11:55:27AM +, Simon Cozens wrote: > On Wed, Nov 15, 2000 at 03:29:24AM +, David Grove wrote: > > If this should be a PDD, I'll be happy to propose it that way, but I will > > need some slight help in the specific implementation of the C code that > > does it. > > I may have misunderstood the purpose of this group, but it's *API*, which > means we're not (yet) designing how the parser acts or is implemented, but The parser acts and is implemented in a fast, compact, and clean way :-) > we're merely talking about how it communicates with the rest of Perl. So I > think we're expecting to see things along the lines of: > OP* parse(SV *); /* Parse a piece of code, return op tree */ > > void parse_add_hook(int level, FPTR function, void* data); > /* Add a hook (function) to be called at level (level) of parsing */ Yes, that's the kind of stuff we are after. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Introduction, I suppose.
On Wed, Nov 15, 2000 at 03:29:24AM +, David Grove wrote: > If this should be a PDD, I'll be happy to propose it that way, but I will > need some slight help in the specific implementation of the C code that > does it. I may have misunderstood the purpose of this group, but it's *API*, which means we're not (yet) designing how the parser acts or is implemented, but we're merely talking about how it communicates with the rest of Perl. So I think we're expecting to see things along the lines of: OP* parse(SV *); /* Parse a piece of code, return op tree */ void parse_add_hook(int level, FPTR function, void* data); /* Add a hook (function) to be called at level (level) of parsing */ Have patience. :) -- The angels want to wear my red shoes.
Introduction, I suppose.
No traffic yet, so I suppose I'll open with a couple statements and a couple questions. First of all, do we talk, or submit PDDs? Are we aiming for a single PDD from this group, or a short number of them, or a short number to be collated into one? I'm not quite clear how this works, and what we end up with. The official definition from ask seemed to indicate that we're wanting to end up with one, but the later definition seemed to indicate the opposite... that we might end up with more than one PDD per working group. Ok, statements are, I've been working on something that may be of some assistance at least in testing the perl parsing. Based on Larry's notion of perl parsing perl, I've begun to work on a perl (not a fork, not a module, somewhere inbetween) that makes perl OOP easier to write and read. (I'm considering creating an actual application in Perl, and don't want the hassle of the perl OOP verbosity, so I shorthanded it to make it easier to write, read, maintain, and comprehend.) The basic idea is to take Perl 5 and stick in a parsing script embedded as a char*, let the perl executable parse that since it's compiled in, import the script to be run, run it through the parser, and eval it. (Two interpreters are at work, the one that runs the parser, and the one that runs the parsed script.) This is all in C naturally, compiled into the perl executable. I think this would be helpful in testing whatever theories we come up with, given that we don't have a perl6 to do any real tests with. Basically, in other words, it's a perl executable with a compiled-in script that preprocesses then evals the script to be run. The preprocessing script could serve as a testing ground for whatever we choose to come up with. It "translates" the syntax I've come up with into much longer but actual perl code. No, I'm not going to put the OOP grammar up here for a syntax proposal, that's not what I'm offering. Just the concept of a parser testing method. Frankly, this method could virtually be used to build up a working perl6 parser even before perl6 is ready to parse anything. Once we have a language definition, the parsing algo's should be flexible enough to match the differences between perl5's implementation and perl 6's. What concerns me here is the need to keep things flexible enough to handle _multiple_ ways of parsing. Like larry said, if people want to write perl in python, they should... we can test that without needing perl6, as scary as it sounds. This might be a good point... if we can be flexible enough to handle the transition from perl5 to perl6, we might be able to come up with a parser that understands visual forth... It seems that our parsing job is less one of strict grammatical recognition and more one of providing the general capability of providing strict grammatical recognition to come up with a common language (perl 6), that (off topic) could eventually be written out as other code for Java, C#, etc. IOW less of a translator and more of a how-to-translate kind of thing. Less of mapping syntax to opcode, but of mapping syntactic alternatives to grammar that would be mapped to opcode (or later, maybe skip the middle step), if that makes any sense. So we would have somewhat of a three-way translation to opcode... 1. \bclass\b\s+ => \bpackage\b\s+ => opcode 2. \bdef\b\s+ => \bsub\b\s+ => opcode 3. \bfunc\b\s+ => \bsub\b\s+ => opcode 4. \bsub\b\s+ => \bsub\b\s+ => opcode 5. \bvar\b\s+ => \bmy\b\s+ => opcode Where 2, 3, and 4 express the same thing, depending on how the parser-writer wanted to write it... perl style, python style, or tcl style. The gist being that several alternative modes of self expression translate to the same perl concept which translates directly to perl internals. Since those internals aren't invented yet, it might be beneficial to concentrate on the modes of self expression translating to some form of commonality that exists at a higher level than opcode, even if it eventually translates to opcode in perl6. If we can translate it to perl 5 for testing, we can translate it to perl6 opcode later for implementation. The key here being the flexibility of the parsing mechanism. It also makes sense to test the thing initially using pure perl, whereas the eventual perl parsing mechanisms would probably not be embedded perl but perl api itself translating the modes into perl opcode proper. I don't think it would be a good testbed to use existing perl api rather than embedded perl code within the executable, if for no other reason than that it would take longer to write and our fingers would get sore. (My vocabulary is lacking, I do confess.) If this should be a PDD, I'll be happy to propose it that way, but I will need some slight help in the specific implementation of the C code that does it. I've just about got it going, and if I hadn't seen some funky new grammar in the Camel III that bummed me out for a couple of days would probably have been complete. As for parsing, are
