[Bug]: Haskell feature is gone from https://containers.dev/features

Feature id and version
ghcr.io/devcontainers-contrib/features/haskell:2
Devcontainer base Image
mcr.microsoft.com/devcontainers/base:bookworm
What happened?
Haskell feature is gone from devcontainer feature list: https://containers.dev/features
Relevant log output
No response

You may want to see #628

This project is not associated with the devcontainer project and appears to have been abandoned #628 . The official project has removed all devcontainer-contrib features from their listing. https://github.com/devcontainers/devcontainers.github.io/issues/451


mail/rspamd: template error after fresh install

Oct 31 06:23:11 OPNsense pkg: fann-2.2.0 installed
Oct 31 06:23:12 OPNsense pkg: luajit-2.0.5 installed
Oct 31 06:23:12 OPNsense pkg: glib-2.50.2_6,1 installed
Oct 31 06:23:12 OPNsense pkg: rspamd-1.6.5 installed
Oct 31 06:23:13 OPNsense configd.py: [62a7b5a9-1eb0-4148-a00d-64096d90c1fc] request pfctl byte/packet counters
Oct 31 06:23:16 OPNsense configd.py Stopping daemon.
Oct 31 06:23:16 OPNsense configd.py Starting daemon.
Oct 31 06:23:17 OPNsense configd.py: [0f558658-5597-4493-8dfb-29f786e5622b] generate template OPNsense/Rspamd
Oct 31 06:23:18 OPNsense configd.py: generate template container OPNsense/Rspamd
Oct 31 06:23:18 OPNsense configd.py: [0f558658-5597-4493-8dfb-29f786e5622b] Inline action failed with OPNsense/Rspamd OPNsense/Rspamd/mx_check.conf 'collections.OrderedDict object' has no attribute 'Rspamd' at Traceback (most recent call last):   File "/usr/local/opnsense/service/modules/processhandler.py", line 507, in execute     return ph_inline_actions.execute(self, inline_act_parameters)   File "/usr/local/opnsense/service/modules/ph_inline_actions.py", line 50, in execute     filenames = tmpl.generate(parameters)   File "/usr/local/opnsense/service/modules/template.py", line 309, in generate     raise render_exception Exception: OPNsense/Rspamd OPNsense/Rspamd/mx_check.conf 'collections.OrderedDict object' has no attribute 'Rspamd'
Oct 31 06:23:18 OPNsense pkg: os-rspamd-devel-0.1 installed

Perhaps some wrong defaults? Havent digged into it yet.

No, probably not saved the file and I have not added a default value or a lock. I'll add a fix for that.

Closed, thanks 👍

@mimugmail everything ok now?

Yes.
Why is openfish premium enabled by default?

maybe a copying issue

@mimugmail this was disabled - maybe something went wrong:
https://github.com/opnsense/plugins/blob/master/mail/rspamd/src/opnsense/mvc/app/models/OPNsense/Rspamd/RSpamd.xml#L126

Model is missing a field type

which one?

The link you posted before?

thanks - fixed: https://github.com/opnsense/plugins/commit/7d91e49d4087ad372e1f2af0c12015f1bcbe65b4


Functions that return rate area and region [delivers #156635384]

Description
This change adds two funcs, FetchRateAreaForZip5 and FetchRegionForZip5 to the models package. It also changes zipcodes to be represented using strings instead of ints in a few places (including the database).
Reviewer Notes

This code performs explicit length checks on the zip5s that are passed into the new functions. I think this is warranted, as otherwise, the program will panic if we attempt to operate on two short of a value. But we should think about where in the application the responsibility to enforce this should live. Is validating this in Swagger and models enough?

Code Review Verification Steps

[ ] All tests pass.
[ ] Code follows the guidelines for Logging
[ ] The requirements listed in
Querying the Database Safely
have been satisfied.
[ ] Request review from a member of a different team.
[ ] Have the Pivotal acceptance criteria been met for this change?

References

Pivotal story for this change

@kilbergr Thanks for the thorough review. Can you take another look now?


Error with-- cannot run freesurfer

Hello,
I'm confused on the freesurfer running for the last three subjects, all time run this step: resume recon-all : recon-all -autorecon-hemi lh -noparcstats -nocortparc2 -noparcstats2 -nocortparc3 -noparcstats3 -nopctsurfcon -nohyporelabel -noaparc2aseg -noapas2aseg -nosegstats -nowmparc -nobalabels -openmp 8 -subjid sub-055 -sd /out/freesurfer
sometime reported this crash.
Node: _autorecon_surfs0
Working directory: /tmp/work/fmriprep_wf/single_subject_082_wf/anat_preproc_wf/surface_recon_wf/autorecon_resume_wf/autorecon_surfs/mapflow/_autorecon_surfs0
Node inputs:
FLAIR_file =
T1_files =
T2_file =
args =
big_ventricles =
brainstem =
directive = autorecon-hemi
environ = {}
expert =
flags = ['-noparcstats', '-nocortparc2', '-noparcstats2', '-nocortparc3', '-noparcstats3', '-nopctsurfcon', '-nohyporelabel', '-noaparc2aseg', '-noapas2aseg', '-nosegstats', '-nowmparc', '-nobalabels']
hemi = lh
hippocampal_subfields_T1 =
hippocampal_subfields_T2 =
hires =
mprage =
mri_aparc2aseg =
mri_ca_label =
mri_ca_normalize =
mri_ca_register =
mri_edit_wm_with_aseg =
mri_em_register =
mri_fill =
mri_mask =
mri_normalize =
mri_pretess =
mri_remove_neck =
mri_segment =
mri_segstats =
mri_tessellate =
mri_watershed =
mris_anatomical_stats =
mris_ca_label =
mris_fix_topology =
mris_inflate =
mris_make_surfaces =
mris_register =
mris_smooth =
mris_sphere =
mris_surf2vol =
mrisp_paint =
openmp = 8
parallel =
subject_id = sub-082
subjects_dir = /out/freesurfer
talairach =
use_FLAIR =
use_T2 =
xopts =
Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.6/site-packages/nipype/pipeline/plugins/multiproc.py", line 69, in run_node
result['result'] = node.run(updatehash=updatehash)
File "/usr/local/miniconda/lib/python3.6/site-packages/nipype/pipeline/engine/nodes.py", line 471, in run
result = self._run_interface(execute=True)
File "/usr/local/miniconda/lib/python3.6/site-packages/nipype/pipeline/engine/nodes.py", line 555, in _run_interface
return self._run_command(execute)
File "/usr/local/miniconda/lib/python3.6/site-packages/nipype/pipeline/engine/nodes.py", line 635, in _run_command
result = self._interface.run(cwd=outdir)
File "/usr/local/miniconda/lib/python3.6/site-packages/nipype/interfaces/base/core.py", line 522, in run
runtime = self._run_interface(runtime)
File "/usr/local/miniconda/lib/python3.6/site-packages/nipype/interfaces/base/core.py", line 1038, in _run_interface
self.raise_exception(runtime)
File "/usr/local/miniconda/lib/python3.6/site-packages/nipype/interfaces/base/core.py", line 975, in raise_exception
).format(**runtime.dictcopy()))
RuntimeError: Command:
recon-all -autorecon-hemi lh -noparcstats -nocortparc2 -noparcstats2 -nocortparc3 -noparcstats3 -nopctsurfcon -nohyporelabel -noaparc2aseg -noapas2aseg -nosegstats -nowmparc -nobalabels -openmp 8 -subjid sub-082 -sd /out/freesurfer
Standard output:
Subject Stamp: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.1-f53a55a
Current Stamp: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.1-f53a55a
INFO: SUBJECTS_DIR is /out/freesurfer
Actual FREESURFER_HOME /opt/freesurfer
Linux b16d469ba965 4.4.0-141-generic #167~14.04.1-Ubuntu SMP Mon Dec 10 13:20:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
'/opt/freesurfer/bin/recon-all' -> '/out/freesurfer/sub-082/scripts/recon-all.local-copy'
#--------------------------------------------
#@# Tessellate lh Wed Mar 13 00:45:54 UTC 2019
/out/freesurfer/sub-082/scripts
mri_pretess ../mri/filled.mgz 255 ../mri/norm.mgz ../mri/filled-pretess255.mgz
Iteration Number : 1
pass   1 (xy+):   5 found -   5 modified     |    TOTAL:   5
pass   2 (xy+):   0 found -   5 modified     |    TOTAL:   5
pass   1 (xy-):   2 found -   2 modified     |    TOTAL:   7
pass   2 (xy-):   0 found -   2 modified     |    TOTAL:   7
pass   1 (yz+):   3 found -   3 modified     |    TOTAL:  10
pass   2 (yz+):   0 found -   3 modified     |    TOTAL:  10
pass   1 (yz-):   2 found -   2 modified     |    TOTAL:  12
pass   2 (yz-):   0 found -   2 modified     |    TOTAL:  12
pass   1 (xz+):   1 found -   1 modified     |    TOTAL:  13
pass   2 (xz+):   0 found -   1 modified     |    TOTAL:  13
pass   1 (xz-):   3 found -   3 modified     |    TOTAL:  16
pass   2 (xz-):   0 found -   3 modified     |    TOTAL:  16
Iteration Number : 1
pass   1 (+++):   0 found -   0 modified     |    TOTAL:   0
pass   1 (+++):   0 found -   0 modified     |    TOTAL:   0
pass   1 (+++):   0 found -   0 modified     |    TOTAL:   0
pass   1 (+++):   0 found -   0 modified     |    TOTAL:   0
Iteration Number : 1
pass   1 (++):   0 found -   0 modified     |    TOTAL:   0
pass   1 (+-):   2 found -   2 modified     |    TOTAL:   2
pass   2 (+-):   0 found -   2 modified     |    TOTAL:   2
pass   1 (--):   4 found -   4 modified     |    TOTAL:   6
pass   2 (--):   0 found -   4 modified     |    TOTAL:   6
pass   1 (-+):   1 found -   1 modified     |    TOTAL:   7
pass   2 (-+):   0 found -   1 modified     |    TOTAL:   7
Iteration Number : 2
pass   1 (xy+):   0 found -   0 modified     |    TOTAL:   0
pass   1 (xy-):   0 found -   0 modified     |    TOTAL:   0
pass   1 (yz+):   0 found -   0 modified     |    TOTAL:   0
pass   1 (yz-):   0 found -   0 modified     |    TOTAL:   0
pass   1 (xz+):   0 found -   0 modified     |    TOTAL:   0
pass   1 (xz-):   0 found -   0 modified     |    TOTAL:   0
Iteration Number : 2
pass   1 (+++):   0 found -   0 modified     |    TOTAL:   0
pass   1 (+++):   0 found -   0 modified     |    TOTAL:   0
pass   1 (+++):   0 found -   0 modified     |    TOTAL:   0
pass   1 (+++):   0 found -   0 modified     |    TOTAL:   0
Iteration Number : 2
pass   1 (++):   0 found -   0 modified     |    TOTAL:   0
pass   1 (+-):   0 found -   0 modified     |    TOTAL:   0
pass   1 (--):   0 found -   0 modified     |    TOTAL:   0
pass   1 (-+):   0 found -   0 modified     |    TOTAL:   0
Total Number of Modified Voxels = 23 (out of 326350: 0.007048)
Ambiguous edge configurations...
mri_pretess done
mri_tessellate ../mri/filled-pretess255.mgz 255 ../surf/lh.orig.nofix
$Id: mri_tessellate.c,v <IP_ADDRESS> 2016/07/26 18:46:38 zkaufman Exp $
$Id: mrisurf.c,v 1.781.2.6 2016/12/27 16:47:14 zkaufman Exp $
slice 50: 62 vertices, 80 faces
slice 60: 3767 vertices, 3991 faces
slice 70: 12903 vertices, 13302 faces
slice 80: 23047 vertices, 23511 faces
slice 90: 33113 vertices, 33588 faces
slice 100: 44483 vertices, 45100 faces
slice 110: 57268 vertices, 57889 faces
slice 120: 69266 vertices, 69901 faces
slice 130: 80948 vertices, 81672 faces
slice 140: 92777 vertices, 93507 faces
slice 150: 103049 vertices, 103825 faces
slice 160: 113567 vertices, 114382 faces
slice 170: 124012 vertices, 124947 faces
slice 180: 133377 vertices, 134284 faces
slice 190: 140405 vertices, 141245 faces
slice 200: 142300 vertices, 142948 faces
slice 210: 142300 vertices, 142948 faces
slice 220: 142300 vertices, 142948 faces
slice 230: 142300 vertices, 142948 faces
slice 240: 142300 vertices, 142948 faces
slice 250: 142300 vertices, 142948 faces
using the conformed surface RAS to save vertex points...
writing ../surf/lh.orig.nofix
using vox2ras matrix:
-1.00000   0.00000   0.00000   128.00000;
0.00000   0.00000   1.00000  -128.00000;
0.00000  -1.00000   0.00000   128.00000;
0.00000   0.00000   0.00000   1.00000;
rm -f ../mri/filled-pretess255.mgz
mris_extract_main_component ../surf/lh.orig.nofix ../surf/lh.orig.nofix
counting number of connected components...
142300 voxel in cpt #1: X=-648 [v=142300,e=428844,f=285896] located at (-34.191639, -6.548222, 19.964750)
For the whole surface: X=-648 [v=142300,e=428844,f=285896]
One single component has been found
nothing to do
done
#--------------------------------------------
#@# Smooth1 lh Wed Mar 13 00:45:58 UTC 2019
/out/freesurfer/sub-082/scripts
mris_smooth -nw -seed 1234 ../surf/lh.orig.nofix ../surf/lh.smoothwm.nofix
setting seed for random number generator to 1234
smoothing surface tessellation for 10 iterations...
smoothing complete - recomputing first and second fundamental forms...

Not saving sulc
mris_inflate utimesec    61.348000
mris_inflate stimesec    0.532000
mris_inflate ru_maxrss   233440
mris_inflate ru_ixrss    0
mris_inflate ru_idrss    0
mris_inflate ru_isrss    0
mris_inflate ru_minflt   57094
mris_inflate ru_majflt   8
mris_inflate ru_nswap    0
mris_inflate ru_inblock  1504
mris_inflate ru_oublock  10040
mris_inflate ru_msgsnd   0
mris_inflate ru_msgrcv   0
mris_inflate ru_nsignals 0
mris_inflate ru_nvcsw    67501
mris_inflate ru_nivcsw   6493
#--------------------------------------------
#@# QSphere lh Wed Mar 13 00:46:16 UTC 2019
/out/freesurfer/sub-082/scripts
mris_sphere -q -seed 1234 ../surf/lh.inflated.nofix ../surf/lh.qsphere.nofix
doing quick spherical unfolding.
setting seed for random number genererator to 1234
$Id: mris_sphere.c,v 1.61 2016/01/20 23:42:15 greve Exp $
$Id: mrisurf.c,v 1.781.2.6 2016/12/27 16:47:14 zkaufman Exp $
reading original vertex positions...
unfolding cortex into spherical form...
surface projected - minimizing metric distortion...
vertex spacing 0.99 +- 0.67 (0.00-->9.62) (max @ vno 86197 --> 86209)
face area 0.03 +- 0.05 (-0.71-->1.12)
== Number of threads available to mris_sphere for OpenMP = 8 ==
scaling brain by 0.371...
inflating to sphere (rms error < 2.00)
000: dt: 0.0000, rms radial error=174.333, avgs=0
005/300: dt: 0.9000, rms radial error=174.076, avgs=0
010/300: dt: 0.9000, rms radial error=173.524, avgs=0
015/300: dt: 0.9000, rms radial error=172.800, avgs=0
020/300: dt: 0.9000, rms radial error=171.976, avgs=0
025/300: dt: 0.9000, rms radial error=171.095, avgs=0
030/300: dt: 0.9000, rms radial error=170.182, avgs=0
035/300: dt: 0.9000, rms radial error=169.251, avgs=0
040/300: dt: 0.9000, rms radial error=168.312, avgs=0
045/300: dt: 0.9000, rms radial error=167.369, avgs=0
050/300: dt: 0.9000, rms radial error=166.427, avgs=0
055/300: dt: 0.9000, rms radial error=165.488, avgs=0
060/300: dt: 0.9000, rms radial error=164.551, avgs=0
065/300: dt: 0.9000, rms radial error=163.618, avgs=0
070/300: dt: 0.9000, rms radial error=162.690, avgs=0
075/300: dt: 0.9000, rms radial error=161.767, avgs=0
080/300: dt: 0.9000, rms radial error=160.848, avgs=0
085/300: dt: 0.9000, rms radial error=159.933, avgs=0
090/300: dt: 0.9000, rms radial error=159.026, avgs=0
095/300: dt: 0.9000, rms radial error=158.123, avgs=0
100/300: dt: 0.9000, rms radial error=157.225, avgs=0
105/300: dt: 0.9000, rms radial error=156.333, avgs=0
110/300: dt: 0.9000, rms radial error=155.450, avgs=0
115/300: dt: 0.9000, rms radial error=154.572, avgs=0
120/300: dt: 0.9000, rms radial error=153.698, avgs=0
125/300: dt: 0.9000, rms radial error=152.830, avgs=0
130/300: dt: 0.9000, rms radial error=151.966, avgs=0
135/300: dt: 0.9000, rms radial error=151.106, avgs=0
140/300: dt: 0.9000, rms radial error=150.252, avgs=0
145/300: dt: 0.9000, rms radial error=149.402, avgs=0
150/300: dt: 0.9000, rms radial error=148.557, avgs=0
155/300: dt: 0.9000, rms radial error=147.716, avgs=0
160/300: dt: 0.9000, rms radial error=146.881, avgs=0
165/300: dt: 0.9000, rms radial error=146.049, avgs=0
170/300: dt: 0.9000, rms radial error=145.223, avgs=0
175/300: dt: 0.9000, rms radial error=144.401, avgs=0
180/300: dt: 0.9000, rms radial error=143.584, avgs=0
185/300: dt: 0.9000, rms radial error=142.772, avgs=0
190/300: dt: 0.9000, rms radial error=141.965, avgs=0
195/300: dt: 0.9000, rms radial error=141.162, avgs=0
200/300: dt: 0.9000, rms radial error=140.363, avgs=0
205/300: dt: 0.9000, rms radial error=139.569, avgs=0
210/300: dt: 0.9000, rms radial error=138.779, avgs=0
215/300: dt: 0.9000, rms radial error=137.994, avgs=0
220/300: dt: 0.9000, rms radial error=137.213, avgs=0
225/300: dt: 0.9000, rms radial error=136.437, avgs=0
230/300: dt: 0.9000, rms radial error=135.665, avgs=0
235/300: dt: 0.9000, rms radial error=134.897, avgs=0
240/300: dt: 0.9000, rms radial error=134.134, avgs=0
245/300: dt: 0.9000, rms radial error=133.375, avgs=0
250/300: dt: 0.9000, rms radial error=132.620, avgs=0
255/300: dt: 0.9000, rms radial error=131.870, avgs=0
260/300: dt: 0.9000, rms radial error=131.123, avgs=0
265/300: dt: 0.9000, rms radial error=130.381, avgs=0
270/300: dt: 0.9000, rms radial error=129.644, avgs=0
275/300: dt: 0.9000, rms radial error=128.910, avgs=0
280/300: dt: 0.9000, rms radial error=128.181, avgs=0
285/300: dt: 0.9000, rms radial error=127.456, avgs=0
290/300: dt: 0.9000, rms radial error=126.734, avgs=0
295/300: dt: 0.9000, rms radial error=126.017, avgs=0
300/300: dt: 0.9000, rms radial error=125.304, avgs=0
spherical inflation complete.
epoch 1 (K=10.0), pass 1, starting sse = 16172.49
taking momentum steps...
taking momentum steps...
taking momentum steps...
pass 1 complete, delta sse/iter = 0.00/10 = 0.00014
epoch 2 (K=40.0), pass 1, starting sse = 2927.15
taking momentum steps...
taking momentum steps...
taking momentum steps...
pass 1 complete, delta sse/iter = 0.01/10 = 0.00065
epoch 3 (K=160.0), pass 1, starting sse = 564.35
taking momentum steps...
taking momentum steps...
taking momentum steps...
pass 1 complete, delta sse/iter = 0.07/11 = 0.00626
epoch 4 (K=640.0), pass 1, starting sse = 167.70
taking momentum steps...
taking momentum steps...
taking momentum steps...
pass 1 complete, delta sse/iter = 0.19/15 = 0.01271
final distance error %24.49
writing spherical brain to ../surf/lh.qsphere.nofix
spherical transformation took 0.02 hours
mris_sphere utimesec    321.468000
mris_sphere stimesec    0.712000
mris_sphere ru_maxrss   233752
mris_sphere ru_ixrss    0
mris_sphere ru_idrss    0
mris_sphere ru_isrss    0
mris_sphere ru_minflt   57134
mris_sphere ru_majflt   16
mris_sphere ru_nswap    0
mris_sphere ru_inblock  1792
mris_sphere ru_oublock  10040
mris_sphere ru_msgsnd   0
mris_sphere ru_msgrcv   0
mris_sphere ru_nsignals 0
mris_sphere ru_nvcsw    82973
mris_sphere ru_nivcsw   33307
FSRUNTIME@ mris_sphere  0.0226 hours 1 threads
#--------------------------------------------
#@# Fix Topology Copy lh Wed Mar 13 00:47:37 UTC 2019
/out/freesurfer/sub-082/scripts
cp ../surf/lh.orig.nofix ../surf/lh.orig
cp ../surf/lh.inflated.nofix ../surf/lh.inflated
#@# Fix Topology lh Wed Mar 13 00:47:37 UTC 2019
mris_fix_topology -rusage /out/freesurfer/sub-082/touch/rusage.mris_fix_topology.lh.dat -mgz -sphere qsphere.nofix -ga -seed 1234 sub-082 lh
reading spherical homeomorphism from 'qsphere.nofix'
using genetic algorithm with optimized parameters
setting seed for random number genererator to 1234

Topology Correction Parameters
retessellation mode:           genetic search
number of patches/generation : 10
number of generations :        10
surface mri loglikelihood coefficient :         1.0
volume mri loglikelihood coefficient :          10.0
normal dot loglikelihood coefficient :          1.0
quadratic curvature loglikelihood coefficient : 1.0
volume resolution :                             2
eliminate vertices during search :              1
initial patch selection :                       1
select all defect vertices :                    0
ordering dependant retessellation:              0
use precomputed edge table :                    0
smooth retessellated patch :                    2
match retessellated patch :                     1
verbose mode :                                  0

INFO: assuming .mgz format
$Id: mris_fix_topology.c,v <IP_ADDRESS> 2016/10/27 22:25:58 zkaufman Exp $
$Id: mrisurf.c,v 1.781.2.6 2016/12/27 16:47:14 zkaufman Exp $
before topology correction, eno=-648 (nv=142300, nf=285896, ne=428844, g=325)
using quasi-homeomorphic spherical map to tessellate cortical surface...
Correction of the Topology
Finding true center and radius of Spherical Surface...done
Surface centered at (0,0,0) with radius 100.0 in 8 iterations
marking ambiguous vertices...
93579 ambiguous faces found in tessellation
segmenting defects...
138 defects found, arbitrating ambiguous regions...
analyzing neighboring defects...
-merging segment 40 into 12
-merging segment 48 into 47
-merging segment 69 into 47
-merging segment 80 into 47
-merging segment 47 into 60
-merging segment 89 into 88
-merging segment 115 into 111
-merging segment 121 into 120
-merging segment 131 into 122
129 defects to be corrected
0 vertices coincident
reading input surface /out/freesurfer/sub-082/surf/lh.qsphere.nofix...
reading brain volume from brain...
reading wm segmentation from wm...
Computing Initial Surface Statistics
-face       loglikelihood: -9.4188  (-4.7094)
-vertex     loglikelihood: -7.4598  (-3.7299)
-normal dot loglikelihood: -3.5471  (-3.5471)
-quad curv  loglikelihood: -6.1984  (-3.0992)
Total Loglikelihood : -26.6240
CORRECTING DEFECT 0 (vertices=24, convex hull=41, v0=258)
After retessellation of defect 0 (v0=258), euler #=-106 (90956,263189,172127) : difference with theory (-126) = -20
CORRECTING DEFECT 1 (vertices=63, convex hull=107, v0=276)
After retessellation of defect 1 (v0=276), euler #=-105 (90987,263329,172237) : difference with theory (-125) = -20
CORRECTING DEFECT 2 (vertices=53, convex hull=91, v0=473)
After retessellation of defect 2 (v0=473), euler #=-104 (91011,263443,172328) : difference with theory (-124) = -20
CORRECTING DEFECT 3 (vertices=246, convex hull=302, v0=706)
After retessellation of defect 3 (v0=706), euler #=-104 (91063,263750,172583) : difference with theory (-123) = -19
CORRECTING DEFECT 4 (vertices=88, convex hull=37, v0=742)
After retessellation of defect 4 (v0=742), euler #=-103 (91070,263786,172613) : difference with theory (-122) = -19
CORRECTING DEFECT 5 (vertices=41, convex hull=52, v0=808)
After retessellation of defect 5 (v0=808), euler #=-102 (91090,263870,172678) : difference with theory (-121) = -19
CORRECTING DEFECT 6 (vertices=26, convex hull=66, v0=1694)
After retessellation of defect 6 (v0=1694), euler #=-101 (91100,263923,172722) : difference with theory (-120) = -19
CORRECTING DEFECT 7 (vertices=52, convex hull=96, v0=2680)
After retessellation of defect 7 (v0=2680), euler #=-100 (91113,263999,172786) : difference with theory (-119) = -19
CORRECTING DEFECT 8 (vertices=183, convex hull=85, v0=3440)
After retessellation of defect 8 (v0=3440), euler #=-99 (91141,264124,172884) : difference with theory (-118) = -19
CORRECTING DEFECT 9 (vertices=96, convex hull=118, v0=3454)
After retessellation of defect 9 (v0=3454), euler #=-98 (91185,264306,173023) : difference with theory (-117) = -19
CORRECTING DEFECT 10 (vertices=58, convex hull=67, v0=3767)
After retessellation of defect 10 (v0=3767), euler #=-97 (91201,264382,173084) : difference with theory (-116) = -19
CORRECTING DEFECT 11 (vertices=36, convex hull=70, v0=5638)
After retessellation of defect 11 (v0=5638), euler #=-96 (91221,264471,173154) : difference with theory (-115) = -19
CORRECTING DEFECT 12 (vertices=471, convex hull=208, v0=5850)
After retessellation of defect 12 (v0=5850), euler #=-94 (91281,264751,173376) : difference with theory (-114) = -20
CORRECTING DEFECT 13 (vertices=35, convex hull=52, v0=6153)
After retessellation of defect 13 (v0=6153), euler #=-93 (91294,264808,173421) : difference with theory (-113) = -20
CORRECTING DEFECT 14 (vertices=41, convex hull=55, v0=6604)
After retessellation of defect 14 (v0=6604), euler #=-92 (91308,264869,173469) : difference with theory (-112) = -20
CORRECTING DEFECT 15 (vertices=454, convex hull=234, v0=6650)
After retessellation of defect 15 (v0=6650), euler #=-91 (91511,265597,173995) : difference with theory (-111) = -20
CORRECTING DEFECT 16 (vertices=5, convex hull=23, v0=6887)
After retessellation of defect 16 (v0=6887), euler #=-90 (91511,265604,174003) : difference with theory (-110) = -20
CORRECTING DEFECT 17 (vertices=462, convex hull=169, v0=7787)
After retessellation of defect 17 (v0=7787), euler #=-89 (91530,265738,174119) : difference with theory (-109) = -20
CORRECTING DEFECT 18 (vertices=26, convex hull=71, v0=8010)
After retessellation of defect 18 (v0=8010), euler #=-88 (91540,265796,174168) : difference with theory (-108) = -20
CORRECTING DEFECT 19 (vertices=110, convex hull=143, v0=8286)
After retessellation of defect 19 (v0=8286), euler #=-87 (91549,265894,174258) : difference with theory (-107) = -20
CORRECTING DEFECT 20 (vertices=73, convex hull=78, v0=8607)
After retessellation of defect 20 (v0=8607), euler #=-87 (91568,265991,174336) : difference with theory (-106) = -19
CORRECTING DEFECT 21 (vertices=39, convex hull=36, v0=8687)
After retessellation of defect 21 (v0=8687), euler #=-86 (91570,266007,174351) : difference with theory (-105) = -19
CORRECTING DEFECT 22 (vertices=219, convex hull=99, v0=9209)
After retessellation of defect 22 (v0=9209), euler #=-85 (91591,266118,174442) : difference with theory (-104) = -19
CORRECTING DEFECT 23 (vertices=23, convex hull=23, v0=9562)
After retessellation of defect 23 (v0=9562), euler #=-84 (91595,266136,174457) : difference with theory (-103) = -19
CORRECTING DEFECT 24 (vertices=160, convex hull=105, v0=9768)
After retessellation of defect 24 (v0=9768), euler #=-83 (91631,266290,174576) : difference with theory (-102) = -19
CORRECTING DEFECT 25 (vertices=45, convex hull=17, v0=9886)
After retessellation of defect 25 (v0=9886), euler #=-82 (91633,266298,174583) : difference with theory (-101) = -19
CORRECTING DEFECT 26 (vertices=6, convex hull=17, v0=10250)
After retessellation of defect 26 (v0=10250), euler #=-81 (91634,266307,174592) : difference with theory (-100) = -19
CORRECTING DEFECT 27 (vertices=16, convex hull=40, v0=10345)
After retessellation of defect 27 (v0=10345), euler #=-80 (91638,266331,174613) : difference with theory (-99) = -19
CORRECTING DEFECT 28 (vertices=40, convex hull=27, v0=10411)
After retessellation of defect 28 (v0=10411), euler #=-79 (91643,266351,174629) : difference with theory (-98) = -19
CORRECTING DEFECT 29 (vertices=378, convex hull=154, v0=12440)
After retessellation of defect 29 (v0=12440), euler #=-78 (91702,266603,174823) : difference with theory (-97) = -19
CORRECTING DEFECT 30 (vertices=104, convex hull=45, v0=13644)
After retessellation of defect 30 (v0=13644), euler #=-77 (91709,266640,174854) : difference with theory (-96) = -19
CORRECTING DEFECT 31 (vertices=15, convex hull=31, v0=13991)
After retessellation of defect 31 (v0=13991), euler #=-76 (91711,266660,174873) : difference with theory (-95) = -19
CORRECTING DEFECT 32 (vertices=56, convex hull=88, v0=14123)
After retessellation of defect 32 (v0=14123), euler #=-75 (91750,266820,174995) : difference with theory (-94) = -19
CORRECTING DEFECT 33 (vertices=173, convex hull=181, v0=14317)
After retessellation of defect 33 (v0=14317), euler #=-74 (91822,267121,175225) : difference with theory (-93) = -19
CORRECTING DEFECT 34 (vertices=24, convex hull=65, v0=14489)
After retessellation of defect 34 (v0=14489), euler #=-73 (91836,267187,175278) : difference with theory (-92) = -19
CORRECTING DEFECT 35 (vertices=5, convex hull=20, v0=14595)
After retessellation of defect 35 (v0=14595), euler #=-72 (91836,267196,175288) : difference with theory (-91) = -19
CORRECTING DEFECT 36 (vertices=77, convex hull=124, v0=14954)
After retessellation of defect 36 (v0=14954), euler #=-71 (91856,267306,175379) : difference with theory (-90) = -19
CORRECTING DEFECT 37 (vertices=18, convex hull=16, v0=15106)
After retessellation of defect 37 (v0=15106), euler #=-70 (91857,267315,175388) : difference with theory (-89) = -19
CORRECTING DEFECT 38 (vertices=309, convex hull=190, v0=15605)
After retessellation of defect 38 (v0=15605), euler #=-69 (91963,267725,175693) : difference with theory (-88) = -19
CORRECTING DEFECT 39 (vertices=65, convex hull=100, v0=16317)
After retessellation of defect 39 (v0=16317), euler #=-68 (91977,267809,175764) : difference with theory (-87) = -19
CORRECTING DEFECT 40 (vertices=138, convex hull=128, v0=17513)
After retessellation of defect 40 (v0=17513), euler #=-67 (92041,268058,175950) : difference with theory (-86) = -19
CORRECTING DEFECT 41 (vertices=40, convex hull=26, v0=17833)
After retessellation of defect 41 (v0=17833), euler #=-66 (92045,268077,175966) : difference with theory (-85) = -19
CORRECTING DEFECT 42 (vertices=96, convex hull=37, v0=18837)
After retessellation of defect 42 (v0=18837), euler #=-65 (92050,268106,175991) : difference with theory (-84) = -19
CORRECTING DEFECT 43 (vertices=26, convex hull=42, v0=18950)
After retessellation of defect 43 (v0=18950), euler #=-64 (92061,268155,176030) : difference with theory (-83) = -19
CORRECTING DEFECT 44 (vertices=59, convex hull=34, v0=20822)
After retessellation of defect 44 (v0=20822), euler #=-63 (92066,268183,176054) : difference with theory (-82) = -19
CORRECTING DEFECT 45 (vertices=12, convex hull=23, v0=20962)
After retessellation of defect 45 (v0=20962), euler #=-62 (92067,268193,176064) : difference with theory (-81) = -19
CORRECTING DEFECT 46 (vertices=16, convex hull=17, v0=21848)
After retessellation of defect 46 (v0=21848), euler #=-61 (92069,268202,176072) : difference with theory (-80) = -19
CORRECTING DEFECT 47 (vertices=79, convex hull=74, v0=22047)
After retessellation of defect 47 (v0=22047), euler #=-60 (92098,268325,176167) : difference with theory (-79) = -19
CORRECTING DEFECT 48 (vertices=179, convex hull=134, v0=22512)
After retessellation of defect 48 (v0=22512), euler #=-59 (92169,268596,176368) : difference with theory (-78) = -19
CORRECTING DEFECT 49 (vertices=28, convex hull=39, v0=23908)
After retessellation of defect 49 (v0=23908), euler #=-58 (92173,268620,176389) : difference with theory (-77) = -19
CORRECTING DEFECT 50 (vertices=7, convex hull=19, v0=23968)
After retessellation of defect 50 (v0=23968), euler #=-57 (92174,268625,176394) : difference with theory (-76) = -19
CORRECTING DEFECT 51 (vertices=26, convex hull=24, v0=24023)
After retessellation of defect 51 (v0=24023), euler #=-56 (92176,268643,176411) : difference with theory (-75) = -19
CORRECTING DEFECT 52 (vertices=119, convex hull=130, v0=25659)
After retessellation of defect 52 (v0=25659), euler #=-55 (92224,268848,176569) : difference with theory (-74) = -19
CORRECTING DEFECT 53 (vertices=29, convex hull=53, v0=26879)
After retessellation of defect 53 (v0=26879), euler #=-54 (92241,268921,176626) : difference with theory (-73) = -19
CORRECTING DEFECT 54 (vertices=35, convex hull=70, v0=27714)
After retessellation of defect 54 (v0=27714), euler #=-53 (92252,268979,176674) : difference with theory (-72) = -19
CORRECTING DEFECT 55 (vertices=17, convex hull=27, v0=27804)
After retessellation of defect 55 (v0=27804), euler #=-52 (92253,268992,176687) : difference with theory (-71) = -19
CORRECTING DEFECT 56 (vertices=37, convex hull=30, v0=28972)
After retessellation of defect 56 (v0=28972), euler #=-51 (92257,269014,176706) : difference with theory (-70) = -19
CORRECTING DEFECT 57 (vertices=9216, convex hull=2162, v0=29043)
XL defect detected...
After retessellation of defect 57 (v0=29043), euler #=-52 (94054,275609,181503) : difference with theory (-69) = -17
CORRECTING DEFECT 58 (vertices=48, convex hull=42, v0=29215)
After retessellation of defect 58 (v0=29215), euler #=-51 (94060,275643,181532) : difference with theory (-68) = -17
CORRECTING DEFECT 59 (vertices=27, convex hull=49, v0=29469)
After retessellation of defect 59 (v0=29469), euler #=-50 (94069,275691,181572) : difference with theory (-67) = -17
CORRECTING DEFECT 60 (vertices=33, convex hull=36, v0=29574)
After retessellation of defect 60 (v0=29574), euler #=-49 (94072,275712,181591) : difference with theory (-66) = -17
CORRECTING DEFECT 61 (vertices=31, convex hull=51, v0=30292)
After retessellation of defect 61 (v0=30292), euler #=-48 (94085,275773,181640) : difference with theory (-65) = -17
CORRECTING DEFECT 62 (vertices=27, convex hull=56, v0=31967)
After retessellation of defect 62 (v0=31967), euler #=-47 (94094,275824,181683) : difference with theory (-64) = -17
CORRECTING DEFECT 63 (vertices=485, convex hull=96, v0=32539)
After retessellation of defect 63 (v0=32539), euler #=-46 (94110,275917,181761) : difference with theory (-63) = -17
CORRECTING DEFECT 64 (vertices=17, convex hull=16, v0=32619)
After retessellation of defect 64 (v0=32619), euler #=-45 (94111,275926,181770) : difference with theory (-62) = -17
CORRECTING DEFECT 65 (vertices=32, convex hull=71, v0=33389)
After retessellation of defect 65 (v0=33389), euler #=-44 (94131,276016,181841) : difference with theory (-61) = -17
CORRECTING DEFECT 66 (vertices=50, convex hull=100, v0=37554)
After retessellation of defect 66 (v0=37554), euler #=-43 (94164,276155,181948) : difference with theory (-60) = -17
CORRECTING DEFECT 67 (vertices=93, convex hull=138, v0=38621)
After retessellation of defect 67 (v0=38621), euler #=-42 (94195,276306,182069) : difference with theory (-59) = -17
CORRECTING DEFECT 68 (vertices=4806, convex hull=741, v0=39136)
XL defect detected...
After retessellation of defect 68 (v0=39136), euler #=-41 (94526,277712,183145) : difference with theory (-58) = -17
CORRECTING DEFECT 69 (vertices=57, convex hull=33, v0=40900)
After retessellation of defect 69 (v0=40900), euler #=-40 (94534,277747,183173) : difference with theory (-57) = -17
CORRECTING DEFECT 70 (vertices=1434, convex hull=643, v0=41048)
XL defect detected...
After retessellation of defect 70 (v0=41048), euler #=-42 (94956,279387,184389) : difference with theory (-56) = -14
CORRECTING DEFECT 71 (vertices=20, convex hull=22, v0=44873)
After retessellation of defect 71 (v0=44873), euler #=-41 (94957,279397,184399) : difference with theory (-55) = -14
CORRECTING DEFECT 72 (vertices=300, convex hull=51, v0=46288)
After retessellation of defect 72 (v0=46288), euler #=-40 (94995,279531,184496) : difference with theory (-54) = -14
CORRECTING DEFECT 73 (vertices=71, convex hull=86, v0=47177)
After retessellation of defect 73 (v0=47177), euler #=-39 (95026,279658,184593) : difference with theory (-53) = -14
CORRECTING DEFECT 74 (vertices=55, convex hull=74, v0=47526)
After retessellation of defect 74 (v0=47526), euler #=-38 (95053,279770,184679) : difference with theory (-52) = -14
CORRECTING DEFECT 75 (vertices=44, convex hull=35, v0=48035)
After retessellation of defect 75 (v0=48035), euler #=-37 (95058,279799,184704) : difference with theory (-51) = -14
CORRECTING DEFECT 76 (vertices=7, convex hull=10, v0=52174)
After retessellation of defect 76 (v0=52174), euler #=-36 (95059,279803,184708) : difference with theory (-50) = -14
CORRECTING DEFECT 77 (vertices=102, convex hull=134, v0=55294)
After retessellation of defect 77 (v0=55294), euler #=-35 (95115,280025,184875) : difference with theory (-49) = -14
CORRECTING DEFECT 78 (vertices=23, convex hull=34, v0=59013)
After retessellation of defect 78 (v0=59013), euler #=-34 (95120,280053,184899) : difference with theory (-48) = -14
CORRECTING DEFECT 79 (vertices=9, convex hull=24, v0=59499)
After retessellation of defect 79 (v0=59499), euler #=-33 (95121,280063,184909) : difference with theory (-47) = -14
CORRECTING DEFECT 80 (vertices=169, convex hull=87, v0=60059)
After retessellation of defect 80 (v0=60059), euler #=-32 (95157,280217,185028) : difference with theory (-46) = -14
CORRECTING DEFECT 81 (vertices=72, convex hull=90, v0=62039)
After retessellation of defect 81 (v0=62039), euler #=-31 (95202,280394,185161) : difference with theory (-45) = -14
CORRECTING DEFECT 82 (vertices=79, convex hull=104, v0=66191)
After retessellation of defect 82 (v0=66191), euler #=-30 (95235,280538,185273) : difference with theory (-44) = -14
CORRECTING DEFECT 83 (vertices=230, convex hull=200, v0=67494)
After retessellation of defect 83 (v0=67494), euler #=-28 (95325,280903,185550) : difference with theory (-43) = -15
CORRECTING DEFECT 84 (vertices=1901, convex hull=1206, v0=69852)
XL defect detected...
After retessellation of defect 84 (v0=69852), euler #=-31 (96202,284211,187978) : difference with theory (-42) = -11
CORRECTING DEFECT 85 (vertices=27, convex hull=34, v0=70403)
After retessellation of defect 85 (v0=70403), euler #=-30 (96204,284229,187995) : difference with theory (-41) = -11
CORRECTING DEFECT 86 (vertices=72, convex hull=79, v0=71987)
After retessellation of defect 86 (v0=71987), euler #=-30 (96238,284366,188098) : difference with theory (-40) = -10
CORRECTING DEFECT 87 (vertices=135, convex hull=143, v0=72089)
After retessellation of defect 87 (v0=72089), euler #=-29 (96303,284625,188293) : difference with theory (-39) = -10
CORRECTING DEFECT 88 (vertices=29, convex hull=18, v0=74068)
After retessellation of defect 88 (v0=74068), euler #=-28 (96306,284639,188305) : difference with theory (-38) = -10
CORRECTING DEFECT 89 (vertices=32, convex hull=29, v0=75647)
After retessellation of defect 89 (v0=75647), euler #=-27 (96308,284651,188316) : difference with theory (-37) = -10
CORRECTING DEFECT 90 (vertices=32, convex hull=57, v0=75906)
After retessellation of defect 90 (v0=75906), euler #=-26 (96322,284716,188368) : difference with theory (-36) = -10
CORRECTING DEFECT 91 (vertices=8, convex hull=20, v0=76970)
After retessellation of defect 91 (v0=76970), euler #=-25 (96322,284722,188375) : difference with theory (-35) = -10
CORRECTING DEFECT 92 (vertices=85, convex hull=91, v0=78508)
After retessellation of defect 92 (v0=78508), euler #=-24 (96353,284860,188483) : difference with theory (-34) = -10
CORRECTING DEFECT 93 (vertices=44, convex hull=99, v0=79855)
After retessellation of defect 93 (v0=79855), euler #=-23 (96385,285001,188593) : difference with theory (-33) = -10
CORRECTING DEFECT 94 (vertices=15, convex hull=30, v0=80389)
After retessellation of defect 94 (v0=80389), euler #=-22 (96386,285015,188607) : difference with theory (-32) = -10
CORRECTING DEFECT 95 (vertices=47, convex hull=87, v0=81228)
After retessellation of defect 95 (v0=81228), euler #=-21 (96404,285107,188682) : difference with theory (-31) = -10
CORRECTING DEFECT 96 (vertices=7, convex hull=26, v0=81300)
After retessellation of defect 96 (v0=81300), euler #=-20 (96405,285122,188697) : difference with theory (-30) = -10
CORRECTING DEFECT 97 (vertices=12, convex hull=24, v0=82642)
After retessellation of defect 97 (v0=82642), euler #=-19 (96407,285135,188709) : difference with theory (-29) = -10
CORRECTING DEFECT 98 (vertices=48, convex hull=66, v0=83044)
After retessellation of defect 98 (v0=83044), euler #=-18 (96429,285231,188784) : difference with theory (-28) = -10
CORRECTING DEFECT 99 (vertices=2763, convex hull=868, v0=83269)
XL defect detected...
After retessellation of defect 99 (v0=83269), euler #=-19 (96613,286287,189655) : difference with theory (-27) = -8
CORRECTING DEFECT 100 (vertices=1362, convex hull=647, v0=83865)
XL defect detected...
After retessellation of defect 100 (v0=83865), euler #=-18 (97020,287864,190826) : difference with theory (-26) = -8
CORRECTING DEFECT 101 (vertices=23, convex hull=19, v0=83888)
After retessellation of defect 101 (v0=83888), euler #=-17 (97023,287878,190838) : difference with theory (-25) = -8
CORRECTING DEFECT 102 (vertices=56, convex hull=80, v0=90952)
After retessellation of defect 102 (v0=90952), euler #=-16 (97059,288019,190944) : difference with theory (-24) = -8
CORRECTING DEFECT 103 (vertices=41, convex hull=33, v0=91717)
After retessellation of defect 103 (v0=91717), euler #=-15 (97063,288041,190963) : difference with theory (-23) = -8
CORRECTING DEFECT 104 (vertices=6, convex hull=24, v0=93579)
After retessellation of defect 104 (v0=93579), euler #=-14 (97064,288051,190973) : difference with theory (-22) = -8
CORRECTING DEFECT 105 (vertices=139, convex hull=154, v0=94691)
After retessellation of defect 105 (v0=94691), euler #=-12 (97094,288220,191114) : difference with theory (-21) = -9
CORRECTING DEFECT 106 (vertices=6, convex hull=9, v0=94885)
After retessellation of defect 106 (v0=94885), euler #=-11 (97094,288222,191117) : difference with theory (-20) = -9
CORRECTING DEFECT 107 (vertices=116, convex hull=122, v0=96030)
After retessellation of defect 107 (v0=96030), euler #=-10 (97116,288345,191219) : difference with theory (-19) = -9
CORRECTING DEFECT 108 (vertices=20, convex hull=64, v0=96112)
After retessellation of defect 108 (v0=96112), euler #=-9 (97125,288397,191263) : difference with theory (-18) = -9
CORRECTING DEFECT 109 (vertices=75, convex hull=85, v0=97088)
After retessellation of defect 109 (v0=97088), euler #=-8 (97174,288581,191399) : difference with theory (-17) = -9
CORRECTING DEFECT 110 (vertices=11060, convex hull=2620, v0=100742)
XL defect detected...
After retessellation of defect 110 (v0=100742), euler #=-17 (98292,293485,195176) : difference with theory (-16) = 1
CORRECTING DEFECT 111 (vertices=28, convex hull=18, v0=101328)
After retessellation of defect 111 (v0=101328), euler #=-16 (98293,293495,195186) : difference with theory (-15) = 1
CORRECTING DEFECT 112 (vertices=43, convex hull=63, v0=102767)
After retessellation of defect 112 (v0=102767), euler #=-15 (98305,293557,195237) : difference with theory (-14) = 1
CORRECTING DEFECT 113 (vertices=121, convex hull=102, v0=102977)
After retessellation of defect 113 (v0=102977), euler #=-13 (98333,293696,195350) : difference with theory (-13) = 0
CORRECTING DEFECT 114 (vertices=9172, convex hull=1599, v0=104289)
XL defect detected...
After retessellation of defect 114 (v0=104289), euler #=-12 (99286,297422,198124) : difference with theory (-12) = 0
CORRECTING DEFECT 115 (vertices=68, convex hull=35, v0=105976)
After retessellation of defect 115 (v0=105976), euler #=-11 (99293,297456,198152) : difference with theory (-11) = 0
CORRECTING DEFECT 116 (vertices=133, convex hull=141, v0=106462)
After retessellation of defect 116 (v0=106462), euler #=-10 (99334,297641,198297) : difference with theory (-10) = 0
CORRECTING DEFECT 117 (vertices=31, convex hull=25, v0=106584)
After retessellation of defect 117 (v0=106584), euler #=-9 (99336,297662,198317) : difference with theory (-9) = 0
CORRECTING DEFECT 118 (vertices=34, convex hull=75, v0=106846)
After retessellation of defect 118 (v0=106846), euler #=-8 (99358,297759,198393) : difference with theory (-8) = 0
CORRECTING DEFECT 119 (vertices=154, convex hull=121, v0=107325)
After retessellation of defect 119 (v0=107325), euler #=-7 (99416,297987,198564) : difference with theory (-7) = 0
CORRECTING DEFECT 120 (vertices=90, convex hull=116, v0=111922)
After retessellation of defect 120 (v0=111922), euler #=-6 (99474,298207,198727) : difference with theory (-6) = 0
CORRECTING DEFECT 121 (vertices=153, convex hull=126, v0=112812)
After retessellation of defect 121 (v0=112812), euler #=-5 (99511,298375,198859) : difference with theory (-5) = 0
CORRECTING DEFECT 122 (vertices=11, convex hull=20, v0=112945)
After retessellation of defect 122 (v0=112945), euler #=-4 (99512,298384,198868) : difference with theory (-4) = 0
CORRECTING DEFECT 123 (vertices=93, convex hull=153, v0=117579)
After retessellation of defect 123 (v0=117579), euler #=-3 (99571,298636,199062) : difference with theory (-3) = 0
CORRECTING DEFECT 124 (vertices=22, convex hull=21, v0=124719)
After retessellation of defect 124 (v0=124719), euler #=-2 (99574,298650,199074) : difference with theory (-2) = 0
CORRECTING DEFECT 125 (vertices=9, convex hull=19, v0=124934)
After retessellation of defect 125 (v0=124934), euler #=-1 (99575,298659,199083) : difference with theory (-1) = 0
CORRECTING DEFECT 126 (vertices=6, convex hull=24, v0=129847)
After retessellation of defect 126 (v0=129847), euler #=0 (99576,298671,199095) : difference with theory (0) = 0
CORRECTING DEFECT 127 (vertices=58, convex hull=107, v0=133275)
After retessellation of defect 127 (v0=133275), euler #=1 (99591,298759,199169) : difference with theory (1) = 0
CORRECTING DEFECT 128 (vertices=20, convex hull=25, v0=135771)
After retessellation of defect 128 (v0=135771), euler #=2 (99592,298770,199180) : difference with theory (2) = 0
computing original vertex metric properties...
storing new metric properties...
computing tessellation statistics...
vertex spacing 0.93 +- 0.50 (0.02-->19.57) (max @ vno 81424 --> 88580)
face area 0.00 +- 0.00 (0.00-->0.00)
performing soap bubble on retessellated vertices for 0 iterations...
vertex spacing 0.93 +- 0.50 (0.02-->19.57) (max @ vno 81424 --> 88580)
face area 0.00 +- 0.00 (0.00-->0.00)
tessellation finished, orienting corrected surface...
438 mutations (36.0%), 777 crossovers (64.0%), 6957 vertices were eliminated
building final representation...
42708 vertices and 0 faces have been removed from triangulation
after topology correction, eno=2 (nv=99592, nf=199180, ne=298770, g=0)
writing corrected surface to /out/freesurfer/sub-082/surf/lh.orig...
MRISwrite(/out/freesurfer/sub-082/surf/lh.orig): can't create file
0 defective edges
removing intersecting faces
000: 4042 intersecting
001: 306 intersecting
002: 140 intersecting
003: 123 intersecting
004: 87 intersecting
005: 68 intersecting
006: 62 intersecting
007: 45 intersecting
008: 20 intersecting
No such file or directory
0.000 % of the vertices (0 vertices) exhibit an orientation change
topology fixing took 1112.6 minutes
mris_fix_topology utimesec    66722.916000
mris_fix_topology stimesec    17.384000
mris_fix_topology ru_maxrss   1589096
mris_fix_topology ru_ixrss    0
mris_fix_topology ru_idrss    0
mris_fix_topology ru_isrss    0
mris_fix_topology ru_minflt   12333608
mris_fix_topology ru_majflt   25687
mris_fix_topology ru_nswap    0
mris_fix_topology ru_inblock  428464
mris_fix_topology ru_oublock  3344
mris_fix_topology ru_msgsnd   0
mris_fix_topology ru_msgrcv   0
mris_fix_topology ru_nsignals 0
mris_fix_topology ru_nvcsw    33822
mris_fix_topology ru_nivcsw   5602139
FSRUNTIME@ mris_fix_topology lh 18.5441 hours 1 threads
tee: /out/freesurfer/sub-082/scripts/recon-all-lh.log: No such file or directory
mris_euler_number ../surf/lh.orig
Abort (core dumped)
Linux b16d469ba965 4.4.0-141-generic #167~14.04.1-Ubuntu SMP Mon Dec 10 13:20:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
tee: /out/freesurfer/sub-082/scripts/recon-all-lh.log: No such file or directory
tee: /out/freesurfer/sub-082/scripts/recon-all-lh.log: No such file or directory
recon-all -s sub-082 exited with ERRORS at Wed Mar 13 19:20:18 UTC 2019
tee: /out/freesurfer/sub-082/scripts/recon-all-lh.log: No such file or directory
For more details, see the log file /out/freesurfer/sub-082/scripts/recon-all-lh.log
To report a problem, see http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
Standard error:
tee: /out/freesurfer/sub-082/scripts/recon-all-lh.cmd: No such file or directory
tee: /out/freesurfer/sub-082/scripts/recon-all-lh.log: No such file or directory
tee: /out/freesurfer/sub-082/scripts/recon-all-status-lh.log: No such file or directory
tee: /out/freesurfer/sub-082/scripts/recon-all-status-lh.log: No such file or directory
tee: /out/freesurfer/sub-082/scripts/recon-all-status-lh.log: No such file or directory
tee: /out/freesurfer/sub-082/scripts/recon-all-status-lh.log: No such file or directory
tee: /out/freesurfer/sub-082/scripts/recon-all-lh.log: No such file or directory
/out/freesurfer/sub-082/scripts/recon-all.error: No such file or directory.
Return code: 1

This looks like a filesystem issue. Did you run out of space or hit a quota during your run? It also looks like you're running in Docker.  And what OS are you running from?

Yes, I run it using ubuntu docker on 128G workstation.
sudo docker run -ti --rm -v /home/Data/doc_data/bids:/data:ro -v /home/Data/doc_data/out:/out -v /home/Desktop/script/license.txt:/opt/freesurfer/license.txt  poldracklab/fmriprep:latest /data /out participant --use-syn-sdc --bold2t1w-dof 12 --template-resampling-grid 2mm -participant_label sub-034

Thanks. So first I'll just note that the following lines make me think it's a filesystem issue:
writing corrected surface to /out/freesurfer/sub-082/surf/lh.orig...
MRISwrite(/out/freesurfer/sub-082/surf/lh.orig): can't create file
...
tee: /out/freesurfer/sub-082/scripts/recon-all-lh.log: No such file or directory
...
/out/freesurfer/sub-082/scripts/recon-all.error: No such file or directory.

The first could be an issue of a full filesystem, but the latter two are unlikely to be missing files, as they should have been written to before, and there's no evidence of that until the very end. This is consistent with a disconnection.
What kind of filesystem is /home/Data/doc_data hosted on? If it's an NFS mount or removal drive, I would guess that what happened is a connection error at an inconvenient time. I would simply make sure it's reconnected and retry. It's also possible that there was some kind of filesystem-related glitch in Docker that would appear to be a disconnection from the perspective of a job running in Docker. Again the solution would probably be to retry.
If it's a typical Linux filesystem, then I would consider whether you hit a quota or filled up the disk. quota and df will be useful tools here. If it's full, then the solution would be to clear up space or increase your quota (for root, the quota issue is very unlikely).
I would check your /home/Data/doc_data/out/freesurfer/sub-082/scripts/ directory and remove any files that have IsRunning in the name. The odds are good that the script was unable to remove them when it was shutting down. If they're still there when you attempt to run again, then recon-all will quit.

As an aside, I would recommend using a specific version, rather than poldracklab/fmriprep:latest. As long as you don't pull a new version, it will be fine, but from the perspective of reproducibility, it's a good habit to specify the exact version. (It also makes it easier for us to associate versions with issues.)

Thanks a lot! I resolved this problem by running those subjects on freesurfer rather than on docker. Then    putting the results into original place, the docker run Successfully. Thank you for your time.

Great! Glad to hear it.


feat: update container labels

What this PR does / why we need it:

Fixes legacy container warnings

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Which issue/s this PR fixes

How Has This Been Tested?

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I've read the CONTRIBUTION guide
[ ] I have added CI tests to cover my changes.
[ ] All new and existing tests passed.

/code pr


Prometheus getting OOM killed

What did you do?
Deployed Prometheus 2.10.0 using https://github.com/helm/charts/tree/master/stable/prometheus
What did you expect to see?
Prometheus server up and running
What did you see instead? Under which circumstances?
Within 5 minutes RAM usage exceeds 80GB and gets OOM killed
Environment

Number of Head series:
3M

Number of Head chunk:
3M

Prometheus version:
2.10.0

Questions

Is this RAM usage expected for the above mentioned head series ?
One of the labels (source IP) in a metric has high cardinality which is not needed. When I tried to drop the label I get the error "Error on ingesting out-of-order samples" num_dropped". Is there a way to merge the time series under source_ip label before ingestion so that head series count will not explode.
Any other suggestions most welcome.

I have already removed the unwanted targets and metrics.

Hello !
Since the version v3.10, Prometheus released many bufixes and optimizations. So it's totally worth to upgrade Prometheus, and that would be my first advise here

Deployed Prometheus 2.10.0 using https://github.com/helm/charts/tree/master/stable/prometheus

You should probably also take a look at https://github.com/prometheus-community/helm-charts. That's where you have the latest version of the helm chart for Prometheus.

Thanks. As advised I used the new helm chart and Prometheus is upgraded to 2.26.0. Memory usage is reduced a little. It is ~68GB for 2.6M series. Would you please confirm if this is expected ? Any optimization to decrease the memory ?

I have attached TSDB status for more details.

Can you give more details about your Prometheus configuration ? Like how many days do you keep the data ?
In case you are scraping too many timeseries, an idea would be to split the scraping in multiple different Prometheus.
Then you will probably need Thanos to be able to query and aggregate the data across the different Prometheus.

Thanks for the suggestion on Thanos. Currently we have two Prometheus - one for Istio http metrics and another for application metrics. Splitting further might add additional maintenance over ahead. We want to first explore the alternatives without splitting.
retention: "3d"
scrape_interval: 30s
scrape_timeout: 10s
evaluation_interval: 1m

I am able to remove few more unwanted timeseries and reduce the # Head series from 2.6M to 1.6M. But not much change in the memory usage - 70G (from kubectl top pods).
To further understand, I dropped all the metrics from the scrape targets (in metric_relabel_configs -> keep only for an unavailable label value). # Head series reduced to 15K (all internal to Prometheus). Screenshots below. Memory usage was still high at 45G. This explains why there is not much reduction in memory usage earlier.

We believed memory usage depends mostly on number of head series count. It may not be the case here ?
Isnt the memory usage high for no metrics ingested and just scraping the targets (from ~3000 pods) ?
Can you please help us understand what is going wrong here ? How to optimize ?

Please let me know if any other details needed.

More updates. Upgraded to Prometheus v2.31.1. No improvements in Memory usage.
Go profiling using command go tool pprof -symbolize=remote -inuse_space "http://<prom-server>/debug/pprof/heap" showed 38G which is only ~40% of the 90G shown in kubectl top pods. Major consumption is for textParse (*PromParser) metrics: 20G. I guess this is the memory used for the time series ?
I tried to reduce the cache memory but storage.local.target-heap-size is deprecated from 2.X.
What could be accounting for the remaining 52G ? Memory leak ? Is there a way to figure out what could be the culprit ? Any help will be much appreciated.

I'm not really an expert around this particular topic unfortunately :/.
From my point of view, I fear you will have to split the targets across more Prometheus.
Perhaps @roidelapluie would you have more ideas ?

Another way around would be to see how much targets you are dropping in the discovery. I think it impacts more the CPU side and not really the memory, but can another way to optimize.
One day in my company we had an issue with the k8s discovery where we actually asked to Prometheus to get all the pods from the API regardless the different namespace, and then we asked to Prometheus to filter them using relabeling configuration.
It cost a lot of CPUs on our side (and probably memories as well). So a way to avoid it was to list the namespaces Prometheus should use when querying the k8s API.

Thanks for the suggestions. We have already listed the interested namespaces in kubernetes_sd_configs. In "/service_discovery" I see 3000/10000 active targets. I guess the dropped 7000 are targets (containers, ports) generated from containers other than istio-proxy and dropped via relabel_configs.
go_memstats_heap_inuse_bytes (actual memory used) = 45G.
go_memstats_heap_idle_bytes - go_memstats_heap_released_bytes (unused memory not yet released to OS) = 25G.
This confirms 70G memory is actually consumed. But pprof inuse_space accounts only for 30G (metric: 17G). I was expecting pprof inuse_space (30G) to match with go_memstats_heap_inuse_bytes (45G). It will be helpful to understand where the missing 15G is accounted for.


Allow to stop/restart HikariPool.

In order to create a checkpoint using CRaC it is required that all open connections are closed before taking the snapshot.
On resuming from the a captured checkpoint the pool needs to be restarted.
The current arrangement allows to suspend the pool but does not guarantee connections are closed. Also invoking softEvictConnections before suspending the pool may leave connections open resulting in jdk.internal.crac.impl.CheckpointOpenSocketException preventing the checkpoint from being created.
It is however possible to call HikariPool#shutdown() to close open connections, but there is (unless I'm missing something) no counterpart that would allow to restart the pool after being closed as outlined below
class HikariDataSourceResource implements org.crac.Resource {

	HikariDataSource dataSource;
	// ...

	@Override
	public void beforeCheckpoint(Context<? extends Resource> context) throws Exception {
		if (dataSource.getHikariPoolMXBean() instanceof HikariPool pool) {
			pool.shutdown(); // <-- make sure to close all connections
		}
	}
	@Override
	public void afterRestore(Context<? extends Resource> context) throws Exception {
		if (dataSource.getHikariPoolMXBean() instanceof HikariPool pool) {
			pool.resume(); // <-- restart the pool
		}
	}
}

It would be possible to create a new instance of HikariDataSource on restore but that would potentially break existing references to the DataSource, so  I'm looking for a solution closer to what suspending currently offers.

After a bit more investigation it seems the problem we're facing is that after calling softEvictConnections the pool immediately reports zero open/idle connections whereas some of the underlying sockets are still open and it takes about 500 ms (on my machine) till all of them are closed.

2023-06-21T09:45:11.605Z TRACE 129 - Sockets before softEvictConnections():
	Socket[addr=host.docker.internal,port=3306,localport=41884]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41886]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41900]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41908]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41922]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41924]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41926]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41934]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41936]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41942]: connected
// ...
2023-06-21T09:45:11.638Z  INFO 129 - suspending HikariPool HikariPool-1
2023-06-21T09:45:11.640Z  INFO 129 - evicting HikariPool HikariPool-1 connections
HikariPool-1 connections:
	total: 0
	active: 0
	idle: 0
// ...
2023-06-21T09:45:11.641Z  TRACE 129 - Sockets after softEvictConnections():
	Socket[addr=host.docker.internal,port=3306,localport=41884]: closed
	Socket[addr=host.docker.internal,port=3306,localport=41886]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41900]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41908]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41922]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41924]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41926]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41934]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41936]: connected
	Socket[addr=host.docker.internal,port=3306,localport=41942]: connected

Is there a way to reliably tell when all connections are closed?

this is because the HikarPool's config ,  you can see the code in com.zaxxer.hikari.pool.HikariPool.PoolEntryCreator . when create a HikariPool, it will create a PoolEntryCreater , whitch will check is there need a new connection in fixed rate  .  after you use softEvictConnections close the pool connection , the poolentryCreater may be create a new one   , then checkpont failed .

I'm currently investigating why my Spring Boot app is still trying to use an invalid connection after restore although HikariCheckpointRestoreLifecycle reports to have closed all connections:
INFO 8 --- [ main] o.s.b.j.HikariCheckpointRestoreLifecycle : Evicting Hikari connections
DEBUG 8 --- [ main] o.s.b.j.HikariCheckpointRestoreLifecycle : Waiting for Hikari connections to be closed
DEBUG 8 --- [ main] o.s.b.j.HikariCheckpointRestoreLifecycle : Hikari connections closed
--- RESTORE ---
INFO 8 --- [           main] o.s.c.support.DefaultLifecycleProcessor  : Restarting Spring-managed lifecycle beans after JVM restore
INFO 8 --- [           main] o.s.c.support.DefaultLifecycleProcessor  : Spring-managed lifecycle restart completed (restored JVM running for -1 ms)
WARN 8 --- [           main] com.zaxxer.hikari.pool.PoolBase          : HikariPool-1 - Failed to validate connection org.postgresql.jdbc.PgConnection@2c6a3f77 (This connection has been closed.). Possibly consider using a shorter maxLifetime value.

So +1 on having a proper shutdown method.


Add Basic English as alternative to the Minilex

https://en.wiktionary.org/wiki/Appendix:Basic_English_word_list#:~:text=come%2C get%2C give%2C go,I%2C he%2C you%2C who

Since Basic English might be a pretty large jump comparing to the Minilex, it would be good to break it down into several levels, built on the top of each other.
Each level can be like follows:

+100/200 words
the words are picked by usage frequency

Frequency for English words can be downloaded from:

https://frequencylist.com/ -- 5000 words
https://www.kaggle.com/datasets/rtatman/english-word-frequency -- 333,333 words

Related (but perhaps requires a separate issue):

Consider a "nanolex": subset of words from the Minilex, that includes 100 words according to their usage frequency. This can be more useful for absolute beginners, for whom the vocabulary of minilex can be rather challenging.


fix(type): avoid ThisType incompatibility of the nextTick function

Fix: #3599
When the component has the emits options, the ThisType of the nextTick function may be incompatible with the component instance, e.g.
  defineComponent({
    emits: ['click']
  })

The $emit's type of the component instance is:
(event: "click", n: number) => void

But the $emit's type of ThisType of $nextTick is:
(event: string, n: number) => void

So there is a type incompatibility 'Type 'string' is not assignable to type '"click"''. At first, I tried to unify their types, but I failed, maybe @pikax can give it another try.

@pikax will give a new PR


zoekt: 3.7.2-2-unstable-2024-09-19 -> 3.7.2-2-unstable-2024-10-01

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for zoekt is: Fast trigram based code search
meta.homepage for zoekt is: https://github.com/sourcegraph/zoekt
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.7.2-2-unstable-2024-10-01 in filename of file in /nix/store/chyk3vqk4rjjsdyh8afqkfsgcdrnr7v9-zoekt-3.7.2-2-unstable-2024-10-01

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

zoekt

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/chyk3vqk4rjjsdyh8afqkfsgcdrnr7v9-zoekt-3.7.2-2-unstable-2024-10-01 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A zoekt https://github.com/r-ryantm/nixpkgs/archive/8dc6ec42dda2c72e78d052290b6857b24b153141.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/8dc6ec42dda2c72e78d052290b6857b24b153141#zoekt

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/chyk3vqk4rjjsdyh8afqkfsgcdrnr7v9-zoekt-3.7.2-2-unstable-2024-10-01
ls -la /nix/store/chyk3vqk4rjjsdyh8afqkfsgcdrnr7v9-zoekt-3.7.2-2-unstable-2024-10-01/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

zoekt

Maintainer pings
cc @AndersonTorres for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot merge


Homepage

Description
Please provide a short summary explaining what this PR is about.
Homepage
Fixes # https://github.com/HackYourFuture-CPH/rate-my-cv/issues/119
How to test?
npm run dev
Please provide a short summary how your changes can be tested?
Checklist

[x ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[x ] I have made corresponding changes to the documentation
[ x] This PR is ready to be merged and not breaking any other functionality

Please fix the build step before requesting rewiews. Also, can i have you respond on Alis review?


Duplicated entries in xlf file

When compiling one of our apps duplicate entries for a translation (trans-unit-id) are created in g.xlf file. In total 4 trans-unit-ids are duplicated.
Screenshots below show these entries:
first occurence of the first two entries

first occurence of second two entries

duplicate entries (second occurence of entries - same frame color marks corresponding entries from above screenshots):

It seems that duplication is caused by page customization objects. All controls with duplicated captions were added in page extension as well as used in page customization to move them to another position.

Issue occured the first time when making some minor changes in the app.
Issue can be reproduced by compiling the app with actual AL extension (Version: 5.0.270354).
NOTE
I cannot share the source code via GitHub because it's our IP.

Hi @makuhn, thank for reporting the issue. This is a bug, I put corresponding label. It will be fixed in the next releases.

ALProject46.zip
Project to repro the issue

@AndreyKorepanov @JesperSchulz Any news to this issue? It is meanwhile open for more than half a year.

Looping in @atoader, as this repository is managed by his team.

The issue is in our backlog, but we have not started working on it. I will post an overview of how we prioritize issues coming in from GitHub over the following weeks to offer more visibility into the process.

@atoader Are there any news regarding this issue?

@atoader any news regarding this issue?

@atoader has left Microsoft years ago, please leave him be ;-)
@BazookaMusic can you take over?

There is a repro, marking this for triage.

The fix for this issue has been checked in to the master branch. It will be available in the bcinsider.azurecr.io/bcsandbox-master Docker image starting from platform build number 25.0.18947.0 and VS Code Extension Version 14.0.1001176.
If you don’t have access to these images you need to become part of the Ready2Go program: aka.ms/readytogo
For more details on code branches and docker images please read:
https://blogs.msdn.microsoft.com/nav/2018/05/03/al-developer-previews-multiple-releases-and-github/
https://freddysblog.com/2020/06/25/working-with-artifacts/


Don't display report results without group

API request with action request_download generates report result. This result is used in endpoint task to get downloads(details here).
It sounds like that such results shouldn't be visible in UI or API and basically it is true because such reports don't have group (miq_group==nil) and we don't display them thanks to usage .for_user scope everywhere.
Issue
We are not using logic from .for_user or .for_groups in
Overview -> Reports screen  but there is used scope with_current_user_groups_and_report which returns also results without group.

when you click on orange result -error message is displayed because there is used .for_user scope which filters out results without group.

This change updates with_current_user_groups_and_report to return only results with group (for report_admin role).
cc @abellotti
@miq-bot assign @gtanzillo
@miq-bot add_label jansa/yes, bug
NOTE: This PR pertains only report_admin role. It works as expected for the other roles.

Jansa backport details:
$ git log -1
commit 9500945e30785076c1ac64d95e6743940c67bba8
Author: Gregg Tanzillo<EMAIL_ADDRESS>Date:   Tue Jul 21 11:47:06 2020 -0400

    Merge pull request #20368 from lpichler/use_for_groups_scope_in_with_current_user_groups

    Don't display report results without group

    (cherry picked from commit db87b15c2629cab81686750114d7d099ee471a32)


Fixed Dockerize lncli failure and docs

In reference to #295, fixed small documentation issue in "Step by Step payment guide" and modified docker script to not specify a data directory (which was preventing lncli form running without additional command line parameters, and breaking the documentation).
I'd be worried moving the data direction may not be backwards compatible, but I'm not sure if people map it or not.
cc @halseth

@Roasbeef do you squash and merging, or need me to make a cleaner PR?

@patwhite Would be nice if you could squash into one commit with a nice description (check contribution guidelines) and rebase on master :)


Improve agent starting and simultaneously restarting (common for Agent install) concurrency handling

What does this PR do?
Improve agent starting and simultaneously restarting, which is common for Agent install and upgrade, concurrency handling. Specifically it handles the following edge case:

[Process A] datadogagent service is starting in the end of Agent installation (no Agent services are running at this moment)
[Process B] Externally and concurrently (after Agent configuration change) agent.exe restart-service CLI command is started.
[Process B] agent.exe restart-service CLI command will get list of datadogagent dependent services to be stopped before stopping datadogagent service itself.
[Process A] datadog-trace-agent service (or other dependent services) is started by the still starting datadogagent service (from step no.1).
[Process B] agent.exe restart-service CLI command should stop just started datadog-trace-agent service before moving on to stop datadogagent service itself.

Specifically:

Collection of dependent services for the datadogagent service previously collected only Running dependent service. In some cases with concurrent execution stopping dependent services missed just started dependents services if they started AFTER dependent service collection,. The command would miss newly started dependent services and stopping datadogagent service would fail because a dependent service is still running. New code collects all dependent services to avoid this particular edge case. It does not solve all possible race condition but it eliminates a few of them.
Previously timeout for service stop was 10 seconds and now it is increased to 30 seconds.

Both changes above are also similar to the Powershell's Restart-Service cmdlet logic.

Motivation
We suspect that there is a small risk that certain small timing changes in Agent code may increase race conditions outlined above.

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes
No need for manual test since key logic is tested in the accompanied unit tests

/merge


release_below_ivcp

Short Description

release_below_ivcp functionality. Release pokemon based on ivcp score.
Possible solution

as a release parameter
How it would help others

The ivcp calculation is more accurate according to the docs.

I'd look at it but... beer

Yes.. let me take a look :)

Working on it. Adding "keep_best_ivcp" as well.

Nice thank you!

@javajohnHub Take a look at PR #5465


Readme now points to two branches - port to 2014 branch

https://github.com/intersystems-ru/EnsLogViewer/compare/2014...master?expand=1


Identifiers validation failed for dataset Inventario herpetofaunístico del valle semiárido de Tehuacán-Cuicatlán

Identifier validation failed for the dataset Inventario herpetofaunístico del valle semiárido de Tehuacán-Cuicatlán:

Crawler attempt: 267
Publishing organization: Comisión nacional para el conocimiento y uso de la biodiversidad
Publishing country: MEXICO
Installation: IPTCONABIO
Number of occurrences indexed for this dataset at the time of the issue: 1419
Cause: GBIF IDs hit maximum allowed - 50%, duplicates - 52%, total records count 1319, absent records count 685
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3073134/step

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Inventario herpetofaunístico del valle semiárido de Tehuacán-Cuicatlán : https://doi.org/10.15468/77ijjw.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset Inventario herpetofaunístico del valle semiárido de Tehuacán-Cuicatlán:

Crawler attempt: 270
Publishing organization: Comisión nacional para el conocimiento y uso de la biodiversidad
Publishing country: MEXICO
Installation: IPTCONABIO
Number of occurrences indexed for this dataset at the time of the issue: 1419
Cause: GBIF IDs hit maximum allowed - 50%, duplicates - 100%, total records count 1319, absent records count 1319
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3094000/step

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Inventario herpetofaunístico del valle semiárido de Tehuacán-Cuicatlán : https://doi.org/10.15468/77ijjw.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.


MacOS: App CLI does not accept  key combinations

This is a very old issue, however, it has not been solved and it's not open anymore.
What happened:
When using the app on MacOS, entering characters that are typed using the <option> key are not accepted. That applies for example to the curly braces and the square brackets on a German keyboard layout.
What you expected to happen:
The CLI should print the characters as every other app on MacOS.
How to reproduce it (as minimally and precisely as possible):
Click the CLI symbol in the app. Now try to enter a character using <option>+<something>.
What are your environment parameters?

DeFi App Version: 2.1.17 (happened ever since the first version I downloaded months ago)
Operating System (OS): MacOS

Hi @tame81 , thanks for your feedback. Yes the team is aware of this and will get it fixed in due time. Thank you.

Hi @tame81 , update v2.3.2 is out, this is a mandatory update.
Please read through the release notes before updating.
The above feature / issue is not included in this update yet, this comment is to notify you about the update.


Amend Shopware/Models/Order/Detail::getTaxRate

1. Why is this change necessary?
Because it is a minor upfuck discomfort for IDEs and their users.
2. What does this change do, exactly?
It just fixes a type in phpDoc.
3. Describe each step to reproduce the issue or behaviour.
/** @var $model \Shopware\Models\Order\Detail */
$model = /* --- */;
$taxRate = $model->getTaxRate(); // this gets hinted as string
var_dump($taxRate); // this will dump float

4. Please link to the relevant issues (if any).
None.
5. Which documentation changes (if any) need to be made because of this PR?
It is a documentation change.
6. Checklist

[ ] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[x] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfill them.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/SW-20537
Please use this issue to track the state of your pull request.

Hi,
thx. We merged this into the 5.4 Branch.
Greetings,
Marcel


This is a test branch!

Note: It looks like stable and develop are out of sync. I created this change by pushing random buttons on github and I got here...


Create google/cloud/bigtable/{README.md,quickstart/}

We want each per-library area to contain its own README.md and quickstart/ area. The build instructions that currently exist in the top-level README.md file would be replaced by the instructions in the google/cloud/bigtable/quickstart/ folder.
The google/cloud/bigtable/README.md should follow a pattern similar to https://github.com/googleapis/google-cloud-cpp-spanner/blob/master/README.md
The google/cloud/bigtable/quickstart/ directory should follow a pattern similar to https://github.com/googleapis/google-cloud-cpp-spanner/tree/master/quickstart
Tasks:

[ ] Created/updated google/cloud/bigtable/README.md
[ ] Created google/cloud/bigtable/quickstart/
[ ] Build scripts test google/cloud/bigtable/quickstart/

Note that there is a quickstart program in google/cloud/bigtable/examples/bigtable_quickstart.cc which is probably suitable for this, it is referenced by the cloudsite documentation too.


added support for legacy octest

Short description 📝
productType = "com.apple.product-type.bundle.ocunit-test"; in PBXNativeTarget caused crash when loading project
Solution 📦
case ocUnitTestBundle = "com.apple.product-type.bundle.ocunit-test" in PBXProductType has been added to address this issue

Nice catch @solgar. Would you mind adding a test that validates the string value for that enum case?

@pepibumur Will do.

👏 🎉  Nice job @solgar. I've merged it!


Generate cluster id in case it's not in the seedReconfig

Following https://github.com/openshift/image-based-install-operator/pull/34, this is no longer required


Update data_import_log_expiration.rake

fix wrong name

Frontend tests were OK :+1: (details)

@juanignaciosl can you review, sounds good for me

:+1:

thanks!

Frontend tests were OK :+1: (details)

@amnesic we've received your CLA. Thank you!


Take care of Plane => vec4 type conversion when converting materials

Fixes #84633
Also, I'm a little curious why we use Plane as the parameter type at the first place.

Also, I'm a little curious why we use Plane as the parameter type at the first place.

We didn't have a Vector4 type before 4.0, so both Color and Plane were used as alternatives for arrays of 4 floats.
That parameter could likely be changed to Vector4, but would that break compat?

Seems to fix the issue.
(I tried to fix this after opening the issue (and before reading clayjohn's comment) but got lost into shader generating code in material.cpp). Worked somehow but also had some issues (besides being implemented into a wrong place altogether). This doesn't have those).

That parameter could likely be changed to Vector4, but would that break compat?

It seems that  we do not store a Plane but an index like below, if only the runtime representation is effected maybe it will not break compact ?
[sub_resource type="StandardMaterial3D" id="StandardMaterial3D_a7enu"]
metallic = 0.62
metallic_texture_channel = 2
roughness = 0.09
roughness_texture_channel = 1
ao_enabled = true
ao_light_affect = 0.32
ao_texture_channel = 3

I did some more search of the code, it seems to me that the type mistach in material (Plane and vector4) seems only happens here, so I believe it's safe to change the _get_texture_mask 's return type. I will try it in the next few days.

This might also fix https://github.com/godotengine/godot/issues/99663

@tetrapod00 Thank you for highlighting this issue. As @jsjtxietian suspected, a more ideal solution is just to change the return type of _get_texture_mask() which I have done in https://github.com/godotengine/godot/pull/99743


Start supporting SNPE backend

[x] Run dlc like caffe2 https://github.com/pytorch/pytorch/tree/b8c8977be797cb16354aa97c3fcdc910d3e9e5c5/caffe2/mobile/contrib/snpe
[x] Generate ONNX to dlc

/test

/test


[HackerOne-2354265] Restrict number of imports, program depth, and call depth.

This PR,

introduces a limit for the number of imports in a program.
checks that each function in a program makes at most MAX_TRANSITIONS - 1 calls.
introduces an upper bound in import depth
caches get_number_of_function_calls.

One question less related this issue: Would it be better to set a larger 'TRANSACTION_DEPTH', (e.g. 8)? This will make it easier to increase 'MAX_TRANSITION' in the future. We can still keep 'MAX_TRANSITION' as 32 for now.

One question less related this issue: Would it be better to set a larger 'TRANSACTION_DEPTH', (e.g. 8)? This will make it easier to increase 'MAX_TRANSITION' in the future. We can still keep 'MAX_TRANSITION' as 32 for now.

This has problems because it will change the Merklization to be much slower, and require a larger inclusion circuit for proving. Ultimately, these impact runtime for transaction generation.


I guess astral fails to interpret something here ...

event/407fa3bfa42b38f1d0c1707440c9794ab81da27622393ca1b617d2adcc724b59 looks weird here:

Due to #19 it's a bit cumbersome to investigate.

this is fixed now, though it still is a bit slow it does populate. closing.
previously if an event wasn't received in time I cancelled the request which lead to empty quote events being listed.


Add manifests for G-Cloud 6 and 7

Add manifest files
The commit extracts the manifest files from the apps into one central place without modifying them.
Although each file is typically only used by one app (at the moment) this will make them easier to keep organised if/when we have 2+ frameworks.
Add G-Cloud 6 framework as symlink
This commit adds the G-Cloud 6 framework as a symlink.
It could be real files in the future, but since we want to keep parity between 6 and 7 it seems reasonable not to maintain two separate collections of files.
This allows us to access the content for a G-Cloud 6 service page in a dynamic way.
Add G-Cloud 6 as copy of G-Cloud 7
Excludes things which we don't have or need content for, ie declaration, submissions

:+1:


Uninstall feature goal

It would be nice the ability to uninstall features from the server as mentioned in http://www-01.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.wlp.doc/ae/rwlp_command_featuremanager.html?cp=SSEQTP_8.5.5%2F1-3-11-0-3-2-1-2

Added support for it in https://github.com/WASdev/ci.maven/commit/9d04e8962370e05e5005e12b10b1ea7e8f945d57.


strange "%" mark in every line of integrated terminal

VSCode Version: 1.21.1
OS Version: windows 7

hi all :
i am using zsh as my terminal ( i'm using windows 7) and it's working
great but in vscode a strange "%" character appear before every line  as in picture ... any body know how to remove it ?

What's your settings.json look like?
Does the same thing occur when using insiders? http://code.visualstudio.com/insiders


Flags for reading in coil map data

In order to be able to calculate coil maps for a Cartesian SENSE scan, we need to read in only the data with flag == ACQ_IS_PARALLEL_CALIBRATION and flag == ACQ_IS_PARALLEL_CALIBRATION_AND_IMAGING.
Currently we can only set an ignore_flag but it is not possible to ignore the data without any flag because NO_FLAG has a value of 0 which is tricky to encode in the bit-logic.
Suggestion: Give NO_FLAG the highest possible value in MRpro and then have a separate check in KData (similar to ACQ_IS_PARALLEL_CALIBRATION_AND_IMAGING/ACQ_IS_PARALLEL_CALIBRATION logic) for this case.

Suggestion by Felix: KData has as an input a function handle to a filter_function:
def filter_function(acquisition) -> bool
which defines if an acquisition should be included or not.


Nuke: (Non) Existing Files

Changelog Description
When a write instance is set to "existing files", the collection will error with the message below:
Traceback (most recent call last):
  File "C:\Users\tokejepsen\bumpybox_development\OpenPype\.venv\lib\site-packages\pyblish\[plugin.py](http://plugin.py/)", line 527, in __explicit_process
    runner(*args)
  File "C:\Users\tokejepsen\bumpybox_development\OpenPype\openpype\hosts\nuke\plugins\publish\[collect_writes.py](http://collect_writes.py/)", line 40, in process
  File "C:\Users\tokejepsen\bumpybox_development\OpenPype\openpype\hosts\nuke\plugins\publish\[collect_writes.py](http://collect_writes.py/)", line 76, in _set_existing_files_data
  File "C:\Users\tokejepsen\bumpybox_development\OpenPype\openpype\pipeline\publish\[publish_plugins.py](http://publish_plugins.py/)", line 350, in set_representation_colorspace
    log=self.log
  File "C:\Users\tokejepsen\bumpybox_development\OpenPype\openpype\pipeline\[colorspace.py](http://colorspace.py/)", line 705, in set_colorspace_data_to_representation
    filename = filename[0]
IndexError: list index out of range

This PR will skip setting the colorspace when there are no files, so existing files validation can kick in later with a more user-friendly error report.
Testing notes:

Setup write instance in Nuke with "existing files" option.
Publish and ensure validation kicks in.

LGFM...

Side note: whatever that lock_connections false, mapsize 0.15, etc. is in the artist facing reports in that screenshots should be changed to DEBUG logs. That is not an artist facing message.

Because we're splitting OpenPype into ayon-core and individual host addons, this PR would have to be re-created to target one of those.
We're closing it down, but we'll he happy for a new PR to ynput/ayon-core or the host addon repository once it's up.


add method findIndex / findLast / findLastIndex

Codecov Report

Merging #114 (f866b6b) into main (56228c6) will increase coverage by 0.06%.
The diff coverage is 98.30%.

@@            Coverage Diff             @@
##             main     #114      +/-   ##
==========================================
+ Coverage   96.49%   96.56%   +0.06%
==========================================
  Files         149      153       +4
  Lines        1482     1541      +59
==========================================
+ Hits         1430     1488      +58
- Misses         52       53       +1

Impacted Files
Coverage Δ

ramda/private/_xfindIndex.py
95.00% <95.00%> (ø)

ramda/__init__.py
100.00% <100.00%> (ø)

ramda/findIndex.py
100.00% <100.00%> (ø)

ramda/findLast.py
100.00% <100.00%> (ø)

ramda/private/_xfindLast.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 56228c6...f866b6b. Read the comment docs.


⚠ ClamAV has degraded performance

In ca70b96, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 67 ms

Resolved: ClamAV performance has improved in ec492d0.


FTP support

pls add ftp support.

Certainly something I'd consider adding should enough people want it or I receive a pull request for it :-)

+1

+1

-1 sorry
IMHO purpose of rclone seems to be to store and retrieve data that sits
behind Application Programming Interface(API).
On Mon, Jul 11, 2016 at 5:42 PM erse80<EMAIL_ADDRESS>wrote:

+1
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ncw/rclone/issues/540#issuecomment-231874620, or mute
the thread
https://github.com/notifications/unsubscribe/AGXRY2oB7GTUOmcPW_Y0r7dYK5qRjuXUks5qUri9gaJpZM4I6XJj
.

+1
We use rclone to move big data from ftp to object storage. At the moment we have to mount the ftp server with fusefs as a local file system. The performance is not good, it would be much better to have rclone able to speak FTP

+1
There are many scientific datasets stored on ftp servers right now, and they might stay there for "legacy" reasons. However, having a copy on a cloud storage would allow new applications to be written more cloud-friendly and help the migration from filesystem based data management to API-based.

I think FTP sits well with rclone.  The trouble with it is that it is a rather loosely defined protocol and the whole control channel & data channel thing will make rclone's life more complicated.  The first thing to do would be to evaluate the various FTP client libraries available.

+1
Also mentioned sFTP here: https://github.com/ncw/rclone/issues/521

@nick
Would you like a list of available ftp libraries in a spreadsheet format or
CSV is okay? Also, what column names do you prefer for the available
libraries?
On Thu, Jul 14, 2016, 7:42 AM Nick Craig-Wood<EMAIL_ADDRESS>wrote:

I think FTP sits well with rclone. The trouble with it is that it is a
rather loosely defined protocol and the whole control channel & data
channel thing will make rclone's life more complicated. The first thing to
do would be to evaluate the various FTP client libraries available.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ncw/rclone/issues/540#issuecomment-232641990, or mute
the thread
https://github.com/notifications/unsubscribe/AGXRYz0Lmumkm5qyMq0ukcsdOoUagRsCks5qViCXgaJpZM4I6XJj
.

In the this issue as a table would be perfect.  Don't mind about column names.  Thanks in advance!

Path
Synopsis

github.com/jlaffaye/ftp
Package ftp implements a FTP client as described in RFC 959.

github.com/deuill/sleepy/core/server
Package server contains the core server functionality for Sleepy, including the RPC service, the embedded HTTP server for files uploaded via Sleepy, and an FTP server, containing a subset of functionality required for uploading files to Sleepy in an efficient manner.

github.com/smira/aptly/http
Package http provides all HTTP (and FTP)-related operations

github.com/mingzhi/hgt/genome/report
This package is to retreive prokaryotes information from the folder of GENOME_REPORTS in NCBI ftp.

github.com/yob/graval
An experimental FTP server framework.

github.com/smira/go-ftp-protocol/protocol
Package protocol implements ftp:// scheme plugin for http.Transport

github.com/remogatto/ftpget
Fetch files from FTP

bitbucket.org/zombiezen/ftp
Package ftp provides a minimal FTP client as defined in RFC 959.

github.com/goftp/ftp
Package ftp implements a FTP client as described in RFC 959.

github.com/felixge/go-ardrone/net/ftp
Package ftp provides ftp access to the ardrone.

github.com/dabamos/openadms/monitoring/module/transfer/ftp
Package ftp provides a module to transfer files via ftp.

github.com/MG-RAST/Shock/vendor/github.com/jum/tinyftp
Package tinyftp implements a small subset of FTP, enough to retrieve directory listings and files (including resume support).

github.com/mezzato/ftp4go
Package ftp implements an FTP client.

github.com/secsy/goftp
Package goftp provides a high-level FTP client for go.

github.com/MDrollette/ftp4go
Package ftp implements an FTP client.

-------------
-------------

-------------
-------------

-------------
-------------

Thanks @zeshanb :-)

+1! 👍

Most welcome :)
On Jul 24, 2016 8:04 AM, "Nick Craig-Wood"<EMAIL_ADDRESS>wrote:

Thanks @zeshanb https://github.com/zeshanb :-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ncw/rclone/issues/540#issuecomment-234773618, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGXRY-HOlxz_m4iwVwrSgL9Z-CB8Voo4ks5qY1TcgaJpZM4I6XJj
.

+1
I'd like ftp support for rclone.

+1

Great app and FTP support would be very useful ;)

+10
@ncw Hopefully, these are enough supporters? :)

Please find a beta of the FTP backend here
https://beta.rclone.org/v1.36-114-gcdacf026/ (uploaded in 15-30 mins)
Please open new issues if you find any.


Fix running on Windows

This fixes the following error when running on Windows (tested on 4.18 with ruby 3.3.4-1 but maybe dating back to 4.15?)
lib/aspera/environment.rb:127:in `terminal_supports_unicode?': undefined method `include?' for nil (NoMethodError)

        @terminal_supports_unicode = terminal? && ENV.values_at('LC_ALL', 'LC_CTYPE', 'LANG').compact.first.include?('UTF-8') if @terminal_supports_unicode.nil?

None of the environment variables this line is looking for is set on Windows by default so we need to test for that possibility.

Hi, I have manually reported your fix to the dev branch, thanks for the heads up.
Next release will include it.


proposal: rename secure-scuttlebutt repo / pkg to ssb-db

see discussion on ssb here.

The viewer link isn't working for me, but I'm 👍 for this idea.

I'm okay with this, I'm intending to rewrite using depject, so this can be the name for that.

The viewer link isn't working for me

should be fixed now

[ ] Remove internal name references (#242)
[ ] Rename GitHub repo
[ ] npm publish as ssb-db
[ ] npm deprecate secure-scuttlebutt


Use Status enums instead of u32

Solves #617
Most of the changes are from VS code auto formatting.

Hello @BulkBeing thank you! Let's see if CI passes, but looks good at first glance. Is this hacktoberfest contribution? :-)

@BulkBeing there's failures to compile unit and integration tests, can you please fix it?
You can build/run unit tests from root directory like this
RUST_TEST_THREADS=1 RUST_LOG=info cargo test --features general_test

and aries-vcx integration tests
cargo test -p aries-vcx --no-run --features "pool_tests agency_pool_tests mysql_test"

Also please rebase on latest main, it will make your CI run somewhat faster

Codecov Report

Merging #621 (4770d8e) into main (4517ef7) will decrease coverage by 29.78%.
The diff coverage is n/a.

:exclamation: Current head 4770d8e differs from pull request most recent head b552844. Consider uploading reports for the commit b552844 to get more accurate results

@@             Coverage Diff             @@
##             main     #621       +/-   ##
===========================================
- Coverage   58.91%   29.12%   -29.79%
===========================================
  Files         200       31      -169
  Lines       19273     1181    -18092
  Branches     4385      230     -4155
===========================================
- Hits        11354      344    -11010
+ Misses       3564      694     -2870
+ Partials     4355      143     -4212

Flag
Coverage Δ

integration-aries-vcx
?

unittests-agency-client
29.12% <ø> (ø)

unittests-aries-vcx
?

Flags with carried forward coverage won't be shown. Click here to find out more.

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@Patrik-Stas  Both
RUST_TEST_THREADS=1 RUST_LOG=info cargo test --features general_test
cargo test -p aries-vcx --no-run --features "pool_tests agency_pool_tests mysql_test"

are passing on my local now.

@BulkBeing awesome, let's wait for CI. I am not sure if something wrong with github, or we've run of some sort of per-repo computation minutes limit but it's terribly slow today.

@mirgee our CI is not quite adjusted for fork PRs, seems like something to improve. Tested test manually, passing. I suggest we merge this and we can address CI for fork-based PRs after that.
I am just thinking perhaps we should run cargo fmt on main branch, then run it on this branch to loose the formatting delta here.

@BulkBeing can you please run cargo fmt against the files (only those) you have modified? I think we are good to merge after that.
Thank you!

@Patrik-Stas All the files I edited are already formatted (VS code format on save). Rechecked.

@BulkBeing we've resolved some conflicts after we merged other PR. Merging this, thank you for contribution :-)


Add PostgreSQL cache

This cache works with GCP CloudSQL, making it easier to setup caches that are shared among users.
Question: it introduces some optional dependencies
   "pg8000",
        "google-cloud-storage",
        "sqlalchemy",

What's manifest's way of ensuring that these don't break imports for folks who don't have them installed?

At the moment, a try/catch around the cache dictionary in manifest.py. So the postgres key only gets added if the class is loaded sucessfully.

Also how hard would adding a test be. See https://github.com/HazyResearch/manifest/blob/c306e16da6d320f397db0705a278cd94158eeb44/tests/conftest.py#L20. I have support for instantiating different caches. If it's too hard or costs money, it's not worth it except maybe some get/set key methods. I certainly don't test all the clients lol.

Just added in some simple tests that monkeypatch the connection to the db