Re: [perl #48014] [DEPRECATED] PMC union struct
Christoph Otto schrieb:
Christoph Otto via RT wrote:
The attached patch implements this behavior and fixes two core PMCs
that had been doing the inheritance manually. All tests in make test
pass. I didn't bother testing any HLLs as this is more of a here's
what I'm thinking patch, but it's not likely there will need to be
any changes other than nuking a few more now-redundant ATTRs.
Obviously, the HLLs will get a test before this gets committed,
barring any other objections.
+#prepend parent ATTRs to this PMC's ATTR list
+if (@{$pmc-{parents}} 0 $pmc-{parents}[0] ne 'default') {
+my $got_attrs_from = '';
+foreach my $parent (@{$pmc-{parents}}) {
+my $parent_dump = $pmc2cMain-read_dump(lc($parent).'.dump');
+if ($got_attrs_from ne '' $parent_dump-{has_attribute}) {
+die $filename is trying to extend $got_attrs_from and $parent,
.
+but both these PMCs have ATTRs.;
+}
+if ($parent_dump-{has_attribute}) {
+$got_attrs_from = $parent;
+foreach my $parent_attrs (@{$parent_dump-{attributes}}) {
+$pmc-add_attribute($parent_attrs);
+}
+}
+}
+}
+
I am wondering about the check with check with $got_attrs_from.
How is the case handled, where an PMC 'child' inherits from the PMC 'parent'
and 'child' wants to add an attribute to the attributes inherited from
'parent' ?
Regards,
Bernhard
Re: [perl #60554] BUG: 'our' variables getting lost in NQP actions
Patrick R. Michaud via RT schrieb: On Sat, Nov 15, 2008 at 11:46:01AM -0800, Bernhard Schmalhofer wrote: In Pipp I encountered the problem that an our variables seem to get lost in NQP actions. This means that I had set an our variable in one action. When trying to look at the variable in a subsequently called action, the variable was not defined. However this was not reproducible. Using the variable in another action worked as expected. In t/compilers/pct/complete_workflow.t:84 I added a TODO test case that illustrates this behavior. The test case appears to have incorrect logic. $?MY_OUR_VAR appears to be set by the action method for TOP, but the action method for thingy will be called _before_ the action method for TOP. Thus it's pretty clear that thingy won't see the setting of $?MY_OUR_VAR because it hasn't occurred yet. Pm I think that I misunderstood how actions work. I thought that the action for thingy is called by the line: make $( $thingy ); But is looks like it is called during the matching process, which make perfect sense. So my real problem is: In the action for thingy how do I determine that the match is below TOP? I need this for distinguishing between function scope and global scope of variables in PHP. Regards, Bernhard
[perl #56382] [RFC] Making Test::Harness 3 available without including it in core parrot.
On So. 07. Sep. 2008, 15:31:49, [EMAIL PROTECTED] wrote: This ticket has not been addressed since early July. Re-reading it now, it seems to have two major discussion threads: one specific to Test::Harness 3 and one relating more generally to the versions of CPAN modules needed to configure, build and test Parrot. May I ask for those who have posted to this ticket to comment on where we stand? For testing Pipp I now explicitly require TAP::Harness 3.12 in languages/pipp/t/harness. So if T::H 3 is going to be generally required, it should be considered to require that version. Since T::H 3.12, a closure can be passed to the exec option. -- /* [EMAIL PROTECTED] */
[perl #48014] [DEPRECATED] PMC union struct
On Mo. 08. Sep. 2008, 13:59:08, julianalbo wrote: Done in r30914: changed name to Parrot_type_attributes, fixed codingstd, changed also pmc in languages lua and perl6, and updated pdd17_pmc.pod Does this mean that this ticket can be closed and the deprecation item in DEPRECATED.pod be removed? -- /* [EMAIL PROTECTED] */
Re: [perl #31633] [TODO] Allow Languages to be self contained
Will Coleda via RT schrieb: On Sat Sep 18 23:13:06 2004, coke wrote: That is: Contrive things so that no code whatsover must be maintained outside of the language specific directory. This includes: - MANIFEST - config files - ./library/Parrot/Test/* The long term goal for languages is that they'll live in their own repository, rather than being shipped with parrot's. There are a lot of languages that nobody cares enough about, to put them into a separate repository. How about creating a repository, https://svn.perl.org/parrot-little-languages, that can serve as a container for those semi-maintained languages? Having just gone through this with partcl, I don't think we need to do more in the parrot repository on this ticket; Any language that moves out just needs to have a small Configure.pl: partcl's just invokes reconfigure.pl, nothing else in parrot's repo was needed. Feedback on closing the ticket?
[perl #43851] [CAGE] All calls to stack_entry need to be NULL-checked
On Fr. 13. Jul. 2007, 16:21:54, rgrjr wrote: Are there any? The only ones I can find that that Splint might be complaining about are the derefs in rotate_entries, but the code explicitly checks that stack_height is large enough such that stack_entry will never return NULL. True? Looks like it. Furthermore, as rotate_entries() isn't used anywhere I propose to remove the function rotate_entries(). This will quiet the complaints from Splint for good. Any comments? -- /* [EMAIL PROTECTED] */
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
James Keenan via RT schrieb: I'm trying to see if we can move this ticket toward resolution. I think that it has remained unresolved for so long because the original post originally called for two steps: (a) removal from Configure.pl of configuration steps which probed for features only used in specific language implementations; (b) development of a way to conduct such language-specific probes in the language directory trees after 'perl Configure.pl' and 'make' have been run. There were two specific steps cited for removal per (a): auto::python and auto::m4. By June of this year I had removed both of those from Parrot configuration. So that leaves us with (b). particle wrote: languages/dotnet/ has its own configure.pl, and m4, plumhead, etc. should follow that model. Barney responded: One thing that held me back from using something like 'dotnet/Configure.pl' was that 'dotnet/Configure.pl' currently needs to be explicitly called after the main 'Configure.pl' has run. This is bad for universal languages testing. And that's where discussion left off three months ago. I am recommending the following: (1) Mark this ticket resolved. (2) Conduct discussion on list or IRC as to the best architecture/model for language-specific probes. (3) Once we've come to such resolution on (2), open a new RT to implement what we've decided. particle, Barney: Any objections? Sounds good. An example for a language specific config probe could be put mk_language_shell.pl. Regards, Bernhard Thank you very much. kid51
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
Reini Urban via RT schrieb: Defining the hash entries for the subs in PIR syntax is awful. So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax. For p6 we must ensure that every parrot package has a perl6 also then. Not good. So pl, pir or the simple nqp. The libs and scripts could be written in Perl 6 and compiled to bytecode. In this way the languages would need no full Perl 6, just some *.pbc files. Regards, Bernhard
Re: codingstd tests should pass in every release
Will Coleda schrieb: On Mon, Aug 18, 2008 at 4:39 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Sun, Aug 17, 2008 at 10:21:18PM -0400, Bob Rogers wrote: From: James E Keenan [EMAIL PROTECTED] Date: Sun, 17 Aug 2008 19:55:02 -0400 Yes, when one of the 'make codingstd_tests' accumulates sufficient PASSes, we promote it to 'make test'. Those that are not yet passing can generally be described as: Requires cage-cleaner with vast number of tuits. . . . So, no, failures in these files are not from showstoppers. They're a TODO for my golden years (and those of several other Parrot developers). I committed a fuller explanation in r30292. Perhaps make fulltest should run the make codetest target instead of make codingstd_tests? The codetest target is the one that means run the codingstd tests that are part of 'make test'. This would allow make fulltest to still run the required subset of coding standard tests (i.e., the same ones as make test) without having to run the entire codingstd suite (which produces the ignorable failures). And we can remove the note from the release_manager guide entirely, since make fulltest will run exactly what we want (and any errors in coding tests are then significant). Pm +1 Thumbs up from me.
Re: YAPC::EU 2008
Jonathan Worthington schrieb: Allison Randal wrote: Bernhard Schmalhofer wrote: We could always do the 12th AND the 16th, just for fun and bonus productivity (if everyone isn't exhausted from a day of hacking and three days of conference)? ;-) Patrick and I will be hacking on the 12th and the 16th. If you've not seen Copenhagen before, I could forgive you for wanting to spend a day enjoying the city rather than hacking though - it's nice! :-) Hi, I've also booked flight and hotel for August 11th to 17th. So I will be around on the 12th and the 16th. Regards, Bernhard
Re: [perl #55954] [PATCH]: Add 'make smolder_test' target
James Keenan via RT schrieb:
Michael:
I install TAP::Harness::Archive from CPAN, then applied the patches to a
fresh checkout from trunk. I configured, built and ran 'make
smolder_test'. The Smolder test completed and stated that it uploaded
-- though I have a tough time matching my particular report to those at
http://smolder.plusthree.com/app/public_projects/smoke_reports/8.
More importantly, running the Smolder test revealed that
lib/Parrot/Harness/Smoke.pm was itself in violation of some
t/codingstd/perlcritic.t standards.
08:37 dalek : Committing Michael Peters' most recent patches for Smolder
testing
08:37 dalek : (http://rt.perl.org/rt3/Ticket/Display.html?id=55954). NOTE:
08:37 dalek : lib/Parrot/Harness/Smoke.pm is failing perlcritic.t policy
re comments with
08:37 dalek : 'TODO' -- a failure I found out by running make
smolder_test itself!
08:37 dalek diff: http://www.parrotvm.org/svn/parrot/revision?rev=29572
not ok 166 - Test::Perl::Critic for
/home/jimk/work/forsmolder/lib/Parrot/Harness/Smoke.pm
# Failed test 'Test::Perl::Critic for
/home/jimk/work/forsmolder/lib/Parrot/Harness/Smoke.pm'
# at t/codingstd/perlcritic.t line 69.
#
# Perl::Critic found these violations in
/home/jimk/work/forsmolder/lib/Parrot/Harness/Smoke.pm:
# Flag comment 'TODO' found at
/home/jimk/work/forsmolder/lib/Parrot/Harness/Smoke.pm line 100
# Flag comment 'TODO' found at
/home/jimk/work/forsmolder/lib/Parrot/Harness/Smoke.pm line 108
I was told on #parrot that you have to replace # TODO comments by
creating RT tickets and referencing the RT instead of the TODO.
Perhaps it would be simpler to just delete these comments. Please
advise. Thank you very much.
I think it is a good idea to centralize all interactions with svn.
So how about using $Parrot::Revision::current or PConfig{revision} there?
Regards,
Bernhard
Re: [perl #57026] [BUG]: Changes to Parrot::Ops2c::Utils in remove_getfd branch cause failures in buildtools_tests
Will Coleda schrieb: On Wed, Jul 16, 2008 at 10:54 PM, James Keenan via RT [EMAIL PROTECTED] wrote: This module is written in Perl 5 and is called in a program written in Perl 5. In the work I've done in this project, I've taken the approach to return values which I think is more Perlish, namely, if a subroutine completes and does what you wanted it to, it should return a true value. A bare return returns an undef, which in Perl is false. False values (whether empty string, empty list, 0 or undef) should indicate some unsatisfactory completion of the subroutine. Having these subs end in a bare return to me connotes an unsatisfactory outcome of some sort. That's why I did not have them end in bare returns, and it's why I object to the changes that were made yesterday. Not every function has a true/false return value. These methods that were refactored from the original script are only invoked once, and are just there to encapsulate code. They are not expected to return a true -or- false value. The one place they are invoked outside of the test suite treats them as a void return value and doesn't save the return value, let alone have a conditional based on it. Since there's no 'void' return in perl, undef is about as close as you can get. I'm done, and I didn't die. That said, we can agree to disagree on that point for now, and leave the tests unchanged for the moment... ... because we can change the bare 'return;'s to 'return 1;' for now. That avoids the implicit return value that we were unintentionally getting, and will get us one step closer to passing the perlcritic policy [Subroutines::RequireFinalReturn]. Hi, sorry for not running 'make buildtool-tests'. The only reason for adding the empty returns, was that the implementation was not in accord with function documentation. In the POD for the changed functions there was: Return Value: None. I think the interface of a function should reflect it's intent. If only internal state is modified, I'm happy with returning undef or the empty list. On the other hand, I wouldn't expect that a function returns 1, only because the code ran successfully. So I would be in favour of changing the tests. But as I have no strong feelings about that, a return 1; would be fine as well. Regards, Bernhard
[perl #56800] [META] merge pdd25cx branch back into trunk
In r29552 of https://svn.perl.org/parrot/branches/pdd25cx I ran make test for: pipp, eclectus, hq9plus, lazy-k, m4, unlambda. All tests were passing. -- /* [EMAIL PROTECTED] */
Re: CPAN-Permissions for Perl 5 Modules
chromatic schrieb: https://pause.perl.org/pause/authenqueryI It's only a CPAN indexing issue. Whenever a release manager uploads a new bundle, he or she needs to change permissions for all new indexed modules to allow the PARROTRE group to upload new versions. Unless/until you're a release manager yourself, you can safely ignore this. Does this mean that all release managers should be in the PARROTRE group? If so, somebody should check that this is indeed the case. Judging from https://pause.perl.org/pause/authenquery, I'm no member in PARROTRE. (The implication is that Bernhard should go into PAUSE right now and check that he's not listed as the primary first-come, first-served maintainer for any Parrot modules.) That's what I did right after the upload. But I can change permissions only for new modules, not for modules that weren't indexed. Regards, Bernhard
Re: CPAN-Permissions for Perl 5 Modules
Bernhard Schmalhofer schrieb: Does this mean that all release managers should be in the PARROTRE group? If so, somebody should check that this is indeed the case. Judging from https://pause.perl.org/pause/authenquery, I'm no member in PARROTRE. ** Sorry, I misread https://pause.perl.org/pause/authenquery. It says: * Select Mailinglist/Action *mlrepr Representatives of mailing lists have their special menu here. Only Representatives of mailing lists, not the members, have a special menu there. However it would be nice to see mailing list membership somewhere. Regards, Bernhard
Parrot 0.6.4
Hi, on behalf of the Parrot team, I'm proud to announce the release of Parrot 0.6.4 St. Vincent Amazon. Parrot 0.6.4 is available via CPAN, or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 0.6.4 News: - Documentation + removed a lot of old information from the FAQ + improved function level documentation - Configuration + removed the configuration item 'has_gnu_m4' + refactored ICU-detection - Languages + ChitChat - improved the Smalltalk implementation + Pipp - renamed Plumhead to Pipp - support for a lot of builtin functions. - Pipp now uses PHP specific data types. - converted from PCT with TGE to PCT with NQP actions - improvements in the PCT variant by using optok parsing - start of object support + pir - simple assignments work + json - added a PCT-based implementation of JSON parsing + lolcode - improved handling of symbols - added support for block handling - added support for globals + Lua - more tests + Rakudo - updated Range implementation - added enums - added generic type declarations (::T) - added runtime mixing of roles with 'does' and 'but' - added generic type declarations - fixed handling of implicit lexicals ($_, $!, and $/) - fixed implicit method calls on $_ - improved complex math builtins, added Complex - moved many builtins to class Any - declaration of lists of variables now work - improved test infrastructure - 910 additional passing spec tests since last release - more convergence with STD.pm grammar - added named 0-ary parsing and ops - Compilers + PCT: - allowed subroutine and method names to be a PAST tree that produces the name - Improved lexical handling - Tools + pbc_disassemble renamed from disassemble - Implementation + allowed .macro_const in PIR + added the flag :lexid(...) for subroutines + made multiple dispatch work for sub types + fixed garbage collection bug related to the metadata attached to a PMC_EXT structure + added a warning when using deprecated opcodes + simplified the stacks implementation + fixed C++ build + improved closure and lexical support + improved IMCC register allocator + added cache for all runtime-constant strings, reducing memory usage - Miscellaneous + improved OpenGL/GLU/GLUT bindings + added a standard profile for Perl::Critic coding standard testing + added support for smoke testing with Smolder + enabled use of Test::Harness 3.0 if available, but don't require it for 'make test' + added the executable 'parrot_config' to query Parrot configuration Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is August 19th 2008. Enjoy!
CPAN-Permissions for Perl 5 Modules
Hi, for Parrot 0.6.4 following Perl 5 modules were not indexed: Parrot::Configure::Options::Test::Prepare Parrot::Pmc2c::PMC::PrintTree Parrot::Test::Util::Runloop Parrot::SearchOps It looks like co-maintainership needs to be given the release managers. Regards, Bernhard
July 2008 Release
Hi, the July 2008 release of Parrot will be most likely Parrot 0.6.4. It will take place on tuesday, July 15th. So, as usual, try to not break the build and the tests. Updates to NEWS, CREDITS, PLATFORMS, RESPONSIBLE_PARTIES and LANGUAGES_STATUS are appreciated very much. Please add the open issues, that are relevant for the release, to http://rt.perl.org/rt3/Ticket/Display.html?id=55926. Best regards, Bernhard
Re: [perl #55842] [BUG] empty .const .String broken
François Perrad schrieb:
chromatic a écrit :
On Tuesday 08 July 2008 02:36:37 François PERRAD via RT wrote:
This bug starts with r28354 (cache string).
The cache don't handle empty string.
Now, in Pipp (PHP), an empty string is used to stringify boolean False.
// languages/pipp/src/pmc/phpboolean.pmc
STRING* get_string() {
if (PMC_int_val(SELF))
return const_string(INTERP, 1);
else
return const_string(INTERP, );
}
Instead of an empty string, I obtain another cached string like MD2,
PhpUndef, ...
I can't reproduce that with this test case:
.loadlib 'php_group'
.sub 'main' :main
.local pmc true, false
true = new 'PhpBoolean'
false = new 'PhpBoolean'
true = 1
false = 0
$S0 = true
say $S0
$S0 = false
say $S0
.end
On windows, r29191, with this test, I obtain :
D:\fperrad\Parrot\trunk\languages\pippparrot bool.pir
1
Php
D:\fperrad\Parrot\trunk\languages\pipp
and with a Lua PMC test
D:\fperrad\Parrot\trunk\languages\luaperl -I../../lib t/pmc/string.t
1..13
ok 1 - check inheritance
ok 2 - check interface
ok 3 - check name
ok 4 - check get_bool
ok 5 - check logical_not
ok 6 - check embedded zero
ok 7 - check HLL
ok 8 - check HLL (autoboxing)
ok 9 - check HLL .const
not ok 10 - .const empty string
# Failed test '.const empty string'
# at t/pmc/string.t line 196.
# got: '¤
# 1
# '
# expected: '
# 1
# '
ok 11 - check tostring
ok 12 - check tonumber
ok 13 - check tobase
# Looks like you failed 1 test of 13.
I shaw the same behavior on Xubuntu 8.04 (r29194).
But I notice that this issue is random (disappear or re-appear after
an update re-compilation).
I made the same experience under Linux. This misfeature appears and
disappears after making
arbitrary changes.
Regards,
Bernhard
[perl #41666] Test PIR and PASM by generating PBC and running it
On Mi. 02. Jul. 2008, 23:25:56, [EMAIL PROTECTED] wrote: make testr does this; if that doesn't work, let's re-open the ticket. Actually 'make testr' does something a little bit different. It creates a '*.pbc' File, converts it into an executable and runs the executable. It doesn't run the pbc-File directly. -- /* [EMAIL PROTECTED] */
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
James Keenan via RT schrieb: On Fri Jul 13 09:58:33 2007, bernhard wrote: There are several config probes that are only used for language implementations. Examples are config/auto/m4.pm and config/auto/python.pm. Please find attached two files. The first greps the repository for mentions of 'm4'. The second is a patch which eliminates config/auto/m4.pm and the associated test file and updates the MANIFEST. Configure.pl, make and make test all perform without error after this config step is eliminated. When I switch into languages/m4, then call 'make' and 'make test', I get the same test failures in t/regex/002_tokens.t either way. So my belief is that removing this step causes no harm to the m4 language implementation itself. I will apply this patch to trunk in about 2 days if there is no objection. Thank you very much. kid51 AFAIK 'languages/m4/config/makefiles/root.in' is the only place where the config entry 'has_gnu_m4' is used. It is meant as a doublecheck of the 'm4' tests. If 'GNU m4' is available then the m4 tests should be run with 'GNU m4' as well. This should make sure that the Parrot implementation behaves the same way as the reference implementation. So 'has_gnu_m4' is not essential to the implementation of 'Parrot m4'. In r28633 I removed the use of 'has_gnu_m4' and the config step auto::m4.pm can now be removed. But the real scope of ticket RT#43857 is something different. Language implementations may need config probes that are only relevant for that particular language. Therefore there should be some kind of infrastructure set up, so that those probes can be placed within the language dir. Taking 'Plumhead' as an example, I would have liked to set up probes checking for 'phc', 'antlr' and 'xsltproc'. I didn't do so because I didn't want to clutter the Parrot config. Regards, Bernhard
Re: Keep the 'keet Re: Renaming Plumhead
Bill Ricker schrieb: Plumhead may sound stupid but there's nothing wrong with Plum-Headed Parakeet spelled correctly with the Hyphen and Three Cap Letters. It's a real bird whose initials spell PHP, what more could you want in a name?. O'Reilly's cover editor will be happy, although they may have to hand-tint the old block to get the evocative colo[u]?ring - they're quite colo[u]?rful, almost pretty in a garish sort of way, which somehow seems appropriate for PHP. http://en.wikipedia.org/wiki/Plum-headed_Parakeet. (One /could/ be obscure and use the latin name http://home.wanadoo.nl/psittaculaworld/Mutations/P-cyanocephala.htm ) On the Wikipedia page I liked the sentence: Plum-headed Parakeet is a gregarious and noisy species with range of raucous calls. This is definitly a good description of PHP. If what one wants is a short-form of the name that sounds less goofy than Plumhead but still much fewer keystrokes than Plum-Headed Parakeet , perhaps PHPkeet would serve as a logotype for the longer formal name with good pun and allusions, and simultaneously serve as a Google(tm)-able keyword distinct from the aviary variety? My favourite short form would be PHParakeet, pronounced as P - H - Parakeet. This still has the PHP in it, but only as a sensible abbreviation of Plum-Headed Parakeet. Regards, Bernhard
Renaming Plumhead
Hi, Plumhead, from *P*lum*h*eaded *P*arakeet, is the current name of the PHP on Parrot implementation. As Plumhead is a stupid name, cotto proposed to rename to Pharrot. Pharrot is definitly nicer than Plumhead, but maybe too close to Parrot. Furthermore it changes the 'P' sound that is common to PHP and Parrot to an 'F' sound. The last time Pharrot' was used as a project name, it was renamed to Pint. http://blog.coggeshall.org/archives/290-Back-from-the-Int.-PHP-Conference.html So I'm still open for an alternative. If no better suggestion turns up, I'll rename to 'Pharrot' after the June release. Regards, Bernhard
Re: [perl #52776] [PATCH] Allow @foo@ syntax when setting config data.
On Fri, Jun 06, 2008 at 11:17:33PM -0700, Will Coleda via RT wrote: Let's borrow the syntax from the makefile generation itself, and just have RM_F's definition be: +rm_f = '@perl@ -MExtUtils::Command -e rm_f', [...] Sound good to me. Additionally (though it won't help the original problem, it will help remove a ton of boilerplate), we can also eliminate all the RM_F = @rm_f@ boilerplate in the makefiles, and simply use @rm_f@ where we now use $(RM_F) Actually I don't mind having things like RM_F = /home/coke/bin/perl -MExtUtils::Command -e rm_f defined on top of Makefiles. It is standard Makfile syntax. When editing the generated Makefile, for testing and development, it easier to change the global definition of a variable than to change all ocurrances. Regards, Bernhard
[perl #54148] [NEW] Add tools/util/dump-pbc.pl (weave PIR source and PBC disassembly)
The previous version of the patch didn't work on Windows, because pipe open doesn't work there, grrr. Please try the attached version of the patch. It looks like the current version of the patch has been applied. In r28039 I added a sanity test in the new file t/tools/dump_pbc.pl. If that works across platforms, I propose to close this ticket. -- /* [EMAIL PROTECTED] */
Re: [perl #42393] [TODO] regex - FIXME items in languages/regex/lib/Regex/Grammar.y
James E Keenan schrieb: Patrick R. Michaud via RT wrote: plus I don't know that languages/regex is being used or maintained. I vote to remove languages/regex, either for the May 2008 release or soon thereafter. FWIW, svn status -v languages/regex/ suggests that François, Barney and chromatic have worked in this tree in the last year. So it's getting some degree of attention. kid51 I'd vote to keep it. But I don't have strong feelings either way. How about setting the tickets for the not actively developed languages to 'STALLED'? Regards, Bernhard
[perl #52288] [install] undefined reference to `Parrot_set_executable_name', linking failed
On Mi. 02. Apr. 2008, 06:27:23, doughera wrote: This very minimal patch at leasts gives a brief warning about the issue. On a closely related topic, I thought about changing the default in this case to not build a shared libparrot, but dealing with the combination of undocumented Configure.pl variables and the inability to use command- line overrides made that patch become too large a project for me to tackle today. In r27445 I added this warning. Additionally I added this note: RT#52288: the check for old_versions should be improved Regards, Bernhard -- /* [EMAIL PROTECTED] */
[perl #45015] [TODO] Create a 'Rational' PMC for rational numbers
On Mi. 07. Mai 2008, 13:55:13, desertmax wrote: As discussed on IRC, I've replaced print foo print \n with say foo. Furthermore, I've added tests for init and version, if GMP is not available and one test for version, if GMP is present. The constructor does not raise an exception anymore, if GMP is not available. This gives users a chance to check at runtime whether GMP is available using the version method. Hi, I tested this under Linux with an installed GMP and it looks OK. This will be useful for Eclectus. However, some codingstd tests are failing. Could you, desertmax, take a look at: t/codingstd/c_cppcomments.t t/codingstd/c_indent.t t/codingstd/c_operator.t t/codingstd/linelength.t t/codingstd/trailing_space.t Best regards, Bernhard -- /* [EMAIL PROTECTED] */
Re: YAPC::EU 2008
Jonathan Worthington schrieb: Allison Randal wrote: Will Coleda schrieb: Can we get an idea of how many parrot hackers are planning on attending YAPC::EU this year? (will be held in Copenhagen, Denmark, on 13-15 August 2008 Bernhard Schmalhofer wrote: Is there enough critical mass that would warrant a Mini-hackathon? I'm now definitely going to be there, and would like to spend some time hacking with whichever Parrot hackers/enthusiasts make it. August 12 or 16 works for me. Do either of those days work for anyone else? I can be flexible. I'm planning to see a friend in south Sweden around the time of the conference too, so expect I will just hang around in the general area for a week or so. We could always do the 12th AND the 16th, just for fun and bonus productivity (if everyone isn't exhausted from a day of hacking and three days of conference)? ;-) I'm also flexible. 12th and 16th sounds good to me. Best regards, Bernhard
Re: [perl #45015] [TODO] Create a 'Rational' PMC for rational numbers
Markus Mayr via RT schrieb: I am currently working on this. I'll probably finish work on it during the next 10 days. That's great. In case of questions please do not hesitate to ask on #parrot or on the mailing list. Regards, Bernhard
[perl #47828] [TODO] Implement the 'copy' opcode
On Mi. 19. Mär. 2008, 07:38:36, pmichaud wrote: On Thu Dec 13 17:47:05 2007, [EMAIL PROTECTED] wrote: Implement a 'copy' assignment (at least until we get the 'copy' opcode -- see RT#47828). The copy opcode has been added in r23917. Can this ticket be resolved now? Regards, Bernhard -- /* [EMAIL PROTECTED] */
Code with BSD-like license in Parrot repository?
Hi, it was suggested by Andreas Rottmanm, rotty, to use 'riaxpander' in the implementation of 'Eclectus'. riaxpander is a macro expander for Scheme. It is licensed in a BSD-like way, http://mumble.net/~campbell/darcs/riaxpander/LICENCE. Can this code be added to 'languages/eclectus' in the Parrot repository? I know that 'Artistic 2.0' in incompatible with GPL. What's the score with BSD-like? Regards, Bernhard
SVN checkin: r26841 'perl Configure.pl' is required after svn update
Hi, in r26841 I removed the directory 'compilers/past-pm', resolving the deprecation item from RT#48030. After updating to the new revision, a 'perl Configure.pl' is required, as Makefile dependencies have changed. Best regards, Bernhard
[perl #48030] [DEPRECATED] compilers/PAST-pm, Parrot/HLLCompiler.pir
On Sa. 05. Apr. 2008, 07:40:12, bernhard wrote: On Di. 26. Feb. 2008, 13:37:20, bernhard wrote: The compiler tools in compilers/PAST-pm/ and runtime/parrot/library/Parrot/HLLCompiler.pir are deprecated in favor of the new versions in the Parrot Compiler Toolkit ( compilers/pct/ ). In particular, the PAST representation in PCT follows the specification given by pdd26 . In r26481 PAST-pm was removed. However runtime/parrot/library/Parrot/HLLCompiler.pir is still used in a couple of places. -- /* [EMAIL PROTECTED] */
Re: YAPC::EU 2008
Will Coleda schrieb: Can we get an idea of how many parrot hackers are planning on attending YAPC::EU this year? (will be held in Copenhagen, Denmark, on 13-15 August 2008.) http://www.yapceurope2008.org/ye2008/ Another I'm not sure whether I can make it from me. Is there enough critical mass that would warrant a Mini-hackathon? Regards, Bernhard
[perl #51894] [PATCH] aligning code and localization of vars
On Mi. 19. Mär. 2008, 06:25:32, kjs wrote:
hi,
attached a patch that does some aligning of = tokens and limits the
scope of some variables.
I don't commit this myself, because I want to check whether this
practice of localizing vars. is ok, as it introduces else clauses.
For instance, instead of writing:
STRING *s;
if ( bla bla )
return -1;
s = xyz
more stuff()
return s
I changed this into:
if (bla bla)
return -1;
else {
STRING *s = xyz
more stuff()
return s;
}
Not sure whether which is better. My personal preference is the patch,
obviously.
Comments welcome, so I know how to do this in the future.
Personally I like your version a little bit better, as *s is declared
close to where the action is.
Alternativels one could avoid the technical variable 's' altogether
and stick with using '*buf'.
Regards,
Bernhard
--
/* [EMAIL PROTECTED] */
[perl #31133] [TODO] Run different run cores inside Test.pm
On So. 24. Feb. 2008, 17:39:36, [EMAIL PROTECTED] wrote: 'make fulltest' exits at the end of any core with failing tests; that's how I expect make to behave. (If it doesn't, there's something wrong.) Actually it no longer does that, as I have changed 'make fulltest' in preparation for the 0.6.0 release. -- /* [EMAIL PROTECTED] */
Re: [perl #51860] Failures in t/manifest/*.t in a release
James Keenan via RT schrieb: On Tue Mar 18 12:58:08 2008, bernhard wrote: When preparing the Parrot 0.6.0 release I encountered in an unpacked distfile for prove -v t/manifest/*.t the attached errors. For the release I simply commented out the dubious tests. Barney: If I read parrotsketch correctly, these tests had not previously been included in one of the test targets -- 'make fulltest', IIRC. So there obviously were not conditions I had anticipated when I originally wrote them. Yes, I had added 'manifest_tests' to 'fulltest' a couple of days earlier. There was no special reason to add it, just aiming to make 'fulltest' as comprehensive as possible. So if the failures are hard to fix, you can simple remove 'manifest_tests' from 'fulltest'. The failures should be easily reproducable. i. Ununcomment the 'RT#51860' lines in t/manifest/*.t ii. 'make release' = parrot-0.6.0-devel.tgz' iii. Unpack the tarfile iv. Run 'perl Configure.pl make' iv. Run 'make manifest_tests' The '.svn' dirs are no in the unpacked dist. So it is assumed that 'svk' is used. But I don't have 'svn' installed. Thanks for looking into that, Bernhard If you could give me just a little bit more description of the problem you experienced (or of the conditions under which the test will have to be run), I will fix it. Thank you very much. kid51
[perl #51790] Segfaults for GDBMHash in -C and -S runcores
On So. 16. Mär. 2008, 06:57:31, bernhard wrote: Hi, running 'make fulltest' under Linux leaves me with segfaults for gdbmhast.t. This happens only for the computed-goto and for the switched runcore. [EMAIL PROTECTED]:~/devel/Parrot/trunk$ uname -a Linux heist 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux The same symptoms show with ./parrot -C t/dynpmc/digest_9.pir and ./parrot -S t/dynpmc/digest_9.pir Regards, Bernhard -- /* [EMAIL PROTECTED] */
Parrot 0.6.0 PP is released.
On behalf of the Parrot team, I'm proud to announce Parrot 0.6.0
PP.
Parrot (http://parrotcode.org/) is a virtual machine aimed
at running dynamic languages.
This release is a milestone release featuring the
revamping of Parrot Magic Cookies.
Parrot 0.6.0 can be obtained via CPAN (soon), or follow the
download instructions at http://parrotcode.org/source.html.
For those who would like to develop on Parrot, or help develop
Parrot itself, we recommend using Subversion or SVK on the
source code repository to get the latest and best Parrot code.
Parrot 0.6.0 News:
- Specification
+ launched pdd18_security.pod
+ updated pdd17_pmc.pod
+ launching draft of pdd28_character_sets.pod
- Documentation
+ cleanup of IMCC documentation
- Configuration
+ add step auto::gettext
+ add step auto::crypto
- Compilers
+ PCT:
. Fix '-e' option
. Phase out P6Regex in favor of Perl6Regex
+ IMCC:
'.local Array my_arr' is illegal now
- Languages
+ C99: reimplementation with PCT
+ lolcode:
. various updates
. add support for functions with params
. add math functions
+ Rakudo:
. support for 'say'
. first cut at smart matching
. indirect method calls
. support for Pairs
. added methods 'grep' and 'first'
. implement auto{increment,decrement}
. initial implementation of 'perl6doc'
+ Lua:
. various updates
. add base64 library
+ Cardinal: basic support for functions with parameters
+ Pheme: various updates
+ Ecmascript: various updates
+ Tcl: now targeting tcl 8.5.1, no more expected failures in test suite.
(No, this doesn't mean everything's implemented. =-)
+ Eclectus: various updates
+ WMLScript: various updates
- Implementation
+ PDD17 (PMCs)
+ Add library YAML::Dumper
+ Add the MD2, MD4, MD5, RIPEMD160, SHA SHA1 PMC, as a wrapper
around libcrypto
- Miscellaneous
+ various bugfixes, code cleanups and coding standard fixes
+ consting
+ remove external Perl 5 modules from the Parrot distribution
Thanks to all our contributors for making this possible, and our
sponsors for supporting this project.
Enjoy!
Bernhard Schmalhofer
[perl #51794] Test in languages/urm try to call _export_to_level
Testing URM, that is cd languages/urm make test and cd languages perl t/harness --languages=urm should work again in r26422. Could somebody check with older versions of Test::More ? Regards, Bernhard -- /* [EMAIL PROTECTED] */
Re: [perl #51380] [PATCH] Code layout of imcc.y
chromatic via RT schrieb: i. rule names start at pos 0. The colon follows immediately. Nothing else is on that line. ii. productions start a pos 5 iii. the '|' separating productions is at pos 3 iv. the semicolon finishing a rule is at pos 3 v. actions are either inline or start at pos 10 vi. inline actions preferable start at pos 27 A patch of imcc.y is attached. All test of 'make test' are passing. Could somebody with 'yacc' experience comment? Great idea. Unfortunately, I ran into a collision in hunk #6, starting at line 861. Can you rebase and resubmit? (Or apply yourself, that's fine too.) -- c In order to play it safe, I'll rebase and apply after the Parrot 0.6.0 release.
[perl #38262] [CAGE] get external Perl5 modules out of the parrot repo
On So. 09. Mär. 2008, 19:11:53, [EMAIL PROTECTED] wrote: Well, it looks like we've survived for a week without Test::Builder or any other Perl 5 core module in the Parrot distribution. (Thanks to Matt Kraai for helping out with t/perl/Parrot_Test.t.) So I think we can close this ticket. kid51 I'm reopening this ticket, as there are still external Perl 5 modules in lib/Digest, lib/File, lib/IO, lib/Pod. The Perl::Critic policies in lib/Perl/Critic/Policy seem to be Parrot-specific. -- /* [EMAIL PROTECTED] */
Release of Parrot 0.6.0 is coming up
Hi, another milestone release of Parrot is coming up this Tuesday, March 18th. I'm proud to host the release procedures this time. All contributors are encouraged to look at their contributions from the last month and to add their bits to NEWS and CREDITS. Also updates to PLATFORMS and to LANGUAGES_STATUS are very much appreciated. Please put experiments and your nifty new features on hold until Tuesday. Let's concentrate on testing and bugfixing. 'make fulltest' rules. --- Barney, Bernhard Schmalhofer
Re: [perl #51662] [TODO] Remove 'classname' rule in imcc.y
Klaas-Jan Stol via RT schrieb: On Wed, Mar 12, 2008 at 9:28 PM, via RT Bernhard Schmalhofer [EMAIL PROTECTED] wrote: # New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #51662] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=51662 In RT#41237 it was decided: P0 = new 'Integer' # correct $P0 = new .Integer # deprecated the dot notation is still used heavily in the .const rule: .const .Sub foo = foo It was mentioned before, and someone (don't remember who) suggested to change this into: .const Sub foo = foo this seems like a good solution to me. This, or an alternative solution must be implemented before the dot notation can be removed altogether. $P0 = new Integer # deprecated As far as I understand it, the 'classname' is only for supporting the $P0 = new Integer # deprecated syntax. So discarding the dot notation is a different issue and should be handled in a separate ticket. After removing 'classname' things look fine for the Parrot test, but I haven't looked at the languages tests. Regards, Bernhard
Re: [perl #50244] [RFE] Remove 'languages/perl5'
Andrew Parker via RT schrieb: This fix seems to have broken Configure.pl. I just checked out a fresh copy (r25239) of parrot trunk and got: Configuring languages... step gen::languages died during execution: Can't open languages/perl5/config/makefiles/root.in: No such file or directory at lib/Parrot/Configure/Compiler.pm line 261. Thanks for pointing that out. This was one, hopefully the last, reference to 'perl5' that I missed. Patch is applied. Best regards, Bernhard
[perl #49828] [PATCH] Configure hanging on GNU m4 test under FreeBSD
Hi Bruno, I found parrot installer still hanging under FreeBSD (at least FreeBSD 5.5). Its's probably because OS name isn't properly separated. Could you test the patch from ticket 49780, http://rt.perl.org/rt3/Ticket/Display.html?id=49780 ? That patch looks like a more general solution. Best regards, Bernhard -- /* [EMAIL PROTECTED] */
Re: [perl #49780] [config] m4 doesn't hang, it does its job...
Simon Cozens (via RT) schrieb:
# New Ticket Created by Simon Cozens
# Please include the string: [perl #49780]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49780
There's some code in config to detect 'm4 --version' hanging on FreeBSD.
It doesn't hang, it just silently ignores the option and starts
preprocessing the input from stdin.
This is true for all BSD-derived m4s - I'm actually running on *cough*
Minix, and the same behaviour is true there.
I think this patch will DTRT, but I'm not applying it because I'd like
someone else who's done configure stuff to have a look at it first:
Looks good to me.
Under Linux it seems to still do the right thing.
BTW you can also get rid of:
-my $archname = $conf-data-get_p5('archname');
-my ( $cpuarch, $osname ) = split m/-/, $archname, 2;
-if ( !defined $osname ) {
-( $osname, $cpuarch ) = ( $cpuarch, );
-}
Regards,
Bernhard
Re: [perl #49780] [config] m4 doesn't hang, it does its job...
James Keenan via RT schrieb: Since we're on the subject of m4 ... Are the concerns raised in this ticket still valid? http://rt.perl.org/rt3/Ticket/Display.html?id=43857 Yes, that's still a very sensible TODO. http://rt.perl.org/rt3/Public/Bug/Display.html?id=31633 is also related to that issue. Regards, Bernhard
Re: [perl #45137] [TODO] Add a revision control test in Configure.pl
James Keenan via RT schrieb: The question I would have is: What is the functionality of src/revision.c -- the file written by tools/build/revision_c.pl when the latter script is invoked by 'make'? It looks like it provides the C-function Parrot_revision() which is used in compilers/imcc/main.c to generate the 'r24879' part of: [EMAIL PROTECTED]:~/devel/Parrot/parrot/trunk$ ./parrot --version This is parrot version 0.5.1-devel (r24879) built for i386-linux. Copyright (C) 2001-2007, The Perl Foundation. This code is distributed under the terms of the Artistic License 2.0. For more details, see the full text of the license in the LICENSE file included in the Parrot source tree.
Re: [perl #44269] [TODO] Need more meaningful comment in Parrot Bug Summary
James Keenan via RT schrieb: This ticket has obviously not generated much interest since I opened it lo these five months ago. Coke and I had some IRC discussion of something he's developing that's related to it, but I haven't heard from anyone else. So, let me ask again: When you see the Parrot Bug Summary generated every Monday morning, what do you want to see in it? What I'd like to see are numbers of new, resolved and edited Tickets in the last week. Along the numbers I'd like to see an HTML link that opens the RT-Webinterface with a table of the relevant tickets. Regards, Bernhard
Re: [perl #37324] [TODO] build - root.in makefile split-up
James Keenan via RT schrieb: On Sun Oct 02 05:22:08 2005, [EMAIL PROTECTED] wrote: config/gen/makefiles/root.in already weighs in at 1581 lines. It needs to be divided up into smaller files that are combined when Configure is run. Apart from the fact that it's a PITA to edit a file which, since Oct 2005, has swelled to 2258 lines, is there a strong reason to split root.in up into smaller components? For instance, do particular Parrot developers tend to edit only in small parts of the file that are specific to their tasks? If so, then we have some logic by which to split the file up. If not, we should not. root.in can probably be improved, but I see no need to split it up, just because it is large. Just my 0.02€, Bernhard
Re: [perl #38982] [CAGE] refactor long test files
James Keenan via RT schrieb: Hey, gang! Can anyone comment on the status of this ticket? I agree that if a test file is 2400 lines long, there's a prima facie case for splitting it into smaller components. However, based on my experience and ptc's in cage-cleaning, I'd recommend opening up individual RTs for test files that would benefit subdividing. That way, we can more easily identify which test files have been refactored and which remain to be done. One of the problems with the Parrot-RT is that there are tickets that linger on and nobody knows whether they can be closed. So opening, and quickly resolving, small and specific tickets is a good idea. I suggest to open specific tickets for each file that is a candidate for refactoring and add it as a dependency of the meta ticket #38982. Once the dependencies are resolved, the meta ticket can be resolved as well. My 0.02 € Bernhard
Re: [perl #48090] plumhead smoke test presents prompt
B. Estrade (via RT) schrieb: # New Ticket Created by B. Estrade # Please include the string: [perl #48090] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=48090 --- osname= freebsd osvers= 7.0-current arch= i386-freebsd-64int cc= cc --- Flags: category=languages severity=high ack=no --- Here is the snippet, the is some sort of interactive prompt, which makes automated smoke testing a pain. I also don't know immediately how to get past it.: Sorry I broke this when I reformated the template for languages/Plumhead/Makefile. I forgot to add a '\' for line continuation in that target. I should be fixed in r23354. Actually in SVN head 'pgc' isn't used at all, as I'm porting over to the new PCT. Thanks for the report, Bernhard
Re: prototype-based language under parrot
Robert Lemmen schrieb: hi folks, i want to write a compiler for a small prototype-based language that should target parrot. as a reminder: prototype-based means that i have objects, and objects are cloned from other objects, but i have no classes. objects consist of methods and variables that are only accessible to methods on the same object. my question is: how should such code look on pir level? has anyone done something like it before? my current solution is to have a namespace for each object, with methods in it: I have no answer for that. My suggestion is to look how it is solved in PJS, http://users.fulladsl.be/spb1622/pjs/. Regards, Bernhard
Re: [perl #41597] [PATCH] replacing explicit access to $^O in Configure
James Keenan via RT schrieb:
(I'm surprised this patch slipped beneath my radar, as it refers to
files I've been staring at for months.)
This is very consistent with what I've recommended for %Config in
http://rt.perl.org/rt3//Public/Bug/Display.html?id=47902, so I recommend
this patch be applied as well. Since it was originally submitted early
in the year, we may have to double-check the locations to which it is
being applied to get it to work correctly. Here's where $^O is
currently being invoked under config/:
[parrot] 509 $ fnsa config/ '*.pm' | xargs grep -n '$^O'
config/inter/progs.pm:99:$libs = join ' ', grep { $^O =~ /VMS|MSWin/
|| !/^-l(c|gdbm(_compat)?|dbm|ndbm|db)$/ }
config/init/hints.pm:41:my $hints = init::hints:: . lc($^O);
config/auto/headers.pm:113:if ( $^O eq msys ) {
config/auto/gdbm.pm:71:if ( $^O =~ /mswin32/i ) {
config/auto/gmp.pm:54:if ( $^O =~ /mswin32/i ) {
config/auto/readline.pm:43:if ( $^O =~ /mswin32/i ) {
config/auto/gcc.pm:402:if $^O eq 'hpux';
config/auto/alignptrs.pm:48:elsif ( $^O eq 'hpux'
$Config{ccflags} !~ /DD64/ ) {
config/gen/config_h.pm:83:print {$HH} \n#define BUILD_OS_NAME
\$^O\\n;
config/gen/platform.pm:39:my $platform = lc $^O;
James,
could you look into this patch and apply it if appropriate?
Obviously you are the person that knows best, whether
it can be applied right away or needs some fiddling or merging.
Regards,
Bernhard
[perl #45601] [unified_testing] Plans and notes for the unified testing branch
On Do. 20. Sep. 2007, 13:03:31, [EMAIL PROTECTED] wrote: Goals: Completely unified testing. The ability to run tests and aggregate their results regardless of how the test is implemented, (perl, parrot, hll, etc.) HTML Reports should function much as we have now, but with the additional ability to look at results across versions to check when tests were injected. Hi, after the release of Test::Harness 3.03 I'm wondering about the status of the 'unified_testing' branch. I merged the changes in trunk that happened since the last merge. svn merge -r 21797:23132 https://svn.perl.org/parrot/tru After fixing an issue with hardcode pathes I could run 'make smoke' and 'make languages-smoke'. http://smoke.parrotcode.org/smoke/parrot-smoke-0.5.0-devel-r23154-unknown--i386-linux-cc-default--1196200586-443--10169-10164-5-284-594-3--2d443430202d2d67632d6465627567--a503316a8736a7166163f1b2a0511f21.html http://smoke.parrotcode.org/smoke/parrot-smoke-0.5.0-devel-r23154-unknown--i386-linux-cc-default--1196201509-715--2947-2455-492-61-50-0--6c616e677561676573--0137598e1bd34c520ede56c629be7e85.html I wonder whether any major obstacles have surfaced and whether it makes sense to merge the changes in 'unified_testing' with 'trunk' again. Regards, Bernhard -- /* [EMAIL PROTECTED] */
Re: [perl #47792] [BUG]: languages/dotnet/Configure.pl causes configuration error
James E Keenan schrieb: On Nov 25, 2007, at 12:52 PM, Paul Cochrane via RT wrote: This error has been happening in dotnet for a long time. I can't give you a better timeframe than that, but it's been in that state (giving these warnings) since before I managed to get it's Configure.pl to go again, (which was a few months ago now). Paul: I really have to wonder about that. In my work, I am *constantly* running: svn update;perl Configure.pl ... and I only started to get this error today. As I was offline for a couple of days, the error has to have crept in since Thursday. The difference is that the root Configure.pl is now also generating 'language/dotnet/Makefile' by executing 'cd languages/dotnet; perl Configure.pl' in gen::languages. Previously 'languages/dotnet/Makefile' was only generated when 'cd languages/dotnet; perl Configure.pl' was called manually. Generating 'language/dotnet/Makefile' by the root Configure.pl became necessary, because I made 'make realclean' more thorough in cleaning up. As far as I see it, the output that are seen are harmless warnings from 'languages/dotnet/Configure.pl'. If nobody beats me to it, I take a look at it after experimenting with 'languages/plumhead/Configure.pl'. Regards, Bernhard
[perl #31633] [TODO] Allow Languages to be self contained
On Mi. 05. Jul. 2006, 12:17:12, bernhard wrote: Contrive things so that no code whatsover must be maintained outside of the language specific directory. This includes: When adding Eclectus I had to edit following files: - config/gen/makefiles/languages.in - config/gen/languages.pm - languages/LANGUAGES_STATUS.pod Adding info to LANGUAGES_STATUS.pod is reasonable. config/gen/languages.pm handles the configuration of languages. Primarily configuration is the generation of the file LANGUAGE/Makefile. I propose that languages should follow the 'dotnet' way, that does configuration with: cd LANGUAGE; perl Configure.pl. Thus gen::languages could simply loop through the the subdirs of the 'languages' directory. The language specific targets of 'languages/Makefile' could also be generated from a loop over the subdirs of 'languages'. The root Makefile also has a list of generated Makefiles of the languages. This list could be done away with, with cleaning up is done with 'make languages-realclean'. Any comments ? -- /* [EMAIL PROTECTED] */
Re: [perl #47560] [BUG]: 'make realclean' not exiting cleanly
James Keenan (via RT) schrieb: # New Ticket Created by James Keenan # Please include the string: [perl #47560] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47560 Coke reported this evening that 'make realclean' was not exiting cleanly: 08:18 Coke make -C languages realcleanmake[1]: *** No rule to make target `realclean'. Stop. 08:19 Coke (from `make realclean`) I confirmed this on Darwin which recently had been svn-updated: make -C languages realclean make[1]: Entering directory `/Users/jimk/work/parrot/languages' make[1]: *** No rule to make target `realclean'. Stop. make[1]: Leaving directory `/Users/jimk/work/parrot/languages' make: *** [languages-realclean] Error 2 I called svn update in a sandbox that had not been updated since r22850 and got: Uconfig/gen/makefiles/root.in Uconfig/gen/makefiles/languages.in Ulanguages/jako/config/makefiles/root.in Ulanguages/PIR/config/makefiles/root.in Ulanguages/APL/config/makefiles/root.in The effect should go away with the next 'perl Configure.pl svn up'. The 'realclean' target of Makefile now depends on the new 'realclean' target of 'languages/Makefile'. The two changes were done atomically in a single commit. That's why I didn't expect this effect. I assume that the root Makefile was updated by the automatically by usr/bin/perl tools/dev/reconfigure.pl --step=gen::makefiles --target=Makefile which didn't look for changes in 'config/gen/makefiles/languages.in'. I'll take a brief look at reconfigure.pl . Regards, Bernhard
[perl #41597] [PATCH] replacing explicit access to $^O in Configure
On Fr. 23. Feb. 2007, 07:28:38, acalpini wrote:
this patch adds an 'osname' key to Parrot's own $conf-data, which is
used in the configure process instead of $^O (and $Config{osname}).
this patch does not affect the current configuration process. in the
long term, an --osname parameter (along with --arch and others,
probably) will be added to Configure.pl, to provide support for
cross-compilation.
as of now, the value of $conf-data-get('osname') ALWAYS returns $^O.
This patch hasn't been applied yet.
It make sense to me as it is a prerequisite for cross-compilation.
Should I go ahead and try to apply the patch ?
Regards,
Bernhard
--
/* [EMAIL PROTECTED] */
Re: adding failing tests (was t/pmc/objects.t test failures in RT)
Allison Randal schrieb: As a general rule of thumb, if you find a failure but don't have the time/expertise to debug it or classify it as TODO or BUG or new underdocumented feature, but do have enough time to create a failing test for the problem (always nice), submit a ticket explaining the problem and attach the test to the ticket. The patch monster/cage cleaner who handles the ticket can decide if the test is good and where/whether it should be added to the test files. Yes, that makes perfect sense. Best regards, Bernhard
Re: [perl #46541] [BUG] t/pmc/objects.t test failures
Allison Randal schrieb: I saw the failing test, but didn't know where it came from or why it was there. (And until I dug into it the commit logs, I didn't even know if it was an old test that I had broken while working on the threads tests.) I added this failing, as the test '1 equals 1' in languages/lisp/t/arithmetics.t started failing after the merge. Investigating that failure, I found that I could reproduce the problem with a simple PIR test case. This is what I added in t/pmc/objects.t. So it's a test for something that was previously working. I don't see why. I'd like to see Parrot be in a releasable state with every checkin. That's why we have the tests. I support this as a rule. I broke it when I merged in the pdd15oo branch with 4 failing tests because I was planning to fix them right away. I did cut it down to 3 failing tests, and resolved the surface issues with the remaining 3. But, there's a deeper issue with cloning vtable overrides across threads that I haven't resolved yet (the interpreter cloning code is sorely in need of a rewrite). So, I'll mark those as TODO, with a reference to the tickets that James created (thanks, James!). Yes, that's the intention of 'TODO' as I understood. Tests that are failing because something isn't done yet. But IMHO somebody should look at the issue and classify it as TODO. IMHO the classifier doesn't have to be submitter of the test case, as there should be a low entrance barrier for adding tests. Regards, Bernhard Allison
Re: [perl #46541] [BUG] t/pmc/objects.t test failures
chromatic schrieb: On Thursday 18 October 2007 18:04:15 James Keenan wrote: Linux. r22261 [li11-226:parrot] 559 $ prove -v t/pmc/objects.t t/pmc/objects1..74 ok 1 - find_type (base class) [snip] not ok 57 - equality of subclassed Integer # Failed test (t/pmc/objects.t at line 1668) # got: '123 is not equal to 123 # ' # expected: '123 is equal to 123 # ' ok 58 - short name attributes Bernhard added this one in r22241, but didn't TODO it or file a ticket (as I can tell). TODOd in 22265. Why should it be a TODO test? As far as I see, it exposes a real bug. So I want a red light going on. TODOing known bugs for a release is a different issue. Regards, Bernhard
Re: [perl #39824] [CAGE] tools/dev/check_source_standards.pl -- this should be a test
Paul Cochrane via RT schrieb: On Fri Nov 17 14:17:18 2006, particle wrote: ~ all but one test have been adapted for and moved to t/codingstd/ ~ remaining test is for not-yet-approved codingstd item The remaining test complains about more than one '.' in a filename and filenames which don't conform to the 8.3 format. I have talked to some VMS people at YAPC::EU 2007. For them the more than one '.' issue was a real problem, that they had to work around before even creating a Makefile. Regards, Bernhard My feeling is that these should be guidelines but are not strict enough for a test. What are people's feelings? Allison: do you wish to make a decision about this particular coding standard item? Anyway, can this file (check_source_standards.pl) be removed and this ticket closed?
Re: [perl #46007] [CAGE] licensing cleanup
Allison Randal (via RT) schrieb: Review these languages and decide whether to update the license or move them to the google-code repository for Parrot languages: languages/m4/README:15 What is the legal situation for Parrot m4? Personally I would like to put 'languages/m4' under Artistic 2.0. But I'm not sure whether this isn't a derived work. I implemented Parrot m4 by: i. Looking at the GNU m4 source code ii. Implemented in PIR, based on the C source code, taking source organization from GNU m4 iii. In the case of eval.c, taking only slightly modified GPLed source code I'm sure the eval.c has to stay GPL licensed or be removed. I'm not sure about the PIR code. Regards, Bernhard
Re: [IMCC] add .label to lexer for macro labels
Klaas-Jan Stol schrieb: I wonder in what case it's useful to have a normal .local directive in a macro (with its normal semantics). Every time the macro is expanded, the same local var. would be declared, which can't be good. As far as I understand it, PIR macros a simple text replacements with some magic, like for '.label'. So it could be used to add boilerplate code to subs. E.g: .macro init_log() .local string my_debug .endm .macro log(MSG) concat my_debug, .MSG .endm .macro print_log print my_debug .endm .sub my_sub .init_log() .log( 'my log message') .print_log() .end In this case a regular '.local' is more or less sensible. So, it'd make sense to have '.local' generate a unique var within a macro, but it does break consistency a bit (because the same directive does different things, but arguably it does the *right* thing in different contexts). I would prefer to be more consistent and less magic. Regards, Bernhard
Re: [PATCH][IMCC] add .label to lexer for macro labels
Klaas-Jan Stol schrieb: hi, attached a patch that adds .label as a directive to declare labels in a macro. Applied in r21624. The big overall cunning plan is to remove .local for this purpose (defining labels), and to use .local ONLY for declaring variables. Then, once all .local (in macros) are replaced by .label, we can start replacing .syms by .local, so that .sym can be removed from the lexer. Shouldn't that be '.macro_local' or something like that ? CU, Bernhard
Re: [perl #45697] [PROPOSAL][IMCC] Remove optional comma for sub flags
Klaas-Jan Stol (via RT) schrieb: .sub :load, :init :main ## newbies may wonder why there's a comma sometimes #... .end Instead, it should look like this: .sub :load :init :main # ... .end The version without the ',' looks saner and consistency is a good thing. So I second this proposal. Regards, Bernhard
Re: [perl #45703] [PATCH] my 1st patch: cleaning up some headerizer warnings as noted in RT 45593
[EMAIL PROTECTED] (via RT) schrieb:
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #45703]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45703
As a start of contributing to parrot, I cleaned a file of the headerizer warnings as noted in RT 45593, because this is my first patch i only changed one file (to keep it simple).
Hi,
welcome to the vibrant world of Parrot.
I have a question regarding your patch. Are you sure about
@@ -87,7 +89,7 @@
PARROT_API
void
-imc_cleanup(PARROT_INTERP, void *yyscanner)
+imc_cleanup(PARROT_INTERP, NULLOK(void *yyscanner))
{
IMCC_pop_parser_state(interp, yyscanner);
clear_globals(interp);
I gather that imc_cleanup() does cleaning up and probably needs
an initialized yyscanner. So Parrot should either be prepared for
yyscanner being NULL or complain loudly.
Best regards,
Bernhard
Re: [perl #45023] SUGGESTION inlining subs
Patrick R. Michaud schrieb: On Tue, Aug 28, 2007 at 09:37:39AM -0700, Debbie Harry wrote: # New Ticket Created by Debbie Harry # Please include the string: [perl #45023] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45023 Maybe it would be useful to support inlining of subs (at PIR level?) This would support good programming style. Well, I'm a bit confused as to what's being asked here, so I'll go ahead and ask for some clarification. Are you asking for the ability to define subs in PIR such that any PIR-based calls to those subs are then inlined? Or are you looking at this from more of a high-level language (HLL) perspective, such that someone writing in a HLL can designate certain blocks as being suitable for inlining? I remember this as a conversation I had with a German guy at YAPC::EU. The idea was optimisation of PIR code. Avoid the overhead of argument passing by inlining subs in the PBC. My suggestion was to start a discussion by submitting an RT ticket for that idea. Regards, Bernhard
Re: [perl #42769] Names of basic PMC serve as keywords in PIR
Patrick R. Michaud schrieb: related to this, I think that imcc also allows for built-in types as types. such as .local Array a etc. (sorry can't check; don't have my own pc around here, this is a public pc) (I added some notes about this and other PIR cleanups in languages/PIR and I think also in compilers/pirc IIRC). In fact, I think many PIR programmers will find this confusing. Let's stick with 'pmc' for now -- we can extend it later if need be. The question is not whether this feature should be added, but whether it should be first deprecated and then removed. Currently .sub main :main .local Array my_string my_string = new String my_string = 'hello' say my_string .end is valid PIR. Regards, Bernhard
[perl #42769] can't create a variable named 'object'
On Fr. 27. Apr. 2007, 14:02:49, smash wrote: On Fri Apr 27 09:36:50 2007, particle wrote: it seems that 'object' is a reserved word in imcc, it's a synonym for 'pmc'. it seems undocumented, and i don't see a reason for it--we already have a word for 'pmc'. I removed 'object' from IMCC lexer and grammar, so it's not a reserved word anymore and can be normally used as a variable name: The patch from smash did not apply cleanly any more, so I manually applied it and add a test. The new patch is attached. Does anybody mind if 'object' is removed as an alias of 'pmc'? As 'object' hasn't been documented, I think that no deprecation cycle is necessary. Regards, Bernhard -- /* [EMAIL PROTECTED] */
[perl #42769] Names of basic PMC serve as keywords in PIR
On So. 29. Apr. 2007, 06:01:16, kjs wrote: In r21167 the keyword 'object', as a synonym of 'pmc', was removed from PIR. However the question from kjs remains to be answered: related to this, I think that imcc also allows for built-in types as types. such as .local Array a etc. (sorry can't check; don't have my own pc around here, this is a public pc) (I added some notes about this and other PIR cleanups in languages/PIR and I think also in compilers/pirc IIRC). IMHO, this is not needed; pmc is sufficient, and it'd be nice to keep PIR as simple as possible, after all it's an intermediate language. Moreover, everytime a built-in type is added (although not happening that often) the grammar would have to be updated to stay consistent. I second the suggestion from kjs. It isn't helpful to be able to say: .local Array my_string my_string = new String Regards, Bernhard -- /* [EMAIL PROTECTED] */
[perl #42300] [PATCH] t/pmc/sub.t: test for creation of lex by clone op
On Do. 26. Apr. 2007, 16:45:08, [EMAIL PROTECTED] wrote: Now it makes sense. :) Anyway, I found this by following the Compiler FAQ, which says that a new closure should be created by cloning the sub. I think it should be changed to say newclosure, or even explain this (because you might really want to clone the Sub in some cases.) Hi, in r21136 I have changed compiler_faq.pod, so that it now uses 'newclosure' instead of 'clone'. More explanation could also be added to 'examples/tutorial/80_closure.pir'. As the original issue has been clarified, can I close this ticket? Regards, Bernhard -- /* [EMAIL PROTECTED] */
[perl #40626] [BUG] :vtable fails for subclasses of core classes
thanks for the quick turnaround. this test is perfect for the 'executed from pir test case', and will be applied shortly. The test case has been added in r21092. but as patrick later provided an example of executing a .pbc file, we'll also need a test for this before the ticket is closed. I propose to close this ticket, as running the PIR and PASM test by generating first PBC is issue of RT#41666. The good news is that it really works: [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot$ ./parrot -o t.pbc t/pmc/objects_78.pir [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot$ ./parrot t.pbc Hello world Hello world [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot$ ./parrot t/pmc/objects_78.pir Hello world Hello world [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot$ Any comments? Bernhard -- /* [EMAIL PROTECTED] */
Re: Change 21059 breaks src/dynpmc/gdbmhash.pmc
Andy Dougherty schrieb: Change 21059 removed #include parrot/parrot.h from gdbmhash.pmc. But gdbmhash.pmc then goes on to do all sorts of things with STRING and PMC. Obviously, they no longer work. Was this deliberate? If so, what's the plan forward? Sorry, this was definitly not deliberate. Om my machine there is no 'libgdbm', so the broken code was never compiled here. My understanding is that dynamic ops and dynamic PMCs are extenders of Parrot, so they should only use the symbols available with 'parrot/extend.h'. The plan forward is that extenders should use Parrot_String and not STRING. Regards, Bernhard
Re: [perl #45109] [Lisp] Breakage when an unused PMC is removed
Ron Blaschke via RT schrieb: In all three sections a value is loaded into a register and then set as an attribute on an object. In the first hunk only the used register is changed from 0x12 to 0x13. In the second hunks it's register 0x11 to 0x12. With hunk three it's getting interesting because only the first occurrence changes from 0x13 to 0x11. set_attribute still uses 0x13, which is wrong I think. In the end, the wrong (Sub) value is put into the object's attribute because the wrong register is used. The error that comes up later is not because the arguments are wrong, but because the wrong sub is called. Can anyone tell if I'm on the right track? Yes, I can see the pattern. One possibility to verify this, is to add a 'dummy_5' PMC. I'd expect three hunks again, but the third hunk should than conform to the two first hunks. Is this a register allocator bug? Regards, Bernhard
Re: [perl #43342] [TODO] config/init/miniparrot.pm: Write unit tests
James Keenan via RT schrieb: There was code in several of the test files in the reconfigure/ branch which was repeated. At the hackathon, David Adler refactored it into a subroutine which I then placed in new file Auxiliary.pm. That file is contained in this patch along with a revised t/104-init_miniparrot.t and appropriate MANIFEST revisions. Please review. Thank you very much. kid51 Reducing code redundancy is good idea. My suggestion is to call the packaga something like Parrot::Test::Configure and accordingly move the file to lib/Parrot/Test/Configure.pm. Regards, Bernhard
Re: t/codingstd/perlcritic.t needs to be optional
chromatic schrieb:
On Wednesday 27 June 2007 13:22:22 Andy Lester wrote:
The Perl::Critic testing in t/codingstd/perlcritic.t needs to be
optional. The existence of Perl::Critic on a machine doesn't mean
that it's appropriate to run Perl::Critic on the Parrot code.
I'd like to see an option to run it only on *modified* files. I'm not aware
of a mechanism where source code mysteriously changes without the presence of
cosmic rays, and I'm not aware of any testing mechanisms reliable in the face
of cosmic rays.
Actually it seemed to have happened at my company,
http://use.perl.org/~Bernhard/journal/33593
Suddenly a space had changed into a '(' in Sys::Hostname. However It
didn't need Perl::Critic to uncover that.
Regards,
Bernhard
Re: [perl #43413] [TODO] Pass options to policies from perlcritic.t command line
Paul Cochrane (via RT) schrieb:
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #43413]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43413
Hi,
In perlcritic.t i'd like to find a way to pass options to perlcritic
policies from the command line. Options are passed as anonymous
hashes. Basically, we want to be able to do something like:
perl t/codingstd/perlcritic.t --list
--policy=CodeLayout::ProhibitHardTabs={'allow_leading_tabs'=0}
and it to give the output:
CodeLayout::ProhibitHardTabs = \{
'allow_leading_tabs' = 0
}
Isn't that reimplementing 'perlcritic' ?
If somebody wants to work on satisfying a new policy one can set up a
my_perlcriticrc file and call
perlcritic --profile my_perlcriticrc
Another question. Can we simplify perlcritic.t by using Test::Perl::Critic?
Just my $0.02,
Bernhard
[perl #41915] [TODO] remove unused manifest-generating scripts
On So. 06. Mai 2007, 12:09:58, bernhard wrote: TODO: Check whether Parrot::Distribution::gen_manifest_skip() can be used in mk_manifest_and_skip.pl or alternatively be deleted. Parrot::Distribution::gen_manifest_skip() and subsequently t/distro/manifest_skip.t have been broken for some time. Does anybody mind if I remove them? -- /* Bernhard.Schmalhofer !-- x -- at gmx.de */
Re: [perl #43251] [PATCH] Rename tools/dev/mk_manifests.pl
James Keenan (via RT) schrieb: According to its documentation, mk_manifests.pl ...generates a set of FMANIFEST.* files that give the final locations in the file system for all the installable files listed in FMANIFEST and FMANIFEST.generated. The name of this program is close to that of tools/dev/ mk_manifest_and_skip.pl -- confusingly close, IMHO. The patch attached changes the name to be more self-documenting: mk_rpm_manifests.pl. I have come to the same conclusions, when I tried to resolve RT#41915. Perhaps somebody who knows about creating Parrot distributions can comment whether 'tools/dev/mk_manifests.pl' and 'tools/dev/installfiles.pl' are needed at all. Regards, Bernhard
Re: [svn:parrot] r18988 - trunk/lib/Parrot
chromatic schrieb:
@@ -697,7 +694,7 @@
$builder-diag('$cmd' failed with exit code $exit_code)
if $exit_code and not $pass;
-unless ( $ENV{POSTMORTEM} ) {
+if ( ! $ENV{POSTMORTEM} ) {
unlink $out_f;
}
That's an ... odd definition of beautification. I prefer:
unlink $out_f unless $ENV{POSTMORTEM};
It's two lines shorter and has several fewer punctuation characters.
That's an habit formed by Perl::Critic:
ControlStructures::ProhibitUnlessBlocks- replace 'unless (' with
'if ( !'
ControlStructures::ProhibitPostfixControls - use postfix controls only
for functions like |die|, |croak|, and |confess|
But as beauty lies in the eye of the beholder, it's just a matter of taste.
Regards,
Bernhard
Re: [perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
Nicholas Clark schrieb: On Sun, Jun 03, 2007 at 08:00:18AM -0700, Bernhard Schmalhofer via RT wrote: I have looked at the 'more_memory.patch' and I'm wondering about the portability. In that patch loops where pointers are explicitly set to NULL are replaced with a memset( start, 0, len); What happens when NULL is not a consective series of '\0' chars? I think that it breaks. Are there such platforms and are they releavant for parrot? I believe that this assumption is endemic in Perl 5, and it's never hindered Perl 5's portability. The C FAQ gives examples of platforms where NULL is not all bits zero - http://c-faq.com/null/machexamp.html - and I've never encountered anyone using them. (As an aside, I think that Perl 5 also (mostly?) doesn't assume 2s complement storage of integers. IIRC a bug report from a Ahmdal mainframes gave the impression that it was using sign and magnitude. However, we've not heard about anyone using Ahmdal mainframes in years. Likewise no-one has missed the removal of memory model support from Configure, so presumably no-one is compiling on a PDP-11 anymore. We did discover nasal daemons, or something similarly painful, on Irix64, until we removed assumptions about signed integer overflow. (It's undefined behaviour. It will bite)) Nicholas Clark
[perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
What happens when NULL is not a consective series of '\0' chars? I think that it breaks. Are there such platforms and are they releavant for parrot? I believe that this assumption is endemic in Perl 5, and it's never hindered Perl 5's portability. The C FAQ gives examples of platforms where NULL is not all bits zero - http://c-faq.com/null/machexamp.html - and I've never encountered anyone using them. This answers the question. So I propose to apply Mehmet's patch and add to pdd07 something like: --- pdds/pdd07_codingstd.pod(Revision 18803) +++ pdds/pdd07_codingstd.pod(Arbeitskopie) @@ -62,6 +62,9 @@ integral type (no smaller than typedef CINTVAL in Parrot), then back to its original type, without loss. +Also C code may assume that there is a single NULL pointer representation +and that it consists of a number, usually 4 or 8, of '\0' chars in memory. + C code that makes assumptions beyond these must depend on the configuration system, either to not compile an entire non-portable source where it will not work, or to provide an appropriate #ifdef macro. Regards, Bernhard -- /* Bernhard.Schmalhofer !-- x -- at gmx.de */
[perl #43105] [PATCH] function mmd.c::mmd_expand_y: newly allocated memory unitialized
I grepped for other files that can make use of mem_sys_*_zeroed variants. I attached a patch that affects objects.c, vtables.c, gc/register.c and stm/waitlist.c. I have looked at the 'more_memory.patch' and I'm wondering about the portability. In that patch loops where pointers are explicitly set to NULL are replaced with a memset( start, 0, len); What happens when NULL is not a consective series of '\0' chars? Are there such platforms and are they releavant for parrot? -- /* Bernhard.Schmalhofer !-- x -- at gmx.de */
Re: new FAQs
Josh Wilmes schrieb: The compiler tools target Parrot, so that it will be easier for people (including us) to write languages that run on Parrot. I understand. I'm just saying that *if* perl 6 were being written to target an existing VM, any brilliant compiler tools could be written to target it as well. It's not parrot that makes these possible. Sure, that's what I want to showcase with 'Plumhead'. A side by side comparison of several compiler tool that target the same language, PHP, to the same virtual machine, Parrot. Currently the compiler tools that I'm toying with are: - XML output of phc, transformed by XSLT - ANTLR3 - PGE and TGE On my TODO list are: - lex and yacc - Perl 5.10 regexes The downside is that all these implementations are still very rudimentary. But that's entirely due to my lack of abiltity and time. Regards, Bernhard
[perl #43008] [PATCH] docs/tests.pod: Expand discussion of testing of Perl 5 components of Parrot
On So. 20. Mai 2007, 15:45:56, jkeen !-- x -- at verizon.net wrote: The patch attached reflects the approach we've been taking over the last half-year or so in testing the Perl 5 components of Parrot. Feedback encouraged. Thanks, patch applied in r18608. My $0.02: When hearing 'executables' I primarily think of compiled programs, e.g. compiled C-programs. Personally I'd call the *.pl files simple scripts. A pointer to http://qa.perl.org could be useful. Mentioning Perl::Critic and the tests in t/codingstd would also be nice. Best regards, Bernhard -- /* Bernhard.Schmalhofer !-- x -- at gmx.de */
Re: [perl #42883] [PATCH] Fix up headerfile guards
Mark Glines schrieb: * Fix up the indentation problems caused by the above bullet point. (TODO: why does t/codingstd/c_indent.t require indentation for #if and #ifdef, but not for #ifndef?) As far as I understand c_indent.t, #ifndef is also covered Except that it isn't. If you apply the attached patch, you will see that t/codingstd/c_indent.t starts failing. C_indent.t will not be happy until you reindent everything else, inside of it. (This patch should not be checked in, it only exhibits the problem, it does not solve anything.) After applying c_indent_doesnt_recognise_ifndef.diff I got no complaints from c_indent.t. Could you check again? In r18452 I checked in a small beautification of c_indent.t, which shouldn't have chaned the algorithm. On Sat, 05 May 2007 07:58:45 -0700 Bernhard Schmalhofer via RT [EMAIL PROTECTED] wrote: I'd like to write some tests for this stuff, and then fix up the rest of the cases (I know I've missed a bunch). How would the list feel about a patch to PDD07 specifying the above for header files, and a codingstd test to enforce it? My feeling is that we need to differentiate two cases: i. header files that define an interfaces for e.g. a subsystem ii. Convenience headers, that contain declaration of internal functions Case i. might need stricter checks than ii. Thanks for your input. I have written a test case for this, t/codingstd/c_header_guards.t (attached), which checks the following: * The existence of an #ifndef PARROT_*_GUARD * That each header file only contains one #ifndef PARROT_*_GUARD * The existence of a matching #define (this caught a few misspells) * The existence of an #endif /* PARROT_*_GUARD */ * That the PARROT_*_GUARD macro is unique (doesn't stomp on any other files) I patched up another large set of headers, to pass this test. But before I send in another big patch with some changes to type ii (convenience) headers, can you please tell me if there's a clean, programmatic way to determine which headers it should perform strict checks on? That way I can fix the test to only run on the non-convenience subset of headers. IMHO the above tests looks quite sane for all header files. For API defining headers I was vaguely pondering a check like. Make sure that the API does not change, unless there has been a deprecation cycle. This might be along the lined of 'tools/dev/parrot_api.pl'. Also, should any of the above tests be applied to type ii headers, or should they only apply to type i headers? (Should type ii headers be ignored completely, or only subjected to a subset of the tests?) Checking for header guards in all *.h files sounds good to me. Regards, Bernhard
Re: [perl #42883] [PATCH] Fix up headerfile guards
Jerry Gay via RT schrieb: On 5/4/07, via RT Mark Glines [EMAIL PROTECTED] wrote: * Standardize on PARROT_*_GUARD style names for these lines (some headers used a style that looks like __PIRLEXER_H instead) It looks like the __FOO_H convention was only used in compilers/pirc. There are no generated files there. there's a problem here... compilers/imcc/pirlexer.h is a *generated* header file. next time somebody runs Cperl Configure.pl --maintainer to make lexer changes, this file will be regenerated by bison, and your changes will be lost. I have been skimming through the *.y and the *.l files and found no header guards. AFAIK lex and yacc produce no guards, so this should be fine as well. Regards, Bernhard
Re: [perl #37997] r10604 build failure on Cygwin
Eric Hanchrow schrieb: I use Cygwin and am willing to occasionally test the build on it. Alas I have no clue how to actually -develop- for Cygwin, so I doubt I'd be much help fixing any problems that I find. But I'd be happy to svn up; perl Configure.pl make all test and summarize or post the results. You can also use make smoke', as documented in docs/tests.pod. The results of smoke testing should show up in http://smoke.parrotcode.org/smoke/. Regards, Bernhard
Re: [svn:parrot] r17814 - in trunk: . compilers/pirc
Will Coleda schrieb: Is it me, or did this also change all the paths in MANIFEST.SKIP from win style with backslashes to unix style with slashes? I've seen the same effect. I suppose if stems from the changeset 17760, where tools/dev/mk_manifest_and_skip.pl got a fix for Windows. Under Linux 'perl Configure.pl' and 'make manitest' are not complaining, so I suppose the the patch is OK. Regards, Bernhard
Re: What Skills Do We Need to Finish Parrot?
Joshua Isom schrieb: On Feb 7, 2007, at 1:49 PM, chromatic wrote: On Tuesday 06 February 2007 15:56, James Keenan wrote: On Feb 6, 2007, at 12:07 PM, Allison Randal wrote: E ... I'm the one who *needs* the tutorial, not the one to write it. That makes you a prime person to capture the questions it needs to answer! You can't evade the Responsibility Ponies that easily. -- c Or at a minimum a prime candidate to start a pir faq(frequently asked doesn't mean you need to know the answer to add a question). Or add questions to docs/imcc/imcfaq.pod Another €0.02, Bernhard
Re: [PATCH] PIR updates
Klaas-Jan Stol schrieb: attached a patch for languages/PIR, fixing: Thanks, applied in r16892. When I made the patch, *again* it contained the contents of the new files twice. I manually removed the double contents from the patch file. Yes, this time the patch applied without any hassle. Thanks, Bernhard
Re: use diff for string in some test
Nicholas Clark schrieb: On Sun, Jan 07, 2007 at 03:34:41PM +0800, Lee Duhem wrote: I think we need some diff-like facility for string in Test::More (or somewhere else appropriate), these options of diff for files will be wanted: -E --ignore-tab-expansion Ignore changes due to tab expansion. -b --ignore-space-change Ignore changes in the amount of white space. -w --ignore-all-space Ignore all white space. -B --ignore-blank-lines Ignore changes whose lines are all blank. --strip-trailing-cr Strip trailing carriage return on input. Shouldn't that have failed tests before it was checked in? I'm not convinced that allowing slop in expected output is a good idea. It introduces (more) complexity into the tests, which increases the chance for false positives (errors in the tests reporting themselves as failures, distracting developers) and false negatives (tests not spotting real errors) I think the t/examples/past.t is one of the rare cases where ignoring whitespace would be useful. Generated code is allowed to change, as long as it still does the wanted thing. However, the only purpose of t/examples/past.t is to check that examples/past/01-sub.pir is still working. This can be guaranteed with a regexp-based sanity check, as it is done now. So there is no immediate need for action. I propose to use Test::Differences for other reasons. When comparing texts with eq_or_diff() it is much easier to see where the deviation is. It is also much easier to decide wheter the code or the test is incorrect. Regards, Bernhard
Re: SVN tips in wranglers.pod
Paul Cochrane schrieb: In the attached patch, I've added a section on SVN usage tips for the doc/dev/wranglers.pod documentation, mostly distilled from wisdom on #parrot. Is there anything else people think should be added before I commit the patch? Or any changes to the pod itself? When the commit is associated with a ticket in RT, I usually copypaste the ticket header. e.g. #39197: [CAGE] lib/Parrot/Test.pm ignores core dumps failures!CU, Bernhard
Re: Questions about DEPRECATED.pod
Paul Cochrane schrieb: Hi all, I was having a poke around in DEPRECATED.pod and I've got a couple of questions about the items therein: .imc file extension paragraph: There aren't any .imc files in parrot anymore as far as I can tell. So, should this paragraph be in DEPRECATED.pod anymore? If not, I can supply a patch removing it. From looking at the parrot-porters thread associated with the paragraph, there might still be some outstanding issues, with this change. Is this still the case? AFAIK all '*.imc' have been renamed. Deprecated opcodes paragraph: To remove the deprecated Cfetchmethod opcode does one simply remove the references to it in src/ops/object.ops (and other .ops files), and remove the function from src/ops/ops.num? Does one then move all of the ops numbers up so that there isn't a gap caused by removing the opcodes? Is this relabelling of the opcode numbers going to break anything else? If not, should I go through and remove references to Cfetchmethod and fix up ops.num and patch? I think you mostly got it. For the renumbering of src/ops/ops.num you can use make -f tools/dev/ops_renum.mak Also see the notes in PBC_COMPAT. CU, Bernhard
Re: [#39063 and #40066] boolean arrays
Karl Forner schrieb: So in my opinion too this pmc should be rewritten. I'm ready to do it, based on my fixedbooleanarray implementation, but before doing it I need some answers : Yes, I've always why ResizableBooleanArray extends FixedBooleanArray and why FixedBooleanArray is not simply a special case of ResizableBooleanArray. pdd17_basic_types.pod says nothing about the implementation, so whatever works should be OK. What are the requirements/constraints of a ResizableBooleanArray ? e.g are unshift to be less frequent that shift ? What's a typical usage test case ? Should I keep the actual implementation concept : allocating by chunks of 64 bytes ? Sorry, no answers to that, just more questions. Is there a real difference between boolean arrays, big integers and binary data? Are the above really different from a STRING ? If not they could become the same thing, or at least share a common implementation. Of course it would be nice to have all the bitwise and arithmetic methods available. Can the C-code of the Perl5 Module Bit::Vector reused for that? Another item on my wishlist is the interaction with the outside world. It would be nice to be able to pass a BooleanArray|BigInt|Binary PMC directly to image manipulation, math and encryption libraries. So something like morphing to and from UnmanagedStruc would be cool. Just my $0.02, Bernhard
Re: Bytecode PDD
Jonathan Worthington schrieb: Hi, I've checked in the proposed bytecode PDD and also most of the changes that I discussed with Allison earlier today. Feedback on it would be greatly appreciated. One thing that I noticed is the naming of the new field UUID. ||| The UUID is | ||| computed by applying the hash function specified in| ||| the UUID type field over the entire packfile not | ||| including this header and the trailing zero padding Shouldn't this field be renamed to something like 'checksum' ? The term 'UUID' already has a specific meaning, http://en.wikipedia.org/wiki/UUID. CU, Bernhard
