Stack builder can not find list files if the file names start with a number

[raacampbell]

This has apparently happened with data in the MF lab when the sample ID is a number. e.g. "15".

[alexanderbrown]

Not something I've noticed. Where does it fail?

[raacampbell]

Don't know. I only know about this second-hand. I will invite people to contribute to this issue if they want it fixed.

[ghost]

I haven't tested longer filenames starting with numbers, however if the sample name is something simple, eg. "17," even if the list files are present, MaSIV will complain that it cannot find them. The channel options will also not be present for building after clicking "New." Renaming the sample (and all sub-folder/sampleID references to it) to something like: "AB_17" fixes the issue.

[raacampbell]

So the image list files start with the characters 17_

[ghost]

As does the yml, the "stackName" field in the yml, and the "sampleID" field in our mosaic files.

[alexanderbrown]

OK so one explanation is that matlab variables can't begin with a number. Because the masivMeta object uses the channel name to create a structure, it can't create a variable

[raacampbell]

Yeah, something like this screwed me too in StitchIt when those samples were acquired. In general we don't name our sample IDs with strings that start with a number. So this was a bit of a great occurrence. It will be impossible to do with out custom acquisition software, but TissueVision's software allows it.

Shall we fix this in MaSIV or should we just be crap and create a FAQ that tells users not to have sample IDs that start with a number?

[alexanderbrown]

I'm seeing if i can come up with a fix. If it's a ballache we'll take the easy route, but i'll just make sure that there isn't an easy fix

[raacampbell]

The easy route is waiting for you if you need it.

[alexanderbrown]

This may now be fixed in 19e9f26. @Synpaptic please confirm.

[raacampbell]

Doesn't fix it for me. I just mocked this up and it fails with it.

[ghost]

Works for me

[ghost]

Confirmed. Rolling back to previous version broke it, and new fixes it again.

[alexanderbrown]

Worked on my mocked up data too. Rob you sure your mocked data doesn't have another error?

…

On Fri, 6 Jan 2017 at 16:17, Synpaptic ***@***.***> wrote: Confirmed. Rolling back to previous version broke it, and new fixes it again. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFH45UmHsXbAelXlD1In2iQKCFmz4udWks5rPmkNgaJpZM4Lcks1> .

[raacampbell]

I think your fix fails if the sample ID is "01". If I rename everything to "10" then it works. I don't know why isnumeric would fail under those circumstances. Maybe there is a different failure point if the first character is zero. Try with the mock up I sent, above.

[ghost]

Yep, same thing happens here. I was testing with "10," but "01" breaks it

[alexanderbrown]

Odd. Should be fixable. I'll look in to it

…

On Fri, 6 Jan 2017 at 16:30, Synpaptic ***@***.***> wrote: Yep, same thing happens here. I was testing with "10," but "01" breaks it — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFH45fqOyYTQjF9HG3lCDgCNJtJgV4E1ks5rPmwKgaJpZM4Lcks1> .

[alexanderbrown]

Ok I can guess why that is the case. I'll write a fix later today or tomorrow

…

On Fri, 6 Jan 2017 at 16:30, Synpaptic ***@***.***> wrote: Yep, same thing happens here. I was testing with "10," but "01" breaks it — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFH45fqOyYTQjF9HG3lCDgCNJtJgV4E1ks5rPmwKgaJpZM4Lcks1> .

[alexanderbrown]

Should now be resolved in 2b357eb

The problem was caused when the stackname was read from yaml, converted to numeric and then back in to string, therefore losing the leading zero. I've tweaked the yaml reader to keep any seemingly numeric values as string if they contain leading zeros.

It's possible that this is unwise and could cause some unforeseen problems, but the chances are low and I'm hoping that writing this will reduce those chances further...

[raacampbell]

I double-checked that I have the changes pulled but I still don't see the stack appear. At the command line I get this:

>> masiv.yaml.readSimpleYAML('01_Meta.yml')

ans = 

  struct with fields:

             VoxelSize: [1×1 struct]
             stackName: 1
    imageBaseDirectory: '../'

and my YAML file contains:

VoxelSize:
    x: 1
    y: 1
    z: 9

stackName: 01
imageBaseDirectory: ../

So it's definitely importing it as a number. If I get a chance I'll look into this too. If it keeps being annoying we can just list as a known bug and move on.

[alexanderbrown]

Sorry I tried to replicate this but your example is no longer available

[raacampbell]

Sorry, I put it back. I also see I can drag into a comment to attach it. So here it is:
01_MaSIV.tar.gz

[alexanderbrown]

Should now be fixed in 8e2739f (I actually tested it this time)

Closing

[raacampbell]

See #15