changing arguments names to default values for traits (closes #2532) #2533

djarecka · 2018-04-10T14:24:59Z

I tried to fix the names of the arguments, so the default values are set properly, changed:

default in Range, List, Dict, File to value
default in Bool, Int, Float to default_value
removed default in Enum and put the value fromdefault as the first one (so it will be treated as default)

Also:

I assumed that if default value is defined we want to have usedefault=True, so I added for traits that were missing this, but I think there are much more traits that have a default value set (just don't use default name argument) and they don't ask for usedefault=True
when I saw usedefault=False I just removed default

satra · 2018-04-11T11:22:29Z

nipype/interfaces/afni/utils.py

@@ -1696,13 +1697,14 @@ class NwarpCatInputSpec(AFNICommandInputSpec):
    inv_warp = traits.Bool(
        desc='invert the final warp before output', argstr='-iwarp')
    interp = traits.Enum(
+        'wsinc5',
        'linear',
        'quintic',
        'wsinc5',


this needs to be removed.

what do you mean? this element needs to be removed (so "linear" will be default) or usedefault=True should be removed?

I have two more traits as this one as interp or ainterp

'wsinc5' is listed twice - only once is necessary - for enum's the first element automatically becomes default.

oh, you are right, I forgot to remove the second one here. I've changed the order because Enum takes the first element as a default, and in the previous version it was default='wsinc5'.

Since the previous way of setting default was not working doctests were ignoring these elements, so I'd have to change a few doctests, unless you believe that these traits shouldn't have default

I can create a list of all doctests I'd have to change to pass now the tests

sounds good - just don't do make specs yet. that should happen after everything has been reviewed.

satra · 2018-04-11T11:26:10Z

also usedefault=False should be caught by check specs.

djarecka · 2018-04-11T13:00:28Z

@satra - what do you mean that usedefault=False should be caught by check specs? there are several places in nipype that uses it

satra · 2018-04-11T13:33:30Z

@djarecka - just like mandatory=False is not useful, usedefault=False is also not useful. hence if a default should not be used, those keywords should be left out. make specs reports all the inconsistencies of any keyword. if it is not catching usedefault=False, we should add it.

djarecka · 2018-04-11T13:52:37Z

@satra - ok, so you mean warnings. Indeed make specs returns warnings for mandatory=False (we have around 40 of them), but we don't have warnings for usedefault=False

djarecka · 2018-04-11T13:58:24Z

Ok, so in the last commit I changes tests in order to pass them, so would ask for extra checking:

in ants/resampling.py::ApplyTransforms I added float to cmdline
in afni/utils.py::[NwarpApply, NwarpCat] I dded interp and ainterp
in niftyseg/em.py::EM I added bc_order, bc_thresh, max_iter and min_iter
fsl.dti.py::BEDPOSTX5, I added burn_in, sample_every, update_proposal_every and burn_in_no_ard (different commit)
had to change hash in base/tests/test_core.py due to changest in ants.Registration

Check quickly doctest of other interfaces that I changed and it seems that they either don't change cmdline or specify values for traits I changed

djarecka · 2018-04-11T14:03:15Z

As I mentioned at the beginning there are traits that have specified default values and do not have usedefault=True. I'm guessing that authors who are specifying default values would like them to be used so it's a bug, but I'd need a few more hours to find all places. In most cases the name of the argument (default, default_value, etc.) was not used, so it's hard to search...

satra · 2018-04-14T02:00:43Z

@djarecka - are you going to add warning for usedefault=False

satra · 2018-04-14T02:01:01Z

other than that this looks good.

djarecka · 2018-04-14T02:13:35Z

@satra - oh, yes, I can add warning. I thought that I can just remove them too.

I was thinking whether to search other traits that don't have usedefault=True and define some default values, just not sure how long it can take. can do only for most popular interfaces, and can always open a new pr

satra · 2018-04-14T02:17:37Z

you can add some checks in make specs by looking for some metadata key, like default and/or default_value and also check if the trait has usedefault.

djarecka · 2018-04-14T02:25:13Z

@satra many default values in traits are set just using the first position, like here.

give me one day, will try to check a few directories and see how it goes.

djarecka · 2018-04-14T02:40:38Z

@satra - If I add more warnings now, I will just increase the list that no one reads anymore... Should I just remove all mandatory=false and usedefault=False

satra · 2018-04-14T12:29:04Z

@djarecka - we do remove them whenever we ask people to run make specs and we review, but we should improve that process. we should really start adding bots to github.

djarecka · 2018-04-15T14:06:28Z

we have many warnings for exists, e.g. nipype.interfaces.dtitk.registration:AffineTask:Inputs:fixed_file:exists. Why do we need them? What is wrong with this trait?

satra · 2018-04-15T14:50:15Z

this is being cleaned up in #2514

djarecka · 2018-04-15T14:56:50Z

@satra - so you don't want me to clean dtitk? I've already cleaned mandatory=False. can always revert it...

Also, I'm still not sure when exists should be reported in the checkspecs.py.

satra · 2018-04-15T15:01:31Z

@djarecka - don't clean dtitk.

…et by traits)

djarecka · 2018-04-15T19:53:37Z

ok, reverted my changes to dtitk

I added a simple check for default values, but it's not perfect. I wasn't sure what is a good way to check if an author of an interface defines any default, so I'm checking if trait.default, so I'm checking if the default value seen by traits is not the default "default value", i.e. it's not 0, False, [], etc.
Unfortunately, sometimes in nipype default value is set to 0 or False, and my check won't be able to catch this.

Because the way how traits treats default for various trait types, I also had to make several exceptions:

for Enum traits always treat the first value as default, so have no way of checking if the author wanted to have default value or not (excluded from the check)
for Tuple traits takes tuple of default values of inner traits as default tuple, but doesn't use it even if usedefault=True (excluded from the check
for Range traits assumes that default == low if no value is provided (if low == default I don't return any warning)

@satra you can check the list of warnings, if my rules and the list make sense, I can correct the interfaces

djarecka · 2018-04-16T15:28:28Z

ok, I merged and updated the code to remove most warnings. We had many places without usedefault, hopefully this is really what it should be...

I also exclude traits that have xor or requires, IMO it doesn't make sense to provide any default value for this kind of traits, but I just kept them unchanged.

One trait that is still in warnings that I wasn't sure about is this output name: https://github.com/nipy/nipype/blob/master/nipype/interfaces/ants/segmentation.py#L1263
with %d inside string. Should this have usedefault=True?

djarecka · 2018-04-16T16:04:29Z

so unfortunately I have to again change some tests, I changed hash in one of them, but I'm not sure what to do with:

workflows/rsfmri/fsl/tests/test_resting.py
algorithms/tests/test_CompCor.py
they're comparing to array of numbers that i don't know where does it come from. Is it any "ground truth" or can I change it?

effigies

Nice! A few comments, but overall it looks good. I would just make sure that things that are now being set as usedefault actually have correct default values, with respect to the commands. I caught a couple that looked funny to me on first glance, but did not attempt a systematic check.

effigies · 2018-04-17T17:38:44Z

nipype/algorithms/confounds.py

@@ -391,12 +391,13 @@ class CompCorInputSpec(BaseInterfaceInputSpec):
        'extraction')
    use_regress_poly = traits.Bool(
        True,
+        usedefault=True,


Since this is deprecated, it would probably be better to remove the default than to turn it on by default. (I think the main effect of adding usedefault=True will be to cause a DeprecationWarning to display, but I'm not sure of this.)

ok, will remove it. Actually DeprecationWarning is not displayed after my changes, only when you're changing later, so it's better to remove the default

effigies · 2018-04-17T17:54:55Z

nipype/interfaces/afni/utils.py

        desc='specify a different interpolation method than might '
        'be used for the warp',
        argstr='-ainterp %s',
-        default='wsinc5')
+        usedefault=True)


This seems like a change in semantics. From the docs:

-interp iii = 'iii' is the interpolation mode ++ Default interpolation mode is 'wsinc5' (slowest, bestest) ++ Available modes are the same as in 3dAllineate: NN linear cubic quintic wsinc5 ++ The same interpolation mode is used for the warp itself (if needed) and then for the data being warped. ++ The warp will be interpolated if the output dataset is not on the same 3D grid as the warp itself, or if a warp expression is used in the '-nwarp' option. Otherwise, it won't need to be interpolated. -ainterp jjj = This option lets you specify a different interpolation mode for the data than might be used for the warp. In particular, '-ainterp NN' would be most logical for atlas datasets, where the data values being mapped are labels

If I set -interp NN, then -ainterp would implicitly become NN, but we're setting it to wsinc5 by default.

I think it makes sense to remove the default form -ainterp entirely.

ok, will remove

effigies · 2018-04-17T17:55:43Z

nipype/interfaces/afni/utils.py

@@ -1841,7 +1842,6 @@ class OneDToolPyInputSpec(AFNIPythonCommandInputSpec):
    show_cormat_warnings = traits.File(
        desc='Write cormat warnings to a file',
        argstr="-show_cormat_warnings |& tee %s",
-        default="out.cormat_warn.txt",
        usedefault=False,


Should probably remove usedefault=False, too, right?

yes, should add warnings

effigies · 2018-04-18T02:16:38Z

nipype/interfaces/fsl/aroma.py

@@ -28,7 +28,8 @@ class ICA_AROMAInputSpec(CommandLineInputSpec):
        xor=['feat_dir'],
        desc='volume to be denoised')
    out_dir = Directory(
-        'out', genfile=True, argstr='-o %s', desc='output directory')
+        'out', usedefault=True, genfile=True,


Judging by _gen_filename, this wasn't intended to be a default value. @jdkent can you clarify your intent here?

Bump @jdkent.

haha, my intent when I made this was to get it to work, I kluged the out_dir definition from melodic and your comment from when I first tried making the wrapper. what a blast from the past!

so should out_dir have a default value? or should i remove 'out', usedefault=True,?

Okay, so in practice, it's been setting out_dir=os.getcwd(), as opposed to 'out'. Which is the preferable default?

out_dir = Directory('out', usedefault=True, mandatory=True, argstr='-o %s', desc='output directory')

out_dir = Directory(genfile=True, argstr='-o %s', desc='output directory')

I have a slight preference to the former, just to avoid cluttering the local directory (though maybe 'aroma_output' would be a better default). In which case we should also drop _gen_filename() method.

Yup, sounds good.

@effigies - just an extra question, do we use mandatory=True if we already have a default value and usedefault=True?

I think it's a good idea. The reason I suggest it is because somebody could set it as Undefined manually or (god knows why) pipe in a value that fails to be defined from a previous node.

In [1]: from nipype.interfaces.base import * In [2]: class A(BaseInterface): ...: class input_spec(TraitedSpec): ...: a = traits.Str('test', usedefault=True) ...: def _run_interface(self, runtime): ...: print(self.inputs.a) ...: return runtime ...: In [3]: a = A() In [4]: a.inputs Out[4]: a = test In [5]: a.inputs.a = Undefined In [6]: _ = a.run() <undefined>

So unless it really is optional, I would recommend flagging it mandatory.

sure, I can add it. I was just asking because in many places that we use usedefault=True we don't have mandatory=True (and I believe some of them are mandatory).

But that was just general question, adding mandatory=True won't hurt for sure, so will do it.

Ah. Yeah, I think we should probably add mandatory=True to those cases, when we see them. Alas, nipype interface metadata will remain inaccurate for a while longer.

effigies · 2018-04-18T02:23:55Z

nipype/interfaces/fsl/model.py

@@ -56,7 +56,7 @@ class Level1DesignInputSpec(BaseInterfaceInputSpec):
        desc=("which regressors to make orthogonal e.g., "
              "{1: {0:0,1:0,2:0}, 2: {0:1,1:1,2:0}} to make the second "
              "regressor in a 2-regressor model orthogonal to the first."),
-        default={})
+        value={}, usedefault=True)


{} is already the default.

that's true, sometimes I just kept it if author wanted to be explicit, but can remove it

effigies · 2018-04-18T02:25:50Z

nipype/interfaces/mrtrix3/tracking.py

@@ -262,7 +262,8 @@ class Tractography(MRTrix3Base):
    >>> tk.inputs.roi_mask = 'mask.nii.gz'
    >>> tk.inputs.seed_sphere = (80, 100, 70, 10)
    >>> tk.cmdline                               # doctest: +ELLIPSIS
-    'tckgen -algorithm iFOD2 -mask mask.nii.gz -seed_sphere \
+    'tckgen -algorithm iFOD2 -samples 4 -output_seeds out_seeds.nii.gz \
+-mask mask.nii.gz -seed_sphere \


Just a note you can drop the backslashes from this output string.

it doesn't work without

effigies · 2018-04-18T02:28:21Z

nipype/interfaces/mrtrix3/utils.py

@@ -183,6 +183,7 @@ class TensorMetricsInputSpec(CommandLineInputSpec):
        argstr='-value %s', desc='output selected eigenvalue(s) file')
    component = traits.List(
        [1, 2, 3],
+        usedefault=True,


From the docs:

-num sequence specify the desired eigenvalue/eigenvector(s). Note that several eigenvalues can be specified as a number sequence. For example, ‘1,3’ specifies the principal (1) and minor (3) eigenvalues/eigenvectors (default = 1).

ok, can keep just the first one

effigies · 2018-04-18T02:30:16Z

nipype/interfaces/mrtrix3/utils.py

@@ -266,7 +267,7 @@ class ComputeTDIInputSpec(CommandLineInputSpec):
        desc='specify output image data type')
    use_dec = traits.Bool(argstr='-dec', desc='perform mapping in DEC space')
    dixel = File(
-        'dixels.txt',
+        'dixels.txt', usedefault=True,


It's not clear to me from the docs that this is set by default.

we can remove usedefault=True, but I'd also remove the filename, imo it might me misleading

effigies · 2018-04-18T02:30:44Z

nipype/interfaces/niftyseg/em.py

+        argstr='-min_iter %s',
+        default_value=0,
+        usedefault=True,
+        desc='Minimun number of iterations')


djarecka · 2018-04-18T03:21:02Z

@effigies thanks for review, I indeed have problem with judging if the default value are correct and if the interfaces works "better" now... Still have 2 tests that are giving me assert error because they're comparing to specific arrays, and not sure what to do with them.

Will check your specific comments.

…t i also remove this value)

effigies

LGTM. Still not really sure about the ICA-AROMA trait, so making a little more noise.

effigies · 2018-04-24T15:32:47Z

nipype/interfaces/fsl/aroma.py

@@ -28,7 +28,8 @@ class ICA_AROMAInputSpec(CommandLineInputSpec):
        xor=['feat_dir'],
        desc='volume to be denoised')
    out_dir = Directory(
-        'out', genfile=True, argstr='-o %s', desc='output directory')
+        'out', usedefault=True, genfile=True,


Bump @jdkent.

djarecka · 2018-04-25T21:21:00Z

@effigies - can you also suggest something regarding out_intensity_fusion_name_format in AntsJointFusion. If I add usedefault=True here
I will get "antsJointFusion -a 0.1 -g ['rc1s1.nii', 'rc1s2.nii'] -l segmentation0.nii.gz -b 2.0 -o [ants_fusion_label_output.nii, antsJointFusionIntensity_%d.nii.gz] -s 3x3x3 -t ['im1.nii']" in this test.
Is this look ok as a default command? Wasn't sure...

effigies · 2018-04-25T21:28:26Z

It explicitly says optional. I would drop it and add it to desc as an example. Like:

out_intensity_fusion_name_format = traits.Str(
    argstr="",
    desc='Optional intensity fusion image file name format. '
         '(e.g. "antsJointFusionIntensity_%d.nii.gz")')

djarecka · 2018-04-25T21:33:27Z

@effigies ok, so I'll assume that desc is correct and will remove default value as you suggested.

atsuch · 2018-07-09T10:07:45Z

Hello @djarecka @satra, @effigies,

I think there might be an issue here. My lab mate noticed a considerable change in the output of FSL topup, and found the culprit to be the usedefault=True introduced @ 7871798.

Previously, command for the popup with minimum required input was;

'topup --config=b02b0.cnf --datain=topup_encoding.txt
--imain=b0_b0rev.nii --out=b0_b0rev_base --iout=b0_b0rev_corrected.nii.gz
--fout=b0_b0rev_field.nii.gz --jacout=jac --logout=b0_b0rev_topup.log
--rbmout=xfm --dfout=warpfield'

But because of the usedefault=True, the same minimum input gives;

'topup --config=b02b0.cnf --datain=topup_encoding.txt
--fwhm=8.000000 --imain=b0_b0rev.nii --miter=5
--out=b0_b0rev_base --iout=b0_b0rev_corrected.nii.gz
--fout=b0_b0rev_field.nii.gz --jacout=jac --logout=b0_b0rev_topup.log
--rbmout=xfm --dfout=warpfield --miter=1 --splineorder=3 --subsamp=1
--warpres=10.000000'

All the additional arguments (e.g. --fwhm, --miter, --warpres..) are optional, yet set by default in the new version of nipype (>1.0.3). While FSL provides default values for these args, some of these are default values IF these options are chosen (e.g. 8mm smoothing IF --fwhm is set). Some of these values may be default used regardless of whether the optional arg was included or not, but otherwise it's introducing a whole set of arguments the user did not intend to use with the command.

We found this to be the case for topup at least, but I think the options should be reviewed to make sure unintended options are not added to the command...

djarecka · 2018-07-09T16:58:57Z

@atsuch - thank you for reporting this issue. I added usedefault=True in places where I found that the default value was set by the author of the interface and at the end the value is not used (I assumed that this is misleading and it might be even unintentional).

I understand that you main concern is that at least some of these additional arguments should not be used as default for topup command. Could you please tell me which argument should be used as default (including the values) in your opinion?

cc: @oesteban - since you are the author of this interface, please let me know if you have any comments.

atsuch · 2018-07-10T09:53:27Z

Hi @djarecka , @oesteban,

I'm not expert in this command either. We just noticed the difference in the output when using the newer nipype in our pipeline. I read the FSL topup user guide quickly here (https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/topup/TopupUsersGuide), and found it a bit ambiguous with regard to the default values for --fwhm, --miter, and --warpres. Even though calling the topup in terminal tells you that default for these values are set to 8, 5, 10, respectively, the user guide does not mention these default values, and I'm not sure why you'd want to smooth it at 8mm for example, if you're not sub-sampling your image.

The fact that we get different results with or without setting these values suggest to me that these are not true default values, but we need to test it a bit more. We are running the command with and without some of these options to check the log and output.

By the way, I just noticed that --miter argument repeat itself (5 and then 1) in the generated topup command. Do you have any idea why and which value is actually being used??

atsuch · 2018-07-13T13:28:13Z

Hi again, @djarecka , @oesteban,

We did some tests and checked the topup log file and found that default values related to subsampling scheme are actually different from what is described in the documentation, and that's why when you explicitly specify these (wrong) values as default, it gives a different result.

For example, if we run the topup command with minimal arguments like this;

topup --config=b02b0.cnf --datain=topup_parameters.txt --imain=mydata.nii.gz --out=out_base --iout=out_corrected.nii.gz --fout=out_field.nii.gz --jacout=out_jac --logout=out_topup.log

This is what the log tells you what it's doing. Notice the discrepancy in what it says is the default values, and what are actually used...

#(approximate) resolution (in mm) of warp basis for the different sub-sampling levels, default 10
--warpres=20,16,14,12,10,6,4,4,4
#sub-sampling scheme, default 1
--subsamp=2,2,2,2,2,1,1,1,1
#FWHM (in mm) of gaussian smoothing kernel, default 8
--fwhm=8,6,4,3,3,2,1,0,0
#Max # of non-linear iterations, default 5"
--miter=5,5,5,5,5,10,10,20,20
#Weight of regularisation, default depending on --ssqlambda and --regmod switches. See user > documetation.
--lambda=0.005,0.001,0.0001,1.5e-05,5e-06,5e-07,5e-08,5e-10,1e-11
#If set (=1), lambda is weighted by current ssq, default 1
--ssqlambda=1
#Estimate movements if set, default 1 (true)
--estmov=1,1,1,1,1,0,0,0,0
#Minimisation method 0=Levenberg-Marquardt, 1=Scaled Conjugate Gradient, default 0 (LM)
--minmet=0,0,0,0,0,1,1,1,1
#Model for regularisation of warp-field [membrane_energy bending_energy], default > >
bending_energy
--regmod=bending_energy
#Order of spline, 2->Qadratic spline, 3->Cubic spline. Default=3
--splineorder=3
#Precision for representing Hessian, double or float. Default double
--numprec=double
#Image interpolation model, linear or spline. Default spline
--interp=spline
#If set (=1), the images are individually scaled to a common mean, default 0 (false)
--scale=1
#If set (=1), the calculations are done in a different grid, default 1 (true)
--regrid=1

I flagged this in FSL mailing list, so we'll see if they can tell us if this is the bug in the documentation...https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1807&L=fsl&F=&S=&P=136210

djarecka · 2018-07-13T15:20:03Z

@atsuch - thank you for testing this more! Indeed the log is interesting, and it doesn't look like the default values are always used. I'd be happy to know what FSL team thinks about it.

From nipype perspective it probably makes sense just to remove the default values. I can always provide the FSL default value from the FSL help (assuming that they are correct...?), but do not set them on the nipype level.

And answering your question about miter used twice. It is a bug, reg_lambda uses the same name of the argument for the topup command. Before I started using the default values probably not many people used it, so no one noticed. Reading the topup help, I believe the argument name should be --lambda

djarecka · 2018-07-13T17:08:21Z

@atsuch - I've created a PR #2637 with changes for topup, let me know if you have any comments

weningerleon · 2018-07-25T16:40:16Z

Hi all,

I also noticed this new behaviour when updating to a newer version of nipype.
However, I found this new behaviour quite problematic: If the user creates a config file, the custom settings in the config file are overwritten by the nipype default values. As far as I see, there is no way to deactivate the default values of nipype, so config files cannot be used any more if any nipype default values are given.

In comparison, the fsl-default values are overwritten by the config file, and the config file can be overwritten by the values given in the command.

So I would suggest deactivating the nipype default values again.

djarecka added 5 commits April 10, 2018 10:29

changing the name of the argument to set default values for traits

feea3ed

fixing changes in minc

456a516

removing usedefault=True if xor is defined

c55fdfd

restoring previous version with default (either trait)

7aa6fc1

typo

2e27fa2

satra reviewed Apr 11, 2018

View reviewed changes

removing the second wsinc5

cc0c0c6

changing tests (to be able to pass the after changes...)

5b73787

changing doctesr in BEDPOSTX5

d7917fe

djarecka added 3 commits April 15, 2018 14:40

adding check for default values

57d09ea

removing tuples from checks

388009f

checking if for Range the default is not equal low (this is default s…

952a034

…et by traits)

changing hash in test_core

83844ad

effigies reviewed Apr 18, 2018

View reviewed changes

djarecka added 7 commits April 18, 2018 00:06

suggestions from chris

a01d4b4

warnings for usedefault=False

7b17b4e

removing usedefault=False from traits (for traits were default was se…

f2d39a2

…t i also remove this value)

changinf freesurfer test_preprocess (default number of iterat)

f82baf2

changinf freesurfer test_preprocess (default number of iterat)

534a6a0

fixing the test

5cebe22

resolving conflicts

365d9c5

effigies approved these changes Apr 24, 2018

View reviewed changes

effigies added this to the 1.0.3 milestone Apr 25, 2018

removing gen_file and using a default value in ICA_AROMA

618e5a2

removing default value from out_intensity_fusion_name_format

59083d5

effigies approved these changes Apr 26, 2018

View reviewed changes

satra merged commit 615964c into nipy:master Apr 26, 2018

djarecka mentioned this pull request Jul 13, 2018

FIX: Un-set incorrect default options in TOPUP #2637

Merged

djarecka mentioned this pull request Jul 20, 2018

FSL TOPUP changes behavior at nipype 1.0.3 #2644

Closed

changing arguments names to default values for traits (closes #2532) #2533

changing arguments names to default values for traits (closes #2532) #2533

Uh oh!

Conversation

djarecka commented Apr 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

satra commented Apr 11, 2018

Uh oh!

djarecka commented Apr 11, 2018

Uh oh!

satra commented Apr 11, 2018

Uh oh!

djarecka commented Apr 11, 2018

Uh oh!

djarecka commented Apr 11, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

djarecka commented Apr 11, 2018

Uh oh!

satra commented Apr 14, 2018

Uh oh!

satra commented Apr 14, 2018

Uh oh!

djarecka commented Apr 14, 2018

Uh oh!

satra commented Apr 14, 2018

Uh oh!

djarecka commented Apr 14, 2018

Uh oh!

djarecka commented Apr 14, 2018

Uh oh!

satra commented Apr 14, 2018

Uh oh!

djarecka commented Apr 15, 2018

Uh oh!

satra commented Apr 15, 2018

Uh oh!

djarecka commented Apr 15, 2018

Uh oh!

satra commented Apr 15, 2018

Uh oh!

djarecka commented Apr 15, 2018

Uh oh!

djarecka commented Apr 16, 2018

Uh oh!

djarecka commented Apr 16, 2018

Uh oh!

effigies left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

djarecka commented Apr 10, 2018 •

edited

Loading

djarecka commented Apr 11, 2018 •

edited

Loading