Re: [CAGE] Coverity and Split: Has anyone started using these with Parrot?
On Tuesday 11 July 2006 22:49, Kevin Tew wrote: Has anyone done anything about coverity, whats the next course of action? I'd be happy to send off an email and start a conversation with coverity if that is what is needed. I talked to them after their first big announcement. They'll look into adding Parrot for their next stage of tests. -- c
Re: TAP diagnostic syntax proposal
* Adam Kennedy [EMAIL PROTECTED] [2006-07-12 06:10]: Fair enough a Layer 1 TAP parser might not care, but why not make it as equally easy to implement a Layer 2 parser as well. +1 Did you guys consider the problem of newlines in content? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: TAP Namespace Nonproliferation Treaty
Ian Langworth writes: Ovid: TAP::Parser::Pedantic Schwern: TAP::Parser::Heuristic That's the best idea: nobody claiming that his particular parser is _the_ TAP::Parser (or even _the_ TAPx::Parser), but giving them parallel names with adjectives that hint at ways in which they differ. Even if the hints are obscure it's better than just having arbitrary different names. At least, nobody claim that namespace _yet_. A few years down the line we might've collectively learnt enough that we bless one particular parser as canonical, or perhaps we'll make TAP::Parser be a front end multiplexer for picking which parser to load. I've always feared /^[A-Z]+x::/ namespaces because I never understood them. They make sense in some circumstances, where there is a well defined project or system which itself is spread across several modules, and other folk wish to contribute modules which are not part of that system but are extensions to it. But ... I don't think that applies here; it isn't that there's a core Tap system and a clear distinction between that and extensions to it, and I think it would just get confusing trying to remember which are TAP:: and which are TAPx:: modules. Smylers
Re: [svn:perl6-synopsis] r10077 - doc/trunk/design/syn
[EMAIL PROTECTED] commits: New Revision: 10077 Modified: doc/trunk/design/syn/S02.pod == -foo.bar # foo().bar -- postfix prevents args +foo.bar # foo().bar -- illegal postfix, must use foo().bar foo .bar # foo($_.bar) -- no postfix starts with whitespace I don't think it makes much sense to start the comments with an alternate form for the expressions now denoted as illegal -- here's some other syntax which this used to be the same as but it no longer is probably only confuses the casual reader. Smylers
fetching module version from the command line
While checking if the versions of all the modules are as required in our installation I am using the following one liner to fetch the version numbers. perl -MModule -e'print $Module::VERSION' Some of the modules print extra error messages and some print only error messages. I have sent e-mail to the respective module authors reporting this issue but I wonder if it would this a good practice in the genric case. Is there a Test module that test just the above? Is the a CPANST score one can get if all the modules in a distro provide the correct version information and if they don't print anything else to STDOUT or STDERR. Gabor
Re: fetching module version from the command line
On 7/12/06, Gabor Szabo [EMAIL PROTECTED] wrote:
While checking if the versions of all the modules are as
required in our installation I am using the following one liner to
fetch the version numbers.
perl -MModule -e'print $Module::VERSION'
This one-liner doesn't work all the time in modules with deep magic
(filters and modules which do strange/heavy things in BEGIN blocks,
POD-only modules and the like). A (text-based) alternative is the
ExtUtils::MakeMaker approach, which goes as follows:
perl -MExtUtils::MakeMaker -e 'print MM-parse_version(shift)'
/usr/lib/perl5/site_perl/5.8/Module.pm
Unfortunately, it depends on knowing where the .pm file is. But that
can be arranged.
Some of the modules print extra error messages and some print
only error messages.
I have sent e-mail to the respective module authors reporting this
issue but I wonder if it would this a good practice in the genric case.
I think that having version numbers is a good practice. Although to
demand they may be retrieved with perl -MModule -e 'print
$Module::VERSION' may be too much - don't forget that it means the
module should compile and certain modules may demand a bunch of
environment settings to do it (the right libraries, some bit of
configuration, etc.)
Is there a Test module that test just the above?
Is the a CPANST score one can get if all the modules in a distro
provide the correct version information and if they don't print anything
else to STDOUT or STDERR.
I think a test to check version numbers are provided is enough.
Another issue is that use_ok() (or some variant) works too (in a
silent fashion). As a matter of fact, the absence of version numbers
is very common for modules which are not the ones that provide the
version number for a CPAN distribution - you may see this at many
places: core modules and many others. For example, trying the YAML::*
modules installed in a Cygwin machine with which_pm (from Module-Which
distribution) gives me (module name, version, location):
$ which_pm YAML:: --p5p
YAML::Syck 0.45 at ${installsitearch}/
YAML::Loader::Syck undef at ${installsitearch}/
YAML::Dumper::Syck undef at ${installsitearch}/
YAML::Transfer undef at ${installsitelib}/
YAML::Family undef at ${installsitelib}/
YAML::Node undef at ${installsitelib}/
YAML::Marshall undef at ${installsitelib}/
YAML::Tagundef at ${installsitelib}/
YAML::Base undef at ${installsitelib}/
YAML::Types undef at ${installsitelib}/
YAML::Loader undef at ${installsitelib}/
YAML::Error undef at ${installsitelib}/
YAML::Dumper undef at ${installsitelib}/
YAML::Tiny 0.05 at ${installsitelib}/
YAML::Loader::Base undef at ${installsitelib}/
YAML::Dumper::Base undef at ${installsitelib}/
from Config:
installsitearch: /usr/lib/perl5/site_perl/5.8/cygwin
installsitelib: /usr/lib/perl5/site_perl/5.8
Adriano.
Re: fetching module version from the command line
On Wed, 12 Jul 2006 13:41:16 +0300, Gabor Szabo [EMAIL PROTECTED] wrote: While checking if the versions of all the modules are as required in our installation I am using the following one liner to fetch the version numbers. perl -MModule -e'print $Module::VERSION' Not really reliable :) But the more reliable ways take some post-processing pc09:/home/merijn 108 perl -le'require V;print V::get_version(DBI)' 1.51 pc09:/home/merijn 109 perl -MExtUtils::Installed -le'print ExtUtils::Installed-new-version(DBI)' 1.51 pc09:/home/merijn 110 perl -MV=DBI DBI /pro/lib/perl5/site_perl/5.8.7/i686-linux-64int/DBI.pm: 1.51 pc09:/home/merijn 111 perl -le'require V;print V::get_version(DBI)' 1.51 pc09:/home/merijn 112 perl -MDBI=99 DBI version 99 required--this is only version 1.51 at /pro/lib/perl5/5.8.7/Exporter/Heavy.pm line 121. BEGIN failed--compilation aborted. Exit 9 pc09:/home/merijn 113 V is not (yet) on CPAN: http://www.test-smoke.org/otherperl.html Some of the modules print extra error messages and some print only error messages. I have sent e-mail to the respective module authors reporting this issue but I wonder if it would this a good practice in the genric case. Is there a Test module that test just the above? Is the a CPANST score one can get if all the modules in a distro provide the correct version information and if they don't print anything else to STDOUT or STDERR. -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11, 11.23, SuSE 10.0, AIX 4.3 5.2, and Cygwin. http://qa.perl.org http://mirrors.develooper.com/hpux/ http://www.test-smoke.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: fetching module version from the command line
Gabor Szabo wrote in perl.qa : While checking if the versions of all the modules are as required in our installation I am using the following one liner to fetch the version numbers. perl -MModule -e'print $Module::VERSION' You should probably use -mModule to avoid calling Module::import(). (also, in some pathological cases, one can imagine that UNIVERSAL::VERSION() has been overidden) Side note: Abe Timmerman has a module, V, useful to get versions of installed modules: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-03/msg01038.html
Re: [svn:perl6-synopsis] r10077 - doc/trunk/design/syn
Smylers wrote: [EMAIL PROTECTED] commits: New Revision: 10077 Modified: doc/trunk/design/syn/S02.pod == -foo.bar # foo().bar -- postfix prevents args +foo.bar# foo().bar -- illegal postfix, must use foo().bar foo .bar # foo($_.bar) -- no postfix starts with whitespace I don't think it makes much sense to start the comments with an alternate form for the expressions now denoted as illegal -- here's some other syntax which this used to be the same as but it no longer is probably only confuses the casual reader. On a side note, does that apply only to expressions that start with an identifier, or does that mean that: $socket.accept.getlines will have to be: $socket.accept().getlines ?
Re: fetching module version from the command line
On 12 Jul 2006 11:52:07 -, Rafael Garcia-Suarez [EMAIL PROTECTED] wrote: Gabor Szabo wrote in perl.qa : While checking if the versions of all the modules are as required in our installation I am using the following one liner to fetch the version numbers. perl -MModule -e'print $Module::VERSION' You should probably use -mModule to avoid calling Module::import(). (also, in some pathological cases, one can imagine that UNIVERSAL::VERSION() has been overidden) Side note: Abe Timmerman has a module, V, useful to get versions of installed modules: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-03/msg01038.html I never use -m. I should :) # perl -mV -le'print V::get_version(DBI)' 1.51 -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11, 11.23, SuSE 10.0, AIX 4.3 5.2, and Cygwin. http://qa.perl.org http://mirrors.develooper.com/hpux/ http://www.test-smoke.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: TAP diagnostic syntax proposal
Jonathan T. Rockway wrote: I agree that got is generally a good word to avoid in formal writing, but in a testing protocol I think that it's an acceptable abbreviation No! Do not accept inferior substitutes, strive for perfection. for the actual result. Especially since received doesn't quite convey the right meaning here. Maybe expected data and actual data Expected and actual has a long tradition in scientific endeavour, and is what I put forward last year, the last time this subject came up. (or expected and actually) are better? Or maybe got is fine; HTTP still works even though Referer is misspelled. So we should use Recieved? :) Has got/expected ever caused any confusion to anyone (including non-speakers of English)? If so, why? Yes me, and I am a native speaker (well, Australian... so... whatever...) I ranted about this on -qa some time back, and Schwern said that it was too late to do anything about it now. But this new format allows me to roll out my rant again! My confusion regarding got is that I never know whether it's what I got initially, and then I want to see what the test brings back, or whether I have something, and it's what I got back from the test. On a number of occasions I have stared at a failing test, wondering why when I run it manually or stick in printf statements I appear to be getting the right thing. Or the wrong thing, whatever. It gets me confused. Compounded by the fact that, as others point out elsewhere in this thread, the order of appearance is backwards. A primary school teacher taught me that got was a word of the weak, that can nearly always be replaced by something better. This is the only lesson that still stands out vivdly for me from that time. Here, let me dig up that rant: http://www.mail-archive.com/perl-qa@perl.org/msg03999.html Thanks, David -- Much of the propaganda that passes for news in our own society is given to immobilising and pacifying people and diverting them from the idea that they can confront power. -- John Pilger
Re: TAP diagnostic syntax proposal
On 7/11/06, Adam Kennedy [EMAIL PROTECTED] wrote: Fair enough a Layer 1 TAP parser might not care, but why not make it as equally easy to implement a Layer 2 parser as well. Bingo. -- Ian Langworth
Re: TAP diagnostic syntax proposal
Did you guys consider the problem of newlines in content? This is a good question. Implementing your own file format means you have a big-bag-o-quoting problems. How do you print a verbatim newline? What about a verbatim single quote? What about Unicode? What about a new line then not ok - ++$counter? :) http://cr.yp.to/qmail/guarantee.html says: When another programmer wants to talk to a user interface, he has to /quote/: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data. This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way. Things to think about :) Regards, Jonathan Rockway
Re: fetching module version from the command line
On Jul 12, 2006, at 03:41, Gabor Szabo wrote:
perl -MModule -e'print $Module::VERSION'
I have this alias set up:
function pv () { perl -M$1 -le print $1-VERSION; }
I think that calling -VERSION is more correct.
Best,
David
Re: [perl #39777] Macro array considered lame
On Mon, Jul 10, 2006 at 12:09:08AM -0500, Vishal Soni wrote: -#define N_MACROS 4096 +#define N_MACROS 8192 Thanks, applied. But we can all see where this is going. Will no one rid me of this troublesome fixed-size array for macros? -- Chip Salzenberg [EMAIL PROTECTED]
[perl #39802] [PATCH] [CAGE] turning up the warnings levels in gcc as much as we can
# New Ticket Created by Kevin Tew # Please include the string: [perl #39802] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39802 turning up the warnings levels in gcc as much as we can =item C--cage [CAGE] compile includes many additional warnings Configure.pl |5 +++ config/auto/gcc.pm | 87 + 2 files changed, 87 insertions(+), 5 deletions(-) Kevin Index: Configure.pl === --- Configure.pl(revision 13258) +++ Configure.pl(working copy) @@ -52,6 +52,10 @@ Sets the location where parrot will be installed. +=item C--cage + +[CAGE] compile includes many additional warnings + =item C--ask This turns on the user prompts. @@ -284,6 +288,7 @@ --verbose-step=regex Set verbose for step matching description --nomanicheckDon't check the MANIFEST --prefix Set the installation prefix + --cage [CAGE] compile includes many additional warnings --askHave Configure ask for commonly-changed info Index: config/auto/gcc.pm === --- config/auto/gcc.pm (revision 13258) +++ config/auto/gcc.pm (working copy) @@ -127,18 +127,95 @@ # us -Wpadded may prove interesting, or even noisy. # -Wunreachable-code might be useful in a non debugging version ); +my @cage_opt_and_vers = ( +0 = + -std=c89 -Wall -Wextra -Wundef -Wbad-function-cast -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wlong-long +. -Wfloat-equal -Wpadded -Wunreachable-code + +#. -fsyntax-only +#. -pedantic -pedantic-errors +#. -w +#. -Werror +. -Wextra -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts +. -Wcomment -Wconversion -Wno-deprecated-declarations -Wdisabled-optimization -Wno-div-by-zero -Wno-endif-labels +. -Werror-implicit-function-declaration -Wfatal-errors -Wfloat-equal -Wformat -Wformat=2 -Wno-format-extra-args -Wformat-nonliteral +. -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport -Wno-import -Winit-self +. -Winline -Winvalid-pch -Wlarger-than-4096 -Wlong-long -Wmain -Wmissing-braces -Wmissing-field-initializers +. -Wmissing-format-attribute -Wmissing-include-dirs -Wmissing-noreturn -Wno-multichar -Wnonnull -Wpacked +. -Wpadded -Wparentheses -Wpointer-arith -Wredundant-decls -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare +. -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wswitch-enum -Wsystem-headers -Wtrigraphs -Wundef + +#. -Wuninitialized +# requires -O +. -Wunknown-pragmas -Wunreachable-code -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value +. -Wunused-variable -Wwrite-strings -Wvariadic-macros +#.-Wmost (APPLE ONLY) + +#C-only Warning Options +. -Wbad-function-cast -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wstrict-prototypes +#. -Wtraditional +. -Wdeclaration-after-statement -Wno-discard-qual -Wno-pointer-sign , + +#-Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused, +# others; ones we might like marked with ? +# ? -Wundef for undefined idenfiers in #if +# ? -Wbad-function-cast +# Warn whenever a function call is cast to a non-matching type +# ? -Wmissing-declarations +# Warn if a global function is defined without a previous +# declaration -Wmissing-noreturn +# ? -Wredundant-decls +#Warn if anything is declared more than once in the same scope, +# ? -Wnested-externs +#Warn if an `extern' declaration is encountered within an +#function. -Wlong-long +# Ha. this is the default! with -pedantic. +# -Wno-long-long for the nicest bit of C99 +# +# -Wcast-align is now removed: it gives too many false positives +#e.g. when accessing registers - this is all aligned + +2.7 = , +2.8 = , +#2.8 = -Wsign-compare, +2.95 = , + +# 2.95 does align functions per default -malign-functions=4 +# where the argument is used as a power of 2 +# 3.x does not align functions per default,
Re: Ruby on Parrot
On Tue, Jul 11, 2006 at 02:41:19PM -0600, Kevin Tew wrote:
It parses my simple puts.rb example, but parse time is really slow.. 2
minutes.
I'm sure I've made some dumb grammar mistakes that is slowing it down.
Well, the first thing to note is that subrule calls can be comparatively
slow, so I think you might get a huge improvement by eliminating
the sp subrule from
token ws {[sp|[\t]]*}
resulting in
token ws { [ \t]* }
(Also, sp is a capturing subrule, so that means a separate Match
object is being created and stored for every space encountered
in the source program. In such cases ?sp might be better.)
Along a similar vein, I think that a rule such as
rule statement {
ALIAS fitem fitem
|ALIAS global_variable [global_variable|back_reference]
|UNDEF undef_list
|statement2 [IF |UNLESS |WHILE |UNTIL] expression_value
|statement2 RESCUE statement
|BEGIN \{ compound_statement \}
|END \{ compound_statement \}
|command_call
|statement2
}
may be quite a bit slower than the more direct
rule statement {
alias fitem fitem
|alias global_variable [global_variable|back_reference]
|undef undef_list
|statement2 [if|unless|while|until] expression_value
|statement2 rescue statement
|begin \{ compound_statement \}
|end \{ compound_statement \}
|command_call
|statement2
}
but I haven't tested this at all to know if the difference
in speed is significant. I do know that the regex engine will
have more optimization possibilities with the second form than
with the first. (If one stylistically prefers the keyword tokens
not appear as barewords in the rule, then 'alias', 'undef',
etc. work equally well for constant literals.)
It's also probably worthwhile to avoid backtracking and re-parsing
complex subrules such as statement2 above. In the above, a plain
statement2 w/o if/unless/while/until/rescue ends up being parsed
three separate times before the rule succeeds. Better might be:
rule statement {
|alias fitem fitem
|alias global_variable [global_variable|back_reference]
|undef undef_list
|begin \{ compound_statement \}
|end \{ compound_statement \}
|statement2 [ [if|unless|while|until] expression_value
| rescue statement
]?
|command_call
}
(In fact, looking at the grammar I'm not sure that command_call
is really needed, since statement2 already covers that. But I'm
not a Ruby expert.)
Anyway, let me know if any of the above suggestions make sense
or provide any form of improvement in parsing speed.
Thanks!
Pm
Patrick R. Michaud wrote:
On Fri, Jul 07, 2006 at 10:07:57AM -0600, Kevin Tew wrote:
I based the initial PGE grammar for PRuby off of
svn://rubyforge.org/var/svn/rubygrammar/grammars/antlr-v3/trunk/ruby.g
which is in complete.
I'm looking for a BNF style description of the Ruby grammar. Otherwise
I will have to dig into :pserver:[EMAIL PROTECTED]:/src/parse.y.
I'll be glad to provide any help that I can in building a PGE
version of the grammar -- just let me know where I can help.
Pm
Re: [TODO] Implement .loadlib pragma in IMCC
On Wed, Jul 12, 2006 at 12:14:21AM -0400, Audrey Tang wrote: Allison and Chip expressed their go-ahead with a .loadlib pragma, to replace this current use: .sub foo :immediate $I0 = loadlib XXX .end With this: .loadlib XXX Done, r13262. Actually loading libs matching /ops/ *was* already performed at compile time. This hack is now removed too. Thanks for the proposal, leo
Re: TAP diagnostic syntax proposal
* Jonathan Rockway [EMAIL PROTECTED] [2006-07-12 17:50]: Things to think about :) This is the time in our program where we stop to consider what it means that DJB, who wrote that advice/rant, also wrote an RFC2822 parser. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: CPANDB - was: Module::Dependency 1.84
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moin, On Wednesday 12 July 2006 03:13, David Golden wrote: Tels wrote: My idea was to build _only_ the database, and do it right, simple and easy to use and then get everyone else to just use the DB instead of fiddling with their own. (simple by having the database being superior to every other hack thats in existance now :-) I even got so far as to do a mockup v0.02 - but then went back to playing Guildwars. Is this a project that would be of general interest? At YAPC::NA, Adam Kennedy mention that he wanted to try to make some headway on CPAN::Index, which sounds very similar in intent. While it's not released, you can see the formative project at his public repository: http://tinyurl.com/g888h Perhaps you can join forces with him and help push some collective project towards a release. Quoted: BCPAN::Index provides object-oriented access to the CPAN index, using a collection of relatively common modules, and automates entire process of fetching and accessing the index. Uhm, no the DB should maybe be able to have a front-end that fills it from the CPAN index, but you should also be able to build a DB from a local file, if you so wish. The index is stored in a LDBD::SQLite database file, with an object model implemented around it using LDBIx::Class. To update the index, the LCPAN::Index::Loader class implements the logic to flush and reset the database, fetch the index files, parse them, and repopulate the database. The DB backend shouldn't matter at all, it should be transparent and be switchable without any noticable change at the front. Plus, I planned to use YAML because it creates a _much_ less heavy overhead and dependency chain. Using SQLite or similiar is what really creates the problems with CPANTS - you cant just access the raw database without the front-end. WithYAML, at least you could get at the data by other means. Of course for performance reasons it might not be good, but since premature optimization is the root of all evil, I'd say use YAML now, change when nec. Otherwise, the projects seem similiar in scope, except that I focus on the DB and let things like download stuff be done outside. Whether that works out, uh I don't know. In any event I have quite a few ideas I'd like to try out and this proves to be fun to me. I hope it doesn't end upI have to implement other people ideas - thats too much work like :D Best wishes, Tels - -- Signed on Wed Jul 12 18:54:01 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. When it's done in 2001. - 2000 Christmas card about Duke Nukem Forever (http://tinyurl.com/6m8nh) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQEVAwUBRLUqL3cLPEOTuEwVAQK3DAf/VEIV3fCdHTMinHZqL9N3JTxAHBIVZSlw 4grWxod0u3/8DiAhHkSjNu4y0XjE2WV1LrI6JWFD+4/qoElUhvMFydLYXP8cG31X CnXGuAFvq6TVKXCQbHWWucSlcHrILc648i5sCkmi+OTJYUP1AP0/IWdyEbgevWp3 7daHed1UvCetKYyWwTNwgxerTwHAyziFd8kCR2pWzsXUve3zcHhEudm+KF6q6mOI K069eG99V0R5Ix5nisYAdJdei1+TQ8SSXmNZ30VKju8YFTRKcWQNMmWcdxqErydB 19E5C8HDpXAiafUizpmvG8/tChioFjOS+bbsV/AInid6BcQDBDXONg== =2qra -END PGP SIGNATURE-
Re: [TODO] Implement .loadlib pragma in IMCC
It occurs to me, after thinking about it overnight, that the .loadlib directive shouldn't operate at :immediate time, but at :init time, because it's more common to want a library to load when you run the code than to load only when you compile the code. Which leaves us with :immediate for the rare cases when you really want to load a library at compile time. Allison
Easy Str === Str question: what is a reference type
S03 says: Binary === tests type and value correspondence: for two value types, tests whether they are the same value (eg. 1 === 1); for two reference types, checks whether they have the same identity value. For reference types that do not define an identity, the reference itself is used (eg. it is not true that [1,2] === [1,2], but it is true that @a === @a). There's a problem here, from my point of view. I'll take it one assumption at a time: * $whatever.asObject.id ~~ $whateverelse.asObject.id is true if and only if $whatever := $whateverelse at some point in the past, either explicitly, or through some sort of folding. * Str is a boxed type, and thus is a reference type * Thus, Str should be compared by .id and not by value, according to the above. So, IMHO, either there's a mistake in S03; Str is a special case WRT ===; or I misunderstand reference type (which S03 never defines). Clarification please? Two things were mentioned on IRC about this: * Str might be compared by .id, but .id for Str is based on the contents of its underlying storage... this worries me because it means that Strs with radically different meanings would be === because their encoding is different. * A reference type might only mean containers (though S03 seems to imply that objects are included to me). Thanks, and sorry for all the lame questions! I'm just trying to make sure that the docs I write aren't utterly, worthlessly wrong. :-/ -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith We had some good machines, but they don't work no more. -Shriekback
===, =:=, ~~, eq and == revisited (blame ajs!)
Over at #perl6 we had a short discussion on =:=, ===, and ~~, mostly raised by ajs's discussion on Str items and ===. After a brief discussion we managed to formulate several questions that we feel are slightly to totally unresolved. 1. what is .id on references? Is it related to the memory slot, like refaddr() in Perl 5? 2. is .id *always* a low level type representation of the object's value? It's specced that low level typed items have the same ID when they have the same value. What about complex types? 3. Are these descriptions of the operators correct? ~~ matches the left side to a description on the right side =:= makes sure the objects are actually the same single object (if $x =:= $y and you change $x.foo then $y.foo was also changed... is this .id on refs?) Is =:= really eq .id? or more like variable($x).id eq variable($y).id? === makes sure that the values are equivalent ( @foo = ( 1, 2, 3 ); @bar = ( 1, 2, 3); @foo === @bar currently works like that, but @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 ); @foo === @bar does not (in pugs). This is not useful because we already have this return false with =:=). If they are not correct, why is there an overlap between =:=? Why is it hard to deeply compare values in 2006 without using e.g. Data::Compare? 4. will we have a deep (possibly optimized[1]) equality operator, that *will* return true for @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 ); op(@foo, @bar)? Is it going to be easy to make the newbies use that when they mean it's the same, like they currently expect == and eq to work on simple values? 5. is there room for a new opperator? =::= makes sure the memory slot is the same (might be different for simple values). refaddr($x) == refaddr($y) in Perl 5 =:= makes sure that .ids are the same, and is useful if the .id method is meaningful for an object. A bit like Test::More::is( $x, $y ) but without the diagnosis in Perl 5, or abusing eq if the object doesn't overload stringification. === makes sure the values are the same even if they are copies/clones/whatever. Data::Compare in Perl 5. A bit like what people overload == for in Perl 5 right now (which confuses numerical equality with true equality, so we want to phase that out). ~~ makes sure the value on the right side describes the value on the left side. Reminiscient of Test::Deep::cmp_deeply, with all the various matching magic. Thanks, [1] It could, of course, be just =:= === inside, and it could optimize arrays to check length first, and it could cache checksums and it could do whatever - please don't bring this up as a performance issue, it is one of correctness and ergonomics that must be resolved first. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpVx2Q88D1JG.pgp Description: PGP signature
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
If we do have deep value equality checks, then default == and eq
are probably:
sub infix:== ( $x, $y ) {
+$x === +$y;
}
sub infix:eq ( $x, $y ) {
~$x === ~$y;
}
So that the compare-as-sometype behavior is retained from perl 5
without introducing new complexity to the objects being compared as
strings/numbers.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpNhYctTCtP5.pgp
Description: PGP signature
Another quick one: .asancestor
I would assume that all classes automatically define:
multi submethod *infix:as ($self: $?CLASS) { $self }
so that derived classes can automatically:
$obj.asancestor
Without actually changing their implementation details (only the type
that Perl currently thinks it's dealing with polymorphically).
In fact, I would expect that this bit of behind-the-curtain magic is how
the MCP arranges for polymorphism when you:
sub foo(Object $x) {...}
my A $y;
foo($y);
Is all of that fair?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines, but they don't work no more. -Shriekback
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
Jedai and I went through some of pugs current implementations. Here's a list of what we expect the operators to return and what they currently do. This does not exactly agree with S03 right now, but is our opinion. Force into a type before comparing values: 42 == 42 - true, same numeric value 42 == 42 - true, same numeric value 42 == 42 - true, same numeric value 42 == 42.0 - true, same numeric value 42 eq 42.0 - false, different string value 4 eq 4 - true, same string value Well typed value comparison: 42 === 42 - true, the same type 42 === 42 - false, not the same type 42 === 42 - true, the same type 42 === 42.0 - false, different value in natural type (string values) (1, 2, 3) === (1, 2, 3) - true, same value ([1, 2 ], 3 ) === ([1, 2 ], 3) - true, same value - BROKEN (actually false, since refs are not the same). S03 thinks this is actually OK. [1, 2, 3] === [1, 2, 3] - true, same value, (S03 says that this is actually broken, because references should not be the same (we disagree)) my @foo = (1, 2, 3); my @bar = @foo; @foo === @bar - true, same value. my @foo = ([1, 2], 3); my @bar = @foo; @bar === @foo - true, same value - BROKEN (S03 actually agrees with us here, since the ref is the same in this case) Slot/container equality (this is actually up to debate, but this is what we would expect if it was refaddr($x) == refaddr($y)): [ 1, 2, 3 ] =:= [ 1, 2, 3 ] - false, different containers - BROKEN (actually true) my $foo = [ 1, 2, 3 ]; $foo =:= $foo - true, same container my $foo = [ 1, 2, 3 ]; my $bar := $foo; $bar =:= $foo - true, same container my $foo = [ 1, 2, 3 ]; my $bar = $foo; $bar =:= $foo - true, ref to same container, or false since different container, unsure - currently true my @foo = (1, 2, 3); my @bar = @foo; @foo =:= @bar - false, container should be different - BROKEN (actually true) my @foo = (1, 2, 3); my @bar = @foo; @bar[1] = moose; @foo =:= @bar - false, container should be different. This actually works like we expected, appearantly pugs does some sort of COW Under := slot semantics the first test should be false, the second should be true, the third should be true, the fourth should be false, the fifth should be false, and the sixth should be false. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpGSy7OFZEBd.pgp Description: PGP signature
Re: TAP diagnostic syntax proposal
If only we had some kind of standard language for marking things up that was extensible... and wasn't met with universal disapproval, F On 12/07/06, Jonathan Rockway [EMAIL PROTECTED] wrote: Did you guys consider the problem of newlines in content? This is a good question. Implementing your own file format means you have a big-bag-o-quoting problems. How do you print a verbatim newline? What about a verbatim single quote? What about Unicode? What about a new line then not ok - ++$counter? :) http://cr.yp.to/qmail/guarantee.html says: When another programmer wants to talk to a user interface, he has to /quote/: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data. This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way. Things to think about :) Regards, Jonathan Rockway
Re: [svn:perl6-synopsis] r10077 - doc/trunk/design/syn
On Wed, Jul 12, 2006 at 08:40:53AM -0400, Aaron Sherman wrote:
: Smylers wrote:
: [EMAIL PROTECTED] commits:
:
:
: New Revision: 10077
: Modified: doc/trunk/design/syn/S02.pod
:
==
:
: -foo.bar# foo().bar -- postfix prevents args
: +foo.bar# foo().bar -- illegal postfix, must use
: foo().bar
: foo .bar # foo($_.bar) -- no postfix starts with
: whitespace
:
:
: I don't think it makes much sense to start the comments with an
: alternate form for the expressions now denoted as illegal -- here's
: some other syntax which this used to be the same as but it no longer is
: probably only confuses the casual reader.
:
:
: On a side note, does that apply only to expressions that start with an
: identifier, or does that mean that:
:
:$socket.accept.getlines
:
: will have to be:
:
:$socket.accept().getlines
:
: ?
No, this is only list operators, not methods. So
$socket.accept.getlines
is fine, but
foo.accept.getlines
is not, unless foo is predeclared 0-ary.
But I am tempted to extend it to keywords like else and sub as
well, because any foo{} confusion is going to train people not to
think about ...{} as a subscript when they should think about it
whenever there's a lack of whitespace. It would be nice if :foo{}
were the only exception to that.
For similar reasons, I'm also tempted to say that if() is always a
function call, because it looks like one.
Larry
[perl #39799] [PATCH] pmclass brace indentation
# New Ticket Created by willie # Please include the string: [perl #39799] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39799 fixes the indentation of the pmclass's closing brace and the last method's closing brace in src/pmc/array.pmc. no other pmc file in the same directory needs a similar adjustment. Index: src/pmc/array.pmc === --- src/pmc/array.pmc (revision 13260) +++ src/pmc/array.pmc (working copy) @@ -1263,8 +1263,8 @@ SUPER(info); if (info-extra_flags == EXTRA_IS_NULL) DYNSELF.set_integer_native(io-vtable-shift_integer(INTERP, io)); -} } +} /*
Re: CPANDB - was: Module::Dependency 1.84
On Wed, Jul 12, 2006 at 03:03:14AM +0200, Tels wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moin Tim, On Tuesday 11 July 2006 18:34, Tim Bunce wrote: I needed some code to trawl through a directory tree parsing perl modules and scripts to determine their dependencies. The closest existing CPAN code was Module::Dependency but it fell short of what I needed. The original author (P Kent) has passed over maintenance to me. My latest release is: file: $CPAN/authors/id/T/TI/TIMB/Module-Dependency-1.84.tar.gz size: 52161 bytes md5: 90a83b2aee39f5d25060ebdb6cc3105d Thats sort of cool, although I havent looked at it yet :-D My real-grand-plan was always to have a CPANDB module that does exactly the following: maintains a database with: * every CPAN author with all details (ID, email, name) * every package with all details (author id, version, name etc etc) This database could then be used by all the following modules: Module::Dependency Graph::Dependency CPANPLUS CPANTS CPAN Module::Author and a few others I forgot. Basically by every module out there that re-invents the wheel over and over again just to be able to query stuff about CPAN modules. (some of them do really horrible stuff like accessing search.cpan.org - I know I wrote one of them :D A key point about those modules (other than Module::Dependency) is that they don't work for private modules (the so called Dark CPAN) nor for scripts. Module::Dependency handles both (details changed to protect the guilty): $ pmd_dump.pl adnetwork/www/cron/cv.pl adnetwork/www/cron/cv.pl depended_upon_by: adnetwork/www/cron/cv.pl depends_on: strict File::Basename lib Env wConfig vConfig Churl::Log Churl::MyDBI Churl::Util $ pmd_dump.pl Churl::MyDBI Churl::MyDBI depended_upon_by: www/cron/cv.pl www/cron/pub_login.pl Churl::MyDBI depends_on: Exporter strict warnings Carp DBIx::DWIW File::Basename Sys::Syslog vars Churl::MyDBI filename: clcyt/Churl/lib/Churl/MyDBI.pm And up until today it is still not possible to get easily the answer what modules do I need install for Foo::Bar 1.23 when using Perl 5.8.x. Or what module may be affected if I upgrade Foo::Bar. My idea was to build _only_ the database, and do it right, simple and easy to use and then get everyone else to just use the DB instead of fiddling with their own. (simple by having the database being superior to every other hack thats in existance now :-) I even got so far as to do a mockup v0.02 - but then went back to playing Guildwars. Is this a project that would be of general interest? Yes! But widen your horizon, and schema, beyond just CPAN. I'd be interested in helping out and, if it works out, perhaps migrate Module::Dependency to use it. Tim.
Re: [TODO] Implement .loadlib pragma in IMCC
On Wed, Jul 12, 2006 at 10:25:43AM -0700, Allison Randal wrote: It occurs to me, after thinking about it overnight, that the .loadlib directive shouldn't operate at :immediate time, but at :init time, because it's more common to want a library to load when you run the code than to load only when you compile the code. This might not seem totally related (but it is somewhat related)... The perl6 compiler has a custom string type, currently called Perl6Str. What's the canonically correct mechanism for creating an object of that type? $P0 = new 'Perl6Str' $P0 = new .Perl6Str $P0 = new [ 'Perl6Str' ] At different stages of Parrot development I've seen different answers to this question, so it'd be helpful to know what's correct. (Also, if the answer is somehow different for Parrot's built-in types, such as Undef or Integer, I'd like to know that.) Pm
Re: [TODO] Implement .loadlib pragma in IMCC
On Wed, Jul 12, 2006 at 10:25:43AM -0700, Allison Randal wrote: It occurs to me, after thinking about it overnight, that the .loadlib directive shouldn't operate at :immediate time, but at :init time, because it's more common to want a library to load when you run the code than to load only when you compile the code. Well, there was already one very legitimate usage of compile time loadlib, which is now using C.loadlib for that: .loadlib opcode_lib The library is needed immediately in the compiler to be able to proceed parsing (e.g. to check the amount and types of freshly loaded opcodes). There was a crude hack that accomplished this, which is now removed, because it's cleanly covered by C.loadlib. See also t/dynoplibs/*.t Another usage of compile time C.loadlib could be: .loadlib my_pmcs ... $P0 = new .MyInt I.e. some custom PMC loading, w/o defining a HLL language. There might be other cases, where :init time is early enough, though. Allison leo
[perl #39801] [PATCH] adding examples\shootout\spectralnorm.pir
# New Ticket Created by Michal Jurosz # Please include the string: [perl #39801] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39801 Implement spectralnorm shootout benchmark ( http://shootout.alioth.debian.org/sandbox/benchmark.php?test=alllang=parrot ). -- S pozdravem Michal Jurosz Index: examples/shootout/spectralnorm.pir === --- examples/shootout/spectralnorm.pir (revision 0) +++ examples/shootout/spectralnorm.pir (revision 0) @@ -0,0 +1,161 @@ +#!./parrot -j +# +# spectralnorm.pir N (N = 100 for shootout) +# by Michal Jurosz + +.sub eval_A + .param int i + .param int j + + # return 1.0/((i+j)*(i+j+1)/2+i+1); + $N0 = i + j + $N1 = $N0 + 1 + $N0 *= $N1 + $N0 /= 2 + $N0 += i + $N0 += 1 + $N0 = 1 / $N0 + .return ($N0) +.end + + +.sub eval_A_times_u + .param int N + .param pmc u + .param pmc Au + + .local int i, j + + i = 0 +beginfor_i: + unless i N goto endfor_i + Au[i] = 0 + j = 0 + beginfor_j: + unless j N goto endfor_j + # Au[i]+=eval_A(i,j)*u[j] + $N0 = eval_A(i,j) + $N1 = u[j] + $N0 *= $N1 + $N1 = Au[i] + $N0 += $N1 + Au[i] = $N0 + + inc j + goto beginfor_j + endfor_j: + + inc i + goto beginfor_i +endfor_i: +.end + + +.sub eval_At_times_u + .param int N + .param pmc u + .param pmc Au + + .local int i, j + + i = 0 +beginfor_i: + unless i N goto endfor_i + Au[i] = 0 + j = 0 + beginfor_j: + unless j N goto endfor_j + # Au[i]+=eval_A(j,i)*u[j] + $N0 = eval_A(j,i) + $N1 = u[j] + $N0 *= $N1 + $N1 = Au[i] + $N0 += $N1 + Au[i] = $N0 + + inc j + goto beginfor_j + endfor_j: + + inc i + goto beginfor_i +endfor_i: +.end + + +.sub eval_AtA_times_u + .param int N + .param pmc u + .param pmc AtAu + + .local pmc v + v = new .FixedFloatArray + v = N + + eval_A_times_u(N,u,v) + eval_At_times_u(N,v,AtAu) +.end + + +.sub main :main + .param pmc argv + $S0 = argv[1] + .local int N + N = $S0 + + .local pmc u, v + u = new .FixedFloatArray + u = N + v = new .FixedFloatArray + v = N + + .local int i + + i = 0 +beginfor_init: + unless i N goto endfor_init + u[i] = 1 + inc i + goto beginfor_init +endfor_init: + + + i = 0 +beginfor_eval: + unless i 10 goto endfor_eval + eval_AtA_times_u(N,u,v) + eval_AtA_times_u(N,v,u) + inc i + goto beginfor_eval +endfor_eval: + + .local float vBv, vv + vBv = 0.0 + vv = 0.0 + + i = 0 +beginfor_calc: + unless i N goto endfor_calc + # vBv+=u[i]*v[i]; vv+=v[i]*v[i]; + $N0 = u[i] + $N1 = v[i] + $N0 *= $N1 + vBv += $N0 + $N0 = $N1 + $N0 *= $N0 + vv += $N0 + inc i + goto beginfor_calc +endfor_calc: + + # print %0.9f % (sqrt(vBv/vv)) + $N0 = vBv / vv + $N0 = sqrt $N0 + .local pmc spf + spf = new .FixedFloatArray + spf = 1 + spf[0] = $N0 + $S0 = sprintf %.9f\n, spf + print $S0 + exit 0 +.end
Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)
On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote: The perl6 compiler has a custom string type, currently called Perl6Str. What's the canonically correct mechanism for creating an object of that type? $P0 = new 'Perl6Str' $P0 = new .Perl6Str $P0 = new [ 'Perl6Str' ] At different stages of Parrot development I've seen different answers to this question, so it'd be helpful to know what's correct. I tend to use: .local int str_type str_type = find_type [ 'Perl6Str' ] .local pmc p6str p6str= new str_type -- c
Re: [TODO] Implement .loadlib pragma in IMCC
On 7/12/06, Patrick R. Michaud [EMAIL PROTECTED] wrote: The perl6 compiler has a custom string type, currently called Perl6Str. What's the canonically correct mechanism for creating an object of that type? $P0 = new 'Perl6Str' $P0 = new .Perl6Str $P0 = new [ 'Perl6Str' ] At different stages of Parrot development I've seen different answers to this question, so it'd be helpful to know what's correct. (Also, if the answer is somehow different for Parrot's built-in types, such as Undef or Integer, I'd like to know that.) according to DEPRECATED.pod (not the best place for notes about possible changes (predicted deprecation?)): =item Class name IDs ... will require a dot in front $P0 = new Integer = $P0 = new .Integer according to P6PE, 2nd edition, PMC variables section (p.188): Unlike PASM, PIR doesn't use a dot in front of the class name. P0 = new PerlString # same as new P0, .PerlString i have no point/counterpoint for the bracketed syntax. hope that provides some history, context, clarification, or confusion. ~jerry
Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)
On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote: On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote: The perl6 compiler has a custom string type, currently called Perl6Str. What's the canonically correct mechanism for creating an object of that type? $P0 = new 'Perl6Str' $P0 = new .Perl6Str $P0 = new [ 'Perl6Str' ] I tend to use: .local int str_type str_type = find_type [ 'Perl6Str' ] .local pmc p6str p6str= new str_type Along similar lines... - If another HLL wants to create a Perl6Str, how does it do it? - If another HLL wants to create a subclass of Perl6Str...? Pm
Re: [TODO] Implement .loadlib pragma in IMCC
On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote: The perl6 compiler has a custom string type, currently called Perl6Str. What's the canonically correct mechanism for creating an object of that type? $P0 = new 'Perl6Str' $P0 = new .Perl6Str $P0 = new [ 'Perl6Str' ] At different stages of Parrot development I've seen different answers to this question, so it'd be helpful to know what's correct. Correct are all three, but: 1) and 3) are totally the same (bracketed syntax just containing a single string constant just yields that string concstant as a result) thusly, 3) is containing some syntax overkill :-) 1) works always, but defers the type lookup to runtime. It's a more efficient version of: $I0 = find_type 'Perl6Str' $P0 = new $I0 ..., which takes one more opcode dispatch 2) only works, *if* the lib, which defines that type is already loaded (via :immediate/loadlib or .loadlib), because it's translated to new_p_ic, i.e. the type name is converted to a type number at compile time, which speeds up run time object creation. A remark WRT: $P0 = new Integer # bare word 'Integer' this currently works with a lexer hack (and special code for 'new' IIRC) but it's deprecated in favour of the much more explicit C.Integer, which is indicating some macroish replacement. Pm leo
Re: [TODO] Implement .loadlib pragma in IMCC
Leopold Toetsch wrote: Well, there was already one very legitimate usage of compile time loadlib, which is now using C.loadlib for that: We certainly need both compile-time and runtime loading of libraries. So, it's just a question of which syntax to use for which case. chromatic suggests .include for load this library at compile and run time. The .include directive is currently being used to mean inline the entire source code for this file here. But, I've always thought of that as a hack we put in before we had library loading working. Any thoughts? That would leave us the consistency of the loadlib opcode and the .loadlib directive both meaning load this library at runtime. Allison
Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)
On Wed, Jul 12, 2006 at 01:55:39PM -0500, Patrick R. Michaud wrote: On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote: On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote: The perl6 compiler has a custom string type, currently called Perl6Str. What's the canonically correct mechanism for creating an object of that type? $P0 = new 'Perl6Str' $P0 = new .Perl6Str $P0 = new [ 'Perl6Str' ] I tend to use: .local int str_type str_type = find_type [ 'Perl6Str' ] .local pmc p6str p6str= new str_type Along similar lines... - If another HLL wants to create a Perl6Str, how does it do it? - If another HLL wants to create a subclass of Perl6Str...? AFAIK there is no answer for this at present. (1) POSSIBLE KLUDGE In the very short term we could introduce a simple hack that would allow the user to specify the root namespace for the creation of the new class, defaulting to the HLL root: .HLL evillang .sub foo $P0 = get_hll_namespace# ['evillang'] $P1 = newclass ['Perl6Str'], $P0 # Not a Perl 6 string, but an incredible simulation ... (2) ELEGANT DIRECTION FOR THE FUTURE [to be determined] Seriously: Allison's busy (as am I) with nailing namespaces to the wall, so I wouldn't ask her to decide this. I do have ... not so much an idea, but an approach, which I'll suggest when the time comes: At present, newclass creates a class object and a namespace, both of which have the same name. That must change once we stop depending on typed namespaces. Assuming a single namespace object can represent a single class in future -- which is good for class manipulation and introspection -- I think we'd want to stop having 'newclass' futz with namespaces at all, leaving it up to the user to give it a name ... if any. Yes, Virginia, there are anonymous classes. :-) So it might look like: .HLL evillang .sub foo $P0 = newclass ... set_hll_global ['Perl6Str'], $P0 # Not a Perl 6 string, but an incredible simulation ... -- Chip Salzenberg [EMAIL PROTECTED]
Re: [TODO] Implement .loadlib pragma in IMCC
On Jul 12, 2006, at 3:18 PM, Allison Randal wrote: Leopold Toetsch wrote: Well, there was already one very legitimate usage of compile time loadlib, which is now using C.loadlib for that: We certainly need both compile-time and runtime loading of libraries. So, it's just a question of which syntax to use for which case. chromatic suggests .include for load this library at compile and run time. The .include directive is currently being used to mean inline the entire source code for this file here. But, I've always thought of that as a hack we put in before we had library loading working. Any thoughts? I would prefer .include to maintain its current meaning. Not everything you .include is a complete PIR program. That would leave us the consistency of the loadlib opcode and the .loadlib directive both meaning load this library at runtime. How does this relate to leo's previous statement that .loadlib now does both compile runtime loads? Allison -- Will Coke Coleda [EMAIL PROTECTED]
Re: [TODO] Implement .loadlib pragma in IMCC
On Wed, Jul 12, 2006 at 12:18:51PM -0700, Allison Randal wrote: Leopold Toetsch wrote: Well, there was already one very legitimate usage of compile time loadlib, which is now using C.loadlib for that: We certainly need both compile-time and runtime loading of libraries. So, it's just a question of which syntax to use for which case. chromatic suggests .include for load this library at compile and run time. The .include directive is currently being used to mean inline the entire source code for this file here. But, I've always thought of that as a hack we put in before we had library loading working. Any thoughts? I think I'm confused by or totally misunderstanding the proposal. I think we have two very different sorts of library at play here: dynamic libraries (with a .so extension on my system), and libraries of parrot code (with .pir, .pbc, and .pasm extensions). IIUC, the loadlib opcode (and the new .loadlib directive) are used strictly for dynamic libraries -- on my system those are files with .so extensions. loadlib and .loadlib aren't used for .pbc files... that's the domain of the load_bytecode opcode. load_bytecode can be used for loading .pbc/.pir files at runtime, at load-time via :load, or at compile-time with :immediate. .include is currently compile-time only, and only works with .pir/.pasm files (i.e., one cannot include a .pbc). In addition, any .included source honors the current .HLL and .namespace settings, which isn't true for files (.pir/.pbc) that are obtained via load_bytecode opcode. So, if the proposal is that .include means load a .pbc/.pir library whenever the including file is compiled or loaded in a manner analogous to load_bytecode, then I'm still wanting a way to get source files that are compile-only and honor any .namespace directives. But as I said, I think I must be misunderstanding what is being said, so feel free to re-explain or correct my misunderstanding. Pm
[perl #39796] [TODO] Implement .loadlib pragma in IMCC
# New Ticket Created by Autrijus Tang # Please include the string: [perl #39796] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39796 Allison and Chip expressed their go-ahead with a .loadlib pragma, to replace this current use: .sub foo :immediate $I0 = loadlib XXX .end With this: .loadlib XXX This might be done as part of vsoni's IMCC refactoring, or as a lexer action that loads the library as soon as this directive is seen. In any case, this will let dependency checkers have a much easier time to figure out what dynamic libraries a .pir file is loading, without actually have to invoke Parrot themselves. Audrey PGP.sig Description: PGP signature
Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)
On Wed, Jul 12, 2006 at 01:55:39PM -0500, Patrick R. Michaud wrote: On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote: On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote: $P0 = new 'Perl6Str' I tend to use: .local int str_type str_type = find_type [ 'Perl6Str' ] .local pmc p6str p6str= new str_type That's a rather complicated :-) way of expressing the one-liner above. Along similar lines... - If another HLL wants to create a Perl6Str, how does it do it? loadlib 'perl6' # or load_bytecode or whatever $P0 = new 'Perl6Str' - If another HLL wants to create a subclass of Perl6Str...? loadlib 'perl6' # or load_bytecode or whatever clas = subclass 'Perl6Str', 'MyStr' Pm leo
Re: [TODO] Implement .loadlib pragma in IMCC
From: Leopold Toetsch [EMAIL PROTECTED] Date: Wed, 12 Jul 2006 21:15:44 +0200 On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote: The perl6 compiler has a custom string type, currently called Perl6Str. What's the canonically correct mechanism for creating an object of that type? $P0 = new 'Perl6Str' $P0 = new .Perl6Str $P0 = new [ 'Perl6Str' ] At different stages of Parrot development I've seen different answers to this question, so it'd be helpful to know what's correct. Correct are all three, but . . . 2) only works, *if* the lib, which defines that type is already loaded (via :immediate/loadlib or .loadlib), because it's translated to new_p_ic, i.e. the type name is converted to a type number at compile time, which speeds up run time object creation. So the type is bound to a number in the .pbc? Isn't this dangerous for types that are not built in? Couldn't this number mean something different if libraries happen to get loaded in a different order? -- Bob Rogers http://rgrjr.dyndns.org/
Re: [TODO] Implement .loadlib pragma in IMCC
On Wed, Jul 12, 2006 at 12:18:51PM -0700, Allison Randal wrote: Leopold Toetsch wrote: Well, there was already one very legitimate usage of compile time loadlib, which is now using C.loadlib for that: We certainly need both compile-time and runtime loading of libraries. So, it's just a question of which syntax to use for which case. chromatic suggests .include for load this library at compile and run time. The .include directive is currently being used to mean inline the entire source code for this file here. But, I've always thought of that as a hack we put in before we had library loading working. Any thoughts? C.include and Cloadlib are really very different. It's like #include and dlopen(3) in the C language. But I can see, what is leading to this argument: loading arbitrary bytecode within .include, which should better be done with Cload_bytecode. This means, we'd have: .include file.pasm/.pir ... load macros or constants (no code) load_bytecode file.pbc ... load a module $P0 = loadlib file ... load a shared lib (pmc or ops) .loadlib file... same during compilation That would leave us the consistency of the loadlib opcode and the .loadlib directive both meaning load this library at runtime. Not really. Allison leo
Re: [TODO] Implement .loadlib pragma in IMCC
On Wed, Jul 12, 2006 at 03:51:53PM -0400, Bob Rogers wrote: From: Leopold Toetsch [EMAIL PROTECTED] Date: Wed, 12 Jul 2006 21:15:44 +0200 On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote: The perl6 compiler has a custom string type, currently called Perl6Str. What's the canonically correct mechanism for creating an object of that type? $P0 = new 'Perl6Str' $P0 = new .Perl6Str $P0 = new [ 'Perl6Str' ] 2) only works, *if* the lib, which defines that type is already loaded (via :immediate/loadlib or .loadlib), because it's translated to new_p_ic, i.e. the type name is converted to a type number at compile time, which speeds up run time object creation. So the type is bound to a number in the .pbc? Isn't this dangerous for types that are not built in? Couldn't this number mean something different if libraries happen to get loaded in a different order? IIUC, the type is bound to a number in the .pbc only for the second form (.Perl6Str). And yes, it is dangerous for the non-built-in types, which is why I think the note in DEPRECATED.pod is likewise dangerous: =item Class name IDs ... will require a dot in front $P0 = new Integer = $P0 = new .Integer AFAICT, the only safe form for the non-builtin types is to use a string, a key, or the separate find_type lookup...which is what prompted my original question in this thread about which form is canonically (and operationally) correct. Pm
Re: [TODO] Implement .loadlib pragma in IMCC
On Wed, Jul 12, 2006 at 03:51:53PM -0400, Bob Rogers wrote: So the type is bound to a number in the .pbc? Isn't this dangerous for types that are not built in? Couldn't this number mean something different if libraries happen to get loaded in a different order? The declaration order of PMC libs is recorded in the HLL_info structure. When the .pbc is loaded, PMCs are initialized in that very same order, so that type numbers *should* match in the .pbc again. -- Bob Rogers leo
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote: Over at #perl6 we had a short discussion on =:=, ===, and ~~, mostly raised by ajs's discussion on Str items and ===. *wave* 1. what is .id on references? Is it related to the memory slot, like refaddr() in Perl 5? That's something I'm not sure of, so I'll let it go, other than to say that that question should probably avoid the word memory, see below. 4. will we have a deep (possibly optimized[1]) equality operator, that *will* Now, let me handle this one out of order, since I think it's really key: return true for @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 ); op(@foo, @bar)? Is it going to be easy to make the newbies use that when they mean it's the same, like they currently expect == and eq to work on simple values? Isn't that ~~? Per S03: Array Array arrays are comparablematch if $_ »~~« $x ~~ is really the all-purpose, bake-your-bread, clean-your-floors, wax-your-cat operator that you're looking for. It sounds like pugs is wrong here WRT the spec, since: ( [ 1, 2 ], 3 ) ~~ ( [ 1, 2 ], 3 ) is the same as: [1,2]~~[1,2] 3 ~~ 3 which is the same as: (1~~1 2~~2) 3~~3 which is true. Ain't recursive hyperoperators grand? Of course, I'm assuming that a comparison hyperoperator in boolean context returns the [] reduction of all of the values... that's an interesting assumption, isn't it? But, it seems to be the assumption made by S03 under Smart Matching, so I say it's true. ;) 2. is .id *always* a low level type representation of the object's value? It's specced that low level typed items have the same ID when they have the same value. What about complex types? It cannot be for complex types or even strings... well, at least it Imust not be Iif we care about performance. That is, if C$anything.id needs to read every byte of $anything, then an anything that happened to be a Buf containing the 3GB in-memory raw image from the Hubble is going to really make C.id unhappy. I would hope that C.id is an efficient enough operation that === should not look like a performance bottleneck in my code 3. Are these descriptions of the operators correct? ~~ matches the left side to a description on the right side =:= makes sure the objects are actually the same single object (if $x =:= $y and you change $x.foo then $y.foo was also changed... is this .id on refs?) Is =:= really eq .id? or more like variable($x).id eq variable($y).id? === makes sure that the values are equivalent ( @foo = ( 1, 2, 3 ); @bar = ( 1, 2, 3); @foo === @bar currently works like that, but @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 ); @foo === @bar does not (in pugs). This is not useful because we already have this return false with =:=). Let me counter-propose a slightly different way of saying that: ~~ as above. I think we all agree on this. =:= looks in the symbol table (caveat dragons) to see if LHS refers to the same variable as the RHS. Does this dereference? Probably not, but I'm not sure, based on S03. === Compares types and .id values. An implementation of this, as I interpreted S03, and with some assumptions made, and with some extra bits filling in the cracks where S03 didn't quite specify an implementation: * A .id method may return Cint, Cnum or Cbit. === returns false for two objects which are not the same type (with the same traits), and thus the comparison must always be between identical .id return types. * As a special case, however, all undefined values (not objects which have the undefined trait, but true undefs with no other functionality) are === to each other. * Objects are always compared according to their underlying type, not the polymorphic role which they are serving at the moment. * num, Num and all like values return their num representation as a .id. * int, Int and all like values return their int representation as a .id. * Bool, bool and bit all have a bit representation for .id * All other code, objects, references, structures, complex numbers, etc. are compared strictly on the basis of an arbitrary Cint which Perl will generate to represent their storage, and can be overridden by replacing the default .id method. The other way to think about === would be that it tells you if its LHS *could* be constant-folded onto its RHS (if it were constant for long enough), where =:= tells you if that has already been done. Only ~~ has some sort of deep semantics, and I think the documentation warns users sufficiently of this magical
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
On Wed, Jul 12, 2006 at 04:16:13PM -0400, Aaron Sherman wrote:
On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
4. will we have a deep (possibly optimized[1]) equality operator, that
*will* return true for @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 );
op(@foo, @bar)?
Is it going to be easy to make the newbies use that when they mean it's the
same, like they currently expect == and eq to work on simple values?
Isn't that ~~?
Per S03:
Array Array arrays are comparablematch if $_ »~~« $x
~~ is really the all-purpose, bake-your-bread, clean-your-floors,
wax-your-cat operator that you're looking for.
Granted, ~~ will return true in that case. I think the main problem
is Yuval wants a guarantee that it will return true if and only if
the things on either side have the same deep structure and values.
Currently, ~~ will also return true for structures where this does
not hold. For example:
@a = ( [ 1, 2] , 3 );
@b = ( sub { return 1 }, sub { return 1 } );
@a ~~ @b; # true
Why is that true? By the rules of hyper-operation, it turns into
this:
[1,2] ~~ sub { return 1 }
3 ~~ sub { return 1 }
which is true if these return true values:
sub { return 1 }-([1,2])
sub { return 1 }-(3)
Which they do.
So, smart-match fails as a deep equality operator precisely
because it's so smart.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: [TODO] Implement .loadlib pragma in IMCC
Will Coleda wrote: I would prefer .include to maintain its current meaning. Not everything you .include is a complete PIR program. I think the most common case at the moment is stitching together .pir files generated by PGE/TGE. Which is useful. Allison
Re: [TODO] Implement .loadlib pragma in IMCC
Patrick R. Michaud wrote: IIUC, the loadlib opcode (and the new .loadlib directive) are used strictly for dynamic libraries... .include is currently compile-time only, and only works with .pir/.pasm ... Yes, the suggestion is an extreme reuse of existing syntax. Something that's good to avoid on general design principles. Allison
Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)
On Wed, Jul 12, 2006 at 12:15:07PM -0700, Chip Salzenberg wrote: - If another HLL wants to create a Perl6Str, how does it do it? - If another HLL wants to create a subclass of Perl6Str...? I just realized that I misinterpreted these questions. I thought that the first question was asking how some random HLL can create its own class that also has the name 'Perl6Str' -- i.e. a name collision question -- and that the second question was adding on by asking how the new name-collided class could coexist with (for example, derive from) the original. I'll be happy to answer the actual questions precisely, but I need to know more: Frst: Is this about now or the eventual future? Do you want the answer for when the full name of Perl6Str is ['parrot';'Perl6Str'], as I think it is today, or ['perl6';'Perl6Str'], as it should be eventually? Second: Does the derived class have to be named ['myhll','Perl6Str'], or can it have a new basename like ['myhll','MyPerl6Str']? AFAIK there is no answer for this at present. (1) POSSIBLE KLUDGE In the very short term we could introduce a simple hack that would allow the user to specify the root namespace for the creation of the new class, defaulting to the HLL root: .HLL evillang .sub foo $P0 = get_hll_namespace# ['evillang'] $P1 = newclass ['Perl6Str'], $P0 # Not a Perl 6 string, but an incredible simulation ... (2) ELEGANT DIRECTION FOR THE FUTURE [to be determined] Seriously: Allison's busy (as am I) with nailing namespaces to the wall, so I wouldn't ask her to decide this. I do have ... not so much an idea, but an approach, which I'll suggest when the time comes: At present, newclass creates a class object and a namespace, both of which have the same name. That must change once we stop depending on typed namespaces. Assuming a single namespace object can represent a single class in future -- which is good for class manipulation and introspection -- I think we'd want to stop having 'newclass' futz with namespaces at all, leaving it up to the user to give it a name ... if any. Yes, Virginia, there are anonymous classes. :-) So it might look like: .HLL evillang .sub foo $P0 = newclass ... set_hll_global ['Perl6Str'], $P0 # Not a Perl 6 string, but an incredible simulation ... -- Chip Salzenberg [EMAIL PROTECTED] -- Chip Salzenberg [EMAIL PROTECTED]
Re: Easy Str === Str question: what is a reference type
On 7/12/06, Aaron Sherman wrote: There's a problem here, from my point of view. I'll take it one assumption at a time: * $whatever.asObject.id ~~ $whateverelse.asObject.id is true if and only if $whatever := $whateverelse at some point in the past, either explicitly, or through some sort of folding. * Str is a boxed type, and thus is a reference type * Thus, Str should be compared by .id and not by value, according to the above. So, IMHO, either there's a mistake in S03; Str is a special case WRT ===; or I misunderstand reference type (which S03 never defines). Well, Str is special insofar as it surely won't rely on the default .id comparison; as I see it, that's something objects get for free, because it makes sense in a lot of common situations (e.g. a typical Person class would consider each instance to represent a different person). * Str might be compared by .id, but .id for Str is based on the contents of its underlying storage... this worries me because it means that Strs with radically different meanings would be === because their encoding is different. Even though S03 doesn't say so, I'm sure that Str's .id will return some sort of value that includes not only the contents but anything else relevant, like the encoding. As for array-refs, I don't know why they couldn't (or shouldn't) be === if they contain the same values. That seems the least surprising way to go. A couple of other questions about S03: Any reference type may pretend to be a value type by defining a .id method which returns a built-in value, i.e. an immutable object or a native value, as specified in S06. Why does it have to be a built-in value (other than for performance)? It might be useful to return a value of some other type, which would in turn be checked for its .id's. Or does the problem lie in not being able to guarantee that we'd ever actually reach real built-in values? Because Perl 6 uses a false .id to signify a non-instantiated prototype, all instances should arrange to return a .id that boolifies to true. Does that mean all non-instances are equivalent? I can see that two non-existent Dog's might be considered the same thing, but not a non-existent Dog and a non-existent Cat. Or will $uninstantiated.id return something unique Cbut false? -David
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
On Wed, 2006-07-12 at 15:32 -0500, Jonathan Scott Duff wrote:
On Wed, Jul 12, 2006 at 04:16:13PM -0400, Aaron Sherman wrote:
On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
4. will we have a deep (possibly optimized[1]) equality operator, that
*will* return true for @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 );
op(@foo, @bar)?
Is it going to be easy to make the newbies use that when they mean it's
the
same, like they currently expect == and eq to work on simple values?
Isn't that ~~?
[...] # hmm, what kind of reduction IS that? ;)
~~ is really the all-purpose, bake-your-bread, clean-your-floors,
wax-your-cat operator that you're looking for.
Granted, ~~ will return true in that case. I think the main problem
is Yuval wants a guarantee that it will return true if and only if
the things on either side have the same deep structure and values.
Currently, ~~ will also return true for structures where this does
not hold. For example:
@a = ( [ 1, 2] , 3 );
@b = ( sub { return 1 }, sub { return 1 } );
@a ~~ @b; # true
Then ~~ is wrong in that respect, and I think we should be talking about
that, not about making === into ~~, but without invoking code when it
shouldn't.
Why is that true? By the rules of hyper-operation, it turns into
this:
[1,2] ~~ sub { return 1 }
3 ~~ sub { return 1 }
which is true if these return true values:
sub { return 1 }-([1,2])
sub { return 1 }-(3)
OK, so this always bothered me, I just wasn't sure why. Now I know, and
I think I agree with Yuval quite a bit more. ~~ should never imply
running it's data arguments as code *when dispatched at runtime*. It's:
* likely to cause security problems when I accidentally compare a
safe, internal structure that (probably unknown to me) contains
code against an unsafe, external structure that I got from a
user.
* potentially a destructive comparison.
* potentially not hyper-parallelization friendly
* probably bad in other ways I could think of, given time.
Let me boil that down to a simple assertion: comparison via ~~ which
will have to perform run-time dispatch should never Iexpect to have
side-effects (dynamic language, caveat, caveat...)
So, I do agree that we need a new operator, but I disagree about how it
should be used. I'd suggest:
C=~=
This is similar to C~~ for arguments that are simple value types such
as CInt or CStr.
For objects which do not have a C=~= operation, C=== is invoked.
By default, the only objects which will define a C=~= operation will
be containers, which will look like:
our Bool multi submethod infix:=~= ($a: Container $b) {
[] $a =~= $b;
}
which works for Hashes too, since a Pair is a container, so we'll just
recursively hyperoperate through each of the hash's .kv Pairs, comparing
them, though it might have to sort the Pairs by keys in order to assure
it's comparing apples to apples.
That's it. Just three types of behavior, unlike ~~s massive table of
behavior.
Then, in the table for C~~:
$_ $xType of Match ImpliedMatching Code
== = ==
...
Array Array arrays are comparablematch if $_ »=~=« $x
...
Any Any run-time dispatchmatch if infix:=~=($_, $x)
The first change is to Array/Array, and this is to minimize surprises
when comparing containers. There might be a special case for containers
that have typed buckets, but I'm not even going to touch that right now.
The second change is to Any/Any, and that's purely a matter of putting
the control in the hands of the caller, not whoever constructed the
caller's data. Anything else is a debugging nightmare.
In general, I would expect that no one would use =~= directly (hence the
ugly, name that's longer than ~~), it's just an implementation detail of
run-time dispatch on ~~
Thoughts?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines, but they don't work no more. -Shriekback
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
On Wed, Jul 12, 2006 at 16:16:13 -0400, Aaron Sherman wrote:
Isn't that ~~?
Per S03:
Array Array arrays are comparablematch if $_ »~~« $x
~~ is really the all-purpose, bake-your-bread, clean-your-floors,
wax-your-cat operator that you're looking for.
Not at all, because:
( [ 1, 2 ], 3 ) ~~ ( { 1 }, { 1 } )
It's matching, not equality.
which is true. Ain't recursive hyperoperators grand?
It isn't a hyperoperator, it's just recursive ;-)
2. is .id *always* a low level type representation of the object's value?
It's
specced that low level typed items have the same ID when they have the same
value. What about complex types?
It cannot be for complex types or even strings... well, at least it
Imust not be Iif we care about performance
That's orthogonal. .id is used for hash keys. If you're keying y
hubble images then they must be unique for some keyspace, and that's
where .id makes a mapping.
=:= looks in the symbol table (caveat dragons) to see if LHS
refers to the same variable as the RHS. Does this dereference?
Probably not, but I'm not sure, based on S03.
Then it's a purely lexical opeation, and it doesn't even work for
my $x := $array[3];
$x =:= $array[3];
but i'll pretend you didn't say that ;-)
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpkrsvQqGF99.pgp
Description: PGP signature
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
On Wed, Jul 12, 2006 at 16:16:13 -0400, Aaron Sherman wrote: The other way to think about === would be that it tells you if its LHS *could* be constant-folded onto its RHS (if it were constant for long enough) What is the benefit here? Because of the word deep. Deep implies arbitrary work, which isn't really what you want in such a low-level operator. However, using these operator, one could easily build whatever you like. The number of times i *sigh*ed at having to reinvent deep operators in a clunky way in Perl 5 is really not in line with Perlishness and DWIM. Also ~~ is deep in exactly the same way. Perl is also not low level. I could build it, and I have, but I don't want to. It can short circuit and be faster when the structure is definitely not the same (totally different early on) or definitely the same (refaddr is equal, etc). Should I go on? I'd avoid saying memory, here. Some implementations of Perl 6 might not know what memory looks like (on a sufficiently abstract VM). Slot -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpAR436ytaZh.pgp Description: PGP signature
Re: [TODO] Implement .loadlib pragma in IMCC
Leopold Toetsch wrote: This means, we'd have: .include file.pasm/.pir ... load macros or constants (no code) load_bytecode file.pbc ... load a module $P0 = loadlib file ... load a shared lib (pmc or ops) .loadlib file... same during compilation The 5 parameters are runtime vs. compile-time, C library vs. .pasm/.pir/.pbc, and inline a file. The .include directive doesn't actually load a library, it just inlines a file. (The reason it respects .HLL directives and such is not because it's incredibly smart, but because it's incredibly stupid. If you have .namespace directive in the inlined file, it will apply that namespace to any code in the original file that follows the .include directive.) I like .inline better than .include for this, but I also don't see any urgent need to change the name of the directive. I like .loadlib (for C libraries) as long as it's both compile and run time. That's the most common case of all, and so deserves the best syntax. And, the loadlib opcode is a clear parallel for the runtime variant. For the extremely rare case when you want to load a C library at compile-time but not at runtime, you can still use the loadlib opcode inside a :immediate sub. load_bytecode is good for runtime loading of PASM/PIR/PBC. A logical but unexplored option is compile-time loading of PASM/PIR/PBC. Some things that are currently being done with .include could be better expressed by a compile-and-run-time .load_bytecode directive. Allison
Re: [TODO] Implement .loadlib pragma in IMCC
On Wednesday 12 July 2006 16:11, Allison Randal wrote:
load_bytecode is good for runtime loading of PASM/PIR/PBC.
Except for the misleading name.
I wonder if there could be a variant that evaluates the code with the
appropriate compiler, too:
load_{something} 'file', 'compiler_name'
load_{something} 'file', compiler_pmc
-- c
Re: [svn:parrot] r13270 - trunk/languages/perl6
[EMAIL PROTECTED] wrote: Modified: trunk/languages/perl6/perl6.pir == --- trunk/languages/perl6/perl6.pir (original) +++ trunk/languages/perl6/perl6.pir Wed Jul 12 17:05:26 2006 @@ -24,9 +24,7 @@ .namespace [ 'Perl6' ] -.sub '__loadlib' :immediate -$P1 = loadlib 'perl6_group' -.end +.loadlib 'perl6_group' .sub '__onload' :load $P1 = loadlib 'perl6_group' If Leo's comment about .loadlib being compile-and-runtime is already implemented, then you should be able to eliminate that runtime call to the loadlib opcode too. Allison
Re: [TODO] Implement .loadlib pragma in IMCC
chromatic wrote:
On Wednesday 12 July 2006 16:11, Allison Randal wrote:
load_bytecode is good for runtime loading of PASM/PIR/PBC.
Except for the misleading name.
Oh, you mean the fact that much of the time it's not loading bytecode at
all? It has crossed my mind, but the irritation hasn't been great enough
to make it worth changing the name of an existing opcode that didn't
otherwise need changing.
I wonder if there could be a variant that evaluates the code with the
appropriate compiler, too:
load_{something} 'file', 'compiler_name'
load_{something} 'file', compiler_pmc
Hmmm... a compile-and-runtime version of that could potentially compile
the source to bytecode at compile-time, and then load the bytecode at
runtime.
Not urgent, but there is long-term potential there.
Allison
[svn:perl6-synopsis] r10156 - doc/trunk/design/syn
Author: larry
Date: Wed Jul 12 18:05:24 2006
New Revision: 10156
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
Log:
Clarifications from Smylers++ and ajs++.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podWed Jul 12 18:05:24 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 10 Aug 2004
- Last Modified: 10 July 2006
+ Last Modified: 12 July 2006
Number: 2
- Version: 49
+ Version: 50
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -1215,7 +1215,7 @@
way, but with any radix it's not clear whether the exponentiator should
be 10 or the radix, and this makes it explicit:
-0b1.1e10illegal, could be read as any of:
+0b1.1e10ILLEGAL, could be read as any of:
:21.1 * 2 ** 10 1536
:21.1 * 10 ** 10 15,000,000,000
@@ -1747,15 +1747,15 @@
or a method call in dot form. (It is also allowed on a label when a
statement is expected.) So for any undeclared identifier Cfoo:
-foo.bar# foo().bar -- illegal postfix, must use foo().bar
+foo.bar# ILLEGAL -- postfix must use foo().bar
foo .bar # foo($_.bar) -- no postfix starts with whitespace
-foo\ .bar # foo().bar -- illegal long dot, use foo()\ .bar
-foo++ # foo()++ -- illegal postfix, must use foo()++
+foo\ .bar # ILLEGAL -- long dot must use foo()\ .bar
+foo++ # ILLEGAL -- postfix must use foo()++
foo 1,2,3 # foo(1,2,3)-- args always expected after listop
foo + 1# foo(+1) -- term always expected after listop
foo; # foo();-- no postfix, but no args either
foo: # label -- must be label at statement boundary.
- -- illegal otherwise
+ -- ILLEGAL otherwise
foo: bar: # two labels in a row, okay
.foo: # $_.foo: 1 -- must be dot method with : args
.foo(1)# $_.foo(1) -- must be dot method with () args
@@ -1768,13 +1768,13 @@
foo $bar: 1# $bar.foo(1) -- indirect object even if
declared sub
-- $bar considered one token
foo (bar()): # bar().foo(1) -- even if foo declared sub
-foo bar(): # illegal -- bar() is two tokens.
+foo bar(): # ILLEGAL -- bar() is two tokens.
foo .bar: # foo(.bar:)-- colon chooses .bar to listopify
foo bar baz: 1 # foo(baz.bar(1)) -- colon controls bar, not foo.
foo (bar baz): 1 # bar(baz()).foo(1) -- colon controls foo
-$foo $bar # illegal -- two terms in a row
-$foo $bar: # illegal -- use $bar.$foo for indirection
-(foo bar) baz: 1 # illegal -- use $baz.$(foo bar) for indirection
+$foo $bar # ILLEGAL -- two terms in a row
+$foo $bar: # ILLEGAL -- use $bar.$foo for indirection
+(foo bar) baz: 1 # ILLEGAL -- use $baz.$(foo bar) for indirection
The indirect object colon only ever dominates a simple term, where
simple includes classes and variables and parenthesized expressions,
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podWed Jul 12 18:05:24 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 8 Mar 2004
- Last Modified: 10 Jul 2006
+ Last Modified: 12 Jul 2006
Number: 3
- Version: 45
+ Version: 46
=head1 Changes to existing operators
@@ -249,18 +249,18 @@
say foo ($bar+1),$baz say(foo($bar+1, $baz));
say foo .($bar+1),$baz say(foo($_.($bar+1), $baz));
-say foo[$bar+1],$baz illegal, need foo()[]
-say foo.[$bar+1],$baz illegal, need foo().[]
+say foo[$bar+1],$baz ILLEGAL, need foo()[]
+say foo.[$bar+1],$baz ILLEGAL, need foo().[]
say foo [$bar+1],$baz say(foo([$bar+1], $baz));
say foo .[$bar+1],$baz say(foo($_.[$bar+1], $baz));
-say foo{$bar+1},$baz illegal, need foo(){}
-say foo.{$bar+1},$baz illegal, need foo().{}
+say foo{$bar+1},$baz ILLEGAL, need foo(){}
+say foo.{$bar+1},$baz ILLEGAL, need foo().{}
say foo {$bar+1},$baz say(foo({$bar+1}, $baz));
say foo .{$bar+1},$baz say(foo($_.{$bar+1}, $baz));
-say
_group in library name (was Re: r13272 - in trunk: compilers/imcc docs/imcc src)
On Wed, Jul 12, 2006 at 05:29:08PM -0700, [EMAIL PROTECTED] wrote: * Apply heuristics that tells .loadlib 'perl6_group' # HLL dynamic PMCs and .loadlib 'dynlexpad'# non-HLL dynamic PMCs apart, by locating the '_group substring inside the library name. Urque, that's really not OK even in the short term. Could you alter it to use an adverb: .loadlib 'perl6_group' :hll please? PS: yes, I am planning to standardize on lower case for pir directives PPS: yes, I am planning to let the upper-case .HLL work for a -long- time :-) -- Chip Salzenberg [EMAIL PROTECTED]
[perl #39808] [PATCH] Allows execution of a single configure step such as rebuilding language makefiles
# New Ticket Created by Kevin Tew
# Please include the string: [perl #39808]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39808
example:
perl Configure --step=gen::languages
Configure.pl | 12 +++
lib/Parrot/Configure.pm | 135
+++
lib/Parrot/Configure/Data.pm | 20 ++
3 files changed, 116 insertions(+), 51 deletions(-)
Index: lib/Parrot/Configure/Data.pm
===
--- lib/Parrot/Configure/Data.pm(revision 13269)
+++ lib/Parrot/Configure/Data.pm(working copy)
@@ -171,6 +171,26 @@
return keys %{$self-{c}};
}
+=item Cslurp()
+
+Slurps in Parrot::Config data from previous configure.
+
+Accepts no arguments.
+
+=cut
+
+sub slurp()
+{
+ my $self = shift;
+
+ my $res = eval {
+use Parrot::Config;
+\%PConfig
+ };
+
+ $self-{c} = $res;
+}
+
=item Cdump()
Provides a LData::Dumper serialized string of the objects key/value pairs
Index: lib/Parrot/Configure.pm
===
--- lib/Parrot/Configure.pm (revision 13269)
+++ lib/Parrot/Configure.pm (working copy)
@@ -197,74 +197,111 @@
my $n = 0; # step number
foreach my $task ($self-steps) {
-my $step_name = $task-step;
-my @step_params = @{$task-params};
-
$n++;
+$self-_runstep($task, $verbose_step, $ask, $n);
+}
+return $self;
+}
-eval use $step_name;;
-die $@ if $@;
+=item * Crunstep()
-my $step = $step_name-new;
+The invoking
+LParrot::Configure object is passed as the first argument to each steps
+Crunstep() method followed by any parameters that were registered for that
+step.
-# XXX This works. but is probably not a good design.
-# Using $step-description() would be nicer
-my $description = $step-description();
-$description = unless defined $description;
+Accepts no arguments and returns a LParrot::Configure object.
-# set per step verbosity
-if (defined $verbose_step) {
+=cut
-# by step number
-if ($verbose_step =~ /^\d+$/ $n == $verbose_step) {
-$self-options-set(verbose = 2);
-}
-# by description
-elsif ($description =~ /$verbose_step/) {
-$self-options-set(verbose = 2);
-}
+sub runstep
+{
+my $self = shift;
+my $taskname = shift;
+
+my ($verbose, $verbose_step, $ask) =
+$self-options-get(qw(verbose verbose-step ask));
+
+for my $task ($self-steps()) {
+if ( $task-{Parrot::Configure::Task::step} eq $taskname ) {
+print $taskname\n;
+$self-_runstep($task, $verbose, $verbose_step, $ask, 1);
}
+}
+}
-# XXX cc_build uses this verbose setting, why?
-$self-data-set(verbose = $verbose) if $n 2;
+sub _runstep
+{
+my $self = shift;
+my $task = shift;
-print \n, $description, '...';
-print \n if $verbose $verbose == 2;
+my ($verbose, $verbose_step, $ask, $n) = @_;
-my $ret; # step return value
-eval {
-if (@step_params) {
-$ret = $step-runstep($self, @step_params);
-} else {
-$ret = $step-runstep($self);
-}
-};
-if ($@) {
-carp \nstep $step_name died during execution: [EMAIL PROTECTED];
-return;
+my $step_name = $task-step;
+my @step_params = @{$task-params};
+
+
+eval use $step_name;;
+die $@ if $@;
+
+my $step = $step_name-new;
+
+# XXX This works. but is probably not a good design.
+# Using $step-description() would be nicer
+my $description = $step-description();
+$description = unless defined $description;
+
+# set per step verbosity
+if (defined $verbose_step) {
+
+# by step number
+if ($verbose_step =~ /^\d+$/ $n == $verbose_step) {
+$self-options-set(verbose = 2);
}
-# did the step return itself?
-eval { $ret-can('result'); };
-# if not, report the result and return
-if ($@) {
-my $result = $step-result || 'no result returned';
-carp \nstep $step_name failed: . $result;
-return;
+# by description
+elsif ($description =~ /$verbose_step/) {
+$self-options-set(verbose = 2);
}
+}
-my $result = $step-result || 'done';
+# XXX cc_build uses this verbose setting, why?
+$self-data-set(verbose = $verbose) if $n 2;
-print ... if $verbose $verbose == 2;
-print . x (71 - length($description) - length($result));
-print $result. unless $step =~ m{^inter/} $ask;
+print \n, $description, '...';
+print \n if $verbose $verbose ==
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
Yuval Kogman wrote: On Wed, Jul 12, 2006 at 17:58:03 -0400, Aaron Sherman wrote: Then ~~ is wrong in that respect, and I think we should be talking about that, not about making === into ~~, but without invoking code when it shouldn't. But it should! It's the smart match! If the rhs matches the code ref (the code ref gets it as an argument it's a match! That's why ~~ isn't a comparison operator, but a smart match operator - it DWIMs *very* deeply DWIM generally means don't shoot me in the head for trying this, and it can be strongly argued that CAny ~~ Any is almost certain to shoot you in the head a couple of times in your P6 career if we don't fix it. Now, I'm all for every single case that Larry put in the table for Smart Matching in S03... EXCEPT FOR RUNTIME DISPATCH! There are only two cases of runtime dispatch in there that you could possibly invoke: Array/Array and Any/Any. Fix those two, and I think ~~ DWIMs safely and just as powerfully (perhaps much more so). My suggestion (falling back to a much simpler and less dynamic =~= for runtime dispatch) is one way to fix them, and I think that if we DO fix them in that manner, then no one's expectations will be violated (unless you expected C@a1 ~~ @a2 to be shorthand for a function vector, dot-product-like, parallel dispatch, in which case I'm going to make the suggestion that you quietly retire from public life and find a nice place in the mountains. ;-) Really, all of the magic on ~~ isn't intended for such runtime traversal of containers. it's intended for the immediate semantic value of the compile-time typed match, most notably in the case of given which has more connotations to hang semantic meaning off of in English. To invoke those special rules when recursively evaluating the sameness of containers doesn't even make sense if you stop and consider why you would do such a comparison. Why is C$a ~~ $b going to invoke code when I know nothing about $a and $b at compile time? Is that useful other than in defining an alias for ~~?
Re: Another quick one: .asancestor
On Wed, Jul 12, 2006 at 12:51:57PM -0400, Aaron Sherman wrote:
: I would assume that all classes automatically define:
:
: multi submethod *infix:as ($self: $?CLASS) { $self }
Hmm, as is really only intended for explicit type mutation (which
can work either by role mixin or by new object construction). It's
not intended to give Perl a different view of an unmutated object.
: so that derived classes can automatically:
:
: $obj.asancestor
Nit: that's illegal syntax. Or rather, it's legal, but you're saying
$obj.as.{'ancestor'}
which is an attempt to do a hash subscript on whatever .as returns.
Only () and : cause arguments to be passed to .as. So you have to
write one of
$obj.as(Foo)# or .(Foo), \.(Foo), etc.
$obj.as: Foo
(Note that those work because Foo is predeclared, presumably.)
: Without actually changing their implementation details (only the type
: that Perl currently thinks it's dealing with polymorphically).
Perl doesn't keep track of that in general except by marking a container
at compile time with the expected type. But an object is always just
itself, unless you go through some kind of proxy or container.
: In fact, I would expect that this bit of behind-the-curtain magic is how
: the MCP arranges for polymorphism when you:
:
: sub foo(Object $x) {...}
: my A $y;
: foo($y);
If you ask for the type of $x within foo(), it will tell you A, not Object.
(The type of variable($x) is Object, however.)
The behind-the-curtain polymorphic magic you're thinking of is really
handled within the various dispatchers, which call various methods
as if they were subroutines rather than methods. That's how the
lying happens, generally.
Larry
[perl #39809] PGE crash on parrot;PGE::Exp::Quant;reduce
# New Ticket Created by Chris Dolan
# Please include the string: [perl #39809]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39809
---
osname= darwin
osvers= 8.0
arch= darwin-thread-multi-2level
cc= cc
---
Flags:
category=core
severity=medium
ack=no
---
As simple token containing :i causes PGE to crash with an attempted
method call on Undef.
Steps to reproduce:
1) Create a grammar file called foo.pg that has one line:
token foo { :i a }
2) Run this command:
./parrot compilers/pge/pgc.pir --output=foo.pir foo.pg
Actual results:
set_integer_keyed() not implemented in class 'Undef'
current instr.: 'parrot;PGE::Exp::Quant;reduce' pc 4333
(compilers/pge/PGE/Exp.pir:396)
called from Sub 'parrot;PGE::Exp::Concat;reduce' pc 4098
(compilers/pge/PGE/Exp.pir:316)
called from Sub 'parrot;PGE::Exp;root_pir' pc 3609 (compilers/pge/
PGE/Exp.pir:69)
called from Sub 'parrot;PGE::P6Regex;compile_p6regex' pc 6244
(compilers/pge/PGE/P6Regex.pir:123)
called from Sub 'parrot;PGE::P6Grammar;regex_stmt' pc 622
(compilers/pge/pgc.pir:336)
called from Sub 'parrot;PGE::P6Grammar;compile_p6grammar' pc 345
(compilers/pge/pgc.pir:225)
called from Sub 'parrot;PGE::P6Grammar;main' pc 135 (compilers/
pge/pgc.pir:111)
Expected results:
Either a successful compile or a more understandable syntax error
Reproducibility:
Reproduced on G5 Mac OS X 10.4.7, parrot r13176
Reproduced on x86 FreeBSD 5.4, parrot r13181
Reproduced on x86 Linux 7.x, parrot r13181
---
Summary of my parrot 0.4.5 (r13176) configuration:
configdate='Thu Jul 6 00:20:50 2006'
Platform:
osname=darwin, archname=darwin-thread-multi-2level
jitcapable=1, jitarchname=ppc-darwin,
jitosname=DARWIN, jitcpuarch=ppc
execcapable=1
perl=perl
Compiler:
cc='cc', ccflags='-g -pipe -fno-common -no-cpp-precomp -I/usr/
local/include
-pipe -fno-common -Wno-long-double -I/sw/include -I/sw/include',
Linker and Libraries:
ld='c++', ldflags='-L/usr/local/lib -flat_namespace -L/sw/lib -
L/sw/lib',
cc_ldflags='',
libs='-lm -lgmp -lreadline'
Dynamic Linking:
share_ext='.dylib', ld_share_flags='-dynamiclib -undefined
suppress',
load_ext='.bundle', ld_load_flags='-bundle -undefined suppress'
Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=4321,
nv=double, numvalsize=8, doublesize=8
---
Environment:
DYLD_LIBRARY_PATHHOMELANGLANGUAGELC_ALL
LD_LIBRARY_PATH LOGDIRPATHPERL5LIB
PERL5_CPANPLUS_CONFIGSHELL
Re: [perl #39809] PGE crash on parrot;PGE::Exp::Quant;reduce
On Wed, Jul 12, 2006 at 08:04:01PM -0700, Chris Dolan wrote:
As simple token containing :i causes PGE to crash with an attempted
method call on Undef.
Steps to reproduce:
1) Create a grammar file called foo.pg that has one line:
token foo { :i a }
As I read S05, a modifier has to occur at the *very* beginning
of a regex (or group) in order to work. In other words, no whitespace
before modifiers in a regex (because whitespace may have some
other meta-syntactic meaning with :sigspace). Thus
token foo {:i a }
works, while
token foo { :i a }
is an error, since the ':' acts as a cut operator that doesn't
have anything to cut.
But I admit that since we've gone to regex/token/rule, then perhaps
leading whitespace prior to a modifier should be ignored. That
probably needs a ruling from p6l or @Larry.
Pm
Re: [perl #39809] PGE crash on parrot;PGE::Exp::Quant;reduce
On Jul 12, 2006, at 10:53 PM, Patrick R. Michaud wrote:
On Wed, Jul 12, 2006 at 08:04:01PM -0700, Chris Dolan wrote:
As simple token containing :i causes PGE to crash with an attempted
method call on Undef.
Steps to reproduce:
1) Create a grammar file called foo.pg that has one line:
token foo { :i a }
As I read S05, a modifier has to occur at the *very* beginning
of a regex (or group) in order to work. In other words, no whitespace
before modifiers in a regex (because whitespace may have some
other meta-syntactic meaning with :sigspace). Thus
token foo {:i a }
works, while
token foo { :i a }
is an error, since the ':' acts as a cut operator that doesn't
have anything to cut.
But I admit that since we've gone to regex/token/rule, then perhaps
leading whitespace prior to a modifier should be ignored. That
probably needs a ruling from p6l or @Larry.
Pm
Ahh, that makes sense. So it's possibly just an uncaught syntax
error, and definitely a syntax error under :sigspace. I propose that
P6Regex.pir gets something like:
parse_error(mob, pos, Too late for modifier)
but I have not yet figured out where it belongs in P6Regex.pir.
On a related note, I don't see any regression tests for syntactically
incorrect regexps. I'm good at writing invalid regexps :-) so if
someone starts a stub .t file for syntax errors, I'd be happy to
populate it with TODO tests like the above.
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [perl #39715] [TODO] #39715 IMCC errors should throw Parrot exceptions
On Wednesday 12 July 2006 22:02, Vishal Soni via RT wrote: This patch also introduces a Parrot API for the calling programs to compile the code. Currently pugs uses immc_compile() call into IMCC. Ideally Pugs should not be communicating with IMCC but with Parrot. This new API will try to hide IMCC/PASM compile details from programming languages PARROT_API PMC *Parrot_compile_string(Parrot_Interp interpreter, STRING *type, char *code, STRING **error); PARROT_API void *Parrot_compile_file(Parrot_Interp interpreter,char *fullname, String **error); I like this interface, except for the return value from Parrot_compile_file. Are there other options, such as returning a Sub PMC? -- c
Re: [perl #39715] [TODO] #39715 IMCC errors should throw Parrot exceptions
PARROT_API void *Parrot_compile_file(Parrot_Interp interpreter,char *fullname, String **error); I like this interface, except for the return value from Parrot_compile_file. Are there other options, such as returning a Sub PMC? Chip and I have had a chat about other possible API's which could be added in future. Some e.g. 1. To throw Parrot exceptions instead of the String **error. 2. Possibly using Compiler PMC. (not sure on that yet) Your suggestion is good and I will keep in mind. These two functions are just a start for defining Compile API's. Programming languages should not talk directly to IMCC or any other low level compiler like IMCC and PASM. Thanks for your suggestion. Vishal
[perl #39810] [PATCH] regression tests for P6Regex syntax errors
# New Ticket Created by Chris Dolan # Please include the string: [perl #39810] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39810 This patch adds a new syntax_errors.t file with some known broken regexps. This is intended to exercise the PGE::P6Regex error catching code. This patch includes one TODO test for an unhandled P6Regexp error described in [perl #39809]. The patch also includes a new p6rule_throws() method in Parrot::Test::PGE % diffstat pge_syntax_errors.patch lib/Parrot/Test/PGE.pm | 50 +++ + t/compilers/pge/p6regex/syntax_errors.t | 44 +++ + 2 files changed, 94 insertions(+) Chris pge_syntax_errors.patch Description: Binary data
