freeBSD build failing on f8f230e

[jungle-boogie]

Hello,

This commit seems to cause a regression on FreeBSD:
f8f230e

The commit just before this one builds successfully.

https://gist.github.com/jungle-boogie/0e1e3eef359ec930e0cc

Any ideas what's the blame?

[johnkerl]

Hmm ... can you try a fresh pull from head (into a new directory) ?

[jungle-boogie]

Hmm ... can you try a fresh pull from head (into a new directory) ?

Yes, that fails, too. I git checkout to the specific commit I provided to determine it was the problem.

[johnkerl]

Do you mind to run mlr --csvlite put '$sec=gmt2sec($gmt)' ./reg_test/input/gmt2sec at the command line directly? I get:

$ mlr --csvlite put '$sec=gmt2sec($gmt)' ./reg_test/input/gmt2sec
gmt,sec
1970-01-01T00:00:00Z,0
1970-01-01T00:00:01Z,1
1970-01-01T00:00:10Z,10
1970-01-01T00:01:40Z,100
1970-01-01T00:16:40Z,1000
1970-01-01T02:46:40Z,10000
1970-01-02T03:46:40Z,100000
1970-01-12T13:46:40Z,1000000
1970-04-26T17:46:40Z,10000000
1973-03-03T09:46:40Z,100000000
2001-09-09T01:46:40Z,1000000000
2015-05-19T11:49:40Z,1432036180
2017-07-14T02:40:00Z,1500000000
2033-05-18T03:33:20Z,2000000000

[jungle-boogie]

$ mlr --csvlite put '$sec=gmt2sec($gmt)' ./reg_test/input/gmt2sec:
https://gist.github.com/jungle-boogie/0e0c0cb80a8bfed24212

$ mlr --csvlite sec2gmt sec ./reg_test/input/sec2gmt:
https://gist.github.com/jungle-boogie/28a2d4854ce5d25d42aa

Interestingly, this one fails:
$ mlr --csvlite put $sec=gmt2sec($gmt) ./reg_test/input/gmt2sec:
Badly placed ()'s.

[jungle-boogie]

And with the zsh shell:
% mlr --csvlite put $sec=gmt2sec($gmt) ./reg_test/input/gmt2sec
zsh: gmt2sec not found

[johnkerl]

The last two are due to missing single quotes on your shell commands.

I'm sure there's a system-dependent regression here but I'm skeptical that your bisection has identified the culprit commit. In a couple days I'll get you some experiments to run if you don't mind.

Also I need to set up a FreeBSD VM or something to shorten these cross-platform debug cycles.

[jungle-boogie]

Hello,

right, I'm not positive that the problem is exactly with f8f230e. I just know if I checkout the commit prior to f8f230e, it will build and install correctly. I don't know git bisect well enough to conclusively report the problem, just my observations.

Regarding the VM, it may be much simpler to install vagrant on your host and then download the 10.2-release of freebsd:
https://atlas.hashicorp.com/freebsd/
Here's vagrant: https://www.vagrantup.com/

This is basically a pre-made freebsd VM without the need to go through the install process of the guest OS.

To use vagrant, though, you need to have virtualbox or VMWare installed.

Once you have the freebsd vagrant up (presuming you'll use that), I recommend these steps:

sudo pkg install git, clone your repo and then make -f Makefile.no-autoconfig CC=clang in the c dir.

In fact I just downloaded a second 10.2-release and the same exact problem exists.

[jungle-boogie]

Any luck on getting your freeBSD environment setup and/or identifying the issue?

[johnkerl]

Not yet. I was on travel this last weekend, and while I had plenty of coding time, it was all on the airplane (off-net). Either I'll get the VM set up, or I'll send you some isolated, printf-decorated C snippets & ask you to compile and run them.

This and #82 are two things I absolutely want to get taken care of before making the next release.

[jungle-boogie]

Not a problem, @johnkerl. Hope your traveling was safe.

[johnkerl]

f4de252 has some overdue error-checking in these routines. (Things that should not have been failing with these particular inputs, but error-checking nonetheless.)

As a next step, @jungle-boogie if you can pull from head and recompile & post the output, I'd be grateful.

[johnkerl]

Also, your gist https://gist.github.com/jungle-boogie/0e0c0cb80a8bfed24212 above shows the test case not failing. So there is something odd and subtle here.

[jungle-boogie]

Hi @johnkerl,

Scroll all the way down and see the good news:
https://clbin.com/MrFtV

can you explain how you fixed it?

[johnkerl]

I don't see how I did. The commit you pointed to was number-to-string logic, and the unit-test failure you pointed out was in string-to-int. But I'm glad to hear it's resolved.

[johnkerl]

Thanks for your help!

[johnkerl]

To be specific, this most recent commit wouldn't have fixed it. An earlier one might have, inadvertently.

[jungle-boogie]

thank you for your help!