MinGW support

I see a bunch of pull requests related to MinGW support, but they are quite outdated. Any plans to support MinGW out of the box, please, to avoid headaches with digging the code?

I picked from the patches what I found generic improvements. I found contradicting change requests in different pull request and, since we are not windows experts, have no MinWG environment. If I remember it correctly, I think when we were looking around to set one up, we found that there are multiple ways of doing so and it wasn't clear which one to use.
Is there one MinGW environment we should use? Getting something in I can't test is something I'm hesitating to do.

Hi,
I think that Appveyor can be used to test windows version (at least for the building). It has an integration with GitHub.

Is there one MinGW environment we should use?

Most people are using this distribution.
It would be great if you can separate the code in the traditional way using directives like #if defined(_WIN32) && defined(__GNUC__) instead of __MINGW32__ for better compatibility. Right now GCC throws a lot of errors. Some of them are quite easy to fix, but some are not, unfortunately.

I think that Appveyor can be used to test windows version (at least for the building).

Thanks for the suggestion.

If you are looking for mingw version of the usrsctp take a look at my MinGW fork. I've been trying to keep the source code updated with latest version of the usrsctp.

@CoolmanCZ Thanks! I've built debug version without any problems, but release throws some errors, unfortunately.

Hi, can you send me the command to build the release version?

You can set it right in the CMake:

OK, try fixed Mingw branch.

That was fast, thank you, it works. 😺

We already have a Windows buildbot with MinGW support, but we haven't used it yet.
I'll have a closer look at your branch during the next days and we'll check how to integrate it. 👍

@weinrank Any progress on this? 🎗

This should be fixed now. If not, please re-open.

Thanks, just built the library. 👍
There are only some problems with example programs like:
E:\C\SCTP\programs\programs_helper.c: In function 'handle_peer_address_change_event':
E:\C\SCTP\programs\programs_helper.c:134:10: error: implicit declaration of function 'inet_ntop'; did you mean 'inet_ntoa'? [-Werror=implicit-function-declaration]
   addr = inet_ntop(AF_INET, &sin->sin_addr, addr_buf, INET_ADDRSTRLEN);
          ^~~~~~~~~
          inet_ntoa
E:\C\SCTP\programs\programs_helper.c:134:8: error: assignment to 'const char *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
   addr = inet_ntop(AF_INET, &sin->sin_addr, addr_buf, INET_ADDRSTRLEN);
        ^
E:\C\SCTP\programs\programs_helper.c:138:8: error: assignment to 'const char *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
   addr = inet_ntop(AF_INET6, &sin6->sin6_addr, addr_buf, INET6_ADDRSTRLEN);
        ^
E:\C\SCTP\programs\programs_helper.c: In function 'handle_send_failed_event':
E:\C\SCTP\programs\programs_helper.c:200:31: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'u_long' {aka 'long unsigned int'} [-Werror=format=]
  printf("message with PPID = %u, SID = %u, flags: 0x%04x due to error = 0x%08x",
                              ~^
                              %lu
         ntohl(ssfe->ssfe_info.snd_ppid), ssfe->ssfe_info.snd_sid,
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
E:\C\SCTP\programs\programs_helper.c:200:31: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'u_long' {aka 'long unsigned int'} [-Werror=format=]
  printf("message with PPID = %u, SID = %u, flags: 0x%04x due to error = 0x%08x",
                              ~^
                              %lu
         ntohl(ssfe->ssfe_info.snd_ppid), ssfe->ssfe_info.snd_sid,
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1.exe: all warnings being treated as errors
make[2]: *** [programs\CMakeFiles\chargen_server_upcall.dir\build.make:77: programs/CMakeFiles/chargen_server_upcall.dir/programs_helper.c.obj] Error 1
make[1]: *** [CMakeFiles\Makefile2:226: programs/CMakeFiles/chargen_server_upcall.dir/all] Error 2
make: *** [Makefile:129: all] Error 2

The inet_ntop() problem is related to a missing declaration, I guess. @weinrank : Can you take a look?
The other problem is a bug in gcc on Windows, I guess. ntohl() on windows returns an unsigned long, whereas %u expects an unsigned int. However, on Windows, both a 32-bit entities. So gcc should not issue a warning, but unfortunately does. That is why @weinrank disabled the corresponding warning in https://github.com/sctplab/usrsctp/pull/321/commits/111e0caa5911833ef223df0ec92546582c8d83c7. Are you saying that the cmake based build does not work on your system?

Are you saying that the cmake based build does not work on your system?

Yup, I'm using CMake for building.

For inet_ntop() and inet_pton() you can grab https://github.com/CoolmanCZ/usrsctp/tree/mingw/programs/mingw from @CoolmanCZ fork. It's under ISC license.

@nxrighthere Which MinGW environment do you use?
MSYS? OS?

I'm using MinGW-W64 GCC-8.1.0 x86_64-posix-seh on Windows directly with CMake.

Can't build the library from master with the latest changes, too many errors.

Yeah. I really do suggest taking my CI files, so you're able to detect breaking changes with each commit made. I can help you setting it up, @tuexen & @weinrank.

@weinrank: Do we have MinGW on a buildbot? If yes, are we detecting the problems?
@nxrighthere What errors do you see?

I mean, being able to see the build status on GitHub, like here (click the X next to the commit): https://github.com/rawrtc/usrsctp/commits/meson-test
You can see the build error here: https://circleci.com/gh/rawrtc/usrsctp/191?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

@tuexen I have an MSYS/MinGW buildbot for internal use but it's not yet exposed to the public buildbot interface.
This is because I'm still not sure if I'm using the "correct" MinGW setup. I'm not an expert in this area.
I've modified and successfully tested the usrsctp library in a MSYS2 environment using the MinGW64 shell. That's what have been merged recently.
Now I've set up a fresh Windows host and installed MinGW-W64 GCC-8.1.0 x86_64-posix-seh @nxrighthere mentioned. I can see compiling issues regarding inet_ntop.
So there seems to be a significant difference between the MinGW Software itself and the MSYS2 distribution.
I'm currently looking into the problem.
@lgrahl
Adding a MinGW buildbot to our existing setup isn't such a big deal, thanks for the offer!

@nxrighthere What errors do you see?

There's only one left now:
E:\C\SCTP\usrsctplib\netinet\sctp_pcb.c: In function 'sctp_pcb_init':
E:\C\SCTP\usrsctplib\netinet\sctp_pcb.c:6854:2: error: implicit declaration of function 'atomic_init'; did you mean 'atomic_add_int'? [-Werror=implicit-function-declaration]
  atomic_init();
  ^~~~~~~~~~~
  atomic_add_int

I can see compiling issues regarding inet_ntop.

You can grab the implementation from here.

@nxrighthere This should be fixed by https://github.com/sctplab/usrsctp/commit/1a0619db218f6804bfd3c420b71a4422a7da17d7. Does it work for you?

I've tried to include it before your commit, no luck, it's still there. 😿

OK, then I think the problem is in user_atomic.h:
#if defined(__Userspace_os_Windows)
#if defined(__MINGW32__)
static void atomic_init(void) {} /* empty when we are not using atomic_mtx */
#endif
#else
static inline void atomic_init(void) {} /* empty when we are not using atomic_mtx */
#endif

Can you figure out which prototype is needed on you platform and whether __MINGW32__ is defined or not? Maybe it should be:
#if defined(__Userspace_os_Windows)
#if defined(__MINGW32__)
static void atomic_init(void) {} /* empty when we are not using atomic_mtx */
#else
static inline void atomic_init(void) {} /* empty when we are not using atomic_mtx */
#endif
#else
static inline void atomic_init(void) {} /* empty when we are not using atomic_mtx */
#endif

or
#if defined(__Userspace_os_Windows)
#if defined(__MINGW32__) || defined(__MINGW64__)
static void atomic_init(void) {} /* empty when we are not using atomic_mtx */
#else
static inline void atomic_init(void) {} /* empty when we are not using atomic_mtx */
#endif
#else
static inline void atomic_init(void) {} /* empty when we are not using atomic_mtx */
#endif

I believe it should be:
#if defined(__Userspace_os_Windows)
static void atomic_init(void) {} /* empty when we are not using atomic_mtx */
#else
static inline void atomic_init(void) {} /* empty when we are not using atomic_mtx */
#endif

By the way, MinGW x64 is compatible with __MINGW32__.
There's are more errors appears along the road:
E:\C\SCTP\usrsctplib\netinet\sctp_usrreq.c:201:39: error: comparison of integer expressions of different signedness: 'SOCKET' {aka 'long long unsigned int'} and 'int' [-Werror=sign-compare]
  if (SCTP_BASE_VAR(userspace_rawsctp) != -1) {
                                       ^~
E:\C\SCTP\usrsctplib\netinet\sctp_usrreq.c:209:39: error: comparison of integer expressions of different signedness: 'SOCKET' {aka 'long long unsigned int'} and 'int' [-Werror=sign-compare]
  if (SCTP_BASE_VAR(userspace_udpsctp) != -1) {
                                       ^~
E:\C\SCTP\usrsctplib\netinet\sctp_usrreq.c:219:40: error: comparison of integer expressions of different signedness: 'SOCKET' {aka 'long long unsigned int'} and 'int' [-Werror=sign-compare]
  if (SCTP_BASE_VAR(userspace_rawsctp6) != -1) {
                                        ^~
E:\C\SCTP\usrsctplib\netinet\sctp_usrreq.c:227:40: error: comparison of integer expressions of different signedness: 'SOCKET' {aka 'long long unsigned int'} and 'int' [-Werror=sign-compare]
  if (SCTP_BASE_VAR(userspace_udpsctp6) != -1) {
``

I think it's better to setup CI as Lennart suggested. 😸

@nxrighthere Please test PR #329
It seems that MinGW sets Windows 2003 Server as the oldest supported windows version.
Support for inet_pton and inet_ntop was introduced for Windows Vista and newer.
Since even Windows Vista is out of support, I've set the minimum supported (API) version to Windows 7.
In addition I've fixed the compile issues you mentioned above.

At least the Meson MinGW build is fixed with #329.

@weinrank Works like a charm, thanks!

It seems that MinGW sets Windows 2003 Server as the oldest supported windows version.
Support for inet_pton and inet_ntop was introduced for Windows Vista and newer.
Since even Windows Vista is out of support, I've set the minimum supported (API) version to Windows 7.

Interesting, I didn't know about this. 🤔


(request) prebuilt kitkat binaries for macOS

Is your feature request related to a problem? Please describe.
branch api19 has prebuilt binaries for windows, but not macOS. it won't compile since jdk is too new and downgrading causes other problems, and i just can't compile it
Describe the solution you'd like
add precompiled macOS binaries to the guide for the api19 branch
Describe alternatives you've considered
checking for other versions of scrcpy with kitkat and macOS support

It does not work for kitkat. Min required version is Android 5.
The branch api19 was just an experimebt. It does not work.


Blog post: new funding

There's a bunch of line breaks mid-sentence. Are those intentional, or being added by your IDE?

Oh, I didn't think they'd render. Let me remove them

How's that?

(I'm not actually seeing a difference)


Start text rendering

This commit puts in basic integration with ttf-parser and starts
populating the various piet text objects. The font is currently
hard-coded.

I'm inclined to merge this. It's very rough, and in many ways doesn't represent the long term direction of where I want this to go, but it gets some text rendering in place, and most importantly for my present goals, allows us to start running performance evaluation for font rendering workloads.

Sounds good, the render_ctx refactoring also look nice.


npm create analog@latest: npm install fails

Please provide the environment you discovered this bug in.
running npm create analog@latest
Which area/package is the issue in?
create-analog
Description
npm install fails
Please provide the exception or error you saw
npm i
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/@angular/compiler-cli
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@angular-devkit/build-angular
npm ERR!     dev<EMAIL_ADDRESS>from the root project
npm ERR!     peer<EMAIL_ADDRESS>|| ^18.0.0-rc.0" from<EMAIL_ADDRESS>npm ERR!     node_modules/@analogjs/vite-plugin-angular
npm ERR!       dev<EMAIL_ADDRESS>from the root project
npm ERR!   2 more (@angular/localize, ng-packagr)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/@ngtools/webpack
npm ERR!   peer<EMAIL_ADDRESS>|| ^18.0.0-rc.0" from<EMAIL_ADDRESS>npm ERR!   node_modules/@analogjs/vite-plugin-angular
npm ERR!     dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR!
npm ERR! For a full report see:
npm ERR! /Users/alexciesielski/.npm/_logs/2024-05-24T09_27_42_356Z-eresolve-report.txt

npm ERR! A complete log of this run can be found in: /Users/alexciesielski/.npm/_logs/2024-05-24T09_27_42_356Z-debug-0.log

running npm i --force does the trick though

Yea, we're in between Angular and Nx releases right now. Using --force or --legacy-peer-deps works with npm.


Add a unit test for calling clearPersistence() on a new Firestore instance

Note that the same unit test is being add to the js repository: https://github.com/firebase/firebase-js-sdk/pull/3005


Missing event lifecycle docs?

Can someone point me to the docs on lifecycle events? Thanks

What lifecycle events are your referring to?

Things like, isMounted, unmount e.t.c

Web Components have lifecycle events like connectedCallback, disconnectedCallback, etc when they are appended or removed from the DOM. Here is more documentation on it. Is this what you mean?
If you are rendering Web Components inside of lit-html's parser, those lifecycle events will be called on each web component. But those lifecycle events have nothing to do with lit-html. In fact, they can be used even without lit-html.

lit-html does not have any preference for how lifecycle/structure is handled. lit-html is only concerned with updating the DOM (via e.g. render(html`...`, document.body). That said, most cases I've seen are using a base-class that you extend to get a consistent behavior for creating components.
lit-element is a lib by the Polymer team, that is an example of such a base-class. It has plenty of hooks for pre/post-render etc. In our project we are using a custom base-class that is similar to lit-element, with decorators for attributes (@attr()) and properties (@prop()) to invalidate the view on changes, and schedule a new render.
So what lifecycle hooks you have depend entirely on what your implementation looks like.

Thanks for the info @mkay581 and @csvn.
I would take a closer look at lit-element


meshing panics with indeterminate data

I'm seeing this panic in 0.6.1:
panicked at 'Trying to evaluate cell data with indeterminate data!', /home/whiterabbit/.cargo/registry/src/github.com-1ecc6299db9ec823/splashsurf_lib-0.6.1/src/marching_cubes.rs:45:17

when trying to mesh a fluid from salva; i previously had no issues, so i'm not sure what happened here. It would be great if this didn't panic, but returned an error, so I could handle, and reuse an old mesh, etc.  I could also try to help figure out why this panic is getting hit, but will need some help where to start.

update: so salva 0.5/0.4 libsplashsurf_lib meshes fine. after some work i got libsplash_surf 0.5 and 0.6 working with salva 0.5 (by copying all the points to nalgebra24).
it has the indeterminate error in 0.5 and 0.6 (libsplashsurf), so i don't think this is a salva issue.

Yes, an error would definitely be better here. Can you still send me your parameters and maybe try to dump the specific particle data that causes this error, e.g. with Serde? Or simply by writing the f32 vector components just as xyzxyz... into a binary file? Because this should not happen with fluid data.
The reason I can imagine right now is that you manually specify a bounding box (which overwrites the automatic bounding box computation in the library that would add some additional margin around the particles). Now, if a particle is close to this boundary, in particular closer than the kernel compact support radius, then the resulting mesh might have a hole in that area if the marching cubes implementation would support this. However, I implemented it under the assumption that the surface of the fluid is closed, and this error is usually an indicator for this not being the case.
So if it sounds like this might be the cause, then you can try to increase the bounding box by at least your compact support radius (maybe 1.5x just to be sure). If this fixes the problem, then I don't need your simulation data. However I still have to think about how to best return an error there and this should probably be documented.

Hm, looking at the code that evaluates the density level-set I'm not 100% if this can really be the cause of the issue as I'm filtering out particles that are too close to the boundary. Maybe the margin I use for this is not sufficient. But it would still be helpful I you tried out increasing your domain by the compact support radius to potentially rule this our as an issue.

Attached are positions which were written just before calling match splashsurf_lib::reconstruct_surface_inplace::<i64, _>(positions, params, surface) with them, in json format:
        #[derive(serde::Serialize)]
        struct Data {
            pub positions: Vec<nalgebra::Vector3<Real>>,
            //pub params: splashsurf_lib::Parameters<Real>,
        }

{"positions":[[174.93918,1.5122641,190.92006],[178.57767,1.4219357,194.24754],[171.69406,1.3687683,192.87764],[180.79414,0.9100841,195.23088],[198.33655,1.117507,66.91833],[140.06471,0.99449396,196.05074],[121.81991,1.1253536,198.4992],[133.6017,0.80098724,145.81076],[198.71927,2.592601,187.21736],[167.82578,0.8342979,163.022],[178.55347,1.1408678,198.45593],[168.09354,1.2243371,195.29057],[198.48679,1.4311651,66.78468],[198.45325,0.84855443,56.778534],[134.0125,0.5627359,152.42792],[170.2481,1.470292,196.02425],[175.67227,0.8285564,190.84717],[158.49533,1.5639855,198.49786],[163.15814,1.3920583,182.39392],[159.28773,1.4500996,181.55293],[182.80284,1.1213125,196.47226],[188.47392,0.61802834,189.52713],[196.5436,1.2697344,195.06187],[152.04323,1.5028418,123.2912],[158.22867,0.95467186,196.82843],[172.24141,1.5097811,192.5904],[164.26347,4.1683755,177.83134],[175.5865,1.1806273,192.86641],[185.66359,0.6816398,189.8782],[151.14206,1.3693857,179.05151],[191.38626,5.1041045,195.59567],[190.37341,2.05842,192.34914],[158.40125,24.682777,129.26695],[152.67372,0.77549875,195.34198],[167.96483,1.1866438,183.84209],[173.99739,1.1938832,187.5356],[175.11047,1.1890954,185.30295],[165.5491,0.84419525,165.68141],[197.34521,2.0893874,186.49663],[170.86719,1.4941691,189.79459],[191.17676,1.4634686,191.81883],[198.39925,1.147841,159.8416],[158.7516,1.5237088,194.26459],[153.31123,1.4130385,119.13295],[146.9036,0.9382362,198.54202],[172.04185,0.70660484,189.97198],[180.65239,0.8217318,181.24629],[186.20532,1.278522,189.35095],[173.5078,1.5026467,196.40619],[185.92892,1.3566078,190.75073],[194.66922,0.8278826,189.47351],[194.91649,1.2928044,188.15424],[194.18448,0.5549909,119.01033],[158.94043,0.6049575,178.55211],[155.78178,1.5325302,197.51141],[180.85437,0.52980715,197.17276],[174.2965,1.5492333,177.44365],[180.28188,0.54961044,198.37532],[176.55026,1.4381634,198.90665],[198.7085,1.5172218,181.00276],[195.80666,0.8951189,180.70297],[158.95209,1.2055463,100.64562],[159.01926,1.1653472,198.46983],[154.74078,0.8077078,115.037056],[160.33554,0.50819266,197.57213],[198.45874,3.3124774,192.19138],[198.48079,2.173786,183.79796],[185.33563,1.4240927,191.87303],[179.55275,1.3650814,198.48465],[163.4087,0.55346435,198.52144],[198.6457,1.5493687,194.41075],[187.81068,0.69865453,194.21597],[156.3802,1.5393701,160.85147],[163.78438,1.4881283,127.86559],[198.75655,6.1251955,198.92789],[196.38965,3.1708164,194.99173],[187.93912,1.2704667,191.50969],[181.26038,1.0266814,196.32457],[160.77307,2.3759954,199.04976],[175.19414,1.3859811,191.88002],[198.16777,0.6320126,149.95816],[146.41011,0.8795663,134.17546],[162.7643,1.451014,138.252],[197.75934,1.7091184,127.609474],[153.23044,1.5188576,174.34372],[192.30992,1.4167092,196.26172],[193.6779,3.0721333,198.03133],[187.07283,0.51738405,195.2097],[194.06403,2.7229407,188.15962],[179.95633,1.8262733,197.33426],[198.46301,36.92133,145.45576],[151.3078,0.55685496,195.06174],[167.34982,1.5310456,173.32864],[152.60193,8.727786,131.17635],[198.22136,43.29286,121.628525],[162.48659,1.5231607,160.39056],[199.35178,1.3728094,198.80417],[194.09486,0.95506835,198.74841],[195.20119,2.3896348,198.44783],[198.84402,1.9898474,189.12376],[182.13156,1.3386496,190.68459],[172.5135,1.4769919,194.62952],[184.81633,0.9362085,185.86115],[160.85622,1.1687793,197.95575],[130.13307,1.2905195,137.09023],[110.33181,0.8605128,163.9278],[92.528854,1.0865324,184.13472],[157.3388,17.463417,134.50009],[156.76944,0.9780534,198.19086],[171.70125,1.0714597,190.0979],[198.99474,1.7698809,196.45596],[178.37598,0.950933,194.1299],[163.16637,0.9758136,189.97514],[180.03474,0.8803345,193.2657],[115.211,0.6251583,162.97975],[129.49225,0.8488813,156.67892],[176.13774,1.2992271,181.71652],[156.05838,1.1539421,198.28267],[184.46379,1.0562698,191.5605],[188.08974,1.1106015,176.84018],[197.25333,1.5559375,196.43819],[195.47206,0.53123385,189.80609],[193.38889,1.5537688,193.92946],[198.52805,0.9192514,151.87312],[199.49931,1.1726614,113.534676],[139.73279,1.3556925,198.85439],[139.50555,0.9532349,197.43176],[136.2672,1.4398482,198.47227],[162.01202,1.3937355,198.6988],[166.63458,0.74703664,198.07043],[199.21602,1.2701155,151.83923],[188.65678,1.3383623,162.8323],[196.58102,1.5603551,182.54303],[191.65584,1.5357391,149.33101],[142.33824,0.9020556,132.7979],[131.77025,0.5376519,198.47455],[191.29605,1.2490281,197.01944],[142.92714,1.496559,169.46252],[187.1887,1.1432909,191.83229],[165.77496,1.9768733,172.71675],[199.1637,1.5397037,167.77832],[188.51248,1.5075712,155.0059],[199.28654,1.0006881,133.3998],[195.51958,1.1031275,135.8726],[159.40009,1.521972,198.43423],[161.85336,1.417284,195.9843],[166.5897,1.519859,199.31233],[196.49942,0.971837,186.48705],[165.8696,1.5424433,188.62485],[185.63231,1.5601434,199.04294],[190.44717,1.9777818,195.36783],[198.3842,1.0649638,174.2836],[194.81673,1.274488,176.54657],[172.5958,1.9087436,130.47267],[134.60957,1.4947459,198.27339],[178.00795,0.77767664,195.27098],[189.84642,2.578502,188.60765],[189.5122,1.2748005,191.3376],[169.14551,0.7807201,196.70662],[171.69861,1.5137879,197.67734],[197.20952,1.2389692,146.58751],[196.22647,1.5123614,168.45251],[143.25401,0.8768679,177.65614],[197.9502,1.5444891,113.40602],[155.70901,1.485445,168.66011],[152.01611,0.93772036,138.61841],[186.94939,2.1649742,194.29524],[186.24193,2.7644083,189.0837],[183.89954,1.4397119,186.47432],[187.6265,1.5223637,193.86252],[195.607,0.84922194,195.22537],[193.32883,1.0442835,196.64299],[197.65982,20.20968,155.19818],[157.84071,1.5476649,120.98412],[198.87343,2.8147318,197.97173],[170.05765,1.4339491,184.74335],[196.70717,0.5454315,187.4174],[191.75589,4.4047217,190.68051],[175.47118,1.2912613,199.36491],[177.7667,1.1461332,186.11034],[194.76651,1.5313444,194.889],[198.59525,0.7025105,34.676353],[195.50018,1.4933653,198.17087],[198.6344,1.6536044,183.03516],[157.87943,0.9314697,143.5347],[125.3054,1.5237241,196.95189],[191.27875,10.091464,197.80028],[197.4522,0.53927445,189.83925],[198.50133,15.226072,198.4817],[173.90195,0.99989873,198.19449],[194.84265,2.0317705,195.62816],[195.77022,27.822552,187.71571],[198.5795,4.078013,195.65048],[160.87689,30.498829,129.9479],[187.22139,1.5351086,126.98054],[155.48032,1.4262625,108.26879],[161.83824,1.1094414,199.32951],[175.61453,1.210083,184.91872],[189.9585,14.812392,198.94156],[183.62482,1.4242579,192.3545],[182.6843,2.146715,189.80591],[161.53784,1.3892505,186.92175],[178.27214,1.1696318,197.39763],[190.01265,1.2150131,196.60524],[198.22565,1.0533808,188.4032],[199.49213,0.5096966,55.77836],[149.76111,1.5125045,108.890015],[159.47867,1.4162593,124.29379],[161.39471,1.5283729,193.5134],[157.11613,1.5370725,198.92323],[198.52086,1.0893946,142.5044],[186.03316,1.4434177,194.7514],[169.74089,1.3901577,196.86073],[191.86957,0.54208076,192.16335],[169.02762,1.2495236,184.19452],[126.30725,1.1949948,155.7198],[96.09486,1.3697516,198.5488],[113.06521,1.2960389,155.83678],[157.16907,0.9969807,164.82614],[163.06288,1.4955359,188.05295],[197.79935,1.5192741,128.13266],[173.00139,1.1220938,193.68964],[172.56429,1.5439143,190.8255],[183.59117,1.0318238,191.4267],[129.41183,0.9560345,128.6067],[152.17383,0.61618096,196.65517],[197.70192,1.8351916,168.12659],[156.36662,24.41953,130.47803],[170.23843,1.5034134,192.4642],[160.58545,1.4600511,186.08888],[158.16714,1.4977633,111.23329],[198.22101,1.6478548,195.19116],[190.6911,3.1559494,191.03549],[172.91125,1.4392713,192.28139],[156.1697,1.2738535,111.55124],[149.90196,0.6610915,197.58096],[138.96185,1.5014443,192.48228],[187.90347,21.638908,170.75262],[176.34496,8.98725,172.36041],[167.69391,1.5005083,184.45172],[149.95691,0.87158287,116.51513],[192.39096,0.9394371,191.70634],[197.30093,1.5268447,182.09782],[196.63493,1.4261925,176.34186],[139.28922,1.2821825,135.47284],[198.57468,31.108322,195.18867],[142.07845,1.5247365,198.71094],[162.89124,0.99285674,197.37865],[166.97726,0.98815453,179.20322],[184.13684,1.2858073,187.3482],[166.20059,0.7947798,141.13676],[197.03711,2.1675858,196.064],[186.41756,1.4740803,192.28139],[196.38237,1.5096332,160.82735],[197.90926,38.508923,74.0505],[145.30458,0.5330794,166.9055],[198.4186,2.165554,198.19586],[192.73112,9.613052,199.36867],[168.82361,1.4411907,183.60675],[165.00853,1.5441992,199.38696],[188.36848,0.91555583,156.1761],[199.49187,1.0676893,180.51788],[192.8525,20.673069,186.06029],[162.36421,1.5510626,114.7205],[153.50333,1.4486703,163.78143],[188.25922,1.7913918,196.33104],[168.8799,0.8787701,193.91211],[180.1061,0.6932826,198.76596],[187.60938,0.9476241,190.15489],[160.90666,1.4727361,198.48679],[198.44112,1.4676645,149.3282],[198.30406,1.2936995,199.03918],[196.96857,18.398424,166.3214],[197.55515,26.669184,147.9219],[198.06306,59.57501,153.80219],[160.38316,1.3258003,181.00098],[164.57372,0.87000835,195.19124],[176.65416,1.1275256,192.46245],[183.58766,1.4476469,190.40686],[188.40764,2.0921326,191.42442],[157.56517,1.1196885,132.17476],[198.4937,1.3132054,186.9134],[143.89175,1.2440083,172.89447],[197.7761,49.068295,140.44257],[198.51564,1.1331856,150.70575],[157.05663,13.342608,170.89905],[183.48425,1.3891852,179.99149],[189.3512,0.68746066,192.4497],[186.23767,1.4351624,197.27838],[170.90527,0.98245764,196.50386],[191.14386,13.099526,157.71349],[197.72594,78.75952,198.05779],[165.42496,1.4215281,167.95056],[198.18993,16.01879,178.4497],[198.25475,68.105194,167.74223],[133.64761,1.3149486,131.59259],[156.8962,1.4249765,83.8478],[146.69655,1.2174827,197.9614],[176.3515,1.2344556,190.16934],[167.02187,1.5202085,195.31184],[182.43358,0.8209701,188.92758],[167.84302,1.0105283,182.36899],[192.32121,4.8980656,197.2904],[179.59686,2.2473893,198.47635],[198.41615,1.3684676,143.09445],[198.52942,1.2928699,86.4897],[140.0015,0.81604177,186.51424],[99.148094,1.4684933,196.31844],[165.2438,1.3968174,198.47588],[196.66753,1.8751444,188.8793],[197.67366,1.6660594,189.57632],[162.13297,0.7844497,189.00589],[159.91074,3.221482,198.54092],[173.8253,1.5069067,192.87894],[196.07787,1.9771459,185.88533],[132.49399,1.5635223,143.94398],[151.18654,9.5458145,133.35379],[141.2312,1.5120671,198.65298],[112.80179,0.9963291,198.23116],[184.90244,1.4966365,195.47536],[159.15987,0.79179096,60.362152],[174.3963,1.5018715,185.70026],[193.25375,1.645234,197.59196],[195.80096,1.89808,196.4976],[164.00285,0.87119216,116.628555],[152.096,1.1067135,167.11607],[158.47482,1.0813061,112.21173],[140.54807,1.1989727,198.46638],[169.19951,1.393344,180.01262],[154.14877,1.655966,177.95439],[198.48083,1.4136664,79.184395],[177.2937,1.4016074,193.8221],[192.88051,12.575206,169.64023],[198.33607,1.2770606,195.69289],[198.34273,1.5352731,174.71442],[194.09435,1.29599,152.52481],[156.10335,1.4549948,195.20341],[161.76015,1.504322,180.27924],[192.38156,0.9056737,198.26999],[176.04088,1.4518605,194.09381],[157.98257,1.4638432,109.22693],[170.51299,1.1322036,197.74908],[176.22508,0.5910229,191.85739],[190.04541,1.3354865,194.73853],[198.39102,1.6110983,198.57777],[193.78136,0.55641186,196.43253],[159.26276,0.73002815,118.40012],[197.77173,24.643625,198.48965],[167.62802,0.8008542,197.8145],[193.43304,0.86698365,191.80067],[157.76137,1.53815,103.86863],[185.81305,1.2032503,188.89064],[189.41019,1.5048891,196.24321],[196.54733,2.137925,197.28847],[117.8904,0.5083132,138.31061],[134.38388,0.9101165,170.48582],[176.1688,1.4960511,185.19272],[199.14433,6.664953,198.80719],[167.41537,1.2405484,184.6353],[168.14175,1.5747688,181.91814],[198.15718,3.7623987,115.52743],[197.33498,1.2225026,198.39925],[198.92671,5.3286395,197.61821],[198.60089,35.17279,153.08963],[198.23752,24.808105,128.12085],[88.28042,1.3091894,163.90707],[161.50912,14.1975765,160.93062],[194.71617,1.3221565,172.62706],[179.0487,1.5095971,185.24326],[163.09038,7.298515,168.40567],[198.48706,1.4408214,165.56313],[191.75873,1.6990134,197.01144],[153.79616,0.9756878,125.77025],[197.27454,38.952583,153.27585],[141.86592,1.5686613,136.25899],[198.81265,0.66552913,70.48747],[189.70175,0.8187756,191.91675],[176.4921,1.3401154,183.44817],[184.12312,1.4760056,198.16237],[191.2987,8.746571,189.94214],[165.8034,1.4003623,121.22595],[190.63986,1.2282019,96.522934],[190.9379,28.91949,88.55669],[198.494,45.64509,198.42422],[197.21863,58.03777,167.2539],[137.83475,1.3398308,175.0286],[143.57071,1.2366465,198.97803],[158.84113,1.5088993,144.80309],[182.3016,2.053276,198.46701],[191.81822,0.60372794,198.2565],[197.83415,1.8004177,183.24538],[199.1749,54.186565,198.49278],[198.01852,34.644436,85.57223],[156.26572,1.5180799,198.4387],[198.26665,80.13474,180.55429],[199.36612,0.7230595,53.351402],[197.98503,91.80092,171.08728],[122.95683,66.57302,198.44339],[139.37299,81.962906,140.91411],[195.20424,3.5785117,187.74039],[199.00525,1.6569775,188.89313],[169.81725,1.0900989,198.9814],[180.8863,1.1905566,194.6688],[161.84357,1.8722677,198.47212],[159.4128,2.5659285,191.45367],[196.91806,0.9646504,169.83423],[198.49258,0.9196478,96.32704],[148.04321,0.9510961,102.17952],[172.95389,1.5756474,182.53728],[160.78644,1.4360569,181.24448],[198.48636,0.60730493,140.50252],[183.49284,1.4863502,190.38326],[185.5162,1.5289376,195.39526],[165.26514,1.4900148,193.70273],[173.4723,1.3987731,198.52733],[198.91216,1.0576509,126.539375],[93.78217,1.5031492,198.17368],[198.39746,4.2978964,137.2971],[163.86293,1.445457,186.49403],[185.32823,1.3654552,185.83727],[168.47975,1.534206,103.89196],[185.20004,1.3302407,187.28963],[169.9319,1.4236046,198.89352],[183.43857,1.3610903,196.13246],[184.38464,1.2218746,195.12865],[129.66954,1.4649621,179.85646],[109.80983,5.9819245,135.31865],[140.76897,1.4154233,113.84306],[166.36404,1.485218,198.46075],[195.02028,0.53626704,194.7611],[198.21043,1.667327,21.017178],[195.74951,2.6802928,194.99106],[188.9316,1.2976385,196.4681],[190.92401,1.247501,180.87749],[198.78352,0.51357186,168.9964],[166.04532,0.93015075,176.86829],[163.3788,1.558183,120.18213],[164.07625,1.424326,183.46527],[198.51125,0.84183365,177.0498],[165.5321,1.397894,185.6184],[177.89294,1.0753734,59.362648],[166.8204,3.0198808,182.70163],[166.74934,0.5777824,181.69176],[197.16658,3.4365954,195.76503],[198.33351,6.0150514,194.80005],[100.10779,1.4093482,198.46294],[149.50755,1.0743906,156.13232],[185.23636,1.5410004,193.53484],[141.42432,0.8669315,197.95822],[192.99593,0.76117027,174.45363],[197.94832,1.3851109,174.54726],[198.65709,1.9262564,189.91525],[184.77902,2.240425,189.02481],[188.46017,1.1971662,198.38564],[198.49927,1.1192269,135.21538],[187.58421,1.4520831,190.09839],[149.46342,0.911041,157.45851],[168.78482,1.3224099,196.20598],[198.45123,6.8019257,193.2218],[188.87227,1.0734783,198.3878],[193.65027,1.3544816,195.54851],[183.83821,0.97047055,186.79314],[172.66695,0.77303714,172.81294],[186.97739,5.4201007,193.37144],[198.49634,44.559925,119.91407],[196.44052,1.4206169,148.73605],[163.4404,1.4194938,179.89438],[181.68616,3.2093213,173.85243],[172.31255,1.4594105,191.78154],[190.00194,1.57883,197.80127],[191.96414,1.142069,194.12595],[190.02788,3.4141445,192.03554],[189.95149,2.8429463,196.57426],[199.0158,39.86735,144.37448],[198.93907,5.9129825,155.63443],[170.30775,11.452622,124.13451],[196.32028,6.0829353,195.59943],[197.34952,1.4265113,199.31223],[157.3517,1.2186147,190.09506],[167.43054,1.3385555,181.53642],[198.48763,19.674925,163.70457],[198.36937,1.5815787,-0.28034574],[198.73788,2.9415522,195.23476],[196.21071,65.80613,198.81516],[198.30333,65.770035,157.66779],[197.09608,78.75448,132.17729],[198.39531,1.4338781,132.30621],[198.28755,1.1267223,89.4839],[197.98738,64.058846,198.15668],[198.73297,39.13787,198.57436],[187.0844,1.8942347,193.28038],[194.13713,1.6132853,197.25769],[196.42511,0.96540236,198.40945],[156.47668,1.0506207,158.34299],[198.44547,35.937374,197.71199],[164.20923,41.63749,29.766014],[115.46172,10.243661,88.71101],[149.87166,14.877169,145.2259],[146.14798,99.1629,189.46887],[186.74123,1.6950612,190.61702],[173.10527,1.5787351,193.93463],[188.3575,1.5094323,194.70743],[184.60866,1.365203,195.88419],[191.2307,1.5434256,192.3222],[168.04854,0.87122774,180.6287],[158.35022,6.51856,195.0192],[103.15959,0.8293157,198.48737],[126.31282,1.4801592,198.45355],[154.4717,0.90161043,177.42172],[172.13164,1.0222887,192.99399],[181.35738,1.0449526,189.99565],[188.59999,1.1838976,193.1915],[185.23087,0.65509415,192.32295],[167.94875,1.1067835,179.71895],[160.30112,4.9677873,198.08856],[191.21921,1.0321257,196.3483],[164.58635,0.6234586,115.78238],[177.03326,1.0657824,191.94579],[89.68683,0.66273963,149.08911],[171.5893,1.4645685,193.85185],[198.48244,1.1721269,64.10658],[184.50151,0.8925542,189.40865],[198.85913,0.55120695,188.70474],[168.22047,0.6353155,195.30411],[185.33412,1.5195663,198.3064],[195.0847,1.5175139,196.12695],[198.68027,1.2202592,119.62268],[167.23538,0.9681519,196.76294],[174.3417,0.5869741,187.02658],[195.50885,0.85305434,198.7198],[180.34677,1.0146102,41.812195],[198.73413,1.2383733,196.54454],[193.3924,5.006422,190.90027],[195.81636,1.9481348,197.38844],[187.77388,2.0383177,190.09286],[195.45383,0.9922996,154.12479],[196.28743,1.4995518,169.95326],[150.50023,1.5069393,112.55291],[134.1328,11.3484745,198.48552],[171.26392,0.88199204,191.58485],[182.72537,1.1969031,127.50127],[198.7342,2.3749804,194.14331],[173.5105,0.9067036,194.98296],[168.2681,2.0365722,180.68687],[163.351,0.6956214,184.12515],[170.14204,1.0121449,51.080643],[198.20197,98.21845,134.00539],[148.93811,0.89120364,198.14688],[167.1278,1.4771105,183.81592],[185.8942,1.3131546,195.85481],[163.45718,1.5020567,99.55917],[189.09012,2.4633155,198.51222],[185.72804,1.3513764,186.32393],[185.34346,1.1890209,196.25067],[198.40709,3.6740174,191.14008],[151.13806,1.5817424,199.10677],[198.49838,52.910103,150.23303],[141.68672,1.6025807,197.68027],[176.19295,0.80747676,198.08992],[198.46217,16.67189,198.49498],[194.53162,1.9906696,199.48344],[187.65479,1.4548618,192.79428],[192.7778,0.72472596,185.05539],[193.1504,1.3589697,193.0852],[188.36588,4.015508,192.55908],[198.54498,1.5084125,159.9277],[95.66501,1.3502067,188.87363],[156.93275,1.193335,198.55127],[196.52988,64.84361,197.29256],[180.40166,1.0425863,185.80714],[198.48372,25.330252,131.4952],[181.25195,0.69469154,188.86638],[188.21014,2.0321133,197.10442],[198.15883,2.5214498,194.81383],[197.57185,61.510876,152.86583],[195.97064,0.93538874,138.96492],[120.45943,4.677148,198.39066],[177.94228,0.60267186,198.46222],[195.94081,16.644932,199.3431],[160.27324,0.9821126,199.08093],[174.62552,1.3240774,141.89217],[192.72171,46.560894,198.20683],[198.56516,82.98908,198.2828],[176.8231,1.2239306,70.11874],[195.48976,1.2135651,150.66035],[198.20383,95.09621,197.36394],[154.62909,1.1703869,126.706276],[172.00377,1.1025023,194.11324],[174.81693,1.4781324,143.81137],[198.66263,22.22346,198.4993],[197.7942,1.793496,193.32507],[187.25037,1.1686454,198.34036],[194.60008,2.575285,198.44724],[198.16458,32.94333,101.9156],[199.0727,19.264858,198.49446],[197.41307,70.51045,175.29004],[164.40639,41.465343,131.63228],[137.42581,1.1213291,198.4751],[154.60179,90.423965,138.10464],[189.98688,0.91699106,198.44809],[196.8872,1.4899594,195.23099],[171.12372,1.1909344,198.30028],[195.22134,2.3592613,196.75014],[177.23367,2.0933225,184.49104],[164.57094,1.3369694,198.17758],[162.31029,4.0699916,198.47633],[199.45816,1.1971294,141.26321],[144.32567,0.5520979,81.02496],[160.5594,1.9835615,182.88075],[181.42998,0.6658154,191.94069],[147.29288,1.2241714,147.43622],[198.90875,2.7299962,184.49136],[192.96408,1.3380381,197.43272],[186.29869,1.5550095,198.52689],[155.68051,1.3729383,184.4921],[162.09082,8.808968,187.7002],[83.368706,1.1563962,102.7621],[186.63371,0.87081647,194.32204],[116.106445,1.444521,198.34535],[154.14172,0.9191418,178.66557],[162.50916,1.0891423,118.83611],[171.97354,1.4503111,186.50061],[194.37512,1.4386885,195.51192],[185.04382,0.7111921,190.45578],[168.65965,0.6170673,185.23238],[182.14438,1.5028106,190.02203],[197.97424,36.146263,116.8348],[152.54626,0.7069266,177.53508],[198.26982,3.303385,195.79027],[174.0253,1.3294505,188.57759],[198.49971,9.596001,38.968178],[196.87956,1.5655136,196.28438],[177.70174,1.3357682,183.86978],[174.28711,0.55683625,189.53229],[180.69202,2.2114406,196.07794],[189.60103,1.2076269,198.55086],[198.48691,43.46462,110.264336],[174.0928,0.7369611,184.38982],[171.1318,1.0523577,194.88185],[162.29236,0.8413683,198.35107],[198.36533,1.529256,82.98133],[173.8169,1.1286478,177.41953],[193.93164,1.7134001,198.50911],[166.0971,0.9346866,189.76144],[172.65367,1.4498619,190.26123],[194.1399,1.1908842,190.58214],[196.42043,1.2910602,179.57571],[192.06894,1.4234097,194.66629],[159.95203,1.2256646,194.86964],[173.99478,1.508171,188.23343],[198.37767,17.572077,71.00036],[198.02565,5.3265233,198.42201],[175.1723,1.11203,186.4648],[185.01918,1.3641913,189.4482],[166.8556,11.4292145,181.63235],[198.49771,0.50107145,156.0876],[164.33475,1.5177317,197.77333],[198.37224,28.828396,135.43929],[198.1466,1.6157049,196.83076],[193.6495,1.5847652,198.59155],[176.84732,1.013852,63.680687],[196.67949,1.3522335,197.39536],[165.14778,1.5283521,173.2227],[188.65753,1.5279386,192.06178],[196.33266,0.9543571,199.20131],[198.12024,39.848595,147.67523],[153.55896,1.3397235,154.12868],[186.04318,1.4445814,189.00513],[198.18257,16.42685,107.294876],[173.54884,1.5271722,178.75998],[196.78291,1.4459529,86.44474],[181.24341,0.6473675,187.46237],[173.07086,1.4620053,175.84158],[184.12828,1.231169,191.40712],[198.49532,52.725212,131.28502],[198.54155,88.792984,124.37886],[198.11183,1.0033422,123.2695],[151.72249,1.1020148,179.82689],[192.45764,1.6532011,197.37955],[178.77065,1.3544947,192.39847],[158.25296,7.574814,127.096054],[191.76228,0.8936816,198.83054],[188.52869,14.082296,198.40286],[197.20364,1.3004987,198.3114],[198.26933,33.972393,197.7063],[195.71735,13.144025,198.4098],[162.44473,1.8646755,157.56537],[197.8369,2.9095235,189.80257],[136.34505,92.10021,143.89613],[186.83022,0.5851115,197.62871],[198.4393,93.79253,124.46106],[198.83989,1.3881322,198.83444],[194.96373,0.80759525,198.01587],[196.32747,21.245071,198.33194],[198.48764,78.45031,183.32124],[191.73474,23.24813,198.44995],[159.65512,1.3434218,148.21461],[145.90982,67.72693,150.84947],[86.749695,1.2651674,198.2932],[198.6078,29.415766,198.49486],[161.84235,1.3718811,77.42511],[195.21274,1.3238543,171.13924],[183.61171,1.2451271,188.41003],[160.82428,1.4876958,180.68759],[177.5048,10.754978,176.76057],[162.58015,1.519053,182.95988],[194.34889,3.1835186,195.98967],[88.05022,1.0615112,117.47363],[198.40306,1.1316897,78.11034],[122.84578,1.4455497,198.02202],[180.05887,1.512565,68.81197],[172.51036,1.4581276,195.89067],[189.37122,1.4320477,191.36835],[160.12659,1.4815855,178.19237],[185.69023,1.377951,192.70724],[187.42525,1.1332628,193.21677],[193.15579,1.4593172,173.9951],[190.41995,1.1498094,168.75104],[172.16446,0.5424747,188.45593],[138.74434,1.1465651,198.76999],[198.3688,1.237061,63.31551],[189.86572,1.4375309,50.68058],[191.47687,3.7639246,195.59453],[167.15077,0.80917555,180.39174],[172.69434,1.5603119,187.20135],[169.42145,0.8100917,198.30742],[161.42244,1.4495956,112.49235],[198.47517,1.3677173,173.80634],[198.48122,27.79662,184.02486],[180.64226,1.1345527,182.80923],[182.7485,1.4378726,37.869667],[184.48833,1.449085,194.09662],[198.50249,1.2077336,184.20506],[173.44365,1.2856091,183.15663],[196.1413,2.3239632,186.78754],[169.35153,1.097492,192.12006],[189.21785,1.624007,195.03102],[197.98604,1.2323091,176.13559],[119.428024,1.2651774,128.4964],[176.7099,1.4855176,184.2972],[199.27014,1.347543,122.84036],[198.2156,43.28411,0.883824],[180.86781,1.5135258,186.6959],[165.65343,3.0667768,184.09534],[180.39034,1.3373713,196.04164],[187.86372,1.1841034,194.63387],[163.8965,0.8898221,177.5061],[198.85182,0.9559216,195.12424],[157.981,2.0348456,181.26865],[168.03964,1.2566116,185.14561],[180.64178,0.9987655,49.85076],[199.40923,2.7327263,189.3429],[196.91823,6.421777,180.23026],[174.70584,1.2663302,173.05716],[192.02979,0.7212043,175.184],[179.96304,1.4784558,187.83897],[199.20848,43.325146,145.64088],[199.29971,1.6803426,149.59296],[189.16353,1.5344496,168.4472],[173.78166,1.3271443,190.65034],[198.31354,1.1419146,46.37971],[197.93947,1.3955147,194.41844],[187.79646,0.81784856,192.29642],[193.25432,1.586777,198.56444],[191.31136,1.5579542,197.57143],[197.53668,50.01527,198.26521],[198.5463,1.741924,145.46245],[197.99623,59.05455,112.781166],[179.591,1.2254663,195.5222],[175.69104,1.0984607,191.59898],[198.33641,0.69821405,39.53065],[188.10503,0.8976083,182.0542],[185.13454,1.5888675,198.45439],[172.61931,1.2552775,173.6805],[198.55115,0.8638896,131.14891],[197.71582,2.0478318,188.99933],[198.55067,1.2714083,194.02637],[186.17766,0.55982804,191.46233],[174.85252,0.8927449,193.07378],[174.48347,0.7260392,173.76399],[197.83144,1.2007316,106.72905],[198.29631,0.8238746,68.25558],[195.15263,2.4481394,188.36281],[198.78384,1.374482,197.45576],[121.030396,0.5954653,151.62656],[198.49103,6.5779333,198.34833],[197.9355,66.15786,143.80432],[198.08162,83.63421,196.87816],[150.57755,81.34436,197.4637],[197.8148,40.970535,198.4135],[198.15536,1.0915563,33.184784],[198.458,1.0484954,148.62389],[192.79448,1.3267837,199.33096],[197.77136,1.4718939,197.66107],[197.05774,1.0737085,119.49109],[187.32698,3.64072,192.34505],[198.44463,18.189999,198.42627],[198.3915,48.3395,0.69401884],[54.56334,1.494458,197.9336],[198.00517,16.140324,193.87428],[167.12679,2.031646,184.89903],[171.75784,1.3025832,54.021812],[189.27719,0.68616265,193.31288],[161.2422,0.73277676,181.05205],[189.49803,1.0931689,197.40561],[182.28088,0.8211672,190.53355],[165.2676,1.5973027,184.67947],[159.99225,0.6472157,129.25357],[128.78035,1.1769425,138.14981],[179.40723,0.9127062,181.20789],[180.00656,0.656351,102.67817],[192.47777,1.956461,194.6972],[172.51227,0.8441109,195.0836],[172.74869,0.87490404,171.59302],[167.44675,2.385794,198.48326],[151.19948,0.8941742,178.03159],[185.75307,11.238015,177.26566],[198.3781,3.5325782,196.87639],[180.45183,1.5457566,191.2895],[179.9079,1.4334152,182.56439],[193.17882,1.3342363,170.9235],[179.25766,0.8895546,74.83411],[182.56642,1.5377191,196.19695],[168.7036,1.1542765,199.16258],[176.8041,2.6911638,194.12529],[181.33105,1.378669,188.24696],[199.44528,1.2414036,190.58932],[198.01915,3.2037094,179.63557],[164.4099,1.2827579,199.34169],[187.72404,42.13465,198.01756],[198.18549,1.5741442,51.432404],[190.09892,3.7664857,195.47029],[179.29332,1.132347,184.34529],[161.62897,1.2712467,190.94406],[193.8514,2.2768574,182.90991],[176.07755,1.4053805,179.60548],[165.59152,1.102331,184.28807],[188.14685,0.889617,190.89885],[190.35283,1.5495491,196.36768],[158.00812,0.85970145,182.3148],[197.66058,1.3657455,76.5388],[198.34834,1.4074095,11.737535],[155.69963,0.5243771,178.56517],[198.29027,1.2687575,197.40318],[174.58656,1.3768433,179.80592],[160.8517,1.4290953,194.45844],[194.43591,1.3463418,196.95547],[164.19926,35.821102,161.47469],[159.57196,1.2694919,198.39758],[198.61053,5.0210733,179.48969],[198.6844,1.4906855,21.587477],[197.93369,1.1745217,194.93497],[185.68459,0.7026768,184.63365],[180.25385,2.3392584,173.17064],[193.89398,1.5751307,194.24165],[175.76198,1.3982314,186.57751],[199.04103,52.096733,176.64392],[151.86865,0.7958768,177.16768],[154.01627,0.8711799,193.0947],[187.42076,1.5742171,198.50499],[199.11987,1.2491652,187.87659],[190.92334,1.2754799,195.6011],[188.62679,1.4248925,189.23372],[184.20586,0.66415536,192.35852],[176.76457,1.1077597,185.09671],[180.06244,1.0137564,199.24391],[198.16255,73.83079,195.76213],[198.41849,70.32704,129.07265],[196.64558,0.6633455,197.24928],[166.72969,0.85006094,180.53197],[196.46896,1.4042236,174.42204],[196.75554,2.7146,195.55013],[196.15602,2.0774713,193.38083],[178.64018,1.512146,198.62924],[175.19682,15.670244,175.57509],[198.38904,24.902859,111.79803],[198.588,2.2751846,177.88115],[198.1523,65.08873,101.832436],[198.74486,55.321182,167.12144],[167.72902,1.3791047,198.49034],[198.23721,47.535305,132.75186],[198.57771,1.2254206,10.550398],[198.03346,4.5360518,154.6973],[196.0587,1.3181697,193.31145],[198.67226,3.5524874,196.74881],[197.07652,18.931358,198.44173],[168.89056,0.7601826,181.01436],[199.4076,36.102737,133.12042],[198.49298,46.94912,117.52448],[198.41475,47.194214,188.97102],[197.96603,1.2241663,0.3122391],[198.5135,1.5331883,54.001133],[187.89508,1.0388067,197.50533],[190.63567,2.9562366,196.05766],[194.32347,0.90191203,199.30678],[160.91621,34.443214,134.74936],[186.52379,1.5928581,195.25966],[186.14758,1.2434437,194.36086],[47.289886,1.286993,89.27341],[57.971447,1.1408865,198.2109],[198.22838,1.1624993,28.716976],[159.96896,1.0770586,74.34593],[162.0776,1.4904912,196.97821],[194.13136,4.799131,188.516],[178.69957,1.4651096,189.28937],[191.83258,1.5029284,173.71172],[163.35492,1.0607864,177.29018],[195.36298,0.58738697,187.27472],[159.93117,1.6050382,198.83798],[152.95676,1.5594995,197.83366],[196.13713,1.4692405,195.31752],[198.66081,0.81052923,88.74299],[154.83333,0.7769164,98.242676],[171.0645,1.5427057,196.3678],[165.31525,1.4758627,195.62772],[175.83221,1.5118234,188.32556],[175.24013,1.0106161,189.11569],[197.44536,1.2709675,145.07196],[167.98927,1.5344383,178.47676],[140.50194,1.3608373,85.527695],[175.07346,1.1877022,187.7305],[189.22827,0.70565116,77.75494],[183.06836,0.69288176,189.3984],[168.49857,0.9842722,198.47293],[174.92393,0.5000297,198.34505],[160.75618,1.0629456,192.48184],[164.47777,1.2826931,177.311],[198.41675,0.62407243,57.630165],[188.97667,1.5319083,195.87383],[192.17963,1.2374026,176.5146],[185.01733,0.8635687,187.1064],[198.50179,1.0978847,41.04489],[185.79498,0.6725768,57.899178],[171.88737,1.1710604,198.6652],[169.73268,1.689073,198.10663],[184.40024,1.4827931,184.29628],[160.2253,0.95065045,192.25107],[163.06064,1.5138222,102.47893],[196.84216,1.4505113,122.5987],[184.90393,1.4663298,183.1942],[180.36777,0.5065757,186.73091],[198.11623,0.70958245,69.48635],[192.64426,1.3862362,196.20728],[197.28265,2.3527148,176.88326],[176.70271,0.57402563,182.00972],[165.3298,17.375671,181.28958],[167.43929,1.5008603,176.65329],[142.41489,1.5026746,198.2298],[146.86162,1.4763134,175.43256],[190.40216,0.9590267,198.90643],[165.6807,0.70253193,111.80126],[196.29048,0.5822494,48.269146],[184.4742,1.4543129,196.72777],[162.68921,0.62357926,186.78914],[167.05988,1.3664043,187.71938],[163.3835,1.5203615,157.79703],[186.29161,1.2743348,187.94402],[181.08954,1.406305,189.38637],[183.81526,1.5422837,185.64015],[165.13492,0.82567304,177.61766],[198.49417,89.21003,95.173195],[195.33528,1.2613642,79.208176],[197.18913,28.593607,198.48265],[179.85074,0.8141397,194.39684],[177.63298,1.502298,178.83913],[199.20927,0.94882065,174.73193],[196.9092,6.6080728,198.36873],[198.90872,1.0046705,90.46355],[173.12775,0.9552691,176.33493],[168.67554,1.6648989,168.08359],[170.07944,6.8749685,170.93243],[197.33162,1.3500844,47.76061],[197.73093,1.2954093,36.365448],[178.20583,1.4276453,180.06621],[189.07242,0.98958296,190.42119],[197.09894,50.735397,177.47765],[175.65874,1.1826336,171.34627],[196.4202,96.047745,86.66869],[198.43163,1.7231392,153.01013],[180.39148,0.7971734,182.89906],[198.01877,1.4223322,8.338392],[198.61096,1.4660022,111.608574],[179.69672,1.4730304,194.4531],[185.55293,0.8971108,198.69746],[194.89827,0.66170603,180.5669],[196.52998,39.453907,198.21352],[160.48457,0.5422466,88.7654],[176.16331,1.2013965,188.89868],[175.11346,0.5371837,137.87077],[159.07944,27.183048,135.78966],[197.6911,6.662053,193.69292],[198.04643,1.5224144,126.34333],[198.46973,35.508846,198.55492],[185.53065,1.2914982,191.3861],[183.80194,1.3670775,183.05434],[198.55191,28.70514,128.46986],[158.50916,30.186293,133.87721],[199.20767,1.5799882,180.74309],[198.499,1.4863393,191.3238],[163.95593,53.786385,197.43]]}

so i was able to tweak my params to appear to avoid the panic:
Parameters {
    particle_radius: 0.4,
    rest_density: 1000.0,
    compact_support_radius: 2.0,
    cube_size: 0.6,
    iso_surface_threshold: 0.45,
    domain_aabb: None,
    enable_multi_threading: false,
    spatial_decomposition: None,
}

it doesn't look as good imho, but it seems to work for now.  making the functions more panic safe would be great though :)

So for me your first particle set works when using the following parameters:
let params = Parameters {
        particle_radius: 0.5,
        rest_density: 1000.0,
        compact_support_radius: 2.0,
        cube_size: 0.75,
        iso_surface_threshold: 0.45,
        domain_aabb: Some(AxisAlignedBoundingBox3d::new(
            Vector3::new(46.0, 0.0, -1.0),
            Vector3::new(200.0, 100.0, 200.0),
        )),
        enable_multi_threading: false,
        spatial_decomposition: None,
    };

i.e. by specifiying a sufficiently large AABB. I would recommend using this if you know that your simulation domain cannot be larger than this over all timesteps. Of course this might not be possible for all applications. As mentioned before, not specifying this explictly but using the automatic computation over multiple timesteps might lead to temporal artificats due to the implicit cube grid moving between timesteps. To fix this, I would have to add an alternative option for e.g. an "anchor point" of the automatically computed grid/AABB. I'll put this onto my todo list.
To properly fix your problem, I still have to

Check why the margin of the automatic AABB computation is not sufficient in this case
Replace the panic with an error

Furthermore, I found another panic that should be replaced with an error. When you deliberatley pass in an AABB that is too small for all particles, the neighborhood search can crash. This is caused by particles outside of the domain not being explicitly filtered out in the beginning. Later they cannot be correctly located inside the AABB which leads to a panic.

Hmm, i tried using a domain aabb which should smaller and larger than any of the attached position, but i'm still seeing the panic:
Parameters {
    particle_radius: 0.5,
    rest_density: 1000.0,
    compact_support_radius: 2.0,
    cube_size: 0.75,
    iso_surface_threshold: 0.45,
    domain_aabb: Some(
        AxisAlignedBoundingBox { min: [-10.0000000, -10.0000000, -10.0000000], max: [210.0000000,<PHONE_NUMBER>,<PHONE_NUMBER>] },
    ),
    enable_multi_threading: false,
    spatial_decomposition: None,
}

{"positions":[[158.80353,29.653088,131.12979],[156.49847,29.48464,130.72267],[157.97023,29.500221,133.33952],[158.75528,29.712734,134.45831],[159.43091,29.702572,135.41794],[158.59912,30.366186,130.89786],[158.31448,30.821266,131.89442],[158.39333,30.8764,133.23872],[158.79137,30.573883,134.7547],[159.4229,30.64538,135.44809],[157.75726,31.749855,131.56218],[158.35136,31.749905,132.19568],[158.49353,31.71414,133.2391],[158.83691,31.852606,134.56932],[159.24124,31.642317,135.39131],[157.48033,32.568535,131.65637],[158.69238,33.028477,131.99512],[158.55763,32.93753,133.26659],[159.0332,32.569744,134.50768],[159.07579,32.64805,135.30394],[157.54507,33.692207,131.43414],[158.68631,33.73513,132.30559],[156.50899,33.726917,131.98593],[158.20586,33.927856,133.77898],[159.06229,33.751892,135.42978],[157.75188,30.38949,129.508],[156.9066,29.031578,131.4931],[157.42078,28.715755,131.65086],[157.35329,30.391077,133.50984],[160.09404,29.610209,135.63797],[160.02188,30.520048,130.68944],[159.1442,31.084026,131.03828],[158.90552,30.81909,133.28174],[159.78168,30.530987,134.83482],[160.1775,30.602213,135.71945],[158.52737,31.255272,130.97487],[159.27599,32.172348,131.53534],[159.27592,31.83924,133.13837],[159.2465,31.846283,134.73499],[159.919,31.617422,135.89377],[158.31448,32.85959,130.78267],[160.04071,32.844414,132.03197],[157.08725,32.899094,132.14748],[157.13313,32.920116,133.42743],[159.97743,32.82193,135.60214],[158.56192,34.368103,131.05093],[158.5113,33.885944,129.8644],[160.18361,33.966286,131.2508],[157.60173,33.91294,134.4811],[155.89565,33.75132,133.82825],[157.11964,29.49432,128.54036],[160.48341,29.015345,131.85187],[157.24881,30.975653,132.37389],[158.33853,29.750172,131.6216],[161.33699,29.339958,136.14505],[157.64424,32.20989,129.14102],[159.2364,31.002285,130.40578],[158.90535,31.030252,131.9429],[159.22212,30.25468,133.97203],[160.9458,30.774242,136.06688],[160.56013,30.625599,130.21872],[159.08101,32.27511,131.14696],[161.30872,31.940845,131.31587],[159.38187,31.669683,132.57504],[160.82678,31.814278,135.75404],[160.79489,33.1244,130.31056],[159.48212,33.553955,130.05826],[161.20111,33.029266,131.23627],[159.70198,33.068214,132.41222],[158.72656,32.68203,135.69145],[160.63069,34.93365,131.04996],[157.45479,34.052563,130.08138],[158.49586,34.39145,132.61302],[157.85861,34.994877,131.2869],[157.46144,33.912586,135.83891],[162.31516,29.527967,129.95833],[159.31366,29.803345,129.88002],[157.71466,28.377062,130.08728],[157.03418,29.019152,132.25041],[157.49641,28.548655,133.92354],[161.94164,30.813242,130.18686],[158.60742,31.448334,129.40593],[160.25891,31.297565,130.86592],[160.64478,30.1442,132.1987],[160.3668,31.429773,135.00555],[154.9756,30.541649,130.15952],[158.5036,31.998848,129.5844],[159.10284,32.69271,129.77077],[158.69357,32.324116,131.1839],[158.67522,31.503801,136.75938],[155.01317,33.113457,129.95638],[162.19765,32.97756,131.50467],[158.83803,32.685993,130.02263],[158.63316,32.5622,132.24545],[158.67722,33.421078,136.75229],[154.84653,35.465904,130.76035],[162.68942,33.877724,131.62354],[162.49829,34.157906,131.79317],[161.95168,34.368904,131.49219],[157.50499,34.245407,133.68677],[164.13231,29.347942,130.46242],[158.6581,28.648994,128.63608],[159.15332,28.699114,128.89018],[158.6987,29.97141,131.11748],[158.03801,29.540203,132.32712],[163.7454,30.885513,129.33295],[160.95105,30.97818,129.50124],[159.43896,30.547253,132.00703],[157.53246,30.435358,132.32213],[160.13394,29.650892,134.37036],[156.73044,31.667141,130.9136],[160.26361,31.929098,128.9026],[160.50352,31.75374,129.75168],[159.602,32.017506,130.54283],[158.09337,31.784245,133.14569],[156.99629,32.74391,131.00879],[163.68765,32.62551,132.22147],[160.84714,32.38678,130.11415],[158.84825,32.547688,134.43996],[157.66757,32.858322,133.41154],[156.4662,34.143238,130.94165],[163.65309,33.71715,131.95851],[164.5175,33.84594,132.47034],[158.84236,35.300537,131.33473],[158.44725,34.891098,132.71939]]}

Thanks for the feedback! That was a bit surprising to me. I think I didn't notice this issue before because I'm often using much smaller particle radii and larger surface thresholds. Anyway, I think the cause of the issue should be fixed on master for now. Can you try changing your explicit version dependency of the lib to the current master and try it out before I publish a new version?
I still have to add some errors instead of panics though.

yes, this appears to fix the issue (or at least i can't reproduce it anymore!) this is great, thanks! so if i tweak the some of the param values will the panic manifest again, or has the general underlying issue likely been fixed?

This specific error should not appear anymore. It should now be similiar to the situation before the version that introduced this panic. In any case, thanks for reporting this. Your data really helped debugging this.
I'll leave this open until I added some errors instead of panics at places related to this.

great, and thanks for fixing so quickly! let me know if you need anything else

Ok, closing this now as I started to return some more errors, e.g. when the triangulation fails (https://github.com/w1th0utnam3/splashsurf/commit/6fd48cd17f967d95b9371768be5432b1251dc354).


V 1.19.2 | LootTable

Describe the Bug
As soon as I start my server these errors come up in the console.
[main/ERROR] [minecraft/LootTables]: Couldn't parse loot table extendedgears:blocks/brass_cogwheel
[minecraft/LootTables]: Couldn't parse loot table extendedgears:blocks/large_brass_cogwheel
Reproduction Steps

starting server
see console

Crash Report or Log
https://pastebin.com/9hTQWNtc
Operating System
Windows 10
Mod Version
0.5.0i
Minecraft Version
1.19.2
Forge Version
43.2.4
Other Mods
[Mod Liste.txt] (https://github.com/Creators-of-Create/Create/files/10610579/Mod.Liste.txt)
Additional Context
auch in anderen Versionen

Patched In Latest Beta Release


How to use? / Dont work with useraccount and "admin"

Like the Titel says.
Quiet dont understand how to use it.
Installed pytapo, created "device account" on the tapo app (it works, zoneminder use it already over rtsp).
Created a test.py like described:
from pytapo import Tapo

user = "admin" # user you set in Advanced Settings -> Camera Account
password = "yopasswordsecret" # password you set in Advanced Settings -> Camera Account
host = "<IP_ADDRESS>" # ip of the camera, example: <IP_ADDRESS>

tapo = Tapo(host, user, password)

print(tapo.getBasicInfo())

Tried user, the user i set in the app. both dont work:
#: python test.py
Traceback (most recent call last):
  File "/home/user/test.py", line 7, in <module>
    tapo = Tapo(host, user, password)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/pytapo-3.3.18-py3.11.egg/pytapo/__init__.py", line 86, in __init__
  File "/usr/lib/python3.11/site-packages/pytapo-3.3.18-py3.11.egg/pytapo/__init__.py", line 1009, in getBasicInfo
  File "/usr/lib/python3.11/site-packages/pytapo-3.3.18-py3.11.egg/pytapo/__init__.py", line 491, in executeFunction
  File "/usr/lib/python3.11/site-packages/pytapo-3.3.18-py3.11.egg/pytapo/__init__.py", line 530, in performRequest
  File "/usr/lib/python3.11/site-packages/pytapo-3.3.18-py3.11.egg/pytapo/__init__.py", line 108, in ensureAuthenticated
  File "/usr/lib/python3.11/site-packages/pytapo-3.3.18-py3.11.egg/pytapo/__init__.py", line 418, in refreshStok
  File "/usr/lib/python3.11/site-packages/pytapo-3.3.18-py3.11.egg/pytapo/__init__.py", line 418, in refreshStok
  File "/usr/lib/python3.11/site-packages/pytapo-3.3.18-py3.11.egg/pytapo/__init__.py", line 423, in refreshStok
Exception: Invalid authentication data

What i try to do, is to be able to move and tilt my camera.

For admin account use your tplink cloud pwd.

Because it works for hundreds others with this exact configuration with no issues and it's support question not an actual issue that needs to be fixed.

-Tapoversion: Latest from Google Play available for Google Pixel 7 Pro. Version 3.1.315(1065)
-Tapo C200 Version 1.3.9 Build 231019 Rel.29120n(4555)
What i have done:
-Exactly what the App wanted. Everything works on the App. Created local account under advanced settings (user: userab, password: the same like for the cloud. both works (can log in the app, and can watch rtsp stream with that password)).
-Intalled pytapo, created test.py with the content like posted.
-executed the script with python test.py (as user and root, linux)

[...]as well as enable debug logs and post that.

how do i enable debug logs pytapo?

What pytapo version are you using?
Set printDebugInformation to true in initializer of pytapo.

What pytapo version are you using?

git. so the latest available. 20 Nov. 2023.

Set printDebugInformation to true in initializer of pytapo.

How i do that? I dont have a init.py file on my System:

Pass it to the pytapo initializer inside function Tapo(host, user, password)


F masking enhancement

Issue #1837 - Fix Details: There is no way to access ScenarioRuntime.engine.getConfig() in the Result phase. So in order to find out if call args(any args defined in config of karate-config.js) needs to be hidden, I am checking the if a step result has field hidden == true then I am making callArgs values set to ***
HOW TO TEST AND VALIDATE
STEP 1:
NOTE:  To test the fix, uncomment these line in karate-core/src/test/java/karate-config.js
 //var results = karate.callSingle('classpath:com/intuit/karate/report/suite.feature@test1',config);
  //results = karate.callSingle('classpath:com/intuit/karate/report/suite2.feature@test2',config);

STEP 2:
Run test karate-core/src/test/java/com/intuit/karate/report/CucumberMaskReportTest.java
STEP 3:
Check the cucumber-html-reports under target folder.
You should see that for step definition -

com/intuit/karate/report/suite.feature@test1 the values are masked with *** as file has

* config report = false

com/intuit/karate/report/suite.feature@test1 the values are NOT masked with *** as file is not using report = false

Description
Thanks for contributing this Pull Request. Make sure that you submit this Pull Request against the develop branch of this repository, add a brief description, and tag the relevant issue(s) and PR(s) below.

Relevant Issues : (compulsory)
Relevant PRs : (optional)
Type of change :

[ ] New feature
[X ] Bug fix for existing feature
[ ] Code quality improvement
[ ] Addition or Improvement of tests
[ ] Addition or Improvement of documentation

and I think you noticed it - make sure PRs are against develop not master

I will redo the PR.
The reason we have to check the steps of a scenario because
a) the report = false flag only focuses on values in feature files.
b) The showLog property is not available during the Result phase.

The showLog property is not available during the Result phase.

which means it may need to be passed along. this is a design change, hence needs time, but happy to review what you come up with


Add Stride <> Stargaze and stSTARS

Add Stride <> Stargaze connection information to chain registry, as well stSTARS info and images

LGTM!


Unexpected change to DateTimeKind of MessageContext.SentTime in v8.2.0

Contact Details
No response
Version
8.x
On which operating system(s) are you experiencing the issue?
Linux
Using which broker(s) did you encounter the issue?
Amazon SQS
What are the steps required to reproduce the issue?
Previously (at least in v8.1.x), ConsumeContext<T>.SentTime satisfied the pattern context.SentTime is null or { Kind: DateTimeKind.Utc }, but as of v8.2.0, this is no longer the case.
I'm opening this issue because from looking through the commits included in v8.2.0, I don't think this was an intentional change, so while it's easy enough for me to work around, figured it was worth bubbling to you kind folks for review.
Possibly related to b8e20552b84e8b1b50974a5779219c90aa6fe38c, but I'm not entirely sure yet.
Opening this as a placeholder without a self-contained repro because I just got burned by this and want to flag it for others, but won't have time to put together a self-contained repro until later tonight, but will update this issue when I can.
public Task Consume(ConsumeContext<SomeMessage> context)
{
    Debug.Assert(context.SentTime is null or { Kind: DateTimeKind.Utc });

    return Task.CompletedTask;
}

What is the expected behavior?
MessageContext.SentTime is null or contains a DateTime with DateTimeKind.Utc.
What actually happened?
MessageContext.SentTime is null or contains a DateTime that is not DateTimeKind.Utc.
Related log output, including any exceptions
These logs are very unlikely to matter to the MassTransit team, but including for the sake of completeness (and SEO for future readers) to show how this manifested in my specific case which was triggered when converting to NodaTime's Instant type:
context.SentTime?.ToInstant()

System.ArgumentException: Invalid DateTime.Kind for Instant.FromDateTimeUtc (Parameter 'dateTime')
   at NodaTime.Utility.Preconditions.CheckArgument(Boolean expression, String parameter, String message)
   at NodaTime.Instant.FromDateTimeUtc(DateTime dateTime)
   at NodaTime.Extensions.DateTimeExtensions.ToInstant(DateTime dateTime)
   at SomeConsumer.Consume(ConsumeContext`1 context) in /_/src/SomeConsumer/SomeConsumer.cs:line 62
   at MassTransit.DependencyInjection.ScopeConsumerFactory`1.Send[TMessage](ConsumeContext`1 context, IPipe`1 next) in /_/src/MassTransit/DependencyInjection/DependencyInjection/ScopeConsumerFactory.cs:line 22
   at MassTransit.DependencyInjection.ScopeConsumerFactory`1.Send[TMessage](ConsumeContext`1 context, IPipe`1 next) in /_/src/MassTransit/DependencyInjection/DependencyInjection/ScopeConsumerFactory.cs:line 22
   at MassTransit.Middleware.ConsumerMessageFilter`2.MassTransit.IFilter<MassTransit.ConsumeContext<TMessage>>.Send(ConsumeContext`1 context, IPipe`1 next) in /_/src/MassTransit/Middleware/ConsumerMessageFilter.cs:line 48

Link to repository that demonstrates/reproduces the issue
No response

You'll need to submit a repository that reproduces this, because in my quick test using both InMemory and SQS, I didn't see the issue:
namespace MassTransit.AmazonSqsTransport.Tests
{
    using System;
    using System.Threading.Tasks;
    using Microsoft.Extensions.DependencyInjection;
    using NUnit.Framework;
    using TestFramework.Messages;
    using Testing;

    [TestFixture]
    public class SentTime_Specs
    {
        [Test]
        public async Task Should_have_sent_time_header_in_utc()
        {
            await using var provider = new ServiceCollection()
                .AddMassTransitTestHarness(x =>
                {
                    x.AddHandler(async (PingMessage _) =>
                    {
                    });

                    x.UsingAmazonSqs((context, cfg) =>
                    {
                        cfg.LocalstackHost();

                        cfg.ConfigureEndpoints(context);
                    });
                })
                .BuildServiceProvider(true);

            var harness = await provider.StartTestHarness();

            await harness.Bus.Publish(new PingMessage());

            IReceivedMessage<PingMessage> consumed = await harness.Consumed.SelectAsync<PingMessage>().FirstOrDefault();
            Assert.That(consumed, Is.Not.Null);

            Assert.That(consumed.Context.SentTime.Value.Kind, Is.EqualTo(DateTimeKind.Utc));
        }
    }
}

Still trying to figure out how to reproduce this outside of AWS, but added some logs just to prove (mostly to myself) that I'm not imagining this:
public Task Consume(ConsumeContext<SomeMessage> context)
{
    DebugMassTransit(context.SentTime, context.ReceiveContext.TransportHeaders.TryGetHeader(MessageHeaders.TransportSentTime, out var header) ? header : null);

    return Task.CompletedTask;
}

[LoggerMessage(200, LogLevel.Information, "Received message using MassTransit with AmazonSQS at {SentTime} based on header value {Header}")]
partial void DebugMassTransit(DateTime? sentTime, object? header);

[2024-03-28T23:18:21.695Z] Received message using MassTransit with AmazonSQS at 09/07/2270 07:27:37 based on header value (null)
...
[2024-03-28T23:25:49.779Z] Received message using MassTransit with AmazonSQS at (null) based on header value
...
[2024-03-28T23:27:35.969Z] Received message using MassTransit with AmazonSQS at 06/23/2500 00:22:07 based on header value (null)
...
[2024-03-28T23:27:37.154Z] Received message using MassTransit with AmazonSQS at 12/31/9999 23:59:59 based on header value (null)

Based on the above logs it appears that the timestamps I'm seeing are not coming from context.ReceiveContext.TransportHeaders.GetTimestamp(MessageHeaders.TransportSentTime) since none of the logs ever return a value from context.ReceiveContext.TransportHeaders.TryGetHeader(MessageHeaders.TransportSentTime, ...).

Also, assuming the AWS SQS docs are up to date, I'm not sure this call to DateTime.TryParse(...) ever succeeds since SentTimestamp is described in the docs as milliseconds since epoch, and, at least in my local testing, DateTime.TryParse(...) didn't like being given a stringified unix timestamp.
https://github.com/MassTransit/MassTransit/blob/0341a02e74f93b54d0f8c6a70616b969d76af964/src/Transports/MassTransit.AmazonSqsTransport/AmazonSqsTransport/AmazonSqsHeaderProvider.cs#L35-L45

So question becomes: how else is MessageContext.SentTime populated? Maybe something in a retry filter?

Actually, it occurs to me now that many (but not all) of these logs are for 12/31/9999 23:59:59 which is suspiciously DateTime.MaxValue.

I have access to SQS, I can test it, but I need a complete repository reproducing it because testing with localstack (which is identical to SQS) works just fine.

Based on the above logs it appears that the timestamps I'm seeing are not coming from context.ReceiveContext.TransportHeaders.GetTimestamp(MessageHeaders.TransportSentTime) since none of the logs ever return a value from context.ReceiveContext.TransportHeaders.TryGetHeader(MessageHeaders.TransportSentTime, ...).

Why would you use the new header, vs. just using consumeContext.SentTime which is what you should be using. Especially prior to 8.2.0.

Why would you use the new header, vs. just using consumeContext.SentTime which is what you should be using. Especially prior to 8.2.0.

Oh, wasn't trying to actually use it, just tried extracting it in those logs for the sake of figuring out if that's where the funky datetime data was coming from. The actual app code has always/continues to use consumeContext.SentTime.


Some impls have wrong impl of total length encoding for lengths > 127

Reported (email) by Daniel Braniss
What is wrong / not implemented
For len=224 "E0 01" is sent, which is correct, and decoding side does "((E0 & ~80) << 7) + 1"
How should it be
1 << 7 | (e0 & ~80)
i.e. order of processing is wrong.

@dzavalishin where should we add this change?


Use absolute path for static directory

Docs repos can be structured in various ways, so we need to make sure that sphinxmark knows the correct place to find and create static files.

Setting an absolute static path that leads where we want it to is difficult. Let's try refactoring so no files need to be copied.

Ooo. And we can grab the config.py path from Sphinx. Nice.


version problem

Unable to install razorpay/ifsc after updating laravel, causing error because it requires php-http/httplug version 1.0 and i have latest version 2.0, and i can't degrade, thus package cannot be installed error.

it is not reflected yet on packagist

Dear,
It is not reflected yet on packagist.
On Fri, Jun 21, 2019 at 11:39 PM Nemo<EMAIL_ADDRESS>wrote:

Closed #130 https://github.com/razorpay/ifsc/issues/130 via #132
https://github.com/razorpay/ifsc/pull/132.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/razorpay/ifsc/issues/130?email_source=notifications&email_token=AECBCDDYNZXVJ4DUQRMBGCLP3UKMFA5CNFSM4HZTCPY2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOSDTQG2I#event-2431058793,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AECBCDBRJZPXTDOSPFNDLMLP3UKMFANCNFSM4HZTCPYQ
.

The next 1.4.4 release (pending today/tomorrow) will have this covered.


Add Java Command Line Args At Runtime

I want to add command line args to the entrypoint based on runtime environment variables. For example, right now my Java application runs as java -classpath . org.springframework.boot.loader.JarLauncher. I want to expose an environment variable to the Docker image called JAVA_OPTS and have the value of that added to that command. So, for example if JAVA_OPTS is set to -javaagent:myagent.jar then the command becomes java -classpath . org.springframework.boot.loader.JarLauncher -javaagent:myagent.jar. Is it possible to do this?

I think you can do this by having a custom Procfile with something like:
web: java -classpath . org.springframework.boot.loader.JarLauncher $JAVA_PARAMS

Note that I used JAVA_PARAMS since JAVA_OPTS usually gets used for other things.

Just in case you're looking to do this because of difficulty in passing in arguments in the past…
We recently updated the GCP Buildpacks to use Cloud Native Buildpacks lifecycle 0.9 / Platform API 0.4 which reworks how processes are represented.  Buildpacks-built images now behave like normal container images, such that you you can just provide command-line arguments using the normal mechanisms.  For example:
$ cat src/main/java/Main.java
public class Main {
  public static void main(String[] args) {
    for(String arg : args) {
      System.out.println("arg: " + arg);
    }
  }
}

$ pack build jcli --builder gcr.io/buildpacks/builder:v1
...
$ docker run --rm jcli arg1 arg2 arg3
arg: arg1
arg: arg2
arg: arg3

Thanks that's good to know.
I found that for Java I could use JDK_JAVA_OPTIONS and it got picked up correctly. I'll stick with that for now.


GoogleCredentialsProvider$Builder.setUseJwtAccessWithScope not registered for reflection

We are using GraalVM support library 0.5.0 with the Google Cloud Workflows library version 2.0.2 successfully (even though it's not officially supported). When we tried to upgrade the workflows library to 2.0.3 we got the following error at runtime:
java.lang.NoSuchMethodError: com.google.api.gax.core.GoogleCredentialsProvider$Builder.setUseJwtAccessWithScope(boolean)

This was the workflows SDK change:
https://github.com/googleapis/java-workflow-executions/compare/v2.0.2...v2.0.3
Relevant bit:
    return GoogleCredentialsProvider.newBuilder()
        .setScopesToApply(DEFAULT_SERVICE_SCOPES)
        .setUseJwtAccessWithScope(true);

Flagging because it seems like it might be a general method that might get used across various SDKs.
We were unable to test it with 0.6.0, so not sure if the above has been resolved in that version.

Hey @kostacasa -- I think this issue is not GraalVM/reflection related but rather an issue with library versions in your stack.
This method com.google.api.gax.core.GoogleCredentialsProvider$Builder.setUseJwtAccessWithScope(boolean) was actually introduced relatively recently here: https://github.com/googleapis/gax-java/commit/ed39c34693783460fc03effb47e7027914cfb5bc
From what it looks like, I think cloud workflows library expects a newer version of gax than what may be in your dependency tree right now. The method was introduced in com.google.api:gax in version 2.3.0. Can you run a mvn dependency:tree and confirm that your version of com.google.api:gax is above version 2.3.0?

Hi @dzou! You are right, we accidentally explicitly defined the workflow dependency version instead of letting the Google libraries-bom manage it. Our libraries-bom was on v 2.1.0 and so it was pulling in the older (and incompatible) com.google.api:gax.
That said, I can confirm that google-cloud-workflow-executions library seems to work just fine in native mode! I might throw together a quick sample so that you can add it to the compatibility table.

Nice, great to hear you figured out the issue!

I might throw together a quick sample so that you can add it to the compatibility table.

Hey, don't worry about doing this. We're developing a more comprehensive way of testing to validate all the google cloud client libraries in one go. And this will be a much stronger guarantee than the samples approach we've been taking :slightly_smiling_face:. Soon we hope to be able to say that "everything just works."


A few things.

Why does this app request access to manage device accounts, and administer the devices, when Github doesn't have features to control said access to its users?

Needs to be able to logout.

I currently have 3 issues that are mentioning me, and one opened by me. None show in the dashboard.

This issue now boils down to the idiosyncrasies within the app dealing with repository issues, which are mentioned in many other issues.

Moved to #312


non-linear diffusion problem

Hello,
I am looking to solve a non-linear diffusion problem
$-\nabla  \cdot  \kappa(u)\nabla u = f$
I checked the documentation for linear integrators and bilinear integrators:
https://mfem.org/lininteg/
https://mfem.org/bilininteg/
and ex0.cpp for a simple diffusion equation.
From what I gather from the above documentation, you can use the above linear operators to solve linear PDEs if not wrong. However, I do not know how to go about solving non-linear PDEs.
I am relatively new to mfem, if there is an existing example or a sample code, from which I can build that would be great. Thank you.
Kind regards,
Karthik.

Hi @karthichockalingam ,
You have to use a NonlinearForm with an appropriately-prepared NonlinearFormIntegrator for this - please check out https://github.com/mfem/mfem/issues/3975, I had pretty much this same question when first starting up with MFEM and hope that the linked discussion helps!

Thank you @j-signorelli for your response. I will have a look.

Hi @j-signorelli I was able to go over the issue and understand how to implement non-linear PDEs :)
Thanks a lot. Please let me know how I can make it a time-dependent problem.
$\frac{\partial u}{\partial t} -\nabla  \cdot  \kappa(u)\nabla u = f$
In the sample non-linear code gist, shared by @pazner , the AddDomainIntegrator is called using  NonlinearForm
// 6. Set up the nonlinear form n(u,v) = (grad u, grad v) + (f(u), v)
   NonlinearForm n(&fespace);
   n.AddDomainIntegrator(new NonlinearMassIntegrator(fespace));
   n.AddDomainIntegrator(new DiffusionIntegrator);
   n.SetEssentialBC(boundary_dofs);

In the above code, I believe everything is assembled elementwise.
In ex16 were a time depenedent non-linear PDE is solved, the AddDomainIntegrator is called using BilinearForm
void ConductionOperator::SetParameters(const Vector &u)
{
   GridFunction u_alpha_gf(&fespace);
   u_alpha_gf.SetFromTrueDofs(u);
   for (int i = 0; i < u_alpha_gf.Size(); i++)
   {
      u_alpha_gf(i) = kappa + alpha*u_alpha_gf(i);
   }

   delete K;
   K = new BilinearForm(&fespace);

   GridFunctionCoefficient u_coeff(&u_alpha_gf);

   K->AddDomainIntegrator(new DiffusionIntegrator(u_coeff));
   K->Assemble();
   K->FormSystemMatrix(ess_tdof_list, Kmat);
   delete T;
   T = NULL; // re-compute T on the next ImplicitSolve
}

Maybe  ex16, K is to setting up the global assembly of Kmat. I am not sure if I should proceed element-wise and by globally assembled matrix to make the problem time-dependent. If I should be using NonlinearForm or not.
If the sample non-linear code gist can be extended to time-dependent problems, it would be helpful.
Many thanks!!


Chrome data channels drop queued data on close

Ref: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/source/talk/app/webrtc/datachannel.cc&rcl=1425488633&l=390

We don't seem to verify that there aren't any queued messages to go out on the DataChannel before actually closing.  Only happens when we're congested.

Verify that usrsctp sends stream ID resets in queue order with data chunks.

So, I tried to produce a single-page repro case just now and couldn't.
Here is my test case:
https://gist.github.com/trevj/f5417ba1b04440cab1a1
Here's what it does:

establishes a WebRTC connection
generates a 4096-byte ArrayBuffer
sends that buffer 1000 times, then immediately close the channel

This raises the question of why this doesn't seem to work in Simple SOCKS. Are they actually the same thing?

Lets chat about it: socks-rtc has the event-tick-loop thing that is likely to interleave the close call within the other sends; could it be that? (we need to make sure to call close only after the send queue is empty if we use the tick-waiting approach)

If we were calling send() after close() then we would see this error in the logs:
Uncaught NetworkError: Failed to execute 'send' on 'RTCDataChannel': Could not send data

I don't see that, though.

@iislucas I think your hunch about event ordering on the SocksToRtc side may be right. I hacked SockstoRtc to not close the data channel when it detects it's shut...just to see what happens. It seems like the data is received!
So, next week I'll figure out a way to workaround this. I don't think we'll need the string message-based sentinel approach we broached.

pre-emptive hurray!!!

OK, I just can't replicate this. Datachannel close works fine.
Turns out the undesirable behaviour we're seeing in Simple SOCKS is due to how we are treating our TCP connection. I will close this and work on a fix for:
https://github.com/uProxy/uproxy/issues/1033


[RFC] Can we access current user information in our backend plugins?

Status: Open for comments
Need
I'm looking for a way to get the user profile info or other parts that are provided via IdentityAPI on the frontend. I could not find anything similar in the sourcecode and thus I'm asking here if there is a built-in way to get the user information in backend plugins?
For example, we have a number of backend plugins, and in one of them, we need to get the email of the currently logged-in user. Is this supported or do I need to dig in and provide a solution for this?

Hi!
The frontend typically passes the user's Backstage token (from the identityApi) in the form of Authorization Bearer token headers in backend requests. If your frontend uses fetch from the fetchApi this happens automatically. However, that token does not contain any profile data or similar; you'll have to take the sub (which is a full entity ref string) out of it, and fetch more user details based on that. For example, if your org has reliable ingested org data in the catalog, you can look up the corresponding User entity.

Hi @freben, thanks for your answer. Another question from our side is: We use SSO providers to login. Is there a way to get the users email adress as claim to the Authorization Bearer token?

Hi @freben.
In addition, we have valuable data for our users kind in the database. The issue is that a logged-in user can be someone that is not ingested as a User kind in our catalog. This is something we have currently, maybe it will change.
We use Okta provider, therefore our entity name is actually an email of the user, correct me if I'm wrong? And full entity ref is something like {kind}:{namespace}/{entity-name} so, in the token we should have<EMAIL_ADDRESS>Also, we are talking about the same token provided by the context in our custom scaffolder actions?

@ikuegelgen Sure! Since you are yourselves responsible for issuing the token, you can add custom claims to the Backstage token at will.

@ProticM You are free to design the entity names and catalog structure in any way you see fit. It's both a freedom and a source of potential confusion :) I think you should start with the question, how would you WANT things to be structured and work?
Your ingestion of entities into the catalog can be done in any of a multitude of ways, there's no fixed naming pattern or structure.
Your sign-in resolver can also choose to do anything it wants. It could extract any part of the incoming identity data (from Okta) and fetch auxiliary data in any way that fits your needs.
You COULD take the first part of the email and use that as your naming pattern, if that makes sense to you. You could also put an annotation on your ingested User entities that you use as the "lookup key" instead of going by name, like this example resolver does.
The key is, you want to align what the catalog ingestion does, and what the sign-in resolver does, so that the issued token contains values that line up with actual entities. But they are two separate systems, and are set up and configured separately and freely.

Hi @freben

You are free to design the entity names and catalog structure in any way you see fit. It's both a freedom and a source of potential confusion :)

Yes, this part is clear :)

You COULD take the first part of the email and use that as your naming pattern, if that makes sense to you.

This is exactly how we have it, with a slight problem that I now see that we can solve with the custom sign-in resolver which is something we did not reach in our implementation yet.
Basically, we use Okta provider to sign in our users and we take the first part of it as an entity name for our user. We do not have an annotation, but we do have a custom object with several additional values that are then used in our instance to build some custom UI. These values did not fit as a label or annotation.
To provide some context, the issue that we have is the vast amount of users belonging to different internal entities. A user with the same name and the first part of the Okta email can exist in multiple entities. In other words, we can have something like<EMAIL_ADDRESS>and<EMAIL_ADDRESS>thus we needed to resolve this by creating a namespace based on our legal entity because the user is unique per one.
Also, in situations when we acquire another external entity we might introduce more users with the same name. This cannot be avoided unless after acquiring it every single email is changed, which is something that is not feasible.
On the other hand, the signed-in user always has a default namespace set, which is something we need to align with the users in the catalog because we do not have users in the default namespace due to uniqueness problems. A custom implementation of the sign-in resolvers is something I see as a solution.
Do you have any remarks about this? And also, can a sign-in resolver be async? I predict that some external API is going to be called to fetch the information required.

Ah I see. Let me throw one more suggestion into the mix:
What if your entities' metadata.name was instead the full email, and leave them all in the default namespace?
Namespaces are fine as such, but having to split apart the email and reconstructing it in an entity ref "shape" just to appease Backstage - and then asking users to type out their ownership info etc in a foreign way when emails are perfectly legible and understandable to them as humans ... Maybe it'd be better to just retain the original emails? Would that be a useful option you think?
The default rules for metadata.name don't permit @ signs, but I feel that this use case is so sensible and the need will be so common, that maybe we should be even relaxing the default. Anyway, it's very easy to customize. In your catalog builder in packages/backend/src/plugins/catalog.ts, you can do
import { makeValidator } from '@backstage/catalog-model';
// ...
  builder.setFieldFormatValidators(
    makeValidator({
      isValidEntityName: value => {
        return (
          typeof value === 'string' &&
          value.length >= 1 &&
          value.length <= 63 &&
          /^[\w@+._-]+$/i.test(value)
        );
      },
    }),
  );

Or something like that. Maybe I missed some characters that are valid in emails in there, but it's a start.

Also, yes - the resolver is async.

Thanks @freben
Yes, this is something we discussed before, whether we should leave them in the default namespace and use the full email as the name. And, it is still a valid thing for us that we might end up doing.
The reason why we did not do it, is because we set the namespace for every backstage entity...component, group, resource...etc...The number one reason for it is the uniqueness, and another important reason is that we have an idea of a possible multitenancy approach.
Something like AWS regions...the user logs in and after selecting a namespace somewhere in the header UI for example, the app will filter the entire UI (where possible) and possibly functionalities based on it. The idea behind this is to show the relevant information to the logged-in user if so desired. For example, if I belong to our internal entity 1 I could have difficulties finding the data that is relevant only to me and my entity in the vast amount of data presented in the backstage instance.
But, this is a milestone that is still far in the future...and also, to achieve it, the backstage user entity is not 100% required to be in a separate namespace...we can still have the above mentioned filter without it.
A question about the field validator. Does it know which field to validate? Where we can specify that this validator should validate metadata.name?

A question about the field validator. Does it know which field to validate? Where we can specify that this validator should validate metadata.name?

It's in the structure - isValidEntityName checks that particular field, and there are other siblings to that one in the parameter to makeValidator that check other aspects of an entity's shape.

The reason why we did not do it, is because we set the namespace for every backstage entity...component, group, resource...etc...The number one reason for it is the uniqueness, and another important reason is that we have an idea of a possible multitenancy approach.

Sure, but your namespace structure CAN be different for different kinds if you want. Since the full email is already a perfect uniqueness constraint in and of itself, I thought it might be helpful to keep that one flat.

Thanks @freben Yes, it is helpful for sure. If nothing else, a good confirmation that this is a valid thing to be considered as a metadata name for the users.
Especially the field validator. I was not aware of that possibility.

No. That particular feature is the overall sanity check - org-wide rules for "lowest common denominator" type things. Also, the intent of the metadata block is that it should be the same for all kinds, in theory at least. That being said, you COULD easily make a processor that runs in the post step, just adding some additional check to the name and throwing an exception if it's not fulfilling some additional requirement.

Ok, thanks for the information. Yes, the idea behind the metadata is clear. We have the metadata name check within our custom processor that ingest the users data and does exactly that, it throws an error if the extracted name does not meet the requirements.
But IMHO some particular things might be more useful if they are different per kind, but depending on the common metadata.
For example, all the columns in the catalog table are the same for every kind. We cannot have different catalog table columns per kind unless we replace the entire catalog table and include this functionality, even though the only thing that differs would be the columns.

Hi @freben A quick question about customizing the claims. Let's take an email as an example.
I see that we are limited to setting sub and ent claims only. Now, I still feel that the sub should have the user entity ref as a value, but the ent field seems as not suitable for storing an email. Do you think the same?
Another idea is to place the email as a sub and then the stringified user entity ref would go to the ent list. The thing I do not like with this approach is that if we add more refs in the ent list then when parsing the token somewhere in the app it might be cumbersome to find the current user entity ref (to fetch more data for the current user for example), and introduce parsing mechanisms to extract it.
Any remarks on this question?


WhiteSpaces or special characters in line =   collapsedLines -1

When u will add text like :
text
text
\n
text
text
More link not appear in latestLine because code enumerates by words...
I fixed issue in my locall file and will contribute later.

I assume this is fixed by #12 and #13.


theft: 0.4.3 -> 0.4.4

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/theft/versions.
meta.description for theft is: '"A C library for property-based testing"'.
Compare changes on GitHub

Checks done (click to expand)

built on NixOS

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 0.4.4 with grep in /nix/store/vzbbi9wdy9qrwlshp7b3c0mqxnazrz75-theft-0.4.4

directory tree listing: https://gist.github.com/c0beaba9928ff4c3d17ca287db71a629

du listing: https://gist.github.com/5c4be045b8ff2ff40a48df52c37e7560

Outpath report (click to expand)

Outpath difference report
3 total rebuild paths
1 package rebuilds
1 x86_64-linux rebuilds
1 i686-linux rebuilds
0 x86_64-darwin rebuilds
1 aarch64-linux rebuilds
First ten rebuilds by attrpath
theft

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/vzbbi9wdy9qrwlshp7b3c0mqxnazrz75-theft-0.4.4 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A theft https://github.com/r-ryantm/nixpkgs/archive/07be63132cbe5fd62e91c78f578cca7ac9ed6d83.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/vzbbi9wdy9qrwlshp7b3c0mqxnazrz75-theft-0.4.4
ls -la /nix/store/vzbbi9wdy9qrwlshp7b3c0mqxnazrz75-theft-0.4.4/bin

cc @kquick for testing.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: theft
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: theft
Partial log (click to expand)
install -c inc/theft_types.h /nix/store/58z83ljrkrhrg06v67hxyvawbvakism7-theft-0.4.4/include/
install -d /nix/store/58z83ljrkrhrg06v67hxyvawbvakism7-theft-0.4.4/share/pkgconfig/
install -c build/libtheft.pc /nix/store/58z83ljrkrhrg06v67hxyvawbvakism7-theft-0.4.4/share/pkgconfig/
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/58z83ljrkrhrg06v67hxyvawbvakism7-theft-0.4.4
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/58z83ljrkrhrg06v67hxyvawbvakism7-theft-0.4.4/lib
patching script interpreter paths in /nix/store/58z83ljrkrhrg06v67hxyvawbvakism7-theft-0.4.4
checking for references to /build in /nix/store/58z83ljrkrhrg06v67hxyvawbvakism7-theft-0.4.4...
/nix/store/58z83ljrkrhrg06v67hxyvawbvakism7-theft-0.4.4

Success on x86_64-linux (full log)
Attempted: theft
Partial log (click to expand)
install -c inc/theft_types.h /nix/store/vzbbi9wdy9qrwlshp7b3c0mqxnazrz75-theft-0.4.4/include/
install -d /nix/store/vzbbi9wdy9qrwlshp7b3c0mqxnazrz75-theft-0.4.4/share/pkgconfig/
install -c build/libtheft.pc /nix/store/vzbbi9wdy9qrwlshp7b3c0mqxnazrz75-theft-0.4.4/share/pkgconfig/
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/vzbbi9wdy9qrwlshp7b3c0mqxnazrz75-theft-0.4.4
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/vzbbi9wdy9qrwlshp7b3c0mqxnazrz75-theft-0.4.4/lib
patching script interpreter paths in /nix/store/vzbbi9wdy9qrwlshp7b3c0mqxnazrz75-theft-0.4.4
checking for references to /build in /nix/store/vzbbi9wdy9qrwlshp7b3c0mqxnazrz75-theft-0.4.4...
/nix/store/vzbbi9wdy9qrwlshp7b3c0mqxnazrz75-theft-0.4.4


remove snap mount point

Describe the bug
I was trying out removing snap feature. Seems to remove snap and snapd from running that was nice and quick, but it still shows up on /snap/* after running df.
To Reproduce
Steps to reproduce the behavior:

Run linutil
Select remove snaps
It seems to work
run df and see snaps show up on right side path row

Expected behavior
Snaps should not take extra space on system after tool is run.
Screenshots
After running df -h:
Filesystem      Size  Used Avail Use% Mounted on
...
/dev/loop0      1.9M  1.9M     0 100% /snap/btop/806
/dev/loop1      1.9M  1.9M     0 100% /snap/btop/808
/dev/loop3       64M   64M     0 100% /snap/core20/2379
/dev/loop2       15M   15M     0 100% /snap/cheat/4279
/dev/loop4       64M   64M     0 100% /snap/core20/2434
/dev/loop5       15M   15M     0 100% /snap/cheat/4243
/dev/loop7       39M   39M     0 100% /snap/snapd/21759
/dev/loop6       67M   67M     0 100% /snap/core24/609
/dev/loop8       67M   67M     0 100% /snap/core24/490
/dev/loop9       39M   39M     0 100% /snap/snapd/21465
...

If applicable, add screenshots to help explain your problem.
Additional context
Running Lubuntu 20.04 (like Ubuntu 20.04)
Checklist

[x] I checked for duplicate issues.
[x] I checked already existing discussions.
[x] This issue is not included in the roadmap.
[x] This issue is present on both stable and development branches.

/close not-planned
if the packages were successfully removed but there are still mountpoints then try rebooting, snap is no longer on your system.

Earlier I did not bother checking if snaps were in my system, but yeah after looking into this, the issue hasn't gone away.
Removing mountpoints and /snap:
sudo umount /snap/*/*
sudo rm /snap/* -r

After typing commands above and rebooting, the snap mount points come back, and the packages from snap still run.
Here's some systemd info if that helps:

Also to double check, I ran linutil again using the snap remover option. It still shows "snapd is not in your system" and doesn't change anything since changes were already made.

Someone deleted their comment after I made above reply :eyes: Anyway, I don't know how to reopen this issue


Suggested changes to docs homepage tone

These are organized by commit, so consider reviewing each commit separately (and possibly asking me to drop an entire commit, if it is completely off the mark).  Also the commits probably get more controversial in order of appearance. :-)

THANKS!