Trunk test failures on OS X

I'd greatly appreciate if someone can run a Trunk image (say, at 12384
or later) on a Cog r.2672 VM on OS X and let me know what happens?

Currently the build has a larger than expected number of failures [1],
several of which have timed out. I'd like to find out _why_ they timed
out.

Thanks!

frank

[1] http://build.squeak.org/job/SqueakTrunk-OSX/lastBuild/testReport/?

On 1/17/13 7:53 AM, "Frank Shearar" <[hidden email]> wrote:

Steps I do:
Download Cog r.2672
The last image I have was Squeak4.4-12327
Update to last in 4.4
MCMcmUpdater defaultUpdateURL: 'http://source.squeak.org/trunk'
New update and reach Squeak4.4-12384.image
Save it
Run Sunit
'3284 run, 3260 passes, 17 expected failures, 7 failures, 0 errors, 0
unexpected passes'
ClassRemovalTest>>#testClassRemovalAndRecompilationWontCreateDuplicateVariab
leBindings
ExceptionTests>>#testHandlerFromAction
LocaleTest>>#testLocaleChanged
ReleaseTest>>#testMethodsWithUnboundGlobals
ReleaseTest>>#testNoObsoleteClasses
SocketTest>>#testSocketReuse
SocketTest>>#testUDP

Also the debugger rise with the attajed.

RFI for 4.5
The report of Sunit could be logged to disk
The SqueakDebug.log could be more precise about which version of OS and Cog.
I test on old iMac 2.66Ghz with Intel core duo and OS.X 10.6.8

Cheers

Edgar

Thanks, Edgar!

That means there might be something wrong with my CI build. That's
(much) better news than a bunch of regressions in trunk.

frank

On 17 January 2013 12:27, Edgar J. De Cleene <[hidden email]> wrote:

On 1/17/13 9:51 AM, "Frank Shearar" <[hidden email]> wrote:

> Thanks, Edgar!
>
> That means there might be something wrong with my CI build. That's
> (much) better news than a bunch of regressions in trunk.
>
> frank


I do not know if you do some swiki page about CI builds, but like to know
any pointers to how to.

Edgar

If you want to repeat what the CI scripts do, it's quite easy, if you
have git installed:

$ git clone https://github.com/frankshearar/squeak-ci/
$ cd squeak-ci
$ ./builtasticMac.sh

That will produce a target/ directory with copies of the image,
changes and sources file. target/ will also contain a bunch of XML
files. These are in JUnit's reporting format, suitable for Jenkins or
whatever to read and display.

If you'd like to see the image while the above runs, edit
builtasticMac.sh and replace the line 'ARGS=$(vm_args "osx")' with
'ARGS=""'.

If you'd like to set up a build slave :), I can give instructions on
how to do that, too.

For the other platforms, the process is the same except the script is
builtastic.sh for the Unix platforms and builtasticWin.sh for Windows.
I don't have a builtasticRisc.sh yet, but if someone volunteers a
build slave I can set one up... *cough*

frank

On 17 January 2013 13:05, Edgar J. De Cleene <[hidden email]> wrote:

On 1/17/13 10:44 AM, "Frank Shearar" <[hidden email]> wrote:

Yes I could do.
Also could made a remote Mac user for you on my mac Mini with a external 2
Gb disk.
Or if you prefer a old box with Linux, but for this need more help.
Sure we learn some.
Email private for details.
Just now I go from home, but in about 5 hours return here.

Edgar

Edgar if you run SUnit from the System Reporter window, you get all the necessary info in one place. Just copy and paste into the email. System Reporter is invoked from the Help menu, select 'About this System'.


Image
-----
/Users/eglenpaling/Documents/Smalltalk/Squeak 4.4 Trunk/Squeak4.4-12327.image
Squeak4.4
latest update: #12385
Current Change Set: Unnamed
Image format 6505 (32 bit)

Virtual Machine
---------------
/Users/eglenpaling/Documents/Smalltalk/Build/VMs/Cog.app/Contents/MacOS/Croquet
Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.255] Croquet Cog 4.0.2672
Mac OS X built on Jan 14 2013 11:57:23 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3)
platform sources revision VM: r2672 http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins
CoInterpreter VMMaker.oscog-eem.255 uuid: 51e53ec1-8caf-41f6-9293-1088ef4b82d8 Jan 12 2013
StackToRegisterMappingCogit VMMaker.oscog-eem.255 uuid: 51e53ec1-8caf-41f6-9293-1088ef4b82d8 Jan 12 2013

SUnit Results
-------------
3284 run, 3260 passes, 17 expected failures, 7 failures, 0 errors, 0 unexpected passes

Failed Tests
------------
(ClassRemovalTest selector: #testClassRemovalAndRecompilationWontCreateDuplicateVariableBindings) debug.
(ExceptionTests selector: #testHandlerFromAction) debug.
(LocaleTest selector: #testLocaleChanged) debug.
(ReleaseTest selector: #testMethodsWithUnboundGlobals) debug.
(ReleaseTest selector: #testNoObsoleteClasses) debug.
(SocketTest selector: #testSocketReuse) debug.
(SocketTest selector: #testUDP) debug.

Errors
------

On 1/17/13 11:25 AM, "glenpaling" <[hidden email]> wrote:

> Edgar if you run SUnit from the System Reporter window, you get all the
> necessary info in one place. Just copy and paste into the email. System
> Reporter is invoked from the Help menu, select 'About this System'.

Ok.
Thanks!

Edgar

On 17-01-2013, at 5:44 AM, Frank Shearar <[hidden email]> wrote:
> I don't have a builtasticRisc.sh yet, but if someone volunteers a
> build slave I can set one up... *cough*


As in RISC OS?

It shouldn't be too hard to make something work I guess. There's an assortment of faintly unixy telnet type stuff that might help; makefile and so on are much the same, you can schedule jobs easily enough, SVN works ok (most of the time). Since the raspberryPi costs a whole $35 I imagine the smart thing to do would be to find a way to get one setup at your place.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
I haven't lost my mind; it's backed up on tape somewhere.

On 17 January 2013 19:10, tim Rowledge <[hidden email]> wrote:
>
> On 17-01-2013, at 5:44 AM, Frank Shearar <[hidden email]> wrote:
>> I don't have a builtasticRisc.sh yet, but if someone volunteers a
>> build slave I can set one up... *cough*
>
>
> As in RISC OS?

Ah, I think I got a nibble there!

> It shouldn't be too hard to make something work I guess. There's an assortment of faintly unixy telnet type stuff that might help; makefile and so on are much the same, you can schedule jobs easily enough, SVN works ok (most of the time).

The major issue, if it is actually an issue, is that we use Jenkins,
which necessitates running Java on the device. It might be possible to
write a special kind of Jenkins slave that instead of doing anything
itself, sshed commands to another slave on the RISC OS machine, if
running Java on such a device is untenable.

> Since the raspberryPi costs a whole $35 I imagine the smart thing to do would be to find a way to get one setup at your place.

Mine's currently broken, somehow. Both video and (more importantly)
network have stopped working. I should perhaps buy another one, you're
quite right! (But my own bias is towards running a unix on it.)

frank

On 17-01-2013, at 2:26 PM, Frank Shearar <[hidden email]> wrote:
> The major issue, if it is actually an issue, is that we use Jenkins,
> which necessitates running Java on the device. It might be possible to
> write a special kind of Jenkins slave that instead of doing anything
> itself, sshed commands to another slave on the RISC OS machine, if
> running Java on such a device is untenable.

Well there's no current version of java for RISC OS; something that is generally a Good Thing, if a touch ironic given that the CPU has built-in java bytecode support. Can jenkins be persuaded to output a human readable list of things to do? Does it simply automate fetching a load of files, compiling and then storing the results?

>
>> Since the raspberryPi costs a whole $35 I imagine the smart thing to do would be to find a way to get one setup at your place.
>
> Mine's currently broken, somehow. Both video and (more importantly)
> network have stopped working. I should perhaps buy another one, you're
> quite right! (But my own bias is towards running a unix on it.)

Taking it into the bath with you was probably a mistake. It's not a Rubber Ducky, y'know.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Hackers have kernel knowledge.