Re: Continuous testing tools

[Nik Clayton]

Geoffrey Young wrote:

Since you're using C++, you can probably use libtap
(http://www.onlamp.com/pub/a/onlamp/2006/01/19/libtap.html and
http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap) for writing the tests and
then you could use a Perl harnes to collect those results.


just out of curiosity, has anyone gotten this to work?  about two months
ago I tried to use it for a project but struggled with compilation
issues that were sufficient for me to stop trying...


I managed to get it to work.  But that's probably something of a given.

I never received much positive feedback about libtap, so I stuck it on 
the backburner, figuring that people were using other C frameworks.


I've just gone back to check, and it seems that a few people have 
submitted bug reports, but trac wasn't forwarding them to me, so I never 
saw them.


If you let me know what the compilation issues where I can try and 
resolve them.


N

Re: Continuous testing tools

[Geoffrey Young]

Nik Clayton wrote:
> Geoffrey Young wrote:
> 
>>> Since you're using C++, you can probably use libtap
>>> (http://www.onlamp.com/pub/a/onlamp/2006/01/19/libtap.html and
>>> http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap) for writing the
>>> tests and
>>> then you could use a Perl harnes to collect those results.
>>
>>
>> just out of curiosity, has anyone gotten this to work?  about two months
>> ago I tried to use it for a project but struggled with compilation
>> issues that were sufficient for me to stop trying...
> 
> 
> I managed to get it to work.  But that's probably something of a given.

:)

> 
> I never received much positive feedback about libtap, so I stuck it on
> the backburner, figuring that people were using other C frameworks.

that's too bad.  I definitely wouldn't give it up - it would be great to
 have a robust tap library for C, and that was exactly what I was
looking for.  I suspect that all tap fans would love to know that
something in C is being maintained... when they need it :)

> 
> I've just gone back to check, and it seems that a few people have
> submitted bug reports, but trac wasn't forwarding them to me, so I never
> saw them.

hmph.

> 
> If you let me know what the compilation issues where I can try and
> resolve them.

I don't know that I'll be able to do that with exact precision.  I was
at a client site and they were using their own test library, so I spent
maybe two hours trying to get libtap to work instead.  I was met with
all kinds of unresolved symbols or whatnot, which was painful for me as
just  a casual C guy...

really, to be ultimately useful it would be great if it were all very
self contained.  for example, if it were all in libtap.h as a set of
macros or something so I could include just one file and *poof* that
would be awesome.  well, from an end-user pov more than a developer pov
:)  but my memory tells me the process was actually a bit more than
that, so it wasn't exactly easy for me to use, which made me grumble
(and a bit sad).

anyway, sorry I can't be more specific at the moment - I probably should
have bugged you at the time.  if I ever do try it again I'll let you know.

--Geoff

Re: Continuous testing tools

[Adam Kennedy]

Sorry for the lack of information, but PITA's design is fairly 
ambitious, and until the core testing loop is completed, absolutely 
every other part of it would block waiting for me to finish.


So I've kept things mostly under wraps. With the core almost done (we've 
had to scrap a major component and rewrite it), I'll be doing a proper 
announce at YAPC::NA, and more information should start appearing after 
that.


I've been trying to be cautious to avoid any hyping of something that is 
just vapour, and also to retain the ability to scrap parts that don't 
work and rewrite.


The only public information I've made available, other than what you 
might be able to glean from the early releases of the PITA:: modules is 
the original draft specification is available on my personal website, 
although I'll note that the implementation has changed substantially 
since that was written.


http://ali.as/pita.html

Currently all activity is taking place in IRC at irc://irc.perl.org/pita

Anyone interested should add it to their IRC clients and lurk there.

There aren't any mailing lists or websites at the present time.

Adam K

Tels wrote:

Moin,

On Thursday 08 June 2006 18:10, Chris Dolan wrote:

On Jun 8, 2006, at 10:39 AM, Tels wrote:

On my todo (well, wish list) is still a project that works rouhgly
like a
server/client model.

You upload a snapshot to the server, it notifies the clients, they
download the package, run the tests and report the result back.
Reports
are viewed on the server.

Is there any interest in such a package?

Best wishes,

Tels

That sounds very similar to Adam Kennedy's PITA project.  Yes, there
is great interest!


I am not familiar with Adam's PITA, so maybe such a project already exists 
and I can save myself the work :D


Best wishes,

Tels

Re: Continuous testing tools

[Adam Kennedy]

Hi Andrew

I know it's somewhat vapour at the moment, and I'm keeping somewhat 
quiet, but the new post-Audrey'fied PITA design is aiming at exactly 
what you have described.


Initial deployment targets include a pugs smoker, parrot smoker, and 
CPAN Testers 2.


Of course, I have no idea how you projects are structured, but it may 
well be that it would be appropriate.


Of course, it partly depends on how quickly you need it... if you are in 
a hurry, then I'll get back to you in a few months.


Adam K

Andrew Savige wrote:

We are looking at introducing continuous builds/smoke tests at
work across a number of platforms (mainly Windows and Unix),
building a number of different languages (mainly C++).

I quick google uncovered the list below.

Anyone got any advice?

Thanks,
/-\


Perl


* AutoBuild: http://www.autobuild.org/,
http://search.cpan.org/dist/Test-AutoBuild/

* http://search.cpan.org/dist/Test-Smoke/

* http://search.cpan.org/dist/Test-Nightly/


Other Open Source
-

* BuildBot (Python): http://buildbot.sourceforge.net/

* DamageControl (Ruby):
http://opensource.thoughtworks.com/projects/damagecontrol.jsp

* CruiseControl (Java): http://cruisecontrol.sourceforge.net/

* CruiseControl.NET:
http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET

* Eclipse plug-in: http://www.eclipse.org/

* Tinderbox: http://www.mozilla.org/tinderbox.html

* BusyB: http://sourceforge.net/projects/busyb

Commercial
--

* ParaBuild: http://www.viewtier.com/products/parabuild/index.htm

* BuildForge: http://www.buildforge.com/


Send instant messages to your online friends http://au.messenger.yahoo.com 

[perl #39378] Pheme Segfault with Keyed Class Names

[via RT]

# New Ticket Created by  chromatic 
# Please include the string:  [perl #39378]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=39378 >


Hi there,

I started to port Pheme's class names to the new keyed style.  Applying this 
patch and rebuilding causes segfaults in some tests and multidispatch 
failures in others.

Oddly, I see these only when running through the Pheme interpreter, not when 
dumping out the raw PIR code and executing that.

Here's the backtrace from parrot pheme.pbc t/car.t:

(gdb) run pheme.pbc t/car.t 
Starting program: /home/chromatic/dev/parrot/parrot pheme.pbc t/car.t
[Thread debugging using libthread_db enabled]
[New Thread 805415360 (LWP 22606)]
[New Thread 814109936 (LWP 22609)]
[New Thread 822498544 (LWP 22610)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 805415360 (LWP 22606)]
0x0fdd97a8 in Parrot_Context_info (interpreter=0x1001a008, ctx=0x0, 
info=0x7f9e7b20) at sub.c:316
316 if (PMC_IS_NULL(ctx->current_sub)) {
(gdb) bt
#0  0x0fdd97a8 in Parrot_Context_info (interpreter=0x1001a008, ctx=0x0, 
info=0x7f9e7b20) at sub.c:316
#1  0x0fdd9c34 in Parrot_Context_infostr (interpreter=0x1001a008, ctx=0x0)
at sub.c:387
#2  0x0fea8c60 in Parrot_Continuation_get_string (interpreter=0x1001a008, 
pmc=0x10245128) at continuation.pmc:293
#3  0x0fde052c in key_string (interpreter=0x1001a008, key=0x10245128)
at key.c:367
#4  0x0feeb41c in Parrot_NameSpace_get_pointer_keyed (interpreter=0x1001a008, 
pmc=0x1004fed8, key=0x10245128) at namespace.pmc:292
#5  0x0fddc5b0 in pmc_type_p (interpreter=0x1001a008, name=0x10245140)
at pmc.c:416
#6  0x0fe73650 in mmd_cvt_to_types (interpreter=0x1001a008, 
multi_sig=0x10245158) at mmd.c:1278
#7  0x0fe73760 in mmd_distance (interpreter=0x1001a008, pmc=0x10245188, 
arg_tuple=0x10297ea0) at mmd.c:1305
#8  0x0fe73b04 in mmd_sort_candidates (interpreter=0x1001a008, 
arg_tuple=0x10297ea0, cl=0x10297e88) at mmd.c:1411
#9  0x0fe731cc in mmd_search_default (interpreter=0x1001a008, meth=0x310bdb70, 
arg_tuple=0x10297ea0) at mmd.c:1168
#10 0x0fe7274c in Parrot_MMD_search_default_func (interpreter=0x1001a008, 
meth=0x310bdb70) at mmd.c:912
#11 0x0fe3cc5c in Parrot_get_name (interpreter=0x1001a008, name=0x310bdb70)
at global.c:185
#12 0x0fcd76f0 in Parrot_find_name_p_sc (cur_opcode=0x1034b3a0, 
interpreter=0x1001a008) at var.ops:199
#13 0x0fdda494 in runops_slow_core (interpreter=0x1001a008, pc=0x1034b3a0)
at runops_cores.c:180
#14 0x0fdbec64 in runops_int (interpreter=0x1001a008, offset=3)
at interpreter.c:775
#15 0x0fdc4d18 in runops (interpreter=0x1001a008, offs=3) at inter_run.c:81
#16 0x0fdc5030 in runops_args (interpreter=0x1001a008, sub=0x10188e10, 
obj=0x10054578, meth=0x0, sig=0xff3ea88 "vP", ap=0x7f9e7ee0)
at inter_run.c:182
#17 0x0fdc5224 in Parrot_runops_fromc_args (interpreter=0x1001a008, 
sub=0x10188e10, sig=0xff3ea88 "vP") at inter_run.c:276
#18 0x0fe3ecc0 in Parrot_runcode (interpreter=0x1001a008, argc=2, 
argv=0x7f9e81e8) at embed.c:802
#19 0x10003a0c in main (argc=2, argv=0x7f9e81e8) at main.c:681

For some reason, the continuation being used has an empty context.  I haven't 
been able to track it down further.

-- c

Re: Continuous testing tools

[Andrew Savige]

--- Adam Kennedy wrote:
> I know it's somewhat vapour at the moment, and I'm keeping somewhat 
> quiet, but the new post-Audrey'fied PITA design is aiming at exactly 
> what you have described.

Thanks for the reminder about PITA. I'd (unforgivably) forgotten about
that project when I first enquired. Sorry 'bout that. ;-)

> Initial deployment targets include a pugs smoker, parrot smoker, and 
> CPAN Testers 2.
> 
> Of course, I have no idea how you projects are structured, but it may 
> well be that it would be appropriate.
> 
> Of course, it partly depends on how quickly you need it... if you are 
> in a hurry, then I'll get back to you in a few months.

I don't see an urgent need, though it's something we'd like to have.
I guess the main pressure is coming from the grass roots level where
a Java programmer might enquire "why don't we use CruiseControl?" or
a .NET guy might suggest something else or someone else just saw an
article on BuildBot and asks why don't we use that. I do find it a bit
disturbing that noone seems to ask about Perl-based solutions. ;-)

In the name of empowerment or anarchy, we could allow each group to
do their own thing and set up their own preferred tool themselves.
OTOH, we might try to build a single system that worked with Java,
.NET, C++, Perl, and so on. In terms of requirements, our Perl stuff
is standard TAP, while our C++ stuff has very home-grown non-standard
multi-platform builds and regression test suites.

Thanks,
/-\


Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: Continuous testing tools

[A. Pagaltzis]

* Adam Kennedy <[EMAIL PROTECTED]> [2006-06-09 18:35]:
> Sorry for the lack of information, but PITA's design is fairly 
> ambitious,

Hmm, I just saw this:

http://googleresearch.blogspot.com/2006/04/our-conference-on-automated-testing.html

The submission deadline has already passed, but I figure that
anyone on this thread will likely be interested about the
conference itself.

Regards,
-- 
Aristotle Pagaltzis //