Incorrect Function Length

The ES6 spec defines Symbol.prototype[Symbol.toPrimitive] as a function with a single parameter.
According to section 17, in the absence of any text specifying otherwise, the function's length property value should be dictated by its formal parameter list:

Every built-in Function object, including constructors, has a length
property whose value is an integer. Unless otherwise specified, this value
is equal to the largest number of named arguments shown in the subclause
headings for the function description, including optional parameters.

This is a bit disappointing because the parameter isn't actually referenced in the algorithm, but I believe following the letter of the spec means defining the length property to 1.

This is a bit disappointing because the parameter isn't actually referenced in the algorithm, but I believe following the letter of the spec means defining the length property to 1.

Yupp. I guess a copy-paste error when I initially added the function.

Just in case there was any doubt: I meant "disappointing" to describe the confusing/unnecessary parameter, not your work here!

No worries, I didn't misunderstand you.

Fixed in 6eca8b8448aeca44f78798b20005951bdacc26e5

Nice work!


Feature/add pagination for poducts endpoint

Can't you use https://www.npmjs.com/package/nestjs-typeorm-paginate ?


Tyson Pull Request

This is too big, and has conflicts. Break it up into pieces, one change at a time.

This is really interesting, but it doesn't make sense to review a pull request with 228 files changed and 1364 commits. Maybe you should set this up as a separate project somewhere on github, and we can link to it?


Persistent storage for POS UI Extensions

Please list the related package(s)
retail-ui-extensions, retail-ui-extensions-react
If this related to specific APIs or components, please list them here

Is your feature request related to a problem? Please describe.
Our POS UI Extensions will render differently depending on the merchant's settings for our app (e.g: we need to load the currency format to render money). Currently, we fetch these settings from our server every time a merchant opens the app's modal, and although this approach works it adds delay to the initial render.
We would like a way to maintain the settings on the device between different times the modal is opened.
Describe the changes you are looking for
Some sort of storage that would be persistent between different modal openings. Maybe implement localStorage for POS UI Extensions.
An alternative would be to load the settings on the POS tile, and pass props to the modal through the api.smartGrid.presentModal() function.
Describe alternatives you’ve considered

Additional context

+1 would be useful

+1 facing the same, unable to share data btw tiles x modal, tried using a state management lib but it doesn't work


Error should be reported for missing plugin

When a plugin is requested by the configuration and not resolved after a certain period of time (say 10 seconds), an error should be reported so it is clear that a required plugin is not properly set up.

Fixed in 4b53ec10a91bab5bd6a3065807add62d4c4c0bb3


fix: FluentUI Icons breaks VS intellisense in V3

If you've used icons in version 2, you will be attempting to upgrade them to V3.
The process of editing an existing .razor file in visual Studio 17.6.6  containing FluentIcons breaks as intellisense tries to cope with the editing of the FluentIcon. This results in VS hanging and requiring a restart.
This bug may be in FluentUI Blazor or VS.
The only solution is to edit these files outside of VS, or to save changes before intellisense catches up..
This happens in two separate blazor projects.
To reproduce:
In the most recent VS, open a solution containing a V2 project containing Icons.
Open the razor file containing icons in VS
Edit the "name" tag in the FluentIcon to convert to "Icon".
Edit the text part of the tag to the new format
Delete the old size and fill type tags.
At some point during this process intellisense will catch up and VS will hang,
So from:
<FluentIcon Slot="start"<EMAIL_ADDRESS><EMAIL_ADDRESS>Color=Color.Lightweight/>

to:
<FluentIcon<EMAIL_ADDRESS>Slot="start" Color="Color.Lightweight" />

Duplicate of #643. Closing this one.


A basic template implementation and views function?

I'm pretty new to Django and struggling to implement django-vote to my app.
For voting up a review in my Car page, I tried this in my template:
<form action="{% url 'reviews:review-vote-up' review.id %}" method="GET">
	    	<input type="submit" value="Up" name="vote-up" />
</form>

My URL:
url(r'^(?P<review_id>\d+)/up/$', views.review_vote_up, name="review-vote-up"),

My view function:
def review_vote_up(request, review_id):
	if request.GET.get("vote-up"):
		review = Review.objects.get(id=review_id)
		review.votes.up(request.user)

	context = {"make": review.car.make,
	"model": review.car.model,
	"platform": review.car.platform,
	"body": review.car.body,
	"version": review.car.version,
	"years": review.car.years}
	return redirect("reviews:car", context)

But this doesn't register the vote, and it doesn't redirect me back to the Car page.
Could you give me a simple template implementation and view function example of voting up, or clarify my errors?
Any suggestion or feedback will be welcomed and greatly appreciated.
Thank you.

You have to pass user_id instead of a user instance. We should raise an error here.

I changed that line as review.votes.up(request.user.id) but still can't register the vote. Is the rest OK?

You can add some print  to your view and check if the votes.up have been executed.

Yes, I've got {{ review.votes.count }} in my template and I can't execute upvoting through my view. But it works in the shell.


Release 2.0.0

Tracking sass/node-sass#904

[x] Resolve outstanding questions
[x] Resolve outstanding bugs
[x] Resolve outstanding enhancements
[x] Determine if issues with no milestones should be included for 2.0.0 release
[x] Bump Node Sass version to 3.0.0 (#253)
[x] Add Contributing guidelines (#248)

/cc @micahgodbolt


chore: upgrade charts

updated chart cdf/tekton-pipeline from 0.27.0 to 0.27.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign ccojocar
You can assign the PR to them by writing /assign @ccojocar in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jenkins-x-bot-test: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
4c97d165e2669b1da333d781e64aa69aca522a20
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
4c97d165e2669b1da333d781e64aa69aca522a20
link
/test vault

kube
4c97d165e2669b1da333d781e64aa69aca522a20
link
/test kube

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
4c97d165e2669b1da333d781e64aa69aca522a20
link
/test vault

kube
4c97d165e2669b1da333d781e64aa69aca522a20
link
/test kube

gsm
4c97d165e2669b1da333d781e64aa69aca522a20
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.


InitialIndex doesnt work

I have 15 elements in a list but after the 10th index, it's just stuck on the 11th index (12th element). Is there something I'm missing? I really love this library btw, Just missing that feature to work.

+1

I have the same problem

Try to inspect the module at 'react-native-picker-horizontal/lib/module', then replace if (initialIndex) {       if (flatListRef && flatListRef.current) {         // @ts-ignore         flatListRef.current.scrollToIndex({           animated: false,           index: "" + initialIndex         });       }     }
with if (initialIndex) {       if (flatListRef && flatListRef.current) {         // @ts-ignore         flatListRef.current.scrollToIndex({           animated: true,           index: "" + initialIndex         });       }     }
you can fork the library on then install from your repo with the patch .... i dont know why scrollToIndex doesnt work after certain index with animated: false btw

Try to inspect the module at 'react-native-picker-horizontal/lib/module', then replace if (initialIndex) { if (flatListRef && flatListRef.current) { // @ts-ignore flatListRef.current.scrollToIndex({ animated: false, index: "" + initialIndex }); } }
with if (initialIndex) { if (flatListRef && flatListRef.current) { // @ts-ignore flatListRef.current.scrollToIndex({ animated: true, index: "" + initialIndex }); } }
you can fork the library on then install from your repo with the patch .... i dont know why scrollToIndex doesnt work after certain index with animated: false btw

or betterstill pass a ref to the passToFlatList prop then remove the initial index in the lib to manually do this


plans for v3.public

What is your plans re v3.public will you be supporting it? If so do you have an ETA?

Hey, thanks for reaching out.
I shipped without v3.public because there was some question as to whether or not the cryptography crate I intended to use for the ECDSA cipher used point compression.  Also, it wasn't a cipher combo I needed for my use case.  Implementation is straightforward and shouldn't take longer than a few days to a week.   However, I'm focusing all my efforts on a job search, so I won't be able to get started on it until I've gained employment and settled into that.
I'll prioritize it in my current roadmap and update this issue once it's ready!

Happy new year! v0.5.0 with V3 Public support is now released.


feat: Validate key integrity for translations.txt

Summary:
Summarize the changes in the pull request including how it relates to any issues (include the #number, or link them).
Expected behavior:
Explain and/or show screenshots for how you expect the pull request to work in your testing (in case other devices exhibit different behavior).
Please make sure these boxes are checked before submitting your pull request - thanks!

[ ] Run the unit tests with gradle test to make sure you didn't break anything
[ ] Format the title like "feat: [new feature short description]". Title must follow the Conventional Commit Specification(https://www.conventionalcommits.org/en/v1.0.0/).
[ ] Linked all relevant issues
[ ] Include screenshot(s) showing how this pull request works and fixes the issue(s)

Thank you for this contribution @aababilov!

Thank you for this contribution @aababilov!

My pleasure!

I am splitting this change into pieces. https://github.com/MobilityData/gtfs-validator/pull/979

Thanks for review!


Publish binaries for Presence.SocialFormat.Console

It should be possible to publish binaries for the console applications alongside each release. This may require some automation to manage it consistently (and with minimal effort).

Binaries build with prepare-cli-tools.sh - TODO: automate this process through GitHub Actions, and add these files to each new draft release.


Change JDK16_VERSION to jdk16u

Signed-off-by: Andrew Leonard<EMAIL_ADDRESS>

run tests

@andrew-m-leonard Ref AdoptOpenJDK/ci-jenkins-pipelines#100 (comment), if some of the links in that doc are wrong can you go through and update that section please?

@M-Davies that's my plan once i've gone through everything

openj9 broken upstream...


Some confusions about lime-Tutorial%20-%20images

Hello，I'm a rookie of ML. I am honored to ask you.
I have read your paper and try to run your Tutorial. During this process，there are two problem i met :
1.I can't understand why there are 1001 classes? Shouldn’t it be 1000?
import os with slim.arg_scope(inception.inception_v3_arg_scope()):     logits, _ = inception.inception_v3(processed_images, num_classes=1001, is_training=False) probabilities = tf.nn.softmax(logits)
2.I try to run it for each synset to see what accuracy rate in this models by using LIME explanation，so I download ILSVRC2012_img_val to run this example. But I find the class index can not match in your experience.For example，the "English setter" ’s index in imageNET is “1”，but in your experience is shown as "213".
178 Scottish deerhound, deerhound 0.00051360053 214 Irish setter, red setter 0.0007739145 215 Gordon setter 0.0014154159 170 borzoi, Russian wolfhound 0.0017604019 213 English setter 0.9593616
Why is there a difference?


Removed memory leak with identifierNamesGenerator: 'mangled'

Coverage remained the same at 98.681% when pulling e4ca9f774bffb504b3d6cbbdc21a1ce334dc81c7 on mangled-memory-leak into cc85f93f98c583f80b78b5f90965b710d3acd4c6 on master.


"Indoor run" from Watch GT fails to parse

Here's a link to the output file from my Watch GT. The Huawei app is installed on my Mi Mix 2 which is rooted.
The output from the file is:
---- Input File ----
reading: OKAY
filtering: OKAY
processing gps: OKAY
Something went wrong :-(

Shoving a debug line in, I get Error: list index out of range - does it need another conditional to catch indoor running stats? Sorry, I'm a bit lost in Python having never written any before.

Not sure how I managed to close this!

Well spotted! I initially wrote this script just to extract GPS data, but now we've branched out a bit it doesn't make any sense to extract start time just from gps data, and we should instead extract it from the merged chronologically sorted data. I'll sort this out today :)


Libroffice and Keynote compatibility (probably others programs too)

I used the same code in https://jsfiddle.net/p85by1tf/ which is the fiddle of pptxGenJs website, and the Data is the example data from examples.
The same code generates different 'pie' and 'donut' charts in microsoft office and libreoffice. I'm worried about this compatibilization, I have clients that use the most diverse programs. I have tested the other graphs and they do not cause major problems. please take a look at the screenshots below generated by microsoft office and librofice.
microsoft office:

librofice:

Have you ever had such a problem? How can i fix it?
it seems that on microsoft office it takes the key 'label' which is a array of labels, that is correctly, but in librofice it take the 'name' atribute.

I also encounter this. In my case, in the secondary axis is not showing in keynote but displaying properly in MS PowerPoint.
ON MS powerpoint

Apple keynote

same slide, same script. different output.


LKE-5704: Add Jenkins file for release Job

cc @thibveni
THis adds a new release job, for one of the LKE plugins


iPad Mini 3

'already jailbroken' but cydia don't install

Have you tried rebooting then re-running the yalu app?

Yes, and same. @MattCowley

I presume you calculated the offsets yourself?

No.. @MattCowley

No. Nor do I see them in the project (I may be wrong). It's not on the supported device list so I'd just wait till it is supported.

Yes,  the offsets maybe wrong. I will wait for any change.. thanks. @MattCowley

Can you mark this as closed please :)

Wait if someone has the solution @MattCowley

https://github.com/kpwn/yalu102/issues/64


Include test fixtures in the bom

Discussion at https://cash.slack.com/archives/C01M5M297T7/p1686840372926259 for posterity


Add chrome-image support

It looks like a chrome-png recipe is being added to jsreport.
https://github.com/jsreport/jsreport-chrome-pdf
https://github.com/jsreport/jsreport/issues/478
Are there any plans to add support to the dotnet sdk?

You can now update deps - mainly<EMAIL_ADDRESS>and<EMAIL_ADDRESS>to have support for chrome-image in .net.

Thank you!


Optimise --filter option pattern

The current --filter option just joins a list inside a or regex pattern:
def build_filter_option_pattern(list):
    return '::(' + '|'.join(sorted(list)) + ')( with data set .+)?$'

The pattern could be optimised to avoid really long patterns.
Also, maybe we should put a limit on the size?

Cool ideas!


firefox-bin: update to version 37.0; thunderbird-bin: update to version 31.6.0

Firefox 37.0

Heartbeat user rating system - your feedback about Firefox
Improved protection against site impersonation via OneCRL centralized certificate revocation
Opportunistically encrypt HTTP traffic where the server supports HTTP/2 AltSvc
Disabled insecure TLS version fallback for site security

https://www.mozilla.org/en-US/firefox/37.0/releasenotes/
Thunderbird 31.6.0
No release notes yet.
https://www.mozilla.org/en-US/thunderbird/releases/

Firefox 37.0.1

Various security fixes
Disabled HTTP/2 AltSvc
Start-up crash due to graphics hardware and third party software

https://www.mozilla.org/en-US/firefox/37.0.1/releasenotes/


Two calendar icons are displayed for a date input in Firefox

Describe the bug
A date input control in Firefox displays a native browser calendar icon in addition to the cds-icon.
(Only a single cds-icon is displayed in Safari and Chrome.)
How to reproduce
View the Storybook page in Firefox https://storybook.core.clarity.design/?path=/story/forms-date--page

Expected behavior
A single calendar icon is displayed in all browsers.
Versions
Clarity project:

[x] Clarity Core
[ ] Clarity Angular/UI

Clarity version:

[ ] v5.x
[x] v6.x

Framework:

[x] Angular
[ ] React
[ ] Vue
[ ] Other:

Framework version:
Angular 15
Device:

Type: MacBook
OS: Ventura 13.2
Browser: Firefox
Version: 109

It's a regression caused by Firefox breaking change.
It was fine when I tested it with 107.0.1 and then I reproduced it in 109.0.1, after I updated my browser.
We have to check how to suppress the default icon.

It's actually the whole native selector that needs to be prevented.
It seems it does not respect the ::-webkit-calendar-picker-indicator pseudo selector anymore.

There doesn't seem to have been any change in Firefox according to this bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1812397
Does anyone have a good workaround?


Git LFS uses the wrong paths when used with cygwin Git

https://gist.github.com/TomyLobo/cf8c7cc7cf9f98800f3182368a1cc718
It also ignores LANG=C, so sorry about the germanese :)
As you can see near the bottom of the shell session and all over the log file, Git LFS stores its objects in C:\home\... instead of /home/... (which would correspond to C:\cygwin64\home\...)

Thanks for the report. I don't think any of the LFS developers use Cygwin, so we would need a submitted patch to fix this.

It's free, easy to install and you can just delete C:\cygwin64 when you're done :)

Closing this issue. Still interested in a cygwin patch though.

@technoweenie This issue is not fixed. Why did you close it?

Cygwin support is not a priority at all right now due to very low interest from users, and no Windows developers on the LFS team. If you're interested in maintaining Cygwin support for LFS, you're welcome to submit a patch. Otherwise, we're only supporting the Git shell that's installed with Git for Windows.

@technoweenie I also need cygwin support.  I suspect cygwin people find that things don't work and just go somewhere else (e.g. gitolite works just fine).  In short, if you supported cygwin, github.com would now be collecting storage money from me.

This seems like an issue with cygwin and the git-lfs client, so I'm not sure how it'd work with gitolite and not github. Can you elaborate?

@technoweenie I also need cygwin support. I primarily develop in a windows 7 environment for a linux target platform. Is there another open issue I can track? This forces me to switch over to linux development environment which I would really prefer not pursuing. I'm happy to be a guinea pig if you need one.

I also need cygwin support. +1

Cygwin support is still not on our list of priorities. The LFS team is currently focused elsewhere, on improving the resiliency and efficiency of transfers with large numbers of objects.
I don't think anyone else on @git-lfs/core uses Cygwin, but we'd be happy to help in terms of reviewing a PR.

Cygwin support is not a priority at all right now due to very low interest from users, and no Windows developers on the LFS team.

That's not quite true anymore, as I (and I believe also @larsxschneider) primarily use Windows. In any case, I wonder what the reason for Windows users is to use Cygwin when Git for Windows comes with MSYS?

The reason at least for us is dependency enforced by repo script which was written to support linux platforms.

[..] repo script which was written to support linux platforms.

True. It's a shame that Google decided to use Python as a cross-platform scripting language, but still implement repo in a platform-specific way. Anyway, you might be interested in this fork by E.S.R. Labs which supports Windows quite well.
As a side note, Google is going to deprecate repo in favor of submodules.

I understand this issue was the same as https://github.com/git-lfs/git-lfs/issues/865 and  thus is fixed by https://github.com/git-lfs/git-lfs/pull/1820? Can anyone confirm?


UserStream not work...

After changing the Twitter API, the FilteredStream works fine.
but the UserStream close immediately after opening the stream.
If we can not use the function, it seems to be removed from the wiki and code.
Log:
userStream StreamStarted
userStream StreamResumed
userStream Stoped
userStream StreamStarted
userStream StreamResumed
userStream Stoped
.....

Code:
``
private void StartUserStream()
{
var credential = Authentication.Instance.credential;
userStream = Stream.CreateUserStream(credential);
userStream.TweetCreatedByAnyoneButMe += UserStream_TweetCreatedByAnyoneButMe;
userStream.UnmanagedEventReceived += Stream_UnmanagedEventReceived;
userStream.DisconnectMessageReceived += Stream_DisconnectMessageReceived;
userStream.WarningFallingBehindDetected += (s, e) => Print("userStream WarningFallingBehindDetected", s, e);
userStream.AccessRevoked += (s, e) => Print("userStream AccessRevoked", s, e);
userStream.StreamPaused += (s, e) => Print("userStream StreamPaused", s, e);
userStream.StreamResumed += (s, e) => Print("userStream StreamResumed", s, e);
userStream.StreamStarted += (s, e) => Print("userStream StreamStarted", s, e);
userStream.StreamStopped += UserStream_StreamStopped;
userStream.LimitReached += (s, e) => Print("userStream LimitReached", s, e);
userStream.StartStreamAsync();
}
private void UserStream_StreamStopped(object sender, Tweetinvi.Events.StreamExceptionEventArgs e)
{
Console.WriteLine("User Stream Stoped");
StartUserStream();
}
private void Print(string eventName, object sender, EventArgs e)
{
Console.WriteLine(eventName);
}
``

The User stream has been retired by Twitter: https://developer.twitter.com/en/docs/accounts-and-users/subscribe-account-activity/migration/us-ss-migration-guide.html
Take a look at the release notes for Tweetinvi v4: https://github.com/linvi/tweetinvi/releases/tag/4.0
The section "Twitter Webhooks, Account Activity and UserStream" should help you migrate to the Webhooks new replacement.

Yes yes I know that API has been retired. but wiki page and code are still exist https://github.com/linvi/tweetinvi/wiki/User-Streams
https://github.com/linvi/tweetinvi/blob/master/Tweetinvi.Streams/UserStream.cs
I think it should be deleted .

Ok. At the time of the last release, the user stream was still live so it still needed to be in there. It should be deleted from the code in the next release.

On 7 Sep 2018, at 03:19, DeaDCaTsSociety<EMAIL_ADDRESS>wrote:
Yes yes I know that API has been retired. but wiki page and code are still exist https://github.com/linvi/tweetinvi/wiki/User-Streams
https://github.com/linvi/tweetinvi/blob/master/Tweetinvi.Streams/UserStream.cs
I think it should be deleted .
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Correct the UserStream code will be retired


map is undefined

I'm trying to make a map that will center on the users location when loaded. Or at least center on the users location when a button is clicked. But when you do, map is undefined. When I use {map} = useOL it sends back map is undefined. This is one variation I've tried -
"use client"
import React, { useCallback, useEffect, useState } from "react";
import { RMap, ROSM, useOL, RControl, RFeature, RLayerVector } from "rlayers";
import { Coordinate } from "ol/coordinate";
import { Button } from "../ui/button";
import { fromLonLat } from "ol/proj";
import { RView } from "rlayers/RMap";
import { View } from "ol";
import Polygon from "ol/geom/Polygon";
interface MapOptions {
children: React.ReactNode;
zoom: number;
}
// Define the main map component
const NewRlayersMapComponent: React.FC = ({ children, zoom }: MapOptions) => {
// Initial setup
const origin = [2.364, 48.82];
const initial: RView = { center: fromLonLat(origin), zoom: 11 };
const [isLoading, setIsLoading] = useState(true);
const [firstCoords, setFirstCoords] = useState<Coordinate | undefined>(undefined);
const { map } = useOL();
// Log the map object to console currently returns undefined
console.log("Map:", map);
// Fetch user's geolocation on component mount
useEffect(() => {
const userGeolocation = navigator.geolocation.getCurrentPosition(
(position: GeolocationPosition) => {
setFirstCoords([position.coords.latitude, position.coords.longitude]);
console.log("User's geolocation:", firstCoords);
},
(error) => {
console.error("Error getting geolocation:", error);
}
);
}, []);
// Update loading state once geolocation is available
useEffect(() => {
if (firstCoords) {
setIsLoading(false);
}
}, [firstCoords]);
// Handle button click event
const handleButtonClick = useCallback(() => {
console.log("Button clicked!");
setFirstCoords(origin);
map.setView(new View({ center: firstCoords as Coordinate }));
}, [firstCoords, map]);
// Define coordinates for different locations
const coords: Record<string, Coordinate> = {
origin: [2.364, 48.82],
ArcDeTriomphe: [2.295, 48.8737],
PlaceDItalie: [2.355, 48.831],
Bastille: [2.369, 48.853],
TourEiffel: [2.294, 48.858],
Montmartre: [2.342, 48.887],
};
// Render the map only if firstCoords is not null and not [0, 0]
if (isLoading) {
return Loading...;
}
if (!firstCoords || firstCoords.some((coord) => isNaN(coord) || coord === 0)) {
return No valid location available.;
}
// Return the JSX for the map component
return (
<>

<RMap key={firstCoords.toString()} width={"100%"} height={"60vh"} initial={{ center: coords.ArcDeTriomphe, zoom: zoom }}>
{children}

<RControl.RCustom className="example-control">
<button onClick={() => map.setView(new View({ center: firstCoords }))} className="bg-red-500 rounded-md">
This is a big button

</RControl.RCustom>

Click

{/* Add a vector layer with a polygon feature */}

<RFeature
geometry={
new Polygon([
[
fromLonLat(coords.PlaceDItalie),
fromLonLat(coords.Bastille),
fromLonLat(coords.TourEiffel),
fromLonLat(coords.PlaceDItalie),
],
])
}
>

</>
);
};
export default NewRlayersMapComponent;

As you may have seen from my profile, I have been living on social welfare for the last 3 years - eating with a few euros per day - and I expect to lose my home in the coming months. This is because of an extortion involving the French police and judiciary which included people simultaneously posting messages with content related to my sex life at my previous two employers. Currently, I am being offered a new job only if I accept that people around me continue to do this - without me saying anything - and only if accept a job at an employer chosen by the organizers of the extortion - because most companies refuse to do this. In order to further intimidate me, people are posting simultaneously issues and pull requests in all of the projects that I work in.
You have posted this issue simultaneously with a PR from @snyk-bot who start to be doing this on regular basis.

I don't know what this means.  Thank you for your work on this project,
it's really cool. I appreciation your time.
On Fri, Jan 19, 2024, 11:14 AM Momtchil Momtchev @.***>
wrote:

As you may have seen from my profile, I have been living on social welfare
for the last 3 years - eating with a few euros per day - and I expect to
lose my home in the coming months. This is because of an extortion
involving the French police and judiciary which included people
simultaneously posting messages with content related to my sex life at my
previous two employers. Currently, I am being offered a new job only if I
accept that people around me continue to do this - without me saying
anything - and only if accept a job at an employer chosen by the organizers
of the extortion - because most companies refuse to do this. In order to
further intimidate me, people are posting simultaneously issues and pull
requests in all of the projects that I work in.
You have posted this issue simultaneously with a PR from @snyk-bot
https://github.com/snyk-bot who start to be doing this on regular basis.
—
Reply to this email directly, view it on GitHub
https://github.com/mmomtchev/rlayers/issues/205#issuecomment-1900969722,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVLK5DD2TJOYRQAYQFOXLD3YPLA25AVCNFSM6AAAAABCCL75NKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBQHE3DSNZSGI
.
You are receiving this because you authored the thread.Message ID:
@.***>


JSON: add support for default repeating values

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@185f7ed). Click here to learn what that means.
The diff coverage is 87.19%.

@@            Coverage Diff            @@
##             master     #149   +/-   ##
=========================================
  Coverage          ?   83.47%
=========================================
  Files             ?      134
  Lines             ?     5779
  Branches          ?        0
=========================================
  Hits              ?     4824
  Misses            ?      638
  Partials          ?      317

Impacted Files
Coverage Δ

pkg/codec/json/types.go
85.20% <60.00%> (ø)

pkg/codec/json/decode.go
75.00% <75.00%> (ø)

pkg/codec/json/json.go
75.00% <75.00%> (ø)

pkg/codec/json/enum.go
84.84% <84.84%> (ø)

pkg/codec/json/scalar.go
91.66% <91.66%> (ø)

pkg/codec/json/array.go
89.47% <100.00%> (ø)

pkg/codec/json/encode.go
100.00% <100.00%> (ø)

pkg/codec/json/errors.go
100.00% <100.00%> (ø)

pkg/codec/json/object.go
71.42% <100.00%> (ø)

I have included a temp fix to satisfy the linter by ignoring the gojay vendor directory. This ignore should be removed once the PR over at francoispqt/gojay has been merged (francoispqt/gojay#157)


Remove proxima-nova font and use Roboto

Related to https://github.com/weaveworks/service-ui/issues/2774 and https://github.com/weaveworks/service-ui/issues/2562
Removes proxima-nova as the default font and uses Roboto instead.

Please describe the issue in a way which doesn't require access to a private repo.

CI is complaining about a missing font that isn't a part of this PR:
Module not found: Error: Can't resolve '../fonts/RobotoMono-Regular.ttf'
I cannot reproduce the error locally and won't have time to investigate. Closing for now; someone can re-open if they would like to take over.


POD cannot access outside

Expected Behavior

if host machine restart, the pod are sheduled to other hosts, can new pod can access outside.
Current Behavior

Sometimes  the host machine restart，these pods on this machine are evicted and are scheduled to other hosts.  i can use kubectl get pod -o wide to see the new pod ip, but there is no route cali interface for this pod on the host, so it cannot access outside.
After i restart the calico-node use kubectl delete calico-node**** -n kube-system,  i can get the right route for the pod.
Possible Solution

Steps to Reproduce (for bugs)

i cannot reproduce the problem in test environment
Context

Your Environment

Calico version
Orchestrator version (e.g. kubernetes, mesos, rkt):
Operating System and version:
Link to your project (optional):
kubernetes 1.8.6
calico: calico-node:v3.0.1 calico-cni:v2.0.0 calico-kube-controllers:v2.0.0

Have you reviewed the logs from calico-node, is there anything in there that suggests problems?
Also could you install calicoctl on a node with the problem and do calicoctl node status?
To be clear you are saying that the routes are not showing up on the new node that the pods are being rescheduled to or the original node that was restarted?

@rainbowfhb Calico v3.0 is very old. Please upgrade to a modern version of Calico (and Kubernetes - v1.8 is also quite old) and raise a new issue if you continue to see this behavior. Thanks.


[WIP] replace coveralls gem with coveralls_reborn

Checklist

[ ] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[ ] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[ ] I've read the Contribution Guidelines
[ ] I've updated the documentation if necessary.

Motivation and Context

Description

          1 Warning

:warning:
Pull Request is Work in Progress

  Generated by :no_entry_sign: Danger

Do NOT delete the branch please!


brunch missing during "vagrant up test"

During a "vagrant up test", while building SingularityService, the module SingularityUI is built. In SingularityUI's package.json file, the postinstall script calls brunch but returns the following error:
==> test: [INFO] > bower install --allow-root && brunch build --production
==> test: [ERROR] sh: 1: brunch: not found

However, checking the package.json everything appears fine (see below) and when I vagrant ssh into the machine, the node_modules/brunch/bin/ directory contains brunch.
Here is the excerpt from the package.json for reference:
"bin": {
    "bower": "./node_modules/bower/bin/bower",
    "brunch": "./node_modules/brunch/bin/brunch"
  },
  "scripts": {
    "start": "brunch watch --server",
    "postinstall": "bower install --allow-root && brunch build --production"
  },
  "dependencies": {
    "bower": "~1.4.1",
    "brunch": "^1.7.14",

Here is the full output for reference:
==> test: Downloaded: https://repo.maven.apache.org/maven2/com/google/guava/guava/10.0.1/guava-10.0.1.jar (1467 KB at 290.1 KB/sec)
==> test: [INFO] Node v0.10.28 is already installed.
==> test: [INFO] Found NPM version 1.4.9
==> test: [INFO]
==> test: [INFO] --- frontend-maven-plugin:0.0.23:npm (npm install) @ SingularityService ---
==> test: [INFO] Running 'npm install --color=false' in /singularity/SingularityUI
==> test: [INFO]
==> test: [INFO] ><EMAIL_ADDRESS>postinstall /singularity/SingularityUI
==> test: [INFO] > bower install --allow-root && brunch build --production
==> test: [INFO]
==> test: [ERROR] sh: 1: brunch: not found
==> test: [ERROR]
==> test: [ERROR] npm ERR<EMAIL_ADDRESS>postinstall: `bower install --allow-root && brunch build --production`
==> test: [ERROR] npm ERR! Exit status 127
==> test: [ERROR] npm ERR!
==> test: [ERROR] npm ERR! Failed at the<EMAIL_ADDRESS>postinstall script.
==> test: [ERROR] npm ERR! This is most likely a problem with the SingularityUI package,
==> test: [ERROR] npm ERR! not with npm itself.
==> test: [ERROR] npm ERR! Tell the author that this fails on your system:
==> test: [ERROR] npm ERR!     bower install --allow-root && brunch build --production
==> test: [ERROR] npm ERR! You can get their info via:
==> test: [ERROR] npm ERR!     npm owner ls SingularityUI
==> test: [ERROR] npm ERR! There is likely additional logging output above.
==> test: [ERROR] npm ERR! System Linux 3.13.0-24-generic
==> test: [ERROR] npm ERR! command "/singularity/SingularityUI/node/node" "/singularity/SingularityUI/node/npm/bin/npm-cli.js" "install" "--color=false"
==> test: [ERROR] npm ERR! cwd /singularity/SingularityUI
==> test: [ERROR] npm ERR! node -v v0.10.28
==> test: [ERROR] npm ERR! npm -v 1.4.9
==> test: [ERROR] npm ERR! code ELIFECYCLE
==> test: [ERROR] npm ERR!
==> test: [ERROR] npm ERR! Additional logging details can be found in:
==> test: [ERROR] npm ERR!     /singularity/SingularityUI/npm-debug.log
==> test: [ERROR] npm ERR! not ok code 0
==> test: [INFO] ------------------------------------------------------------------------
==> test: [INFO] Reactor Summary:
==> test: [INFO]
==> test: [INFO] Singularity ........................................ SUCCESS [01:45 min]
==> test: [INFO] SingularityBase .................................... SUCCESS [ 24.655 s]
==> test: [INFO] SingularityMesosClient ............................. SUCCESS [  6.040 s]
==> test: [INFO] SingularitySwagger ................................. SUCCESS [  7.896 s]
==> test: [INFO] SingularityService ................................. FAILURE [01:09 min]
==> test: [INFO] SingularityRunnerBase .............................. SKIPPED
==> test: [INFO] SingularityS3Base .................................. SKIPPED
==> test: [INFO] SingularityClient .................................. SKIPPED
==> test: [INFO] SingularityExecutor ................................ SKIPPED
==> test: [INFO] SingularityExecutorCleanup ......................... SKIPPED
==> test: [INFO] SingularityLogWatcher .............................. SKIPPED
==> test: [INFO] SingularityS3Uploader .............................. SKIPPED
==> test: [INFO] SingularityS3Downloader ............................ SKIPPED
==> test: [INFO] SingularityOOMKiller ............................... SKIPPED
==> test: [INFO] EmbedSingularityExample ............................ SKIPPED
==> test: [INFO] ------------------------------------------------------------------------
==> test: [INFO] BUILD FAILURE
==> test: [INFO] ------------------------------------------------------------------------
==> test: [INFO] Total time: 03:44 min
==> test: [INFO] Finished at: 2015-05-18T02:21:19+00:00
==> test: [INFO] Final Memory: 42M/100M
==> test: [INFO] ------------------------------------------------------------------------
==> test: [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.23:npm (npm install) on project SingularityService: Failed to run task: 'npm install --color=false' failed. (error code 1) -> [Help 1]
==> test: [ERROR]
==> test:
==> test: [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
==> test: [ERROR] Re-run Maven using the -X switch to enable full debug logging.
==> test: [ERROR]
==> test: [ERROR] For more information about the errors and possible solutions, please read the following articles:
==> test: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
==> test: [ERROR]
==> test: [ERROR] After correcting the problems, you can resume the build with the command
==> test: [ERROR]   mvn <goals> -rf :SingularityService
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

strangely, brunch installs fine for me (from a vagrant destroy test && vagrant up test'):
==> test: [INFO] Node v0.10.28 is already installed.
==> test: [INFO] Found NPM version 1.4.9
==> test: [INFO]
==> test: [INFO] --- frontend-maven-plugin:0.0.23:npm (npm install) @ SingularityService ---
==> test: [INFO] Running 'npm install --color=false' in /singularity/SingularityUI
==> test: [INFO]
==> test: [INFO] ><EMAIL_ADDRESS>postinstall /singularity/SingularityUI
==> test: [INFO] > bower install --allow-root && brunch build --production
==> test: [INFO]
==> test: [INFO] 18 May 13:25:54 - info: compiled 189 files into 2 files, copied 8 in 10577ms
==> test: [INFO]
==> test: [INFO] --- build-helper-maven-plugin:1.9.1:add-resource (add-generated-resources) @ SingularityService ---

No longer reproducible after the fix to #550.


Added timeout to tmate and removed extra instance

Please summarize the bugs that this PR fixes. As relevant, please indicate the issues that the PR closes.
Fixes issue where tmate session would run for way too long on failure, or run on success anyway.

closes #609

Great!  Thanks.


python: Remove workaround for Tsa

The link to scales-ppm's repo is dead, therefore 2 tests failed and had to be removed.

launch jenkins all

balfrin
:green_circle: unit testTest:green_circle:summary :green_circle: integration testTest:green_circle:clang-format-spack_info :green_circle:clang-format-spack_spec :green_circle:cosmo-eccodes-definitions-spack_info :green_circle:cosmo-eccodes-definitions-spack_spec :green_circle:cosmo-spack_info :green_circle:cosmo-spack_spec :green_circle:ecbuild-spack_info :green_circle:ecbuild-spack_spec :green_circle:eccodes-spack_info :green_circle:eccodes-spack_spec :green_circle:fdb-fortran-spack_info :green_circle:fdb-fortran-spack_spec :green_circle:fdb-spack_info :green_circle:fdb-spack_spec :green_circle:flexpart-cosmo-spack_info :green_circle:flexpart-cosmo-spack_spec :green_circle:flexpart-ifs-spack_info :green_circle:flexpart-ifs-spack_spec :green_circle:icon-ham-spack_info :green_circle:icon-ham-spack_spec :green_circle:icon-spack_info :green_circle:icon-spack_spec :green_circle:icon_extra-config-args=--disable-new_feature,--enable-old_config_arg-spack_spec :green_circle:dace_icon.-O1-spack_spec :green_circle:icon_serialization=create-spack_spec :green_circle:icontools-spack_info :green_circle:icontools-spack_spec :green_circle:int2lm-spack_info :green_circle:int2lm-spack_spec :green_circle:int2lm_+parallel-spack_spec :green_circle:int2lm_~parallel-spack_spec :green_circle:libcdi-pio-spack_info :green_circle:libcdi-pio-spack_spec :green_circle:libfyaml-spack_info :green_circle:libfyaml-spack_spec :green_circle:libgrib1-spack_info :green_circle:libgrib1-spack_spec :green_circle:libtorch-spack_info :green_circle:libtorch-spack_spec :green_circle:makedepf90-spack_info :green_circle:makedepf90-spack_spec :green_circle:metkit-spack_info :green_circle:metkit-spack_spec :green_circle:oasis-spack_info :green_circle:oasis-spack_spec :green_circle:py-cytoolz-spack_info :green_circle:py-cytoolz-spack_spec :green_circle:py-devtools-spack_info :green_circle:py-devtools-spack_spec :green_circle:py-factory-boy-spack_info :green_circle:py-factory-boy-spack_spec :green_circle:py-frozendict-spack_info :green_circle:py-frozendict-spack_spec :green_circle:py-gridtools-cpp-spack_info :green_circle:py-gridtools-cpp-spack_spec :green_circle:py-gt4py-spack_info :green_circle:py-gt4py-spack_spec :green_circle:py-hatchling-spack_info :green_circle:py-hatchling-spack_spec :green_circle:py-icon4py-spack_info :green_circle:py-icon4py-spack_spec :green_circle:py-inflection-spack_info :green_circle:py-inflection-spack_spec :green_circle:py-lark-spack_info :green_circle:py-lark-spack_spec :green_circle:py-pytest-factoryboy-spack_info :green_circle:py-pytest-factoryboy-spack_spec :green_circle:py-tabulate-spack_info :green_circle:py-tabulate-spack_spec :green_circle:py-typing-extensions-spack_info :green_circle:py-typing-extensions-spack_spec :green_circle:pytorch-fortran-proxy-spack_info :green_circle:pytorch-fortran-proxy-spack_spec :green_circle:pytorch-fortran-spack_info :green_circle:pytorch-fortran-spack_spec :green_circle:scales-ppm-spack_info :green_circle:scales-ppm-spack_spec :green_circle:xpmem-spack_info :green_circle:xpmem-spack_spec :green_circle:yaxt-spack_info :green_circle:yaxt-spack_spec :red_circle: system<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>:red_circle:install_default-scales-ppm<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>:green_circle:install_fdb_fortran-fdb-fortran<EMAIL_ADDRESS><EMAIL_ADDRESS>:green_circle:install_flexpart_ifs_version-flexpart-ifs_@fdb <EMAIL_ADDRESS><EMAIL_ADDRESS>:green_circle:install_int2lm_version_3_00_nvhpc_fixed_definitions-int2lm_<EMAIL_ADDRESS>:red_circle:install_libcdi_pio_default-libcdi-pio :green_circle:install_libfyaml_default-libfyaml :green_circle:install_libgrib1_22_01_2020_nvhpc-libgrib1_@22-01-2020nvhpc :green_circle:install_libtorch_default-libtorch<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>:green_circle:install_py_hatchling_default-py-hatchling :green_circle:install_py_icon4py_version_0_0_10-py-icon4py_<EMAIL_ADDRESS>:green_circle:install_py_icon4py_version_0_0_11-py-icon4py_<EMAIL_ADDRESS>:green_circle:install_py_icon4py_version_0_0_13-py-icon4py_<EMAIL_ADDRESS>:green_circle:install_py_inflection_default-py-inflection :green_circle:install_py_pyfactoryboy_default-py-pytest-factoryboy :green_circle:install_py_tabulate_default-py-tabulate :green_circle:install_py_typing_extensions_default-py-typing-extensions :green_circle:install_pytorch_fortran_proxy_version_0_4-pytorch-fortran-proxy<EMAIL_ADDRESS>:green_circle:install_pytorch_fortran_version_0_4-pytorch-fortran@0.4nvhpc_^pytorch-fortran-proxy<EMAIL_ADDRESS>:green_circle:install_yaxt_default-yaxt :green_circle:py_cytoolz_install_default-py-cytoolz :green_circle:py_devtools_install_default-py-devtools :green_circle:py_factory_boy_install_default-py-factory-boy :green_circle:py_frozendict_install_default-py-frozendict :green_circle:py_gridtools_cpp_install_default-py-gridtools-cpp

launch jenkins all

balfrin
:green_circle: unit testTest:green_circle:summary :green_circle: integration testTest:green_circle:clang-format-spack_info :green_circle:clang-format-spack_spec :green_circle:cosmo-eccodes-definitions-spack_info :green_circle:cosmo-eccodes-definitions-spack_spec :green_circle:cosmo-spack_info :green_circle:cosmo-spack_spec :green_circle:ecbuild-spack_info :green_circle:ecbuild-spack_spec :green_circle:eccodes-spack_info :green_circle:eccodes-spack_spec :green_circle:fdb-fortran-spack_info :green_circle:fdb-fortran-spack_spec :green_circle:fdb-spack_info :green_circle:fdb-spack_spec :green_circle:flexpart-cosmo-spack_info :green_circle:flexpart-cosmo-spack_spec :green_circle:flexpart-ifs-spack_info :green_circle:flexpart-ifs-spack_spec :green_circle:icon-ham-spack_info :green_circle:icon-ham-spack_spec :green_circle:icon-spack_info :green_circle:icon-spack_spec :green_circle:icon_extra-config-args=--disable-new_feature,--enable-old_config_arg-spack_spec :green_circle:dace_icon.-O1-spack_spec :green_circle:icon_serialization=create-spack_spec :green_circle:icontools-spack_info :green_circle:icontools-spack_spec :green_circle:int2lm-spack_info :green_circle:int2lm-spack_spec :green_circle:int2lm_+parallel-spack_spec :green_circle:int2lm_~parallel-spack_spec :green_circle:libcdi-pio-spack_info :green_circle:libcdi-pio-spack_spec :green_circle:libfyaml-spack_info :green_circle:libfyaml-spack_spec :green_circle:libgrib1-spack_info :green_circle:libgrib1-spack_spec :green_circle:libtorch-spack_info :green_circle:libtorch-spack_spec :green_circle:makedepf90-spack_info :green_circle:makedepf90-spack_spec :green_circle:metkit-spack_info :green_circle:metkit-spack_spec :green_circle:oasis-spack_info :green_circle:oasis-spack_spec :green_circle:py-cytoolz-spack_info :green_circle:py-cytoolz-spack_spec :green_circle:py-devtools-spack_info :green_circle:py-devtools-spack_spec :green_circle:py-factory-boy-spack_info :green_circle:py-factory-boy-spack_spec :green_circle:py-frozendict-spack_info :green_circle:py-frozendict-spack_spec :green_circle:py-gridtools-cpp-spack_info :green_circle:py-gridtools-cpp-spack_spec :green_circle:py-gt4py-spack_info :green_circle:py-gt4py-spack_spec :green_circle:py-hatchling-spack_info :green_circle:py-hatchling-spack_spec :green_circle:py-icon4py-spack_info :green_circle:py-icon4py-spack_spec :green_circle:py-inflection-spack_info :green_circle:py-inflection-spack_spec :green_circle:py-lark-spack_info :green_circle:py-lark-spack_spec :green_circle:py-pytest-factoryboy-spack_info :green_circle:py-pytest-factoryboy-spack_spec :green_circle:py-tabulate-spack_info :green_circle:py-tabulate-spack_spec :green_circle:py-typing-extensions-spack_info :green_circle:py-typing-extensions-spack_spec :green_circle:pytorch-fortran-proxy-spack_info :green_circle:pytorch-fortran-proxy-spack_spec :green_circle:pytorch-fortran-spack_info :green_circle:pytorch-fortran-spack_spec :green_circle:scales-ppm-spack_info :green_circle:scales-ppm-spack_spec :green_circle:xpmem-spack_info :green_circle:xpmem-spack_spec :green_circle:yaxt-spack_info :green_circle:yaxt-spack_spec :green_circle: system<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>:green_circle:install_fdb_fortran-fdb-fortran<EMAIL_ADDRESS><EMAIL_ADDRESS>:green_circle:install_flexpart_ifs_version-flexpart-ifs_@fdb <EMAIL_ADDRESS><EMAIL_ADDRESS>:green_circle:install_int2lm_version_3_00_nvhpc_fixed_definitions-int2lm_<EMAIL_ADDRESS>:green_circle:install_libfyaml_default-libfyaml :green_circle:install_libgrib1_22_01_2020_nvhpc-libgrib1_@22-01-2020nvhpc :green_circle:install_libtorch_default-libtorch<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>:green_circle:install_py_hatchling_default-py-hatchling :green_circle:install_py_icon4py_version_0_0_10-py-icon4py_<EMAIL_ADDRESS>:green_circle:install_py_icon4py_version_0_0_11-py-icon4py_<EMAIL_ADDRESS>:green_circle:install_py_icon4py_version_0_0_13-py-icon4py_<EMAIL_ADDRESS>:green_circle:install_py_inflection_default-py-inflection :green_circle:install_py_pyfactoryboy_default-py-pytest-factoryboy :green_circle:install_py_tabulate_default-py-tabulate :green_circle:install_py_typing_extensions_default-py-typing-extensions :green_circle:install_pytorch_fortran_proxy_version_0_4-pytorch-fortran-proxy<EMAIL_ADDRESS>:green_circle:install_pytorch_fortran_version_0_4-pytorch-fortran@0.4nvhpc_^pytorch-fortran-proxy<EMAIL_ADDRESS>:green_circle:install_yaxt_default-yaxt :green_circle:py_cytoolz_install_default-py-cytoolz :green_circle:py_devtools_install_default-py-devtools :green_circle:py_factory_boy_install_default-py-factory-boy :green_circle:py_frozendict_install_default-py-frozendict :green_circle:py_gridtools_cpp_install_default-py-gridtools-cpp

The link to libcdi is still https://gitlab.dkrz.de/mpim-sw/libcdi, so it looks more like a permission error to me.

But since we anyway don't really use these packages one could also completely remove the tests, not just commenting.

The problem is scales-ppm. These links are dead:
    homepage = "https://www.dkrz.de/redmine/projects/scales-ppm"
    url = "https://www.dkrz.de/redmine/attachments/download/500/ppm-1.0.6.tar.gz"
    list_url = "https://www.dkrz.de/redmine/projects/scales-ppm/files"

But since we anyway don't really use these packages one could also completely remove the tests, not just commenting.

Good point! I created an issue for it: https://github.com/C2SM/spack-c2sm/issues/1006


fix: validation added for empty path and fetched data in withModel()

Can you add unit test coverage as well? Looks good to me.

@niekraaijmakers Thanks for the review. I've added changes to improve test coverage.

@pfauchere WDTY? looks good to me.

who has rights to merge?  @grubyak can you review ?


KAFKA-17304; RaftClient API makes writing to log explicit

RaftClient API is changed to separate the batch accumulation (RaftClient#prepareAppend) from scheduling the append of accumulated batches (RaftClient#schedulePrepatedAppend) to the KRaft log. This change is needed to better match the controller's flow of replaying the generated records before replicating them. When the controller replay records it needs to know the offset associated with the record. To compute a table offset the KafkaClient needs to be aware of the records and their log position.
The controller uses this new API by generated the cluster metadata records, compute their offset using RaftClient#prepareAppend, replay the records in the state machine, and finally allowing KRaft to append the records with RaftClient#schedulePreparedAppend.
To implement this API the BatchAccumulator is changed to also support this access pattern. This is done by adding a drainOffset to the implementation. The batch accumulator is allowed to return any record and batch that is less than the drain offset.
Lastly, this change also removes some functionality that is no longer needed like non-atomic appends and validation of the base offset.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@jsancio thank for the patch! I had a few questions after a brief review
If I understand this change, it looks like we are no longer tracking the next expected write offset and instead just appending to Raft to learn the last offset of the batch.

I added a description to the PR and I think I address the motivation of this change there. Let me know if you have any other questions.

Is it safe to schedule the write to Raft before the replay calls? I think it probably is. These two operations can tasks (writing to log and updating in-memory state) can probably be thought of as concurrent. As long as the in-memory state creates a snapshot with the correct offset, it should be fine. WDYT?

It is not safe to schedule write before replay but this change doesn't do that. At a high-level the new controller algorithm for write events is:

generate the cluster metadata records
stage them in the RaftClient so that the offsets are allocated (RaftClient#prepareAppend)
replay the cluster metadata records against the active controller state machine
tell the RaftClient client that is can write/append the staged batches to the log (RaftClient#schedulePreparedAppend)

Do we need to track nextWriteOffset any more if we aren't using it? We the nextWriteOffset to set the broker epoch when registering brokers. I think this just needs to be monotonic relative to previous broker epochs. Maybe we can remove nextWriteOffset from OffsetControlManager and just track the "last written offset" instead?

Isn't that the same thing? Isn't "last written offset" = "next write offset" - 1?

In the previous code we tracked the next expected offset and passed it down to Raft each time we did an append. AIUI, this sort of acted like an optimistic concurrency control. E.g., "only do this operation if the next offset is X". We still have the controller epoch which serves a similar function, but I'm curious if there are side effects to removing the external offset tracking.

Yes. The issue with that solution is that is doesn't allow for the KRaft leader to append control records to the log. Appending control records to the log would make it so that the controller known offset doesn't match the kraft leader's LEO. The KRaft leader needs to append control records to implement dynamically adding and removing controller/voters.
Take a look at the description of the PR. I have updated it since you last reviewed this PR. I tried to motivate the problem and explain the solution.


Removed ineligible node

Per the requirements outlined in lib/nodes.go, a validator must be active for at least 30 days (1 month) prior to being eligible for the centralized sources list. The requirements state the following:

If you run a DeSo node that has been online for at least one month you may submit a pull request to add your node to the list of nodes.

The node located at node.deso.org does not meet these requirements, as it has only been online since November 9th. Because of this, the node is ineligible to be listed here until December 9th.
This PR removes the ineligible node form the list to uphold the requirements established by the core team for this centralized list. Should the owner decides they want to re-list their node after December 9th, they should create a PR as outlined in the requirements quoted above.

The following sources demonstrate the ineligibility for this node:

This node has been running for two months and was just recently assigned a domain

Come on @maebeam, idk if we can trust this diamondhands guy with running nodes.

This is the content I want on GitHub 🤣
@HPaulson LFG!


Add support for establishing per-shard connections using Scylla shard-aware ports

In commit 1572b9e41cd02e8b676404ba72a549398d281a66, Scylla gained
support for so-called "shard-aware" ports. These ports support the same
Cassandra native protocol as the regular native transport ports.
However, unlike the regular ports, shard-aware ports allow the driver to
choose the shard that will handle the connection by choosing an
appropriate source port.
Currently, regular native transport ports employ a load-balancing
strategy that assigns, for an incoming connection, the shard that has
the least amount of connections assigned. Until now, the driver worked
by opening new connections until a single connection per shard is
established. When a connection to an already connected shard is opened,
it is not immediately closed - only after the number of opened
connections exceeds 10x the number of shards. This behavior does not
work well in some realistic scenarios:

When many shard-aware clients connect at once, the load-balancing
strategy will not work well. Clients will open a very large number of
connections before reaching all of the shards.
When there are non-shard-aware clients connected to a node, the
distribution of their connections per shard may be uneven. If one
shard is occupied by many more connections than the others, it will
prevent the current load-balancing strategy from assigning a
connection to that shard, unless a large number of connections to
other shards is established first.

Shard-aware ports allow the driver to completely avoid those problems by
choosing towards which shard it wishes to connect to. The first
connection is still established towards a regular native transport port,
and the following connections for remaining shards can be established
towards shard-aware ports.
This PR adds support for establishing per-shard connections using
the shard-aware ports.

I have some ideas for the integration tests:

Start 10 Sessions concurrently and observe that no excessive connections were closed.
Provide a malicious DialerExt that changes source port -> source port + 1 (so that it always connects to a wrong shard), and see how the driver works around that.
Observe that no connections are made to the shard-aware port if it is not enabled in config.

Previously, I had some doubts on how to approach doing them, but I think I have an idea. I'll try to send them over the weekend.

I added three tests according to the scenarios listed in my previous comment. Those three scenarios run in two setups: with mocked and real Scylla. I made the mocked version because AFAIK we don't have a released version yet that support shard aware ports.

@mmatczuk @zimnx I added tests for the mechanism of establishing per-shard connection. I consider this PR to be ready for review now - could you take a look?
I left some comments with questions about things that I had doubts about how they should be implemented.
PS: CI tests passed https://travis-ci.org/github/scylladb/gocql/builds/724127399

@mmatczuk @zimnx ping

@zimnx Yes, I agree that it will be cleaner. I probably needlessly fixated on the idea that shard/port information should be passed from the top to the connect function. I also think it is possible to hide the shard assignment/port allocation logic inside the dialer.
Thanks for the push in the right direction, I'll update the PR according to your suggestion.

@zimnx

When control connection finds out that cluster is Scylla not Cassandra, we could wrap config dialer with our own.

After closer inspection it turns out that it's not that simple. We have a separate dialer for each session, not for each host. The Dialer.DialContext method is called from within a method of the Session object, and we have no information about the host pool there. To connect to the shard aware port, the dialer needs to know what the shard aware port is, and towards which shards we do not have a connection yet.
I still think that it is possible to reduce the amount of changes in non-scylla specific code. I'll try to move the logic of allocating shard number to connect to outside hostConnPool. I don't know how to get rid of scyllaConnParams, though.

@zimnx I adjusted the PR so that it intersects the upstream code less. I could not get rid of the scConnParams due to the reasons in my previous comment. If you have any suggestions how to decrease changes in non-Scylla specific code - I'm all ears.
Tests are green: https://travis-ci.org/github/scylladb/gocql/builds/727829237

Passing the source port vs Dialer...
Users need to be able to specify the custom dialer whenever they want, and we should break no code.
I'd suggest to add and export ScyllaShardAwareDialer type (not interface) that implements gocql.Dialer interface and read the sourcePort from a context value.
type ScyllaShardAwareDialer struct {
	net.Dialer
}

func (d *scyllaShardAwareDialer) DialContext(ctx context.Context, network, addr string) (net.Conn, error) {
	sourcePort := ctx.Value(ScyllaSourcePortCtx)
	...
}

Case 1: If I have a code that creates a custom net.Dialer I can just wrap it with ScyllaShardAwareDialer type.
Case 2: If I have a special code to open connections that does some kind of routing this will be broken by design ... but can be fixed be reading the value from context with gocql.ScyllaSourcePortCtx.
My suggestion solves case 1 to some extent or makes the migration path easier.
The code to set the value would live in scyllaConnPicker, we should also instantiate a default one in newScyllaConnPicker.

When it comes to the sleeps I think we should avoid them and fallback to connection pruning scyllaConnPicker already implements.

Updated to v2: I applied @mmatczuk 's suggestions about how this PR should be reworked, and applied other suggestions which were still applicable to the reworked version.
The old version can be found here: https://github.com/piodul/gocql/tree/port-based-load-balancing-v1

@mmatczuk
I just remembered something. I talked with @jul-stas some time ago and he told me that Linux is biased when allocating a source port for a new connection - namely, the port is always even (link to the commit in the kernel).
This can cause a bad situation if:

nodes in the cluster support the shard-aware port,
nodes have an even number of shards,
there is no NAT translating source ports between the driver and cluster nodes,
the user has a custom Dialer but did not update it yet.

In the case described above, the v2 implementation will establish connections to only a half of the shards.
Although I think this should be a rare case, I feel that it should be noted somewhere... I'm not sure if, and where to put it?

@mmatczuk ping

Ping @piodul

@mmatczuk Sorry for the delay. I pushed an updated version with fixes to review comments. All fixes are in new, mostly separate commits.
Apart from that, I would like to once more discuss the idea of falling back to the use of non-shard-aware port when we detect a case in which the shard-aware port cannot be used. I preemptively updated my PR so that it implements the fall back behavior.
These are the cases that I know of when the shard-aware port won't be usable:

The shard-aware port is unreachable (but the non-shard-aware port is reachable),
The shard-aware port is behind NAT which translates source ports,
User did not update their custom implementation of Dialer.

If we won't fall back to the non-shard-aware port but the driver keeps trying to use it, we may get stuck trying to fill hostConnPools but won't succeed in doing so. Some users who don't know about the feature might get annoyed if they upgrade their client and the cluster and will suddenly get worse performance. Even if we warn about it in the logs, it might be inconvenient to have to disable the shard-aware port manually.

In case of 1, we can try connecting to the shard-aware-port first, and if it doesn't succeed, then we can immediately try the non-shard-aware port. This kind of problem can't be detected without false positives, so I think it's better always to try both ports than disable the port temporarily.
In case of 2 and 3, we can stop calling the shard-aware port for a while if we detect that a wrong shard is chosen. This is surely a problem with configuration, so it's expected to persist for some time, and it's easier to implement via timeout than retry.

I documented those issues inside README.md so that the user can become aware of them when they read it. I also print a warning in case situation 2 or 3 is detected (I don't do it for 1 because there is no way to do it without false positives).
Please let me know what you think. I can change it back to not using the fall backs, but I think that the driver will behave a little nicer now.

I'm not sure how effective scyllaShardAwarePortFallbackDuration is and what does it actually mean.
Typically application will start fill pools and use connections, when session is closed so are pools and connections.
I'd suggest to remove the backoff functionality and replace it with a hard fallback.

@mmatczuk
My idea was that the fallback was supposed to help in the following situation:

Client application connects to a node, but detects that source ports are translated by NAT, so it falls back to using the old port,
The NAT issue is fixed in the meantime,
Fallback period ends,
Next time the node restarts, the shard-aware port will be used to connect.

I admit that this scenario is a bit contrived, and I am not knowledgeable enough in networking if it is realistic - if it isn't, I can change it to the hard fallback. In such case, as a last resort, the client application can be restarted to clear the hard fallback flag.


Dex Error

It has been broken for hell long, Hope this can be fixed.

Resolved in https://github.com/Sceleratis/Adonis/commit/01013297e80c895d1c4c2c5c1b9407f2a0a929fa


CTAS stuck on pending

On creating table as with query results (CTAS), it get stuck on pending status. I have marked "Allow CREATE TABLE AS" as well. What is the issue here? Can anyone suggest me ?

+1

Yes, appears to still be an issue.

Started working on it


Remove ViewEncapsulation.NONE from HCATooltipComponent

Update HCATooltipComponent to use global tooltip styles, removing the need to set the view encapsulation of the component to NONE. See FileLocationCopyComponent for an example.

superseded by dx


refactor(runtime-core): enum attribute refers to other attributes of itself

enum attribute refers to other attributes of itself, you can remove enum name.
An example modeled after ShapeFlags.
enum Example {
  A   =  1
  B   =  1 << 1
  C   = Example.A | Example.B
}

But we can do
enum Example {
  A   =  1
  B   =  1 << 1
  C   = A | B
}

@posva hi, Do I need to solve the CI error caused by useContext?


add links to fields in license submittal form

can someone update the text in the license submittal form pop-up to reflect the addition of the links as is shown here https://github.com/spdx/license-list-XML/pull/862
(assuming links are an option in the pop-up text)

can we also fix the header so it says, "Submit a new license to the SPDX License List"
(not "Licenses List" :)
thanks!

Changes merged with https://github.com/spdx/spdx-online-tools/pull/146


Backwards compatibility in payment details

https://github.com/interledger/open-payments/blob/master/documentation/docs/accounts.mdx#payment-details
This came up in a discussion today which prompted me to file this issue. Why is the payment details response not backwards compatible with the SPSP response? We could support existing SPSP clients with no changes by keeping the same content type and the same destination_account and shared_secret, and just add open-payments fields additively. While I understand there's a workable migration path it seems that just making the response body backwards compatible would be simpler

The current proposal is backwards compatible using the content-type as a way to disambiguate between SPSP and Open Payments.
This takes advantage of the fact that SPSP explicitly uses a non-standard content-type allowing open payments to define responses for content types such as application/json and text/html without breaking existing SPSP clients.
The same data is returned but using a different JSON schema for Open Payments based on camel case and use more appropriate property names.

SPSP
	Open Payments

Content Type
	`application/spsp4+json`
	`application/ilp-stream+json`

Destination ILP Address
	`destination_account`
	`ilpAddress`

Shared Secret
	`shared_secret`
	`sharedSecret`

Open Payments servers SHOULD support both content types for now but clients SHOULD move to Open Payments so we can begin transitioning to a state where all clients and servers support the full set of Open Payments use cases.

If we wanted to we could remove the requirement for everybody to migrate their SPSP endpoints though, just at the cost of having these camel case fields.
We did intentionally choose the name destination_account over ilp_address in the past, seeing as destination_account describes what the field is, rather than the format of it.
While technically non-breaking right now, we'll need to manage this migration. It seems like a fairly steep price just for camel case.

We did intentionally choose the name destination_account over ilp_address in the past, seeing as destination_account describes what the field is, rather than the format of it.

What about destinationAddress? That's what I'ved use internally since I don't feel either are sufficiently descriptive ("account" is pretty overloaded)

:+1: I agree that's a better name than destination_account or ilpAddress but I'm still not bought in on the idea of migrating just to change some field names

While technically non-breaking right now, we'll need to manage this migration. It seems like a fairly steep price just for camel case.

Sure, but we're setting a standard for a much wider set of schemas so we're trying to fix this early before people start implementing invoices and mandates etc.
A compliant server will serve both Open Payments and SPSP clients but with a goal to moving SPSP clients to Open Payments over time.

What about destinationAddress? That's what I've use internally since I don't feel either are sufficiently descriptive ("account" is pretty overloaded)

👍


Better alternative to this->redirect() ?

(Discussion started at #4433 )
At the moment, the implementation of redirect() in AbstractController builds a redirect response, sends it to the client and terminate the execution.
This implies that the middlewares are not called.
A solution could be to throw a specific exception in the redirect method and intercept it in the DefaultDispatcher::dispatch() method.
For instance:
public function redirect($to/*, ...*/)
{
    $url = $this->app->make('url/manager')->resolve(func_get_args());
    $response = $this->app->make(ResponseFactoryInterface::class)->redirect($url);
    throw new ResponseReady($response);
}

And in DefaultDispatcher::dispatch():
public function dispatch(SymfonyRequest $request)
{
    $response = null;
    try {
        // Current code
    } catch (ResponseReady $x) {
        $response = $x->getResponse();
    }

    return $response;
}

The problem is that this solution is not backward compatible: current calls to redirect could be enclosed in try... catch constructs, and this new ResponseReady exception would be intercepted by the code, so we should add a new method (call it redirectClean, redirect2).

This is an issue today and it's something I've actively avoided. IMO redirect responses not flowing back through middleware isn't really a huge deal, but you're absolutely right that it's an issue and will be a problem in the future.
That said, in consideration of this I think it's important to avoid using try/catch as a flow control. Today we can redirect by doing:
<?php
class Controller
{

    public function someView()
    {
        return RedirectResponse::create($url);
    }

}

There's value in having a different method like ->createResponse or ->createRedirect available on the controller class (perhaps in a trait) so that we can return $this->createRedirect($to); instead of creating it ourselves.
Now that's cool and all but try/catch flow control is actually pretty nice. Let's look at your suggestion (with the change that we're going to use middleware for it and not the dispatcher).
<?php
class Controller
{

    public function someView()
    {
        throw new \Concrete\Core\Http\Exception\PermanentRedirectException($to);
    }

}

And our middleware:
<?php

class HttpExceptionMiddleware implements MiddlewareInterface
{

    /**
     * Run the next middleware and catch various http exceptions
     */
    public function process($request, $frame)
    {
        try {
            return $frame->next($request);
        } catch (RedirectException $e) {
            // We got a redirect exception
            // might be a PermanentRedirectException or a TemporaryRedirectException
            return $this->handleRedirect($e);
        } catch (HttpException $e) {
            // Catch generic http exceptions and handle them.
            return $this->handleOtherExceptionType($e);
        }
    }

}

Now I really like this flow, the only thing is that again exceptions shouldn't be used to control flow and "PermanentRedirectException" does not sound like an exception case to me. Though you could argue that since the current request is invalid, we throw an exception and recommend the client make a new request.
I'd be happy seeing this implemented either way. I'd definitely prefer a middleware if you're going to use exceptions.

IMHO this is still valid... The core currently uses these two ways of redirecting clients:

Using the redirect() method:$this->redirect('path');

but it breaks the standard request->response flow (for example, middlewares are not executed)
Using some code like this:return $this->app->make(ResponseFactoryInterface::class)->redirect(
    $this->app->make(ResolverManagerInterface::class)->resolve(['path']),
    301
);

but it's really ugly...

Yeah, the second is just horrendously ugly. It's why I don't use it.
I think we ought to un-deprecated $this->redirect() and simply make it work the way number 2 works. We get the nice syntax of number 1 without terminating before middlewares run.

Replaced by https://github.com/concrete5/concrete5/issues/8361


Fix Profilers - Remove *Profiler from Contexts

This PR fixes profiling in MQE. See #207 as well, which offers a different solution.
This change moves the *Profiler pointers out of the ExecutionContexts, EvaluationContexts, and the FetchSingle/MultipleRequests.
Instead, the *inspect.Profiler pointer is placed exclusively in the ProfilingMetadataAPI, the ProfilingTimeseriesStorageAPI, and the ProfilingCommand.
However, because of this, it is not possible to profile individual FetchSingleSeries calls, since the ProfilingTimeseriesStorageAPI isn't able to capture these calls (single the blueflood object explicitly invokes the methods on itself).
In general, this might not be a problem (for example, a backend which uses batched requests wouldn't have any meaningful single-series requests to profile).
PR #207 goes in a different direction, instead getting rid of the ProfilingAPI types and exclusively passing the *inspect.Profiler pointer around in the contexts.

I think between this and #207 I'm leaning toward this one. My one concern would be that we lose profiling information from within the query parser directly. Have we ever had performance issues in there? My guess is no, but I want to make sure we've considered it.

Actually, maybe the right answer is a hybrid between #206 and #207. In an ideal world a request would come in which would imply a 'context' that could accumulate profiling data. I don't necessarily think there was a problem with the *context objects carrying a profiler since it made it easy to propagate. Then, if the query builder creates FetchSingle/Multiple requests it could propagate the same profiler to those and it would be up to the underlying implementation to signal profiling events. Then by the time everything is done the final request would have an accurate + complete profiling tree. Does that make sense?

We've never actually had profiling information on the parser- so I can't say for sure that it was never slow, but it has never seemed to be a problem either. (PEG allows linear time parsing, so it's unlikely that there are any pathological inputs).

@cchandler what you described is essentially #207, where the *Profiler is carried first in the ExecutionContext, then in the EvaluationContext, and then put into the FetchMultipleSeriesRequest and then (if needed) into the FetchSingleSeriesRequest.
The only real disadvantage towards #207 is that every API has to do its own profiling to be complete and consistent, because something that wraps up the Blueflood API can't record the calls it makes to its own methods.

@Nathan-Fenner Yeah, you're right. I thought about it more at the gym last night :-). I'm more strongly in favor of #207 but instead of making that second parameter on the MetricMetadataAPI a profiler, something like a MetricMetadataAPIContext that happens to have a profiler on it. That way we have an auxiliary struct we can pass around with ancillary capability on it without polluting the API excessively. That will also let an underlying implementation access a profiler if it needed it.

#206 is closing in favor of #207


Choosing a style for our blog

We will need to create a wireframe of our blog style (only the main page and the blog post page are required, as it is just a guide not a complete design overview)
-[ ] we will create some scss files to match our prefered style (mainly color and font as the main css will be handle by bootstrap)

not a valid issue we cannot push a dseign like a feature, but the design as been chosen


[MWPW-135726] Tightened Check on YT Links

With the new way we are converting YouTube links to modals and embedded videos, it was picking up unintended YT links, such as account pages. See the subscribe section, where the button attempts to open the link as a modal video.

Resolves: MWPW-135726
Test URLs:

Before: https://main--express--adobecom.hlx.page/express/community
After: https://mwpw-135726-yt--express--adobecom.hlx.page/express/community?lighthouse=on

Codecov Report

Merging #293 (a5afa8d) into stage (e18d45e) will decrease coverage by 0.11%.
Report is 3 commits behind head on stage.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##            stage     #293      +/-   ##
==========================================
- Coverage   48.85%   48.74%   -0.11%
==========================================
  Files          32       32
  Lines        9614     9615       +1
==========================================
- Hits         4697     4687      -10
- Misses       4917     4928      +11

Files Changed
Coverage Δ

express/blocks/shared/video.js
34.47% <100.00%> (+0.22%)
:arrow_up:

... and 2 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Update AMDS Firmware for Timing Manager in AMDC

This PR is a mild revision to the AMDS Firmware that makes its side of the interface compatible with the new AMDS driver and new Timing Manager IPs introduced in v1.3 of the AMDC Firmware.
This is a relatively small code change on the AMDS firmware side. The code that is called to transmit the data from the AMDS to the AMDC driver over UART was previously in an interrupt context. Now that the data transmission is meant to happen as soon as all the daughtercards have been sampled, this code is no longer executed by its own interrupt.
Therefore, the UART transmission ISR has been moved into the function "transmit_samples()", which is called from the ADC sync interrupt context after sampling is completed.
Making this change also allowed me to remove the "ignore next sample" issue, since the sampling will no longer go out-of-sync  with the PWM carrier due to data transmission.
I still need to update docs.amdc.dev page on the AMDS' firmware. I will do so once we complete v1.3 in the AMDC repo.

Hey @codecubepi , this PR needs the following before review & close:

[ ] Test these changes with the old AMDS driver on the AMDC side for sanity sake
[ ] Test these changes with the new AMDS driver on the AMDC side for real functionality sake
[ ] When v1.3 in AMDC-Firmware is ready for review, this PR is also ready for final review

The default AMDS firmware in this PR works fine, but exhibits a rather large jitter in timing---I believe this issue has been present in the AMDS firmware for years. The end result is that, from the AMDC perspective, the AMDS total sampling time has around 1 us of jitter. This was observed by @annikaolson during testing of the new Timing Manager feature in the AMDC FPGA.
I was doing some testing in the lab to try to figure out why and reduce the jitter. There is no reason the AMDS shouldn't behave EXACTLY the same way for each sampling instance.
I found the issue: the AMDS firmware is totally interrupt-driven: the GPIO EXTI ISR for the SYNC_ADC signal from the AMDC triggers the ADC sampling etc. However, there is another ISR lurking, the default SysTick ISR. In the current firmware, the SysTick ISR is actually higher priority vs. the SYNC_ADC ISR. Therefore, sometimes, it fires during the sampling which causes the large jitter as the MCU handles the SysTick.
Since the AMDS does not use the SysTick feature, we can simply disable the ISR on boot. Right before the while(1) loop in the main.c file, add this line of code:
// Disable the SysTick ISR
//
// The SysTick ISR causes jitter in the firmware operation,
// and since this project does not use the SysTick features,
// we do not need it to run during operation!
//
// Set bit 0 to 0
SysTick->CTRL &= 0xFFFFFFFE;

Based on the scope testing, this reduces the jitter to about 70 ns (about 12 clock cycles), which is simply the MCU ISR handling jitter. Now, the AMDC won't see hardly any jitter when sampling from the AMDS. However, this fix only reduces the jitter---there is still around 10us of latency for the total AMDS sampling and data transmission.
@codecubepi can you add the line of code above to this PR and confirm the AMDS still runs per your local build? Thanks!

Thanks codecubepi.
One comment for us to discuss---I know this code works, has been tested pretty extensively, etc. So, I hesitate to change anything. However, if you read the ADC code, it has some extra complexity with two memory buffers that it ping-pongs between due to the old ISR operation. However, now, since there is only 1 ISR context that does everything, it does not need this complexity. It would be nice to simplify the code a bit, but I am not sure we need to invest the time to do that, test it, etc.... what do you think?

Well, if I were to fix the code to address the tab/space issue, I might as well just remove the unnecessary buffer code (and do some retesting).
Otherwise it'd be easy to open an issue and have a be a "good first issue" for future contributors... but in all reality it could turn into an issue that never really gets addressed... I think the first option of me just fixing it and retesting is probably the better way to go 🙃

@npetersen2
I took care of removing those obselete double buffers. I ran a hardware test with the fixed ADC data flushing, to verify that the AMDS data still matches what is seen by the AMDC's on-board ADC:

So nice to have clean code :) Thanks codecubepi
Best code is no code---115 lines removed!

Haha you're welcome. I can delete more if it'll make you even happier 😂

Note from @elsevers : We should start tagging AMDS releases with a version number that matches the AMDC Firmware version number, so user's know when firmware is compatible. So the previous commit on develop would be tagged v.1.2.x, and this merge would get tagged as v1.3.x.

Per the release of AMDC-Firmware v1.3.0, I believe this PR should be merged, correct @codecubepi ?

Per the release of AMDC-Firmware v1.3.0, I believe this PR should be merged, correct codecubepi ?

Yes, let's merge this! See my comment above about version tagging in this repo to match AMDC-Firmware.

Note from @elsevers : We should start tagging AMDS releases with a version number that matches the AMDC Firmware version number, so user's know when firmware is compatible. So the previous commit on develop would be tagged v.1.2.x, and this merge would get tagged as v1.3.x.

@codecubepi, I compared notes with @npetersen2 on this and we decided on another approach to handle this. From @npetersen2 's message:

The way you suggested could work, but I worry it will cause too much overhead, and might confuse folks to have X releases that are all exactly the same code... e.g., if the AMDS stays constant, could be easily 10+ releases for "no reason"
The way this is usually done I believe (e.g., in python) is for the AMDS to be released on its own vA.B.C numbering as makes sense, then provide a "requirements" file in the AMDC for each release saying it needs AMDS >= v2 etc.
I could see either way working, but I feel it just adds some overhead to always keep releasing the AMDS when there are no changes, plus I am not sure that codebase will change too much
A future idea would be that the AMDC can query the AMDS at boot-up to determine the firmware version to ensure compatibility :slightly_smiling_face:
Since, for now, this is really strictly a user/human issue, I guess keeping it in the docs.amdc.dev website makes sense, probably on the "https://docs.amdc.dev/getting-started/user-guide/amds-interface/" page near the top, a new section about installing the correct AMDS firmware and a table of compatible versions between the AMDS/AMDC

@elsevers @npetersen2
Yeah, this is a completely fair concern. I'm willing to concede 😄


net/haproxy: automatically add inspect-delay

If you use ACLs which need to inspect the Server Name TLS extension (SNI) you are required to add the directives (see the Docs):
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }

Currently these directives can be placed in the Option pass-through but then there is a waring that they are placed at the wrong position:
[WARNING] 161/133608 (42137) : parsing [/usr/local/etc/haproxy.conf:113] : a 'tcp-request' rule placed after a 'use_backend' rule will still be processed before.
Configuration file is valid

With this PR the directives are automatically placed before the use_backend directives but only if SNI ACLs exist. This could also be done via an extra configuration option, but I decided to do this automatically as there is no change required the model/gui/etc.

@MrRoundRobin Have you considered setting the inspect-delay by adding a Rule?
The following rule should do the job:

Next place the new rule before your existing rules:

This results in the following configuration in this example:
    # ACL: check sni value
    acl acl_5eeb1a404f72a3.01187173 req.ssl_sni -m sub -i example

    # ACTION: add tcp inspect delay
    # NOTE: actions with no ACLs/conditions will always match
    tcp-request inspect-delay 5s

    # ACTION: use backend for sni match
    use_backend testing_backend if acl_5eeb1a404f72a3.01187173

Does this work for you?
I'm not sure if the check for req_ssl_hello_type is strictly required in this case. If that is the case I would add support for it to the ruleset.
I do understand that adding these things automatically would make things a little bit easier. But on the other hand it would make the ruleset less flexible. I would argue that TCP rules are targeted to experts, so making it easy is not the top priority if it comes at the cost of flexibility. :)
And adding the rule manually doesn't cost much, one has to build the inspec-delay rule only once and could re-use it many times.

Didn't know that this is possible with rules, i'll try and come back to you

@MrRoundRobin Yeah, all these configuration options in all these different places can be quite overwhelming at times – even for me and I've created this plugin. :D I'm absolutely open for suggestions on how to improve the presentation and/or the wording!


Typo in index.redirects: RelRelPermalink instead of RelPermalink

Description
I think there is a typo in file index.redirects, which prevents redirects to work (hugo fails to compile if an alias is created in any content markdown).
The content of the file is:
{{- range $p := .Site.Pages -}}
{{- range .Aliases }}
{{ . }} {{ $p.RelRelPermalink -}}
{{- end }}
{{- end -}}

I think $p.RelRelPermalink should be replaced with $p.RelPermalink.
As a workaround, I overwrote this file with its copy in the site directly, replaced the typo above, and now it works fine.
Steps to reproduce

Create a site using Doks template child theme
Create a markdown in the content folder, and add an alias in the front matter, e.g.:

aliases:
  - /Install-LDAPCP.html

Then start the server

Expected result
Compilation works
Actual result
Compilation fails
Environment
{
  'hugo-ldapcp': '0.1.0',
  npm: '6.14.13',
  ares: '1.17.1',
  brotli: '1.0.9',
  cldr: '38.1',
  icu: '68.2',
  llhttp: '2.1.3',
  modules: '83',
  napi: '8',
  nghttp2: '1.42.0',
  node: '14.17.0',
  openssl: '1.1.1k',
  tz: '2020d',
  unicode: '13.0',
  uv: '1.41.0',
  v8: '8.4.371.23-node.63',
  zlib: '1.2.11'
}

Fixed w/ 819cbc3ae8408cd1bf195149f9290542d90cb5e4


Set 'gc.autoDetach' to false to be executed 'git gc' in the foreground by some git commands

What this PR does / why we need it:
Set 'gc.autoDetach' to false to be executed 'git gc' in the foreground by some git commands
Which issue(s) this PR fixes:
Fixes #4760
Does this PR introduce a user-facing change?:

How are users affected by this change:
Is this breaking change:
How to migrate (if breaking change):

✅ tested on local :)
log↓
received a plan-preview command to handle	{"command": "c0c563fb-7a78-43d3-ad5e-8e45f0f7cbf8"}
start building planpreview result for command c0c563fb-7a78-43d3-ad5e-8e45f0f7cbf8	{"command": "c0c563fb-7a78-43d3-ad5e-8e45f0f7cbf8"}
cloning ffjlabo-dev for the first time	{"repo-id": "ffjlabo-dev", "remote": "XXX", "repo-cache-path": "/var/folders/th/pq_q9v6j6_n_0fgx6v1_zp09_2tx_x/T/gitcache651340412/ffjlabo-dev"}
cloning a repo from cached one in local	{"repo-id": "ffjlabo-dev", "remote": "XXX", "repo-cache-path": "/var/folders/th/pq_q9v6j6_n_0fgx6v1_zp09_2tx_x/T/gitcache651340412/ffjlabo-dev", "src": "/var/folders/th/pq_q9v6j6_n_0fgx6v1_zp09_2tx_x/T/gitcache651340412/ffjlabo-dev", "dst": "/var/folders/th/pq_q9v6j6_n_0fgx6v1_zp09_2tx_x/T/plan-preview-builder-1425043400/1752730028"}
setting gc.autoDetach	{"repo-id": "ffjlabo-dev", "remote": "XXX", "repo-cache-path": "/var/folders/th/pq_q9v6j6_n_0fgx6v1_zp09_2tx_x/T/gitcache651340412/ffjlabo-dev", "gc.autoDetach": true}
successfully reported a failure command	{"command": "c0c563fb-7a78-43d3-ad5e-8e45f0f7cbf8"}

repo setting↓
% cd /var/folders/th/pq_q9v6j6_n_0fgx6v1_zp09_2tx_x/T/plan-preview-builder-1425043400/1752730028                    (git)-[main|merge]
% /var/folders/th/pq_q9v6j6_n_0fgx6v1_zp09_2tx_x/T/plan-preview-builder-1425043400/1752730028
% git config --get gc.autoDetach                                                                                (git)-[main|merge]
true

Ooops... I mistook the default value... not true but false... Sorry I will fix it 🙏


Bring Noivern and Reuniclus to BL2

Noivern and Reuniclus have been banned by the RU council

Thanks for contributing, but I didn't notice this pull request myself :cry:.

lol dont worry about it dude


taggedTemplateLiteral Error in swc

related: https://github.com/swc-project/swc/pull/2939
Module parse failed: Unterminated string constant (55:8)
File was processed with these loaders:
 * ./.yarn/__virtual__/swc-loader-virtual-2d6a6ef42d/0/cache/swc-loader-npm-0.1.15-1812613e13-dd3b5893cc.zip/node_modules/swc-loader/src/index.js
You may need an additional loader to handle the result of these loaders.
| function _templateObject() {
|     var data = _taggedTemplateLiteral([
\n" padding: 1rem;
|     ]);
|     _templateObject = function _templateObject() {

The issue seems resolved, but some deps(ex. monaco-editor) requires css-loader.
It was intended to not using css-loader for performance, but for compatibility, and improving performance of css parser via Rust in near future, from now, I will add legacy css-parser in template.
The css-parser will be replaced after brand-new css parser(ex. https://github.com/postcss-rs/postcss-rs, https://github.com/parcel-bundler/parcel-css) has stabilized.


Setting up more than one repository for Azure Pipelines

This guide does a good job of describing how to set up the initial connection between GitHub and Azure Pipelines for a single repository.
What is not obvious (to me) is what the expected way to deploy repositories 2, 3, 4, etc...
This page describes a best practice of having a 1:1 relationship between GitHub repository and Azure Project. This seems to make sense and is roughly what I want to do.
But once I have the Azure Pipelines app installed in my GitHub organization, I no longer see any way to automatically create or provision Azure Pipelines projects without re-running the configuration page of the Azure Pipelines App. The problem with this is that only the GitHub organization admin seems to be able to do this (it's documented that a repo admin should be able to as well, but I did not find this to be the case).
On the Azure Pipelines side of things, it looks like the connection is only established to one project at a time. The app connection isn't shared across the whole Azure Pipelines organization as a service connection. This prevents someone from creating a project on the Azure side and simply utilize the existing connection.
Any clarification on what the expected or best practice flow for setting up multiple repositories is would be greatly appreciated.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: bfba9a21-e0f9-4fc6-43fc-bfdc51af31d3
Version Independent ID: d93c7852-ce63-a6d0-417a-45f8cf2fc522
Content: Build GitHub repositories - Azure Pipelines
Content Source: docs/pipelines/repos/github.md
Product: devops
Technology: devops-cicd
GitHub Login: @DavidStaheli
Microsoft Alias: dastahel

Thanks for your question. It looks like you're working through an issue with your scenario or implementation, rather than an issue with the documentation. Here are a couple of options where you might consider asking your question:

Azure DevOps on Stack Overflow
Azure DevOps Support Bot

Hi @WilliamAntonRohm, while you may be right - I argue that this is a gap in the documentation as well.
In the section "Map Users and Organizations" the documentation describes a way / best practice to mirror repos to projects:

Azure DevOps can reflect your GitHub structure with:

An Azure DevOps organization for your GitHub organization or user account
Azure DevOps projects for your GitHub repositories

But then the documentation falls short on how to actually achieve this using the recommended method for connecting GitHub and Azure Pipelines: the GitHub marketplace App.
I will follow up on those other resources. But please consider that as it stands, the documentation is making certain recommendations that when taken together is unclear on how to actually implement.


Can S-Lora be integrated into vLLM?

https://github.com/S-LoRA/S-LoRA
They call it 'unified paging' and don't require the model to be merged before doing inference. This would be really useful for serving Mixture of Expert models for example or a service that requires multiple different fine-tuned lora adapters based on the same base model.
And needless to say there has been a lot of request for lora deployments

+1

+1

+1

+1

+1

+1

+2

+1

+1

+9

+10086

+23333

+120

This could possibly be the solution
#1804

No API, but an allows for serving of multi-lora: https://github.com/punica-ai/punica

+1

The integration is complete. https://docs.vllm.ai/en/latest/models/lora.html

Does this handle multiple loras simultaneously for concurrent calls to different lora adaptors like slora ?

It is exactly S-LoRA with Punica batched gemm kernels. This means concurrent calls of different lora adaptors can be executed in one batch.


Array to String conversion - Instamojo.php line no. 298

Hello, I am using it with Laravel and while running the code. Create payment request is successful but when i check the payment status, it returns
Array to String Conversion
Debugging more , I found it is line no. 298 in instamojo.php
Could you please check, what am i doing wrong.

@rebootcode Can you share your code that is resulting in this error? Note that $id should be a string not an array.

This is what, I am exactly doing :-
$app->get('instamojo/payment', function() { $api = new Instamojo\Instamojo('My_API_Key', 'My_Auth_Token'); try {     $response = $api->paymentRequestCreate(array(         "purpose" => "FIFA 16",         "amount" => "3499",         "send_email" => true,         "email" =><EMAIL_ADDRESS>        "redirect_url" => "http://www.example.local/instamojo/payment/status"         ));     print_r($response); } catch (Exception $e) {     print('Error: ' . $e->getMessage()); } });
and to get the status :-
$app->get('instamojo/payment/status', function() { $api = new Instamojo\Instamojo('My_API_Key', 'My_Auth_Token'); try {     $response = $api->paymentRequestStatus(['payment_id_received_from_top']);     print_r($response); } catch (Exception $e) {     print('Error: ' . $e->getMessage()); }     });
from second route "instamojo/payment/status" , I am getting error
Array to string converstion

The [] are just placeholders, don't include them.
Use: paymentRequestStatus('payment_id_received_from_top')

Oh! Got it.
Thanks