Artifact when stroking with small points

There is some sort of artifact when drawing a stroke. It seems to be dependent on small points or angles. Here is a code example:

{-# LANGUAGE FlexibleContexts          #-}
{-# LANGUAGE NoMonomorphismRestriction #-}
{-# LANGUAGE TypeFamilies              #-}
module Artifact where

import           Data.Aeson
import           Data.Vector                 (Vector)
import qualified Data.Vector                 as V
import           Diagrams.Backend.Rasterific
import           Diagrams.Backend.SVG
import           Diagrams.Prelude

test :: IO ()
test = do
  renderSVG "florida.svg" (dims (V2 1000 1000)) mkDia
  renderRasterific "florida.png" (dims (V2 1000 1000)) mkDia

mkDia = (map p2 pts)
        # fromVertices
        # closeTrail
        # strokeTrail
        # lc blue
        # bgFrame 1 white

pts :: [(Double, Double)]
pts = [(-82.478063,27.92768),(-82.489817,27.9196),(-82.491117,27.9145),(-82.487417,27.895001),(-82.48142,27.889097),(-82.481763,27.878098),(-82.487883,27.872072),(-82.488057,27.863566),(-82.480137,27.853246),(-82.471624,27.847342),(-82.46884,27.843295),(-82.47244,27.822559),(-82.475273,27.820991),(-82.489849,27.822607),(-82.511193,27.828015),(-82.553946,27.848462),(-82.552918,27.862702),(-82.538618,27.864901),(-82.533218,27.870701),(-82.529918,27.877501),(-82.539318,27.885001),(-82.542818,27.890601),(-82.541747,27.893706),(-82.535818,27.898),(-82.531318,27.9039),(-82.533718,27.932999),(-82.541218,27.948998),(-82.553918,27.966998),(-82.576003,27.969424),(-82.60865,27.983245),(-82.62959,27.998474),(-82.641487,27.999426),(-82.664806,27.997046),(-82.678606,27.993715),(-82.682414,27.987053),(-82.684793,27.971824),(-82.700134,27.960307),(-82.716522,27.958398),(-82.720522,27.955798),(-82.724122,27.948098),(-82.720122,27.936399),(-82.710022,27.928299),(-82.691621,27.924899),(-82.685121,27.916299),(-82.671221,27.913),(-82.628063,27.910397),(-82.63422,27.9037),(-82.63212,27.8911),(-82.61002,27.873501),(-82.598443,27.857582),(-82.594819,27.843402),(-82.589319,27.835702),(-82.586519,27.816703),(-82.60742,27.798904),(-82.622723,27.779868),(-82.63052,27.753905),(-82.62502,27.732706),(-82.62572,27.727006),(-82.63362,27.710607),(-82.63982,27.703907),(-82.652521,27.700307),(-82.662921,27.702307),(-82.671621,27.705907),(-82.677321,27.706207),(-82.679251,27.694665),(-82.693748,27.700217),(-82.713629,27.698661),(-82.718822,27.692007),(-82.723022,27.671208),(-82.721622,27.663908),(-82.716322,27.651409),(-82.712555,27.646647),(-82.698091,27.638858),(-82.705017,27.62531),(-82.733076,27.612972),(-82.736552,27.617326),(-82.739122,27.636909),(-82.738022,27.706807),(-82.740323,27.718206),(-82.746223,27.731306),(-82.753723,27.736306),(-82.760923,27.745205),(-82.770023,27.767904),(-82.783124,27.783804),(-82.790224,27.791603),(-82.820433,27.813742),(-82.828561,27.822254),(-82.846526,27.854301),(-82.849126,27.8632),(-82.851126,27.8863),(-82.847826,27.910199),(-82.840882,27.937162),(-82.831388,27.962117),(-82.824875,27.960201),(-82.821975,27.956868),(-82.830819,27.930926),(-82.838484,27.909111),(-82.832155,27.909242),(-82.820715,27.927268),(-82.805462,27.960201),(-82.792635,28.01116),(-82.792635,28.032307),(-82.782724,28.055894),(-82.783824,28.106292),(-82.781324,28.127591),(-82.786624,28.144991),(-82.790724,28.15249),(-82.799024,28.15179),(-82.808474,28.154803),(-82.805097,28.172181),(-82.797762,28.187789),(-82.762643,28.219013),(-82.76446,28.220069),(-82.764103,28.244345),(-82.759072,28.25402),(-82.746188,28.261192),(-82.732792,28.291933),(-82.735463,28.30039),(-82.73146,28.325075),(-82.715822,28.345501),(-82.706112,28.368057),(-82.706322,28.401325),(-82.697433,28.420166),(-82.684137,28.428019),(-82.677839,28.434367),(-82.674787,28.441956),(-82.680396,28.457194),(-82.67241,28.464746),(-82.665055,28.484434),(-82.66447,28.488788),(-82.66639,28.49733),(-82.670146,28.500769),(-82.669416,28.519879),(-82.66804,28.528199),(-82.663705,28.530193),(-82.656694,28.544814),(-82.661729,28.549743),(-82.66165,28.554143),(-82.65705,28.568028),(-82.654138,28.590837),(-82.664055,28.606584),(-82.656649,28.623727),(-82.671815,28.627604),(-82.675596,28.656475),(-82.668034,28.683285),(-82.668722,28.695658),(-82.712373,28.720921),(-82.698281,28.75701),(-82.696906,28.768009),(-82.70103,28.797224),(-82.716497,28.810285),(-82.730245,28.850155),(-82.688657,28.89518),(-82.688864,28.905609),(-82.702618,28.932955),(-82.708793,28.935979),(-82.723861,28.953506),(-82.735754,28.973709),(-82.737872,28.995703),(-82.760551,28.993087),(-82.764055,28.999707),(-82.759378,29.006619),(-82.753513,29.026496),(-82.759704,29.054192),(-82.783328,29.064619),(-82.780558,29.07358),(-82.816925,29.076215),(-82.823659,29.098902),(-82.809483,29.10462),(-82.801166,29.105103),(-82.799117,29.110647),(-82.798876,29.114504),(-82.805703,29.129848),(-82.804736,29.146624),(-82.827073,29.158425),(-82.858179,29.162275),(-82.887211,29.161741),(-82.922613,29.169769),(-82.932405,29.167891),(-82.945302,29.167821),(-82.974676,29.17091),(-82.979522,29.171817),(-82.987162,29.180094),(-82.991653,29.180664),(-82.996144,29.178074),(-83.018212,29.151417),(-83.019071,29.141324),(-83.030453,29.134023),(-83.053207,29.130839),(-83.056867,29.146263),(-83.068249,29.153135),(-83.060947,29.170959),(-83.061162,29.176113),(-83.065242,29.184489),(-83.078986,29.196944),(-83.087839,29.21642),(-83.074734,29.247975),(-83.077265,29.255331),(-83.089013,29.266502),(-83.107477,29.268889),(-83.125567,29.278845),(-83.128027,29.282733),(-83.146445,29.289194),(-83.149764,29.289768),(-83.16073,29.286611),(-83.169576,29.290355),(-83.176736,29.31422),(-83.17826,29.327916),(-83.176852,29.329269),(-83.175518,29.34469),(-83.189581,29.363417),(-83.200702,29.373855),(-83.202446,29.394422),(-83.218075,29.420492),(-83.240509,29.433178),(-83.263965,29.435806),(-83.272019,29.432256),(-83.294747,29.437923),(-83.307094,29.459651),(-83.307828,29.468861),(-83.311546,29.475666),(-83.323214,29.476789),(-83.33113,29.475594),(-83.350067,29.489358),(-83.356722,29.499901),(-83.370288,29.499901),(-83.379254,29.503558),(-83.383973,29.512995),(-83.400252,29.517242),(-83.401552,29.523291),(-83.39983,29.533042),(-83.405256,29.578319),(-83.405068,29.59557),(-83.39948,29.612956),(-83.404081,29.640798),(-83.412768,29.668485),(-83.414701,29.670536),(-83.436259,29.677389),(-83.444635,29.677155),(-83.448194,29.675254),(-83.455356,29.676444),(-83.483143,29.690478),(-83.483567,29.698542),(-83.493728,29.708388),(-83.512716,29.71648),(-83.537645,29.72306),(-83.547172,29.732223),(-83.554993,29.7426),(-83.566018,29.761434),(-83.578955,29.768378),(-83.584716,29.77608),(-83.586089,29.784644),(-83.583045,29.787307),(-83.581903,29.792063),(-83.585899,29.811754),(-83.595493,29.827984),(-83.605244,29.836387),(-83.618568,29.842336),(-83.63798,29.886073),(-83.659951,29.899524),(-83.679219,29.918513),(-83.686423,29.923735),(-83.757249,29.957943),(-83.788729,29.976982),(-83.82869,29.983187),(-83.845427,29.998068),(-83.93151,30.039068),(-83.933668,30.041152),(-83.931879,30.044175),(-83.933432,30.046305),(-83.95968,30.064943),(-83.991607,30.08392),(-84.000716,30.096209),(-84.024274,30.103271),(-84.048715,30.103208),(-84.06299,30.101378),(-84.083057,30.092286),(-84.087034,30.092103),(-84.094725,30.094964),(-84.10273,30.093611),(-84.11384,30.085478),(-84.124889,30.090601),(-84.135683,30.083018),(-84.157278,30.072714),(-84.167881,30.071422),(-84.179149,30.073187),(-84.184493,30.077254),(-84.182217,30.082359),(-84.177405,30.085452),(-84.174999,30.095763),(-84.177062,30.096107),(-84.179811,30.091982),(-84.18806,30.094045),(-84.19356,30.097826),(-84.202152,30.112261),(-84.205589,30.114323),(-84.207652,30.106762),(-84.19853,30.087937),(-84.201585,30.087982),(-84.203349,30.085875),(-84.20801,30.084776),(-84.237014,30.08556),(-84.245668,30.093021),(-84.247491,30.10114),(-84.256439,30.103791),(-84.269363,30.09766),(-84.272511,30.092358),(-84.274003,30.083079),(-84.270368,30.075469),(-84.270792,30.068094),(-84.277168,30.060263),(-84.289727,30.057197),(-84.297836,30.057451),(-84.315344,30.069492),(-84.342022,30.063858),(-84.358923,30.058224),(-84.365882,30.024588),(-84.361962,29.987739),(-84.359986,29.984739),(-84.3477,29.984123),(-84.343041,29.9751),(-84.342046,29.967101),(-84.423335,29.983354),(-84.429865,29.982667),(-84.432958,29.981292),(-84.432271,29.972356),(-84.435708,29.964107),(-84.433646,29.962388),(-84.417816,29.9655),(-84.384133,29.961375),(-84.339426,29.946007),(-84.336511,29.942508),(-84.333746,29.923721),(-84.335953,29.912962),(-84.343389,29.899539),(-84.349066,29.896812),(-84.378937,29.893112),(-84.404958,29.901229),(-84.423834,29.902996),(-84.434287,29.906328),(-84.443652,29.913785),(-84.451705,29.929085),(-84.470323,29.924524),(-84.494562,29.913957),(-84.511996,29.916574),(-84.535873,29.910092),(-84.57744,29.887828),(-84.603303,29.876117),(-84.613154,29.867984),(-84.647958,29.847104),(-84.656318,29.837943),(-84.65645,29.834277),(-84.669728,29.82891),(-84.683934,29.831327),(-84.692053,29.829059),(-84.730327,29.8069),(-84.755595,29.78854),(-84.762998,29.788846),(-84.824197,29.758288),(-84.837168,29.755926),(-84.868271,29.742454),(-84.881777,29.733882),(-84.888031,29.722406),(-84.892493,29.72266),(-84.901781,29.735723),(-84.890066,29.755802),(-84.877111,29.772888),(-84.893992,29.785176),(-84.90413,29.786279),(-84.91511,29.783303),(-84.920917,29.772901),(-84.93837,29.750211),(-84.946595,29.745032),(-84.964007,29.742422),(-84.968841,29.72708),(-84.977004,29.721209),(-84.993264,29.714961),(-85.037212,29.711074),(-85.072123,29.719027),(-85.101682,29.718748),(-85.121473,29.715854),(-85.153238,29.708231),(-85.177284,29.700193),(-85.22745,29.693633),(-85.259719,29.681296),(-85.29074,29.684081),(-85.319215,29.681494),(-85.343619,29.672004),(-85.347711,29.66719),(-85.344768,29.654793),(-85.352615,29.659787),(-85.369419,29.681048),(-85.380303,29.698485),(-85.397871,29.740498),(-85.413983,29.799865),(-85.417971,29.828855),(-85.416548,29.842628),(-85.413575,29.85294),(-85.405815,29.865817),(-85.392469,29.870914),(-85.39874,29.859267),(-85.405011,29.830151),(-85.405907,29.80193),(-85.395528,29.762368),(-85.37796,29.709621),(-85.3638,29.693526),(-85.353885,29.684765),(-85.344986,29.685015),(-85.317661,29.691286),(-85.31139,29.697557),(-85.301331,29.797117),(-85.302591,29.808094),(-85.304877,29.811096),(-85.31142,29.814373),(-85.314547,29.822279),(-85.314783,29.830575),(-85.312911,29.832273),(-85.317464,29.838894),(-85.325008,29.844966),(-85.332289,29.845905),(-85.336654,29.849295),(-85.347044,29.871981),(-85.363731,29.898915),(-85.38473,29.920949),(-85.405052,29.938487),(-85.425956,29.949888),(-85.460488,29.959579),(-85.469425,29.957788),(-85.487764,29.961227),(-85.509148,29.971466),(-85.541176,29.995791),(-85.571907,30.02644),(-85.58139,30.037783),(-85.591048,30.048874),(-85.601178,30.056342),(-85.618254,30.065481),(-85.637285,30.073319),(-85.653251,30.077839),(-85.69681,30.09689),(-85.730054,30.118153),(-85.74993,30.136537),(-85.775405,30.15629),(-85.811219,30.17832),(-85.878138,30.215619),(-85.9226,30.238024),(-85.999937,30.27078),(-86.089963,30.303569),(-86.222561,30.343585),(-86.2987,30.363049),(-86.364175,30.374524),(-86.412076,30.380346),(-86.470849,30.3839),(-86.50615,30.3823),(-86.529067,30.386896),(-86.632953,30.396299),(-86.750906,30.391881),(-86.850625,30.380967),(-86.909679,30.372423),(-87.155392,30.327748),(-87.206254,30.320943),(-87.267827,30.31548),(-87.282787,30.318744),(-87.295422,30.323503),(-87.319518,30.317814),(-87.350486,30.313064),(-87.419859,30.297128),(-87.518324,30.280435),(-87.51838,30.283901),(-87.50548,30.287101),(-87.49998,30.287901),(-87.452378,30.300201),(-87.450078,30.3111),(-87.455578,30.3102),(-87.459578,30.3083),(-87.462978,30.3078),(-87.465778,30.3076),(-87.468678,30.3082),(-87.475879,30.3079),(-87.481879,30.306001),(-87.483679,30.304801),(-87.494879,30.305001),(-87.50278,30.307301),(-87.50468,30.308901),(-87.50578,30.3125),(-87.505943,30.319396),(-87.504701,30.324039),(-87.502572,30.327405),(-87.49998,30.328957),(-87.491879,30.3309),(-87.475579,30.3314),(-87.464878,30.3333),(-87.462978,30.334),(-87.459978,30.3363),(-87.452278,30.344099),(-87.450962,30.346262),(-87.451978,30.360299),(-87.451878,30.364999),(-87.451378,30.367199),(-87.449078,30.370399),(-87.441823,30.376304),(-87.438678,30.380798),(-87.438678,30.382098),(-87.440878,30.386698),(-87.441178,30.388598),(-87.440678,30.391498),(-87.437278,30.395898),(-87.434278,30.397498),(-87.431778,30.403198),(-87.429578,30.406498),(-87.426177,30.409198),(-87.422677,30.410098),(-87.419177,30.410198),(-87.413177,30.408998),(-87.408877,30.408798),(-87.403477,30.410198),(-87.401777,30.411398),(-87.398776,30.415098),(-87.395676,30.417597),(-87.386376,30.420497),(-87.382076,30.422897),(-87.371169,30.43049),(-87.368191,30.433407),(-87.366591,30.436648),(-87.366939,30.44048),(-87.36868,30.444631),(-87.370768,30.446865),(-87.381176,30.450097),(-87.391976,30.451597),(-87.396877,30.450597),(-87.399877,30.450997),(-87.404677,30.452897),(-87.407877,30.456396),(-87.414677,30.457296),(-87.425078,30.465596),(-87.429578,30.470596),(-87.430578,30.476596),(-87.431578,30.477696),(-87.434678,30.479196),(-87.435578,30.480496),(-87.432978,30.484896),(-87.430578,30.491096),(-87.431178,30.495795),(-87.438269,30.505357),(-87.43969,30.506649),(-87.44322,30.506782),(-87.444714,30.507494),(-87.447702,30.510458),(-87.447782,30.511913),(-87.447305,30.512629),(-87.446499,30.513569),(-87.445182,30.51398),(-87.444944,30.514943),(-87.446427,30.520306),(-87.446586,30.527068),(-87.43544,30.54914),(-87.434963,30.549599),(-87.431441,30.550263),(-87.427891,30.554159),(-87.426037,30.560073),(-87.423362,30.561425),(-87.422805,30.561379),(-87.422408,30.560439),(-87.420925,30.560668),(-87.418647,30.561837),(-87.41666,30.566306),(-87.416951,30.568003),(-87.418513,30.569561),(-87.418354,30.570043),(-87.416261,30.572448),(-87.414513,30.573456),(-87.412712,30.573227),(-87.408736,30.583701),(-87.406558,30.599928),(-87.404597,30.603389),(-87.401178,30.604397),(-87.39927,30.605611),(-87.397308,30.608728),(-87.395026,30.615281),(-87.395053,30.6159),(-87.39643,30.616909),(-87.39643,30.617734),(-87.395659,30.623372),(-87.394479,30.625192),(-87.393775,30.627006),(-87.393588,30.63088),(-87.395941,30.643968),(-87.397185,30.648117),(-87.396177,30.650454),(-87.397262,30.654351),(-87.400177,30.657217),(-87.400707,30.657148),(-87.405874,30.666616),(-87.407118,30.671796),(-87.406561,30.674019),(-87.406958,30.675165),(-87.412739,30.678055),(-87.419527,30.679981),(-87.424883,30.683374),(-87.430372,30.688645),(-87.436021,30.688668),(-87.439814,30.690479),(-87.44228,30.692679),(-87.44358,30.694604),(-87.449362,30.698913),(-87.451404,30.699806),(-87.456948,30.69756),(-87.466338,30.700835),(-87.467717,30.701683),(-87.470397,30.705281),(-87.474429,30.706586),(-87.479579,30.712865),(-87.479819,30.71495),(-87.481225,30.716508),(-87.487036,30.7185),(-87.496772,30.720353),(-87.497515,30.720123),(-87.502317,30.72159),(-87.505153,30.726313),(-87.511729,30.733535),(-87.523613,30.738306),(-87.532607,30.743489),(-87.535365,30.749775),(-87.535416,30.75476),(-87.536528,30.761383),(-87.537085,30.76253),(-87.54226,30.767504),(-87.54616,30.77202),(-87.545364,30.774105),(-87.545044,30.778666),(-87.552051,30.786254),(-87.552954,30.786941),(-87.554838,30.787125),(-87.559484,30.790447),(-87.560068,30.792258),(-87.564209,30.796246),(-87.56814,30.799088),(-87.572043,30.800532),(-87.576849,30.808163),(-87.581869,30.812403),(-87.58787,30.815037),(-87.594297,30.816984),(-87.600486,30.820627),(-87.60163,30.82514),(-87.60357,30.828624),(-87.605776,30.831304),(-87.610982,30.832632),(-87.615923,30.834693),(-87.615367,30.837031),(-87.617281,30.840353),(-87.624137,30.845713),(-87.626075,30.846494),(-87.627323,30.847961),(-87.626497,30.85188),(-87.62538,30.854355),(-87.626228,30.857127),(-87.628245,30.860131),(-87.634938,30.865886),(-87.629987,30.877686),(-87.629454,30.880115),(-87.6244,30.884696),(-87.622062,30.885408),(-87.620788,30.887494),(-87.620922,30.889923),(-87.622519,30.89368),(-87.622203,30.897508),(-87.620715,30.89893),(-87.616013,30.901453),(-87.614951,30.904226),(-87.614209,30.908536),(-87.611847,30.914541),(-87.6102,30.916628),(-87.608262,30.9219),(-87.607811,30.92449),(-87.602684,30.934277),(-87.600691,30.937074),(-87.598299,30.938793),(-87.59689,30.941131),(-87.592055,30.951492),(-87.589187,30.964464),(-87.590917,30.969414),(-87.593046,30.972966),(-87.594111,30.976335),(-87.594164,30.977572),(-87.592676,30.98014),(-87.593395,30.982959),(-87.596722,30.98761),(-87.599172,30.995722),(-87.598928,30.997457),(-87.571281,30.99787),(-87.548543,30.997927),(-87.51952,30.997586),(-87.480243,30.998202),(-87.479703,30.998197),(-87.478706,30.998213),(-87.466879,30.998178),(-87.466827,30.998178),(-87.461783,30.998201),(-87.461638,30.998202),(-87.458658,30.998386),(-87.455705,30.998318),(-87.449811,30.998272),(-87.432292,30.998205),(-87.425774,30.99809),(-87.367842,30.998292),(-87.364011,30.998218),(-87.355656,30.998244),(-87.333973,30.998272),(-87.312183,30.998435),(-87.30403,30.998191),(-87.301567,30.998434),(-87.290995,30.998352),(-87.288905,30.998345),(-87.265564,30.998267),(-87.26054,30.998195),(-87.259689,30.998172),(-87.25796,30.998263),(-87.257002,30.998194),(-87.255592,30.998216),(-87.25498,30.998285),(-87.237685,30.996393),(-87.224746,30.997169),(-87.162614,30.999055),(-87.140755,30.999532),(-87.124969,30.998802),(-87.118873,30.999427),(-87.068633,30.999143),(-87.064063,30.999191),(-87.053737,30.999131),(-87.039989,30.999594),(-87.036366,30.999348),(-87.027107,30.999255),(-87.004359,30.999316),(-86.998477,30.998661),(-86.92781,30.997704),(-86.888135,30.997577),(-86.872989,30.997631),(-86.831934,30.997378),(-86.830497,30.997401),(-86.785918,30.996978),(-86.74524,30.99629),(-86.728392,30.996739),(-86.727293,30.996882),(-86.725379,30.996872),(-86.706261,30.994703),(-86.678383,30.994537),(-86.664681,30.994534),(-86.567586,30.995109),(-86.563436,30.995223),(-86.519938,30.993245),(-86.512834,30.9937),(-86.49995,30.99334),(-86.458319,30.993998),(-86.454704,30.993791),(-86.404912,30.994049),(-86.391937,30.994172),(-86.388647,30.994181),(-86.374545,30.994474),(-86.36927,30.994477),(-86.364907,30.994455),(-86.304596,30.994029),(-86.289247,30.993798),(-86.256448,30.993853),(-86.238335,30.99437),(-86.180232,30.994005),(-86.175204,30.993798),(-86.168979,30.993706),(-86.162886,30.993682),(-86.116918,30.992917),(-86.056213,30.993133),(-86.052462,30.993247),(-86.035039,30.99332),(-85.998643,30.99287),(-85.893543,30.993467),(-85.749932,30.994837),(-85.749619,30.995292),(-85.498272,30.996928),(-85.243632,31.000884),(-85.154452,31.000835),(-85.152218,31.000834),(-85.152085,31.000888),(-85.145835,31.000695),(-85.057534,31.000585),(-85.054802,31.000585),(-85.052088,31.000585),(-85.031155,31.000647),(-85.030107,31.000653),(-85.027512,31.00067),(-85.024108,31.000681),(-85.002368,31.000682),(-85.0019,31.000681),(-85.001819,30.997889),(-85.00254,30.986899),(-85.005934,30.979804),(-85.005931,30.97704),(-85.005105,30.974704),(-85.004026,30.973468),(-84.999928,30.971186),(-84.999828,30.971486),(-84.997628,30.971186),(-84.988027,30.968786),(-84.984827,30.967486),(-84.982527,30.965586),(-84.980127,30.961286),(-84.979627,30.958986),(-84.979627,30.954686),(-84.982227,30.946886),(-84.983027,30.942586),(-84.983627,30.936986),(-84.983127,30.934786),(-84.980627,30.932687),(-84.975226,30.930787),(-84.971026,30.928187),(-84.969426,30.921987),(-84.966726,30.917287),(-84.956125,30.907587),(-84.952325,30.902287),(-84.949625,30.897387),(-84.942525,30.888488),(-84.941325,30.887688),(-84.939974,30.886728),(-84.938087,30.885627),(-84.936828,30.884683),(-84.935413,30.882481),(-84.93557,30.878707),(-84.937615,30.875876),(-84.938401,30.873045),(-84.937772,30.870528),(-84.935728,30.86754),(-84.934627,30.865495),(-84.933997,30.863293),(-84.934627,30.86062),(-84.935413,30.858418),(-84.935256,30.854328),(-84.933224,30.851488),(-84.930065,30.848824),(-84.928807,30.846779),(-84.928335,30.844263),(-84.928335,30.842532),(-84.929436,30.840331),(-84.931953,30.837499),(-84.934155,30.834039),(-84.935256,30.830894),(-84.93557,30.824603),(-84.936042,30.820671),(-84.935413,30.81721),(-84.930923,30.810489),(-84.928323,30.80509),(-84.927923,30.80279),(-84.929023,30.79729),(-84.928323,30.79309),(-84.926723,30.79019),(-84.918023,30.77809),(-84.917423,30.77589),(-84.918023,30.77209),(-84.920123,30.76599),(-84.915022,30.761191),(-84.914322,30.753591),(-84.913522,30.752291),(-84.911122,30.751191),(-84.906322,30.750591),(-84.903122,30.751791),(-84.900222,30.751891),(-84.897622,30.751391),(-84.896122,30.750591),(-84.887522,30.741791),(-84.885221,30.734991),(-84.883821,30.732591),(-84.875421,30.727491),(-84.869752,30.721897),(-84.864693,30.711542),(-84.836324,30.710709),(-84.644815,30.701992),(-84.606386,30.699865),(-84.606249,30.699872),(-84.53937,30.696775),(-84.535042,30.696523),(-84.474409,30.692793),(-84.374905,30.689794),(-84.28121,30.685256),(-84.2499,30.684145),(-84.124895,30.678046),(-84.107699,30.676818),(-84.057228,30.674705),(-84.046605,30.6742),(-84.04181,30.673878),(-84.039707,30.673819),(-84.007391,30.672097),(-83.880317,30.665807),(-83.88022,30.665832),(-83.855216,30.664412),(-83.820886,30.662612),(-83.810536,30.66188),(-83.676773,30.654905),(-83.674058,30.654747),(-83.611667,30.651255),(-83.499876,30.645671),(-83.448895,30.64241),(-83.440021,30.642023),(-83.429584,30.641496),(-83.429477,30.641519),(-83.390062,30.639333),(-83.37946,30.63868),(-83.341011,30.636346),(-83.311647,30.634577),(-83.309455,30.634417),(-83.187391,30.627223),(-83.174411,30.626444),(-83.163309,30.625895),(-83.15617,30.625504),(-83.13137,30.623583),(-82.878779,30.609082),(-82.877259,30.609024),(-82.698902,30.598271),(-82.698618,30.598232),(-82.689271,30.597719),(-82.569237,30.590965),(-82.565476,30.590622),(-82.553159,30.589934),(-82.545055,30.589361),(-82.536233,30.588885),(-82.524899,30.588189),(-82.459544,30.584272),(-82.374844,30.579004),(-82.287343,30.573458),(-82.2581,30.571559),(-82.249841,30.570863),(-82.214839,30.568591),(-82.214385,30.566958),(-82.218579,30.564403),(-82.223025,30.56321),(-82.227254,30.561041),(-82.231916,30.55627),(-82.235603,30.544885),(-82.23582,30.537187),(-82.234952,30.533066),(-82.230752,30.526758),(-82.229399,30.520823),(-82.230377,30.517339),(-82.226933,30.510281),(-82.225026,30.50783),(-82.218514,30.504187),(-82.212852,30.498751),(-82.206445,30.491877),(-82.201416,30.485164),(-82.200938,30.474438),(-82.204614,30.468868),(-82.207708,30.460503),(-82.207522,30.456928),(-82.20604,30.455507),(-82.204823,30.45184),(-82.203975,30.444507),(-82.206486,30.437081),(-82.20987,30.432818),(-82.210291,30.42459),(-82.204151,30.40133),(-82.19294,30.378779),(-82.189847,30.375938),(-82.183797,30.373712),(-82.180018,30.368625),(-82.171508,30.359869),(-82.170054,30.358929),(-82.165192,30.358035),(-82.161757,30.357851),(-82.158109,30.359913),(-82.143282,30.363393),(-82.116385,30.367335),(-82.104834,30.368319),(-82.1025,30.367823),(-82.101416,30.366556),(-82.101798,30.365336),(-82.094687,30.360781),(-82.081106,30.358806),(-82.068533,30.359184),(-82.060034,30.360328),(-82.050069,30.362338),(-82.047917,30.363265),(-82.040746,30.370158),(-82.036825,30.377884),(-82.035871,30.385287),(-82.041164,30.396841),(-82.04199,30.403266),(-82.041164,30.409966),(-82.039971,30.41428),(-82.034005,30.422357),(-82.034464,30.428048),(-82.037209,30.434518),(-82.036203,30.43846),(-82.030064,30.444853),(-82.028212,30.447396),(-82.025457,30.457755),(-82.023734,30.467289),(-82.017779,30.475081),(-82.016982,30.478779),(-82.017297,30.487638),(-82.018222,30.492085),(-82.015892,30.495499),(-82.01477,30.513009),(-82.015826,30.518166),(-82.01699,30.519358),(-82.018868,30.523828),(-82.018361,30.531184),(-82.013216,30.550091),(-82.005477,30.563495),(-82.008091,30.577018),(-82.012109,30.593773),(-82.015708,30.601704),(-82.016503,30.602484),(-82.026941,30.606153),(-82.027338,30.606726),(-82.026541,30.613303),(-82.028499,30.621829),(-82.033927,30.629603),(-82.037609,30.633271),(-82.039941,30.637144),(-82.039092,30.641132),(-82.039595,30.643309),(-82.042271,30.649452),(-82.046114,30.651767),(-82.049507,30.655548),(-82.050432,30.676266),(-82.041812,30.692376),(-82.036426,30.706585),(-82.037563,30.71864),(-82.039154,30.723178),(-82.04101,30.72508),(-82.043795,30.729641),(-82.041168,30.734248),(-82.040026,30.737548),(-82.039634,30.747727),(-82.038967,30.749262),(-82.035964,30.750998),(-82.032645,30.750674),(-82.0284,30.750981),(-82.017917,30.755263),(-82.01266,30.761289),(-82.011597,30.763122),(-82.017881,30.775844),(-82.024035,30.783156),(-82.023848,30.786685),(-82.022866,30.787991),(-82.017051,30.791657),(-82.007865,30.792937),(-82.004973,30.791744),(-81.994972,30.786073),(-81.990855,30.781611),(-81.988605,30.780056),(-81.981273,30.776767),(-81.979061,30.776415),(-81.973856,30.778487),(-81.962534,30.796526),(-81.961989,30.800443),(-81.962441,30.808441),(-81.962739,30.813636),(-81.962175,30.818001),(-81.959759,30.821168),(-81.949787,30.827493),(-81.943168,30.827434),(-81.938381,30.825745),(-81.935444,30.821131),(-81.934655,30.820424),(-81.924448,30.817566),(-81.910926,30.815889),(-81.906279,30.817015),(-81.903745,30.818986),(-81.902337,30.820817),(-81.89938,30.821662),(-81.89572,30.821098),(-81.892904,30.819268),(-81.891281,30.815945),(-81.882725,30.805124),(-81.876882,30.799516),(-81.868608,30.792754),(-81.852626,30.794439),(-81.846286,30.790548),(-81.842058,30.78712),(-81.840375,30.786384),(-81.827014,30.788933),(-81.808529,30.790014),(-81.806652,30.789683),(-81.792769,30.784432),(-81.78435,30.77359),(-81.782653,30.769937),(-81.779171,30.768062),(-81.775021,30.76833),(-81.772611,30.769535),(-81.770468,30.772481),(-81.768192,30.773954),(-81.763372,30.77382),(-81.759338,30.771377),(-81.755074,30.768319),(-81.751283,30.767082),(-81.747572,30.766455),(-81.746312,30.765891),(-81.745035,30.765039),(-81.744183,30.763868),(-81.743438,30.762271),(-81.743094,30.759912),(-81.742736,30.759201),(-81.732227,30.749634),(-81.727127,30.746934),(-81.719927,30.744634),(-81.694778,30.748414),(-81.692815,30.7471),(-81.691818,30.74399),(-81.69099,30.742841),(-81.688925,30.741434),(-81.672824,30.738935),(-81.670124,30.740235),(-81.669324,30.741335),(-81.668275,30.744643),(-81.667336,30.74566),(-81.664598,30.746599),(-81.662173,30.746521),(-81.656541,30.745113),(-81.652123,30.742435),(-81.651723,30.740235),(-81.652161,30.735648),(-81.65177,30.732284),(-81.65044,30.729703),(-81.649188,30.728686),(-81.646137,30.727591),(-81.633266,30.729603),(-81.629609,30.732407),(-81.625098,30.733017),(-81.621929,30.731188),(-81.620822,30.729535),(-81.619613,30.724849),(-81.617663,30.722046),(-81.609495,30.720705),(-81.607667,30.721924),(-81.605716,30.725337),(-81.60401,30.727287),(-81.601206,30.728141),(-81.593648,30.725459),(-81.58682,30.723735),(-81.573719,30.722336),(-81.571419,30.721636),(-81.566219,30.717836),(-81.561706,30.715597),(-81.552566,30.716974),(-81.549186,30.715972),(-81.546932,30.714345),(-81.544679,30.713969),(-81.542675,30.713593),(-81.540923,30.713343),(-81.539295,30.713468),(-81.537668,30.714345),(-81.535539,30.716348),(-81.534517,30.717936),(-81.534037,30.719853),(-81.532785,30.721606),(-81.530531,30.722858),(-81.528278,30.723359),(-81.521417,30.722536),(-81.516116,30.722236),(-81.507216,30.722936),(-81.489537,30.7261),(-81.487332,30.726081),(-81.483786,30.723891),(-81.475754,30.714754),(-81.472597,30.713312),(-81.464465,30.711045),(-81.459978,30.710434),(-81.448718,30.709353),(-81.444124,30.709714),(-81.432725,30.703017),(-81.42742,30.69802),(-81.430843,30.669393),(-81.443099,30.600938),(-81.442564,30.555189),(-81.434064,30.522569),(-81.447087,30.503679),(-81.440108,30.497678),(-81.42601,30.496739),(-81.410809,30.482039),(-81.407008,30.42204),(-81.397422,30.400626),(-81.39736,30.396967),(-81.389789,30.397422),(-81.397067,30.379511),(-81.396407,30.34004),(-81.391606,30.303441),(-81.385505,30.273841),(-81.355591,30.162563),(-81.308978,29.96944),(-81.295268,29.928614),(-81.288955,29.91518),(-81.27654,29.90046),(-81.270442,29.883106),(-81.264693,29.858212),(-81.263396,29.820663),(-81.256711,29.784693),(-81.240924,29.739218),(-81.229015,29.714693),(-81.211565,29.667085),(-81.163581,29.55529),(-81.123896,29.474465),(-81.046678,29.307856),(-80.966176,29.14796),(-80.944376,29.110861),(-80.907275,29.064262),(-80.893675,29.036163),(-80.878275,29.010563),(-80.787021,28.875266),(-80.709725,28.756692),(-80.647288,28.677875),(-80.61679,28.634561),(-80.583884,28.597705),(-80.574868,28.585166),(-80.567361,28.562353),(-80.560973,28.530736),(-80.536115,28.478647),(-80.525094,28.459454),(-80.526732,28.451705),(-80.562877,28.437779),(-80.574136,28.427764),(-80.587813,28.410856),(-80.596174,28.390682),(-80.603374,28.363983),(-80.606874,28.336484),(-80.608074,28.311285),(-80.604214,28.257733),(-80.589975,28.17799),(-80.566432,28.09563),(-80.547675,28.048795),(-80.508871,27.970477),(-80.446973,27.861954),(-80.447179,27.859731),(-80.383695,27.740045),(-80.351717,27.642623),(-80.350553,27.628361),(-80.34437,27.616226),(-80.330956,27.597541),(-80.324699,27.569178),(-80.311757,27.524625),(-80.30117,27.500314),(-80.293171,27.500314),(-80.265535,27.420542),(-80.253665,27.37979),(-80.233538,27.341307),(-80.226753,27.322736),(-80.19309,27.249546),(-80.16147,27.192814),(-80.153375,27.169308),(-80.159554,27.163325),(-80.14982,27.143557),(-80.138605,27.111517),(-80.116772,27.072397),(-80.093909,27.018587),(-80.046263,26.859238),(-80.031362,26.796339),(-80.03212,26.77153),(-80.036362,26.77124),(-80.037462,26.76634),(-80.032862,26.715242),(-80.032862,26.700842),(-80.035763,26.676043),(-80.035363,26.612346),(-80.038863,26.569347),(-80.050363,26.509549),(-80.060564,26.444652),(-80.070564,26.336455),(-80.072264,26.335356),(-80.075264,26.318656),(-80.079865,26.264358),(-80.085565,26.249259),(-80.089365,26.231859),(-80.101366,26.147762),(-80.105266,26.096264),(-80.109566,26.087165),(-80.117778,25.986369),(-80.117904,25.915772),(-80.12087,25.883152),(-80.119684,25.841043),(-80.122056,25.817913),(-80.127394,25.791224),(-80.127987,25.772245),(-80.137476,25.750301),(-80.144,25.740812),(-80.152896,25.702855),(-80.154082,25.683283),(-80.152303,25.676759),(-80.154972,25.66549),(-80.160903,25.664897),(-80.176916,25.685062),(-80.170392,25.710565),(-80.164461,25.721833),(-80.166241,25.72895),(-80.172765,25.737847),(-80.184626,25.745557),(-80.197674,25.74437),(-80.229107,25.732509),(-80.240376,25.724206),(-80.244528,25.717089),(-80.250459,25.688028),(-80.265879,25.658373),(-80.267065,25.651849),(-80.277147,25.637022),(-80.288416,25.630498),(-80.296719,25.622195),(-80.301464,25.613299),(-80.305615,25.593134),(-80.305615,25.575342),(-80.302057,25.567632),(-80.313918,25.539164),(-80.324594,25.535605),(-80.328746,25.53264),(-80.339421,25.499427),(-80.339421,25.478669),(-80.337049,25.465621),(-80.328152,25.443084),(-80.320442,25.437153),(-80.326373,25.422919),(-80.32578,25.39801),(-80.320442,25.391486),(-80.31036,25.389707),(-80.306801,25.384369),(-80.31036,25.3731),(-80.335269,25.338701),(-80.352469,25.329805),(-80.361662,25.327433),(-80.374116,25.31735),(-80.383013,25.301337),(-80.37969,25.288463),(-80.393438,25.271965),(-80.394469,25.253061),(-80.412686,25.248593),(-80.418872,25.235532),(-80.432621,25.235876),(-80.442588,25.24275),(-80.462833,25.236247),(-80.467824,25.23254),(-80.469842,25.230443),(-80.481136,25.226046),(-80.4887,25.226936),(-80.49315,25.225157),(-80.49315,25.218482),(-80.485865,25.211281),(-80.488035,25.206942),(-80.495341,25.199463),(-80.498644,25.20015),(-80.508113,25.206719),(-80.512928,25.216719),(-80.520359,25.220788),(-80.52319,25.22008),(-80.530207,25.216207),(-80.53464,25.211252),(-80.535197,25.207915),(-80.532416,25.19846),(-80.536309,25.197348),(-80.554107,25.209027),(-80.556888,25.207915),(-80.556888,25.197348),(-80.563006,25.191786),(-80.569124,25.190117),(-80.584771,25.200665),(-80.609609,25.181901),(-80.619024,25.177328),(-80.624185,25.183443),(-80.605275,25.190674),(-80.605275,25.195123),(-80.610837,25.19846),(-80.645876,25.189005),(-80.655331,25.184556),(-80.659224,25.17955),(-80.654219,25.177881),(-80.63364,25.181775),(-80.63399,25.176829),(-80.640275,25.17662),(-80.645822,25.174029),(-80.649251,25.168708),(-80.648657,25.157859),(-80.651994,25.151185),(-80.650326,25.147292),(-80.650326,25.144511),(-80.669236,25.137837),(-80.67591,25.13728),(-80.677578,25.142286),(-80.661449,25.155078),(-80.655887,25.161752),(-80.656942,25.168216),(-80.67985,25.166751),(-80.678273,25.172042),(-80.681611,25.173293),(-80.697462,25.162865),(-80.695037,25.157588),(-80.70127,25.146683),(-80.703718,25.139115),(-80.709141,25.144511),(-80.712896,25.151185),(-80.717901,25.154522),(-80.723324,25.152019),(-80.719153,25.148682),(-80.721885,25.145101),(-80.742877,25.142646),(-80.755991,25.150038),(-80.756642,25.155904),(-80.764464,25.159163),(-80.768374,25.157859),(-80.765767,25.148082),(-80.769678,25.137002),(-80.777499,25.135047),(-80.780758,25.139609),(-80.775544,25.149386),(-80.782062,25.161118),(-80.791186,25.16177),(-80.795097,25.157207),(-80.795097,25.144824),(-80.798356,25.140913),(-80.802266,25.140913),(-80.804874,25.1546),(-80.796218,25.17245),(-80.798356,25.179367),(-80.807481,25.181975),(-80.809436,25.178064),(-80.806177,25.17285),(-80.815183,25.164959),(-80.82653,25.160478),(-80.830034,25.168094),(-80.838227,25.174791),(-80.846395,25.17706),(-80.858167,25.176576),(-80.87546,25.174321),(-80.900066,25.162034),(-80.901617,25.153803),(-80.898911,25.147652),(-80.900577,25.139669),(-80.915924,25.141301),(-80.943216,25.134443),(-80.957427,25.135704),(-80.971765,25.133958),(-80.999176,25.124222),(-81.009598,25.125403),(-81.022989,25.129393),(-81.050505,25.128273),(-81.079859,25.118797),(-81.094524,25.127054),(-81.111943,25.14547),(-81.120616,25.152302),(-81.133567,25.156295),(-81.141024,25.163868),(-81.142278,25.183),(-81.146737,25.193139),(-81.155481,25.208098),(-81.172044,25.222276),(-81.170907,25.245857),(-81.168307,25.253178),(-81.16207,25.289833),(-81.159293,25.298595),(-81.1523,25.305543),(-81.148915,25.318067),(-81.151916,25.324766),(-81.148103,25.332793),(-81.140099,25.341117),(-81.133913,25.342996),(-81.12141,25.33875),(-81.118208,25.34522),(-81.117265,25.354953),(-81.128492,25.380511),(-81.141395,25.381358),(-81.150508,25.387255),(-81.150656,25.399206),(-81.147144,25.404297),(-81.146765,25.407577),(-81.168652,25.463848),(-81.179406,25.475427),(-81.191924,25.484745),(-81.208201,25.504937),(-81.210149,25.516888),(-81.203175,25.53416),(-81.204389,25.538908),(-81.209321,25.548611),(-81.225557,25.55847),(-81.232705,25.573366),(-81.233051,25.586587),(-81.240519,25.599041),(-81.240677,25.613629),(-81.253951,25.638181),(-81.268924,25.656927),(-81.277374,25.66498),(-81.290328,25.687506),(-81.328935,25.717233),(-81.335037,25.715649),(-81.346078,25.721473),(-81.345972,25.736536),(-81.343984,25.747668),(-81.346767,25.754029),(-81.355116,25.76039),(-81.359489,25.766354),(-81.361875,25.772715),(-81.344779,25.782257),(-81.340406,25.786631),(-81.341598,25.794582),(-81.349152,25.816847),(-81.352731,25.822015),(-81.362272,25.824401),(-81.386127,25.839906),(-81.394476,25.851834),(-81.417536,25.864954),(-81.424295,25.867737),(-81.429066,25.865351),(-81.441391,25.863761),(-81.458487,25.868929),(-81.471607,25.881652),(-81.473992,25.888411),(-81.48751,25.888411),(-81.501027,25.884037),(-81.508979,25.884037),(-81.512955,25.886423),(-81.511762,25.89676),(-81.515738,25.899941),(-81.527665,25.901531),(-81.541183,25.900338),(-81.577363,25.889206),(-81.584519,25.888808),(-81.614735,25.893977),(-81.623482,25.897158),(-81.644553,25.897953),(-81.654493,25.893579),(-81.663821,25.885605),(-81.672633,25.856654),(-81.678287,25.845301),(-81.6848,25.847205),(-81.68954,25.85271),(-81.713172,25.897568),(-81.717687,25.902039),(-81.727086,25.907207),(-81.73195,25.931506),(-81.738118,25.942009),(-81.745579,25.949643),(-81.749724,25.960463),(-81.747834,25.994273),(-81.750668,25.998425),(-81.757463,26.000374),(-81.762439,26.00607),(-81.801663,26.088227),(-81.808833,26.152246),(-81.81461,26.173167),(-81.81681,26.207166),(-81.820675,26.236735),(-81.833142,26.294518),(-81.844555,26.327712),(-81.868983,26.378648),(-81.90191,26.410859),(-81.90271,26.416159),(-81.91171,26.427158),(-81.923611,26.436658),(-81.938411,26.445058),(-81.956611,26.452358),(-81.964212,26.457957),(-81.967112,26.462857),(-81.966212,26.465057),(-81.969509,26.476505),(-81.980712,26.480957),(-81.997012,26.484856),(-82.008961,26.484052),(-82.01368,26.490829),(-82.00908,26.505203),(-82.024604,26.512677),(-82.043577,26.519577),(-82.06715,26.513252),(-82.07175,26.492554),(-82.094748,26.48393),(-82.105672,26.48393),(-82.111996,26.54085),(-82.118896,26.560973),(-82.122345,26.579371),(-82.137869,26.637441),(-82.149943,26.654115),(-82.181565,26.681712),(-82.17984,26.696661),(-82.173516,26.701836),(-82.151668,26.704136),(-82.139019,26.702986),(-82.125795,26.699536),(-82.118896,26.690912),(-82.106247,26.667339),(-82.099922,26.662739),(-82.093023,26.665614),(-82.086698,26.685162),(-82.084974,26.702411),(-82.079799,26.716784),(-82.066575,26.742657),(-82.061401,26.774279),(-82.061401,26.789228),(-82.055076,26.802452),(-82.057951,26.822),(-82.058526,26.838674),(-82.056801,26.858797),(-82.059101,26.876621),(-82.066575,26.88237),(-82.090723,26.888694),(-82.093023,26.906518),(-82.090148,26.923191),(-82.083249,26.927791),(-82.067725,26.927791),(-82.061976,26.931241),(-82.061401,26.938715),(-82.063126,26.950214),(-82.076349,26.958263),(-82.107972,26.957688),(-82.117171,26.954239),(-82.124645,26.945615),(-82.137294,26.926066),(-82.162017,26.925491),(-82.169491,26.923191),(-82.175241,26.916867),(-82.172941,26.897319),(-82.156267,26.851898),(-82.147068,26.789803),(-82.151093,26.783479),(-82.172941,26.778879),(-82.17869,26.772555),(-82.221812,26.77198),(-82.233311,26.784054),(-82.241935,26.774279),(-82.251134,26.755881),(-82.259867,26.717398),(-82.263804,26.725644),(-82.264682,26.756836),(-82.269499,26.784674),(-82.289086,26.827784),(-82.301736,26.841588),(-82.351649,26.908384),(-82.400618,26.984937),(-82.419218,27.020736),(-82.445718,27.060634),(-82.460319,27.099933),(-82.465319,27.110732),(-82.46889,27.113612),(-82.477019,27.141231),(-82.512319,27.207528),(-82.539719,27.254326),(-82.54512,27.261026),(-82.55902,27.268826),(-82.569754,27.279452),(-82.569248,27.298588),(-82.57602,27.309324),(-82.597629,27.335754),(-82.623863,27.362206),(-82.642821,27.38972),(-82.675121,27.424318),(-82.691821,27.437218),(-82.691004,27.444331),(-82.707821,27.487615),(-82.714521,27.500415),(-82.724522,27.513614),(-82.743017,27.531086),(-82.745748,27.538834),(-82.742437,27.53936),(-82.708121,27.523514),(-82.710621,27.501715),(-82.706821,27.498415),(-82.690421,27.496415),(-82.686421,27.497215),(-82.686921,27.508015),(-82.683621,27.513115),(-82.674621,27.519614),(-82.66202,27.522814),(-82.65072,27.523115),(-82.646014,27.53354),(-82.632053,27.551908),(-82.612019,27.571231),(-82.613003,27.582837),(-82.611717,27.585283),(-82.596488,27.594045),(-82.584629,27.596021),(-82.570607,27.608882),(-82.565667,27.615713),(-82.558538,27.638678),(-82.537146,27.672933),(-82.514265,27.705588),(-82.494891,27.718963),(-82.482449,27.719886),(-82.477638,27.723004),(-82.476297,27.729929),(-82.477129,27.735216),(-82.482305,27.742649),(-82.478339,27.74625),(-82.457543,27.752571),(-82.434635,27.764355),(-82.43198,27.768092),(-82.433981,27.774087),(-82.419066,27.793767),(-82.418401,27.803187),(-82.410837,27.810868),(-82.402857,27.812671),(-82.393383,27.837519),(-82.397463,27.851631),(-82.402615,27.882602),(-82.413915,27.901401),(-82.432316,27.901301),(-82.451591,27.907506),(-82.453731,27.908546),(-82.461914,27.908431),(-82.462459,27.920248),(-82.461055,27.938161),(-82.478063,27.92768)]

Here is an image of the issue:

Ty


Fix incorrect preprocessor usage of LwIP PBUF_POOL

Configuration allowed specifying an LwIP pbuf_type value for System::PacketBuffer allocations, and code tested this configuration in preprocessor conditions; however, the LwIP names are enum constants, not preprocessor defintions.
This change replaces the configuration macro with a new one selecting between PBUF_POOL and PBUF_RAM. (From PR#14257 that introduced the configuration, it does not appear that other options were ever used.)
Fixes #29208

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Kevin Schoedel seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


1.1.7

The site needs cookie again. I need to get it to request.

Both user-agent and cookie are needed for this to work. Once I save the user-agent, the site should load properly (I hope).

The fix is working. Now, some refactors are needed for a better user experience.

The fix works for latest and one episode. However, it doesn't work for the anime list. Very strange and need to investigate.

Can be fixed by #42.

More testings are needed for now before releasing.


Fix threading issues in AKSequencerEngine

Fix issues discovered by TSAN
Improve threading correctness.

Does that mean we can re-enable TSAN runs in CI?

@megastep I'm afraid not. This was for some new code I added.


Direct routing CI test

Implemented in
                It("Check connectivity with automatic direct nodes routes", func() {


feat: Add zone ARN to outputs

Description
Add the route53 zone ARN to outputs.
Motivation and Context
ARN is needed in other modules.
Breaking Changes
No
How Has This Been Tested?

[x] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[x] I have tested and validated these changes using one or more of the provided examples/* projects

[x] I have executed pre-commit run -a on my pull request

@antonbabenko can you please review this pr.

This PR is included in version 2.10.0 :tada:


Reduce JWT exception chatter

Overview
We were getting our logs flooded with JWT token expiration stack traces. This commit removes the exception cascade that was leading to the traces. The AuthenticationException that gets thrown when a principal can't be read on a JWT is expected so we shouldn't be seeing that much information and be cluttering out important events.
Connects #255
Testing Instructions

Start the app
Create / log into a board
Modify the token in the cookies
Make sure network calls still 401
Make sure there is no stacktrace in the logs

Fixes #255


Upgrade sidekiq

Upgrades govuk sidekiq to the latest version
⚠ This repo is Continuously Deployed: make sure you follow the guidance ⚠
Follow these steps if you are doing a Rails upgrade.

As this PR is an example, I wanted to reference this logging fix which has been necessary on some other apps: https://github.com/alphagov/account-api/pull/577


Slow Queries - Add configuration of MAX_MEMORY on target

Discussed in https://github.com/trimble-oss/dba-dash/discussions/138
This setting is a potential fix for the issue described in the above discussion.
Note:
App already allows configuration of the WITH MAX_MEMORY setting for event buffering but configuration is needed for max_memory on the target.

https://www.sqlskills.com/blogs/jonathan/extended-events-ring_buffer/

Notes:
target max memory can be queried:
Normal SQL
SELECT e.*,f.value as max_memory
FROM sys.server_event_sessions e
LEFT JOIN sys.server_event_session_fields f ON e.event_session_id = f.event_session_id AND f.name = 'max_memory'

--total_target_memory (SQL 2022)
SELECT * FROM sys.dm_xe_sessions

Azure:
SELECT e.*,f.value as max_memory
FROM sys.database_event_sessions e
LEFT JOIN sys.database_event_session_fields f ON e.event_session_id = f.event_session_id AND f.name = 'max_memory'

--total_target_memory
SELECT * FROM sys.dm_xe_database_sessions

On Azure it seems to default to 32MB.
DBA Dash tracks the memory_used for the target in dbo.SlowQueriesStats.


Update the code so that long schema names do not cause errors when saving a report_file

User Story
As a developer, I would like the report_file.schema_name to support the length of schemas that we have
Description/Use Case
This column was originally setup to store the schema names from the covid pipeline which had a different convention that was much shorter (i.e. waters/waters-covid-19).  The schema names in the universal pipeline are now paths to schemas which can be substantially longer, but the column is only configured to allow for 63 characters.  In some places we are over the limit already metadata/fhir_transforms/senders/SimpleReport/simple-report-sender-transform, (through a current bug/quirk this is not recorded in the db) and in other places we are extremely close metadata/hl7_mapping/receivers/STLTs/VI/VI-receiver-transform.  Adding in classpath:/ and .yml tipped it so that the schemas we do record are greater than 63
Risks/Impacts/Considerations
Dev Notes

Altering the length of a varchar should not require a lock/rewrite on the table so this should be safe.  The migration would be something like ALTER TABLE report_file ALTER COLUMN schema_name TYPE VARCHAR(5000);

We should make sure to ask devops to check this beforehand since a table lock would require downtime

Acceptance Criteria

[ ] The temporary code is removed
[ ] Longer schema names do not cause an issue when saving a report_file

PR https://github.com/CDCgov/prime-reportstream/pull/14624 exists to implement this ticket but has received pushback from DevOps. TBD how to proceed.


Offline/Online Smarts for App

What the user will see:

[ ] when online (on desktop and mobile), reference data (map layers, other peoples records) are loaded seamlessly from the server
[ ] when offline (on mobile) reference data then becomes what was cached in trips.

Dev tasks:

[x] make a 'data access layer' that looks the same to the map, recordtable, and other components
[x] have it query either the back end API OR cached database for data based, and allow for paging records.

TODO in other tickets later:

[ ] offline sorting and filtering
[ ] online (API side) sorting and filtering

going to break this into smaller tasks so i dont have to keep looking at itj


⚠ Bofrost.de has degraded performance

In 4f34a12, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1426 ms

Resolved: Bofrost.de performance has improved in c485ffc.


getting unauthenticated error after install

hi , i installed this package and did every thing that documentation said . but when i open it it gives me the unauthenticated error like below :

and this is in my console :
http://localhost:8000/elfinder/connector?_token=o3oQdRCdwyZOcytiX0lHdD341WfY9DGt44ZFv1iy&cmd=open&target=&init=1&tree=1&_=1607243511786

Please make sure elfinder.php must exist under the config folder. Run below command to publish this config file.
php artisan vendor:publish --provider='Ridhima\MediaManager\Providers\MediaManagerServiceProvider'

well when i try to run that command i get this error :
Unable to locate publishable resources.
Publishing complete.

though i added the service provider and cleared cache :
   Webkul\Velocity\Providers\VelocityServiceProvider::class,
        Webkul\BookingProduct\Providers\BookingProductServiceProvider::class,
        Ridhima\MediaManager\Providers\MediaManagerServiceProvider::class

and the elfinder.php does not exist on config folder

Which method (composer or direct download under packages folder) you are using to install this package?

i required with composer like below :
Require this package with Composer

should i try the secound method ?

Both will work same. You can try another method meanwhile I will try to debug this on the new setup.

i solved this by coping the elfinder.php manually to app/config folder

Glad to know that you have solved the problem.

cool . thanks for the great package <3


mbedTLS rejects a cert while OpenSSL, GnuTLS, and wolfSSL accept it

Description

Type: Bug
Priority: Major

Bug
OS
Mbed OS linux
mbed TLS build:
Version: 2.25.0
OS version: 18.04, 20.04
Configuration: no
Compiler and options (if you used a pre-built binary, please indicate how you obtained it):  gcc 9.3.0
Additional environment information:  no
Peer device TLS stack and version
OpenSSL|GnuTls|Chrome|NSS(Firefox)|SecureChannel (IIS/Internet Explorer/Edge)|Other
Version:  OpenSSL 1.1.1f, GnuTLS  3.5.5 & 3.6.13, wolfSSL 4.6.0
Expected behavior
Consistent verification results among mbedTLS and others (i.e., OpenSSL, GnuTLS, and wolfSSL).
Actual behavior
  . Loading the CA root certificate ... ok (0 skipped)

  . Loading the certificate(s) ... failed
  !  mbedtls_x509_crt_parse_file returned -8320

Steps to reproduce
./cert_app mode=file ca_file=ca.pem filename=seed-5s26-41s18-189s27.pem
Attachments
ca.zip
seed-5s26-41s18-189s27.zip

Looking at the error code that was generated by the test, this is actually a feature that is not supported, rather than a bug.
Error code 8320 yields:
Unavailable feature, e.g. RSA hashing/encryption combination
when examined with programs/util/strerror.
Since this is labelled a bug report, and not a request to actually implement this feature, this issue will now be closed.

Looking at the error code that was generated by the test, this is actually a feature that is not supported, rather than a bug.
Error code 8320 yields:
Unavailable feature, e.g. RSA hashing/encryption combination
when examined with programs/util/strerror.
Since this is labelled a bug report, and not a request to actually implement this feature, this issue will now be closed.

Specifically, what is unsupported is the content of the CertificatePolicies extension. Mbed TLS only supports anyPolicy. This certificate has a different policy, so Mbed TLS is unable to determine whether it is permitted (it doesn't know what the caller wants to do with the certificate anyway) and rejects it.

Specifically, what is unsupported is the content of the CertificatePolicies extension. Mbed TLS only supports anyPolicy. This certificate has a different policy, so Mbed TLS is unable to determine whether it is permitted (it doesn't know what the caller wants to do with the certificate anyway) and rejects it.


Make a home page for ESAS

We could draft of a homepage for ESAS.

To clarify, you mean a homepage for the ESAS dataset at https://www.ices.dk/data/dataset-collections/Pages/Project-datasets.aspx?

To clarify, you mean a homepage for the ESAS dataset at https://www.ices.dk/data/dataset-collections/Pages/Project-datasets.aspx?

I assume Carlos means a landing page (for the portal) https://www.ices.dk/data/data-portals/Pages/default.aspx?

I assume Carlos means a landing page (for the portal) https://www.ices.dk/data/data-portals/Pages/default.aspx?

can we agree the vanity domain:
https://esas.ices.dk
OR
https://seabirds-at-sea.ices.dk

can we agree the vanity domain:
https://esas.ices.dk
OR
https://seabirds-at-sea.ices.dk

I would opt for esas.ices.dk but I'll let @nicolasvanermen weigh in as well.

I would opt for esas.ices.dk but I'll let @nicolasvanermen weigh in as well.

Perfect!
On Fri, Jan 8, 2021 at 11:29 AM Peter Desmet<EMAIL_ADDRESS>wrote:

I would opt for esas.ices.dk but I'll let @nicolasvanermen
https://github.com/nicolasvanermen weigh in as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ices-tools-dev/esas/issues/42#issuecomment-756680008,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABYKGXPW3DEZNOTUYZSHZ2TSY3NCJANCNFSM4VYVSSLQ
.

Perfect!
On Fri, Jan 8, 2021 at 11:29 AM Peter Desmet<EMAIL_ADDRESS>wrote:

I would opt for esas.ices.dk but I'll let @nicolasvanermen
https://github.com/nicolasvanermen weigh in as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ices-tools-dev/esas/issues/42#issuecomment-756680008,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABYKGXPW3DEZNOTUYZSHZ2TSY3NCJANCNFSM4VYVSSLQ
.

We have written a 2 paragraph summary of the ESAS database, intended for the homepage. It is already used on the GitHub website for the data model: https://ices-tools-dev.github.io/esas/

The European Seabirds At Sea (ESAS) database assembles monitoring data on offshore seabirds and marine mammals, collected and/or managed by 18 European organizations. This international database mostly includes data from the North Sea (dating back to 1979), but large parts of the northeastern Atlantic Ocean are covered as well. ESAS data are collected during at-sea surveys from a moving ship or aeroplane and according to a methodology that allows to calculate seabird densities. Standard practice further implies collecting as much information as possible on observation conditions, distance to the counted bird(s), age, plumage, behaviour and association with other marine wildlife and/or anthropogenic objects.
The ESAS database finds its origin in the 'Seabirds at Sea' project that was initiated in 1979 following the discovery of major oil potential in the North Sea and an urgent need to gain knowledge on seabird occurrence and distribution in their offshore habitat. The first European-wide data assembly was performed in 1991 and for about three decades the resulting ESAS database was hosted by the Joint Nature Conservation Committee (JNCC). As part of the Dutch WOZEP research project, the database was migrated to the International Council for the Exploration of the Sea (ICES) Data Centre in 2021. The aim of this particular project was a major update of the ESAS database and to make offshore seabird monitoring data more widely available.

@peterdesmet a good summary, perhaps worth denoting that the JNCC is a UK institution, other than that, looks good to go 👍

Adapted by adding UK-based.

@peterdesmet would need a one line 'news teaser' text that sits where it says 'some text here'

https://www.ices.dk/data/data-portals/Pages/European-Seabirds-at-sea.aspx

@neil-ices-dk not sure what to announce, do we need a one line news item or can we just drop it.
In the Resource links, you can remove the link to Github resources. A link to the Data Model is sufficient.

not sure what to announce, do we need a one line news item or can we just drop it.

thanks @peterdesmet it's really just a snappy one liner intro - the database in a sentence; see example here https://www.ices.dk/data/data-portals/Pages/underwater-noise.aspx (the text in light grey "Continuous and Impulsive noise measurements in support of regional sea assessments")
My suggestion would be to move the first sentence from the body text up into the teaser.
"The European Seabirds At Sea (ESAS) database assembles monitoring data on offshore seabirds and marine mammals, collected and/or managed by 18 European organizations."

Ah, ok. I would make the first sentence:

Monitoring data on offshore seabirds and marine mammals

@nicolasvanermen can then do a final review.

Looks good, thanks

Sorry, we had to make some changes to the home page text to make it easier to copy/paste to other places where we want to describe ESAS. Please see the updated version in https://docs.google.com/document/d/1JaDbchwtM5Z9E84ICkxpZKEJCv7mGes9lJMgXXx_Wpg/edit?usp=sharing

OK thanks, I added two small suggestions, also highlighting that the citation has not been adapted as suggested by Peter.

have updated the citation, i can't add the metadata record line yet as we don't have the record yet;
@nicolasvanermen - i can't see any changes in the Google doc as i don't have edit access, can you give me access or paste the suggestions below thanks

Shared the document...

One small more thing:  the title should also show capital A in European Seabirds At Sea

Great, looks good!
No, there is no need for copyright notice on the image.
Nicolas Vanermen
Scientific Employee
Research Institute for Nature and Forest
Havenlaan 88, box 73,
1000 Brussels, Belgium
+32 486 361 582
On Mon, Mar 28, 2022 at 8:39 PM Neil Holdsworth @.***>
wrote:

have implemented the changes suggested from
https://drive.google.com/drive/folders/17V01ngI4TPFOwMqHDt52hKBKOAjwDy80
with one small change (updated citation to 2022)
@nicolasvanermen https://github.com/nicolasvanermen do you need a
copyright notice on the image?
[image: image]
https://user-images.githubusercontent.com/23527005/160464517-bb0ee64e-04c3-41f1-a45f-cdeb18eb5f08.png
—
Reply to this email directly, view it on GitHub
https://github.com/ices-tools-dev/esas/issues/42#issuecomment-1081007326,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABYKGXIVP64FQINC2DAG453VCH4HTANCNFSM4VYVSSLQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


Multisig address derivation

~Depends on #18 (because it introduces Swift 5.1 behavior when handling an optional enum)~
This adds the ability to generate a multisig address for a set of public keys ([HDKey]) and a threshold (e.g. 2 of 2).
It adds a scriptPubKey initializer to Address, which uses a new witnessProgram property on ScriptPubKey. This should be expanded to handle different types of ScriptType (maybe in a different PR). See also #7.
It adds a multisig initializer to ScriptPubKey which uses wally_scriptpubkey_multisig_from_bytes internally: https://wally.readthedocs.io/en/release_0.7.5/script/#c.wally_scriptpubkey_multisig_from_bytes

Rebased and fixed some conflicts with #22


Every time menu item is clicked, screen is loaded again. How to solve this?

I'm sure it depends on the onTap implementation on your project.
In example folder, you can do it by checking first if the type is changed or still the same, such as here.

"It will make sure the content will only be reload when the type changed."
But I don't want to reload screen in any case, then how can we achieve this.

Ok. First thing, this example needs reload because it needs show many ways to use this drawer.
In normal application, we usually stick with one theme. So you don't need to copy the example as it is.
Mostly the menu item will click to navigate to other page, which you can do by calling Navigator.

So, in normal application, the menu item will be like:
MenuItem('Basic',
  icon: Icons.rss_feed,
   onTap: () => Navigator.push(context,
     MaterialPageRoute(builder: (context) => YourPage()),
  );
)

And in normal application we don't need to set _appKey like in here.
So the app will simply be:
return MaterialApp(
  title: 'Slide Drawer Demo',
  theme: ThemeData(
    primarySwatch: Colors.blue,
    visualDensity: VisualDensity.adaptivePlatformDensity,
  ),
  home: _home,
);


expect source code release !!!

We're currently preparing the code. Hopefully, it will be released in 2-3 months.
Thanks for your interest in our work!

@Tzy010822
Nice work!
Your Arxiv link to Cycle3D paper on your Project Pagehttps://pku-yuangroup.github.io/Cycle3D/ is pointing towards a different paper from last year: Repaint123

Thanks. I've fixed it.


HOPS-29

https://hopshadoop.atlassian.net/projects/HOPS/issues/HOPS-29?filter=allopenissues

retest this please


glob patterns for data_files

Would be great to be able to use glob patterns for data_files, so that one can write something like this:
[options.data_files]
share/myapp/doc = doc/*.md

This would be consistent with the way package_data works.

I have no great objections to this, though do we need some indication that it's to be interpreted as a glob pattern and not a literal string? Even if we limit it just to supporting *, asterisk is a valid character in a file or folder.

* in file names sounds like a weird edge case to me. It is going to cause trouble for users in many places. I don't think it is worth supporting, but then I haven't checked if it is taken into account in other parts of setuptools.

@agateau I'm not really willing to break backwards compatibility by changing the way these strings are interpreted from being paths to being glob patterns. An asterisk is a valid character for a file name, it's definitely something we want to support, regardless of whether it will break in other places as well.
We just need a way to differentiate between "interpret this as a path" and "interpret this as a glob", hopefully it's not terribly difficult.

@pganssle * is already interpreted as a wildcard in a number of places, just see the number of occurrences in the documentation all over the place.
It's really not interpreting it as a wildcard in a single place that breaks consistency with all the rest of the API.

@hydrargyrum Like I said above, I'm in favor of adding a way to do this, but it would be a backwards-incompatible change and would be removing the ability to literally specify files with asterisks in their names if we just start interpreting all file paths as glob literals.
As much as I am in favor of making common patterns easier in setup.cfg, it's still pretty easy to use glob.glob in setup.py, whereas if we make this backwards-incompatible change, it will be impossible to get the exact current behavior (likely in either setup.py or setup.cfg).
If we want to make actual progress on this issue, I think we need to come up with possible backwards-compatible interfaces that would allow this to move forward. I think they will broadly fall into four categories:

Special syntax for the specifier string that would not be a valid path on any supported OS, but would allow us to indicate that something is a glob pattern, e.g. ::glob::*.md (not sure if that is an invalid path on all supported OSes, just guessing)
Some sort of wrapper type, like GlobPattern('*.md')
A boolean option toggle defaulting to False that specifies that data_files should be interpreted as glob patterns.
A new option that specifies glob patterns, like data_files_pattern, which is always interpreted as a glob pattern.

Number 1 is probably the best option, but it's not terribly discoverable, and right now at least only data_files would requires this special syntax, which is not great. Number 2 would be great if this were for setup.py only, but I don't think there's any good way to specify a custom wrapper type in setup.cfg.
Numbers 3 and 4 are ugly mainly because you now have two different options to specify the same thing, and it may not be obvious to people what they do.
If anyone has better options or wants to argue for one of these, please do let me know, because none of the options seem terribly appealing to me.

Number 1 looks like the best option to me as well, because it would work for setup.py and setup.cfg, but this syntax should be usable for all keys were a glob pattern can be used.
While I respect your desire to not break compatibility, I have yet to find a package shipping files with asterisks in their names. I may be wrong on this, but I would be surprised if simply changing the code to accept asterisks would wreak so much havoc. Quoting the Zen of Python:

practicality beats purity.

The only invalid path on Unix is a null byte (and "/" cannot exist in filenames but validly denotes a directory separator).
It's theoretically possible but highly unlikely people wanted a literal asterisk in their file names, but by the same token that ":" is illegal on Windows, and in fact also illegal even on Unix if you happen to be using fat32 or NTFS without the POSIX namespace (the restriction is part of the filesystem spec)...
... the asterisk is also illegal in filenames on Windows (and at the filesystem layer on fat32 and NTFS).
So, such code depending on literal asterisks would unexpectedly fail on Windows, and also on that one person's USB drive used for copying around a personal python environment from Unix system to Unix system.
One could argue backwards compatibility with something inherently broken is not such an important priority, and even if someone did need that behavior, the asterisk would simply expand to multiple files including the one with the literal asterisk. So the package would collect too many files, but at least the desired file would in fact be there.
If we want to make it super unlikely for anyone to ever stumble across this by using some prefix marker like option 1, I don't think ::glob:: provides additional utility over glob: which would have symmetry with existing directives like file:, attr:, find:, and find_namespace:.

I discovered this issue while trying to migrate some other project off of pbr and onto the builtin setup.cfg support. Unfortunately, the project uses pbr's support for
[files]
data_files =
    share/foo = <glob>

so it cannot be mapped to [options.data_files] no matter how much I'd like... I'm not sure if I should propose a change that involves "oh, also reinstate setup.py as the logic driver in order to glob for files with glob.glob()".

Recently discovered the same thing and found this thread.
I have begrudgingly reinstituted a setup.py just to do some glob() calls, but I feel a new directive like glob: could be in-line with mannerisms of the setup.cfg syntax.

So, I've taken a whack at adding a glob: directive: https://github.com/pypa/setuptools/pull/2712 👀
I feel it's a relatively safe change as the behaviour is the same if the directive is not used. Open for any constructive feedback from anybody in any case.

Well, @pganssle's concern was, I think, that people might be using the new directive and actually mean it to be a literal filename instead of a directive... the question is whether that's a practical concern. So yeah, relatively safe.
Thanks for doing the legwork of actually implementing this!


sqoop sql import fail

Describe the question
this is my config.

this is error.
[INFO] 2020-10-14 11:20:47.387  - [taskAppId=TASK-1-11-27]:[121] -  -> 错误: 找不到或无法加载主类 org.apache.hadoop.hbase.util.GetJavaProperty
2020-10-14 11:20:47,342 INFO sqoop.Sqoop: Running Sqoop version: 1.4.7
2020-10-14 11:20:47,366 WARN tool.BaseSqoopTool: Setting your password on the command-line is insecure. Consider using -P instead.
Must specify destination with --target-dir.
Try --help for usage instructions.
Which version of DolphinScheduler:
-[1.3.2]

When query is used in sqoop, it is not possible to import hive tables directly.
You can first import the mysql data into a directory in HDFS, and then import it into the hive table by means of hive: load data inpath.
Use sqoop to import mysql into hive, 1 import the entire table | using --columns or where to deal with select data

When query is used in sqoop, it is not possible to import hive tables directly.
You can first import the mysql data into a directory in HDFS, and then import it into the hive table by means of hive: load data inpath.
Use sqoop to import mysql into hive, 1 import the entire table | using --columns or where to deal with select data

When query is used in sqoop, it is not possible to import hive tables directly.
You can first import the mysql data into a directory in HDFS, and then import it into the hive table by means of hive: load data inpath.
Use sqoop to import mysql into hive, 1 import the entire table | using --columns or where to deal with select data

can not add --target-dir to parameters?i think it can solve a problem.

emmmm... if you want to add sqoop custom param， please add param in sqoop custom text input。
如果要使用sqoop的自定义参数，请在sqoop组件的sqoop参数中进行设置。

emmmm... if you want to add sqoop custom param， please add param in sqoop custom text input。
如果要使用sqoop的自定义参数，请在sqoop组件的sqoop参数中进行设置。

emmm... I use dolphinScheduler 1.3.2，it can not set sqoop param。

yes，sqoop job can add custom sqoop param like -direct and custom hadoop param like mapreduce memory in ds-1.3.3。

yes，sqoop job can add custom sqoop param like -direct and custom hadoop param like mapreduce memory in ds-1.3.3。

yes，sqoop job can add custom sqoop param like -direct and custom hadoop param like mapreduce memory in ds-1.3.3。
thanks。

How to insert sqoop parameters like 'last-value'   in ds1.3.4?

How to insert sqoop parameters like 'last-value'   in ds1.3.4?


Script for setting up linux namespaces

This will let developers run a controller and device on the same
machines.
Problem
We don't have an very easy way to run device and controller on the same machine.
Change overview
Adds a script to allow running device and controller on the same linux machine using namespaces.
Testing
Tested manually using the lighting app and chip-device-ctrl. With ipv4 support, can ping both ways across the namespace in ipv4 and ipv6.

@cecille please restyle:)

For my edification, is this only needed because all instances of the sdk bind to port 11097?  That's a limitation of the sdk, not the spec.
I'm not saying this script isn't needed.  I just want to understand why it's needed.

Sorry all - I went to go work on some TE3 stuff and let this PR stagnate a bit. It's basically just a helper script for doing controller <-> device development on the same workstation. Being able to compile and test on a linux workstation is just faster than the pi. So you can run the device side using the script and the controller on the same machine. It's not intended as a full test system currently (because it still requires root access).

/rebase

Sorry all - I went to go work on some TE3 stuff and let this PR stagnate a bit. It's basically just a helper script for doing controller <-> device development on the same workstation. Being able to compile and test on a linux workstation is just faster than the pi. So you can run the device side using the script and the controller on the same machine. It's not intended as a full test system currently (because it still requires root access).

I understand why this is useful.  But do you know specifically what limitations we have in the sdk that force us to create such a solution?  It would be good to know because these limitations do not arise from the spec.  These are limitations of our implementation choices in the sdk.
If we could know these limitations, we could probably address them so that the sdk could support this type of operation out of the box.  Is this really just as simple as the fact everybody is binding to the same port 11097?  If so, I think this will be easily addressed once mDNS is ubiquitous in the stack and fully supported.

/rebase

Mdns would still throw a wrench in the works though, right? it's all 5353

Mdns would still throw a wrench in the works though, right? it's all 5353

All of the instances should be able to advertise by talking to avahi-daemon.

That would mean that no one could use the minimal mdns implementation for testing, but maybe that's not a deal breaker.
Honestly, I don't care enough about this to fight to have it go in. I have a local copy that I can use. @msandstedt If you can put up a PR to allow port changes and maybe instructions on how to do device -> controller on the same computer, I can abandon this PR.

That would mean that no one could use the minimal mdns implementation for testing, but maybe that's not a deal breaker.
Honestly, I don't care enough about this to fight to have it go in. I have a local copy that I can use. @msandstedt If you can put up a PR to allow port changes and maybe instructions on how to do device -> controller on the same computer, I can abandon this PR.

I'm not at all claiming we shouldn't have the tool provided by this PR.  I think it's great and I think we should have it.  That's why I approved some time ago.
I'm just using this as a vehicle for us to discuss why we would need such a tool.  I think it's good for us to understand this so that we don't inadvertently introduce constraints into the sdk that really shouldn't exist.  Based on the discussion, I expect (in the absence of such a tool) the constraints for Matter nodes operating within a single network stack are at least the following:

require a single, aggregating advertiser (e.g. avahi-daemon) for mDNS
cannot share ports for other services
only one node can be a member of any given Matter multicast group
there are likely other implicitly shared bits of state (e.g. within BLE transceivers)


Make sure the SIP is compatible with the restrictions imposed by the CSIP

Example: https://dilcisboard.github.io/E-ARK-CSIP/specification/implementation/metadata/mets/metshdr/
If the SIP spec makes something mandatory for example, we need to add a METS profile to the spec.

Done.


[Feature]: Sound notification for lobbys

Feature Summary
Add sound design for enter/leave lobby.
Detailed Description
It would be nice to have an indication that someone join your lobby even if you are not currently on the webpage, to do so adding a different sound for when someone enters the room and leaves the room would be great.

I am working on it.

Resolved by #371


[FEAT] Update ZIA Traffic Forwarding API Endpoints

There are a number of new API endpoints available for ZIA Traffic Forwarding.
pyZscaler should support all ZIA API endpoints.
Reference
ZIA Traffic Forwarding API

Completed and ready for 1.6.0


Feature.mitaka.f5 common networks neutronless tests

@ssorenso
What issues does this address?
WIP #864
What's this change do?

Generated new uuid's for key id's within the network aspect of data

Where should the reviewer start?
testdata
Any background context?
That neutronless tests fails for test_snat_common.py and this test otherwise.

test this please


In SILCodeMotion, be sure to invalidate global enum tag dataflow state when deleting instructions

Specifically what happens is shown by the following SIL example:
enum Optional<T> {
case none
case some(T)
}

class Klass {}

sil @foo : $@convention(thin) () -> () {
bbBegin:
  %0a = enum $Optional<Klass>, #Optional.none!enumelt
  cond_br undef, bb1, bb2

bb1:
  br bb8(%0a : $Optional<Klass>)

bb2:
  %0 = enum $Optional<Klass>, #Optional.none!enumelt
  cond_br undef, bb7, bb3

bb3:
  cond_br undef, bb4, bb5

bb4:
  br bb6

bb5:
  br bb6

bb6:
  br bb9

bb7:
  br bb8(%0 : $Optional<Klass>)

bb8(%result : $Optional<Klass>):
  release_value %result : $Optional<Klass>
  br bb9

bb9:
  %9999 = tuple()
  return %9999 : $()
}

The way the bug manifests is that:

We visit bbBegin, start tracking that enum (for the purpose of moving retains/releases out of switch regions where one of the switch branches has a non-payloaded enum).
When we visit bb8, we want to sink the creation of %result so we perform a release_value on a non-phi node value. But, we move %0a instead of %0 and delete %0.
When we hit bb9, we check our predecessor state to see if we are the end of a switch region. We are still tracking %0 and try to look up %0's RCIdentity... boom =><=.

The fix is to:

Add a layer of indirection so in our dataflow we do not refer directly to SILValues. Instead we use an index into a data store where the SILValues are actually stored.
If a different part of the pass eliminates an instruction, it blots out the SILValue results of that instruction in the list.
When the enum tag dataflow attempts to lookup a value for its ID, if the stored value was invalidated, it just skips it.

Some notes:

I ran into forward declaration issues, so I had to move the non-enum tag dataflow part beneath the enum tag dataflow part. I put that into the first commit to ease review.
I also found another instance of this in a different part of the pass. I fixed that as well.

rdar://36032876

@atrick Can you review?

@swift-ci test

@swift-ci please test source compatibility

nm on the review. I got confused about CCC/etc.


refactor: remove old hacks and fix checks on darwin

added nixpkgs-fmt and reformatted the codebase with it
added systems to inputs, making outputs overridable
instead of using expensive with pkgs;, packages used in lib/packages.nix should refer to the ones listed in the argument section (provided with callPackage)

I'll take a look into https://github.com/lenianiva/lean4-nix/issues/5#issuecomment-2460718642 in a bit

Does it compile on Darwin for v4.12?

I'll migrate bit by bit to main.

Can we break this PR into bits and merge them one by one? e.g. we could get the formatting and systems part in first, and then we can bring in the optimizations.

nix flake check passes on aarch64-darwin

nix flake check passes on x86_64-linux.

I need to configure the linter a bit. I don't like the default formatting.

I need to configure nixfmt a bit. I don't like the default formatting.

change nixpkgs-fmt to nixfmt-rfc-style?

Superseded by #31


CMake test fails with strict diagnostic options for Intel compilers

Hi @nbelakovski ,
I tried adding strict diagnostic options for Intel compilers to cmake.yml:
https://github.com/libprima/prima/compare/5366ab6..ea93390
After that, a few warnings are emitted, which are treated as errors, and the CMake test then fails:
https://github.com/libprima/prima/actions/runs/8790876683
Would you have time to have a look?
I would like to reiterate the following.

Warnings are future bugs. PRIMA does not tolerate warnings, unless they are emitted due to compiler bugs or we are one thousand percent sure that they are irrelevant.

In our development and test, compilers and linters should be invoked with the most strict diagnostic/debugging options, e.g., -Wall -Wextra -Wpedantic -Werror or something similar. This also applies to other code such as C++ and Python.

Thank you very much.
Zaikun

Hi Alexis @amontoison,
Could you have a look at this? Thank you.
Best regards,
Zaikun

Hi @zaikunzhang!
The issue is that you have some headers of C functions in prima.c.
They should in a *.h file.
I suppose that they are not in prima.h because you don't to export them but we can create another header file.
More details: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54817

Thank you @amontoison . Could you propose the changes by a PR?
There are also other warnings/ errors of different nature.
Many thanks.


Error messages returned from registries should be exposed to users.

Description
Error messages returned from Docker Registries are not exposed to users during the pull flow.

Registries sometimes return a body with an error which contains useful information, with containerd only the status code and sometimes the error from the challenge header are returned to the end user, but not the .message field of the error body.
The docker client, in contrast, does return the message part of the body which can often help users diagnose issues.
On such example where this is useful is when pulling from a registry the enforces billing quotas.
Also worth noting that http://www.faqs.org/rfcs/rfc2616.html states that for 403s  "If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity."
Steps to reproduce the issue:
Whilst using the IBM Container Registry

Set traffic quota to 1mb ibmcloud cr quota-set --traffic 1
crictl pull image over 1mb in size

Describe the results you received:
Containerd error:
Failed to pull image <image_name>": rpc error: code = Unknown desc = failed to pull and unpack image "/<image_name>": failed to copy: httpReaderSeeker: failed open: unexpected status code https://<image_name>/blobs/sha256:<blob>: 403 Forbidden

Describe the results you expected:
Docker example:
error pulling image configuration: unauthorized: You have exceeded your pull traffic quota for the current month. Review your pull traffic quota and pricing plan. For more information, see https://ibm.biz/BdjFwL

Output of containerd --version:
containerd github.com/containerd/containerd v1.2.4 e6b3f5632f50dbc4e9cb6288d911bf4f5e95b18e

I'm happy to do the work on this one.
My proposed solution having looked at the code would add code to the docker fetcher to check for a body that matches the errcode.Error object from the Distribution project and if it exists add the message field to the error returned to the user.

SGTM for the more useful error message. 👍

https://github.com/containerd/containerd/pull/3109 PR for this issue

Have locally tested my change and can confirm I now see the message returned as expected.


Update README.md to specify SDL2

SDL3 is coming and they've changed the main website to default to SDL3, this is just a small change to fix a little annoyance with the link in the readme

Thank you @coffandro!


Create camp blocker calendar entry for outlook (*.ics file?)

downloadable to client
can be opened and forwarded in outlook

https://github.com/jshor/angular-addtocalendar

This issue was moved to joachimprinzbach/ng2-camp2#6


Can't initialize Context

If I try to create an instance of AlecrimCoreData.Context, the instance is always nil.
Do you have any idea on what I'm doing wrong? Is there any setup that I have to do before to try to create this instance?
This is my current structure:
final class XPDataContext: NSObject {
	var user: AlecrimCoreData.Table<XPUser> { return AlecrimCoreData.Table<XPUser>(context: self.context!) }
	var context:AlecrimCoreData.Context! = AlecrimCoreData.Context()
}

// --

class XPContextManager: NSObject {
	class var shared: XPContextManager {
		struct Static {
			static var instance:XPContextManager?
			static var token: dispatch_once_t = 0
		}

		dispatch_once(&Static.token){
			Static.instance = XPContextManager( )
		}

		return Static.instance!
	}

	var dataContext:XPDataContext!

	override init( )
	{
		dataContext = XPDataContext( )
		super.init()
	}
}

XPContextManager.shared //this is ok
XPContextManager.shared.dataContext //this is ok too
XPContextManager.shared.dataContext.context //This is nil

the context property is always nil
Thanks!

Same here, it's always showing
fatal error: unexpectedly found nil while unwrapping an Optional value
for the dataContext?!
let dataContext = DataContext()!
final class DataContext: AlecrimCoreData.Context {
var events:      AlecrimCoreData.Table<Event>     { return AlecrimCoreData.Table<Event>(context: self) }

}

The documentation says the models must exist before you run the app.  What I have found is that if you make changes to the models after you have run your app, the context will return as nil too.  Have you tried getting rid of the sqlite tables as I mentioned above?

These files you mentioned on previous post as far as i know are created on simulator Documents folder, so yes i delete them all, they will be deleted also when you delete the app from simulator(what i already tried) but still the same issue.It's strange because when i try almost anything and any change inside the AlecrimCoreDataExample project it works ( i tried and deleted whole object model and created new one and there it works, but it doesn't work on new project)?!
Thank you

Just solved it and i wanted to share. The problem is that managedObjectModelWithName on the Stack class is not validated to accept name with spaces in case of getting the name from bundle.
So the error was coming as result of trying to create the ManagedObjectModel with name that contains white spaces.
So i solved this issue as follows:
// I added this method to validate the default name from bundle
private class func validateManagedObjectModelName(name:String)->String?
{
var myArray : [String] = name.componentsSeparatedByString(" ")
    var validatedName = name.stringByReplacingOccurrencesOfString(" ", withString: "_", options: nil, range: nil)

    return validatedName
}

// MARK: - private class methods
private class func managedObjectModelWithName(var name: String?, bundle: NSBundle) -> NSManagedObjectModel?
{

//Here is the validation of name
if let managedObjectModelName = validateManagedObjectModelName(name!)
{
if let managedObjectModelURL = bundle.URLForResource(managedObjectModelName, withExtension: "momd")
{
if let managedObjectModel = NSManagedObjectModel(contentsOfURL: managedObjectModelURL)
{
return managedObjectModel
}
}
}
    return nil
}

Regards

Just solved it and i wanted to share. The problem is that managedObjectModelWithName on the Stack class is not validated to accept name with spaces in case of getting the name from bundle.
So the error was coming as result of trying to create the ManagedObjectModel with name that contains white spaces.
So i solved this issue as follows:
// I added this method to validate the default name from bundle
private class func validateManagedObjectModelName(name:String)->String?
    {

        var validatedName = name.stringByReplacingOccurrencesOfString(" ", withString: "_", options: nil, range: nil)

        return validatedName
    }

// MARK: - private class methods

    private class func managedObjectModelWithName(var name: String?, bundle: NSBundle) -> NSManagedObjectModel?
    {
//Here is the validation of name
        if let managedObjectModelName = validateManagedObjectModelName(name!)
        {
            if let managedObjectModelURL = bundle.URLForResource(managedObjectModelName, withExtension: "momd")
            {
                if let managedObjectModel = NSManagedObjectModel(contentsOfURL: managedObjectModelURL)
                {
                    return managedObjectModel
                }
            }
        }

        return nil
    }

let dataContext = DataContext(managedObjectModelName:"whatDid")!
this solved my problem


Release under a free software/open source license

Hello! I was made aware of this project by Dr. Carothers in his parallel computing class. In his lecture notes, he described NeMo as open source software, however I was disapointed to find a lack of a license clearly associated with this project. I (and I presume many others) would love to see this project released under a free/open source license. I personally advocate for the GPLv3, however there are many other licenses approved by the OSI, you can find them here: https://opensource.org/licenses/alphabetical
Additionally, GitHub has created a convenient resource for understanding many popular licenses. That can be found at https://choosealicense.com/.
Thank you again!

Boom! We can't do GLPv3 due to linking/grant/library issues, so we've gone for the time being with MIT.
Thanks for the heads up, I'm amazed that we had missed putting the license file in here for so long.


Cannot read properties of undefined (reading 'path')

I'm trying to use publish-crates on the following crate: https://github.com/maia-sdr/maia-sdr/tree/main/maia-httpd
I'm getting the following error:
Found packages: maia-httpd
Checking packages consistency
Error: TypeError: Cannot read properties of undefined (reading 'path')

(full action run).
I'm calling publish-crates from this reusable workflow, which gets run from this workflow.
I'm also finding the same problem in another crate in the same repo. The thing these two crates have in common is that they have some dependencies with path and version. Another simpler crate in the same repo works fine with publish-crates.

@daniestevez Seems need add packages (maia-json, maia-pac) to workspace members.

I'm not using a workspace. Do I need to use a workspace for this action to work?

Seems this issue is solved in main branch.
Feel free reopen it otherwise.


Try adapt to 1.19.0 rc.5

Tried to resolve #14 and didn't stumble upon bugs or crushes. But I still don't know what is dt parameter in GetItemStackRenderInfo(ItemSlot inSlot, EnumItemRenderTarget ground, float dt), and am quite sure about just plugging 0 there

Thank you for the contribution! I checked and you were right, in 1.18 the API automatically used 0 for dt in GetItemStackRenderInfo. Weird, but apparently correct!


Add Programs feature

Description
LEARNER-2365
Add Programs feature

@salman2013 You need to add special keys for Automation work.

@salman2013 After enrolling into a course through Program app crashes with crashlog Cannot form weak reference to instance (0x7fcce5709340) of class edX.AuthenticatedWebViewController. It is possible that this object was over-released, or is in the process of deallocation..
After enrollment of a course, course start appearing in my courses but in Program Enroll button is still appearing. Enroll button should be updated to View Course.

The config PR has created https://github.com/edx/edx-mobile-config/pull/82

@saeedbashir PR ready for another pass. Thanks

@salman2013 Tests are failing

The title should be empty for the back button.


fix generating list of modules in CI

List of modules is no longer generated correctly. Please see https://github.com/SumoLogic/sumologic-otel-collector/pull/1188#discussion_r1255511685_

Well then. Didn't expect this one to go quite so deep. https://github.com/golang/go/issues/61644

Backing up a bit now that I've been able satisfy my curiosity.
I would be interested to hear how you all find this function valuable @sumo-drosiek, @swiatekm-sumo. I see that we are publishing this as a build asset (and interestingly not as part of our release asset) for FIPS builds. Perhaps we are compelled to provide some sort of SBOM with our fips builds and have fallen short of packaging this alongside our release?
Personally I do not see obvious value in repairing this outside of maybe aiding in the debugging of some unlikely CI issues.


Transition Auto Stretch Amount

Discussed in https://github.com/AllskyTeam/allsky/discussions/2942

Originally posted by AlaskanAstro August 29, 2023
Perhaps I have missed it but it would be nice to either offset the time of day that the auto stretch kicks in or have it ramp the amount, similar to how gain works for a day and night value.
Currently if a time lapse starts fairly early in the evening the initial auto stretch may be too aggressive for the first hour or so.
Thanks! Currently running the _03 release updated last night so auto stretch does actually work.

I'm realizing that the original question about ramping the STRETCH value from the config file through sunrise and sunset is different than what a true "auto stretch" would be.
So the idea of "auto stretch" is something that changes the stretch amount and/or midpoint to the raw image to get a target median brightness in the saved jpeg. It would help preserve the dynamic range of the image by not blowing out highlights but still bringing up the dark area of the histogram. Exactly the same idea as the built in STRETCH settings in the config, but adjusting on the fly as needed. For instance the desired stretch amount is rarely the same on a full moon night as a dark winter night with barely any milky way. Similar to what PixInsight does with the screen transfer function. Basically the STRETCH value is not usually a one-size-fits-all throughout the month even with the auto-exposure working correctly. I hope that helps clear up the idea? I probably rambled too long.

That makes sense, thanks. Do you know if the convert command can do an auto stretch?

I really have no idea, sorry. The biggest difference I see is that the currently implemented setting called "auto stretch" is essentially a fixed value, not an automatic recalculation of what the stretch should be.


grpc_ios_binary_size flake

https://source.cloud.google.com/results/invocations/0075e296-23ab-4b8c-a490-d0e5a647a2da/targets/grpc%2Fcore%2Fpull_request%2Fmacos%2Fgrpc_ios_binary_size/log
Previous HEAD position was 2bd7ad0112... Merge pull request #18263 from markdroth/grpclb_child_policy_configurable
Switched to branch 'pull_branch'
Traceback (most recent call last):
  File "tools/profiling/ios_bin/../../run_tests/python_utils/check_on_pr.py", line 64, in _access_token
    'token': resp.json()['token'],
KeyError: 'token'
Traceback (most recent call last):
  File "tools/profiling/ios_bin/../../run_tests/python_utils/check_on_pr.py", line 64, in _access_token
    'token': resp.json()['token'],
KeyError: 'token'
Traceback (most recent call last):
  File "tools/profiling/ios_bin/../../run_tests/python_utils/check_on_pr.py", line 64, in _access_token
    'token': resp.json()['token'],
KeyError: 'token'
Traceback (most recent call last):
  File "tools/profiling/ios_bin/../../run_tests/python_utils/check_on_pr.py", line 64, in _access_token
    'token': resp.json()['token'],
KeyError: 'token'
Traceback (most recent call last):
  File "tools/profiling/ios_bin/../../run_tests/python_utils/check_on_pr.py", line 64, in _access_token
    'token': resp.json()['token'],
KeyError: 'token'
Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 2,093,825      Total (<)      2,093,897
 No significant differences in binary sizes
***************FRAMEWORKS****************
  New size                      Old size
11,722,920      Total (>)     11,722,918
 No significant differences in binary sizes
HTTP Status 401 Unauthorized
Fetch access token from Github API failed:
{"message":"'Issued at' claim ('iat') must be an Integer representing the time that the assertion was issued","documentation_url":"https://developer.github.com/v3"}
Retrying after 1.00 second.
HTTP Status 401 Unauthorized
Fetch access token from Github API failed:
{"message":"'Issued at' claim ('iat') must be an Integer representing the time that the assertion was issued","documentation_url":"https://developer.github.com/v3"}
Retrying after 1.00 second.
HTTP Status 401 Unauthorized
Fetch access token from Github API failed:
{"message":"'Issued at' claim ('iat') must be an Integer representing the time that the assertion was issued","documentation_url":"https://developer.github.com/v3"}
Retrying after 1.00 second.
HTTP Status 401 Unauthorized
Fetch access token from Github API failed:
{"message":"'Issued at' claim ('iat') must be an Integer representing the time that the assertion was issued","documentation_url":"https://developer.github.com/v3"}
Retrying after 1.00 second.
HTTP Status 401 Unauthorized
Fetch access token from Github API failed:
{"message":"'Issued at' claim ('iat') must be an Integer representing the time that the assertion was issued","documentation_url":"https://developer.github.com/v3"}
error: Unable to fetch access token, exiting...
[ID: 4094683] Build finished after 3387 secs, exit value: 1
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
[12:20:52] Collecting build artifacts from build VM
Build script failed with exit code: 1

Looks like the retries added in #18031 don't help in this case as the error is not transient. CC @lidizheng


Update make.jl

change deployment name. closes #36

@dgkf-roche the project name has capital letters now. but the docs do not update anymore. this change could fix this right??


Support maximum number of parallelle postponed or crashed re-invocations

Support:

Maximum number of parallelle invocation be that postponed or crashed re-invocations
Delayed start (usefull for changed check frequency)


Add Platform Environments to E2E tests

This change adds E2E testing against Dynatrace Platform environments in two ways:

as explicit test cases for "core" tests, to make it easily visible if a case failed in general or for a specific environment type
by simply adding a second target environment to test manifests for more "general" tests.

Additionally the second-to-last commit (4dc9ff13eeaf63f7444aec4e3371debb91c86315) changes log output of the Settings client, in turn making the nightly pagination test work again, which depends on the log message.

On second thought the E2E tests can not work on this PR - the workflow itself is from main and is missing the added Environment variables

Latest E2E test failure seems to have been an API hickup

2023/03/28 12:36:39 DEBUG Found existing config Federation Availability_20230328123552_5757_allconfigs_v1 (synthetic-monitor) with id HTTP_CHECK-8A2ADEA50BDFC367
2023/03/28 12:36:39 ERROR === General Errors ===
2023/03/28 12:36:39 ERROR failed to deploy config project:synthetic-monitor:availability: Failed to update DT object Federation Availability_20230328123552_5757_allconfigs_v1 (HTTP 404)!
Response was: {"error":{"code":404,"message":"Synthetic monitor with a given entity ID not found"}}
Error: errors during Deployment

First we found the Synthetic Monitor, then got a 404 when updating


Technical Documentation: Sphinx autogen

This update allows to auto-generate the technical documentation (using Sphinx) in a variety of formats: for instance, the generated HTML doc can be deployed and used on GitHub. A PDF generation is also possible, although a bit more complex.

Commits of this branch hase been added to the sphinx_doc_enhancement one.

The commits of this branch has been added to the sphinx_doc_enhancement one.


Add hash option supports

solve #194

@mizunashi-mana thank you for taking the time to open this PR.  Before considering this I want to see if #211 will help the situation.  We can revisit at a later point.

Closed by https://github.com/sol/hpack/issues/194#issuecomment-725333773


Install Failed

Description
Tried installing from the downloaded installation .exe.  I get a message stating "Install failed. Please contact your software vendor."

Steps To Reproduce
Tried installing multiple times, got the exact same error message.
Requirements
I expected the software to install and be able to function without error messages.
Files Version
<IP_ADDRESS>
Windows Version
Windows 11 Pro Version	21H2 Installed on	10/25/2021 OS build	22000.2538 Experience	Windows Feature Experience Pack 1000.22001.1000.0
Log File

There is no directory matching the name you ask for.  I'm attaching the directory list to show that what you're asking for doesn't exist.

Thanks for the report, unfortunately that's caused by Windows, can you try
1. Opening PowerShell as administrator
2. Run this command
Add-AppxPackage -AppInstallerFile https://cdn.files.community/files/stable/Files.Package.appinstaller
3. See if Files is in the start menu all apps section

Yes, that installation worked.  Still can't use it, though, because now my computer's drives don't display.  Should have a C, D, E, and F on there. Ugh.  I wish Microsloth would just abandon the current Explorer code and rebuild it from the ground up.

Thanks for the report, unfortunately that's caused by Windows, can you try 1. Opening PowerShell as administrator 2. Run this command Add-AppxPackage -AppInstallerFile https://cdn.files.community/files/stable/Files.Package.appinstaller 3. See if Files is in the start menu all apps section

Hello,
Thank you! this is working for me on Windows 10 22H2.
Everything seems working perfectly.