Re: ANNOUNCE - Smolder 0.01
On Sat, Mar 04, 2006 at 09:09:00 -0500, Michael Peters wrote: > It's very similar in nature to the Pugs smoke test server, but is completely > project agnostic. It's also completely self contained (contains local copies > all > of it's Perl modules and a local apache/mod_perl). It's released in binary > packages (currently there's only 1 binary package, but more will hopefully be > coming) and also a source distribution from which you can build a binary > package. All it requires is an existing version of Perl 5.8.x (might work with > 5.6.x but that hasn't been tested) and MySQL 4.x. Could you please please please pretty please with a cherry on top add SQLite support? Another, much more pretentious request is that you refactor anything and everything you can into generic modules and put them on the CPAN. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me dodges cabbages like macalypse log N: neeyah! pgpb3Ys8tDric.pgp Description: PGP signature
Re: Perl 6 design wiki?
* Stevan Little ([EMAIL PROTECTED]) [060305 02:49]: > On 3/4/06, Mark Overmeer <[EMAIL PROTECTED]> wrote: > > Could we try to kind-of pre-register name-spaces for perl6 modules? > There is no need to do such a thing, we have the 3 level naming scheme > in Perl 6 now. > Foo-0.0.1-cpan:JRANDOM I know about the naming scheme, but I am not really looking forward to the two new perl books "Perl DBI-(Any)-cpan:TIMB" and "Perl DBI-(Any)-mailto:[EMAIL PROTECTED]" That you have the possibility to work your way out in namespace clashes shouldn't directly mean that you let them happen easily. I would really like to maintain a certain hierarchical name-space structure on CPAN, where we strive for unique names, although can work around accidental collissions. An other reason to have a kind of module/namespace pre-registration is to see who is (planning to go) working on what. I think that's needed on the moment. -- MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Re: Perl 6 design wiki?
Mark Overmeer skribis 2006-03-05 10:44 (+0100): > I know about the naming scheme, but I am not really looking forward > to the two new perl books "Perl DBI-(Any)-cpan:TIMB" > and "Perl DBI-(Any)-mailto:[EMAIL PROTECTED]" I think that's a very good argument for managing namespace centrally (but not necessarily against using this scheme). > I would really like to maintain a certain hierarchical name-space > structure on CPAN, where we strive for unique names, although can work > around accidental collissions. In principle I agree, but to be honest, hierarchical names make less and less sense by the day, as techniques are combined, and new many new things overlap much. Often it is hard to choose between top level namespaces, or to choose which part of your module name you put first. And once you settle on a name, it's even quite likely that although it describes the way you intended the module to be used, it doesn't cover all the bases. See DBIx::XHTML_Table and Apache::Session, that have nothing to do with DBI and Apache, respectively. More and more, I like cute names that don't really describe the module. We have abstracts for the latter. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6 design wiki?
On 3/5/06, Mark Overmeer <[EMAIL PROTECTED]> wrote: > * Stevan Little ([EMAIL PROTECTED]) [060305 02:49]: > > On 3/4/06, Mark Overmeer <[EMAIL PROTECTED]> wrote: > > > Could we try to kind-of pre-register name-spaces for perl6 modules? > > > There is no need to do such a thing, we have the 3 level naming scheme > > in Perl 6 now. > > Foo-0.0.1-cpan:JRANDOM > > I know about the naming scheme, but I am not really looking forward > to the two new perl books "Perl DBI-(Any)-cpan:TIMB" > and "Perl DBI-(Any)-mailto:[EMAIL PROTECTED]" > > That you have the possibility to work your way out in namespace clashes > shouldn't directly mean that you let them happen easily. I would really > like to maintain a certain hierarchical name-space structure on CPAN, where > we strive for unique names, although can work around accidental collissions. I agree completely, and to be honest, I think the three level namespace will be more useful in the context of a single company and/or application, and be used more for versioning that anything else. > An other reason to have a kind of module/namespace pre-registration is to > see who is (planning to go) working on what. I think that's needed on the > moment. Well, to start with, there is no C6PAN/SixPan/Whatever-it-will-be-called yet, so there is nothing to pre-register for. Second, Perl 6 is still (at the very least) a year away from a (mostly) complete implementation, and that most likely will not be the "official" one, and only a reference implementation that very few people (read: audrey) will actually use in production. The official version with Parrot and Ponie and few enough bugs to call 6.0.0 is maybe a few years out from that. So pre-registration for namespaces in an unfinished language is a litte premature IMO. And lastly, I really don't like the idea anyway. It reminds me of the domain-name squatters of the mid-90s. Just because I (with my best intentions intact) decide that I want to write World::Domination::Simple in 2006, does not mean that someone else in 2008+ should have to come up with another name because I registered for the namespace I never used (and am unwilling to give up). In addition, while I agree with you that there is some Perl 4/5 cruft in CPAN that really should be tossed, this ignores the legacy apps that might still need to use this code. And as for stealing the good namespaces for writing new (and surely better) but very different Perl 6 modules, I am not actually sure I like that. Of course if the dream of Parrot/Ponie really works 100%, then it will probably be a non-issue, but if it doesn't (and there is yet to be a clear plan layed out as to how we will bridge Perl 5 -> 6), then updating legacy modules to Perl 6 might be something which really needs to happen if people are going to be able to port their larger Perl 5 code within a reasonable amount of time and effort. This is especailly true for modules like File::Spec or Test::More, which so many other modules just use as if they are part of the language. I don't mind re-working my core module to use the new whiz-bang OO features, but I would prefer to be able to automatically (and mechanically) convert my test suite rather than have to covert to some type off xUnit style tests or something. Some things may just need to stay the same, namespace intact. Anything else would IMO further the Perl 5/6 gap that will inevitably exist because of the depths of the language changes. - Stevan
Re: Parrot vs NekoVM
On Mar 4, 2006, at 18:05, Nicolas Cannasse wrote: -Cj does not produce different results than -j on the Win32 build of Parrot. Is -Cj supported on this architecture ? Yes, it should work. It might depend on, how fib is actually written in PIR. As said this option is in a rather early state. Compiling a subroutine to machine code is currently only done, if all Parrot registers are fitting into CPU registers. The fib function below is working here on x86/linux. Mmm - actually -C needs computed goto, which isn't supported by all C compilers. You can try: $ ./parrot -Sj fib.pir 38 Fib(38): 63245986 Nicolas leo .sub main :main .param pmc argv .local int argc, n argc = argv n = 1 unless argc == 2 goto argsok $S0 = argv[1] n = $S0 argsok: $P0 = getinterp $P0.'recursion_limit'(10) .local pmc array array = new .FixedFloatArray array = 2 $I1 = FibInt(n) array[0] = n array[1] = $I1 $S0 = sprintf <<"END", array Fib(%d): %d END print $S0 .end .sub FibInt .param int n unless n < 2 goto endif .return(1) endif: .local int tmp tmp = n - 2 $I0 = FibInt(tmp) tmp = n - 1 tmp = FibInt(tmp) $I0 += tmp .return($I0) .end
Re: Parrot vs NekoVM
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote: Mmm - actually -C needs computed goto, which isn't supported by all C compilers. Including the one that I produce the Win32 builds that I believe were being tested with (MS Visual C++). Shouldn't it give a "we don't have a computed goto runcore" error though when you supply -C on platforms without it? Jonathan
Re: Perl 6 design wiki?
Juerd schreef: > hierarchical names make less > and less sense by the day I don't oversee the field yet, but maybe: Introduce aliases (or hardlinks, in file-system-speak). Likely in a separate top branch, such as "@alias::". The @alias-prefix is only necessary when there is a collision. @alias::HTTPD::Session -> Apache::Session HTTPD::Session -> Apache::Session -- Greetings, Ruud
Re: early draft of I/O PDD
On Fri, Mar 03, 2006 at 05:54:43PM -0600, Joshua Isom wrote: > How do you verify that a print succeeded? Currently there's no way to > know. Throwing an exception if a global flag is set would suffice and I assumed that the lack of documentation of any return code meant that it would return as Perl 5 does. Bad me. > wouldn't require constantly pushing exception handlers in case the > program doesn't care enough (e.g. the run it and delete it variety). > Plus using exceptions would probably make platform independence easier > from PIR's standpoint as it won't need to know what the error code > actually means, and the exception object can include a message saying > so. As well, the lines of code can go straight from open to print to > close without throwing in error checking after each opcode. Since that > runs contrary to how most HLL's operate, I don't know how good of an > idea it really is for parrot. I get the impression that a lot of people would like to be able to switch Perl 5 to a mode where IO operations that return errors (but usually don't) throw exceptions instead. So rather than needing open $fh, ... or die ...; print $fh, ... or die ...; close $fh or die ...; # Some file systems may not notice that you are over quota until close time you do use fatal 'io'; # making this up open $fh, ...; print $fh, ...; close $fh; and errors are still reported correctly. This approach works even better if the void context open/print/close are in someone else's code that you're using, as you can impose decent error handling on it without needing to rewrite it. (An alternative setting is to run in exception throwing mode when builtins are called in void context, but return error codes when someone is listening for them) This is a HLL way of working, but not one currently easily supported. However, my understanding was that PIR doesn't have Perl 5's concept of context, so some of this isn't going to translate directly. But I think it will be possible to generate much tighter PIR if IO opcodes can be told to throw exceptions. > The 'write' opcode does seem redundant, but what if it's changed to > print to a user selected file stream? Just select the file stream with > one opcode, and each write call after that will print to that instead > of stdout. That's the best idea I can come up with to remove > redundancy(without removing the opcode of course), even though I don't > know if it'd be worth all the side effects. write in Perl 5 is for formats. I don't really see a need for it and print. > Concerning all the byte/character issues, all the string opcodes except > bytelength work with characters. But the io subsystem currently only > deals with bytes. I know there is the speed issue for things like > reading with dealing with utf8, but something like 'peek' should > probably be able to get the full character. Also, what's supposed to peek can't really guarantee to get more than 1 byte. This restriction sort of comes from C's stdio, which will allow you to ungetc() 1 byte, so you can (sort of) implement peek, in that you fake peek by pushing it back. However, the socket API allows a 1 byte peek from a socket without actually consuming it, so there is precedent at lower level APIs for 1 byte peek rather than a 1 character peek. The perl 5 PerlIO system allows unlimited unread() by pushing back a temporary buffer - this is more "peek" by "ungetc" than peek by really peeking. > be the default encoding for all data read in from a stream where a > layer's not added that explicitly states so? Ascii, binary? EBCDIC? Logically the default default is it's either compile time chosen "ASCII or EBCDIC" or "binary". Nicholas Clark
socket addresses (was Re: early draft of I/O PDD)
On Fri, Mar 03, 2006 at 05:54:43PM -0600, Joshua Isom wrote: > I don't think it's really been addressed, at least not recently, but > what about IPv6? By the time perl6 becomes commonplace and used > often(and thus, parrot), IPv6 will be common enough that problems could > occur. Currently it's not speced or stated, aside from a comment in > PIO_sockaddr_in. The draft has: =item * C returns a string representing a socket address, generated from a port number (integer) and an address (string). I don't think that this is appropriate. It's IPv4 specific. It doesn't cover AF_UNIX (er, AF_LOCAL), IPv6, or any of the other address formats (of which I'm not sure if any other than IPX are still commonly used. I'm not sure how to make an appropriate interface, partly as I have little idea if it's possible to make a sufficiently flexible abstraction for address names. IPv4 and IPv6 both use addresses and port numbers. AF_LOCAL just uses a string, which is a file system path. But I think that specifying an op for just one address format is too narrow. Nicholas Clark
Re: ANNOUNCE - Smolder 0.01
After some trouble, I managed to create a distribution tarball for my
patched Redhat 8 system from smolder-0.01-src using bin/
smolder_makedist.
The problem I encountered was in
src/libapreq-1.3.tar.gz - specifically in
src/libapreq-1.3/Makefile.PL (after unpacking the tarball)
the code in the BEGIN block was not finding the proper mod_perl
installation.
I hacked the Makefile.PL, mainly by putting this in the BEGIN block
(notice this is a hack it specifically mention my specific arch_lib -
i686-linux:
+use FindBin qw($Bin);
+my $arch_lib = "$Bin/../../../lib/i686-linux";
+use lib $arch_lib;
+my $mod_perl = "$arch_lib/mod_perl.pm";
+unless (eval {require $mod_perl}) {
+die "Please install mod_perl: 1.25 < version < 1.99\n($@)";
+}
Then, once I was able to create the dist tarball, I ran into another
problem:
WHen I ran ./bin/smolder_install from within my unpacked
distribution tarball, I got an error because Class::Trigger could
not be found - it doesn't seem to be included in the package,
although lib/Class/DBI.pm uses it. SO for the moment, I'm stuck.
-Matisse
#
Complete diff of how I hacked the Makefile.PL in src/
libapreq-1.3.tar.gz:
--- libapreq-1.3/Makefile.PL2003-07-04 19:42:02.0 -0700
+++ libapreq-1.3.hacked/Makefile.PL 2006-03-04 15:50:28.0
-0800
@@ -1,7 +1,21 @@
use ExtUtils::MakeMaker;
use strict;
-use FindBin;
use 5.005;
+BEGIN {
+use FindBin qw($Bin);
+my $arch_lib = "$Bin/../../../lib/i686-linux";
+use lib $arch_lib;
+my $mod_perl = "$arch_lib/mod_perl.pm";
+unless (eval {require $mod_perl}) {
+die "Please install mod_perl: 1.25 < version < 1.99\n($@)";
+}
+if ($mod_perl::VERSION < 1.2402) {
+die "Please upgrade mod_perl to 1.24_02 or greater";
+}
+elsif ($mod_perl::VERSION > 1.98) {
+die "mod_perl 1.x ( < 1.99) is required";
+}
+}
use File::Path qw(mkpath);
use lib qw(Apache-Test/lib);
@@ -18,17 +32,6 @@
require Apache::TestMM;
Apache::TestMM->import(qw(test clean));
}
-BEGIN {
-unless (eval {require mod_perl}) {
-die "Please install mod_perl: 1.25 < version < 1.99\n($@)";
-}
-if ($mod_perl::VERSION < 1.2402) {
-die "Please upgrade mod_perl to 1.24_02 or greater";
-}
-elsif ($mod_perl::VERSION > 1.98) {
-die "mod_perl 1.x ( < 1.99) is required";
-}
-}
my $conf_data = join '', ;
$conf_data =~ s|(blib/arch)|$FindBin::Bin/$1|;
seek/tell (was Re: early draft of I/O PDD)
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote: > What I need from you all is comments. What's missing? What's > inaccurate? What's accurate for the current state of Parrot, but is > something you always intended to write out later? What thoughts have > you had on how the I/O subsystem should work? All contributions > cheerfully welcomed, from a single sentence to several pages of text. =item * C sets the current file position of a stream object to an integer byte offset from an integer starting position (0 for the start of the file, 1 for the current position, and 2 for the end of the file). =item * C retrieves the current file position of a stream object. It also has a 64-bit variant that returns the byte offset as two integers (one for the first 32 bits of the 64-bit offset, and one for the second 32 bits). Shouldn't there be a 64-bit variant of seek? In fact, one doesn't need a tell opcode at all, given that seeking 0 from the current position is tell. (Although in turn that could function as a test for "is this file is seekable?" What does seek return on an unseekable file? What does tell return? IIRC sfio returned the number of bytes read (or written) for an unseekable file. Is that useful? Presumably seek() on a buffered stream discards any written but not flushed data. Mmm. Flush opcode needed for buffered streams? Nicholas Clark
Re: socket addresses (was Re: early draft of I/O PDD)
On Sun, Mar 05, 2006 at 18:34:26 +, Nicholas Clark wrote: > On Fri, Mar 03, 2006 at 05:54:43PM -0600, Joshua Isom wrote: > > > I don't think it's really been addressed, at least not recently, but > > what about IPv6? By the time perl6 becomes commonplace and used > > often(and thus, parrot), IPv6 will be common enough that problems could > > occur. Currently it's not speced or stated, aside from a comment in > > PIO_sockaddr_in. > > The draft has: > > =item * > > C returns a string representing a socket address, generated > from a port number (integer) and an address (string). > > > I don't think that this is appropriate. It's IPv4 specific. It doesn't cover > AF_UNIX (er, AF_LOCAL), IPv6, or any of the other address formats (of which > I'm not sure if any other than IPX are still commonly used. > > I'm not sure how to make an appropriate interface, partly as I have little > idea if it's possible to make a sufficiently flexible abstraction for > address names. IPv4 and IPv6 both use addresses and port numbers. AF_LOCAL > just uses a string, which is a file system path. But I think that specifying > an op for just one address format is too narrow. Objects that stringify! Objects that stringify! -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me whallops greyface with a fnord: neeyah!!! pgp2d8OPP5NHE.pgp Description: PGP signature
basic file IO (was Re: early draft of I/O PDD)
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote: =item * C retrieves a single line from a stream into a string. Calling C flags the stream as operating in line-buffer mode (see C below). Lines are truncated at 64K. Is there a fundamental need for a hard hard limit? I can see that it would be flexible to allow the stream to set this value, but it doesn't seem very perlish to deny programmer sufficient rope to hang themselves if they so wish. =item * C retrieves the UNIX integer file descriptor of a stream object, or 0 if it doesn't have an integer file descriptor. [Maybe -1 would be a better code for "undefined", since standard input is 0.] I think that this has to be -1, as in an embedded system (such as under Apache) standard input is often closed, and so descriptor 0 can be re-used. =item * C retrieves information about a file on the filesystem. It takes a string filename or an integer argument of a UNIX file descriptor, and an integer flag for the type of information requested. It returns an integer containing the requested information. The following constants are defined for the type of information requested (see F): To me it seems that stat should also be able to take a PMC representing an open parrot file handle. I assume that systems exist where we'll be layering Parrot IO onto underlying OS IO, where the OS uses tokens other than integers for its files. For example pointers, if miniparrot is built by layering Parrot IO onto C's stdio. 3STAT_ISDEV Whether the file is a device such as a terminal or a disk. Don't we need to get more flexible than this? At least file/terminal/socket/character special/block special/fifo/symlink/door Nicholas Clark
Re: early draft of I/O PDD
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote: [It's worth considering making all the network I/O opcodes use a consistent way of marking errors. At the moment, all return an integer status code except for C, C, and C.] IIRC the Linux kernel uses negative values as return codes, where these values are the negation of the value errno would hold. If we can use simple numeric values to cover all possibilities, this seems like a good approach, as it avoids thread local issues with errno, and issues such as whether return values are in errno, h_errno, or returned by the call itself (C API for system calls, hostname lookups, threading calls respectively) So I'd suggest that the -1 in these two would be replaced: =item * C receives a message from a connected socket object into a string. It returns an integer indicating the status of the call, -1 if unsuccessful. =item * C sends a message string to a connected socket object. It returns an integer indicating the status of the call, -1 if unsuccessful. As is, these are no different from print and read. The C socket API provides 3 functions, C, C and C. C is C with flags. C is C plus an address to use. [Neither Stevens nor the FreeBSD man page say what happens if the address is given as NULL] C is C with the kitchen sink. We need a C or better to do unconnected UDP sockets. If we make the address optional on our sendto-or-better then we don't need send. And given the frequency with which people write UDP socket code, I suspect that it would be better to provide ops only for C and C. =item * C polls a socket object for particular types of events (an integer flag) at a frequency set by seconds and microseconds (the final two integer arguments). It returns an integer indicating the status of the call, -1 if unsuccessful. [See the system documentation for C to see the constants for event types and return status.] poll should be available for all file descriptors, shouldn't it, not just sockets? Should the network opcodes even be loaded as standard? C et al aren't actually that useful on Perl 5 without all the constants in the Socket module, so in practical terms a redesigned Perl 5 would do better to remove all the socket specific keywords and make them functions exported by the Socket module. Should parrot go the same way? [And likewise System 5 IPC and shared memory builtins really should be functions, as should all the hosts/protocols/services/password lookups] Should the IO system provide symbolic lookup on AF_* and PF_* constants. IIRC at least one of these groups is OS dependant, as demonstrated by Solaris and SunOS differed on the values they used. It would be "useful" if this lookup could be flagged to happen in some way at bytecode load time. (Or maybe I want the moon on a stick alone with a "JIT this lazy constant" routine. Which probably does generalise, if functions can be marked as "cacheable" and the JIT can see a cacheable function taking only constants, and hence constant fold it) Nicholas Clark
Re: Parrot vs NekoVM
On Mar 5, 2006, at 18:33, Jonathan Worthington wrote: "Leopold Toetsch" <[EMAIL PROTECTED]> wrote: Mmm - actually -C needs computed goto, which isn't supported by all C compilers. Including the one that I produce the Win32 builds that I believe were being tested with (MS Visual C++). Shouldn't it give a "we don't have a computed goto runcore" error though when you supply -C on platforms without it? Definitely yes. What does happen currently, when running 'parrot -C' or 'parrot -Cj' with msvc? Jonathan leo
Re: basic file IO (was Re: early draft of I/O PDD)
On Mar 5, 2006, at 20:11, Nicholas Clark wrote: C flags the stream as operating in line-buffer mode (see C below). Lines are truncated at 64K. Is there a fundamental need for a hard hard limit? There used to be a hard limit until about a year ago. This is of course gone now. leo
Re: early draft of I/O PDD
On Mar 5, 2006, at 1:46 PM, Nicholas Clark wrote: On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote: Should the network opcodes even be loaded as standard? C et al aren't actually that useful on Perl 5 without all the constants in the Socket module, so in practical terms a redesigned Perl 5 would do better to remove all the socket specific keywords and make them functions exported by the Socket module. Should parrot go the same way? A pasm include, such as the signal.pasm(even though signals don't work yet), would suffice and is generated at compile time. Parsing .h files with anything but a c preprocessor would cause problems. Writing PMC's is almost a given, and the PMC's could even provide convenience methods that would do common things(like open a socket to foo.com:80). If it/they extend ParrotIO, the possibility of buffered networking would be possible(although I doubt many would want it on by default). But for all the defines, a pasm include would be needed. Should the IO system provide symbolic lookup on AF_* and PF_* constants. IIRC at least one of these groups is OS dependant, as demonstrated by Solaris and SunOS differed on the values they used. It would be "useful" if this lookup could be flagged to happen in some way at bytecode load time. With the pasm include method, the problem is they're mainly just preprocessing. There's currently no way for the include to put a flag in the resulting bytecode, unless platform specific pasm includes include some code that'll do something like that(most likely requiring a new opcode, 'pbcplatform "darwin"' for instance), and whenever the pasm file is included, it gets ran, and when the pbc is saved that state can be stored in a pbc header. Sounds really complicated and troublesome. (Or maybe I want the moon on a stick alone with a "JIT this lazy constant" routine. Which probably does generalise, if functions can be marked as "cacheable" and the JIT can see a cacheable function taking only constants, and hence constant fold it) Nicholas Clark
Re: early draft of I/O PDD
On Sun, Mar 05, 2006 at 02:53:29PM -0600, Joshua Isom wrote: > > On Mar 5, 2006, at 1:46 PM, Nicholas Clark wrote: > > >On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote: > > > >Should the network opcodes even be loaded as standard? C et al > >aren't > >actually that useful on Perl 5 without all the constants in the Socket > >module, > >so in practical terms a redesigned Perl 5 would do better to remove > >all the > >socket specific keywords and make them functions exported by the Socket > >module. Should parrot go the same way? > > A pasm include, such as the signal.pasm(even though signals don't work > yet), would suffice and is generated at compile time. Parsing .h files This way does the numeric values of the constants (at compile time) get frozen into bytecode written out to disk? Or does the generated bytecode do the lookup at run time on the run time platform? Nicholas Clark
Surprising use_ok false positive
I encountered a real-world case where Test::More's use_ok() passed
when the specified package had a fatal syntax error. I'm looking for
advice about whether I should file a bug, or fix my code that
triggered the false positive. Read on for details...
Consider two packages Foo.pm and Bar.pm:
--- Foo.pm ---
package Foo;
my $has_Bar = eval {require Bar; 1;};
sub print_msg {
$has_Bar ? Bar->print("Hello") : print "Hello";
}
1;
--- Bar.pm ---
package Bar;
sub print { # egregious syntax error
1;
--- t/use.t ---
use Test::More tests => 2;
use_ok('Foo');
use_ok('Bar');
Then if I run "perl t/use.t" I get the surprising result:
1..2
ok 1 - use Foo;
ok 2 - use Bar;
The problem is that Foo trapped Bar's syntax error in the eval, so %
INC{Bar} is defined and use_ok() sees it as a success.
Advice? While this example is contrived, the "eval { require ... }"
idiom is used often in the wild, so this is not a wholly unrealistic
scenario.
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: early draft of I/O PDD
On Mar 5, 2006, at 3:46 PM, Nicholas Clark wrote: On Sun, Mar 05, 2006 at 02:53:29PM -0600, Joshua Isom wrote: A pasm include, such as the signal.pasm(even though signals don't work yet), would suffice and is generated at compile time. Parsing .h files This way does the numeric values of the constants (at compile time) get frozen into bytecode written out to disk? Or does the generated bytecode do the lookup at run time on the run time platform? Compile time. Using load_bytecode would be runtime, but a pbc of one of those includes doesn't include any of the defines so those would have to be rewritten to do something else, such as subroutines. Nicholas Clark
Re: Surprising use_ok false positive
On Mar 5, 2006, at 13:52, Chris Dolan wrote:
Advice? While this example is contrived, the "eval
{ require ... }" idiom is used often in the wild, so this is not a
wholly unrealistic scenario.
Of course it should be
eval { require Bar; 1; } or die $@;
But I agree that it seems like if the load failed in your eval, it
should fail for Test::More, too. But maybe even a failed require sets
the record in %INC?
Best,
David
Re: Surprising use_ok false positive
On Mar 5, 2006, at 3:55 PM, David Wheeler wrote:
On Mar 5, 2006, at 13:52, Chris Dolan wrote:
Advice? While this example is contrived, the "eval
{ require ... }" idiom is used often in the wild, so this is not a
wholly unrealistic scenario.
Of course it should be
eval { require Bar; 1; } or die $@;
But I agree that it seems like if the load failed in your eval, it
should fail for Test::More, too. But maybe even a failed require
sets the record in %INC?
In this case, Bar.pm is intended to represent optional functionality
that Foo.pm conditionally loads. So, adding a die would be
counterproductive. The problem is that I don't know how to
distinguish between a load failure or a compile failure. There must
be a way to do that right?
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Perl 6 design wiki?
* Ruud H.G. van Tol ([EMAIL PROTECTED]) [060305 18:11]: > Juerd schreef: > > hierarchical names make less > > and less sense by the day > > I don't oversee the field yet, but maybe: > Introduce aliases (or hardlinks, in file-system-speak). > Likely in a separate top branch, such as "@alias::". > The @alias-prefix is only necessary when there is a collision. Once upon a time, I had to categorize the subjects of 20k websites in some logical structure, and then I discovered why the yellow pages have a flat organization... Of course, hierarchical names get less and less useful when your set grows larger. But it is better than nothing. > @alias::HTTPD::Session -> Apache::Session > HTTPD::Session -> Apache::Session Well, that's a technical solutions... your fill the name-space even more: the larger the harder to grasp. In general, it has many benefit to pick one name, and solve everything else via a searching mechanism like search.cpan.org. -- MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Re: ANNOUNCE - Smolder 0.01
Yuval Kogman wrote: > On Sat, Mar 04, 2006 at 09:09:00 -0500, Michael Peters wrote: >> It's very similar in nature to the Pugs smoke test server, but is completely >> project agnostic. It's also completely self contained (contains local copies >> all >> of it's Perl modules and a local apache/mod_perl). It's released in binary >> packages (currently there's only 1 binary package, but more will hopefully be >> coming) and also a source distribution from which you can build a binary >> package. All it requires is an existing version of Perl 5.8.x (might work >> with >> 5.6.x but that hasn't been tested) and MySQL 4.x. > > Could you please please please pretty please with a cherry on top > add SQLite support? Sure, that sounds reasonable. It would even make it more self contained with less dependencies. I'll add this to the TODO list. We've already received volunteers to add PostgeSQL support, so we'll make sure that it's easy enought to add SQLite as well, but as always, patches are welcome. > Another, much more pretentious request is that you refactor anything > and everything you can into generic modules and put them on the > CPAN. It's already resulted in Test::TAP::XML. Nothing immediately jumps out as applicable outside of smolder, but I'm sure more will come up. I've also got some planned improvements to Test::Harness::Straps and Test::TAP::Model that should make it easier to gather more information. -- Michael Peters Developer Plus Three, LP
Re: Perl 6 design wiki?
* Stevan Little ([EMAIL PROTECTED]) [060305 16:53]: > > to the two new perl books "Perl DBI-(Any)-cpan:TIMB" > > and "Perl DBI-(Any)-mailto:[EMAIL PROTECTED]" > Well, to start with, there is no > C6PAN/SixPan/Whatever-it-will-be-called yet, so there is nothing to > pre-register for. On the German Perl Workshop last week, I stirred things up a little with a BoF session about the subject. Amongst others, Andreas and Juerd where present. > Second, Perl 6 is still (at the very least) a year away from a > (mostly) complete implementation, > So pre-registration for namespaces in an unfinished language > is a litte premature IMO. So, in your opinion, it is easy to extend CPAN to contain perl6/parrot/ etc? Depends on the targets you set. Perl is especially known for its extended library: it is the main reason we still exist. To make Perl6 a success, we have to take care of the library! Just like new languages (like ruby) and ~features challenged Larry to redesign our favorit language, should CPAN be evaluated against new developments. Can we learn from SVN/SVK? Linux/GIT? Packaging like rpm's, etc? The library world grew much more complex with languages, character-sets, webdav, and super-fast networks at home. We do not only need to host Perl6, but also perl5, pir, pasm, partcl, etc etc languages. Quite a large number of people I spoke last week saw the need for major changes in the general set-up of CPAN. But certainly the current one is there to stay as well: CPAN is great. Maybe we can make it greater. Say Perl6 is still 2 years away, than we need to hurry with new plans for CPAN: when the currently eagerly waiting hurd of Perl programmers jump in, it is too late... > And lastly, I really don't like the idea anyway. It reminds me of the > domain-name squatters of the mid-90s. No, what I suggest is just like how cpan works now. But with a little planning ahead. > Some things may just need to stay the same, namespace intact. Anything > else would IMO further the Perl 5/6 gap that will inevitably exist > because of the depths of the language changes. For me, it feels as a big mistake when our new archiving needs are seen as a simple extra glue to the existing CPAN. If we need something smarter over two years, we have to start designing it NOW, and building it tomorrow! Before this becomes a real discussion about the future of CPAN: this thread started with Yuval asking about having a Perl Wiki. It would be nice to have a place where the community can be build, where the wide variety of projects can be organized which are required for a good and large new library. Were we can store presentations and teaching materials for the new languages, and so on. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Re: ANNOUNCE - Smolder 0.01
On Sun, Mar 05, 2006 at 17:55:03 -0500, Michael Peters wrote: > It's already resulted in Test::TAP::XML. Nothing immediately jumps out as > applicable outside of smolder, but I'm sure more will come up. I've also got > some planned improvements to Test::Harness::Straps and Test::TAP::Model that > should make it easier to gather more information. Shlomi Fish wrote Test::Run, a Test::Harness fork and was considering improving Test::TAP::Model as well... It might be beneficial for you guys to help each other out if you can. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: uhm, no, I think I'll sit this one out..: neeyah! pgpvSc6ngPJyD.pgp Description: PGP signature
Re: ANNOUNCE - Smolder 0.01
Matisse Enzer wrote: > After some trouble, I managed to create a distribution tarball for my > patched Redhat 8 system from smolder-0.01-src using bin/smolder_makedist. Thanks for trying this out so soon. It's been developed on FC3, but I can't imagine adding RH8 support will be too hard but it's currently not built-in. Smolder tries to recognize what platform it's being built on when you run smolder_build. What platform did it try and build for? Did you need to add a platform/RH8/Platform.pm > The problem I encountered was in >src/libapreq-1.3.tar.gz - specifically in >src/libapreq-1.3/Makefile.PL (after unpacking the tarball) > the code in the BEGIN block was not finding the proper mod_perl > installation. > > I hacked the Makefile.PL, mainly by putting this in the BEGIN block > (notice this is a hack it specifically mention my specific arch_lib - > i686-linux: That's strange. smolder_build is supposed to add this directory to @INC. What do you get when you dumpe @INC in the Makefile.PL? > WHen I ran ./bin/smolder_install from within my unpacked > distribution tarball, I got an error because Class::Trigger could not > be found - it doesn't seem to be included in the package, although > lib/Class/DBI.pm uses it. SO for the moment, I'm stuck. Thanks for catching this. I've uploaded 0.02 to sourceforge. Could you give that a try? -- Michael Peters Developer Plus Three, LP
Re: early draft of I/O PDD
On Sunday 05 March 2006 11:46, Nicholas Clark wrote: > On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote: > [It's worth considering making all the network I/O opcodes use a > consistent way of marking errors. At the moment, all return an integer > status code except for C, C, and C.] > > IIRC the Linux kernel uses negative values as return codes, where these > values are the negation of the value errno would hold. If we can use simple > numeric values to cover all possibilities, this seems like a good approach, > as it avoids thread local issues with errno, and issues such as whether > return values are in errno, h_errno, or returned by the call itself > (C API for system calls, hostname lookups, threading calls respectively) Parrot, not being C, does have exceptions -- c
Re: Perl 6 design wiki?
Mark Overmeer schreef: > Ruud H.G. van Tol: >> [aliases next to hierarchical names] >> @alias::HTTPD::Session -> Apache::Session >> HTTPD::Session -> Apache::Session > > Well, that's a technical solutions... your fill the name-space even > more: I can see no harm in that. > the larger the harder to grasp. I normally use search as the first step. Only then I look around for similar names. So aliases would bring more home for me. > In general, it has many > benefit to pick one name, and solve everything else via a searching > mechanism like search.cpan.org. I agree with that. I am currently building a photo classification system. Each photo is more or less unique, it has a unique identification code, and a short and a long description. Both descriptions may even be left empty. The classification is with keywords (or rather phrases, like 'marble hall'). A search on '+"marble hall" modern' (or: '+marble.hall modern') returns all 'marble hall' photos, with the 'modern' ones on top. The list of key-phrases is extensible and supposed to remain limited, but of course a user can let it grow out of hand as well. -- Grtz, Ruud
Re: Perl 6 design wiki?
Ruud H.G. van Tol schreef: > [Perl6-modules meta-structure] > I am currently building a photo classification system. Each photo is > more or less unique, it has a unique identification code, and a short > and a long description. Both descriptions may even be left empty. The > classification is with keywords (or rather phrases, like 'marble > hall'). A search on '+"marble hall" modern' (or: '+marble.hall > modern') returns all 'marble hall' photos, with the 'modern' ones on > top. The list of key-phrases is extensible and supposed to remain > limited, but of course a user can let it grow out of hand as well. Oops, I forgot one very important relation: the parent. Photos that belong together, are in the same directory. And a parent can have a parent, so there is still a tree that can be traversed. With modules, the 'See also' links can cover that. -- Grtz, Ruud
Re: ANNOUNCE - Smolder 0.01
On Mar 5, 2006, at 3:15 PM, Michael Peters wrote:
Matisse Enzer wrote:
After some trouble, I managed to create a distribution tarball for my
patched Redhat 8 system from smolder-0.01-src using bin/
smolder_makedist.
Thanks for trying this out so soon. It's been developed on FC3,
...
What platform did it try and build for?
I used the RH9 target:
bin/smolder_build RH9
and that seemed OK.
FYI:
my /etc/redhat-release has:
Red Hat Linux release 8.0 (Psyche)
and my Perl is /usr/bin/perl which is 5.8.7
I'll put output from perl -V at the end of this email.
My gcc is gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Did you need to add a platform/RH8/Platform.pm
Actually no, I didn't.
The problem I encountered was in
src/libapreq-1.3.tar.gz - specifically in
src/libapreq-1.3/Makefile.PL (after unpacking the tarball)
the code in the BEGIN block was not finding the proper mod_perl
installation.
I hacked the Makefile.PL, mainly by putting this in the BEGIN block
(notice this is a hack it specifically mention my specific arch_lib -
i686-linux:
That's strange. smolder_build is supposed to add this directory to
@INC. What do
you get when you dumpe @INC in the Makefile.PL?
See below...
...
Thanks for catching this. I've uploaded 0.02 to sourceforge. Could
you give that
a try?
Here it is from smolder-0.02-src - I added code to the Makefile.PL
for libapreq-1.3 to show @INC when it dies:
mod_perl 1.x ( < 1.99) is required. @INC contains: Apache-Test/lib,/
usr/local/src/smolder/smolder-0.02-src/lib/i686-linux,/usr/local/
src/smolder/smolder-0.02-src/lib,/usr/local/src/smolder/
smolder-0.02-src/platform,/usr/lib/perl5/5.8.7/i686-linux,/usr/lib/
perl5/5.8.7,/usr/lib/perl5/site_perl/5.8.7/i686-linux,/usr/lib/
perl5/site_perl/5.8.7,/usr/lib/perl5/site_perl/5.8.0,/usr/lib/perl5/
site_perl,. at Makefile.PL line 29.
I tried changing:
eval {require mod_perl}
to
eval {use mod_perl}
in Makefile.PL but that didn't work:
Please install mod_perl: 1.25 < version < 1.99 () at Makefile.PL
line 23.
I tried
eval {require 'mod_perl.pm'}
but that didn't work either. Passing the 'require' the exact path to
mod_perl.pm does work though.
I don't know why.
Hmmm. Looks like scripts/smolder_makedist removes the INSTALL file.
The install from the dist tarball worked, with one more change:
The password I used for DBPass has spaces in it, so, in bin/
smolder_createdb:
--- bin/smolder_createdb.dist 2006-03-05 17:18:39.0 -0800
+++ bin/smolder_createdb2006-03-05 17:23:44.0 -0800
@@ -180,7 +180,7 @@
# skip if database exists
my $cmd = qq{mysql -uroot -e 'select "$db_name exists"' $db_name};
-$cmd .= " -p$db_pass" if defined $db_pass;
+$cmd .= " -p\"$db_pass\"" if defined $db_pass;
$cmd .= " -h$hostname" if defined $hostname;
$cmd .= " -v" if $verbose > 1;
$cmd .= " 2>&1";
@@ -222,12 +222,12 @@
print STDERR "Loading SQL for '$db_name' from $file...\n"
if $verbose;
$cmd = "mysql -u$db_user $db_name ";
-$cmd .= " -p$db_pass" if $db_pass;
+$cmd .= " -p\"$db_pass\"" if $db_pass;
$cmd .= " -h$hostname" if defined $hostname;
$cmd .= " -v" if $verbose > 1;
$cmd .= " < $file ";
print "Running '$cmd'\n" if $verbose > 1;
-system($cmd) && die "Couldn't load SQL: $?: $!";
+system($cmd) && die "Couldn't load SQL with '$cmd': $?: $!";
}
# Set the db_version
Even though the install worked, the smolder apache will not run,
because DateTime::Locale is missing:
Can't locate DateTime/Locale.pm in @INC (@INC contains: .. /usr/local/
src/smolder/smolder-0.02-src/tmp/VQO4BAthpk/../trash/lib/perl5/
site_perl/5.8.7/i686-linux /usr/local/smolder/lib/i686-linux /usr/
local/smolder/lib /usr/lib/perl5/5.8.7/i686-linux /usr/lib/
perl5/5.8.7 /usr/lib/perl5/site_perl/5.8.7/i686-linux /usr/lib/perl5/
site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/
site_perl . /usr/local/smolder/apache/ /usr/local/smolder/apache/lib/
perl) at /usr/local/smolder/lib/i686-linux/DateTime.pm line 47
[EMAIL PROTECTED] smolder]# pwd
/usr/local/smolder
[EMAIL PROTECTED] smolder]# find lib -name "DateTime"
lib/i686-linux/auto/Data/FormValidator/Constraints/DateTime
lib/i686-linux/auto/DateTime
lib/i686-linux/DateTime
lib/DateTime
[EMAIL PROTECTED] smolder]# find lib -name "Locale*"
[EMAIL PROTECTED] smolder]#
OK, I gotta stop for now :-)
###
My setup:
perl -V shows:
Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
Platform:
osname=linux, osvers=2.4.29, archname=i686-linux
uname='linux athena 2.4.29 #2 thu feb 24 01:39:56 pst 2005 i686
athlon i386 gnulinux '
config_args='-ds -e -Dprefix=/usr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
usep
Lua PMC & Garbage Collection Segmentation fault
Hi all,
A Segmentation fault occurs in the languages/lua/t/tables_3.pir.
This test is a simple table creation (with 1000 items) :
a = {}
for i=1,1000 do a[i] = i*2 end
print(a[9])
This problem started with revision 11586.
In the previous Lua PMC implementation (r11478),
LuaBoolean extends Boolean
LuaNumber extends Float
LuaString extends String
LuaNil is a standalone PMC.
With r11586, I introduce an abstract PMC LuaBase, and these 4 Lua concrete
types extend LuaBase.
In both revisions, LuaTable extends Hash.
But something is wrong or missing in this new implementation.
I obtain the following back trace :
#0 0x1005b8f9 in pobject_lives (interpreter=0x3f4158, obj=0x0)
at src/dod.c:194
#1 0x1001902d in mark_hash (interpreter=0x3f4158, hash=0x768f28)
at src/hash.c:211
#2 0x1016d95e in Parrot_Hash_mark (interpreter=0x3f4158, pmc=0x6ecb90)
at src/pmc/hash.pmc:180
#3 0x1005be30 in Parrot_dod_trace_children (interpreter=0x3f4158,
how_many=4294966799)
at src/dod.c:455
#4 0x1005bc01 in trace_active_PMCs (interpreter=0x3f4158, trace_stack=1)
at src/dod.c:372
#5 0x1005c591 in Parrot_dod_ms_run (interpreter=0x3f4158, flags=1)
at src/dod.c:1172
#6 0x1005c64a in Parrot_do_dod_run (interpreter=0x3f4158, flags=1)
at src/dod.c:1211
#7 0x1005a0a1 in more_traceable_objects (interpreter=0x3f4158, pool=0x3f4d20)
at src/smallobject.c:114
#8 0x1005a120 in gc_ms_get_free_object (interpreter=0x3f4158, pool=0x3f4d20)
at src/smallobject.c:162
#9 0x1005a885 in new_pmc_header (interpreter=0x3f4158, flags=0)
at src/headers.c:254
#10 0x100163d1 in get_new_pmc_header (interpreter=0x3f4158, base_type=38,
flags=0)
at src/pmc.c:226
#11 0x10016426 in pmc_new_noinit (interpreter=0x3f4158, base_type=38)
at src/pmc.c:264
#12 0x10016094 in pmc_new (interpreter=0x3f4158, base_type=38)
at src/pmc.c:46
#13 0x1014489d in Parrot_default_getprop (interpreter=0x3f4158,
pmc=0x7c0b18, key=0xb17658)
at src/pmc/default.pmc:249
#14 0x009e2250 in ?? ()
#15 0x009ea5ea in ?? ()
#16 0x1009e499 in Parrot_set_p_k_p (cur_opcode=0x536e28, interpreter=0x3f4158)
at src/ops/set.ops:476
#17 0x10014f39 in runops_slow_core (interpreter=0x3f4158, pc=0x536e28)
at src/runops_cores.c:172
#18 0x10003e29 in runops_int (interpreter=0x3f4158, offset=0)
at src/interpreter.c:775
#19 0x100080ef in Parrot_LuaString_i_subtract_LuaString ()
at src/inter_run.c:81
#20 0x100082e0 in Parrot_LuaString_multiply_LuaString ()
at src/inter_run.c:180
#21 0x100083c8 in Parrot_runops_fromc_args (interpreter=0x3f4158,
sub=0x6ecb18, sig=0x101d87be "vP")
at src/inter_run.c:274
#22 0x10054e02 in Parrot_runcode (interpreter=0x3f4158, argc=1, argv=0x3f4134)
at src/embed.c:801
#23 0x0040288e in main (argc=1, argv=0x3f4134) at compilers/imcc/main.c:686
François.
