Re: [perl #49714] [PATCH] Extend perl6 spectest to fetch and execute S04-S29 tests
Jerry Gay via RT wrote: applied as r24965. it's causing a heck of a lot of failing tests. however, i'll leave them in for a day or three, while we see what we can do to get them passing. hint: getting 'fudge' working on rakudo would do us a world of good. ~jerry Do you mean running: perl6.exe util/fudge or extending languages/perl6 to run the tests correctly? In the first case, I don't get exactly the "why"... -- Cosimo
[perl #49912] [BUG] Unable to Configure using Borland C
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #49912] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=49912 > The following text shows the result of attempting to install Parrot using bcc32. The program appeared to hang at the "Generating CPU specific stuff" stage until killed. C:\parrot>Configure.pl --cc=bcc32 Parrot Version 0.5.2 Configure 2.0 Copyright (C) 2001-2007, The Perl Foundation. Hello, I'm Configure. My job is to poke and prod your system to figure out how to build Parrot. The process is completely automated, unless you passed in the `--ask' flag on the command line, in which case I'll prompt you for a few pieces of info. Since you're running this program, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking MANIFEST.done. Setting up Configure's default values.done. Setting up installation paths.done. Tweaking settings for miniparrot...skipped. Loading platform and local hints filesdone. Finding header files distributed with Parrot..done. Determining what C compiler and linker to use.done. Determining whether make is installed..yes. Determining whether lex is installed...skipped. Determining whether yacc is installed..skipped. Determining if your C compiler is actually gcc..no. Determining whether libc has the backtrace* functions (glibc only)..no. Determining Fink location on Darwinskipped. Determining if your C compiler is actually Visual C++...no. Detecting compiler attributes (-DHASATTRIBUTE_xxx)done. Detecting supported compiler warnings (-Wxxx)..skipped. Enabling optimization...no. Determining flags for building shared libraries...done. Determine if parrot should be linked against a shared library...no. Determining what charset files should be compiled in..done. Determining what encoding files should be compiled in.done. Determining what types Parrot should use..done. Determining what opcode files should be compiled in...done. Determining what pmc files should be compiled in..done. Determining your minimum pointer alignment. 1 byte. Probing for C headers.done. Determining some sizesdone. Computing native byteorder for Parrot's wordsize.little-endian. Test the type of va_ptr (this test is likely to segfault)stack. Figuring out how to pack() Parrot's types.done. Figuring out what formats should be used for sprintf..done. Determining if your C library has a working S_ISREGyes. Determining CPU architecture and OS...done. Determining architecture, OS and JIT capability...done. Generating CPU specific stuff...Terminating on signal SIGINT(2)
POD in the test suite
I noticed that many test files contain "old" POD like this: =pod some description here =cut Should that all be replaced by the new POD? =begin description text here =end description -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
[perl #49910] "3e4" does not parse as 30000
binw4ZB5qqTyC.bin Description:
[perl #49898] [PATCH] .chars method for Str
applied with modifications as r24962. ~jerry
[perl #49912] [BUG] Unable to Configure using Borland C
On Thu Jan 17 17:26:45 2008, [EMAIL PROTECTED] wrote: > The following text shows the result of attempting to install Parrot > using > bcc32. The program appeared to hang at the "Generating CPU specific > stuff" > stage until killed. > > C:\parrot>Configure.pl --cc=bcc32 > Parrot Version 0.5.2 Configure 2.0 > Copyright (C) 2001-2007, The Perl Foundation. > > Hello, I'm Configure. My job is to poke and prod your system to figure > out > how to build Parrot. The process is completely automated, unless you > passed in > the `--ask' flag on the command line, in which case I'll prompt you > for a few > pieces of info. > > Since you're running this program, you obviously have Perl 5--I'll be > pulling > some defaults from its configuration. > > Checking > MANIFEST.done. > Setting up Configure's default > values.done. > Setting up installation > paths.done. > Tweaking settings for > miniparrot...skipped. > Loading platform and local hints > filesdone. > Finding header files distributed with > Parrot..done. > Determining what C compiler and linker to > use.done. > Determining whether make is > installed..yes. > Determining whether lex is > installed...skipped. > Determining whether yacc is > installed..skipped. > Determining if your C compiler is actually > gcc..no. > Determining whether libc has the backtrace* functions (glibc > only)..no. > Determining Fink location on > Darwinskipped. > Determining if your C compiler is actually Visual > C++...no. > Detecting compiler attributes (- > DHASATTRIBUTE_xxx)done. > Detecting supported compiler warnings (- > Wxxx)..skipped. > Enabling > optimization...no. > Determining flags for building shared > libraries...done. > Determine if parrot should be linked against a shared > library...no. > Determining what charset files should be compiled > in..done. > Determining what encoding files should be compiled > in.done. > Determining what types Parrot should > use..done. > Determining what opcode files should be compiled > in...done. > Determining what pmc files should be compiled > in..done. > Determining your minimum pointer alignment. 1 > byte. > Probing for C > headers.done. > Determining some > sizesdone. > Computing native byteorder for Parrot's wordsize.little- > endian. > Test the type of va_ptr (this test is likely to > segfault)stack. > Figuring out how to pack() Parrot's > types.done. > Figuring out what formats should be used for > sprintf..done. > Determining if your C library has a working > S_ISREGyes. > Determining CPU architecture and > OS...done. > Determining architecture, OS and JIT > capability...done. > Generating CPU specific stuff...Terminating on signal SIGINT(2) > When using a non-default C compiler, you will usually need to add a --link to the Configure line. So, something like... Configure.pl --cc=bcc32 --link=bcc32 should work. Steve
Re: POD in the test suite
On Fri, Jan 18, 2008 at 10:54:11AM +0100, Moritz Lenz wrote: : I noticed that many test files contain "old" POD like this: : : =pod : : some description here : : =cut : : : Should that all be replaced by the new POD? : : =begin description : : text here : : =end description Jah, so glaube ich. Larry
Re: [perl #49912] [BUG] Unable to Configure using Borland C
On Jan 17, 2008 5:26 PM, via RT arocker @ vex. net <[EMAIL PROTECTED]> wrote: > # New Ticket Created by [EMAIL PROTECTED] > # Please include the string: [perl #49912] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=49912 > > > > The following text shows the result of attempting to install Parrot using > bcc32. The program appeared to hang at the "Generating CPU specific stuff" > stage until killed. > would you mind running again with --verbose added to your flags, and attaching that output? it'll give us much more to go on. thanks for reporting. ~jerry
[perl #45137] [TODO] Add a revision control test in Configure.pl
The patch attached refactors lib/Parrot/Revision.pm and all the files
that use it directly or indirectly.
On Tue Jan 15 09:31:18 2008, [EMAIL PROTECTED] wrote:
> Having looked a bit more at Parrot::Revision and the instances where it
> is used, I *think* we can make it go away completely, at least as a
> separate module, and incorporate its functionality within
> config/auto/revision.pm.
>
> [li11-226:parrot] 508 $ fns . | xargs egrep -l 'Parrot(\/|::)Revision'
> ./tools/build/revision_c.pl
> ./lib/Parrot/Revision.pm
Both revised.
> ./t/configure/018-revision.t
> ./t/configure/017-revision_no_DEVELOPING.t
Renamed; new content.
> ./t/postconfigure/04-revision.t
> ./t/postconfigure/03-revision_no_DEVELOPING.t
Go bye-bye.
> ./t/distro/file_metadata.t
No longer uses Parrot::Revision.
> ./t/steps/auto_revision-01.t
> ./config/auto/revision.pm
> ./MANIFEST
>
Refactored as needed.
Note: Application of the patch attached entails a change in behavior.
It will no longer be possible to say:
svn update
perl Configure.pl
svn update (assuming a new revision number is displayed)
make
... and be able to make 'successfully'. tools/build/revision_c.pl will
now die should you try to do so.
I put 'successfully' in quotes because the current behavior is that if
you do an svn update and get updated files after configuration but
before build -- meaning your build no longer strictly corresponds to a
single state in the repository -- you can run 'make' to its conclusion
but when you call 'parrot --version' you will get warnings. But to
respond to those warnings you have to do what you should have done in
the first place, namely, go directly from configuration to build.
Eliminating this toleration for bad programming practices simplified the
code considerably!
Please review. I'll apply in 2-3 days if there is no objection. Thank
you very much.
kid51
Index: tools/build/revision_c.pl
===
--- tools/build/revision_c.pl (revision 24983)
+++ tools/build/revision_c.pl (working copy)
@@ -22,46 +22,16 @@
use warnings;
use strict;
use lib qw{lib . ../lib ../../ lib};
-use Parrot::Revision;
+use Parrot::Revision::Utils qw(
+get_revision_numbers
+print_src_revision_c
+);
-print <<"EOF";
-/* ex: set ro:
- * !!! DO NOT EDIT THIS FILE !!!
- *
- * This file is generated automatically by $0.
- *
- * Any changes made here will be lost!
- *
- */
+my ($current, $config) = get_revision_numbers();
+exit 1 unless ( $current == $config );
-/* HEADERIZER HFILE: none */
-/* HEADERIZER STOP */
+print_src_revision_c($current, $config, $0);
-#include "parrot/config.h"
-
-/* also in "parrot/embed.h" */
-PARROT_API int Parrot_revision(void);
-/* also in "parrot/misc.h" */
-PARROT_API int Parrot_config_revision(void);
-
-int Parrot_revision(void)
-{
-return ${Parrot::Revision::current};
-}
-
-int Parrot_config_revision(void)
-{
-return ${Parrot::Revision::config};
-}
-
-/*
- * Local variables:
- * c-file-style: "parrot"
- * End:
- * vim: expandtab shiftwidth=4:
- */
-EOF
-
# Local Variables:
# mode: cperl
# cperl-indent-level: 4
Index: MANIFEST
===
--- MANIFEST(revision 24983)
+++ MANIFEST(working copy)
@@ -1,7 +1,7 @@
# ex: set ro:
# $Id$
#
-# generated by C:\usr\local\parrot\trunk\tools\dev\mk_manifest_and_skip.pl Fri
Jan 18 22:14:41 2008 UT
+# generated by tools/dev/mk_manifest_and_skip.pl Sat Jan 19 03:20:22 2008 UT
#
# See tools/dev/install_files.pl for documentation on the
# format of this file.
@@ -2560,6 +2560,7 @@
lib/Parrot/Pmc2c/UtilFunctions.pm [devel]
lib/Parrot/Pmc2c/VTable.pm [devel]
lib/Parrot/Revision.pm [devel]
+lib/Parrot/Revision/Utils.pm[devel]
lib/Parrot/Test.pm [devel]
lib/Parrot/Test/APL.pm [devel]
lib/Parrot/Test/Cardinal.pm [devel]
@@ -3079,8 +3080,8 @@
t/configure/013-die.t []
t/configure/015-no_return.t []
t/configure/016-no_return_but_result.t []
-t/configure/017-revision_no_DEVELOPING.t[]
-t/configure/018-revision.t []
+t/configure/017-revision_from_cache.t []
+t/configure/018-revision_to_cache.t []
t/configure/019-version.t []
t/configure/020-version.t []
t/configure/021-version.t []
@@ -3365,8 +3366,6 @@
t/pmc/vtablecache.t []
t/postconfigure/01-options.t[]
t/postconfigure/02-data_slurp.t
Re: [perl #49912] [BUG] Unable to Configure using Borland C
> > When using a non-default C compiler, you will usually need to add a > --link to the Configure line. So, something like... > > Configure.pl --cc=bcc32 --link=bcc32 > Doesn't appear to make any difference. -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: [svn:perl6-synopsis] r14491 - doc/trunk/design/syn
On Thu, Jan 17, 2008 at 10:56:12PM -0600, Patrick R. Michaud wrote: : On Thu, Jan 17, 2008 at 01:18:32PM -0800, [EMAIL PROTECTED] wrote: : > +=item * : > + : > +The definition of C<.true> for the most ancestral type (that is, the : > +C type) is equivalent to C<.defined>. : : Would we normally consider prefix: to be defined in terms of : C<.true>, or vice versa? Is there a prefix:, or is C : treated like an 'is export' trait on '.true' method? There's a sense in which those are all just aliases for the same operation, and a sense in which the .true method is more basic. The sense in which it is more basic is that the object is in charge of single dispatch, but it is not in charge of multiple dispatch. And all operators and function calls are considered multiple dispatch, hence they do not "belong" to the object. As for whether the ordinary export mechanism handles it, I'm not sure. S03 defines both prefix: and prefix: at different precedence levels than an ordinary true() function would work, and we don't have a mechanism under "is export" for giving multiple names, let alone different precedence levels. So to a first approximation, prefix: and prefix: are defined separately and just call into .true. Another ramification of the single/multiple dispatch distinction is that if you call $obj.true on an object created in a foreign language, it probably calls the .true as defined by the other language. Perl is agnostic about what happens behind .HOW is another way of saying it, and foreign objects are allowed to have their own idea of .HOW to call methods. But if you say "true $obj" you are calling Perl's true operator, which might default to .true, or it might not, if you've given a different multi defininition of prefix: for that foreign type. So Perl's $a + $b is guaranteed to keep numeric semantics even when calling two objects in a language that uses '+' for concatenation. However, $a.'+'($b) is going to try to call the '+' method on $a in the foreign language, and is likely to do concatenation if calling into a language that abuses overloading that way. : Is there also a C<.not> method? While we could force people to write things like (not $obj.foo).bar it seems like it could be useful when the general data flow is left-to-right in a series of method calls: $obj.foo.not.bar And I don't see how it can hurt much. And $obj.foo.prefix:.bar seems a bit tortuous, even if it ends up having the same effect. Though it's not quite the same, since the prefix presumably forces a multiple dispatch to Perl's idea of notiness, while a direct .not method would rely on the the object's notion of notiness. This is probably a good distinction for cross-language programming. So I think Object should define a default .not that is defined in terms of .true. If a Perl class wants to override that, it's probably because it has a more efficient .not test, and wants to define .true in terms of .not instead. Larry
Re: [svn:perl6-synopsis] r14491 - doc/trunk/design/syn
On Fri, Jan 18, 2008 at 09:16:39AM -0800, Larry Wall wrote: : Though it's not quite the same, since the prefix presumably forces : a multiple dispatch to Perl's idea of notiness, while a direct .not : method would rely on the the object's notion of notiness. This is : probably a good distinction for cross-language programming. : : So I think Object should define a default .not that is defined in : terms of .true. If a Perl class wants to override that, it's : probably because it has a more efficient .not test, and wants to : define .true in terms of .not instead. It occurs to me that a foreign object might not *have* a .not method, especially if it's not a boolean type. So I think if the foreign language dispatch fails, it should try to redispatch to any ancestors it thinks it has in Perl space, Object if nothing else. That would at least allow an attempt at mapping .not to !.true. But maybe that means that Object's definition of .not should be !true($obj) to give P6 multis a shot at defining truth for the foreign object before calling into the (probably non-existent) .true method on the foreign object. I figure if it's not a boolean type, it probably won't have either .not or .true, and P6's prefix: for that type probably needs to compare the value to 0 or "" or some such. Or maybe Object's definition of truth can be sophisticated enough to notice foreign influences and compensate for them. Seems like something MD would be good at though. All that being said, we want boolean tests to be *fast*, so since prefix: et al. have proto definitions, we probably can do some decent inlining in lexical scopes where the set of truth multis is known at compile time. Larry
[perl #42360] [TODO]: Unit tests for Parrot::Revision
On Wed Sep 12 17:50:04 2007, [EMAIL PROTECTED] wrote: > On Sat May 05 10:05:58 2007, [EMAIL PROTECTED] wrote: > > On Sat May 05 10:04:24 2007, jkeen at verizon.net wrote: > > > Patch applied in r18427 May 05 2007. > > > > I'm leaving the ticket open in the hope that some project member who > > uses SVK for version > > control can add tests for that VCS under t/configure/ and > > t/postconfigure/. > > 4 months later ... and no response from SVK users! Can anyone give me > some feedback here? (I'd like to close the ticket.) > I'm throwing in the towel on the question of getting unit tests for the SVK or GIT portions of this package. Closing ticket.
Re: [perl #45137] [TODO] Add a revision control test in Configure.pl
On Jan 18, 2008 7:39 PM, James Keenan via RT <[EMAIL PROTECTED]> wrote: > Note: Application of the patch attached entails a change in behavior. > It will no longer be possible to say: > > svn update > perl Configure.pl > svn update (assuming a new revision number is displayed) > make > > ... and be able to make 'successfully'. tools/build/revision_c.pl will > now die should you try to do so. > > I put 'successfully' in quotes because the current behavior is that if > you do an svn update and get updated files after configuration but > before build -- meaning your build no longer strictly corresponds to a > single state in the repository -- you can run 'make' to its conclusion > but when you call 'parrot --version' you will get warnings. But to > respond to those warnings you have to do what you should have done in > the first place, namely, go directly from configuration to build. > > Eliminating this toleration for bad programming practices simplified the > code considerably! > > Please review. I'll apply in 2-3 days if there is no objection. Thank > you very much. > can you still do: svn update perl Configure.pl make svn update (new revision) make ?? this is a common scenario for developers. in the case where updating the working copy does not change any files that would affect the configuration process, the developer should not be forced to reconfigure. if this behavior is allowed, this patch should fit the bill. if not, then i'll have a problem with it. i certainly don't want to be forced to run configure and rebuild parrot from scratch every time i update my working copy (for example, if a pod comment was modified in a high-level language.) ~jerry
Re: Extending Parrot NCI callback functionality
Geoffrey Broadwell wrote: On Wed, 2008-01-16 at 22:38 -0700, Paul Seamons wrote: I am starting to implement a GLUT and OpenGL binding for Parrot. [...] I don't often get concentrated time to help out with Parrot and Perl 6, but I have some now. If this is going to be blocked indefinitely, my tuits are likely to evaporate. And dangit, I don't want to miss out on my window of opportunity! It's true that the generalized solution for varying callback signatures doesn't exist yet, but it's easy enough to create your own C callback layer, with a separate C function for each callback you need. (Note, not one-per-signature, but one-per-callback.) The callback functions can invoke a Parrot sub that they lookup by name, register a callback sub with the concurrency scheduler, or simply directly perform the actions needed. Allison
Re: Extending Parrot NCI callback functionality
On Sat, 2008-01-19 at 17:25 +1300, Allison Randal wrote: > Geoffrey Broadwell wrote: > > On Wed, 2008-01-16 at 22:38 -0700, Paul Seamons wrote: > >>> I am starting to implement a GLUT and OpenGL binding for Parrot. > [...] > > I don't often get concentrated time > > to help out with Parrot and Perl 6, but I have some now. If this is > > going to be blocked indefinitely, my tuits are likely to evaporate. And > > dangit, I don't want to miss out on my window of opportunity! > > It's true that the generalized solution for varying callback signatures > doesn't exist yet, but it's easy enough to create your own C callback > layer, with a separate C function for each callback you need. (Note, not > one-per-signature, but one-per-callback.) The callback functions can > invoke a Parrot sub that they lookup by name, register a callback sub > with the concurrency scheduler, or simply directly perform the actions > needed. Barring some better option coming up in the mean time, I will probably end up doing this. At the very least, I'll get more exposure to Parrot's guts this way. Still, I'll also file an RT ticket asking for the general solution under the "twice requested" rule. I'll reference this thread, Paul's old thread, and our IRC conversation in the ticket. -'f
Re: Extending Parrot NCI callback functionality
On Friday 18 January 2008 20:25:16 Allison Randal wrote: > It's true that the generalized solution for varying callback signatures > doesn't exist yet, but it's easy enough to create your own C callback > layer, with a separate C function for each callback you need. (Note, not > one-per-signature, but one-per-callback.) The callback functions can > invoke a Parrot sub that they lookup by name, register a callback sub > with the concurrency scheduler, or simply directly perform the actions > needed. I'm not even sure *that* will work. To invoke a Sub PMC from C, you need to pass in an Interp as well as the PMC. Unless you know both of those at compile time, I'm not sure how to make the callback mechanism work. ... although I just had an evil idea regarding memcpy and a hash table. -- c
Crazy NCI Callback Solution Idea
Here's my crazy idea. When you register a callback into PIR from C, you need to pass a few arguments: the interpreter into which to call, the PMC Sub to call, and the C signature of the C function which gets called from C. I presume that the PIR function will get called through one of the external API calls which need to know the interpreter, the PMC to invoke, and the C signature of the incoming arguments. The callback registry stores this information in a hash (or array) or other registry and... ... looks up a function pointer in a table of precompiled function pointers keyed off of C signatures. These functions call a "return a varargs pointer from my arguments" function, then call the "invoke registered PIR callback" function with the varargs and an identifier. (I'll get to where the identifier comes from in a moment.) Instead of returning that function pointer directly, the registry copies it (we have to know its size somehow, but I think we can guess pretty well) and changes one spot which records its identifier. It's an integer, probably unsigned. Relying on a JIT might make this easier, but I think we can use this scheme with a fair degree of ease. We do need to make sure that the copied functions are on executable and writeable memory pages, but otherwise I think we're fine. Also, no, I never wrote viruses. Why do you ask? -- c
Perl 6 wiki: (new) Perl 6 Articles and Presentations
Just added a "Perl 6 Articles and Presentations" section to the Perl 6 wiki: http://www.perlfoundation.org/perl6/index.cgi?perl_6_articles_and_presentati ons (It's the last item listed under "Introduction" on the Perl 6 wiki home page.) Best regards, Conrad Schneiker www.AthenaLab.com http://www.perlfoundation.org/perl6 -- Official Perl 6 Wiki http://www.perlfoundation.org/parrot -- Official Parrot Wiki http://www.perlfoundation.org/perl5 -- Official Perl 5 Wiki
