Problem adding geoJson a second time

I am using PruneCluster with Leaflet and I have custom logic happening to attempt to add and remove polygons when clusters are created. It mostly works, but I have an issue when I leave the page, and come back. I need all the markers that were put on the map previously, to be added again. This seems to work fine for markers without a geoJson layer, but when I try to add back a geoJson layer I get Uncaught TypeError: Cannot read property 'min' of undefined which is being triggered by this in Leaflet:
    _getBitCode: function (/*Point*/ p, bounds) {
        var code = 0;

        if (p.x < bounds.min.x) { // left
            code |= 1;
        } else if (p.x > bounds.max.x) { // right
            code |= 2;
        }
        if (p.y < bounds.min.y) { // bottom
            code |= 4;
        } else if (p.y > bounds.max.y) { // top
            code |= 8;
        }

        return code;
    },

My custom code to add shapes, when the marker is not clustered looks like this:
    pruneCluster.PrepareLeafletMarker = function (leafletMarker, data) {
      if (data.isShape) {
        map.addLayer(data.geoJsonLayer);
      }
      leafletMarker.on('click', function (e) {
        GenerateRrosePopup(e, data.popupContent);
        if(data.isShape) {
          map.fitBounds(data.boundsForFit);
        }
      });
      leafletMarker.setIcon(data.icon);
    };

map.addLayer(data.geoJsonLayer) is what causes the issue. I'm not sure why though because my geoJson object looks as I expect it to.
Why would this same code work for initially adding the geoJson layer, but then fail when I come back to the page and try to add the points and shapes I previously added?

I have the same issue.
After re-adding geoJSON layer to a map and calling fitBounds, i get:
Cannot read property 'min' of undefined
Might this be related?

Alright we're using the beta version now to have this resolved.
Kinda scary to use it in a huge production app.

I just hit a similar problem when updating to 1.0beta2 and it took quite a bit to figure out plugin compatibility as the root source. It would be very appreciated to catch the error and give advice on the possible cause when introducing backward incompatibility points. It will save developers quite a bit of debugging time.

I'm getting this problem while using the version 1.03. I'm trying to print a map using the browser print, working with an empty map. When I add my layers, it doesn't work anymore and I get the "Uncaught TypeError: Cannot read property 'call' of undefined" error.

I tried to disable canvas and messagebox but no success

@pedrovsra if you believe this is a bug, I suggest you open a new issue. Also, please first make sure the plugins you use are compatible with 1.0, as you can see from comments above, old plugins could be the source of this issue.
It would be great if you could provide a running example of the problem, for example using http://playground-leaflet.rhcloud.com/?html,output - this makes it a lot easier to find, understand and debug the problem.
With the information we have from your report now, it's more or less impossible for us to tell if this is a bug or not.


Using the same attachment as a color & input attachment for a subpass triggers questionable warnings

Consider an app which uses a renderpass attachment X both as a color & an input attachment in the same subpass. This triggers the following warnings:

However:

The attachment cannot be in COLOR_ATTACHMENT_OPTIMAL layout because that's illegal as per spec.
The attachment cannot be in READ_ONLY_OPTIMAL layout because of the same reason.
The attachment cannot be in two layouts at once :)

Yep, that's pretty awful. To do this properly we need to combine all the constraints on the layout, rather than making a fuss about each constraint individually.


vmq_swc: Use separate DB for DKM store

This PR singles out the DKM store to separate it from storing Objects.
This, again, is an experiment to speed up node sync. It is not compatible with existing on-disk metadata stores.
To reset a node data/swc_meta and data/swc_dkm have to be deleted now.

Been testing this a bit now. Looked very promising after replacing one pod at a time twice, without ending in empty sync, but after a rolling restart the graphs now look like this:

Went into the pods to confirm that they all started with empty data folders.

Did an initial build of the latest commit here, and did a rollout restart after deploying on a cluster that was already in empty sync, and it seems to have cleared it, so very promising! Will do some more testing under load tho.

@marcusramberg Thanks again for testing.
This is not yet in a final state. I want to add an initial fast sync, and do some procedural testing under lab conditions. For instance, doing a re-join, let the node sync up, and then do 1 additional simple stop/start of that leaving/joining node before rolling any others allows me a full rolling restart with my current version.

@marcusramberg feel free to test the latest commit.
It's an idea (POC) that should fix:

all empty sync
issues with rolling re-joins
issues with increased CPU/RAM after joins

Todo:

[ ] Adapt tests
[ ] Test against various load scenarios
[ ] Test Retain store
[ ] Maybe add fast initial sync

Rebuilt this branch and did some testing. Seems I'm getting a lot of crashes after a rolling restart, along with empty sync. Here's a sample from the pod logs:
https://gist.github.com/marcusramberg/91f0c3cc9d3c89c0ccb9b41a38ad87f8

@marcusramberg Thanks a lot for testing. Something somehow is still different in our setups :grimacing:
I don't fully understand your test scenario, but I'll setup something that does a ramp-up with constant connect/disconnects. I think that's what you do.
I also suppose I should start test this on Kubernetes then.

A rollout restart statefulset weirdly shows inconsistent behaviour. I see some nodes leave the cluster, some nodes not.
Deleting the pods one by one manually, consistently makes the nodes leave and re-join the cluster.


Unique validation

I have a minor problem with unique validation.
I'm using a quickForm.
Clicking submit validates all input and the unique validation gets run,
stops submit but when the error message is presented the form resets
and the message displays '[label] is required' instead of notUnique
message because all inputs are empty

Any news about this issue ?

Nah, I've got a reprod for it but I haven't had the time or need to look into this more... it has something to do with latency compensation if I remember correctly.
Hopefully I will come up with a smart solution for this some day, in the meantime I hope someone else will come up with instead :smile:

I think the quick solution is to create a custom validation, and look for yourself a duplication :)


Travis import error: no module named settings

Problem
Travis started showing errors ImportError: No module named 'settings'
Solution
Use same export as when running tests script
Acceptance Criteria
All good after applying this

Coverage increased (+0.1%) to 95.794% when pulling 36ddb6d00c81d1faa1cbea9877ee4d26f8cfbf48 on fix-travis into aa9284fac637b461bb9657270ef2df6f17ca1800 on master.

Thanks for the review @andrewgy8, merging this so people can rebase PRs.


stack-pointer:0.1.0

I am submitting

[x] a new package
[ ] an update for a package

Stack Pointer is a library for visualizing the execution of (imperative) computer programs, particularly in terms of effects on the call stack: stack frames and local variables therein. Its main purpose is to be used in animations using presentation frameworks such as Polylux.

I have read and followed the submission guidelines and, in particular, I

[x] selected a name that isn't the most obvious or canonical name for what the package does
[x] added a typst.toml file with all required keys
[x] added a README.md with documentation for my package
[x] have chosen a license and added a LICENSE file or linked one in my README.md
[x] tested my package locally on my system and it worked
[x] excluded PDFs or README images, if any, but not the LICENSE

Thanks!


Theme Switcher can't add Class in Modal's

@lazynina  Here still an issue with this
https://github.com/JustifydWarrior/frontend/commit/32490d36c9d1327fd2f7ef8edbfb6b3188f1bce9#diff-a945c662b9f44ad5647af5e40a6738b08b16e7a9c2b5274c213a3a681a39e09f
It won't add class in modal's Please look at this.

I believe this is fixed


connection error reported without connection error

Hi, the node works quite well, but shows most of the time a red light and the message connection error. -so it is quite difficult to see when there ae really problems.
I'm running node-red 2.1.3 from docker and oracle-mod node 0.6.1.

What do you see in the Node-RED console (or logs) when you get the error?

It took a while until the status changed to red. There is no information. Neither on the debug panel nor on the console. All works well, data is stored to DB, but the node has status red and text "connection error".

If you are doing an insert, set the module to "Ignore Query Results" (because there is no result for inserts).

Hmmm ... first thing is, that I do a select, so need to get results. Second thing is, that I get a connection error in the status area of the node, so I don't understand how this is connected to result sets.


File watch overhaul

This is a large pull request that is the culmination of a number of month's work trying to improve the overall io and watch performance of sbt. For the most part, I've broken the commits up so that each one more or less stands on its own. I am doing it as one large pull request just because the overhead of making 20 partially dependent commits feels to high.
This commit uses apis that I developed in the swoval file-tree-views library that improve the performance of traversing the file system tree and also provide a dynamically updating in-memory cache of the file system.
As I describe in the file-tree-views readme, it is surprisingly expensive to descend the file system tree because all of the built in jvm apis require a stat of each file to determine if its a directory or a regular file. In the swoval library, I provide jni native libraries that take advantage of extra information in the system call for listing directories to traverse the tree without stat-ing any of the files. This can reduce the run time of traversal of a directory by 3-5x. It was straightforward to update the PathFinder implementations to use the swoval implementations. Because there is some risk that there is a bad bug in the library, I still allow users to fallback to the built-in java implementations via a system property (I have never seen any unexpected behavior, but I can't rule it out in every environment).
Secondly, I add support to cache a portion of the file system. The motivation is so that we can reduce the latency between the beginning of the compile task to when we actually start compilation. Zinc needs to compare file hashes so right now, sbt has to list all the files and compute the hash. The hash is fast, but the entire process is highly io bound. I seem to get roughly 10K iops on my mac with an ssd so it is perhaps unsurprising that before starting compilation I see sbt doing about 700ms of io before compilation starts in a project with 5000 files. By instead using an in-memory cache of the file system that precomputes the hashes, I've seen that 700ms drop drop to about 100-150. As a bonus, since we are already monitoring the file system to maintain the cache, we can re-use the cache in continuous builds by adding a listener to the cache's observable.
Finally, I make some improvements to the watch api for sbt. I refactor the EventMonitor so that it returns more information to sbt. I use this to make continuous builds testable by allowing the user to provide arbitrary termination conditions which do not depend on reading from System.in. In addition, I am able to implement automatic project reloading when the meta build files change. This is a feature that mill advertises as an improvement over sbt: http://www.lihaoyi.com/post/MillBetterScalaBuilds.html.
I have worked as hard as I could to try and preserve all existing behavior for users. In a number of places, I provide multiple implementations that are user configurable via a system property or sbt setting. In an ideal world, the majority of sbt users notice nothing after the change except that sbt feels snappier than before.
There also was an issue that watching a nested symlinked directory did not work on osx. This was because osx file watchers are all recursive, so I'd added logic to the swoval file events api that pruned any watches for any watches of a descendant of a watched directory. When there are no symlinks, this works great and lowers the resource cost of the watch, but in the presence of a symlinked directory descendant, we'd lose the updates. I fixed this upstream in swoval and I even enhanced it so that updates of symlinked files are detected by the watch service. This enhancement is only available using the swoval file repository and will not be available using the WatchServiceBackedObservable implementation of the FileEventMonitor.

To validate this pull request against other sbt modules, please visit this link.

@eed3si9n Thanks for looking over the PR. I know that it's a lot.

I should've run Dbuild before merging.
[sbt212] [error] /home/jenkinssbt/workspace/sbt-validator/target-0.9.14/project-builds/sbt212-0dcf5fdc6c1887745e8427a0496959076954d686/main/src/main/scala/sbt/TemplateCommandUtil.scala:66:12: reference to Logger is ambiguous;
[sbt212] [error] it is imported twice in the same scope by
[sbt212] [error] import sbt.util._
[sbt212] [error] and import sbt.io._
[sbt212] [error]       log: Logger
[sbt212] [error]            ^
[sbt212] [error] /home/jenkinssbt/workspace/sbt-validator/target-0.9.14/project-builds/sbt212-0dcf5fdc6c1887745e8427a0496959076954d686/main/src/main/scala/sbt/TemplateCommandUtil.scala:106:12: reference to Logger is ambiguous;
[sbt212] [error] it is imported twice in the same scope by
[sbt212] [error] import sbt.util._
[sbt212] [error] and import sbt.io._
[sbt212] [error]       log: Logger
[sbt212] [error]            ^
[sbt212] [error] /home/jenkinssbt/workspace/sbt-validator/target-0.9.14/project-builds/sbt212-0dcf5fdc6c1887745e8427a0496959076954d686/main/src/main/scala/sbt/TemplateCommandUtil.scala:134:12: reference to Logger is ambiguous;
[sbt212] [error] it is imported twice in the same scope by
[sbt212] [error] import sbt.util._
[sbt212] [error] and import sbt.io._
[sbt212] [error]       log: Logger
[sbt212] [error]            ^
[sbt212] [info] No documentation generated with unsuccessful compiler run
[sbt212] [error] three errors found
[sbt212] [error] (mainProj / Compile / compileIncremental) Compilation failed
[sbt212] [error] (mainProj / Compile / doc) Scaladoc generation failed


Project viewports on 1D tracks

Viewport projections currently only work on 2D tracks. Extend them to work on 1D tracks as well.

This has been fixed for a while.


Random Beacon: "The Mechanism" README section updates

Closes #2931
The section has been updated to reflect the most recent changes in smart contracts.

Alright @michalinacienciala, all comments addressed, this is ready for another chance!


https://keda.sh/docs/deploy/ link is broken

It was used in the https://github.com/kedacore/keda#deploying-keda to point users to the deployment option. This bug was brought be introducing versioned docs.
https://keda.sh/docs/deploy/ could link to the latests docs

A redirect for this would be ideal actually!

@tomkerkhove You shouldn't need a redirect for this. Just change the URL to https://keda.sh/docs/latest/deploy.

That's good to hear; thanks!

Fixed!


Fixing a typo... pendantic -> pedantic

Thanks for the great documentation!

right, thanks the for contribution!


feat(frontend): support InSubquery.

What's changed and what's your intention?
PLEASE DO NOT LEAVE THIS EMPTY !!!
Please explain IN DETAIL what the changes are in this PR and why they are needed:

Summarize your change (mandatory)
In this pr, I supported (NOT) InSubquery for WHERE clause and add on for LogicalApply.
I bind InSubquery as normal InList and plan it as Left-Semi-Apply using equal condition as its predicate.

Describe any limitations of the current code (optional)
Please note that InSubquery that goes into others cannot be handled by substitute_subqueries yet.

Checklist

[x] I have written necessary docs and comments
[x] I have added necessary unit tests and integration tests

Refer to a related PR or issue link (optional)
close #2027

LGTM!
Just a small note for future considerations:

NOT (a NOT IN subquery) may cause a problem ...
It may be simpler to use same logic of negated as NOT EXISTS.

NOT EXISTS will be parsed to NOT + EXISTS. They are not an entity.


Test community pull request moderation

Just trying to see if I can get moderation action to fire and yell at me for writing to autogenned files

well, that was disappointing


BatchNormalization error with tensorflow backend

hello, everyone!
I have some problems regarding tensorflow backend and BatchNormalization layer
part of my code is:
seq.add(LSTM(256,
input_shape=(length, dim),
activation='tanh',
return_sequences=True))
seq.add(BatchNormalization(
mode=0,
axis=1))
After I update keras to 1.2.1 and tensorflow to 1.0.0rc2 then  I have the following error.
File "D:\SciSoft\Anaconda3\envs\tensorflow\lib\site-packages\tensorflow\python\framework\constant_op.py", line 165, in cons
tant
tensor_util.make_tensor_proto(value, dtype=dtype, shape=shape, verify_shape=verify_shape))
File "D:\SciSoft\Anaconda3\envs\tensorflow\lib\site-packages\tensorflow\python\framework\tensor_util.py", line 441, in make
_tensor_proto
tensor_proto.string_val.extend([compat.as_bytes(x) for x in proto_values])
File "D:\SciSoft\Anaconda3\envs\tensorflow\lib\site-packages\tensorflow\python\framework\tensor_util.py", line 441, in
tensor_proto.string_val.extend([compat.as_bytes(x) for x in proto_values])
File "D:\SciSoft\Anaconda3\envs\tensorflow\lib\site-packages\tensorflow\python\util\compat.py", line 65, in as_bytes
(bytes_or_text,))
TypeError: Expected binary or unicode string, got 1
The code runs ok with theano backend.
Also if set axis=0 or 2, The code is ok. But I need featurewise normalization.
Anything wrong here?

nobody encountered the same problem with tensorflow backend?


Guidance on calling Electon APIs from Blazor server code

Maybe I'm just doing something wrong (which would not be the first time), but I just want to make sure.
So I have a Blazor Server app running in Electron.NET.  All Blazor stuff is fine, as are all standard javascript calls.
If I wire up calls to the Electron.NET API behind the scenes (say setting up the electron menus in my Program.cs), this all works fine.
However, when I try to call Electon APIs via a Blazor button on the server, my app not only DOESN'T do the expected Electron action, but it ends up freezing my app.
My call is pretty simple, but maybe this is just not possible / there's something else I must do to make this work
public async Task SomeButtonHandler() {
     var somePath = "/some/path/on/the/workstation";
     await Electron.Shell.ShowItemInFolderAsync(somePath);
}

Should this work just fine?  Is there something else I need to do / some other way I need to wire this up in a Blazor Server app?  Just trying to get some confirmation.
App Details
Blazor app type:  Blazor server
Electon.NET Version: latest
.NET Version: 6.0x

Worked it out.  So while the code I showed above was async, when the button handler was generated, it was a void and the actual call was
Electron.Shell.ShowItemInFolderAsync(somePath).Wait();

This, apparently, is a big ol' no-no.  Does not work.   Wait() and .Result got me the same pain and suffering.  Only allowing the Electron async methods to run naturally appears to work consistently.
Live and learn.

Worked it out, in case anyone else bumps up against this kind of thing.
My button method was a void, and my call to Electron used a .Wait().    They do NOT work.  You have to ensure the Electron Shell calls are full on await async calls or they don't work.


rg-timepicker

Let's add a time picker (with hours, minutes and optional seconds). :smile:

You got it!

It's a little bit different from a date-picker !

Yeah no worries. Just on holiday at the moment. But I'll tackle this when I get back ;-)

Enjoy ! :smiley:

What do you reckon?
https://riotgear.js.org/components/timepicker/
Doesn't handle seconds. Didn't think it needed them for the MVP...


Provide more guidance about creating SSL certs

I added a link to the form
I added a screen shot of a filled out form
I added an overview of the steps at the top of the document
I separated the instructions into high level steps to make them easier to follow

There was a link to the form, but this certain makes it more obvious.  Thanks @bess


Custom package filtering to simple search

What is the problem that needs solving?
Toggle in simple search to include/exclude custom package nodes. This is really useful when you have a lot of packages installed and are just looking for an OOTB node - can be difficult when the noise of packages is included.
How would you like to see it solved?
Tick box 'include custom packages', or alternatively 'exclude custom packages'
Describe alternatives you've considered
Scrolling through, or having to be more specific with keyword searching.

This has been addressed in, https://github.com/johnpierson/MonocleForDynamo/releases/tag/2020.07.14


Any chance for a AnythingEverywhere3 similar to powerlora?

Was wondering if theres any change you'd consider adding an anythingeverywhere3 but instead of 3 it could have unlimited links like how rgthree's power lora allows you basically just click ADD and you get a new input, theres many work flows that 3 works great but then theres some that i've got 4-5 in 1 area i'd love to be able to shove in but need to use 2 3's or a 3 and 2 1's ... feel like having a version thats flexible for any number would really clean the node options up want 2 inputs sure.. want 5.. done all on 1 node.

I did start looking at this, but the changes to the ComfyUI front end have thrown up issues that slowed it down. Hopefully!

I usually make group nodes for whichever amounts I need that work fine.

ue_group_node_example.json
However it does throw type mismatch errors that never caused any issues for me though.
The only issue I ever had when experimenting with that was including the ue-nodes into a group node which provides the signal and sends at the same time. That did cause it to no longer work upon restarting Comfy.

got prompt
Failed to validate prompt for output 37:3:

(prompt):

Return type mismatch between linked nodes: anything, LATENT != *

Anything Everywhere? 37:3:

Return type mismatch between linked nodes: anything, LATENT != *
Output will be ignored
Failed to validate prompt for output 37:0:

(prompt):

Return type mismatch between linked nodes: anything, MODEL != *

Anything Everywhere? 37:0:

Return type mismatch between linked nodes: anything, MODEL != *
Output will be ignored
Failed to validate prompt for output 37:1:

(prompt):

Return type mismatch between linked nodes: anything, CLIP != *

Anything Everywhere? 37:1:

Return type mismatch between linked nodes: anything, CLIP != *
Output will be ignored
Failed to validate prompt for output 37:2:

(prompt):

Return type mismatch between linked nodes: anything, VAE != *

Anything Everywhere? 37:2:

Return type mismatch between linked nodes: anything, VAE != *
Output will be ignored
model weight dtype torch.float16, manual cast: None
model_type EPS
Using xformers attention in VAE
Using xformers attention in VAE
Requested to load SDXLClipModel
Loading 1 new model
loaded completely 0.0 1560.802734375 True
Requested to load SDXL
Loading 1 new model
loaded completely 0.0 4897.0483474731445 True
100%|█████████████████████████████████████████████████████| 20/20 [00:04<00:00,  4.04it/s]
Requested to load AutoencoderKL
Loading 1 new model
loaded completely 0.0<PHONE_NUMBER>2253418 True
Prompt executed in 11.08 seconds

Aside from that the only downside I found is that priority settings are lost on grouping unfortunately.

I'm not going to address issues related to group nodes. The underlying comfy implementation is very complicated to work with, and I suspect it is going to be re-written - but even if not, it's just not worth the work.

Yeah, absolutely. Group nodes are not very convenient to work with as of now and could do with some love. Especially rebuilding larger groups over and over for small changes, sorting everything, labeling, on/off-ing the in- and outputs...
I would say that there is no real issue for ue-nodes there anyway. It just looks it when those type mismatch errors pop up, but they do not affect anything. It works nicely as is. 👌
Was more meant to be an answer to op's described case


Generated initializer should use FormBuilder instead of SemanticFormBuilder?

I removed the comment from this line in the generated config/initializers/formtastic.rb file:
# Formtastic::SemanticFormBuilder.default_text_area_height = 5

Restarted the server and this had no effect. Wandering around the source code I found the deprecation warning in SemanticFormBuilder stating that FormBuilder should be used. I amended the above line as so:
Formtastic::FormBuilder.default_text_area_height = 5

Which now works. Is this correct? Does the generated initializer simply need updating?
Using Formtastic 2.0.2.
Thanks,
Andrew

This is interesting that the deprecated version doesn't work (I'll leave this open long enough to have a play around), but in 2.0 we supplied a new template for the generator with the correct class names, so all you really need to is re-generate the initializer and review the changes.

Note the generator template has the correct class names: https://github.com/justinfrench/formtastic/blob/master/lib/generators/templates/formtastic.rb

Thanks! I should have checked the latest version of the template.

I've made a separate issue #720, closing.


Update 2018-06-25

@opentecture/the-brains
Story
load stl nasa

STL files from NASA on GitHub

Three.js Basic Template

Very elementary file just to get something simple started
Useful for developer-facing cookbook/sandbox code samples
Loads Three.js renderer, scene, camera and controls
Adds axes helper and cube
Handles screen being resized
Sets up requestanimationframe
Verified by

https://validator.w3.org/#validate_by_input
http://jshint.com/
https://zz85.github.io/mrdoobapproves/

Features.md

Add text

cool stuff from NASA!
I incorporated the .stl loading from GitHub feature into https://opentecture.github.io/mindmapping/build/index.html. The axes helper, cube, resizing, and animation are also included in the build now.
Thanks for these code style links. I will add them to the general README for reference.


Update main.yaml

avoid Errors on new AWS Ubuntu AMIs, need to update_cache like sudo apt update before trying to install Nginx, if not it won't the find its package in apt,.... Thanks btw

@Ayoub-HEDFI thanks for the PR, but

"Become: yes" is already set on the playbook here - https://github.com/antonputra/tutorials/blob/603202344f0a1c1bb07cad3f1fb370db9311dbbd/lessons/014/nginx.yaml#L5
Also I would prefer to include "update_cache: yes" on the existing task  rather then create a new one - https://github.com/antonputra/tutorials/blob/603202344f0a1c1bb07cad3f1fb370db9311dbbd/lessons/014/roles/nginx/tasks/main.yaml#L8


Added IHImageViewEffects under Animation

Project URL

Category

Description

Why it should be included to awesome-ios (mandatory)
Checklist

[x] Only one project/change is in this pull request
[ ] Has unit tests, integration tests or UI tests
[ ] Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[ ] Supports Swift 4 or later
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Warning

:warning:
Found 7 link issues, a project collaborator will take care of these, thanks :)

Link issues by awesome_bot

Line
Status
Link

206
403
https://www.udemy.com/arkit-beginner-to-professional/?couponCode=CREATORS

1497
301
https://github.com/mobilefirstinc/MFCard redirects tohttps://github.com/RC7770/MFCard

1516
301
https://github.com/IvanVorobei/RequestPermission redirects tohttps://github.com/IvanVorobei/SPPermission

1915
404
https://github.com/Cleveroad/CRParticleEffect

1959
404
https://github.com/Cleveroad/CRRulerControl

1967
404
https://github.com/Cleveroad/CRPageViewController

2274
404
https://github.com/Cleveroad/CRNetworkButton

  Generated by :no_entry_sign: Danger

Hello @Ibrahimhass, thanks for contributing! Unfortunately I cannot merge your PR since IHImageViewEffects has too few functionalities. Feel free to open a PR once the project is more production-ready


New: module iam-instance-profile

Fixes #48.
The module was tested in EIP project, although that did not work through. In the generated instance, I could run aws to attach EBS, and associate EIP, which proved that the permissions were given correctly. And outside EIP project, running the single-node-asg gave instance without associate-address permission, which proved that no wrong permission was given.

[ ] Update the changelog
[ ] Make sure that modules and files are documented. This can be done inside the module and files.
[ ] Make sure that new modules directories contain a basic README.md file.
[ ] Make sure that the module is added to tests/main.tf
[ ] Make sure that the linting passes on CI.
[ ] Make sure that there is an up to date example for your code:
- For new modules this would entail example code for how to use the module or some explanation in the module readme.
- For new examples please provide a README explaining how to run the example. It's also ideal to provide a basic makefile to use the example as well.
[ ] Make sure that there is a manual CI trigger that can test the deployment.

I have WIP updates to this PR. I will push those ASAP.


fix: comparator contained_by should assert the type of expect_vaule.

The comparator contained_by assert type on wrong variable expect_value.

@rihkddd Thanks.

@rihkddd Thanks.


Falcon 2096. Feed instance listing doesn't give instance status of all the clusters

This pull request is above https://github.com/apache/falcon/pull/239
Don't merge this before the above one gets merged.


Replicate orbitdb in another browser

Hi,
I am trying to replicate my orbitdb in another browser using the below address
const db= await orbitdb.docs('orbitdb/zdpuAnBgAoZ3CUNkicsdqzCtz6nubD3ubRG1feU72oKhMqoxz/Tom jane@gmail.com');
If I try to open this address in a new tab in the same browser,then it can be accessible. But in another browser,it is not accessible. Please help me to resolve this. Am getting an orbit db ‘id’ as below, when am using the above address in another browser.
id: "/orbitdb/zdpuB37ifQdj2RVmBqyxpauYJDU2xUvDKUZpuMgeSYham6jps/orbitdb/zdpuAnBgAoZ3CUNkicsdqzCtz6nubD3ubRG1feU72oKhMqoxz/Tom<EMAIL_ADDRESS>App.js
ipfs = new IPFSS({
start: true,
EXPERIMENTAL: {
pubsub: true
},
preload: {
enabled: false
},
config: {
Addresses: {
Swarm: [
'/dns4/ws-star.discovery.libp2p.io/tcp/443/wss/p2p-websocket-star'
]
}
}
})

ipfs.on('ready', async () => {
const identity = await Identities.createIdentity({ id: 'local-id' })

// Create OrbitDB instance

const orbitdb = await OrbitDB.createInstance(ipfs, { identity: identity })

const defaultOptions = { accessController: { write: [orbitdb.identity.id] }}

const docStoreOptions = {
defaultOptions,
indexBy: 'wallet',
}

const db = await orbitdb.docs(orbitdbname,docStoreOptions);
await db.load();
})

Environment
Npm: 6.13.4
Node: 10.19.1
libp2p : 0.26.2
libp2p-webrtc-star: 0.13.2
libp2p-websockets: 0.12.2

Peer discovery via the webrtc star server might take a long time. Can you try explicitly connecting to the peer via ipfs.swarm.connect just to see if that works? And then we can troubleshoot from there.

Can you tell how to do that? I am new to orbitdb. Currently am using websocket server for peer discovery.

Sure, in Browser A you can run const id = await ipfs.id() and see its swarm addresses inside id. OrbitDB exposes this via await orbitdb._ipfs.id()
Then in Browser B you can run await orbitdb._ipfs.swarm.conect(addr) where addr is one of the addresses from ipfs.id

@aphelionz I am also new to OrbitDb and I am struggling against making replicate work between browsers....  I tried const id = await ipfs.id() but the address array appears to be empty. BTW, The project I am building is based on browserify.
However, I got addresses from another temp demo node.js app which just load ipfs and orbitdb packages and print the id.
The only difference I can tell is that the ipfs version in browserify project is 0.50.1 and the demo project is 0.46.0. so I changed the browserify project to 0.46.0, the addresses array still shows empty. So my question is, can I use orbitdb in a browserify project and how?

Tried to connect using ipfs.connect.swarm but nothing changed.
In browse A, I have tried the below code:
const info=await ipfs.id()
console.log("IPFS node ready with id:"+info.id);

And in browser B, tried the below code:
await ipfs.swarm.connect('/dns4/wrtc-star2.sjc.dwebops.pub/tcp/443/wss/p2p-webrtc-star/ipfs/QmVcoer53vBab2mkzgf2F71U8Xn5SEEKFd5hrqqazvr7oN')

const identity = await Identities.createIdentity({ id: 'local-id' })

const orbitdb = await OrbitDB.createInstance(ipfs, { identity: identity })

const defaultOptions = { accessController: { write: [orbitdb.identity.id] }}

const docStoreOptions = {
defaultOptions,
indexBy: 'msg',
}

const store = await orbitdb.docs('orbitdb/zdpuAomVC6YbN11jjtkZHqrLxLHbsQd5LS5v7woJU8weZhbcG/Tom jane@gmail.com',docStoreOptions);
store.load();
console.log(store);

Also I am getting the error  ‘Error: Non-base58 character’ when I am using signal servar as below:
Swarm: [
'/dns4/wrtc-star2.sjc.dwebops.pub/tcp/443/wss/p2p-webrtc-star'
]

I have the same question.
There is browser 1 and 2
How can I start data replication and wait for the database to be up to data ?
My app
https://zababurinsv.github.io/markdown/#

@zababurinsv the best way for browsers currently is to add the test webrtc servers to the ipfs config
here is an example](https://github.com/orbitdb/example-orbitdb-todomvc/blob/f0817a8e65a6eac719563bf60325988c23884daa/src/store.js#L7-L24)
once that is there you can test connectivity by trying to have the nodes ipfs.ping each other. If that is successful they should be able to pubsub peer and replicate the db.
dont use the webrtc test servers in production, they should be self-hosted

Hi. I created webrtc servers.
I wanted to know. How to disable localhost checking in my code?
when connection is established localhost check starts. But in the browser version I have no node.
index.js:2 WebSocket connection to 'ws://<IP_ADDRESS>:43361/p2p/12D3KooWC9JVGTBgSaQE6pXNehjrYLgHqRJkm4XwCx98ZUSGuKrV' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED

You can see this in page https://zababurinsv.github.io/markdown/#

@zababurinsv this is most likely the result of remote machines advertising peers on their local network

@zababurinsv this error is most likely the result of remote machines advertising peers on their local network.

I wanted to know. How to disable localhost checking in my code?
when connection is established localhost check starts. But in the browser version I have no node.

I am not sure exactly what you mean by this

How can I catch this error?
I can't check the project because of her

How can I catch this error?

I'm not sure how to catch it but it's not breaking anything.

How can I catch this error?

I'm not sure how to catch it but it's not breaking anything.

I can't use pause on exception

And one more question how can i replication database ?
in API i see event for replication
Store Events

replicated
replicate

But i can't see methods for replication

I can't use pause on exception. I can't debug my code.

These errors are not a result of your code and do not affect anything. They are the result of remote peers you connect to advertising peers you are unable to connect to.

And one more question how can i replication database ?

Replication is done automatically. It will happen when you connect to a new peer over pubsub and when you make an update.
feel free to join the community chat anytime you have more questions

This issue is probably outdated now that version 1.0 has been released. For browser to browser connections, I would recommend looking at the OrbitDB unit tests and Libp2p browser-to-browser documentation. Closing.


docs: wording suggestions for the README.md file

Description
Whilst reading through the documentation, i noted some possible improvements to the wording for clarity. Hope that helps.

@iancooper oh man, you can't imagine how grateful I am for this PR 🙏🏼 and I bet others that had to read it too. I'm trying my best with Grammarly though 😅


Add --build-plan for 'cargo build'

With 'cargo build --build-plan', cargo does not actually run any
commands, but instead prints out what it would have done in the form of
a JSON data structure.
Fixes #3815

cc @aidanhs

Awesome @mshal! I really like how this looks now!
I think we need to be really careful not to expose internal implementation details of Cargo, and this approach achieves this almost perfectly.  However, the following things leak some information:

buildkey stores textual representation of various internal structures. It is intended to be used as opaque key, so this doesn't strictly matter, but perhaps there's a simple way to get more opaque id. For example, we could assign numerical ids to units, by lazily populating a HashMap<Unit, usize> map.

we expose target directory structure via various command-line options. I think this OK probably, as long as we document that precise outputs location are subject to change. I expect that, if a build systems wants to use a different directory structure, it can reliably post-process the build plan and substitute target dir with something else. Perhaps it makes sense to add a targer_dir field to build-plan itself, to make it easier to distinguish invariant source paths from potentially changeable target paths?

we expose links key. Is this really necessary? I think that we use it cargo mainly for user's convenience, and otherwise everything else works with unliked outputs from deps (not sure about this though, let's ask @alexcrichton).

Regarding the implementation itself, it looks great! We use slightly different code style in Cargo though, so you might want to rustup +stable component add rustfmt-preview and run rustfmt +stavle --skip-children $FILE for changed files.
It would also be great to have some tests for this as well! I think we should create a tests/testsuite/build_plan.rs file and add a couple of smoke test. Here's an example of a test for JSON output: https://github.com/rust-lang/cargo/blob/b0d65af158bc2f2e4c1bc4e143a7dcd4b40af0f5/tests/testsuite/build.rs#L4024. Note how [..] and {..} are used as wildcards to match arbitrary strings/objects to get around platform specific variations.

:umbrella: The latest upstream changes (presumably #5348) made this pull request unmergeable. Please resolve the merge conflicts.

Sorry, I'm afraid my refactoring in #5348 has bitrotted this quite a bit. :(
What would be a nice side goal for this (though I hope that doesn't complicate it too much) is if cargo itself is refactored such that it goes through (a) generating the build plan, and then (b) executing from the build plan. That would make it more robust in the sense that we know the cargo build itself is not inadvertently relying on anything but the build plan.
That's not in this PR, as far as I can see, right?

buildkey stores textual representation of various internal structures. It is intended to be used as opaque key, so this doesn't strictly matter, but perhaps there's a simple way to get more opaque id. For example, we could assign numerical ids to units, by lazily populating a HashMap<Unit, usize> map.

I was trying to make the buildkey to be something human-readable, so for example you would be able to see that a "app_units v0.6.0 Target(lib) Profile(build) Target" depends on "num-traits v0.1.43 Target(lib) Profile(build) Target" and "serde v1.0.37 Target(lib) Profile(build) Target" by looking at the generated JSON output. This also gives the external build system some indication of what it is building, so it can use the key when displaying what it's building. Eg: "Now building app_units v0.6.0 Target(lib) Profile(build) Target".  Note this doesn't need to be consistent among cargo versions, as long as the buildkey is unique for different modules (including host vs. target vs. build-script iterations of a particular cargo module) during a single 'cargo --build-plan' invocation. I'm happy to use another naming scheme though if there's a better way to get this information.

we expose target directory structure via various command-line options. I think this OK probably, as long as we document that precise outputs location are subject to change. I expect that, if a build systems wants to use a different directory structure, it can reliably post-process the build plan and substitute target dir with something else. Perhaps it makes sense to add a targer_dir field to build-plan itself, to make it easier to distinguish invariant source paths from potentially changeable target paths?

Sorry I don't quite follow this. What target are you referring to? Is this the --target flag in the json output? Or the self.target in the buildkey definition?
I don't think it matters if the output location changes, since the "outputs" field of the build plan explicitly lists where the file will be created. So if cargo decides things need to be in a different directory, a new 'cargo --build-plan' invocation will list a different output for a module, where the new file can be created.

we expose links key. Is this really necessary? I think that we use it cargo mainly for user's convenience, and otherwise everything else works with unliked outputs from deps (not sure about this though, let's ask @alexcrichton).

I'm pretty sure this is necessary, otherwise the external build system won't know where to create the symlink for the "installed" version of the file.

Regarding the implementation itself, it looks great! We use slightly different code style in Cargo though, so you might want to rustup +stable component add rustfmt-preview and run rustfmt +stavle --skip-children $FILE for changed files.

Ahh, thanks for the heads up! I've used this on the files I've changed, though I had to use '--toolchain stable' instead of '+stable'.

It would also be great to have some tests for this as well! I think we should create a tests/testsuite/build_plan.rs file and add a couple of smoke test.

Good idea, I'll add some tests to get at least some basic coverage.

What would be a nice side goal for this (though I hope that doesn't complicate it too much) is if cargo itself is refactored such that it goes through (a) generating the build plan, and then (b) executing from the build plan. That would make it more robust in the sense that we know the cargo build itself is not inadvertently relying on anything but the build plan.
That's not in this PR, as far as I can see, right?

I like that idea, but unfortunately that's a bit beyond my level of expertise at the moment. You are correct that it is not in this PR. Maybe we can file a followup issue? I'm not really sure what would be involved.

I was trying to make the buildkey to be something human-readable, so for example you would be able to see that a "app_units v0.6.0 Target(lib) Profile(build) Target" depends on "num-traits v0.1.43 Target(lib) Profile(build) Target" and "serde v1.0.37 Target(lib) Profile(build) Target" by looking at the generated JSON output. This also gives the external build system some indication of what it is building, so it can use the key when displaying what it's building.

Hm, interesting! I think it makes sense to also make it possible to connect build plan with other pieces of JSON information: cargo metadata and cargo build --message-format=json. To do that, we could include PackageId and Target field, like we do for artifacts. Hm, perhaps we should just embed Artifact as a field of Module?

Yeah this is something we'll definitely want, otherwise Cargo I believe will only generate files with unreadable hashes!

I'm pretty sure this is necessary, otherwise the external build system won't know where to create the symlink for the "installed" version of the file.

I have a slight suspicion that we are not on the same page here, so let me ask a clarifying question:
Am I correct that links is not strictly required? That is, I think if one executes the build plan without links, everything just works because Cargo only ever uses stuff from the deps folder? That is, link is  there strictly for user's convenience, so that they can ./target/debug/my-binary.
The external build system would probably want to put final artifacts elsewhere, so the link key is probably not to relevant for it?

@matklad hm a good question. So I know a lot of artifacts are target/debug/deps/foo which get linked to target/debug/foo, but I think we've also got artifacts like target/debug/deps/bar-xxxxxxx which get linked to target/debug/bar. For those with hashes I think we need a links, right?

For those with hashes I think we need a links, right?

Hm, so I've made an experiment by disabling all linking, and looks like it is required at least for build scripts:
error: failed to run custom build command for `regex v0.2.10`
could not execute process `/home/matklad/projects/cargo/target/debug/build/regex-c000d0f4c53b8f51/build-script-build` (never executed)
warning: build failed, waiting for other jobs to finish...
error: build failed

Heh interesting! We could probably fix Cargo to not actually require links, but I think we'd still want to keep it for the final artifact regardless

Would it be possible perhaps to do rules name foo-h145135135? The stringified version may not be entirely lossless in terms of capturing all the nuances that Cargo has, but hashing everything will for sure catch everything. I'm not sure if that's too unreadable of a target though? We could certainly work to make the prefix string pretty human readable.

In order to get the test cases working, I had to change the key to be something other than the buildkey, so I've tried to implement @matklad's HashMap suggestion. (The with_json() function doesn't seem to let me wildcard keys with things like "foo [..]", only values). I couldn't get it to work with Unit since we don't have a Unit available during the drain_the_queue() function where I call plan.update(), so I've left it as a buildkey String for now. If there's a good way to fix get_id() to use a Unit everywhere, I could use some suggestions. The previous key is available as "display_name" in the Module structure so it is more clear what it is used for.

I see build plans as a sort of "build me a plan for this exact one invocation" rather than "build me a plan which is configurable at build-time in the same way Cargo is". For the latter case I think you'd want to generate multiple plans or just use Cargo.

Yes, exactly.

Hm, interesting! I think it makes sense to also make it possible to connect build plan with other pieces of JSON information: cargo metadata and cargo build --message-format=json. To do that, we could include PackageId and Target field, like we do for artifacts. Hm, perhaps we should just embed Artifact as a field of Module?

Perhaps? It does look similar, though I don't have a full grasp of the overall architecture to know if they would easily be combined.

The new push includes:

A few basic test cases for --build-plan
A module_map to use integer keys for the modules
Separate display_name for the user-readable string of the module
Ran rustfmt & rebased

I forgot to ask:

Is there a way I can use serde's to_string_pretty() and still have it work with test cases? The with_json() function doesn't seem to like the fact that to_string_pretty() prints on multiple lines.

When usize is serialized, it gets serialized as a string when it's a key, but as an integer when it's in a Vec. For example, in BuildPlan I have modules: BTreeMap<usize, Module>, which ends up looking like this:

"0": { ... }
And inside the module, the deps: Vec show up like this:
"deps": [2, 3, 4]

It would be helpful if they were either both quoted, or both not quoted, if possible.

:umbrella: The latest upstream changes (presumably #5384) made this pull request unmergeable. Please resolve the merge conflicts.

I've addressed most of the review feedback. The remaining issues involve the display_name hashing and storing elements of Unit in the Module. I'm a bit stumped on how to resolve it with Default, and also how to get a Unit into the update() method so that we can call get_id() and update a Module's outputs.
I also updated the BuildPlan to include a list of inputs, so an external build system will know which files cargo accessed so it can determine if the plan is out of date with respect to the input Cargo.toml files. This seemed to be fairly straightforward, but this section should also be reviewed.
After rebasing to the latest master, I noticed that cargo can no longer build mozilla-central. It fails with:
error: failed to resolve patches for `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to load source for a dependency on `serde_derive`

Caused by:
  Unable to update https://github.com/servo/serde?branch=deserialize_from_enums6#b8d39b01

Caused by:
  failed to update replaced source https://github.com/servo/serde?branch=deserialize_from_enums6#b8d39b01

Caused by:
  failed to parse manifest at `/home/mshal/mozilla-central-tmp/third_party/rust/serde/Cargo.toml`

Caused by:
  Feature `derive` depends on `serde_derive` which is not an optional dependency.
Consider adding `optional = true` to the dependency

I bisected it down to commit 4966f5394fbd562db1c7f069018a4e5781eadb7e. Ted poked around with it - it looks like it now finds the last dependency instead of the first, and serde lists serde_derive twice (once in dependencies and once in dev-dependencies), so that commit changes which one it tries to use.

Is there a better way to handle the tests in a cross-platform way than what I have? Right now they are listed as [cfg(unix)] due to the paths in the JSON output and '/' not matching '' on Windows. I also had to wildcard out some of the outputs because of the additional dSYM file in OSX, but I'd prefer if I could list the expected outputs for the platform somewhere and feed that into the expected JSON.

:umbrella: The latest upstream changes (presumably #5432) made this pull request unmergeable. Please resolve the merge conflicts.

@mshal oh the issue about optional dependencies should be resolved by https://github.com/rust-lang/cargo/pull/5454, now landed on master

I'm a bit stumped on how to resolve it with Default, and also how to get a Unit into the update() method so that we can call get_id() and update a Module's outputs.

I may have missed something, but it wasn't immediately apparent to me at least on first read what was causing the problems, can you expand on this a bit and maybe we can help out?

Is there a better way to handle the tests in a cross-platform way than what I have?

Nah unfortunately it's mostly just liberally ignoring stuff like file extensions. You can use [/] to match the platform's path separate to handle Windows, and I think that'll work in the context of JSON matching as well

I'm a bit stumped on how to resolve it with Default, and also how to get a Unit into the update() method so that we can call get_id() and update a Module's outputs.

I may have missed something, but it wasn't immediately apparent to me at least on first read what was causing the problems, can you expand on this a bit and maybe we can help out?

I was having problems calling get_id() on the dep_targets to build the Vec of dependencies, since the dependent Units may not have been in the BuildPlan yet via add(). However, I think this is just solved by calling plan.add() after the dependent Units are processed in compile() instead of before. Then we can know that all dependencies will already have an id in the module_map and avoid adding Default modules for dependencies that haven't been processed yet.
I haven't yet updated this to include PackageId / Target - I'm still trying to sort out how I can use those in the consumer of the JSON to produce a reasonable display. In the meantime I still have display_name, but it's not used for anything in the BuildPlan. I'll try to update this when I have time next week.
Since the module_map (now invocation_map) isn't actually needed by the JSON consumer, I split up the BuildPlan structure to have a serializable part and a part that contains the mapping. We only need the mapping to find the Invocation during update() in order to update the command with the information we get during cargo execution.

Is there a better way to handle the tests in a cross-platform way than what I have?

Nah unfortunately it's mostly just liberally ignoring stuff like file extensions. You can use [/] to match the platform's path separate to handle Windows, and I think that'll work in the context of JSON matching as well

Thanks! That helped me get the tests running on Windows as well.

Sounds great, thanks for continuing to work on this @mshal!

:umbrella: The latest upstream changes (presumably #5358) made this pull request unmergeable. Please resolve the merge conflicts.

I ended up exporting the package name, package version, the unit Kind and the TargetKind so the end-user build system can display the various elements in some way to show what Invocations it is building. I initially tried to use the PackageId, but that includes the source_id URL, which is long and not very useful. With these elements we can show whether its a Host or Target invocation, and distinguish between build scripts & non-build scripts.
As a result of rebasing to master, it seems like the new home for the build_plan flag should be in BuildConfig, so I've moved it there. If I'm wrong in that assumption, let me know.

This all looks good to me, thanks @mshal!
@matklad did you want to take one last look as well?

LGTM modulo couple of ultra minor nits.
But r=me even with nits unfixed: they dont' really matter, and this awesome PR has gone through too many rebases already!
Invocation struct looks great! I am rather confident making it a part of public API. The only think I am not entirely sure is that TargetKind is currently ambiguous, because there may be several targets with the same kind. However, lets solve this issue separately, because it is not specific to build plans: we generally don't do a very good job referring to targets. I've filed https://github.com/rust-lang/cargo/issues/5508 for that.

@bors: r=matklad

:pushpin: Commit 4016bac has been approved by matklad

@bors: r=matklad

:pushpin: Commit a071c3a has been approved by matklad

:hourglass: Testing commit a071c3ab9bf3d18f5c5b7a0c96fe670987680f9b with merge 13c258ecaefccaad88a173e8b8dc8517db9e8aad...

:sunny: Test successful - status-appveyor, status-travis
Approved by: matklad
Pushing 13c258ecaefccaad88a173e8b8dc8517db9e8aad to master...

Does this need a tracking issue?

Sure yeah! @jonas-schievink want to write one up?

Sure, opened https://github.com/rust-lang/cargo/issues/5579 to track this

Awesome, thanks!


Fix react example redirect

The react example didn't work if you configured the UI to be on the different (sub)domain or port than the Ory Tunnel.
Checklist

[x] I have read the contributing guidelines and signed the CLA.
[x] I have referenced an issue containing the design document if my change introduces a new feature.
[x] I have read the security policy.
[x] I confirm that this pull request does not address a security vulnerability.
If this pull request addresses a security vulnerability,
I confirm that I got approval (please contact<EMAIL_ADDRESS>from the maintainers to push the changes.
[ ] I have added tests that prove my fix is effective or that my feature works.
[x] I have added the necessary documentation within the code base (if appropriate).

I just noticed this is kinda the same fix as https://github.com/ory/elements/pull/169


Make it GitHub Pages compatible

Jekyll 2.0 has built-in support of Sass, so we can remove jekyll-assets from this theme and makes it GitHub Pages compatible.
Also Kramdown is used instead of maruku as suggested by GitHub.
This closes #16 #21

Any reason why it's not being merge?

This works for me.


Remove note about TLSRoute being required by Cilium

The requirement for TLSRoute to be installed when
enabling Gateway API functions was removed in
PR #34212, so this caveat can now be removed.

/test


add subject to Email.transform_data

Add subject in the Email.transform_data to be able to return the subject value for the email.

:+1:


Using server-side generated thumbnails for the “Initial File List”

Type of issue

[ ] Bug report
[ ] Feature request
[ X] Support request

Uploader type

[ X] Traditional
[ ] S3
[ ] Azure

Hi, I asked a question about server-side generated thumbnails on StackOberflow, but didn't get any answers. Maybe someone here can help?
https://stackoverflow.com/questions/45935016/fine-uploader-using-server-side-generated-thumbnails-for-the-initial-file-lis
The question :

I saw a couple of messages about this topic, but I still haven't found how to make Fine Uploader use thumbnails generated by the server for the Initial File List files.
I use a "traditional" server-side Fine Uploader implementation, for pictures upload, as described in the Getting Started section. But I also want to use Fine Uploader as a gallery to show already uploaded pictures, so I use the "session" config to populate it, when it loads...
This works, but Fine Uploader creates Base64 images for those already uploaded images, even if I return a thumbnailUrl property for each of them, pointing to already resized thumbnails... Indeed, when I upload pictures, I generate thumbnails on the server, by myself. I want Fine Uploader to display those thumbnails when the "Initial File List" is received. How can I achieve this?
I've read about the drawThumbnail() function, but I don't know exactly how to use it. Should I call it manually in the onSessionRequestComplete event? Will that prevent Fine Uploader to create Base64 thumbnails by itself?

Thanks in advance!

Sorry - I simply don't have the time to troubleshoot. If you can locate a specific bug in the library, I will be happy to re-open and address.


support dnspod

I just discovered this project is in the process of being moved: https://github.com/PalmStoneGames/kube-cert-manager/issues/33#issuecomment-305074550


RIght clicking after opening crashes the editor

Material Maker version:
fad0b678e9ec8ce12171110a28eeab644777236e
OS/device including version:

Issue description:

Open the editor
Right click
Crash

▶ /Applications/material_maker.app/Contents/MacOS/material_maker
arguments
0: /Applications/material_maker.app/Contents/MacOS/material_maker
Godot Engine v3.4.3.rc1.official.894b6d504 - https://godotengine.org
OpenGL ES 3.0 Renderer: Intel(R) Iris(TM) Plus Graphics 655
OpenGL ES Batching: ON
WARNING: World already has an environment (Another WorldEnvironment?), overriding.
at: _notification (scene/3d/world_environment.cpp:38)
Failed to open /Applications/material_maker.app/Contents/MacOS/library/base.json
Failed to open res://material_maker/library/base.json
Failed to open user://library/user.json
Failed to open /Applications/material_maker.app/Contents/MacOS/library/base_brushes.json
Failed to open res://material_maker/library/base_brushes.json
Failed to open user://library/user_brushes.json
LOADER: data not supported:{name:Material, parameters:{size:11}, type:material}
False
[1]    75427 segmentation fault  /Applications/material_maker.app/Contents/MacOS/material_make

Steps to reproduce:
See above

Note, this seems to be another export issue.
I exported the file as .dmg instead of .zip and it seems to be working correctly now.
https://file.io/na9NMIQrdXme


Discuss Release lockdown change requirements

We should Look into the lockdown process in terms of lockdown of changes into the build repository - do we need to be this strict? Does it cause any problems holding up changes into the main nightly builds?

Do you have any examples of this being a problem? I would suggest that as we improve the execution times for the TCK any problems will be reduced over time. Also I would be reluctant to release the lockdown during a period where there is a chance of a respin so I'd personally prefer to keep this as-is.

My vote is to stay strict in terms of what we lock down but we can assess daily when to unlock

I don't think there has been much appetite for this given the potential risks so I'm going to close it. If we find it's causing a problem/holding people up unecessarily we can revisit (The April '22 quad release cycle may provide a good test of how long we lock down for)


Adapt to OpenTelemery protocol

What problem does the new feature solve?
Make greptimedb adapt to OpenTelemery protocol(OTLP) for storing log, tracing , metric time series data
Related discussions:
https://github.com/GreptimeTeam/greptimedb/discussions/1176
What does the feature do?
Can receive and store OLTP time series data
Implementation challenges
Three ideas about this

Adapt OLTP protocol in client library

Add OLTP exporter in greptimedb Frontend

Add another alone backend build on greptimedb just like promscale which is another tsdb component.

It seems logic to implement OTLP in the frontend among other protocols. However, I'm not sure if it's a good idea to support logs and traces. They are known to have a high volume (terabytes to petabytes), so ofter specialized storages like Grafana Tempo are used

yeah, Grafana Tempo is very good. But in my sense, log trace are all timeseries data like metrics and metrics store are also need a high volume.
Querying log and tracing will be two steps:  1. within a time duration range 2. get detail for each data in range
Maybe there is something different in mertics store with log and trace store, but I donot know and you can tell me😄

Querying everything from one store sounds awesome, however, in practice, store has to be optimized to specific type of workload. Traces/logs meta (id, tags, time) are low-volume and timeseries indeed. Metrics are low volume too, usually, tens of gigabytes. However, traces and logs data (message, events etc) are high volume and can occupy terabytes to petabytes. Thus, they're stored in specialized storages, like elastic, clickhouse or some index + S3.
I'm trying to say that logs/traces support is possible, but may require a lot of effort, this can be a big task IMO.
So I'd initially support metrics only and discuss traces/logs separately.

Thx a lot  for explaining difference between metric and log/tracing. You are right and we can only support metrics first.
Maybe we can start another discussion about log\tracing data.
just from my knowledge

logki use blotdb and object store((like s3),
tempo use parquet and object store that is the same as greptimedb
so we can do something with log/tracing meta and data design.
Maybe we can start an new issue or discussion to design this together with greptimedb member

We could implement specialized engines for log/trace data if necessary. Currently, I'd like to focus on metrics-like data first so we might not optimize for log/trace data.

we can only support metrics first.

We could support metrics first. After that, if users don't care about performance, we could store log/trace data like how we store metrics.

Maybe we can start another discussion about log\tracing data.

A new discussion thread is welcome.

We already supported it in https://github.com/GreptimeTeam/greptimedb/pull/1974


Changing LocationEngine (#292)

When replacing the Location from LocationLayerPlugin, the LocationLayerPlugin was still listening the previous LocationEngine. I also remove first, then set the new one in setLocationEngine method.

This is referenced by https://github.com/mapbox/mapbox-plugins-android/pull/307 and will land as a part of https://github.com/mapbox/mapbox-plugins-android/pull/293.


Odd error when importing

Description
I work for a company who is beginning to migrate to github.com from GHES.  The other day a user migrated a repo and they had an error message in the migration issue that I've not seen before.  I don't know if this is a bug in GHES or gh-gei but I felt it was best to ask before I tell people what's going on.
github.example.com in the log below is running GHES 3.6.7.
I've sanitized this a bit but you can see what's happening clearly enough I think:
[2023-02-24T17:44:44Z] INFO -- Migration started by githubautomation_example from https://github.example.com/example-ui/component-library to example-Tech/area.component-library
[2023-02-24T17:44:44Z] INFO -- Migration ID: 0be0085e-cd69-476d-bee5-e3ec2e772d0c
[2023-02-24T17:44:44Z] INFO -- -----------------------------
[2023-02-24T17:44:44Z] INFO -- Git source migration started
[2023-02-24T17:50:20Z] INFO -- Git source migration completed
[2023-02-24T17:50:20Z] INFO -- -----------------------------
[2023-02-24T17:50:20Z] INFO -- Extraction started
[2023-02-24T17:54:24Z] INFO -- Extraction complete
[2023-02-24T17:54:24Z] INFO -- -----------------------------
[2023-02-24T17:54:24Z] INFO -- Transformation started
[2023-02-24T17:55:44Z] INFO -- Pull Request Review Thread Comment with url https://github.example.com/example-ui/component-library/pull/746/files#r793476 could not be transformed. Reason: Document::ValidationError - {:thread_id=>["can't be blank"]}
[2023-02-24T17:56:43Z] INFO -- Transformation complete
[2023-02-24T17:56:43Z] INFO -- -----------------------------
[2023-02-24T17:56:43Z] INFO -- Import started
[2023-02-24T17:56:53Z] WARN -- LoadCommitCommentJob: Commit comment could not be added to commit with ID 052be943b0ad63f17c3973df701ea21ad728db19
[2023-02-24T17:56:53Z] WARN -- LoadCommitCommentJob: Commit comment could not be added to commit with ID 052be943b0ad63f17c3973df701ea21ad728db19
[2023-02-24T17:56:53Z] WARN -- LoadCommitCommentJob: Commit comment could not be added to commit with ID 052be943b0ad63f17c3973df701ea21ad728db19
[2023-02-24T17:56:55Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/13/files#pullrequestreview-1006745 could not be imported.
[2023-02-24T17:56:56Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/17/files#pullrequestreview-1012662 could not be imported.
[2023-02-24T17:56:56Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/21/files#pullrequestreview-1016842 could not be imported.
[2023-02-24T17:56:58Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/18/files#pullrequestreview-1022672 could not be imported.
[2023-02-24T17:56:58Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/25/files#pullrequestreview-1031749 could not be imported.
[2023-02-24T17:57:06Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/175/files#pullrequestreview-1173438 could not be imported.
[2023-02-24T17:57:11Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/175/files#pullrequestreview-1177278 could not be imported.
[2023-02-24T17:57:14Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/320/files#pullrequestreview-1330421 could not be imported.
[2023-02-24T17:57:16Z] WARN -- LoadIssueJob: Issue with url https://github.example.com/example-ui/component-library/issues/904 could not be imported.
[2023-02-24T17:57:18Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/320/files#pullrequestreview-1343463 could not be imported.
[2023-02-24T17:57:19Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/320/files#pullrequestreview-1348393 could not be imported.
[2023-02-24T17:57:19Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/374/files#pullrequestreview-1391950 could not be imported.
[2023-02-24T17:57:19Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/320/files#pullrequestreview-1348409 could not be imported.
[2023-02-24T17:57:25Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/374/files#pullrequestreview-1392860 could not be imported.
[2023-02-24T17:57:28Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/507/files#pullrequestreview-1577873 could not be imported.
[2023-02-24T17:57:29Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/507/files#pullrequestreview-1595939 could not be imported.
[2023-02-24T17:57:29Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/374/files#pullrequestreview-1393178 could not be imported.
[2023-02-24T17:57:30Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/507/files#pullrequestreview-1598025 could not be imported.
[2023-02-24T17:57:30Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/374/files#pullrequestreview-1393182 could not be imported.
[2023-02-24T17:57:31Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/374/files#pullrequestreview-1395585 could not be imported.
[2023-02-24T17:57:33Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/585/files#pullrequestreview-1692553 could not be imported.
[2023-02-24T17:57:35Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/585/files#pullrequestreview-1698169 could not be imported.
[2023-02-24T17:57:36Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/374/files#pullrequestreview-1399214 could not be imported.
[2023-02-24T17:57:37Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/585/files#pullrequestreview-1700605 could not be imported.
[2023-02-24T17:57:39Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/716/files#pullrequestreview-1866910 could not be imported.
[2023-02-24T17:57:43Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/775/files#pullrequestreview-1981075 could not be imported.
[2023-02-24T17:57:43Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/775/files#pullrequestreview-1981115 could not be imported.
[2023-02-24T17:57:46Z] ERROR -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/795/files#pullrequestreview-2010321 could not be imported.
[2023-02-24T17:57:47Z] WARN -- LoadPullRequestReviewJob: Pull Request Review https://github.example.com/example-ui/component-library/pull/751/files#pullrequestreview-1956965 could not be imported.
[2023-02-24T17:57:57Z] INFO -- Import failed
[2023-02-24T17:57:57Z] INFO -- -----------------------------
[2023-02-24T17:57:57Z] INFO -- Migration failed
[2023-02-24T17:57:57Z] INFO -- -----------------------------

What I'm hoping for from this team is to understand if this is something that I can remedy in some way or another.  I don't know if it's GHES or gh-gei which is reporting that {:thread_id=>["can't be blank"]} error, so I don't know where to look for a fix, or even if I need to.
if github.com is looking for data in the metadata export of this repo that GHES is not putting into the metadata export, I can explain that to people and ask them to delay migrations until this is resolved.  They don't really have a choice to wait, as you can see.  Import stops when it sees this problem, it looks like.

@naikrovek Thanks for reaching out! This is an issue with the GitHub Enterprise Importer backend rather than the open-source CLI, so your best bet would be to open a GitHub Support ticket so we can look into this.


Circuit decomposition for all ranges

This makes our Circuit decomposition total for all ranges (old decomposition is invalid if the variables take ranges outside of the element bounds).
This makes circuit about 20% slower (from limited testing)
Alternative is to disallow making circuits with variables outside the expected range.

blocked since we will first make element a total function

Yes, I think we can already merge this one, not really blocked by anything I believe.
An optimization that we can implement is to check whether the bounds of the variables are in fact tight, and make a = cp.BoolVal(True) accordingly.
Also some docstring on the rationale behind this might be good : )

Not sure about checking if all the bounds are tight, in stead of just adding a = True we could as well just use the old decomposition in that case, which would still be a bit better? but seems ugly

They should map to the same after our transformations such as 'simplify_bool', right? Indeed comes down on how clean we want this code :)

we could also just return false in case the bounds don't include 0 or n-1, but that seems like a step too far

actually just realised that checking the bounds is not good enough to set a == true.
if we have a hole in our domain, or more specific if we cant get one of each variable to be in our ordering it will still be wrong.
Maybe i will abandon the optimisation
other option would be to have the ordering aux take wider bounds depending on the bounds in succ (but might still be tricky for missing values i think)
returning false is sound though

will push failing test to show what i mean

There are several issues with the new test : )

You did not make it a NDVarArray so the == just resolves to "True"
If you do make it a NDVarArray the model will fail because x[2]  == 3 can never be true given the domain.

Anyway, I don't think there is an issue with the current approach.
If we have the domains given by the array you gave, the Circuit will never be satisfied, but this is different from being undefined. The definition of successor variables will always be fine, but the constraining part will fail, which ensures the Circuit constraint will fail.
E.g., [1, 2, 1, 0] is a valid solution of ~circuit which defines the order variables as [1, 2, 1, 2] which is fine : )

damn you're right, i was expecting this to break. Got paranoia when it comes to Circuit.
Feel free to alter the docstring, kind of hard to articulate it well

Ran into another problem tough, if you run ~circuit(x) where x does not include 0, the decomposition returns [Boolval(False)], but then decompose_in_tree adds the constraint all([Boolval([False])), which returns False (not a BoolVal). This then breaks push down negation because we assume there that everything is an expression.
Not sure if this is a bug in decompose, all, or push down negation..

Hmm I see.
It is certainly not a bug in the decomposition, either (or rather both) push_down_negation and all should cover this case.
I'll fix this in this PR

I think we can only return boolval (for all and any) if we have expressions in the input, since we still want it to function like the python version in other inputs

Maybe changing the order of the if's is good enough?

Yes, indeed! Had not tought of that - changing the order of if's should indeed do the trick, also better to put the more likely case up anyway : )

So let's merge this and think another time about all/any?

Yes, agreed - will merge.


Error when using Ripple

Hi,
I'm using the latest version of the plugin in a Cordova project. This is my code:
cordova.getAppVersion.getVersionNumber(function (version) {
$scope.versionNumber = version;
});
When using the emulator or a real device it all works well. But when using Ripple as the target, I get the following error:

What can be the problem? It's annoying because I use Ripple for most of development.
Thank you.

its emultaor.. they dont have this getVersionNumber they tell you to give them some example data that you want to get back from that call

Of course, not, this is what the plugin is providing, right? But can it be extended to support Ripple as a platform (just as it does with android, ios, windows8, wp8, etc.)?

and from where it will get the version? as ripple its just running it in the browser not in cordova.. I think you should hanlde it yourself, just check if you are in cordva than use cordova plugin, if not in cordova than find a way to get the version and return it

Well, it could return null or undefined or empty string, but not pop-up the annoying window.
Well, the idea to check the platform before using the plugin is all right. I got it to work this way.

@mariusbancila Is there a standard way that a plugin can add ripple emulation as a platform? What do other plugins do?
I don't want to have code to detect ripple and behave differently if it is installed that gets included in every real app whether it uses ripple or not - that seems like a bad idea.

Ripple seems to no longer be maintained, I'm closing this issue unless more requests return.


Basic view support/Bug fix

On the month, basicWeek and basicDay views right clicking on a day didn't always raise the right click event and on the agendaWeek and agendaDay views right clicking on the all day events wasn't supported. To support this I modified the monkeyPatchViewClass to support multiple parameters and build the css selector to bind to. After navigating to a new month, week or day multiple right click events get raised. To correct this I call 'off' on the contextmenu event before binding it.

Thank you very much for the contribution. I've integrated the changes into master (but had to make some modifications so they would also work for me). Please check out v1.4!


Daemon: Do not clean policy maps on startup

On startup the filepath is not set, and the map is not open (it does not
have an fd) there will be a diff and map will always be deleted.
Fix #5142
Signed-off-by: Eloy Coto<EMAIL_ADDRESS>

This change is

test-me-please

Not sure why the build failed - it only took a few seconds, then exited with failure.


[UI improvement] Return to index rather than to next unread email after performing group select operations

I frequently select multiple email items to delete or archive with one click. It would be nice if there was an option (if not the default) to have RainLoop go back to the Index (with "Select message in list to view it here" on the right side) after the operation rather than to make RainLoop jump to the mail item that follows immediately the last of the mail items that were previously selected.

if not the default

Please don't. Selecting the next item after some sort of operation, in any application, is what's been keeping our sanity for all these years.

Let me elaborate the issue.
Let's say you select the top five mail items in your inbox and perform some sort of operation on them. Then it may make sense to automatically select and view the next item that follows that list.
On the other hand, if you select a disjoint set of items, for example the 1st, the 5th and the 15th item (a common scenario when cleaning out unwanted mails), then it makes no sense to jump to the 16th item once the operation completed.


Add enable VNC command

This command enables VNC and sets up a user account to use for VNC access.
On macOS 12 and above, this needs to be enabled via System Preferences, so we need to run an AppleScript to do this.
The password for the VNC user account should be stored in MAC_ORB_VNC_PASSWORD variable in the project settings.

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/circleci/macos?version=dev:7c1c7406fc608ca59a7c3a61eb42dfa78867b0aa

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/circleci/macos?version=dev:7c1c7406fc608ca59a7c3a61eb42dfa78867b0aa

Your orb has been published to the CircleCI Orb Registry.
You can view your published orb on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/circleci/macos?version=2.3.0


How to pass variables in?

Is there any way to pass variables in?
I know this isn't correct, but something like:
const Button = styled('button')`
  ${props=> tw`font-mono text-sm text-${props.textColor} hover:text-${props.textColorHover}`};
`

Same question. I guess you found an answer for this. May I ask what it was, please?

@pkrogel-kws Did you found the solution?

The plugin doesn't support class name interpolation. e.g. text-${props.foo}

Hey @bradlc 👋, I'm very interested! Is't planned to support class name interpolation one day?


Changed the MQTT client and connection options to be beans registered…

… by the configuration.

@burberius check this link please: https://cbea.ms/git-commit/#imperative


Declaring a Union Type

How can I use Graphiti to define a Union type.

As you might've guessed currently you can't. Thanks for #10. Let's continue the discussion over there. 😊


[Navigator] Top scene always forces sub-scenes to 0 opacity

I'm trying to implement a modal scene, triggered by pushing a scene to a Navigator and using the FloatFromBottom SceneConfig to make it appear as a modal (as per the docs, being the recommended approach). Now that works fine for all situations where you'd like the modal to occupy 100% of the screen height / width, but for modals where you'd like the scene beneath to still be visible this is currently not possible.
Here's a video example to illustrate what's currently happening:
https://www.dropbox.com/s/sd82or6umlzo654/rn-scene-opacity-420.mov?dl=0
I've dug through the Navigator code, and I can see that when the transition has finished there's a call made to _hideScenes which calls _disableScene on every scene loaded and forces the style to have an opacity of 0 through SCENE_DISABLED_NATIVE_PROPS . You can see this here: https://github.com/facebook/react-native/blob/master/Libraries/CustomComponents/Navigator/Navigator.js#L527-L528
I believe there's a valid use-case here of not wanting to always hide the last scene, but currently this is not possible as these props are forced. I'm also aware there are other ways to implement this behavior, but I'd rather rely on the already written transition animations and management that Navigator provides rather than implementing custom open / close animations etc. I can also see others running into this issue, especially as iOS is using more of these style views.
In my mind, it would be perfect to be able to do this in the SceneConfig itself, but I'm totally open to other suggestions and would love to hear opinions before trying to resolve this and PR it myself.
Thanks very much and let me know if you'd like more detail.

cc @ericvicenti @hedgerwang

Any updates on this?

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/navigator-top-scene-always-forces-sub-scenes-to-0-opacity
ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub.
Also, if this issue is a bug, please consider sending a PR with a fix.
We're a small team and rely on the community for bug fixes of issues that don't affect fb apps.


[BUG] Multivariate_normal causing latex build fail

Multivariate_normal had math symbols and math directive issues, details of which are in https://github.com/QuantEcon/lecture-python/issues/269
fixes https://github.com/QuantEcon/lecture-python/issues/269

thanks @AakashGfude - nice work.
So the italic unicode characters are still an issue after fixing the aligned math environments?

@AakashGfude I just checked python and this change shouldn't change the way the code works in python
Python 3.8.3 (default, Jul  2 2020, 11:26:31)
[Clang 10.0.0 ] :: Anaconda, Inc. on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> θ = 1
>>> 𝜃 = 2
>>> print(θ)
2
>>>


fix(list): Fixed list-peers and list-relays commands

PR related to this trello task --> https://trello.com/c/6kntqtYZ

:tada: This PR is included in version 1.26.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Continual tests logging within test scope

Fixes an issue with logging of Continual upgrade tests which interleaves with other logs and cannot be easily connected to a test that produces the logs. An example run that has this problem is here (note especially logs from autoscale.go which are scattered across other logs.
Changes

:bug: Fix bug
Use internal logger that is buffering the logs from continual tests - both Start and Verify phases
Print the complete log in t.Log before the "Verify" phase. Print the rest of background logs to t.Log when the Verify phase ends in case a background routine is still writing logs while being in the Verify phase.
If the Start phase fails and there are some logs they're printed to t.Log immediately without waiting for the Verify phase.
The logs are then printed within the test scope as can be seen in a test PR here: https://prow.knative.dev/view/gs/knative-prow/pr-logs/pull/knative_serving/12027/pull-knative-serving-upgrade-tests/1473586664545718272

Fixes #

Release Note

Docs

/kind bug

Print the complete log in t.Log once the test finishes (at "Verify" phase). This is in turn printed to stdout by testing.T only if the test fails.

Does that mean that the loglines will be out of order and we'll have to backtrack their order based on the timestamps logged?

@markusthoemmes no, if you look at the test run the logs are ordered, the timestamps go chronologically. https://storage.googleapis.com/knative-prow/pr-logs/pull/knative_serving/12027/pull-knative-serving-upgrade-tests/1440597482730950656/build-log.txt
Do you see a problem in the logs?

autoscaler.go:65: Induced error supposedly should actually be at the end of the log rather than at the beginning? If anything in the test itself logs to t.Log it'll be out of order with the buffered logs, I think.

Actually, if the Verify phase logs something via t.Log/Error. it will be printed first. And then the whole output of background operations is printed (but the output in itself is ordered)

Pushed updates. The example of resulting logs is in this run: https://prow.knative.dev/view/gs/knative-prow/pr-logs/pull/knative_serving/12027/pull-knative-serving-upgrade-tests/1440679478693990400 (this is without the last commit which removes the extra space)

/retest

@cardil @markusthoemmes is there anything else to do with this PR or is this ready for merging from your POV? Can we agree that the logs look better than before? Instead of being interleaved with all other logs they're now in the place of the given test.
I've answered the questions and addressed the feedback mostly (except for logging each line separately which I'm missing the reason for). Thanks

@cardil Hey, it's been 1.5 months since I pushed the latest changes. Anything else you want to add/comment?

@cardil Hey, it's been 1.5 months since I pushed the latest changes. Anything else you want to add/comment?

Sorry for the hold up. Review is here: https://github.com/mgencur/pkg/pull/1 - it still has problems, though.

@cardil thanks for the review ! After looking at the other PR with the code review it looks like almost nothing from my PR is left there and it's like a complete rewrite. I'm not sure why/how it performs better at this point except for keeping the tests closer to the original due to loggers delegating to testing.T. But I suppose that's the main part of the review. Perhaps, in this case I'd suggest that you open a new PR against knative/pkg and I can close mine (even though not happy about that). Somebody else should then review it.
Regarding the t.Skip or t.Fail, I don't think they're blockers. Skipping tests should happen at the beginning when there's nothing logged in the background yet. On the other hand t.Fail was not recommended even before this PR because (I believe!) it breaks the whole flow of the upgrade framework. And that's also why all tests so far have been using t.Error, not t.Fail. So, I don't see it as a critical drawback.

it looks like almost nothing from my PR is left there and it's like a complete rewrite

Not entirely. A lot of your code is still there - like to log configuration stuff, thread safe buffer. I did really add the forwarding to testing.T sink stuff, and some cosmetics. I think we could push this further as co-authors, at this point :smiley:.

I'm not sure why/how it performs better at this point except for keeping the tests closer to the original due to loggers delegating to testing.T

A couple of points I had problems with these PRs was the change of tests, to not include expected messages. We should stick to tests as they are describing the current behavior, on which many projects now rely on. Also, by feeding directly to testing.T we will always report messages in the correct test case report. testing.T is taking care of that for us.

Regarding the t.Skip or t.Fail, I don't think they're blockers. Skipping tests should happen at the beginning when there's nothing logged in the background yet.

Unfortunately, that's not true. Even if you skip test at the beginning of verify phase, you will lose all logs that are there. They are collecting in the background. The in memory buffer is created in setup phase, before upgrade/downgrade is taking place. So, numerous logs will be lost.

On the other hand t.Fail was not recommended even before this PR because (I believe!)

The t.Fatal or t.Fail are completely fine with current upgrade framework. What was problematic, was panic (from ensure.NoError(error)). Couple of months ago we had removed the panic from the framework, in favor of t.Fatal, and now it reports properly.

/hold

/hold cancel

@cardil thanks for the review! I'm testing the changes you suggested. The solution for "double output" seems to work fine. But the solution for config defaults has a problem: the zap.Config is passed by reference so the logger() function in logger.go always references the same config and appends fmt.Sprintf("%s://Log/%s", testingTScheme, testName)` to it. The result is printing every message multiple times as you can see in here (look at the bottom). I think the config needs to be passed by value so that logger() always uses a new cfg and doesn't append to the existing one. What do you think about this solution?: https://github.com/mgencur/pkg/commit/d8f109f7016d6396953f4a1928884df5d8dfa90e  (I'm testing it now...)

I've got a reproduction of that double output bug you've found in here. Please attach it for completeness.
https://github.com/knative/pkg/commit/3bba2da852228ee9342e85c8a5cc43f30ff8872c

@cardil this unit test hangs if the fix (the last commit: "Do not pass zap.Config by reference") is not there. I believe we should have a test that either succeeds or fails but doesn't hang. I was trying to find the cause of that but without success. Anyway, this test is something that doesn't need to be in this PR.

At @mgencur:

this unit test hangs if the fix (the last commit: "Do not pass zap.Config by reference") is not there. I believe we should have a test that either succeeds or fails but doesn't hang. I was trying to find the cause of that but without success. Anyway, this test is something that doesn't need to be in this PR.

That's true. This is super weird behavior. I did some debugging, and I saw the goroutine stack's looks like the code is waiting for the stop event. This shouldn't happen. It properly reports error if you limit failure point to first 3 steps: https://github.com/mgencur/pkg/blob/86d8875cfb1f62277b09d3a60010624c639f7748/test/upgrade/execute_failures_test.go#L29
for i := 1; i <= 3; i++ {

I feel a little unsure about merging this PR, without knowing the root cause. I know you are tired of this PR, but surly it's better to debug this here, then on someone else's PR in Serving or Eventing, right?

If you're planning some changes - can you add the test in another PR along the changes? Let's unblock this PR.

Apart from this issue, there are some other failing checks in this PR. We should merge with those failures not addressed.

The https://github.com/knative/pkg/issues/2399 is culprit of one test failure (code do not compile).

The downstream failure "Downstream Knative / Unit Test (serving, knative)" is caused by this PR: https://github.com/knative/pkg/pull/2395 . When I use addressable_resolver.go from before this commit the unit tests in Serving pass (tried locally). The PR above seems to have same failures as my own PR.

The downstream failure "Downstream Knative / Unit Test (serving, knative)" is caused by this PR: #2395 . When I use addressable_resolver.go from before this commit the unit tests in Serving pass (tried locally). The PR above seems to have same failures as my own PR. Edit: The same PR also causes the failure in "Downstream Knative / Unit Test (eventing, knative)" and also Downstream Knative / Unit Test (eventing-kafka-broker, knative-sandbox)

I'm aware of this and I was waiting for the release since pkg is cut one week before the release, downstream repositories can't use pkg@main

I'm also seeing this test failing, https://github.com/knative/pkg/issues/2401. Strangely, it doesn't being reported in prow unit tests or Github's unit test check.

Hey @cardil , I think the cause of the hanging is following: The tests share the same zap.Config and it keeps adding either testing-t://Log or testing-t://Error. As soon as one of the tests adds testing-t:Error, any following call to t.Log or t.Debug will write to all the outputs including the previously added Error - which writes to t.Error - and it ends the current function. The framework is then not able to send the stop event.

I think the scenario with injected failure and shared zap.Config is not testable because t.Error will interrupt the test unexpectedly (in OnWait of the continual test we're calling t.Log.Debug)

@mgencur Yes. Awesome work on analysis! That's the case, for sure. But, I think you can include the test as well because it works properly when the zap.Config is ensured to be copied. Your 86d8875 ensure that the case.

Even now, the test only passes when it's run with -v and fails when running without it. I guess that's because you stopped using the buffer and only check the test output which is only complete with -v :-/

Right. I'll try fixing the test to pass always, even without -v.
I'm okay with merging it as it is, but maybe we should wait until the release, as @pierDipi said?

Right. I'll try fixing the test to pass always, even without -v.
I'm okay with merging it as it is, but maybe we should wait until the release, as @pierDipi said?

The release was done yesterday, so we're good.

I don't get it @pierDipi. We are supposed to merge this without those passing checks? Or, you are going to prepare a fix? Or, we should wait until those failing projects consume new knative-pkg via automated update of dependencies?

We can merge it since these tests are already failing.
I started fixing issues from serving, but the PR is still open https://github.com/knative/serving/pull/12560

The continous probe test is 'split' across two golang tests instances - ContinualTests/SetupProbeTest & VerifyContinualTests/ProbeTest. Because of this split we don't have access to a test logger during the background probing. Thus I believe that's why we have a separate logger.

Yes. That's why we have two separate loggers.

The alternative would be to run the continual tests in a single t.Run() - then the test logger is accessible during the life of the entire 'logical' test ie.

The continual test needs to run in background and while it's running the "upgrade" needs to happen. I tried this approach before but hit issues with ordering of tests and parallelization (especially the t.Parallel) feature. We discussed that briefly with @cardil - an option would be to get rid of nested t.Run and make the structure of the upgrade framework flat - use go routines and synchronization etc. But that would basically require a complete rewrite of the upgrade framework.
This current PR already took enormous time and we arrived at the point where it works. I believe the current way of logging stuff from continual tests is a big improvement and will make parsing the logs easier for everybody.

@dprotaso The real life tests that uses this framework are complex. Take a look, for example, at this test suite configuration:
https://github.com/openshift-knative/serverless-operator/blob/ed2b76b759db261925e0fc6bd0d1788dc18b69e6/test/upgrade/upgrade_test.go#L45-L73
Example test report: https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift-knative_serverless-operator/1390/pull-ci-openshift-knative-serverless-operator-main-4.9-upgrade-tests-aws-ocp-49/1486800035646541824/artifacts/upgrade-tests-aws-ocp-49/serverless-e2e/artifacts/build-IzqjZquW/junit_5fDI8OZv.xml
We've got multiple subtests in various places, all of them are running in parallel during the upgrades. As @mgencur is saying, what you are proposing will mean removing the test structure t.Run, making the reporting much, much more complex.
This PR targets the reporting as the current approach uses the zap logger, so various continual tests outputs are interwoven with each other. That would be the case, if we do what you are suggesting.

Hey I wasn't suggesting we flatten the entire structure - you can use t.Parallel() to coordinate
Here's an example how - https://go.dev/play/p/shyAxjbTZbk