I'm using TinyXML2 to generate XML spreadsheets, and I have a simple regression test comparing a newly generated sheet to a previously verified sheet to ensure new changes don't break the tool.
This test has been working for a while, but recently it has started failing on our CI server: the numbers in the spreadsheet generated on it have an error of about 1e-17 in magnitude or so and it's causing the file diff to fail. For reference builds in both machines are using the exact same docker container. What could be causing this discrepancy?
Line 243 Test: ' <ss:Data ss:Type="Number">0.00073917318674313406</ss:Data>'
Line 243 Expt: ' <ss:Data ss:Type="Number">0.00073917318674313396</ss:Data>'
Line 246 Test: ' <ss:Data ss:Type="Number">0.00086843815746046851</ss:Data>'
Line 246 Expt: ' <ss:Data ss:Type="Number">0.00086843815746046841</ss:Data>'
Line 260 Test: ' <ss:Data ss:Type="Number">0.0029117682828990695</ss:Data>'
Line 260 Expt: ' <ss:Data ss:Type="Number">0.00291176828289907</ss:Data>'
Tried running the regression test on both local machine and CI server many times to see if issue is intermittent or consistent. Local test passed every time while CI test failed every time.
Related
I'm following the instructions at Hugo's Quickstart guide (https://gohugo.io/getting-started/quick-start/) but I keep getting this error message when I try to create a post:
unmarshal failed: Near line 1 (last key parsed 'theme'): expected value but found '\\' instead
I've posted some lines of my code below. The error message appears at the bottom. Could anyone help point out what I am doing wrong?
C:\Users\Scott\quickstart\MyHugoBlog\themes>git init
Initialized empty Git repository in C:/Users/Scott/quickstart/MyHugoBlog/themes/.git/
C:\Users\Scott\quickstart\MyHugoBlog\themes>git submodule add https://github.com/dashdashzako/paperback.git
Cloning into 'C:/Users/Scott/quickstart/MyHugoBlog/themes/paperback'...
remote: Enumerating objects: 16, done.
remote: Counting objects: 100% (16/16), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 194 (delta 3), reused 9 (delta 1), pack-reused 178 eceiving objects: 53% (103/194)
Receiving objects: 100% (194/194), 466.30 KiB | 5.62 MiB/s, done.
Resolving deltas: 100% (93/93), done.
warning: LF will be replaced by CRLF in .gitmodules.
The file will have its original line endings in your working directory
C:\Users\Scott\quickstart\MyHugoBlog\themes>echo theme = \"paperback\" >> config.toml
C:\Users\Scott\quickstart\MyHugoBlog\themes>hugo new posts/my-first-post.md
Error: "C:\Users\Scott\quickstart\MyHugoBlog\themes\config.toml:1:1": unmarshal failed: Near line 1 (last key parsed 'theme'): expected value but found '\\' instead
It looks like you're following instructions meant for Unix-like systems on Windows. This command isn't doing what you want:
echo theme = \"paperback\" >> config.toml
Using Bash on Linux, for example, this appends
theme = "paperback"
to your config.toml file, creating it if necessary. That's what Hugo expects to find in the file.
However, using cmd.exe on Windows I get the backslashes included:
theme = \"paperback\"
And using PowerShell, I get something even stranger:
theme
=
\paperback\
Neither of these looks like valid TOML to me, and both contain extraneous backslashes as referenced in your error message. I suggest you simply edit config.toml using your favourite text editor and add the expected
theme = "paperback"
line manually.
The issue on my end was that the file wasn't created as UTF-8
Delete the config.toml file and recreate it manually on your text editor, then paste the content like: theme = "ananke"
should work
To run updateHITs.sh, I have to use the HIT ID and hittypeid. I have the ID, but I'm not sure how to get the type from command line tools. Any ideas?
There are two places you can get a HITTypeID using the Command Line Tools. First, it's shown when you create HITs. For example, here's the output run executing run.sh in the helloworld sample:
0088653dacfc:helloworld jrb$ ./run.sh
Unable to find a $JAVA_HOME at "/usr", continuing with system-provided Java...
--[Initializing]----------
Input: ../samples/helloworld/helloworld.input
Properties: ../samples/helloworld/helloworld.properties
Question File: ../samples/helloworld/helloworld.question
Preview mode disabled
--[Loading HITs]----------
Start time: Thu Mar 31 17:01:16 PDT 2016
Created HIT 1: HITId=3EHVO81VN5LKU5SFUDTKRPRS0ZQ1HA
Created HIT 2: HITId=3FBEFUUYRK50R4LYUDV95ZV5VFG6A2
Created HIT 3: HITId=307L9TDWJYS8E4S5KF2GK23LKVD3ND
Created HIT 4: HITId=35ZRNT9RUIYQWPSHLU2TZR3QA5I3OS
Created HIT 5: HITId=3X55NP42EOG8HP4I0UF8OR8GKAE3P9
You may see your HIT(s) with HITTypeId '3PFYYPJUJW5X02IODV4MGVYUBJX2Z0' here:
https://workersandbox.mturk.com/mturk/preview?groupId=3PFYYPJUJW5X02IODV4MGVYUBJX2Z0
End time: Thu Mar 31 17:01:17 PDT 2016
--[Done Loading HITs]----------
Total load time: 1 seconds.
Successfully loaded 5 HITs.
Also, you can get the HITTypeId in the .success file that's produced when you execute the run.sh command (to create HITs). For example, after I ran the above command, I had a file called helloworld.success in the same folder with the contents of (note I added a few tabs to make it look pretty, but don't try and use this directly in your file, the extra tabs mean it'll probably not work):
hitid hittypeid
3EHVO81VN5LKU5SFUDTKRPRS0ZQ1HA 3PFYYPJUJW5X02IODV4MGVYUBJX2Z0
3FBEFUUYRK50R4LYUDV95ZV5VFG6A2 3PFYYPJUJW5X02IODV4MGVYUBJX2Z0
307L9TDWJYS8E4S5KF2GK23LKVD3ND 3PFYYPJUJW5X02IODV4MGVYUBJX2Z0
35ZRNT9RUIYQWPSHLU2TZR3QA5I3OS 3PFYYPJUJW5X02IODV4MGVYUBJX2Z0
3X55NP42EOG8HP4I0UF8OR8GKAE3P9 3PFYYPJUJW5X02IODV4MGVYUBJX2Z0
The updateHITs.sh file is expecting a .success file as input. If all you have is a hitid, there's actually a sneaky way to do this. It turns out that you don't actually need a hittypeid in the .success file for it to work. So paste the code into a file, name it something like sneaky.success:
hitid
3FBEFUUYRK50R4LYUDV95ZV5VFG6A2
And then run the command:
./updateHITs.sh -success sneaky.success -properties new_hit.properties
Where "new_hit.properties" contains all the properties you want to update these HITs to.
The go test command has support for the -c flag, described as follows:
-c Compile the test binary to pkg.test but do not run it.
(Where pkg is the last element of the package's import path.)
As far as I understand, generating a binary like this is the way to run it interactively using GDB. However, since the test binary is created by combining the source and test files temporarily in some /tmp/ directory, this is what happens when I run list in gdb:
Loading Go Runtime support.
(gdb) list
42 github.com/<username>/<project>/_test/_testmain.go: No such file or directory.
This means I cannot happily inspect the Go source code in GDB like I'm used to. I know it is possible to force the temporary directory to stay by passing the -work flag to the go test command, but then it is still a huge hassle since the binary is not created in that directory and such. I was wondering if anyone found a clean solution to this problem.
Go 1.5 has been released, and there is still no officially sanctioned Go debugger. I haven't had much success using GDB for effectively debugging Go programs or test binaries. However, I have had success using Delve, a non-official debugger that is still undergoing development: https://github.com/derekparker/delve
To run your test code in the debugger, simply install delve:
go get -u github.com/derekparker/delve/cmd/dlv
... and then start the tests in the debugger from within your workspace:
dlv test
From the debugger prompt, you can single-step, set breakpoints, etc.
Give it a whirl!
Unfortunately, this appears to be a known issue that's not going to be fixed. See this discussion:
https://groups.google.com/forum/#!topic/golang-nuts/nIA09gp3eNU
I've seen two solutions to this problem.
1) create a .gdbinit file with a set substitute-path command to
redirect gdb to the actual location of the source. This file could be
generated by the go tool but you'd risk overwriting someone's custom
.gdbinit file and would tie the go tool to gdb which seems like a bad
idea.
2) Replace the source file paths in the executable (which are pointing
to /tmp/...) with the location they reside on disk. This is
straightforward if the real path is shorter then the /tmp/... path.
This would likely require additional support from the compiler /
linker to make this solution more generic.
It spawned this issue on the Go Google Code issue tracker, to which the decision ended up being:
https://code.google.com/p/go/issues/detail?id=2881
This is annoying, but it is the least of many annoying possibilities.
As a rule, the go tool should not be scribbling in the source
directories, which might not even be writable, and it shouldn't be
leaving files elsewhere after it exits. There is next to nothing
interesting in _testmain.go. People testing with gdb can break on
testing.Main instead.
Russ
Status: Unfortunate
So, in short, it sucks, and while you can work around it and GDB a test executable, the development team is unlikely to make it as easy as it could be for you.
I'm still new to the golang game but for what it's worth basic debugging seems to work.
The list command you're trying to work can be used so long as you're already at a breakpoint somewhere in your code. For example:
(gdb) b aws.go:54
Breakpoint 1 at 0x61841: file /Users/mat/gocode/src/github.com/stellar/deliverator/aws/aws.go, line 54.
(gdb) r
Starting program: /Users/mat/gocode/src/github.com/stellar/deliverator/aws/aws.test
[snip: some arnings about BinaryCache]
Breakpoint 1, github.com/stellar/deliverator/aws.imageIsNewer (latest=0xc2081fe2d0, ami=0xc2081fe3c0, ~r2=false)
at /Users/mat/gocode/src/github.com/stellar/deliverator/aws/aws.go:54
54 layout := "2006-01-02T15:04:05.000Z"
(gdb) list
49 func imageIsNewer(latest *ec2.Image, ami *ec2.Image) bool {
50 if latest == nil {
51 return true
52 }
53
54 layout := "2006-01-02T15:04:05.000Z"
55
56 amiCreationTime, amiErr := time.Parse(layout, *ami.CreationDate)
57 if amiErr != nil {
58 panic(amiErr)
This is just after running the following in the aws subdir of my project:
go test -c
gdb aws.test
As an additional caveat, it does seem very selective about where breakpoints can be placed. Seems like it has to be an expression but that conclusion is only via experimentation.
If you're willing to use tools besides GDB, check out godebug. To use it, first install with:
go get github.com/mailgun/godebug
Next, insert a breakpoint somewhere by adding the following statement to your code:
_ = "breakpoint"
Now run your tests with the godebug test command.
godebug test
It supports many of the parameters from the go test command.
-test.bench string
regular expression per path component to select benchmarks to run
-test.benchmem
print memory allocations for benchmarks
-test.benchtime duration
approximate run time for each benchmark (default 1s)
-test.blockprofile string
write a goroutine blocking profile to the named file after execution
-test.blockprofilerate int
if >= 0, calls runtime.SetBlockProfileRate() (default 1)
-test.count n
run tests and benchmarks n times (default 1)
-test.coverprofile string
write a coverage profile to the named file after execution
-test.cpu string
comma-separated list of number of CPUs to use for each test
-test.cpuprofile string
write a cpu profile to the named file during execution
-test.memprofile string
write a memory profile to the named file after execution
-test.memprofilerate int
if >=0, sets runtime.MemProfileRate
-test.outputdir string
directory in which to write profiles
-test.parallel int
maximum test parallelism (default 4)
-test.run string
regular expression to select tests and examples to run
-test.short
run smaller test suite to save time
-test.timeout duration
if positive, sets an aggregate time limit for all tests
-test.trace string
write an execution trace to the named file after execution
-test.v
verbose: print additional output
I was working on output formatting on C++ when I came across this weird error. Here is a sample of my code used to print info contained in an array:
int store;
while(table[i]!=NULL)
{
store=table[i]->ReturnID();
output<<"ID: "<<setw(9)<<store<<"\t"; // Export to a file channel
store=table[i]->ReturnTotalNumber();
output<<" Total Number: "<<setw(5)<<store<<endl;
i++;
}
Although the code compiles and works as intended here is a part of my output.txt file:
ID: 243 Total Number: 0
ID: 312 Total Number: 0
ID: 458 Total Number: 0
ID: 700 Total Number: 0
ID: 738 Total Number: 0
.....
The second line of the txt file always seems to be off balance. The rest are OK no matter how many they are. I have also noticed that changing the first setw(9) from 9 to any other random number fixes that bug but I can't explain it. Anyone have any explanation for this? My compiler is GCC-G++ version 4.4.1 and my IDE is Code::Blocks 10.05.
Based on the strings you're outputting, it appears that the tab has somehow gone astray. Your task therefore is to find out whether it's not being output by the program or whether it's not being rendered by whatever tool you're using to look at the output.
I would send the output to a file then use whatever hex dump utility you have to examine said file to see if the tab is actually there. Under Linux (or Windows with CygWin), you could use:
od -xcb fileNameYouCapturedTo
If you can establish it's not being output, raise a bug on glibc here. If it is being output then you have two possibilities.
First, you can file a bug against whatever tool you're using to view the output, whether that be an editor or the terminal program you're using (since it doesn't appear to be treating tabs correctly).
Or you could ditch the tabs altogether and just output a single space. Given that you're columns are already lined up because of the setw(), there's little need for tabs here.
A model glue site we use had to be moved to another physically different location. I updated all the paths in ModelGlue.xml, ColdSpring.xml and other specific files, but I keep getting the following error. Note: the current physical path is jmc.divisions.medical_oncology.admin.controller.Controller
Could not find the ColdFusion Component or Interface jmc.medical_oncology.admin.controller.Controller.
Ensure that the name is correct and that the component or interface exists.
The error occurred in E:\Inetpub\framework\ModelGlue\unity\loader\XmlConfigurationLoader.cfc: line 234
Called from E:\Inetpub\framework\ModelGlue\unity\loader\XmlConfigurationLoader.cfc: line 83
Called from E:\Inetpub\framework\ModelGlue\unity\loader\FrameworkLoader.cfc: line 98
Called from E:\Inetpub\framework\ModelGlue\unity\ModelGlue.cfm: line 116
Nevermind! Apparently, the system held onto some app-level caching for almost 48 hours. It finally works now.