The Buildbot has detected a failed build of Parrot-Builder-trunk.
Full details are available at:
http://buildbot.eigenstate.net:8040/Parrot-Builder-trunk/builds/35
Buildbot URL: http://buildbot.eigenstate.net:8040/
Buildslave for this Build: parrot-bot1
Build Reason:
Build Source Stamp: HEAD
B
The Buildbot has detected a failed build of Parrot-Builder-trunk.
Full details are available at:
http://buildbot.eigenstate.net:8040/Parrot-Builder-trunk/builds/40
Buildbot URL: http://buildbot.eigenstate.net:8040/
Buildslave for this Build: parrot-bot1
Build Reason:
Build Source Stamp: HEAD
B
The Buildbot has detected a failed build of Parrot-Builder-trunk.
Full details are available at:
http://buildbot.eigenstate.net:8040/Parrot-Builder-trunk/builds/41
Buildbot URL: http://buildbot.eigenstate.net:8040/
Buildslave for this Build: parrot-bot1
Build Reason:
Build Source Stamp: HEAD
B
The Buildbot has detected a failed build of Parrot-Builder-trunk.
Full details are available at:
http://buildbot.eigenstate.net:8040/Parrot-Builder-trunk/builds/42
Buildbot URL: http://buildbot.eigenstate.net:8040/
Buildslave for this Build: parrot-bot1
Build Reason:
Build Source Stamp: HEAD
B
The Buildbot has detected a failed build of Parrot-Builder-trunk.
Full details are available at:
http://buildbot.eigenstate.net:8040/Parrot-Builder-trunk/builds/43
Buildbot URL: http://buildbot.eigenstate.net:8040/
Buildslave for this Build: parrot-bot1
Build Reason:
Build Source Stamp: HEAD
B
The Buildbot has detected a failed build of ubuntu-ppc-trunk.
Full details are available at:
http://buildbot.eigenstate.net:8040/ubuntu-ppc-trunk/builds/0
Buildbot URL: http://buildbot.eigenstate.net:8040/
Buildslave for this Build: ubuntu-ppc-trunk
Build Reason:
Build Source Stamp: HEAD
Blame
The Buildbot has detected a failed build of ubuntu-ppc-trunk.
Full details are available at:
http://buildbot.eigenstate.net:8040/ubuntu-ppc-trunk/builds/1
Buildbot URL: http://buildbot.eigenstate.net:8040/
Buildslave for this Build: ubuntu-ppc-trunk
Build Reason:
Build Source Stamp: HEAD
Blame
The Buildbot has detected a failed build of ubuntu-ppc-trunk.
Full details are available at:
http://buildbot.eigenstate.net:8040/ubuntu-ppc-trunk/builds/2
Buildbot URL: http://buildbot.eigenstate.net:8040/
Buildslave for this Build: ubuntu-ppc-trunk
Build Reason:
Build Source Stamp: HEAD
Blame
The Buildbot has detected a failed build of ubuntu-ppc-trunk.
Full details are available at:
http://buildbot.eigenstate.net:8040/ubuntu-ppc-trunk/builds/3
Buildbot URL: http://buildbot.eigenstate.net:8040/
Buildslave for this Build: ubuntu-ppc-trunk
Build Reason:
Build Source Stamp: HEAD
Blame
dly rough) case for why I like Test::Unit is at:
http://twoalpha.blogspot.com/2005/11/unit-testing-in-perl-with-
testunit.html
-------
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
of what I've read here I'm going to try using Test::Class
and think more about this.
Thanks again,
Matisse
---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
tuff
}
I'll note here that Carp::Assert handles this issue by having you
make all the test calls conditional:
ASSERT( $a == $b) if DEBUG;
-M
-------
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
By the way - I have also been looking at Test::Assertions
---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
efore.
---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
On Jan 10, 2006, at 8:36 AM, dakkar wrote:
This entry in BooK's use.perl journal might help you:
http://use.perl.org/~BooK/journal/25445
Thanks - that is a helpful idea.
---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.
en very informative about practical techniques,
so we will have a couple good ideas to choose from rather than invent
our own.
-------
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
On Jan 27, 2006, at 6:06 PM, James E Keenan wrote:
Steffen Schwigon wrote:
Quite often -l (to read from lib/) is enough, depending on your
module
build complexity. For -b you have to call ./Build before "prove",
which can be annoying and/or difficult to remember.
I'll have to try that out.
::TCP
---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
llows one to
specify the installed permissions of files, for example, if i want my
executables to be installed as 550, or 4555 it doesn't look like I
can do that. I could be wrong about that though.
-------
Matisse Enzer <[EMAIL PRO
from CPAN,
for example M/MA/MATISSE/Text-TagTemplate-1.8.tar.gz
2) Put the CPAN .tar.gz files in a local CPAN repository and use
CPAN::Site to install - that way we *only* get the versions in
our local CPAN repository and dependencies are managed by the
module Makefile.PL
complicated :-) I'll read
it tomorrow when I've had some sleep.
-------
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
e to the
QA environment (which could be multiple machines.)
-------
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
tion of a powerful technique and Im glad to know about it. Thank
you!
--
Matisse Enzer
[EMAIL PROTECTED]
http://www.eigenstate.net/ - http://www.matisse.net/
sibly
> http://search.cpan.org/~ssoriche/CPAN-Mini-Inject-.18/lib/CPAN/Mini/Inject.pm
Yes thank you - I'm installing both to test.
--
Matisse Enzer
[EMAIL PROTECTED]
http://www.eigenstate.net/ - http://www.matisse.net/
I did some experimenting yesterday with CPAN::Mini::Inject and our
Subversion repository:
As many of you know, in the Subversion source control system every
file has a URL - it can be a file:// url, an http:// URL, an svn://
URL, etc.
I think what will work well for us is to use CPAN::Mi
) things for me -
I *feel better* doing TDD, it is actually easier for me in most
cases, as well as faster (for me) and more accurate - I write better
code. Of course, Your Milage May Vary (YMMV)
---
Matisse Enzer <[EMAIL PROTECTED]>
different environments - small company,
large company, fast-moving, slow-moving, etc.
-------
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
ther
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.
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 o
On Mar 6, 2006, at 4:10 AM, Nik Clayton wrote:
Matisse Enzer wrote:
Currently we are evaluating these options:
1) Maintain a list of the .tar.gz files and install from CPAN,
for example M/MA/MATISSE/Text-TagTemplate-1.8.tar.gz
2) Put the CPAN .tar.gz files in a local CPAN repository
What's the standard (if any) for how to configure a build script to
install specific files (e.g. httpd.conf) in someplace other than the
standard Perl library/script/man locations?
For example, if my distro contains a bunch of .pm files and .pl files,
which go in the "normal" place, and my dis
to live with that for now :-)
It's mainly an issue for executables.
> This has turned out to be one of the most FAQ with Module::Build. There
> are plans to greatly simplify the process in the next version of M::B,
> including removing the above mentioned limitations.
Cool, and thanks again.
-Matisse
On Tue, 28 Mar 2006, Randy W. Sims wrote:
> There are a number of ways to do this. The most simple is:
>
> use strict;
> use warnings;
>
> use File::HomeDir;
> my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' );
>
> use Module::Build;
> my $builder = Module::Build->new(
>
On Thu, 30 Mar 2006, Randy W. Sims wrote:
> Note that the entries in install_path must have the same name as
> supplied to add_build_element() (not with the '_files' appendage).
OK - thanks again, that is my problem... the naming of the entries...
I was too dense to appreciate your note about th
gh* application code to
make the test pass. Each mini-iteration might take between 1 and 5
minutes.
Here's a pretty good Power Point slide show that demonstrates the
process:
http://www.butunclebob.com/files/downloads/Bowling%20Game%20Kata.ppt
------
On Mar 31, 2006, at 11:02 AM, Adam Kennedy wrote:
Most end users don't see the "build" stage as being somehow
distinct, all they want to do is "install a module".
I agree 100% with that, and urge others to keep that in mind.
------
On May 21, 2006, at 7:29 PM, James E Keenan wrote:
Let's say that I'm writing a test suite for a Perl module which
creates files and then, optionally, moves those files to
predetermined directories. To test this module's functionality, I
would have to see what happens when the user runnin
More info:
Test failed on SVN revision 24566, but passed in revision 24567
So OK to close this one.
en.net/wiki/index.php/Buildbot#Installing_and_Configuring_BuildBot
-------
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
build.
---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
ks) -- Andy says he might have a suitable server.
For now I just want to see if people are interested and find the tool
useful.
What would it take to create a separate perl.org mailing list for
buildbot status messages?
-M
-------
Matiss
t have a strong
opinion.
-------
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
On Jan 12, 2008, at 8:29 PM, Andy Lester wrote:
We need to be talking more about what we're doing. Consider the
outside person who's only vaguely, if at all, familiar with Parrot.
"pbc_to_exe" means nothing to them.
++
---
(yet.)
/msg eigenbot status
to watch a currently running build (get builder names from 'status'):
/msg eigenbot watch {builder-name}
On Jan 13, 2008, at 9:33 AM, Andy Armstrong wrote:
On 13 Jan 2008, at 17:28, Matisse Enzer wrote:
Yup, I saw that. Would it help if I set up
On Jan 14, 2008, at 1:00 AM, Paul Cochrane wrote:
Matisse,
this is great work! Would it be possible for you to summarise this on
the parrot wiki somewhere?[1] Then we have a more permanent and
central location for the information.
Yes - I will take a whack at doing that.
Also: If anyone
On Jan 14, 2008, at 1:00 AM, Paul Cochrane wrote:
Matisse,
this is great work! Would it be possible for you to summarise this on
the parrot wiki somewhere?[1] Then we have a more permanent and
central location for the information.
Paul
[1] http://www.perlfoundation.org/parrot/index.cgi
Darwin. Thanks.
Is there someone with a Darwin box who is willing to run a buildbot
build slave on it?
If so, please let me know and I'll add it to my build master at
http://buildbot.eigenstate.net:8040/
-M
---
Matisse Enzer <[EMAIL P
tage :-)
Once I saw how cool the features in something like Eclipse are for
another language it really has made me see how far behind Perl is in
this area. I'm really scared that Perl will be an unacceptable choice
for larger projects in less than a two years.
-Matisse
----
tion that have a
bearing on Perl 6 design?
-------
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
415-225-6703 (work/cellphone)
415-401-8325 (home)
el::Refactor to support "extract subroutine", but a lot more is
needed to match what you can do with Java these days.
What are others' thoughts on this?
-------
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
these
things to me and to Larry Wall who was listening very politely :-)
Maybe this isn't the right place to keep discussing this, so I'll take
pointers to other places. I'm very worried about the continued
viability of Perl for major projects and am trying connect with other
people
51 matches
Mail list logo