4. Tools.Standalone.forkd doesn't compile due to missing

Process.ForkdDecoder, and that causes some tests to fail. Would there be a problem if this is fixed by a this_program_does_not_exist stanza in forkd.pike?

That should work fine. If you try to invoke it with -x, you would get the same error message as if forkd.pike did not exist (which arguably could be improved :). Tools.Standalone.make_wxs already uses this technique.

Well, mine fails 2 tests in Calendar, but I think it's been doing that for some time:

/Users/hww3/pike-git-test/lib/7.6/modules/Calendar.pmod/testsuite.in:32: Test 21 (shift 0) (CRNL) failed. 1: #pike 7.6 2: mixed a() { return Calendar.ISO.set_timezone("CET")->dwim_time("Tue Nov 19 07:04:03 NFT 2002")->tzname(); } 3: mixed b() { return "NFT"; } 4:

o->a(): "CET" o->b(): "NFT"

/Users/hww3/pike-git-test/lib/modules/Calendar.pmod/testsuite.in:38: Test 22 (shift 1) (CRNL) failed. 1: mixed a() { return Calendar.ISO.set_timezone("CET")->dwim_time("Tue Nov 19 07:04:03 NFT 2002")->tzname(); } 2: mixed b() { return "NFT"; } 3:

o->a(): "CET" o->b(): "NFT"

Bill

On Tue, 3 Jul 2012, Martin Stjernholm wrote:

"H. William Welliver III" bill@welliver.org wrote:

...

I've made a new beta build which for your consideration. If no problems are found, this build will become the next stable release. Please download, build, test, make binary packages, etc. As always, please report back with any problems (or successes, too!)

I get failures in the testsuite, both on linux and windows. Does it go through for you?

Regarding Windows, I fixed a couple bugs yesterday in debug_fd_stat which caused file_stat etc to fail spectacularly on most non-local filesystems. I wonder how it has worked earlier..

After that it gets through. My compilation environment provides the following:

features: dynamic loading..... yes threads............. yes (nt) signal handler...... custom NT cdebug.............. yes rtldebug............ no dmalloc............. no dlmalloc............ yes mmx................. no (no mmx.h found) byte code format.... ia32 module reloc........ no use machine code.... yes int type............ long (4 bytes) float type.......... float (4 bytes) (ieee little endian) pointer size........ 4 bytes svalue size......... 8 bytes (2+2+4)

Bz2................. yes (using libbz2) DNS-SD.............. no (dns_sd.h or howl.h not found) DVB................. no (dependencies failed) FFmpeg.............. no (dependencies failed) Fuse................ no (dependencies failed) GLUT................ no (dependencies failed) GSSAPI.............. yes (-lgssapi32) GTK................. no (dependencies failed) GTK.GlArea.......... no (dependencies failed) GTK.GladeXML........ no (dependencies failed) GTK2................ yes Gdbm................ no (dependencies failed) Gmp (bignums)....... yes (using libgmp) Gz.................. yes (libzlib) Image............... yes Image.FreeType...... yes Image.GIF........... yes Image.JPEG.......... yes Image.SVG........... no (dependencies failed) Image.TIFF.......... yes Image.TTF........... no (dependencies failed) Image.XFace......... yes Java................ yes (-lkernel32 -lws2_32 -ladvapi32) Kerberos............ yes (-lkrb5_32) MIME................ yes Math................ yes Math.Transforms.FFT. no (fftw.h not found) Mysql............... yes (liblibmysql) Nettle.............. yes Odbc................ no (dependencies failed) Oracle.............. no (dependencies failed) PDF.PDFlib.......... no (dependencies failed) PDF.Panda........... no (dependencies failed) Postgres............ yes Regexp.PCRE......... yes (libpcre) SDL................. no (dependencies failed) SDL_mixer........... no (dependencies failed) SQLite.............. yes ZXID................ no (dependencies failed) sybase.............. no (dependencies failed)

Is this good enough? Is there something that can/should be improved?

As for the testsuite on windows, things aren't that good. Besides the errors I also get on linux:

1. The socket and sendfile tests fail randomly with errors like

This file does not support nonblocking operation. -:1: Fd(10)->set_nonblocking() -:1: Stdio.File("conftest.dst", "cwt", 666 /* fd=10 */)->set_nonblocking() l:/mast-home/Pike/stable/lib/modules/Stdio.pmod/module.pmod:1442: Stdio.File("conftest.dst", "cwt", 666 /* fd=10 */)->set_nonblocking(0,0,0,UNDEFINED,UNDEFINED) l:/mast-home/Pike/stable/lib/modules/Stdio.pmod/module.pmod:3041: Stdio.Sendfile()->writer_done() l:/mast-home/Pike/stable/lib/modules/Stdio.pmod/module.pmod:2930: Stdio.Sendfile()->reader_done() l:/mast-home/Pike/stable/lib/modules/Stdio.pmod/module.pmod:2946: Stdio.Sendfile()->close_cb(0) -:1: Pike.Backend(0)->`()(3600.0)

2. Stdio.File.pipe tend to return zero in random tests.

3. Process.create_process randomly fails to spawn sub-pikes in tests.

4. Tools.Standalone.forkd doesn't compile due to missing

Process.ForkdDecoder, and that causes some tests to fail. Would there be a problem if this is fixed by a this_program_does_not_exist stanza in forkd.pike?

Unfortunately I can't promise any significant time tracking those random errors down right now. :\

Yes, I'll make a note to bisect the problem. I feel like I'd like to get a release out sooner rather than later, so I might be inclined to let it slide this time around, but then work on getting a new stable release in the next 3 months. I think it's important to get something out, even if it's got some minor issues, as it helps me feel like I've accomplished something, and lets others know that wheels are turning, however slowly.

Re: Win builds, thanks for the more detailed info, I must have missed it the first time around. I've got a fair amount of this sorted out myself, but it's good to get confirmation. I'll make a note of consolidating it with my own and put them someplace public.

Bill

On Tue, 3 Jul 2012, Martin Stjernholm wrote:

Bill Welliver bill@welliver.org wrote:

...

Well, mine fails 2 tests in Calendar, but I think it's been doing that for some time:

Yes, I get those too. The fact that they're old doesn't make them any less buggy, imo. A way to help sort it out could be to bisect out the responsible commit.

I also got more errors due to that putenv() seemingly didn't work, but they disappeared now when I started digging. :\ Strange, but I guess they can be written off as observational errors then.

...

Out of curoisity, what does your windows build environment look like? (OS, compiler, etc)...

sprshd, Windows Vista, Visual Studio 2005, GnuWin32 stuff, and various libraries taken from the net. Everything is quite old by now, but it still works. I wrote a longer explanation how it's set up on the other pike list a while ago. Here's a link in case you missed it: article.gmane.org/gmane.comp.lang.pike.user/8287

So, I've managed to get a .msi of the release candidate, and have successfully installed and run the new version of pike from it. There were/are a few glitches in the process, which I'm going to try to sort through. I suspect they may have something to do with some old libraries and headers I have laying around, or perhaps because I'm using VC9. Even so, I think this qualifies as a major victory for me. I haven't looked through your lengthy notes yet, but I'm sure they'll tell me where I've gone astray.

My goal is to cobble together a service that can be used to compile windows versions of third party modules. That way, a module developer can have some chance of making their module available for windows users.

Bill

On Jul 3, 2012, at 2:36 PM, Martin Stjernholm wrote:

Bill Welliver bill@welliver.org wrote:

...

Well, mine fails 2 tests in Calendar, but I think it's been doing that for some time:

Yes, I get those too. The fact that they're old doesn't make them any less buggy, imo. A way to help sort it out could be to bisect out the responsible commit.

I also got more errors due to that putenv() seemingly didn't work, but they disappeared now when I started digging. :\ Strange, but I guess they can be written off as observational errors then.

...

Out of curoisity, what does your windows build environment look like? (OS, compiler, etc)...

sprshd, Windows Vista, Visual Studio 2005, GnuWin32 stuff, and various libraries taken from the net. Everything is quite old by now, but it still works. I wrote a longer explanation how it's set up on the other pike list a while ago. Here's a link in case you missed it: article.gmane.org/gmane.comp.lang.pike.user/8287

Martin Stjernholm wrote:

1. The socket and sendfile tests fail randomly with errors like

This file does not support nonblocking operation. -:1: Fd(10)->set_nonblocking() -:1: Stdio.File("conftest.dst", "cwt", 666 /* fd=10 */)->set_nonblocking() l:/mast-home/Pike/stable/lib/modules/Stdio.pmod/module.pmod:1442: Stdio.File("conftest.dst", "cwt", 666 /* fd=10 */)->set_nonblocking(0,0,0,UNDEFINED,UNDEFINED) l:/mast-home/Pike/stable/lib/modules/Stdio.pmod/module.pmod:3041: Stdio.Sendfile()->writer_done()

2. Stdio.File.pipe tend to return zero in random tests.

Well, there are some serious issues with the networking/socket code and the corresponding configure tests and testsuite that comes with it.

I cleaned it up partially some time ago, and it still needs a major overhaul. After my USB and 1-wire drivers work, I'll take a look at it again; but this definitely is not going to be for the current 7.8 release.

Some other problem that occured to me is that precompilation in 7.8 does not work with a recent 7.9 because it requires the API version to be specified (version 3) on the command line. Maybe its enough to simply backport grubbas api version feature, or better make 7.9 precompile compatible with 7.8.

Do you have a list of the files that fail to precompile with 7.9?

The api feature is intentionally strict, since precompiling with the wrong api version may cause strange errors that are first noticed when the resulting binary is used.

/grubba

The issue seems to be that object(Thread.Thread) for instance should fall back to 7.8 behavior, which should become object. Its simply handled differently in the 7.9 precompile.

Yes, I thought it was something like that. The reason for the failure is that the 7.8 precompiler behaviour was considered broken.

I have a fix, that enables the old behavior when !api (when its not specified on the command line).

I think that I'd prefer a backport of the api=3 fixes from 7.9, since it's a silent broken success.

On Wed, Jul 11, 2012 at 03:18:12AM -0400, H. William Welliver III wrote:

Seems to build without problems, though I haven't run make verify yet. I will do that tomorrow and if all goes well will update the bundle. Since that's not version controlled, any thoughts on whether we need to increment the build number?

wasn't there another commit to include after 694?

here is hoping that the release will be 7.8.700 ;-)

greetings, martin.

I can certainly wait a few more days to do another build. I might have a few minor things to check in anyway.

As a side note, it's probably worth mentioning that I'm not opposed to doing 7.8 releases on a more frequent basis; in fact, I'd almost prefer to do a quarterly release rather than prepare an ongoing series of betas. I say this not only because it's been so long since an official release, but also because I feel as though people lose interest in looking at betas if they don't see a light (release) at the end of the tunnel.

Or, put another way: once we're rolling toward what would otherwise be an official release, I don't think that fixing a bug alone is reason enough to cut a new beta, unless it's a regression. Of course, that's assuming that one can count on the fix going out in a timely next release (which is a situation I'd like to get back to).

Bill

...

wasn't there another commit to include after 694?

There's a pending out of C-stack issue in the type-checker pending that might qualify [bug 6442]. I hope to have time to fix it soon.

...

here is hoping that the release will be 7.8.700 ;-)

On Thu, 12 Jul 2012, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:

Ok. I believe that I have now successfully fixed the type-checker issue.

Excellent!

The issue I just fixed could be triggered by some of the standard modules (depending on C-compiler and context) and caused the compiler to SEGV due to running out of C-stack. I believe that SEGV bugs are critical enough to hold up a release. Otherwise I certainly agree that we should attempt to release quite a bit more often.

Yes, I probably should have clarified that I wasn't suggesting that this particular bug shouldn't be a "release blocker".

So, basically, I think we're in agreement, which is always nice :)

Thanks (and sorry for any possible confusion)!

Bill

/grubba