Re: odbc.lib still linked?
Klaas-Jan Stol wrote: recently a patch was supplied and applied for odbc32.lib being linked into parrot. This file is not needed for Parrot, but it seems it is still linked (at least, here on my machine, winxp). \parrot\library\PAST-pm.pbc C:\Perl\bin\perl.exe -e chdir shift @ARGV;system 'nmake', '-nologo', @A RGV; exit $? 8; compilers\json link -out:.\pbc_merge.exe src\pbc_merge.obj src\parrot_config.obj lib parrot.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.libcomdlg32 .lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.libws2_3 2.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib -nologo -nodefaultlib -debug -machine:x86 -debug Check the second last line... Should it be there? From your command line you seem to refer to Visual C++, but patch 42950 looks like it's intended for MinGW. For Visual C++ the libraries are pulled in from your Perl (see perl -V:libs). Ron
*.dev = docs/dev/*.pod ??
Hi all, I've been reading through some of the pdd's and have noticed mention of *.dev files for actual implementation of features. I'm fairly sure these are actually the pod files under docs/dev, but I just wanted to make sure of this before I make the pdd's point to the files in this directory instead of the *.dev files. Thanks! Paul
Re: odbc.lib still linked?
I sent this message a few days ago, but hasn't reached the list I think: hi, I experimented on windows with removing some libs that seemed unnecessary, and I ended with this line in my Makefile; C_LIBS = kernel32.lib ws2_32.lib msvcrt.lib which is rather shorter than: C_LIBS = oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib Particle mentioned that this information (what libs to link) is probably coming from Perl's config. I'm sending this as a TODO, so this information won't get lost. best, kjs On 5/20/07, Ron Blaschke [EMAIL PROTECTED] wrote: Klaas-Jan Stol wrote: recently a patch was supplied and applied for odbc32.lib being linked into parrot. This file is not needed for Parrot, but it seems it is still linked (at least, here on my machine, winxp). \parrot\library\PAST-pm.pbc C:\Perl\bin\perl.exe -e chdir shift @ARGV;system 'nmake', '-nologo', @A RGV; exit $? 8; compilers\json link -out:.\pbc_merge.exe src\pbc_merge.obj src\parrot_config.obj lib parrot.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.libcomdlg32 .lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.libws2_3 2.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib -nologo -nodefaultlib -debug -machine:x86 -debug Check the second last line... Should it be there? From your command line you seem to refer to Visual C++, but patch 42950 looks like it's intended for MinGW. For Visual C++ the libraries are pulled in from your Perl (see perl -V:libs). Ron
[perl #43005] [TODO] Update t/README
# New Ticket Created by James Keenan # Please include the string: [perl #43005] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43005 t/README does not appear to have been substantively updated since at least March 2006. In particular, there are several new subdirectories of tests under t/ whose purposes have not yet been documented in t/README. These subdirectories are: 'dynoplibs', 'oo', 'pdd15oo', 'postconfigure', 'stm' Since I created the postconfigure/ subdirectory, I'll start by writing a patch describing what the tests in that directory are for. If you worked on one of the other 4 undocumented subdirectories, please submit a patch as well. Thank you very much. kid51
[perl #43004] [TODO] Update t/TESTS.STATUS.pod
# New Ticket Created by James Keenan # Please include the string: [perl #43004] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43004 t/TESTS.STATUS.pod does not appear to have been substantively updated since March 2006. I know that the work I've been doing since last November on tests under t/configure/ and t/tools/ means that the evaluation in that doc of the state of our progress in those areas should be revised. Whether it moves us from poor to fair or even good is not immediately evident. I suspect that we need to re-evaluate our progress in other areas as well. Could we begin by having people take a look at this doc and comment on where we are with respect to testing? Thank you very much. kid51
[perl #43005] [TODO] Update t/README
On Sun May 20 08:08:13 2007, jkeen !-- x -- at verizon.net wrote: Since I created the postconfigure/ subdirectory, I'll start by writing a patch describing what the tests in that directory are for. If you worked on one of the other 4 undocumented subdirectories, please submit a patch as well. See patch attached. Index: t/README === --- t/README(revision 18590) +++ t/README(working copy) @@ -5,36 +5,39 @@ For details, see the documentation in '../docs/tests.pod'. For status of the testing effort, see 'TESTS.STATUS.pod' in this directory. -benchmark:Run all benchmarks +benchmark: Run all benchmarks -compilers:Mini languages distributed with Parrot +compilers: Mini languages distributed with Parrot -configure:Perl modules of configuration subsystem +configure: Perl modules of configuration subsystem -codingstd:Conventions and Guidelines for Parrot Source Code +codingstd: Conventions and Guidelines for Parrot Source Code -distro: Tests run before a distro is released +distro: Tests run before a distro is released -doc: Completeness and sanity of the documentation +doc:Completeness and sanity of the documentation -dynpmc: Dynamic PMCs +dynpmc: Dynamic PMCs -examples: Check whether the examples are still working +examples: Check whether the examples are still working -library: Parrot modules +library:Parrot modules -native_pbc: Parrot Byte Code +native_pbc: Parrot Byte Code -op: Try to cover all core operators +op: Try to cover all core operators -perl: Test Perl5 modules used for configuration, building and testing of Parrot. +perl: Test Perl5 modules used for configuration, building and testing of Parrot. -pmc: Try to cover all builtin PMCs +pmc:Try to cover all builtin PMCs -run: Mostly command line options of the 'parrot' executable +postconfigure: Tests of configuration system which cannot be run until +configuration has completed. -src: Tests written in C. XXX Is this a meaningful category? +run:Mostly command line options of the 'parrot' executable -stress: Stress testing +src:Tests written in C. XXX Is this a meaningful category? -tools:Executables besides 'parrot' +stress: Stress testing + +tools: Executables besides 'parrot'
Re: [perl #43006] Tail call force-frees current context
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bram Geron wrote:
The patch in parrot.solution1.patch fixes the problem for me.
I realized that contexts currently initially have a ref_count of 0, if
they're not used as :outer targets for other subs. So in 'normal'
situations, the caller's context's ref_count now drops from 0 to -1 in a
tail call, and since -1 != 0 the caller's context will never be freed,
resulting in a memory leak. Attached parrot.solution1.updated.patch
should fix that.
Still, I'm left with a question. How can we DOD a closure? To me it
seems that once a closure exists, it references its context. Often the
context is still left in a register, so the context references the
closure PMC, which in turn references the closure. Because we use
reference counting in these cases, no count ever drops to zero, and they
all live forever.
Sorry for the extra disturbance, thanks for looking at my mail,
- --
Bram Geron | GPG 0xE7B9E65E
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGUKbOvquQbee55l4RAp5wAJ0czwrfQc5Ta/xtMn7FqhSeptq/awCfbNg2
FxMZOHymYqUQCNoyK54pBmo=
=bjro
-END PGP SIGNATURE-
Index: src/pmc/sub.pmc
===
--- src/pmc/sub.pmc (revision 18597)
+++ src/pmc/sub.pmc (working copy)
@@ -284,8 +284,9 @@
if (PObj_get_FLAGS(SELF) SUB_FLAG_IS_OUTER) {
/* don't destroy context */
ccont-vtable = interp-vtables[enum_class_Continuation];
-context-ref_count++;
}
+/* reference counting should work */
+context-ref_count++;
if (!PMC_IS_NULL(INTERP-current_object)) {
context-current_object = INTERP-current_object;
@@ -322,7 +323,7 @@
PObj_get_FLAGS(ccont) = ~SUB_FLAG_TAILCALL;
context-caller_ctx= caller_ctx-caller_ctx;
-Parrot_free_context(INTERP, caller_ctx, 1);
+Parrot_free_context(INTERP, caller_ctx, 0);
}
}
Re: [perl #43006] Tail call force-frees current context
Am Sonntag, 20. Mai 2007 21:51 schrieb Bram Geron: Bram Geron wrote: The patch in parrot.solution1.patch fixes the problem for me. I realized that contexts currently initially have a ref_count of 0, if they're not used as :outer targets for other subs. So in 'normal' situations, the caller's context's ref_count now drops from 0 to -1 in a tail call, and since -1 != 0 the caller's context will never be freed, resulting in a memory leak. Attached parrot.solution1.updated.patch should fix that. It's likely simpler to start all context refcounts equally with 1. This would probably reduce the current special refcount handling. But it would need some changes, which is easily greppable I presume. Still, I'm left with a question. How can we DOD a closure? To me it seems that once a closure exists, it references its context. Often the context is still left in a register, so the context references the closure PMC, which in turn references the closure. Because we use reference counting in these cases, no count ever drops to zero, and they all live forever. Think of (closure) contexts, which were created in eval-ed code. When the outer context ceases to exist, the inner context can be collected. All other closure context is of course persistent. leo
[perl #43007] [PATCH] docs/configure/files.pod contributed in 'reconfigure' branch
# New Ticket Created by James Keenan # Please include the string: [perl #43007] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43007 In the 'reconfigure/' branch, I contributed a new file, docs/ configure/files.pod, in r18602. Please find a copy attached. In April, I wrote on the mailing list: So, can someone draw a roadmap of: -- *which parts* of Parrot's configuration and build tools *need* to be replaced with something else; -- *why* that replacement is necessary; -- *when* in the design process that replacement must take place; and -- *how* that replacement will be maintained going forward from there? On April 26, Allison Randal responded (http://tinyurl.com/3d48fh): The biggest thing we need to start this roadmap is documentation on the current configuration and build system. The current requirements and process for building Parrot are the starting point for all future refinements to the build system. You're in a better position to draft that than anyone else in the project right now. Interested? Whether I actually am in that position is doubtful. In any event, I figured that a good way to start would be to simply list the files that are created during configuration, then ask people to write short descriptions of their purpose/functions. Since the files that are created depend on the options with which you run Configure.pl, there can be no one, definitive list of those files. So I wrote what is intended to be the first draft of a non- authoritative document, one which is supplementary to docs/ configuration.pod. Since the name of this file, what directory it should go in, and what it should contain are all up for discussion, I decided not to commit this directly to trunk. However, since we can develop in branches where appopriate, I did commit this to the 'reconfigure' branch. If you think this file is worthwhile -- and particularly if you can add brief explanations of the purpose of the files created during configuration -- please edit in this branch. Then we'll decided whether it should go into trunk and, if so, where. Thank you very much. kid51 files.pod Description: Binary data
[perl #43008] [PATCH] docs/tests.pod: Expand discussion of testing of Perl 5 components of Parrot
# New Ticket Created by James Keenan # Please include the string: [perl #43008] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43008 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. kid51 tests.pod Description: Binary data
.perl, nested arrays, parens and a bug with .perl after hyperop
Hi!
Yesterday we discussed a strange behaviour of .perl on the result of a
hyperoperator. The basic bug is that
my @hyp = -« ([1, 2], 3);
say @hyp.perl;
outputs
[(-1, -2), -3]
which are strange inner parens inside the brackets that would get
flattened after eval. I committed a :todo test for this in
t/builtins/{perl,perl2}.t.
Some questions arose during the discussion:
1. Should assigning an arrayref to an array dereference? Eg., so that
@foo = [[1, 2], 3]
is basically the same as
@foo = ([1, 2], 3)
Currently the first assignment generates a list whose first element
is the complete array reference:
[[[1, 2], 3],]
which isn't maybe the expected behaviour. Or is it? Which Synopses
describes this?
2. Shouldn't .perl generally use parens for outputting arrays (at
least on the most outer level)? Because currently eval'ing the
output contains the problem from question 1.
3. Which test file is the real one:
pugs/t/builtins/perl.t
or
pugs/t/builtins/perl2.t ?
They are similar but not identical.
(Greeti+Tha)nX
Steffen
--
Steffen Schwigon http://renormalist.net
Dresden Perl Mongers http://dresden-pm.org/
Deutscher Perl-Workshop http://www.perl-workshop.de/
Re: .perl, nested arrays, parens and a bug with .perl after hyperop
Steffen Schwigon skribis 2007-05-21 1:28 (+0200): 1. Should assigning an arrayref to an array dereference? No, an array in list context only flattens when it has the @ sigil, or when it is explicitly flattened with the [] postcircumfix operator, or the | prefix operator. Which Synopses describes this? S03 2. Shouldn't .perl generally use parens for outputting arrays (at least on the most outer level)? No, because parens are just for grouping and controlling precedence. They are not constructors. Note that in this assignment, my @foo = @bar; @bar is in list context. The syntax is ARRAY = LIST; and not ARRAY = ARRAY. Assigning an array to an array seems kind of useless to me. Binding probably makes a bit more sense: my @foo := @bar; That's ARRAY := ARRAY there, so the following should dwym: my @foo := [ 1, 2, 3 ]; However, this does not work with pugs, so I don't know if I am wrong, or pugs is wrong. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
