[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__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] */
[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] */
[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] */
[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] */
[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] */
[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] */
[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] */
[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] */
[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] */
[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] */
[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] */
[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] */
[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] */
[perl #49794] Configure.pl syntax errors - revision 24880
On Di. 15. Jan. 2008, 09:04:47, [EMAIL PROTECTED] wrote: > > Line 366 was: > <<< .mine >use 5.008_000; >use strict; >use warnings; >use lib 'lib'; > > just after here. So I deleted Configure.pl reran the svn fetch (showed no > files transfered) and the new Configure.pl worked fine. > > Did I catch a partially implemented svn update? Yes, it looks like there was a merge conflict. Probably you made local changes to Configure.pl. In the meantime the Configure.pl in the SVN repository was changed as well. When updating 'svn' tried to accomodate both set of changes, that is it tried to merge the two sets of changes. However merging was not possible and 'svn' marked the conflicts in the merged Configure.pl. Thus comes the <<< .mine line. 'svn status' would have marked Configure.pl with a 'C' for conflict. Deleting the file and updating again was the right action. Alternatively 'svn revert Configure.pl' should have worked as well. Regards, Bernhard -- /* [EMAIL PROTECTED] */
[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] */
[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] */
[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] */
[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 #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 #43855] embed.h no longer needs the Parrot_init prototype
On Fr. 13. Jul. 2007, 09:47:53, [EMAIL PROTECTED] wrote: > There's a comment in embed.h which says: > > /* XXX Parrot_init() should be removed, no longer required for embedders */ > > This comment has been there since April 2006. The Parrot_init() > prototype is redundant with the one in interpreter.h. I removed the > one in embed.h and saw no ill effects. I went a step further. Functions used only inside Parrot shouldn't have the prefix 'Parrot_'. So I renamed Parrot_init() to init_world_once() and relocated it tio global_setup.c. I'll close this ticket, if no breakages are reported. 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] */
[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 at gmx.de */
[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 C 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 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 at gmx.de */
[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 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 at gmx.de */
[perl #32642] [TODO] Remove Perl* PMCs from parrot's basic PMCs, src and languages
Hi, as far as I see, the Perl* PMCs are no longer used in the Parrot core. There is still some usage in unmaintained language implementations: BASIC/compiler unmaintained ? BASIC/interpreter unmaintained ? forth unmaintained ? miniperlunmaintained ? parakeetunmaintained ? regex unmaintained ? 'punie' seems to be the only maintained language implementation using Perl* PMCs. Also some tests and examples are using the Perl* PMCs. The next step is to make the Perl* PMCs dynamic. What are the opinions, WRT moving the Perl* PMCs to src/dynpmc or languages/punie/pmc ? In the latter case they could be renamed to Perl1*. Regards, Bernhard -- /* [EMAIL PROTECTED] */
[perl #38235] [TODO] Rename (dyn)?classes to (dyn)?pmc
> [bernhard - Di 17. Jan 2006, 13:02:44]: > > > I propose to rename 'src/classes' to 'src/pmc' > > > > > Yes, and for consistency please also rename dynclasses to dynpmc and the > > t/dynclass to t/dynpmc. The second step of directory renaming has been completed. Altogether follwing dirs have move: src/dynclasses -> src/dynpmc t/dynclass -> t/dynpmc src/classes -> src/pmc Please do a 'svn up' followed by a 'perl Configure.pl'. If 'svn status' reports a spurious dir 'src/dynclasses', 't/dynclass' or 'src/classes', then simple remove it. Please holler, when scripts or tests are failing. Bernhard -- /* [EMAIL PROTECTED] */
[perl #38235] [TODO] Rename (dyn)?classes to (dyn)?pmc
> [jonathan - Sa 14. Jan 2006, 09:57:37]: > > I propose to rename 'src/classes' to 'src/pmc' as IMHO it makes > > more sene. 't/pmc' is already named 'pmc'. > > > Yes, and for consistency please also rename dynclasses to dynpmc and the > t/dynclass to t/dynpmc. The first step, renaming 'src/dynclasses' to 'src/dynpmc' is done. Please do a 'svn up' and 'perl Configure.pl'. The second step. renaming 'src/classes' to 'src/pmc' should follow tomorrow. Mit freundlichen Grüßen, Bernhard -- /* [EMAIL PROTECTED] */
[perl #31646] [TODO] Compile/eval/whatever system a bit of a muddle
> We need to clean up the docs and pmcs for compilation, dynamic > compiler modules, and the associated pmcs (eval, compiler, and so on). The muddle has been somewhat cleaned up. For example the PMCs returned by compreg and from the compilers can now simply be invoked. Are further actions needed? I think the examples and documentation still need some loving care. -- /* [EMAIL PROTECTED] */
[perl #37357] [TODO] Check and split up 'examples/assembly'
> [bernhard - Mi 05. Okt 2005, 12:05:35]: The dir 'examples/assembly' is gone in r10185. The examples it formerly contained are either deleted or moved to 'library', 'pir' or 'pasm'. Most of the moved examples are tested by t/examples/*.t. Some broken examples, or not easily testable examples, have only a failing TODO test. -- /* [EMAIL PROTECTED] */
[perl #37358] [TODO] Tests - cleanup use of temp files
> [EMAIL PROTECTED] - Mi 05. Okt 2005, 14:34:17]: > > Many of the tests write temp files into the current working dir. Even > worse, some of these files many not get cleaned up if the tests exit > prematurely. Tests should be converted to use File::Temp where ever > possible. Personally I don't mind much files leftover from the test suite. When there are failing tests, it's nice to have the input around. However they shouldn't clutter the 'parrot' directory. How about adding a Parrot::Test::get_temp_dir() that gives a path to a sandbox directory, that can safely be cleaned up? Later Parrot::Test::get_temp_dir() could be taught about things like cross compilation and read-only source directories. CU, Bernhard -- /* [EMAIL PROTECTED] */
[perl #37563] [BUG] Parrot m4 has problems with PGE
> [bernhard - So 30. Okt 2005, 04:35:45]: > > Hi, > > it looks like recent PGE changes broke 'Parrot m4'. > I have boiled it down to a 20 line test cast and added it > as test 4 in t/library/pge.t. This test case fails, at least under my > Linux installation, with a segmentation fault. > > My setup: > > [EMAIL PROTECTED]:~/devel/Parrot/local/parrot> uname -a > Linux linux 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown > [EMAIL PROTECTED]:~/devel/Parrot/local/parrot> gcc --version > gcc (GCC) 3.4.2 > > CU, Bernhard I have trace the failure t/library/pge_4.pir with valgrind. It looks like p->pmc_ext ends up with a value of 0x5 in src/dod.c. This looks not healthy to me. More about that once I have 'gdb' and 'ddd' running on my friends machine. CU, Bernhard Process terminating with default action of signal 11 (SIGSEGV) ==4409== Access not within mapped region at address 0x5 ==4409==at 0x80CB662: pobject_lives (src/dod.c:223) ==4409==by 0x808D5FB: mark_stack (src/stacks.c:72) ==4409==by 0x8163263: mark_context (src/sub.c:41) ==4409==by 0x80CB90A: Parrot_dod_trace_root (src/dod.c:365) ==4409==by 0x80CB9B0: trace_active_PMCs (src/dod.c:390) ==4409==by 0x80CC496: Parrot_dod_ms_run (src/dod.c:1236) ==4409==by 0x80CC566: Parrot_do_dod_run (src/dod.c:1275) ==4409==by 0x80CA07D: more_traceable_objects (src/smallobject.c:114) ==4409==by 0x80CA0FF: gc_ms_get_free_object (src/smallobject.c:162) ==4409==by 0x808DC7A: cst_new_stack_chunk (src/stack_common.c:92) ==4409==by 0x808DCE8: stack_prepare_push (src/stack_common.c:117) ==4409==by 0x808D960: stack_push (src/stacks.c:253) -- /* [EMAIL PROTECTED] */
[perl #37455] make hello fails
> [leo - So 23. Okt 2005, 12:25:29]: > > As Parrot_setup_args() is so far only used for passing 'output' to the > > exec runcore, I propose a quick fix. > > > > i. Do not use STRING register for passing options > > ii. Move interp->imc_info->output to interp->output_file and use > > interp->output_file for all uses of the 'output' option. > > or use interp->current_file (or rename that) - this is already marked > during DOD and otherwise unused. A global current_file doesn't make any > sense. The info is also covered by the debug PBC segment. In r9546 I have removed interp->imc_info->output, interp->current_file and usage of REG_STR(0). The output info in now in interp->output_file. Currently this is a plain 'const char *', but I could switch it to a 'STRING *'. So 'make hello' now creates 'examples/pasm/hello'. But execution still give a segfault. CU, Bernhard -- /* [EMAIL PROTECTED] */
[perl #37455] make hello fails
> [bernhard - Do 20. Okt 2005, 13:35:43]: > > When running 'make test' the command > >./parrot -o examples/pasm/hello.o examples/pasm/hello.pbc > > fails to create examples/pasm/hello.o. Instead a file with the name > 'exex_output.o' is generated. It looks like the name of the output file > is expected to be in REG_STR(0), but isn't. So the default file > 'exec_output.o' is used. Sell line 116 of src/exec.c. Hi, I've traced this some more. It looks like the 'output' is stored in the '0' STRING register of the initial interpreter context. This is done be calling 'Parrot_setup_opt()'. However when this information is needed, I assume the register has been cleared or stored in a not current context. I've traced this only to the first VTABLE_invoke call of runops_args() in src/inter_runs.c,line 157. Using registers for passing command line options to a specific runcore seem hazardous to me. Especially as a 'char *' is put where a 'STRING *' is expected. As Parrot_setup_args() is so far only used for passing 'output' to the exec runcore, I propose a quick fix. i. Do not use STRING register for passing options ii. Move interp->imc_info->output to interp->output_file and use interp->output_file for all uses of the 'output' option. Any comments? > Whem copying 'exec_output.o' to 'examples/pasm/hello.o' manually, then > 'make test' produces 'examples/pasm/hello'. However when trying to > execute that executable, I get a segmentation fault. I have no idea about this. CU, Bernhard -- /* [EMAIL PROTECTED] */
[perl #37455] make hello fails
> [EMAIL PROTECTED] - Di 18. Okt 2005, 02:51:18]: > > This bug is a regression, 'make hello' works with release 0.3.0 > (r9297). Just some observations. When running 'make test' the command ./parrot -o examples/pasm/hello.o examples/pasm/hello.pbc fails to create examples/pasm/hello.o. Instead a file with the name 'exex_output.o' is generated. It looks like the name of the output file is expected to be in REG_STR(0), but isn't. So the default file 'exec_output.o' is used. Sell line 116 of src/exec.c. Whem copying 'exec_output.o' to 'examples/pasm/hello.o' manually, then 'make test' produces 'examples/pasm/hello'. However when trying to execute that executable, I get a segmentation fault. CU, Bernhard -- /* [EMAIL PROTECTED] */
[perl #34258] [TODO] Here documents for PIR
> [jonathan - Di 04. Okt 2005, 15:03:03]: > > After a show of demand for here docs on IRC (and leo's approval), I've > now modified to lexer to support them. The syntax for introducing a > heredoc is <<"XXX", and it ends on the line containing (only) XXX. For > example:- > Thanks a lot Jonathan. Here docs are alive and kicking. The ticket is resolved.
[perl #37160] [PATCH] Make it easier to use a different compiler
> [doughera - Di 13. Sep 2005, 10:05:04]: > > This patch makes it easier to compile parrot with a compiler other > than > the one used to compile perl5. It re-arranges the order in which > various > defaults are set so that the user may override them either with hints > files or interactively, via ask. (For example, it used to be > impossible > to set optimize and cc_shared.) I have submittes this patch. I have only tried it under Linux, Andy has run it under Solaris and Linux. Please holler, when there are problems. CU, Bernhard
[perl #30631] [PATCH] Iterator support for Env PMC
> Matt Kennedy <[EMAIL PROTECTED]> wrote: > > > The attached env.patch patches classes/env.pmc to add vtable methods > > elements() and get_iter() and modifies get_string_keyed() to also > > accept integer keys so that it is possible to use an Iterator on the > > environment. I have applied this patch and added implementation and tests for 'get_integer' and 'get_number'. > > ... The patch uses the char **environ variable The usage of 'char **environ' is only a little problematic. It seems to be speced in POSIX.1, but not in ISO-C. In http://search.cpan.org/~stas/Env-C-0.06/ there is only an include switch for _BORLANDC. It might be a good idea to provide wrappers in 'platform.c' for all functions accession 'environ'. The 'unsetenv'-problem, ticket 23025, is another issure related to 'environ'. -- /* [EMAIL PROTECTED] */
[perl #23025] [PATCH] Implement and test 'unsetenv' on all platforms
> [lbr - Fr 08. Aug 2003, 08:45:43]: > > We'll postpone deciding on this one until later - I've attached a > patch to env.t that tests the env-implementation on all platforms, and > doesn't fail on Solaris. I'd like to reopen this ticket, as the issue isn't really resolved. There is still a skipped test for platforms without an native 'unsetenv'. Maybe the resulution is that the effects of deleting entries in %ENV will be platform dependent. CU, Bernhard -- /* [EMAIL PROTECTED] */
[perl #31980] Factorial example gives incorrect result
> [EMAIL PROTECTED] - Di 19. Okt 2004, 19:49:44]: > Is it the intended operation of the 'factorial' program on the Parrot > examples page to > truncate the results? Looks like a bug to me... I have checked the factorial example on http://www.parrotcode.org/examples/pasm.html. Starting with 13! incorrect results are indeed returned on my 32bit Linux machine. Should there a promotion to BigInt be taking place? on an overflow indication? -- /* [EMAIL PROTECTED] */
[perl #37068] [TODO] repair JAPHs in 'examples/japh'
> [jonathan - Mi 07. Sep 2005, 15:41:58]: > > > I see some updates to the examples, so guess somebody is having a hack > at this task. FYI, current test status on Win32:- Actually I haven't looked at the code at all. All I did was to add $Id$ tags for SVN. CU, Bernhard -- /* [EMAIL PROTECTED] */
[perl #37100] [PATCH] Pod tests + fixes
> [EMAIL PROTECTED] - Mi 07. Sep 2005, 14:29:39]: > > This patch adds a new test, t/docs/pod.t, that scans through the parrot > tree and checks the Pod syntax of all files identified by Pod::Find as > containing Pod markup. This is invoked by a new test target named > "doc_tests" which has been added to the "fulltest" target. This patch > also fixes all of the syntax errors currently found by the new test. Hi, I have applied the POD syntax fixes of this patch. 't/doc/pod.t' also make a lot of sense. However could you comment on the relation to t/perl/Parrot_Docs.t ? It looks like it checks the same things as 'pod.t'. I wonder whether it is worthwile to maintain Parrot::Docs, when the needed functionality is already at CPAN. CU, Bernhard > MANIFEST |1 + > charset/gen_tables.pl |4 > config/gen/makefiles/root.in |7 ++- > docs/pdds/pdd04_datatypes.pod |4 > docs/pdds/pdd09_gc.pod|4 ++-- > lib/Test/More.pm |3 +++ > ops/pic.ops |4 ++-- > t/doc/pod.t | 29 + > 8 files changed, 47 insertions(+), 9 deletions(-) > > -- /* [EMAIL PROTECTED] */
[perl #37082] [BUG] Parrot HEAD failing on MacOS Tiger
> Bernhard Schmalhofer via RT wrote: > >>Test 5 of t/examples/japh.t is failing on MacOS Tiger. > > > > > > Hi, > > > > I have played with the timing of the two threads in that test case. > > Could you update to revision 9142 or later and check whether it now works? > [ambs - Di 06. Sep 2005, 00:04:22]: > > r9142 and we are with the same problem. > Too bad. As I reached the end of intuitive bug fixing, I am now skipping 'examples/japh/japh13.pasm' in 't/examples/japh.t'. Perhaps some MacOS X user can provide more insight. CU, Bernhard -- /* [EMAIL PROTECTED] */
[perl #37067] [PATCH] intro.pod - minor corrections
> > This patch fixes a few typos, 81 char lines, and makes a couple of other > > exceedingly minor tweaks. Thanks applied in r9136. > I should have added that this patch does s/behaviour/behavior/g. Which > brings up the issue of: which "English" are we using for docs? That would be a question for Chip, or do we have a 'docs' pumkin? CU, Bernhard -- /* [EMAIL PROTECTED] */
[perl #37049] [PATCH] Use ExtUtils::Commands more consistently
> ExtUtils::Command provides Unix commands on several platforms. > So it make sense to use ExtUtils::Command per default and not only for > Win32. This is now applied in r9128. Please tell me about aventual problems. CU, Bernhard -- /* [EMAIL PROTECTED] */
[perl #36862] [PATCH] m4 tests compatible with Win32
> [EMAIL PROTECTED] - Do 11. Aug 2005, 05:28:37]: > > > *nix utilities are not available on Win32. > But Perl allows to write portable test. > Merci, applied. I'm wondering why we don't use ExtUtils::Commands by default for all of the Parrot Makefiles and config tests. -- /* [EMAIL PROTECTED] */
[perl #29836] [PATCH] No need to skip some tests on Cygwin
> All extend and thread tests have passed for me on trunk with normal > build. timer seems to pass outside the harness, but isn't happy inside > it. Signal seems to have a 'Signal 1' message in the output which breaks > the test. > > I'm just going to repeat this to double check things. I'll add any > updates if there are any. > > [Also trans has the problem with one of the trig tests (which has been > mentioned a few times!), and dynclasses don't build yet] On p6i Nick reported success for the timer and signal tests on an updated Cygwin. For the failing trig test there is now ticket [perl #36835] and for the dynclasses problem there is not [perl #36836]. Thus this ticket can be resolved. Nick: Could you check the cygwin information in PLATFORMS? If you send a patch, I'll apply it. -- /* [EMAIL PROTECTED] */
[perl #29836] [PATCH] No need to skip some tests on Cygwin
Hi, I have applied a couple of old patches from Limbic~Region. These patches are enabling some tests for cygwin. Unfortunately I have no cygwin installed, so I can't tell whether the enabled tests are passing. But I think that right after a release is a good time for breaking things. Could one of the Cygwin users tell whether everything is OK? > extend 12 previously hung on Cygwin: If configured > with --intval=long and --opcode=long this is not the > case This might still be problematic. > threads were all being skipped on Cygwin: They all > pass except the 2 that are being universally skipped The threads tests were already enabled for cygwin. > timer were all being skipped on Cygwin: They all pass Timer tests are now enabled -- /* [EMAIL PROTECTED] */
[perl #36778] [PATCH] gdbmhash with MinGW32
> [EMAIL PROTECTED] - Mi 03. Aug 2005, 00:40:59]: > > With this small patch, gdbmhash works on MinGW. > Thanks, the patch is applied, and thinks look OK under Linux as well. Do you have an explaination why config/auto/gdbm.pl seems to see a gdbm library. I don't see 'gdbm3' mentioned there. Is the linker in MinGW smarter than Parrot_load_lib() ? CU, Bernhard -- /* [EMAIL PROTECTED] */
[perl #35824] [TODO] Remove .cvsignore files
> [bernhard - Mo 16. Mai. 2005, 02:42:49]: > > > i. Migrate the changes in .cvsignore file into the svn:ignore property > Done. > > ii. Tell manicheck.pl to query the SVN properties t/src/manifest.t verifies that MANIFEST.SKIP is consistent with the svn:ignore properties. This make manicheck.pl real simple. TODO: Remove uninteresting STDERR > > iii. remove the .cvsignore files done -- /* [EMAIL PROTECTED] */
[perl #35412] [PATCH] remove io_win32.c warning
> this simple patch removes a build warning in io\io_win32.c: > io\io_win32.c(272) : warning C4550: expression evaluates to a function > which is missing an argument list The patch is applied. This warning surfaces only because I had inadvertedly enabled PARROT_NET_DEVEL in io/io_private.h in SVN revision 7974. Luckily no major harm seemed to have done by that. The good thing is that the tiny webserver './parrot exambles/io/httpd.imc' should work now out of the box. Thanks to Robert Spiers with a neat Parrot as favicon. CU, Bernhard CU, Bernhard
[perl #34121] [NEW] imc http server
> [leo - Mo 14. Feb 2005, 02:59:47]:
>
> Markus Amslser <[EMAIL PROTECTED]> wrote:
> > Now it's getting funny. I have written a tiny webserver in imc, that can
> > serve the parrot html documentation.
>
> Great, thanks. Some remarks:
> - served line endings should by "\r\n": lynx doesn't work with "\n" only
This has already been fixed
> - reading html files should used the C opcode to determine the
> file size
TODO
> While at socket IO:
>
> - all the current socket opcodes should be available as ParrotIO methods,
> e.g.
>
> METHOD PMC* socket(...) {...}
> METHOD INTVAL bind(STRING *address) {...}
>
> so that:
>
> pio = getclass "ParrotIO"
> sock = pio."socket"(.PIO_SOCK_FAM_PF_INET, \
> .PIO_SOCK_TYPE_SOCK_STREAM, \
> .PIO_SOCK_PROTO_IP)
>
> res = sock."bind"(address)
>
> works.
TODO
> - patches welcome to allow constants for the C opcode's "magic
> numbers". See: config/gen/parrot_include.pl and the &gen_from_*
> directives.
> The enums should be attached to the C method.
TODO
Propably due to recent charset changes, I found that httpd.imc was no
longer working under Linux. The op 'recv' seems to return a 'binary'
string. However for 'binary' the 'index' op is not implemented, thus
httpd.imc can't check for "\r\n\r\n".
I don't know how to transcode a 'binary' to 'ascii'. Therefore
I made a dirty hack, telling PIO_unix_recv to return an 'ascii' string.
--
/* [EMAIL PROTECTED] */
[perl #34999] [TODO] remove more old stuff
> > Some outdated files: > > > >lib/Parrot/PackFile/* > >lib/Parrot/PackFile.pm > >lib/Parrot/PackFile2.* > > > > what is: > > > >lib/Parrot/String.pm old packfile code? > >lib/Parrot/Types.pm same? > >lib/Parrot/Key.pm same? > > All the above files appear to be remnants of disassemble.pl. These are now gone > > Do we still need: > > > >lib/Parrot/PMC.pm > Yes. This is an autogenerated file used both for the PMC compiler and > for testing purposes. Alive and kicking. > >lib/Parrot/Makefile.PL > > This is the Makefile for lib/Parrot/Pakfile2.pm (and > lib/Parrot/Pakfile2.xs), which is not referenced anywhere Gone. > > and what about the > > > >chartypes > > > > directory, seems to be created in lib/Parrot/Distribution.pm > > This appears to be a remnant of the long distant past (pre ICU). > There's only one file that mentions it outside of > lib/Parrot/Distribution.pm, No longer mentioned in Distribution.pm. > >classes/pmc2c.pl old PMC compiler > > Already removed. > > >classes/pmcarray.pmc wrapper for PerlArray Was already removed. As everything seems to be taken care of, I'll close this ticket. -- /* [EMAIL PROTECTED] */
[perl #34548] [TODO] Replace classes/pmc2c.pl with classes/pmc2c2.pl
> > >> Either pmc2c.pl should be deleted or pmc2c2.pl should be renamed to > > >> pmc2c.pl. > > > > > A better location might be 'build_tools/pmc2c.pl > > > Attached is a patch that does just that, including appropriate > documentation changes. Note that these changes involved using 'svn rm' > and 'svn mv'. Hopefully the patch DWIW and moves/removes the files. Applied the patch. with some fiddling. Matt: Could you check whether all changes are in? -- /* [EMAIL PROTECTED] */
[perl #34548] [TODO] Replace classes/pmc2c.pl with classes/pmc2c2.pl
> [mdiep - Di 22. MÃr 2005, 14:35:02]: > > pmc2c2.pl is the new pmc2c.pl. Both currently exist in Parrot CVS. > Either pmc2c.pl should be deleted or pmc2c2.pl should be renamed to > pmc2c.pl. A better location might be 'build_tools/pmc2c.pl*, as the script is also used in 'dynclasses/build.pl'. It propably will also be used for for their language specific PMCs in 'languages/'. Should we wait for that, until it is decided whether we will switch to SVN? I think that SVN preserves change history for moved files. -- /* [EMAIL PROTECTED] */
[perl #33995] [BUG] Configure warning on gdbmhash
> The recent gdbmhash configure check causes the following output on my > system during the build. I have changed dynclasses.in to use the CONDITIONED_LINE hack. So there is no longer a need to access a potentially undefined config value. A patch is attached. > runtime/parrot/include.done. > Generating build files..value for 'gdbmhash' in > config/gen/makefiles/dynclasses.in is undef at > lib/Parrot/Configure/Step.pm line 230, line 11. > ..done. > Moving platform files into > place..done. -- /* [EMAIL PROTECTED] */ rt33995_20050131.patch Description: Binary data
[perl #33662] [PATCH] Rename libnci.so to libnci_test.so
> the library 'libnci.so' is used for testing the Native Call Interface, not > for implementing NCI. So the name 'libnci_test.so' make more sense. > > For Win32 I have moved 'libnci.def' for > 'runtime/parrot/dynext/libnci_test.def'. However > I could not test wether this works. I've just noticed that ticket 27305 proposes to move libnci.def into 'src/'. This makes sense to me, so I have changed the patch accordingly. > The file 'libnci.def' can be removed from CVS. -- /* [EMAIL PROTECTED] */ libnci_test_20050107.patch Description: Binary data
[perl #31859] Re: Plain ole Hash
> > The attached patch makes the Hash PMC use basic PMCs by default. Sorry again, one shouldn't send any patches after midnight. First I forgot to clean up cruft from hash_pmc_20041218.patch. Then, trying to send the corrected patch, I misspelled the name of the mailing list. So, please note that a patch for the Hash PMC, hash_pmc_20041218_cleaned.patch, is lying at http://rt.perl.org/rt3/index.html?q=31859. CU, Bernhard -- /* [EMAIL PROTECTED] */
