Better name for atop?

The class of operations encompassed by atop includes elemwise, transpose, tensordot, reductions (in theory if not in practice) and others.  It is characterized by a chunksize operation, and an Einstein-summation style indexing pattern.  Can we think of a better name for this class of operations than atop?
cc @shoyer @jcrist

I tend to think of "tensor" as more of an explicitly indexed quantity than an array.
What about "block indexed op"?

explicitly indexed quantity than an array

What do you mean by indexed quantity here?

An object with the ability to refer to elements in some sort of grid, like a numpy array?
An object with a pandas style index, like an xarray.DataArray?
An object along with some statement that uses something that looks aesthetically like einstein summation notation, like $X_{ijk}^{ij}$?

"block indexed op" sounds like an improvement to me (not to say that we couldn't come up with something better).

Or "chunk indexed"?

I also like tensor_op for the public facing function, but have no strong argument as to why. Agree that whatever it is, atop is too abbreviated to be publicly meaningful.

Any response to this concern about the name tensor_op?

The name "tensor op" seems too generic to me. Aren't operations that don't fall into the atop system also "tensor op"s? Is solve, or slicing, or the generation of random data somehow different?

Not really. When I thin tensor I think indexed operations along multiple dimensions, einstein-sum notation, etc... That all seems to fit within atop's realm (note that I don't do actual tensor work, and this word certainly means something different to others). There may be a better name though.
Free associating atop related words:

indexed
apply
blocks
tensor
op
map
contraction
reduction

And some combinations of these:

indexed_op
apply_indexed_op
apply_indexed
indexed_tensor_op
blockwise_op
apply_blocked_op

FWIW we use atop any time an operation gets too fancy for map_blocks. We also use it for all sorts of things that have nothing to do with traditional tensor operations (in addition to the more usual cases). As one example, we need to translate some frames in a video and truncate them. This is done using atop.

How about broadcast or blockwise
Also, I'm thinking of reusing the high-level atop code for dask dataframe blockwise operations.

Blockwise then?

Sounds good to me.

This has been partially implemented in #4348


Select all child elements using selectAll() with no arguments

I'd like to select all child elements using sel.selectAll() with no arguments, instead of having to use sel.selectAll('*'), because it's more concise and expressive: it just reads "select all", perfect to me.
What do you think?

I’m in favor of parsimony and explicitness, and I think selection.selectAll("*") is both clear and easy to type if that’s the behavior you want. Making that the default behavior when there is no argument would make the behavior less obvious to someone reading the code.

OK, thanks!

would have to agree with @mindrones . I expected selectAll() to just work (I was doing selectAll('g') but now need to support different children), and instead had to find this solution.

I’d support selection.selectAll() throwing an error, though I’d want to use arguments.length to check because selection.selectAll(undefined) should be equivalent to selection.selectAll("undefined").

while I have your attention :) seems like selecting all your immediate children ought to be dead simple... this is what I had to use, and complains in Typescript even with latest @types/selection
this.container.selectAll(function() {return this.childNodes; } as any)

(where container is selection of my svg root).
Would have been nice to have a selectChildren() or such shortcut for what might be very common - see https://stackoverflow.com/questions/20569670/d3-selector-for-immediate-children

Yeah, I could see selection.selectChildren (and selection.selectChild?) as being useful, and I could imagine the selector being optional there. I’d use element.children instead of element.childNodes, however, since you wouldn’t want to select text nodes.

should I file a separate request to have selection.selectChildren ?


Rancher Cleanup Scripts Not Removing a Large Number of Rancher Resources After Upgrade from 2.6.6 to 2.6.7-rc5

Rancher Server Setup

Rancher version: 2.6.7-rc5
Installation option (Docker install/Helm Chart): Helm Chart

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): RKE1 v1.3.11

Proxy/Cert Details: byo-valid

Information about the Cluster

Kubernetes version: v1.23.6-rancher1-1
Cluster Type (Local/Downstream): Local

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom): Admin

Describe the bug
After performing an upgrade from Rancher version 2.6.6 to 2.6.7-rc5, when running the cleanup script to perform a rollback the script leaves behind a large amount of Rancher resources.
To Reproduce

Deploy an HA cluster on Rancher v2.6.6
Log into HA cluster
Click the hamburger menu in the upper left of the page
Click the local cluster
In the left side menu, select Storage > Secrets
Create an Opaque secret with your AWS access keys
Go to Apps > Search for backup > Install Rancher Backups v2.1.2
Configure the default storage location to an AWS S3 bucket
Create a few resources such as users, roles, templates
Create a downstream EC2 cluster with three nodes with all roles
Go back to your local cluster > Rancher Backup > Backup
Create a backup
Perform an upgrade to 2.6.7-rc5
Log in to the control plane node of the HA1 cluster
Install kubectl client on the control plane
Get the kubeconfig file of the local cluster
export KUBECONFIG=<kubeconfig.yaml>
Follow instructions at https://github.com/rancher/rancher-cleanup
Verify the cleanup is successful - kubectl -n kube-system logs -l job-name=verify-job -f -

Result
A large amount of Rancher resources are still present after the cleanup script finishes
Expected Result
No Rancher resources remain after the cleanup script finishes
Screenshots
Cleanup Job Complete:

Cleanup Job Logs:

Verify Script Logs:

/backport v2.6.x

SURE-5349

Tagging some issues that seem related.
The cleanup script doesn't remove finalizers from namespaces
Running for hours but nothing seems to be deleted

Tested on both v2.6-head and v2.7-head rancher clusters and was verified to work as expected. The issue was caused by running the shell script directly on the control node instead of creating the kubernetes job allowing it to run across the whole cluster.
Since this is a non-issue I recommend just closing the issue. If it comes back again we can do further testing, but it was not reproducible on either version.


IA-1678: submissions - org units filter state

Repro
Go to forms list
click “view submissions” for a form
Open the side menu
Click “Submissions”
Expected:
Either: Both the filter selection and the table results are preserved
Or: Both the filter selection and the table results are cleared/ reset
Actual
The filter selection is preserved but the table results are updated (diplaying results of an empty search)
Self proof reading checklist

[x] Did I use eslint and black formatters
[x] Is my code clear enough and well documented
[x] Are my typescript files well typed
[ ] Did I add translations
[ ] My migrations file are included
[ ] Are there enough tests

Changes

useSkipEffectOnMount to watch params and sync filter states with it
ensure fetching data is not done on org units id isSearchActive not set in the params
fix a a small issue with forms without possible fields, cols were empty

How to test
Go to submissions and org units pages, perform seraches and click back the same page in the sidebar
Print screen / video
https://user-images.githubusercontent.com/12494624/205893782-17ff0559-ddc0-4ecb-92f0-76214050fa6d.mov
https://user-images.githubusercontent.com/12494624/205893883-388e1a1a-4397-4499-b3a6-e3212308d884.mov

The org unit filter doesn't reset in submissions though the results do):
Screen.Recording.2022-12-12.at.12.49.01.mov

We had the same issue on org unit selection in org unit lists, this is fixed now


Use OpenSea API key

Doesn't appear to be used. It's optional, but presumably will be more severely rate-limited without it.
Key is available in the file Constants+Credentials.swift under openseaKey, starting with 3940 in Google Drive
Set it with the HTTP header X-API-KEY

Bump


Fix world comparison

this.lastWorld == world will always return false. This is because == is compares object IDs.

Merged.


运行报错

No account for team "44HDC9YG72".
No profiles for 'github.com.njhu.iosproject' were found

请问如何修改？

模拟器可以直接搞, 真机改一下BundleID


Cannot export plan as PDF

Hi,
I cannot export my plan as PDF.
This is the error: Processing by PlanExportsController#show as PDF
Parameters: {"utf8"=>"✓", "export"=>{"form"=>"true", "question_headings"=>"true", "unanswered_questions"=>"true", "formatting"=>{"font_face"=>"Arial, Helvetica, Sans-Serif", "font_size"=>"10", "margin"=>{"top"=>"25", "bottom"=>"20", "left"=>"12", "right"=>"12"}}}, "phase_id"=>"1175", "button"=>"", "plan_id"=>"821"}
WICKED
Rendered shared/export/_plan_styling.erb (0.5ms)
Rendered shared/export/_plan.erb (97.8ms)
Rendered plan_exports/show.erb (104.7ms)
Completed 500 Internal Server Error in 317ms (ActiveRecord: 74.8ms)

RuntimeError (Bad wkhtmltopdf's path: /var/lib/gems/2.4.0/gems/wkhtmltopdf-binary-0.12.4/bin/wkhtmltopdf_linux_x64):
app/controllers/plan_exports_controller.rb:76:in `show_pdf'
app/controllers/plan_exports_controller.rb:44:in `block (2 levels) in show'
app/controllers/plan_exports_controller.rb:39:in `show'
Thank you

The runtime error you got:

RuntimeError (Bad wkhtmltopdf's path: /var/lib/gems/2.4.0/gems/wkhtmltopdf-binary-0.12.4/bin/wkhtmltopdf_linux_x64):

Would suggest that your rails app cannot find the wkhtmltopdf binary.
It's looking for it at /var/lib/gems/2.4.0/gems/wkhtmltopdf-binary-0.12.4/bin/wkhtmltopdf_linux_x64.

Thank you!


Update Formatter.php to avoid error on PHP 8

When upgrading from PHP 7 to PHP 8, I get an error "Unknown named parameter " in a GridView column using this code :
[
	'attribute' => 'id_main',
	'format' => [
		'integer',
		'numberFormatterOptions' => [	\NumberFormatter::MIN_INTEGER_DIGITS => 3],
	],
],

To solve it, we must adapt line 463 in Formatter.php, like this :  return call_user_func_array([$this, $method], array_values($params));
Cf. https://php.watch/versions/8.0/named-parameters#named-params-call_user_func_array

Q
A

Is bugfix?
✔

New feature?
✔/❌

Breaks BC?
✔/❌

Fixed issues

Makes sense. Would you please add a line for CHANGELOG?

Thanks. Next time you can just push another file to the same branch. That will update the pull request.


fix: ensure correct behavior for target ordering with DensityMatrix r…

…esult type
Issue #, if available:
Description of changes:
DensityMatrix(0, 1, 2) and DensityMatrix(0, 2, 1) have the same behavior, contrary to how Probability(0, 2, 1) is handled relative to Probability(0, 1, 2). This PR ensures out-of-order targets will be handled correctly for the DensityMatrix result type, in line with current behavior of the Probability result type.
Testing done:
Tox and added test
Merge Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.
General

[x] I have read the CONTRIBUTING doc
[x] I used the commit message format described in CONTRIBUTING
[x] I have updated any necessary documentation, including READMEs and API docs (if appropriate)

Tests

[x] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[x] I have checked that my tests are not configured for a specific region or account (if appropriate)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

The changes make sense to me. However, I don't understand why marginal_probability works before you made the change. Was there a PR associated with the marginal_probability change? Or we have been long wrong about indexing?

np.argsort returns a permutation of [1..n] giving the corresponding indices of the array elements for the array to be sorted. For example [5, 0, 2] would give [2, 0, 1]. Calling argsort a second time will accomplish nothing further, since the array is already a permutation of [1..n] and therefore the corresponding indices to sort are the same as the array values (ie. argsort([2, 0, 1]) is [2, 0, 1]).
I'm not sure why we were calling argsort twice, but it is equivalent behavior to only calling it once, so I removed the nested call.


[TypeSpec Validation] Add rule to ensure specs match file and folder structure guidelines

We are missing the validation on the path requirement for typespec specs. for example, management plane type specs should be put under the folder of xxx.Management. Management word should be capitalized.
This is an example rp spec checked in without following the guidance.
The rule in TypeSpecValidation should verify everything documented here: https://github.com/Azure/azure-rest-api-specs/blob/main/documentation/typespec-structure-guidelines.md

Please fix #24983 before this issue


SPARKTA-302 Refactor cube definition in policy

This PR includes:
Changes

The possibility of having two models in order keep the Front Web working -> AggregationOldPoliciesModel

The new model that it will be used in the workflow -> WorkflowPoliciesModel

This two models will be parsed into a common model -> Common Policies Model

Fixed a bug when the time dimension field in a policy was a DateType, before it didn't understand the new way to define the granularity (30s, 2h, etc) because they were set by default.

Bug of the front that when the user wanted a granularity of 5,10 or 15 seconds it wasn't working.

This changes only applies to the Cube definition in the policy. To specify the time dimension that you want to use, you have to add the "precision" and the "computeLast" value like in the example below.

The precision field is the granularity you want to add the data with.
The computeLast field is the time that your data will be available before it expires.
The checkpointEvery is the frequency to trigger the checkpoint.
If you don't specify the "precision" and the "computeLast" it will aggregate without time.
Now they look like this:
"cubes": [
    {
      "name": "testCube",
      "checkpointEvery": "1h",
      "dimensions": [
        {
          "name": "product",
          "field": "product"
        },
        {
          "name": "timestamp",
          "field": "timestamp",
          "type": "DateTime",
          "precision": "30s",
          "computeLast": "1h"
        },
        {
          "name": "price",
          "field": "price"
        }
      ]

To aggregate without time, the cube will look like this:
"cubes": [
    {
      "name": "testCube",
      "checkpointEvery": "1h",
      "dimensions": [
        {
          "name": "product",
          "field": "product"
        },
        {
          "name": "price",
          "field": "price"
        }
      ]

Test
All passed
Test-AT passed

Closing this PR. It goes to branch feature/policy-refactor


Sparkly Pixels (NTSC) and Horizontal Glitches (PAL)

I'm aware that others have reported these kind of issues and that investigations led to various possible solutions.  However, I'm not clear as to what the current recommendation(s) are with regard to the issues that I'm currently experiencing.

C64 Fat Breadbin with 250407 motherboard
Custom VIC-II2 NTSC/PAL mod installed with the following VIC-II chips:
- MOS 6567R8 (NTSC) with heatsink
- CGS 6569R5 (PAL) with heatsink
C64 Video Enhancment bought from videogameperfection.com.
- Firmware updated to v2.9

NTSC
When in NTSC mode the system looks great when first powered on - nice and clear and stable.  However, after a few minutes the image starts to exhibit what I think has been described as sparkly pixels and this gets worse the longer it is on.  It seems to reach a peak of awfulness and then a vertical bank of flashing blocks appears towards the left side of the screen.  While the sparkling doesn't get any better or worse from this point, the flashing blocks come and go every few minutes.

  Ignore the moire effect which is an artifact of my poor camera.
https://youtu.be/IfwMiD150iY
PAL
When in PAL mode the image is stable for much longer than when in NTSC mode.  However, after about 10 minutes it does start to exhibit some bad behaviour.  In this case the sparkly pixels seem to be more like single pixel high horizontal glitches.  These do get a little worse with time but at their worst they are much less awful than the sparkly pixels in NTSC mode.
Here's a video showing the PAL mode glitches:
https://youtu.be/kahJh_lod0g

Okay, after lots of reading of the issues that seem to be related to this I've decided to give the pixel clock mod a try.  Before I do though I do have a couple of questions:

Is it critical to use a resistor that is exactly 100 ohm with the pixel clock mod? The only ones I have readily to hand are some 100 ohm resistors with a 10% tolerance that measure 99 ohm. I can't imagine that this only make any difference but just want to check beforehand.
Am I correct in assuming that it really doesn't matter if the pixel clock wire connects to the input of FB17 instead of the output? This is what @tyristori did in Issue #38 but again can't imagine that this makes any practical difference either way.

I see you already found the relevant issue thread already. I would have recommended the pixel clock mod anyway.
But I am not sure how this works together with your VIC selectior board.  Maybe there is something happening with the clock generator of this board that now causes issues with the component mod. I am also a bit curious on how you actually stacked this all together.

Here's the custom VIC-II2 board I created which allows your video adapter board to be no higher than the VIC-II chips:

And here it is installed (I've since added heat sinks to the VIC-II chips):

Okay, I completed the pixel clock mod and was wondering what are good stress tests for stability.  I've seen others mention some demos, are there any particular ones that can be recommended to try?

Hmmm.  It would seem that the pixel clock mod has likely fixed the issues when I'm in PAL mode as I left the system on for 10 minutes and saw no issues.  I really still need to stress test this with some appropriate demos though so looking for suggestions.
However, when I switch to NTSC mode the screen has now shifted down and I get changing garbage in the active screen area.  Here's a video of the problem:
https://youtu.be/_bmP3z4p6Q8
Here's a picture of my pixel clock mod before I installed the VIC-II2 board.  Note that I completely removed the SN74LS629N oscillator and installed an unpopulated socket.

This motherboard was originally an NTSC board and I know that the circuitry around the clock and VIC-II is slightly different between NTSC made boards and PAL made boards.  Might these slight differences be causing the problem?  Here's a table I put together some time ago:

Note that the original NTSC clock crystal (Y1) was removed as part of the VIC-II2 mod and is in effect replaced by brand new crystals located on the mod board itself with the following frequencies:
NTSC : 14.31818 MHz
PAL : 17.734475 MHz

My test of choice for PAL mode is the "EdgeOfDisgrace" demo, as it uses nearly any trick that were ever possible with the VIC-II.
With its excessive use of sprites for all imaginable purposes this also pretty well tests the compatibility with sprite DMA.
When the mod runs without problems in PAL mode with the pixel clock mid, this hints on the original clock circuit creating a wonky signal ("original" from the VIC-II2 board, that is).
The pixel clock signal from the FPGA board defaults to the frequency needed for PAL (7.88200). This will then be fed into the VIC which creates the 0.98525 MHz system clock from it.  This in turn goes back to the FPGA to drive the whole processing. Also, the FPGA checks this frequency to determine which type of system it is installed in and adjusts its behaviour accordingly. This is the reason that it does not work when you switch it to NTSC, as the pixel clock is still PAL (bypassing the whole clock circuit).
To make this whole setup to work you would also need a clean pixel clock compatible with NTSC (8.18MHz). Incidentially, the FPGA board would actually produce this clock frequency if it were somehow triggered to do so. This trigger is a detection of an an actualy NTSC CPU clock in its input. But this of course will not happen as long as the VIC is running with the PAL clock also.
Maybe I can modify the FPGA firmware to switch the default pixel clock output to NTSC triggered by some input pin. You could probably take the necessary mode selector signal from the U31 socket.  But I have to see if I can re-purpose any existing pins on the FPGA board.

After second consideration, the best approuch for your setup is to actually tackle the real issue and get the clock generator straight. When you have an oscilloscope, you should be able to see that the pixel clock is very non-regular. This is an effect of how the MOS 8701 works and how it creates the pixel clock from the 4x subcarrierfrequency without using a PLL.
There have been some projects to improve this matter, using proper PLL circuits, but I don't know if this would work when switching between PAL and NTSC.
This one does something like that:
https://www.youtube.com/watch?v=ipQD7fEKG38

Also I wanted to mention, that by feeding the clock output from the FPGA into the VIC in (as you tried already) you will not get any color on the composite/s-video output on the A/V connector.

I use pixel clock mod even with my 250469 board that is very prone to crashing due to VSP bug.
The aforementioned EdgeOfDisgrace demo crashes every time without the pixel clock mod.

Yes, having a stable pixel clock seems also to cure the VSP bug.
Getting this clock from my FPGA board is a kind of band-aid, but a proper solution would replace the MOS 8701 with modern circuity entirely. The part as described at https://github.com/desaster/c64-dodgypll nearly does it. For use with a VICII2 board it would only need a possibility to switch between NTSC and PAL triggered by an electric signal. I guess adding a single transistor could already do the trick.
@desaster , do you think it feasable to make an easy-to use general MOS 8701 replacement? Ideally a plug-in replacement in a form factor to fit all main boards. I think there would be quite some users that would be happy just to get rid of the VSP bug.

I've heard that the SRAM based memory replacements also cure the VSP bug.

I actually had an issue with my home-made PLL replacement, since the board
was too large to fit alongside with the VIC-II adapter board.
However, in general it should work, but I'd probably recommend getting some
of the commercially available boards. They also support NTSC & PAL afaik.
My github project exists mainly to make the information open source, and
could use some improvements on the actual board design.
On Thu, Dec 17, 2020 at 12:32 PM c0pperdragon<EMAIL_ADDRESS>wrote:

Yes, having a stable pixel clock seems also to cure the VSP bug.
Getting this clock from my FPGA board is a kind of band-aid, but a proper
solution would replace the MOS 8701 with modern circuity entirely. The part
as described at https://github.com/desaster/c64-dodgypll nearly does it.
For use with a VICII2 board it would only need a possibility to switch
between NTSC and PAL triggered by an electric signal. I guess adding a
single transistor could already do the trick.
@desaster https://github.com/desaster , do you think it feasable to
make an easy-to use general MOS 8701 replacement? Ideally a plug-in
replacement in a form factor to fit all main boards. I think there would be
quite some users that would be happy just to get rid of the VSP bug.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/c0pperdragon/C64-Video-Enhancement/issues/53#issuecomment-747354761,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAE2FEK4UQESVADSFPLHEFLSVHM4DANCNFSM4U5DGFIQ
.

My test of choice for PAL mode is the "EdgeOfDisgrace" demo, as it uses nearly any trick that were ever possible with the VIC-II.
With its excessive use of sprites for all imaginable purposes this also pretty well tests the compatibility with sprite DMA.

Great - I'll give that a go later today and will report back.  Am I right in thinking that this is a PAL only demo?

The pixel clock signal from the FPGA board defaults to the frequency needed for PAL (7.88200). This will then be fed into the VIC which creates the 0.98525 MHz system clock from it. This in turn goes back to the FPGA to drive the whole processing. Also, the FPGA checks this frequency to determine which type of system it is installed in and adjusts its behaviour accordingly. This is the reason that it does not work when you switch it to NTSC, as the pixel clock is still PAL (bypassing the whole clock circuit).

Thanks - that really helps me understand better what's going on.

To make this whole setup to work you would also need a clean pixel clock compatible with NTSC (8.18MHz). Incidentially, the FPGA board would actually produce this clock frequency if it were somehow triggered to do so. This trigger is a detection of an an actualy NTSC CPU clock in its input. But this of course will not happen as long as the VIC is running with the PAL clock also.

But the VIC-II2 PAL/NTSC mod board not only switches between a PAL VIC-II and an NTSC VIC-II but it also switches between the appropriate crystal oscillators.  So, when the NTSC VIC-II is selected the crystal oscillator selected is one running at 14.31818 MHz.  The mod also switches the motherboard NTSC/PAL jumpers appropriately.  So, when the NTSC mode is selected this basically reverts the motherboard back to a stock NTSC and disconnects the PAL crystal oscillator.  So, shouldn't this set the CPU clock to NTSC and trigger the FPGA to output an NTSC pixel clock?
Here's a schematic of the VIC-II2 mod that I redrew when designing my custom board in case this helps:
Red Board Schematic - wComponent v0.1.pdf
I have an oscilloscope so can probe any lines as necessary.

After second consideration, the best approuch for your setup is to actually tackle the real issue and get the clock generator straight. When you have an oscilloscope, you should be able to see that the pixel clock is very non-regular. This is an effect of how the MOS 8701 works and how it creates the pixel clock from the 4x subcarrierfrequency without using a PLL.
There have been some projects to improve this matter, using proper PLL circuits, but I don't know if this would work when switching between PAL and NTSC.
This one does something like that:
https://www.youtube.com/watch?v=ipQD7fEKG38

But my board is the earlier 250407 which has the four chips in the clock circuitry rather than he single MOS 8701 in the later 250425 boards.  Is there a modern replacement for the pixel clock generator on the 250407 boards?

Also I wanted to mention, that by feeding the clock output from the FPGA into the VIC in (as you tried already) you will not get any color on the composite/s-video output on the A/V connector.

Yes, that's no problem - I have no desire to use the composite/s-video output.  The analog outputs of both of my VIC-II chips are rather poor hence my wanting to use your video mod.  The NTSC one has awful jail bars that luma fix failed to make a dent in, and the PAL once has checkerboarding with red and green fringing around characters.  With your mod these issues are gone (other than the NTSC pixel clock problem).

Ah, yes. I didn't realize that your board has the old-style clock circuit. This is indeed extremely bad, even worse than the already pretty awful MOS 8701. So you really need a better clock. The only possibility I see now is indeed to get it from the FPGA.
Actually it would be quite simple to produce NTSC clock or PAL clock depending on some input pin.  But I do not have any input pins left. I already re-purposed 2 pins from the JTAG header to trigger compatibiltiy with the 656756A VIC-II and to turn on a specific high-contrast palette for use with the RGBtoHDMI upscaler.
Annoyingly, the FPGA has plenty of pins left, but they are not exposed anywhere on the board. You would actually have to solder a wire to one of the 0.5mm pins!  Also I don't want to modify the firmware in some incompatible way that would break other user's installation.
But maybe I have no other idea than to create a modified firmware just for your use case.
For this, the FPGA would probably need access to a jumper connection, so to speak. As the VICII2 board normally sets the mode input of the MOS 8701, this should be possible.  Specifically I would need some line that is set to GND in one mode and left open (so the FPGA boad can pull it to high) in the other mode. Having this, I could make a custom firmware that expects this signal on the JTAG pin 5 to determine the initial pixel clock frequency.

Ah yes, I see now.  This is kind of a Catch 22 situation with the FPGA using the system clock derived from pixel clock to determine which type of system it is installed in, but using the pixel clock mod forces this to always be PAL.  I'm a little slow on the uptake here but am beginning to understand.  Thanks for your patience.
So, what is needed is a custom alternative way of telling the FPGA which type of system it is installed in and this is where your jumper concept is coming from.  Could this be derived from the position of the motherboard NTSC/PAL jumper?  This would be ideal as the VIC-II2 mod already includes a relay switch that changes that jumper setting.  So perhaps installing a wire between FPGA pin 5 and jumper point E1?  E1 is already pulled high (+Vc) when in PAL mode and pulled down to GND when in NTSC mode.  Could this be what is detected by the FPGA?:

Something like this would be needed, but it is still not ideal, because the FPGA input pins can only work with 3.3 and would possibly be damaged if directly feeding 5V into them. That's way I asked about a way to have a signal that is either grounded or left open, so the FPGA can use its pull-up resistors to bring the voltage to 3.3 volts. These pull-ups are already present on pin 5 of the JTAG inputs. I don't know how your VICII2 interacts with your mainboard, but I guess you could somehow manage to make it behave in the required way.
Specifically if you can make it so that for PAL mode the JTAG pin 5 gets grounded, and for NTSC mode, the pins is left open, then I guess I can make the firmware in a way to be still compatible  with previous use cases  (mainly the 656756A setup).

Oh, no,, this does not work either. This would break compatibility with PAL setups that use the pixel-clock mode.
I need another solution still to make do with the limited amount of input pins (I really should have left more room for expansion here).

Understood.  The VIC-II2 mod includes a relay switch that connects E1 to either E2 (PAL) or E3 (NTSC).  If I were to disconnect the VIC-II2 mod board from E2 then when in PAL mode E1 would be left open and in NTSC mode E1 would be grounded.   Would that work?
Seeing as I have now removed U31 and bypassed the rest of the clock circuitry with the pixel clock mod, does that now mean that the Y1 crystal oscillator is now redundant and not needed?

Oh, no,, this does not work either. This would break compatibility with PAL setups that use the pixel-clock mode.
I need another solution still to make do with the limited amount of input pins (I really should have left more room for expansion here).

Nooooooooooo :(

Maybe this could work (a totally crazy hack now):
Set up your circuit so that the JTAG pin 5 is either left open (for PAL) or connected to the pixel clock output from the FPGA (for NTSC mode).  The FPGA can easily detect such a situation and switch over to NTSC frequencies.
Yes, I think this should actually work.
About your previous question: The Y1 is not used any longer as is the rest of the clock circuit.

Maybe this could work (a totally crazy hack now):
Set up your circuit so that the JTAG pin 5 is either left open (for PAL) or connected to the pixel clock output from the FPGA (for NTSC mode). The FPGA can easily detect such a situation and switch over to NTSC frequencies.
Yes, I think this should actually work.
About your previous question: The Y1 is not used any longer as is the rest of the clock circuit.

Thanks - that's what I thought about Y1.  So the PAL/NTSC motherboard jumpers are also now redundant.  So this allows me to remove one of the VIC-II2 mod relay switches (associated with Y1) and one half of another (associated with the PAL/NTSC jumper) can now be used to provide the input to JTAG pin 5 (open = PAL : pixel clock = NTSC).
So, do you think that this "hack" will work with the current firmware, or will custom firmware still be required?
Is there a convenient spot on the top of the FPGA mod where I can solder a wire to JTAG pin 5?  Or would I be better simply using a wire with a slide on connector that I can then easily remove if I ever want to flash the firmware?
BTW - thank you so much for all your help with this.  Personally, I think that it will be awesome to be able to switch between PAL and NTSC modes with your video mod.

I definitely have to modify the firmware. But I guess I can make it in a way to still keep it compatible with any existing installations. So it is possible for anyone to update to this firmwre without ill effects.
I would recommend something detachable for the wiring to pin 5.
But I need to make the firmware changes and see if it still fits in the the FPGA, because it is already about 99% full or so. Will let you know soon.

But I need to make the firmware changes and see if it still fits in the the FPGA, because it is already about 99% full or so. Will let you know soon.

Fantastic - thank you 👍

Abracadabra.
Please give the 2.10beta2 firmware a try:
https://github.com/c0pperdragon/A-VideoBoard/tree/master/c64mod/firmware
If this works, it will become new 2.10 release.

Abracadabra.
Please give the 2.10beta2 firmware a try:
https://github.com/c0pperdragon/A-VideoBoard/tree/master/c64mod/firmware
If this works, it will become new 2.10 release.

Wow - that was quick 👍   I'll try and do the firmware update and hack tomorrow, if not it will be over the weekend.  I'll let you know how I get on.

I have changed the firmeware a bit more to now also support the pixel clock mod in conjunction with a 656756A chip. For you this should be the same, but please use the firmware 2_10_beta3 instead of the beta2 so I can confidently release this.

Absolutely awesome - it works 👍 👍 👍   Thank you so much for all of you help and for being so incredibly quick with the beta firmware.  I've only hooked up JTAG pin 5 with a manual detachable wire for now, but seeing as it works I'll now revise my PCB design so that the JTAG pin 5 signal passes through one of the relay switches on my PCB and so automatically sets it open or to the pixel clock.
In PAL mode I've put the machine through its paces with the Edge of Disgrace demo and also the Lunatico demo and it has performed flawlessly.  Unfortunately, neither of these demos work on an NTSC system so I tried a bunch of older (less demanding) NTSC demos I had and they all worked perfectly.  No signs of ANY glitches whatsoever.  The quality of the image is very close to the HDMI output of my Ultimate 64 which is a huge testament to how good your video mod is.
Again, thank you for your incredible help with this.  Once I get the a new PCB designed and installed I'll let you know and will post some pictures here.
Oh, one question I do have.  Is the reason for losing colour on the composite/s-video output because there is now no colour clock having removed U31?

The VIC-II needs the NTSC/PAL subcarrier frequency input in order to produce the correct color signal. In your board, this signal was produced by U31, as you have guessed.
I think you could restore the functionality of U31 in parts to at least produce the subcarrier, using the Y1. But this may collide with your plans to rework the VICII2 board.
Anyway with the subcarrier frequency generated independently of the pixel clock (which now comes from the FPGA), your analog color output will then have the dreaded dot crawl effect that plagues the ZX Spectrum, because both clocks are no longer in a harmonic relationship. So this is probably of no use anyway.

About your PCB: Do you really plan to make a new PCB just for this small change? Maybe you can just rewire some things on your C64 main board to achieve the same effect?

@ikrananka any chance you can put your PCB KiCAD/Gerbers up for those of us interesting in building the same?

I have another idea: When you already change your PCB, why don't you fix the unstable clock issue right there and then?
When integrating a proper clock generator (as being used by https://github.com/desaster/c64-dodgypll) you can make a super-convenient VICII2 board that also fixes the clocking issue on its own, even if not having the component video mod.
Installation of this will also become very easy as you will not have to modify the C64 board in any way. Just plug in the VICII2 board that will ignore the incomming clock signal to substitute it with its own. And you can probably also leave away at least one of the relais (maybe two, but I am not sure here).

And as this then will be the most proper solution possible, color will also work on the analog video ports.

For the fastest, and cheapest solution using your current VICII2 PCB, you could do the following thing:

Remove both quarzs from the VICII2 board and insert a wire bridge instead of the NTSC quarz (leave the PAL quarz open).
On the C64 main board connect the FPGA's pixel clock signal to one side of the quarz connector (best on the side where C70 is located). Connect the other side of the quarz connector to pin 5 of the FPGA JTAG header (maybe with just a detachable male-to-female jumper link)

You could make the installation extra "funny" by doing this instead of the above step 2:
2. Put a wire bridge between pin 9 and pin 12 of the U31 socket  (thus routing the FPGA's pixel clock to the quarz connector)
3. Connect the other side of the quarz connector (where C70 is) to the JTAG pin 5 (solder the wire on side, have a female connector on the other)

@c0pperdragon Thank you for all of your suggestions.  Lots to think about and so likely a project I'll work on over the period between Christmas and New Year.  I would like to make the design freely available to others hence my desire to redesign the PCB and also to test it in my C64.
@Obiwantje Yes, I do plan on making the files freely available after I have completed the redesign and testing.

I have another idea: When you already change your PCB, why don't you fix the unstable clock issue right there and then?
When integrating a proper clock generator (as being used by https://github.com/desaster/c64-dodgypll) you can make a super-convenient VICII2 board that also fixes the clocking issue on its own, even if not having the component video mod.

I've just been taking a look at that PLL 8701 replacement.  Unfortunately, in the video, there's no mention if the clock signal is cleaner and if so what it now looks like.  Also the setting of PAL and NTSC seems to be a manual affair.  However, over on the Hey Birt! channel there is a different 8701 replacement where he explicitly compares the pixel clock between the original 8701 and his replacement.  His one also autodetects if the system is PAL or NTSC so that's handy.  Would be great if you could take a look at the pixel clock characteristics he shows and comment if this would be suitable for use with the component video mod to avoid the sparkly pixels / horizontal glitches on those boards that use an 8701?
https://youtu.be/e5o8c656j3Q?t=1418

Yes, the clock signal looks perfect.  Far better than what the 8701 or your current circuit would produce (of course this is the whole point here).
Unluckily for you, this replacement board will not match your C64, because you have one of the very first board that do the clock generation differently. So you could follow one of my suggestions to modify your own PCB to include the clock circuit as well. But be aware that the PLL chip  is quite a tiny part (0,65mm pin pitch). It actually takes some practive to solder this.

Also with the availability of this brilliant 8701 replacment board, there is basically no need for a different solution for the vast majority of use cases. So there would be not much benefit for other users in include the clock IC on your board design.
The only real benefit for you specifically (when using the PLL chip instead of using the clock signal from the FPGA board) is that the analog video signal will carry color.

Yeah. I was just thinking about if this was good idea or not and I have to agree with you that with the availability of the 8701 replacement there is negligible benefit of including this on my board.  I guess with the 250407 motherboards, with the old clock circuits, the benefit of having an 8701 equivalent on my board would be advantageous.  However this adds cost, size and complexity to my board when an easy alternative already exists, i.e. your pixel clock from the FPGA.  As the only real benefit of putting a clock circuit on my board is to add the colour clock signal back in, I just don't see this as sufficient justification.  From my own personal perspective I'm really not interested in the original analog outputs.  Both of my VIC-IIs produce horrible analog images (at least on LED monitors) and I will never use them.  After all, that's why I wanted to install your component mod in the first place.
Now that said, I wonder if there's a simple way to take your pixel clock and generate a colour clock from it???  Just thinking aloud and not really going to pursue it unless it were simple to do.
So, at the moment I'm going to simply focus on revising my board to incorporate the pixel clock PAL/NTSC switching that I've currently got manually hacked together.
BTW - have you seen the prototype VIC-II FPGA prototype that Randi Rossi is developing https://youtu.be/HzgjMjqpOC8?  Looks like this has the potential to not only provide a VIC-II FPGA replacement, but incorporates it's own PAL and NTSC clock circuits and is software switchable between PAL and NTSC.  Plus with a breakout board it also has HDMI output.  The future is quite exciting!!!!!

This  VIC-II replacement project looks pretty nice. I am curious if it may eventually come to a stage where it is actually usable and what the price would be. Specifically generating a proper standard-conform HDMI signal is not easy.
About your specific use case on hand:  Generating the color clock (4x PAL/NTSC subcarrier frequency) from the pixel clock is pretty difficult and basically impossible without a proper PLL chip.
But if you are OK with basically any color signal, you could still use all the clock circuitry in your machine to just create the color clock, and take the pixel clock from the FPGA. This would lead to the "dot crawl" effect that is known from the ZX Sectrum.
For that, leave your PCB completely unchanged (thus it will connect the correct quartz to the clocking circuit) and do some very special rewiring on the C64 main board:

Leave the pixel clock wire from the FPGA to the main board exactly as it is.
Re-insert the U31 chip, but lift pin 7 so it does not connect to the socket (this is the dot clock output which is no longer used)
Remove the E2 female header (which you have  previously installed to connect to the VICII2 board)
Cut the trace from E3 to the GND and connect E3 to the pin 5 of the FPGA JTAG header instead.
Connect the pixel clock from the FPGA to E1 (there is convenient via near the "PAL" marking)

This now should either leave JTAG pin 5 open (in case of PAL) or connected to the pixel clock (for NTSC).

One additional remark: The pixel clock generator on the C64 board will now go completely nuts because the PAL/NTSC input is suddenly carrying a clock signal. But as you don't need it anyway that should be no problem.

I just found a problem with the solution which you need to fix with one additional step:
6. Cut the trace between E1 and the other ICs on the C64 board. As these ICs are LS logic, they will draw quite some current on their input pins, so they will probably overcome the weak pull-up on the JTAG input, causing the FPGA to permanently run in the wrong mode.

Happy New Year :)
Now that the holidays are over, time to get back to this project.  I've had a good think about your suggested modifications but am just not happy about a solution that requires traces to be cut.  I'm definitely going to do some redesign of my PCB so I'm now thinking about the following:

Remove FB17.
Move the pixel clock wire from the FPGA to the main board on the opposite side of where FB17 was (this now allows me to reinstall U31 while still using your FPGA for the pixel clock).
Reinstall U31.
Keep the PAL/NTSC crystals on the VIC-II2 board as-is and associated relay (these will feed U31 to generate the appropriate colour clock as per the original VIC-II2 design).
Remove the PAL/NTSC jumper parts of the VIC-II2 design (E1,E2,E3 + relay) as these are only used on the pixel clock generation side of the circuit and are now redundant.
Connect JTAG pin 5 to one of the relays on the VIC-II2 that will either leave it open or connect it to the pixel clock.

I had a thought regarding the "dot crawl" on the original video output.  Might adjusting R27 be able to compensate for that to get the pixel : clock frequency multiplier spot on, or is the dot crawl more a function of the two frequencies being out of phase (which I believe adjusting R27 wouldn't help with)?

Happy New Year :)
Now that the holidays are over, time to get back to this project.  I've had a good think about your suggested modifications but am just not happy about a solution that requires traces to be cut.  I'm definitely going to do some redesign of my PCB so I'm now thinking about the following:

Remove FB17.
Move the pixel clock wire from the FPGA to the main board on the opposite side of where FB17 was (this now allows me to reinstall U31 while still using your FPGA for the pixel clock).
Reinstall U31.
Keep the PAL/NTSC crystals on the VIC-II2 board as-is and associated relay (these will feed U31 to generate the appropriate colour clock as per the original VIC-II2 design).
Remove the PAL/NTSC jumper parts of the VIC-II2 design (E1,E2,E3 + relay) as these are only used on the pixel clock generation side of the circuit and are now redundant.
Connect JTAG pin 5 to one of the relays on the VIC-II2 that will either leave it open or connect it to the pixel clock.

I had a thought regarding the "dot crawl" on the original video output.  Might adjusting R27 be able to compensate for that to get the pixel : clock frequency multiplier spot on, or is the dot crawl more a function of the two frequencies being out of phase (which I believe adjusting R27 wouldn't help with)?

I guess your modifications give the same effect as my proposals. Maybe no need to redesign the PCB, but you can get away with botching wires to existing solder contacts and by cutting away some connector pins.
The dot crawl is always present when the pixel clock is not in a harmonic relation with the color clock.
In your case you take the pixel from from the FPGA and the color clock is generated in some way from its own independent crystal. So the phases will always drift apart in some way.

I guess your modifications give the same effect as my proposals. Maybe no need to redesign the PCB, but you can get away with botching wires to existing solder contacts and by cutting away some connector pins.
The dot crawl is always present when the pixel clock is not in a harmonic relation with the color clock.
In your case you take the pixel from from the FPGA and the color clock is generated in some way from its own independent crystal. So the phases will always drift apart in some way.

I want to redesign the PCB anyway as I believe some others may also want to do your mod with my VIC-II2 board.
One thing I'm curious about though is how likely it is that after installing your component video modification users will experience the sparkly pixels/horizontal glitches that then needs the pixel clock mod to fix.  I'm just curious to know if this is something that the majority are likely to experience or is it something rarer than that?

I want to redesign the PCB anyway as I believe some others may also want to do your mod with my VIC-II2 board.
One thing I'm curious about though is how likely it is that after installing your component video modification users will experience the sparkly pixels/horizontal glitches that then needs the pixel clock mod to fix.  I'm just curious to know if this is something that the majority are likely to experience or is it something rarer than that?

I thing this may be a pretty common problem with this specific clock generator circuitry.
Especially when using FPGA firmware version prior to 2.9. From then on the firmware tolerates the bad clock circuit a bit better, but it may still not be good enough.

I thing this may be a pretty common problem with this specific clock generator circuitry.
Especially when using FPGA firmware version prior to 2.9. From then on the firmware tolerates the bad clock circuit a bit better, but it may still not be good enough.

So, for those of us who have a 250407 board (NTSC) here are the instructions to eliminate the horizontal glitches if I understand correctly:

Upgrade the firmware to 2.10 or later
Cut the right leg of FB17 on the C64 and lift it a bit or just remove it
Attach a 100 ohm resistor to the right side of R24 (as you look at it from the front after installation) on the FPGA board
Connect the other side of the resistor to both pin 5 on the JTAG pin header of the FPGA board and the pad on the C64 where you cut FB17

Here is what mine looks like and it is working perfectly now.

Yes, you did it prefectly right
The main reason for this strange way of wiring up pin 5 of the JTAG header is the lack of additional input pins into the FPGA. So I had to make pin 5 accept 3 different settings:  low / high / toggling.  As it turns out now, this works pretty fine.

Just a heads up that I will be getting back soon to redesigning my custom VIC-II2 PCB to accommodate the component mod fixes.  Been busy with another project but wrapping that up over the coming weeks.

BTW - I made a video about this project and using it with the RGBtoHDMI board. It shows this workaround to fix the glitches. Hopefully, that will help someone else if they run into the same problem. It should be up tomorrow or the next day. https://youtu.be/oo_gWjK-gGw

I watched your video and the presentation is really very good, I wrote a little comment to clarify the palette reprogramming a bit.

Thank you for clarifying!!! I was wondering about that.


Future plans of HybridWebView ?

Hi, Elon!
At Ventla we decided to create a full-fledged Chat component in a React JS project and integrate it into our MAUI Mobile and Blazor Web projects using your amazing HybridWebView.
But we are concerned because this package stable version is not released yet. So we just want to know whether HybridWebView will become more mature in the near future? Or any other suggestion you want to give us is welcome.

Good news! We plan to make HybridWebView an official part of .NET MAUI. See these issues here: https://github.com/dotnet/maui/issues?q=is%3Aopen+is%3Aissue+label%3Aarea-controls-hybridwebview

Congratulations Eilon!  That's a huge compliment to all your work.  And thanks from my side too.  I Couldn't do what I'm doing without it. 👍

Congrats Eilon 🎉 and thanks for the update. We're excited to try .NET 9 stable version whenever it's ready. 😊


Add node support

Adds nodeCanvas prop.
Updates download method

method now returns a promise, that will resolve with the image URI
buffer option that returns a buffer instead of a URI (only if using nodeCanvas)
skipDownload option if someone only wants the URI, and not have the client download the image.

Added unit test
Updated Readme

closes #9
closes #39

Could you just add the Canvas type in QROptions so that people know what they need to pass in without looking at the source?
QROptions.ts:
add import {Canvas} from "canvas";
change the Options type to: nodeCanvas?: Canvas;
Sorry didn't want to create a new PR for this small change

Can do when I'm at my computer next

I implemented the change in my local copy of the module and in the examples it worked fine and the tests passed fine as well, but when I tried using it in my actual project I get an TS error:
Type 'typeof import("d:/.../node_modules/canvas/types/index")' is missing the following properties from type 'Canvas': width, height, type, PNG_NO_FILTERS, and 12 more.

@mrfrase3 Would love to use this. I'm trying to run the example in your modified README. I created a folder and installed canvas and this PR. Then in another file I pasted in the JS example and tried to run it, but got: Error: Cannot find module 'qr-code-styling/lib/qr-code-styling.common.js' Are there any other steps?

that file is made when this package is deployed for release.
It looks like a recent update to add SVG support has made a lot of my changes to the download method redundant as getRawData seems to be preferred, although it needs to be updated to return a buffer instead of a blob on node.
I'll take a look at merging this with the current master build and making the changes. I would not recommend using this until then.

@randomprogramming I've redone this to take in the latest updates, with tests and not using the devil's any :smiling_imp:

might also @kozakdenys

Thanks again @mrfrase3, I've forked the repo, attempted to reimplement this PR, and published a scoped version of the package. FYI with the new example usage, I'm getting UnhandledPromiseRejectionWarning: ReferenceError: Image is not defined as well as the printout of the super long base64 from imageToBlob. Perhaps related to the error, I didn't end up with a test.png file. test_blob.svg looks just fine, and test.svg has that broken image link icon in the middle (which I think you said in the README might happen).
I should also note that it seems to be failing one of the tests now. Hopefully I didn't miss something while copying off the changes of this PR into each file. It seems to be the final test: Test QRCodeStyling class › Compatible with jsdom . The output base64 URI's are almost the same, but on the received is missing the last 4 characters.
Hope this helps and isn't just some mistakes I've made while copying these changes in.

If all you want is the qr-code-styling.common.js file, I'd suggest just cloning my branch and building it, instead of forking the main repo and copy-pasting the changes.
The 4 characters sounds line your IDE put a newline at the end on the svg file when you copy-pasted it.
Not sure about the Image is not defined error, should only happen if nodecanvas doesn't exist.

Ok cloning and building worked perfectly. I don't know how to google some of this stuff, so thanks for the help!

@mrfrase3 @charles-goode
How do I use this in my node server? I've tried
npm i kozakdenys/qr-code-styling#pull/43/head
or
np[m i https://github.com/mrfrase3/qr-code-styling#node-support
But it just gives me a mostly empty qr-code-styling folder with the LICENSE, package.json, and README.md files, nothing else.
I did go into this folder and run npm i and then npm run build but get errors building. Did I miss a step

@vadimluminous For one, I probably used yarn like yarn add <user>/<repo>#<id>/head. Its been a few weeks so I don't really every detail, but judging my earlier comment, I must have had success with simply running yarn run-script build. You may have success simply using what I published: @charles-goode/qr-code-styling where the import would be
const { QRCodeStyling } = require('@charles-goode/qr-code-styling/lib/qr-code-styling.common.js');
const nodeCanvas = require('canvas');
const { JSDOM } = require('jsdom')

On my fork I also developed support for an extra setting for the cornerDots: extra-rounded to match extra-rounded cornerSquares

Thanks for responding @charles-goode
How do you get the /lib/ folder? I tried running a build command and get many errors like this
`ERROR in ./src/constants/cornerDotTypes.ts 6:2
Module parse failed: Unexpected token (6:2)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
|   dot: "dot",
|   square: "square"

} as CornerDotTypes;
|
@ ./src/index.ts 3:0-56 13:0-22:2`

I'm not too familiar with actual packages, I just use them.

@vadimluminous /lib/ is the output of a successful build. This has something to do with webpack which is a build library. Make sure that you run yarn install to build all of the dependencies before you try to build the actual package. Your error seems to indicate you have not installed a TypeScript loader for webpack which is one of the devDependencies in the package.json (its named ts-loader). FYI I'm also really unfamiliar with this stuff, and this was my first time getting anything like it to work which is why I can't be of much instructional help.

@charles-goode
So odd, I did install all packages, and verified that node_modules/ts-loader is in there.
Thanks for responding though!

@charles-goode
Ended up figuring this out, will list my process for anyone in the future
Runnin npm i to the pull request or mrfrase3s branch did not work.
I had to clone mrfrase3s node-support branch
Then I put the files into my root node folders /custom-scripts/qr-code-styling/
Which includes the src and package.json plus all the other files in there.
For deploying I use this npm run script
		"install:a": "cd custom-scripts/qr-code-styling && npm install && npm run build",
and
		"postinstall": "npm run install:a && npm run build",
Alls good from here on.
Thank you @mrfrase3 for this package modification!!!

I've forked @mrfrase3's repo and modified it so it can be built and installed directly from github.
Just add "qr-code-styling": "github:mackbjon/qr-code-styling#node-support", to your package.json and npm i.
Huge thanks to @mrfrase3 for making this compatible with node!

Thanks for this, we hope to merge soon

Hi, I am having problems with everyone's solution to this.  The repos you made (@mackbjon, @charles-goode) give me the same error:
ReferenceError: self is not defined     at Object.<anonymous> (C:\Users\...\node_modules\qr-code-styling-node\lib\qr-code-styling.js:1:208)

@kuttz-dev perhaps this is related https://stackoverflow.com/a/64639975/12026421

Oh, it looks like it may be. That means that now I need to learn webpack in order to compile it my self. Thanks @charles-goode .

I wrote a comment on the following issue: https://github.com/kozakdenys/qr-code-styling/issues/9#issuecomment-977857608
Where and how could I share my code ? (All the test unit will fail)

I got so pissed off because this wouldn't work properly in node.
You have a complete, installable NPM package on my repo - https://github.com/oblakstudio/qr-code-styling
You'll need to import the files like this:
import * as qrs from<EMAIL_ADDRESS>const nodeCanvas = require('canvas');
const { JSDOM } = require('jsdom');```

I'm gonna rewrite this lib for nodeJS using native functions and modules, without this jerry-rigging

Can we add node support for this library?
Really waiting for it.

If all you want is the qr-code-styling.common.js file, I'd suggest just cloning my branch and building it, instead of forking the main repo and copy-pasting the changes.
The 4 characters sounds like your IDE put a newline at the end on the svg file when you copy-pasted it.
Not sure about the Image is not defined error, should only happen if nodecanvas doesn't exist.

I am also getting the Image is not defined error but If I set it to "svg", It just kills the whole process on
const buffer = await qrCode.getRawData('svg');
console.log(buffer);

The console log buffer never prints. It just ends the program trying to get the Raw Data.

@kozakdenys Please merge and release new version.

If somsone is looking for an alternative, I was in the need for this as well and created my own version only supporting node via skia-canvas, bumping dependencies and incorporating #110
https://github.com/KilianB/qr-code-styling-node

@KilianB Seems better than what I made. PRs welcome? :)

I installed styled-qr-code compiler is not able to resolve the module

Hello,
Do you have an example of integration with Sveltekit?
I always get the message "self is not defined" with import QRCodeStyling from "styled-qr-code";
Thanks

Hey @kozakdenys, thanks for the merge. I was coincidentally talking about how long this has been open earlier today, looks like I jinxed it.
For those that see this, I kinda went silent on this as I actually moved away from generating QR codes on the server side as it was cheaper from a resource perspective and also way faster to just use this package in the browser.
next up, cloudflare worker support :wink:

Hi @mrfrase3, thank you for this PR and contribution! I am so sorry I was missing so much and this PR was here without my intention. I just released these changes to NPM 🎉


The bot repeat the same route when "move_to_spin" is false

Expected Behavior
Go to explore an search pokemon
Actual Behavior

purple route
Steps to Reproduce
"move_to_spin": False
Other Information
OS: Win 10
Git Commit: 190640f

Increase max steps dramatically.


[zh] Update /content/zh/docs/concepts/workloads/controllers/daemonset.md

[zh] Update /content/zh/docs/concepts/workloads/controllers/daemonset.md

/lgtm
/approve


Potential issue in get_farfield_spot_size

When implementing wavefront calibration with the superpixel method, in the current code we might get this error thrown
"ValueError: zero-size array to reduction operation maximum which has no identity" when the code gets to find_centers in cameraslm. By tracing this error across the entire package, we figured out it's due to and potential mishandling with the math in FourierSLM/get_farfield_spot_size.  We can see the program is trying to calculate the spot size according to our result, basically the M matrix from Fourier calibration. And it requires taking the square root of the determinant of M. As the following, np.sqrt(np.linalg.det(M)). But sometimes we do get a negative determinant from M, so np.sqrt freaks out. I wonder if this is done on purpose. Is it okay if I just say np.sqrt(abs(np.linalg.det(M))), and it does seem to solve the problem?

Hi @Lufter, thank you for catching this. I'm away from the computer now, but your solution sounds reasonable to fix get_farfield_spot_size(). Negative determinant was likely not caught in testing. I'll take a look at it later tonight and likely do a fix on the main branch.

Sorry for the delay. Fixed in 282f97a9cc97cd72faef7b5beb7e6ff2c96ad9de . Pull request #80 pending. This issue will be closed once this is pulled.
Interestingly, sqrt(abs(det(M))) is used many times throughout the package (I searched for other breaking cases), but this was the only instance without the abs.


Discord link does not work

It seems that https://discord.gg/xZjKRaNp8b has expired. Are you still maintain a discord community?

Hi @burkovae ! Yes, the community is indeed active. I am testing the link and it works on my side and is set to never expire. While we drill down to the core, can you try this temporary link as an alternative? https://discord.gg/tCRgAbny

That's totally strange!

It tells me, that I have no permission to join.

And now I tested it from another (private) PC and it worked.

Okay, sorry, it was some strange cache invalidation on my part.

@burkovae great that it is solved!


bug: cortex-m0: vector table base address is set to zero when soc has control over where to put vector table.

Describe the bug
BlueNRG-2 has cortex-m0 architecture. As we know, this core does not have vector table reallocation hw support. Usually, MCUs with this core can select to what is mapped at address 0: RAM or Flash. This limitation is a little tweaked in BlueNRG-2 soc. It has register FLASH->CONFIG, that allows selecting where is vector table: in RAM or in Flash. Now, zephyr sets vector address to 0:
#ifdef CONFIG_CPU_CORTEX_M_HAS_VTOR
...
#else
#if defined(CONFIG_SW_VECTOR_RELAY)
Z_GENERIC_SECTION(.vt_pointer_section) void *_vector_table_pointer;
#endif

#define VECTOR_ADDRESS 0

void __weak relocate_vector_table(void)
{
#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
    !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
	size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
	(void)memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
#elif defined(CONFIG_SW_VECTOR_RELAY)
	_vector_table_pointer = _vector_start;
#endif
}
...
#endif /* CONFIG_CPU_CORTEX_M_HAS_VTOR */

Because of this, device can not work with bootloader.
To Reproduce
Currently zephyr does not support BlueNRG soc so there is no way to reproduce.

Maybe we can say that is not a bug because relocate_vector_table function is declared as __weak and it can be overwritten in soc.c like with stm32f0 SOCs. Thats what I did. I am a little bit confused about _vector_table_pointer = _vector_start; and copying vector table to RAM beggining. Both methods works... If I just do this:
void relocate_vector_table(void)
{
#ifdef CONFIG_SW_VECTOR_RELAY
	size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
	memcpy((void*)CONFIG_SRAM_BASE_ADDRESS, _vector_start, vector_size);
	FLASH->CONFIG = FLASH_REMAP_RAM;
#endif
}

or do this:
void relocate_vector_table(void)
{
#ifdef CONFIG_SW_VECTOR_RELAY
    _vector_table_pointer = _vector_start;
#endif
}

everything works... When I just set _vector_table_pointer to _vector_start everything works without selecting where is vector table with FLASH->CONFIG register. Why do I get same results?

Not sure I understand, fully, all points, but just want to try clarifying some things.
I assume, @Aukstkalnis that BlueNRG-2 is an stm32f0 SoC, is this correct?
If so, STM32F0 enables the following setting:
config CPU_CORTEX_M0_HAS_VECTOR_TABLE_REMAP
	bool
	help
	  This option signifies the Cortex-M0 has some mechanisms that can map
	  the vector table to SRAM

This setting makes the ARCH code understand that the SoC will handle the vector table relocation in  SoC configuration, so SW_VECTOR_RELAY does not need to be enabled (i.e. you can see that SW_VECTOR_RELAY depends on !CPU_CORTEX_M0_HAS_VECTOR_TABLE_REMAP). Therefore, SW_VECTOR_RELAY cannot be enabled on this SoC.
I think you are right about the weak implementation. If you see the soc.c of stm32f0x, it seems to do exactly what you refer to, that is copying the tables in SRAM and doing the necessary SoC configuration. This is done, in case the FW is loaded with a bootloader, so there does not seem to be a problem.
Relavant code is here:
/**
 * @brief Relocate vector table to SRAM.
 *
 * On Cortex-M0 platforms, the Vector Base address cannot be changed.
 *
 * A Zephyr image that is run from the mcuboot bootloader must relocate the
 * vector table to SRAM to be able to replace the vectors pointing to the
 * bootloader.
 *
 * A zephyr image that is a bootloader does not have to relocate the
 * vector table.
 *
 * Replaces the default function from prep_c.c.
 *
 * @note Zephyr applications that will not be loaded by a bootloader should
 *       pretend to be a bootloader if the SRAM vector table is not needed.
 */
void relocate_vector_table(void)
{
#ifndef CONFIG_IS_BOOTLOADER
	extern char _ram_vector_start[];

	size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;

	memcpy(_ram_vector_start, _vector_start, vector_size);
	LL_SYSCFG_SetRemapMemory(LL_SYSCFG_REMAP_SRAM);
#endif
}

Thanks. In helped and now works. But I down understand why it worked when I SW_VECTOR_RELAY was declared and I used
void relocate_vector_table(void)
{
#ifdef CONFIG_SW_VECTOR_RELAY
    _vector_table_pointer = _vector_start;
#endif
}

?

@Aukstkalnis I read the following:
config SW_VECTOR_RELAY
	bool "Enable Software Vector Relay"
	default y if BOOTLOADER_MCUBOOT
	depends on ARMV6_M_ARMV8_M_BASELINE && !(CPU_CORTEX_M0_HAS_VECTOR_TABLE_REMAP || CPU_CORTEX_M_HAS_VTOR)
	help
	  Add Vector Table relay handler and relay vector table, to
	  relay interrupts based on a vector table pointer. This is only
	  required for Cortex-M0 (or an Armv8-M baseline core) with no hardware
	  vector table relocation mechanisms or for Cortex-M0+
	  (or an Armv8-M baseline core) with no VTOR and no other hardware
	  relocation table mechanisms.

So I understand that SW_VECTOR_RELAY cannot be defined on a platform that has CPU_CORTEX_M0_HAS_VECTOR_TABLE_REMAP  enabled.

Yes, but at that moment I did not enabled CPU_CORTEX_M0_HAS_VECTOR_TABLE_REMAP.

Yes, but at that moment I did not enabled CPU_CORTEX_M0_HAS_VECTOR_TABLE_REMAP.

@Aukstkalnis this one is enabled by default on SOC_SERIES_STM32F0X

@Aukstkalnis this one is enabled by default on SOC_SERIES_STM32F0X

This is my custom soc for bluenrg because current zephyr do not have BlueNRG support, and I did not select CPU_CORTEX_M0_HAS_VECTOR_TABLE_REMAP. So the SW_VECTOR_RELAY was declared. Soc configuration:
config SOC_BLUENRG
	bool "BlueNRG"
	select ARM
	select CPU_CORTEX_M0
	select SOC_FAMILY_BLUENRG
	select BLUENRG
	select HAS_BLUENRG_HAL
	select CPU_CORTEX_M_HAS_SYSTICK
	select CORTEX_M_SYSTICK
	select SERIAL
	select CLOCK_CONTROL
	select HAS_SYS_POWER_STATE_DEEP_SLEEP_1
	select ARCH_HAS_CUSTOM_SWAP_TO_MAIN

@Aukstkalnis right, I see.
So back to your original comment:

Thanks. In helped and now works. But I down understand why it worked when I SW_VECTOR_RELAY was declared and I used

void relocate_vector_table(void)
{
#ifdef CONFIG_SW_VECTOR_RELAY
    _vector_table_pointer = _vector_start;
#endif
}

Is it possible, that application used bootloader's vector table?

If there is a bootloader, then I suppose the bootloader's vector table is used, anyway, and if this bootloader table contains the logic to route the interrupts to some area in Flash/RAM and if your cector_table_pointer is in that area, then I guess you are achieving this relaying :)

OK. Thanks @ioannisg. Since the problem is solved, then we can close this case :)


Channels not shown

I'm trying to deploy the smart contracts on the Trade Network using the vs-code IBP extension. Unfortunately when I connect to it the Channel section is not shown what it prevents to deploy the contract on the channels. Is this the expected behaviour? If so, how could I deploy the smart contract?
Many thanks

Did you create the channels and join the peers to the channels? The startAndJoinChannels.sh does that, as is specified in the instructions.

No, I didn't. I was following the instructions on the book and somehow I realized that it wasn't described how to show the channels on vscode. I'll try that script and let you know.

The book talks about channel creation in Chapter 9, and you'll find the instruction I linked to there. I assume you are still in Chapter 4? The purpose of that chapter was just to get a network of nodes (peers, orderers, and CAs) up and running. Then you move on to developing chaincode locally in Chapter 5, understand at depth what business networks are comprised of in the next 3 chapters through samples, before resuming the trade network operation in Chapter 9. You can jump from 4 to 9 if you wish; i.e., if you understand chaincode development and business network artifacts (wallets, gateways) already.

Many thanks for your feedback. Indeed I stopped on Chapter 8.
I was able now to see the channels on vscode

I've also gained more understanding about the provided scripts startAndJoinChannels.sh and trade.sh. Regarding the former, when the step ./trade.sh joinchannel -c tradechannel -o 3  is executed, the following function in the trade.sh is invoked:
function joinPeersToChannel () {
  checkPrereqs

  # Create folder for docker network logs
  LOG_DIR=$(dirname $LOG_FILE_CLI)
  if [ ! -d $LOG_DIR ]
  then
    mkdir -p $LOG_DIR
  fi

  # Check if the cli container is already running
  checkAndStartCliContainer

  # Join peers to the channel
  docker exec -e CHANNEL_NAME=$CHANNEL_NAME -e NUM_ORGS_IN_CHANNEL=$NUM_ORGS_IN_CHANNEL $CONTAINER_CLI scripts/channel.sh join >>$LOG_FILE_CLI 2>&1
  if [ $? -ne 0 ]; then
    echo "ERROR !!!! Unable to join channel"
    echo "ERROR !!!! See "$LOG_FILE_CLI" for details"
    exit 1
  fi
  echo "Joined peers to channel "$CHANNEL_NAME
}

It caught my attention the checkAndStartCliContainer line. If I was able to follow the execution chain properly, it's the cli-container the responsible for generating/configuring the peers channel connections. These configurations are stored on the local volumes mounted by this container which are the same that the peers mount as well. In such a way, using shared volumes, the channel configuration is made available for the rest of the network, am I right?
Many thanks

What's mounted in the CLI container using volumes are the crypto artifacts (the certificates and keys of the peers, orderers, and CAs) in the crypto-config folder and the channel artifacts (genesis block, initial channel transaction, and anchor peer configurations) in the channel-artifacts folder. Also are copied the scripts that are run within the CLI container and code corresponding to the four contracts to be deployed in this network. Here are the lines that indicate this: https://github.com/HyperledgerHandsOn/trade-network/blob/master/bash/docker-compose-cli.yaml#L37...L40.
All the scripts in the CLI are doing, as triggered by higher-level scripts like trade.sh and startAndJoinChannels.sh and sampleChaincodeOperations.sh, are sending commands to peers and orderers (mainly using the peer command with different options) to perform basic operations like creating channels, joining peers to channels, installing chaincode on peers, etc. So it's these commands (which are core Fabric tools) that are doing the heavy work of initializing ledger states, starting containers that will run contract code, create blocks, disseminate blocks, etc. It's not the sharing of configuration through volumes; that's simply to provide the payloads for these commands as triggered by scripts in the CLI container.
Hope this is clear? The explanation in the book was quite detailed as I recall, walking you through each file, each command, and the effects of each command.

many thanks for the clear explanation. I spent some time perusing the chapter 9 and got a much better understanding.


Write OIH Compliant "Lookup Object (at most 1)" Iteration 2 Action

OIH standards
There should be an action Lookup Object (at most 1) that adheres to the OIH standard for Salesforce.  It likely makes sense to depricate the existing lookup behavior.   It also makes sense to use the latest API version.
Iteration 1 (by ID only) is insufficient.  Iteration 2 (by unique criteria) is required.  It appears as though it is possible to write business rules that enforce uniqueness on one or more fields, but it is not possible to learn those rules dynamically.  There are some db level settings to enforce uniqueness that can be read.
Suggestions for config fields:

Object Type (dynamic dropdown): All sobjects in describeGlobal where searchable is true.  In the config object, the key should be name and the value should be ${sobject.label} (${sobject.name}).
Type Of Search (static dropdown): Two values: Unique Fields, All Fields
Field to Search (dynamic dropdown): If All Fields then all fields on the selected object.  If Unique Fields all fields on the selected object where type is id or unique is true.  In the config object, the key should be name and the value should be ${sobject.label} (${sobject.name}).
Allow Criteria to be omitted (dropdown/checkbox: yes/no): As the OIH standard describes
Allow zero results (dropdown/checkbox: yes/no): As the OIH standard describes

All fields on the matched object should be returned.  At this point in time we do not need to worry about expanding parent or child linked objects.  We may need to come back to this in the future.

CDoD
Development:

[x] Code is written and formatted in accordance with the Styling guide.
[x] Component logs do not contain any sensitive data (credentials, input/output requests, Environment variables)
[x] Code is covered with unit tests.
[x] Triggers/actions comply with OIH patterns.
[x] Documentation (README.md file in the Github) is 100% ready.
[x] Component code is covered with integration tests.
[x] Component code is reviewed and fixed, if needed.
[ ] CI is set up
[ ] Sprint review preparation is finished (build demo flow is built)

QA:

[ ] Test cases for the component are ready at the TestRail.
[ ] Functional testing is finished.
[ ] Regression testing is finished (optional).
[ ] All the development branches are reviewed and merged into master
[ ] Component is deployed to the production stage (app.elastic.io) or/and other required stage.

Smoke test is finished there.
Component has a proper access level

[ ] Release notes are done.
[ ] Component Roadmap is updated.
[ ] Component spreadsheet is updated


Feature Request: allow the autosuggestor to suggest user-filled breadcrumb types

what I mean is to have it suggest the things filled out in settings. For example:

if I typed like BC-BT (or just BT) to have Breadcrumbs suggest "BT⤴"

@brimwats this is available in the latest beta release :D
You'll need to install it manually from here: https://github.com/SkepticMystic/breadcrumbs/releases/tag/2.44.0
Go to Settings > Alternative Hierarchies > Enable Relation Suggestor. Weird place, I know. You can also change the trigger.
Let me know how it works for you :)


Add explicit module info

Adds an explicit module-info to the final artifact

Hmm... compilation with ant and mavcen succeeds, but IntelliJ complains:
java: module not found: org.apache.logging.log4j.core
java: module not found: org.apache.logging.log4j
java: module not found: org.slf4j

This is perhaps not helpful, but IntelliJ is working fine on my machine. Maybe you need to upgrade your IJ?

Still the same problem, I'm on 2023.2.6

Thats the same version as me.
I nuked my local and re-cloned from github and all was fine. Maybe its an issue as to whether its a "maven project" in intellij's eyes? I'm also on a mac if that ends up mattering.
(I definitely have incentive to figure out whats going on - partially so you don't revert and partially so I can be aware of this in the future)

I think that this pr must have a few tests executed with the modular path,
otherwise it's hard to validate its correctness.
Tristan
On Wed, 1 May 2024, 19:10 Ethan McCue, @.***> wrote:

Thats the same version as me.
I nuked my local and re-cloned from github and all was fine. Maybe its an
issue as to whether its a "maven project" in intellij's eyes? I'm also on a
mac if that ends up mattering.
(I definitely have incentive to figure out whats going on - partially so
you don't revert and partially so I can be aware of this in the future)
—
Reply to this email directly, view it on GitHub
https://github.com/belaban/JGroups/pull/792#issuecomment-2088783014, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAC72HT7RDVABSPI2WGUMFDZAEOZNAVCNFSM6AAAAABHAPONPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYG44DGMBRGQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

This is driving me crazy and now I have a new error: Exception in thread "main" java.lang.NoClassDefFoundError: production/JGroups/module-info is not a class because access_flag ACC_MODULE is set.
Same issue regardless whether I import the project as maven or from srcs (ant).
I'm removing module-info.java, as it prevents me from working. I'll leave the changes in build.xml and pom.xml.


Add option for the user to define new filter resolver repositories

Use new command: regolith repo

regolith repo - lists installed resolvers with their indices. Sth like:Your installed repositories:
- [1] github.com/Bedrock-OSS/experimental-regolith-resolver
- [2] github.com/SecretOrganisation/super-secret-regolith-resolver
- [3] github.com/something/something-regolith-resolver

regolith repo --add <url> adds new filter resolver
regolith repo --remove 2 removes the second item from the regolith repo list

Closed with #225


Add option to "delete stock items" when deleting a stock location

Currently when deleting a StockLocation the contained StockItem objects are automatically moved up a level.
Two new things need to be added:

Provide the user an option to either move the StockItems up a level (default) or delete them. This option should also provide a warning about what stock items are going to be deleted. Also consider whether a separate option should be provided as to what to do with sub-locations

When deleting a stock location, and moving contained parts "upward" ensure that each StockItem is given a new tracking note

@SchrodingersGat What did you decide on in #2736 ?

@eeintech this one is a separate issue.
Consider the case where you have a hierarchy of stock locations A -> B -> C -> D , and location "C" has 10 items in it.
If you were to delete C, the following happens:

The 10 stock items are now located in "B" (the "parent" location for C)
The parent of D is now B
The hierarchy is now A -> B -> D

However, the user may have actually wished to delete C and everything in it. Currently this is not easy to do - you would have to delete each child location and stock item individually.

I was also searching for something like this and ended up with a little scripted version. Just wanted to post that here if somebody else needs it until this feature is implemented.
from inventree.api import InvenTreeAPI
from inventree.stock import StockLocation

SERVER_ADDRESS = ''
MY_USERNAME = ''
MY_PASSWORD = ''

api = InvenTreeAPI(SERVER_ADDRESS, username=MY_USERNAME, password=MY_PASSWORD)

def delete_recursively(location: StockLocation):
    print(location.pathstring)
    for sub_loc in location.getChildLocations():
        delete_recursively(sub_loc)
    location.delete()

delete_recursively(StockLocation(api, pk=306))

But this method has a big downside, its very slow. I guess this is caused by the logic which checks if it has Childs and tries to move them up.

Thank you @luwol03 ! This should really be part of the general API.

@luwol03 looks like this feature is coming into the UI as well : https://github.com/inventree/InvenTree/issues/3384

But this method has a big downside, its very slow

Yep, multiple API certainly add up! That's why we added a BulkDeleteMixin so that some items can be deleted all at once.
https://github.com/inventree/InvenTree/blob/703731ec4d60f39864379ff89c0c90e23d9cb837/InvenTree/InvenTree/api.py#L59
This also has another huge advantage: If one of the delete operations fails, all the others are rolled back.
You can do a search on the codebase to find which API endpoints implement the BulkDeleteMixin
We should port this feature to the python bindings so it can be used there.

Ref: https://github.com/inventree/inventree-python/pull/130

@martonmiklos :)

@SchrodingersGat  Nice job :)

Hi folks!
I started to work on this and get a bit stuck again with the unit testing implementation.
My code lives here:
https://github.com/martonmiklos/InvenTree/tree/fix_757
In the test I try to delete a created StockLocation via API:
url = reverse('api-location-detail', kwargs={'pk': stock_location_to_delete.id})
...
response = self.delete(
                url,
                params,
                #expected_code=204,
            )

My requests fails with 403 with the response content:
(env) mm@mm-precision:~/Projektek/inventree/src$ python3 InvenTree/manage.py test --keepdb  stock.test_api.StockLocationTest.test_stock_location_delete
Using existing test database for alias 'default'...
System check identified no issues (1 silenced).
/api/stock/location/164/
Forbidden: /api/stock/location/164/
{"detail":"You do not have permission to perform this action."}<Response status_code=403, "application/json">

Would you mind to take a look on it and help to find the reason of this?
Many thanks in advance!

@martonmiklos seems like the user you are using does not have the right permissions

In the testing framework you can use the self.assignRole method to give the test environment the right permissions for the API.
e.g. self.assignRole('stock.change')
Search through the code base for examples of this

Closed in https://github.com/inventree/InvenTree/pull/3926


Address user feedback on /docs/intro/concepts/state

Problem
This page has a high blended score (3803) for traffic, bounce, and negative feedback. There are two pieces of user feedback that appear actionable.
NOTE: Unclear how far we should go down the path of making self-hosting state 'easy' but we can address inaccuracies or gaps.
Proposed Solution

[ ] One commenter requests more info about state clean-up in this doc.

[ ] Azure-specific feedback (e.g. replace 'bucket' with 'container') in the Azure example.

these pages were redone since this issue was opened, so closing


Add index.ts to packages/database root

Description

Testing Instructions

Unsure why this is necessary consider packages/database/src/index.ts already exists. If you think this is necessary, please reopen will the PR summary and testing instructions filled out.


is it possible to make reanimated2 an optional dependency (conflicts with realm)

Hello,
Thanks for your effort and so we are switching from RNC to RNVC, and switching from react-native-qrcode-scanner to this code-scaner.
But when use this plugin, we met some issue.
Currently we are using realm as our app offline solution, it's used everywhere in our app. However the realm sdk conflicts with reanimated v2.
see this issue: https://github.com/realm/realm-js/issues/3837
though the issue is closed, it used a workaround(an earlier beta edition), yet that version has significant performance issue.
see https://github.com/realm/realm-js/issues/4443
so we don't really like to upgrade to an beta and unstable realm version.
my question is can this plugin just like react-native-vision-camera does, make react-native-reanimated an optional dependency, so both this plugin and realm sdk can co-exist.

As I know, vision-camera used reanimated for worklets and background computation, so - no

@whalemare Thanks for your reply, yes later I knew that if you want to use the camera frameProcessor you have to include reanimated2, we will just wait for realm to release v11, and seems they already made great progress on this based on the discussion. I will just close this issue.


Do not add IP to name records for aliases

- What I did
Do not add IP to name records for aliases so IP to name resolution will always reply container name.
- How I did it
Send ipMapUpdate = false to addSvcRecords function so it will not add IP to name records https://github.com/docker/libnetwork/blob/09e39d99d5c769cb7d167058504581d1cfc779e3/network.go#L1422-L1427
- How to verify it
This can be easily tested with commands:
docker network create --internal --attachable --driver overlay --scope swarm foo-network
docker run -it --name bar-container --rm --network foo-network nicolaka/netshoot
for i in {1..1000}
do
  nslookup $(hostname -i) | grep "arpa" | grep -v "bar-container"
done

without this one about 100-150 / 1000 tests fails.
Fixes moby/moby#34882

@fcrisciani I can see that this code have been added by your PR #1796
What are you thoughts is this correct way to fix the issue?

@fcrisciani I noticed this issue when I was looking for that if it is possible to modify Redis Sentinel to store hostnames to config files instead of IPs which would make it working with static IPs and would avoid needed for: https://github.com/moby/moby/issues/24170
Here is example config from my lab which is updated by Redis Sentinel
sentinel myid c73d00854dd76658fabc38199394d23d02890533
sentinel deny-scripts-reconfig yes
sentinel resolve-hostnames yes
sentinel monitor redis-cluster redis1.redis 6379 2
sentinel down-after-milliseconds redis-cluster 5000

# Generated by CONFIG REWRITE
port 26379
dir "/data"
maxclients 4064
protected-mode no
sentinel failover-timeout redis-cluster 10000
sentinel config-epoch redis-cluster 0
sentinel leader-epoch redis-cluster 0
sentinel known-replica redis-cluster redis3.redis 6379
sentinel known-replica redis-cluster redis2.redis 6379
sentinel known-sentinel redis-cluster sentinel2.redis 26379 e01aa25470f3464e22bfa312e3d2afdfdb026f88
sentinel known-sentinel redis-cluster sentinel3.redis 26379 69f4033663862814f0dcbc90932fc4eb38f26b1a
sentinel current-epoch 0

and without this change time to time there was container id instead of these redisX.redis or sentinelX.redis hostnames which makes is breaking when container restarts and IP changes.
Reason why I'm looking for this is that currently only way make Redis Sentinel working is create overlay network with manually specified subnet and join standalone containers with static IPs to it.

I ran into this as HBase requires forward/reverse name lookups to match. This fixes the bug that makes HBase unusable in a docker container on an encrypted overlay network.

@fcrisciani did you got enough explanations why this is needed?
These are bit rare use cases and that why most users have been able live without this fix but at least I cannot image any use case where current approach would be needed so can we merge this one?

Thanks @olljanat for the contribution!
Only one comment on leveraging the task name given by swarmkit, there is no real guarantee from swarmkit side that if you scale up a service from 1 to 10 replicas and then scale it back down to 1 replica that the only task remaining is the one with name bla.1.redis. Like the .1. is just a number that keeps the task name unique but not a deterministic way to know how many replicas of a service are present.


🌱 Adding contracts in configs for tests

What this PR does / why we need it:
Adding contracts in configs for tests
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

/hold
until the discussion settles

unholding got lgtm from @smoshiur1237
/unhold

/test metal3-ubuntu-e2e-integration-test-main

/test metal3-centos-e2e-integration-test-main
This should pass now

/test metal3-ubuntu-e2e-integration-test-main
This should also pass now that the dev-env is merged. This was started too early.

Still not OK. @adilGhaffarDev  are you looking at this?
[2024-08-30T09:11:43.684Z] Using override="metadata.yaml" provider="infrastructure-metal3" version="v1.9.99"

[2024-08-30T09:11:43.684Z] Error: invalid provider metadata: version v1.9.99 for the provider capm3-system/infrastructure-metal3 does not match any release series

Still not OK. @adilGhaffarDev are you looking at this?

i am checking

/test metal3-ubuntu-e2e-integration-test-main

/test metal3-centos-e2e-integration-test-main
Let's run both, so we can get it in sooner.

The error seemed to be from jumping 1.7.99 (maybe mistake in previous release process) to 1.9.99 which obviously needs 1.9 contracts as well.

The error seemed to be from jumping 1.7.99 (maybe mistake in previous release process) to 1.9.99 which obviously needs 1.9 contracts as well.

yes I missed it, now it has been added

Still not matching something :(

/test metal3-ubuntu-e2e-integration-test-main
/test metal3-centos-e2e-integration-test-main

Re-adding lgtm in case tests pass. We need to get this in.
/lgtm

failed because we dont have a stable release of 1.8:
15:01:27
15:01:27    [FAILED] The e2e test config file is not valid
15:01:27    Expected success, but got an error:
15:01:27        <*errors.fundamental | 0xc0004b0b40>:
15:01:27        invalid argument<EMAIL_ADDRESS>15:01:27        {
15:01:27            msg: "invalid argument<EMAIL_ADDRESS>15:01:27            stack: [0x327ec77, 0x32809a5, 0x327ecef, 0x327c1bf, 0x351f3b5, 0x34edd7c, 0x15114c6, 0x15105d9, 0x192e5be, 0x193eace, 0x194236d, 0x1491e21],
15:01:27        }
15:01:27    In [SynchronizedBeforeSuite] at: /home/metal3ci/go/pkg/mod/sigs.k8s.io/cluster-api/test@v1.8.1/framework/clusterctl/e2e_config.go:69

Changing it to<EMAIL_ADDRESS>to<EMAIL_ADDRESS>to get rc release.

/test metal3-ubuntu-e2e-integration-test-main
/test metal3-centos-e2e-integration-test-main
fingers crossed

Changing it to<EMAIL_ADDRESS>to<EMAIL_ADDRESS>to get rc release.

This didn't work, I will check later what the issue is there, It is coming from CAPI. For now, I am hard-coding v1.8.0-rc.0 for CAPM3, when we do the stable release I will change it back to<EMAIL_ADDRESS>

/test metal3-ubuntu-e2e-integration-test-main
/test metal3-centos-e2e-integration-test-main

/test metal3-ubuntu-e2e-integration-test-main
/test metal3-centos-e2e-integration-test-main

/lgtm


CLI: Do not reach to Marketplace if extension is already installed unless forced

While installing an extension from CLI, if an extension is already installed, CLI reached to Marketplace to check if there is a newer version or not and prints following message:
Extension '<extension-id>' v0.20.0 is already installed, but a newer version 0.21.0 is available in the marketplace. Use '--force' option to update to newer version.
Though informative, it is not necessary and makes the operation slower. At the end --force flag has to be passed to forcefully install/update.
To make it faster, do not reach to Marketplace if extension is already installed. Check and install updates only when --force flag is passed.

Following message is printed if extension is already installed and --force flag is not passed
Extension '<extension-id>' is already installed. Use '--force' option to check and update to newer version.
When --force flag is passed, updates are checked and installed automatically.


Issue with k8s.io/docs/tasks/example-task-template/

This is a...

[ ] Feature Request
[ x] Bug Report

Problem:
The Link to related explanation is not working.
Proposed Solution:
Fix the broken link
Page to Update:
https://kubernetes.io/...

Documentation changes only

This is a demo which shows how to write a task doc, so it's not a real link. But i will try to improve this sentence in some way.


fix bug and test token - [merged]

In GitLab by @tongjianli on Apr 28, 2020, 09:37
Merges dev_new2 -> dev

In GitLab by @tongjianli on Apr 28, 2020, 09:41
added 1 commit

5828441e - fix code

Compare with previous version

In GitLab by @wknet123 on Apr 28, 2020, 09:58
mentioned in commit f9fddc12f8dc7413a368c4d6b95e0e84cd01ee3b

In GitLab by @wknet123 on Apr 28, 2020, 09:58
merged


Key rotation and trusting directives?

A trusting directive hard-codes a specific public key, which seems like it would make it hard to rotate those keys without brute-force trying every current version.  Is there some mechanism for handling this?

The typical KMS-style key rotation approach is to issue a new key, use that for new credentials, but keeping the old key valid for some time window which doesn’t immediately invalidate them.
Ideally you could make that expiration window longer than the credential validity period.

Third-party blocks carry the public key that can be used to verify them, so the external signatures are only verified once, with the public key carried in the block. The trusting annotation then allow to select the third-party blocks based on their public key.
You can have several public keys in a trusting annotation, so you can have the old and new public keys in the annotation, and the third party block will be considered if either one matches.
So the rotation process would be:

generate a new key pair
expose its public keys so that it can be added  to trusting annotations
start emitting third-party blocks signed with the private key

Since for third party-blocks, the block emitter and the users of trusting annotations are not the same entity, the validity period of public keys has to be longer than the validity of the token containing the trusting annotation, which can be ensured through TTL checks.


Add GRMustache templating engine to Kitura

 Issue by VADIME
Tuesday Feb 02, 2016 at 15:40 GMT
Originally opened as https://github.ibm.com/ibmswift/Phoenix/issues/84

Added a new repo https://github.ibm.com/ibmswift/GRMustache.swift .
Using https://github.com/groue/GRMustache.swift, MIT license

Opened issues against Apple while porting GRMustache to Linux:
https://bugs.swift.org/browse/SR-765
https://bugs.swift.org/browse/SR-789
https://bugs.swift.org/browse/SR-790
https://bugs.swift.org/browse/SR-794

Completed in ea0d77d1ec8f6e3b94b9973a69ccf0a3a12b8693.
All (313) tests pass.

Validated.


Improve accuracy of simulator

The simulator is not very accurate when it has to draw lots of lines, especially when the Ether Dream device is not connected.
This probably has to do with us faking the number of streaming points badly.

I think @Rutger has fixed this recently, but I want to verify this with the EtherDream connected.


how to clear the selected date?

hi,
I have a Reset button at the end of my form which should clear all the fields including the date. however, due to this line setting the v-model of the date picker to an empty string does nothing. and the previously selected date is still displayed.
this results in the actual value and the displayed value being different.
jsfiddle.

hi i really need to clear place holder if person want to clear date !
could you please release as soon as possible ?


Get-GcsBucket : Object reference not set to an instance of an object.

I assume that if none of my projects have any buckets, that it causes this problem:
PS C:\Users\csells> Get-GcsBucket
Get-GcsBucket : Object reference not set to an instance of an object.
At line:1 char:1

Get-GcsBucket

  + CategoryInfo          : NotSpecified: (:) [Get-GcsBucket], NullReferenceException
  + FullyQualifiedErrorId : System.NullReferenceException,Google.PowerShell.CloudStorage.GetGcsBucketCmdlet

This is now fixed with https://github.com/GoogleCloudPlatform/google-cloud-powershell/pull/413