Cant add multiple cookies. using setCookie or setSignedCookie

What version of Hono are you using?
4.6.14
What runtime/platform is your app running on? (with version if possible)
pnpm, node
What steps can reproduce the bug?
import { Hono } from 'hono'
import { setCookie } from 'hono/cookie';

const router = new Hono();

router.post('/cookie', async (c) => {
    setCookie(c, 'first_cookie', 'first_value');
    setCookie(c, 'second_cookie', 'second_value');

    return c.json({ message: 'Should add two cookies' })
});

export { router as TestRouter };

What is the expected behavior?
Two cookies should be added and added in the browser.
What do you see instead?
One cookie is added, and there exists two in set-cookie however I believe its incorrectly seperated.

Additional information
No response

Tried using deno, that worked out. Could have been a problem with esbuild


Update an user role

Status
TASK
Checklist
Add checklist if this is a task

[x] Accept request data
[x] Retrieve object in request
[x] Update data
[x] Persist in database
[x] Return operation StatusCode

Steps
Expected behavior
Should allow an HTTP PUT request with new data for a given user role.
Actual behavior

Closed in PR #95


API calls not adding Limit param and Pageable object ignored

(this might be a duplicate of #89 but I'm not completely sure as this is also related to query methods)
Expected Behavior
Repository should consider Pageable object and AWS API calls should have the Limit param.
Actual Behavior
When using Pageable objects in repository methods, spring data seems to be ignoring the page request. When limiting the results via the query method name (such as findTopYByX) the results seems to be limited, but by looking at AWS SDK logs, the actual query sent to DynamoDB actually has no Limit param so I suppose the limit is done in memory.
Steps to Reproduce the Problem
Given a Java project with spring boot, lombok, junit 5 and proper logging configured, the following classes will demonstrate the problem:
@DynamoDBTable(tableName = "Album")
@NoArgsConstructor
@AllArgsConstructor
public class Album {

  @Id
  private AlbumId albumId;

  @DynamoDBHashKey(attributeName = "artistId")
  public String getArtistId() {
    return Optional.ofNullable(albumId).map(AlbumId::getArtistId).orElse(null);
  }

  public void setArtistId(String artistId) {
    if (albumId == null) {
      albumId = new AlbumId();
    }
    albumId.setArtistId(artistId);
  }

  @DynamoDBRangeKey(attributeName = "index")
  public Integer getIndex() {
    return Optional.ofNullable(albumId).map(AlbumId::getIndex).orElse(null);
  }

  public void setIndex(Integer index) {
    if (albumId == null) {
      albumId = new AlbumId();
    }
    albumId.setIndex(index);
  }

  @Data
  @AllArgsConstructor
  @NoArgsConstructor
  public static class AlbumId {
    @DynamoDBHashKey(attributeName = "artistId")
    private String artistId;

    @DynamoDBRangeKey(attributeName = "index")
    private Integer index;
  }
}

public interface AlbumRepository extends CrudRepository<Album, Album.AlbumId> {

  List<AccountBalance> findTop2ByArtistIdOrderByIndex(String artistId);
  List<AccountBalance> findByArtistIdOrderByIndex(String artistId, Pageable pageable);

}

@ExtendWith(SpringExtension.class)
@SpringBootTest(
  webEnvironment = SpringBootTest.WebEnvironment.NONE,
  classes = SomeApp.class
)
class AlbumRepositoryIntegrationTest {

  @Autowired
  private AlbumRepository albumRepository;

  @Test
  void shouldFindMostRecentBalance() {
    albumRepository.save(new Album(new Album.AlbumId("1", 1)));
    albumRepository.save(new Album(new Album.AlbumId("1", 2)));
    albumRepository.save(new Album(new Album.AlbumId("1", 3)));

    var r1 = albumRepository.findTop2ByArtistIdOrderByIndex("1");
    System.out.println("Results: " + r1.size());

    var r2 = albumRepository.findByArtistIdOrderByIndex("1", PageRequest.of(0, 2));
    System.out.println("Results: " + r2.size());
  }

}

The output can be checked here: https://gist.github.com/csokol/f6b88e7f55002f80150ebdf5f8ca7d6a
By looking at lines 94 and 118 of the gist. It's possible to see that the queries are sent without the Limit param.
Specifications

Spring Data DynamoDB Version: com.github.derjust:spring-data-dynamodb:jar:5.0.3
Spring Data Version: org.springframework.data:spring-data-commons:jar:2.0.11.RELEASE
AWS SDK Version: com.amazonaws:aws-java-sdk-dynamodb:jar:1.11.336
Java Version: Java(TM) SE Runtime Environment 18.9 (build 11+28)
Platform Details: macOS

Yes, you are correct.
Limit has been added via #239 and will be part of 5.1.1
Pageable has a PR I'm working (#117) so that will be supported in the near future, too.

@csokol  have you found a workaround before the 5.1.1 version release?

No, I didn't. In the end we migrated our code to use the dynamo mapper lib
officially supported by aws.
Em dom, 12 de mai de 2019 20:12, Khangaldyan<EMAIL_ADDRESS>escreveu:

@csokol https://github.com/csokol have you found a workaround before
the 5.1.1 version release?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/derjust/spring-data-dynamodb/issues/232#issuecomment-491616865,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHUSDQMGDNO5ZRDNWPKGALPVBMXHANCNFSM4GTS3VRQ
.


OIDC Scope mapping side effect

Working with the latest 5.1.x branch.
In order for attributes to be released when using a scope in OIDC, attributes need to mapped in cas.properties to the correct OIDC name for those attributes. For instance given name comes out of LDAP as "givenName" and needs to be mapped to "given_name" to be released by OIDC.  With the current implementation of mapping attributes, the side effect is that given name will always be released as "given_name" even for non-OIDC requests.
Suggest to find a way to map attributes for OIDC that does not alter the names released by other protocols.

You should be able to test the fix in about an hour or so, by using the new SNAPSHOT.

Also https://apereo.github.io/cas/development/installation/OIDC-Authentication.html#mapping-claims


OCPBUGS-10032: updates: manually requeue when waiting for replicas being ready

When a CPMS machine replica is not yet ready
(underlying machine doesn't have .status.phase == Running, or backing node is NotReady)
relying on machine events is not sufficent,
as the machine could already be in Running phase while
the backing node might still be in NotReady condition.
Therefore in order to catch node's NotReady -> Ready changes
(a necessary condition for a CPMS replicas to be considered Ready),
we need to manually requeue.
Surfaced due to the changes introduced in: #171
TODO:

[ ] needs a 4.13 and 4.12 backport (once https://github.com/openshift/cluster-control-plane-machine-set-operator/pull/174 merges)

/jira refresh

/cherry-pick release-4.13

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest-required

/retest-required

/retest

/retest

/retest

/retest

/approve

/retest

/retest

/test ci/prow/e2e-aws-ovn-etcd-scaling

/retest

/retest

/retest-required

I've spoken with @tjungblu regarding the persistence of the invariant test failure in e2e-aws-ovn-etcd-scaling.
Got confirmation that this is not caused by CPMS or this PR but it has been broken for a while in other places too.
Proceeding to override this.
/override ci/prow/e2e-aws-ovn-etcd-scaling


Fetchers that throw redirects can cause infinite loops when actions also redirect

What version of Remix are you using?
1.11.1
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce
https://github.com/dmarkow/remix-redirect-issue

Current page (/) loads data with useFetcher
The route that fetcher loads from (/data) can possibly redirect (in my case, to redirect to a login form if necessary)
Post to an action on that page that returns or throws a redirect (in this example, a log out button that clears the session and redirects to /login)
After that action completes, the loader for the next page (/login) starts running. But before the redirect actually happens, the fetcher on the previous page (/) reloads as well, triggering another redirect.
Infinite loop, and the next page never loads.

This started in 1.10.0 with the fetcher revalidation updates.

Expected Behavior
If a redirect is already being handled, additional redirects to the same destination should be ignored and not trigger fetcher revalidations.
Actual Behavior
Infinite loop.

@barbinbrad At least for this specific issue, 1.9.0 worked fine for me. 1.10.0 is where the issue started (when Remix fully switched to the new router).

Cleaning up my issues and it looks like this got resolved starting in 1.12.0 (probably the react-router update to 6.8.0).


Qwst sensor modules, including BME688 and SCD41

This PR combines the (hopefully) best bits of #143 and #188 into a single PR.

Note I haven't tested the BME688 changes - I thought I had a BME680 knocking about somewhere, but can't currently find it

I'll run this on my enviro and BME688 tomorrow and check that all looks good.

@MichaelBell @Gadgetoid I've run this code on my Enviro with a BME688 connected. Configured for None and with I2C address and all works as expected.

Great, thank you!


Update Project from database creates objects in incorrect folders

Type: Bug
When using the Update Project from Database option (and possibly schema compare)....  objects that don't exist will be created in project folders without spaces in the names.

For example: if I'm missing an external table. but there is already a folder for external tables called "External Tables" it will create the new objects under a new folder called "ExternalTables".

There doesn't seem to be a way to "fix" this behavior but it isn't desired. I believe the correct behavior should be to place the objects in the existing folder. If no folder exists it should default to the same name as visual studio or SSMS would use which is "External Tables"

I have confirmed the is an issue for any folder that should have a space in the name.
Extension version: 1.4.1
Azure Data Studio version: azuredatastudio 1.47.0 (c7c2b2f21505562d21972d4c135119d00806db4f, 2023-11-07T17:17:45.669Z)
OS version: Windows_NT x64 10.0.19045
Restricted Mode: No
Preview Features: Enabled
Modes:

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz (8 x 1498)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
31.60GB (15.81GB free)

Process Argv

Screen Reader
no

VM
0%

@jasonhorner Thanks for bringing this issue to light. Did you notice this issue pop up recently after the update or has this been an issue for long now?

@SakshiS-harma  I don't think it is a regression.. I have noticed it for both serverless projects and traditional sql projects...
but not 100% sure

@jasonhorner Wondering if you have tested it with "Create project from database"? Do you see the same behavior there as well?

@SakshiS-harma  yes, the behavior is the same when creating a new project from a database


update react native picker select

Details
Update react-native-picker-select to include the temporary solution to keeping whitespaces in Picker on Web
Fixed Issues

$ https://github.com/Expensify/App/issues/16329
PROPOSAL: https://github.com/Expensify/App/issues/16329#issuecomment-1494268504
Tests

[x] Verify that no errors appear in the JS console

Offline tests
Same as QA Steps
QA Steps

Create a new workspace
Update the name to have multiple consecutive spaces
Click the FAB
Select New Room
verify the workspace name in the modal/dropdown shows multiple spaces

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop
N/A

iOS

N/A

Android
N/A

@beamanator Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

I have read the CLA Document and I hereby sign the CLA.

@OlimpiaZurek were you able to install npm successfully pointing to this commit hash?
"react-native-picker-select": "git+https://github.com/Expensify/react-native-picker-select.git#c92aab10ffe24acde04f1c205e19decb9fa4e188",

I am stuck here:

Yes, I was able to install successfully.  Do you have the correct version of node ? Maybe try running rm -r node_modules followed by npm install.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/alex-mechler in version: 1.3.1-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/alex-mechler in version: 1.3.1-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/mountiny in version: 1.3.1-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


[GOV] Set up scikit-time slack

scikit-time is live under https://join.slack.com/t/scikit-timeworkspace/shared_invite/zt-1ph9lewat-x1ZgqoPIydbEzuswe4fJmQ

done


Support conversion webhooks

Is your feature request related to a problem? Please describe.
Custom resource definitions can define so-called "conversion webhooks" that transparently convert custom resources with an older version into the storage version before they are even stored in the cluster (see here). KubeOps already supports Mutation and Validation webhooks, but no Conversion webhooks.
Describe the solution you'd like
Provide a IConversionWebhook interface and register its implementations as webhooks, similar to mutation and validation webhooks.

Hey @anekdoti
I already though of that in #137
But up until now, I did not have the muse to implement them :-)

Hello @buehler , I am sorry for the long delay. Are you currently planning to implement Conversion webhooks? It would be complete the support of versioned custom resource definitions.


Removed redundant check_dtypes

[x] Closes https://github.com/dask/dask/issues/7947
[x] Tests added / passed
[x] Passes black dask / flake8 dask / isort dask

Hi @jakirkham & @jsignell
Have done some initial changes based on the discussion, Please review and let me know if any other things need to be added/changed.
Thanks

From the test failures, it seems like we need to add check_dtype in some other places as well.
here:
https://github.com/dask/dask/blob/ff1cc1cc020ca7f02faa0d52bbd20a625545a5be/dask/dataframe/utils.py#L555
and here:
https://github.com/dask/dask/blob/ff1cc1cc020ca7f02faa0d52bbd20a625545a5be/dask/dataframe/utils.py#L563

From the test failures, it seems like we need to add check_dtype in some other places as well.
here:
https://github.com/dask/dask/blob/ff1cc1cc020ca7f02faa0d52bbd20a625545a5be/dask/dataframe/utils.py#L555
and here:
https://github.com/dask/dask/blob/ff1cc1cc020ca7f02faa0d52bbd20a625545a5be/dask/dataframe/utils.py#L563

Thanks for pointing this out!
I have added the check_dtype in the appropriate places and run the tests locally, test cases are passed, let see how it goes this time. 🤞

I just triggered the tests to run, but it looks like you have some conflicts with main now, so you will need to merge in main or rebase before this can be merged.

Can one of the admins verify this patch?

ok to test

I just triggered the tests to run, but it looks like you have some conflicts with main now, so you will need to merge in main or rebase before this can be merged.

Hi think, I have resolved the conflict, please let me know if any further changes need to be done

Looks great! Thanks @rajagurunath for the contribution!


Compilation error: type annotations needed for Box<_>

error[E0282]: type annotations needed for `Box<_>`
  --> /home/sigurd/.cargo/registry/src/index.crates.io-6f17d22bba15001f/time-0.3.28/src/format_description/parse/mod.rs:83:9
   |
83 |     let items = format_items
   |         ^^^^^
...
86 |     Ok(items.into())
   |              ---- type must be known at this point
   |

I guess wether or not you get away with type inference here depends on the rust version

Run cargo update and then the issue is gone. This is a well known problem.

Tried it, and it didn't work.
Tried using both nightly and stable toolchains, same result.
I'm trying to install an aur package with this as a dependency, so it could be the install script needs to run cargo update for it to work.
But i did run that in the workspace folder ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/time-0.3.28 and i can confirm that the install script installs in the same directory, and that running cargo update again after a new install attempt does not update the deps over again, suggesting the update didnt get reset when installing again.
Installing the package manually works fine, so i'll close this and re-open abusch/sinuous#137.

Here I thought that unpinning an issue after six months would have been sufficient…


Add warning message to log this error.

Issue #, if available:
Customer started received 4xx error with following traceback

2024-02-29T11:07:21,222 [INFO ] W-model-2-stdout com.amazonaws.ml.mms.wlm.WorkerLifeCycle - Traceback (most recent call last):
2024-02-29T11:07:21,222 [INFO ] W-model-2-stdout com.amazonaws.ml.mms.wlm.WorkerLifeCycle - File "/opt/conda/lib/python3.10/site-packages/mms/service.py", line 108, in predict
2024-02-29T11:07:21,222 [INFO ] W-model-2-stdout com.amazonaws.ml.mms.wlm.WorkerLifeCycle - ret = self._entry_point(input_batch, self.context)
2024-02-29T11:07:21,222 [INFO ] W-model-2-stdout com.amazonaws.ml.mms.wlm.WorkerLifeCycle - File "/opt/conda/lib/python3.10/site-packages/sagemaker_huggingface_inference_toolkit/handler_service.py", line 267, in handle
2024-02-29T11:07:21,222 [INFO ] W-model-2-stdout com.amazonaws.ml.mms.wlm.WorkerLifeCycle - raise PredictionException(str(e), 400)
2024-02-29T11:07:21,222 [INFO ] W-model-2-stdout com.amazonaws.ml.mms.wlm.WorkerLifeCycle - mms.service.PredictionException: model_fn() takes 1 positional argument but 2 were given : 400
2024-02-29T11:07:21,315 [INFO ] W-model-4-stdout com.amazonaws.ml.mms.wlm.WorkerLifeCycle - Prediction error

(Potential) Root cause:
If model load failed when first time call initialize(), self.load will overwrite by customer's model_fn but self.initialized = False
https://github.com/aws/sagemaker-huggingface-inference-toolkit/blob/main/src/sagemaker_huggingface_inference_toolkit/handler_service.py#L85-L89
Then when customer send the first request, self.initialize() will get called again https://github.com/aws/sagemaker-huggingface-inference-toolkit/blob/main/src/sagemaker_huggingface_inference_toolkit/handler_service.py#L248. Since self.model is the same as model_fn, we will always pass in context.
Description of changes:
Add warning message for future debug
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Sorry i don't understand this warning/error. Why is this to related if the model is initialized?

I added the description in PR detail. I think the error might caused by model initialization failure. Added this warning message for future debugging.

Sorry i don't understand this warning/error. Why is this to related if the model is initialized?

I added the description in PR detail. I think the error might caused by model initialization failure. Added this warning message for future debugging.

@philschmid Please let us know if there are any other work needs for this PR. Thanks.

TBH I am not sure if thats any value if it is always logged and might more confuse people.

TBH I am not sure if thats any value if it is always logged and might more confuse people.

This warning message will only show up when model initialize failed in the first place. We need an indicator when inference toolkit operate in recover mode.

@philschmid could you please review after @chen3933's updated comment above?

As said before, this PR makes little sense to me since self. initialize will always be first before the first request and will be initialized on the first request. So every user would receive that warning on their first request.

As said before, this PR makes little sense to me since self. initialize will always be first before the first request and will be initialized on the first request. So every user would receive that warning on their first request.

Add check to not show warning for none preload model use case (https://github.com/awslabs/multi-model-server/blob/master/mms/model_service_worker.py#L107)
Now this warning message only show up when first initialize failed and we have load it again when first request come in.

As said before, this PR makes little sense to me since self. initialize will always be first before the first request and will be initialized on the first request. So every user would receive that warning on their first request.

just chiming in here, but looks like @chen3933 is using MMS. In MMS, there are two possible ways for the model to be loaded:

Explicitly preload the model when instantiating the Python backend
Receiving a load model request sent on initial connection by the Java frontend
Implicitly load during prediction request if 1/2 failed

I believe @chen3933 change is referring to the 3rd possibility

Wondering the status of this PR and if there are any further changes or can we get this merged @philschmid


Xamarin Android

There's a compile error when trying to build a project for Xamarin Android. It's probably related to the System.Web library as seen here.
You use it for the SerializeJsonBuiltIn function in WatsonCommons, but you already provide Newtonsoft.Json that also has serialization. Maybe you could provide a branch containing only Newtonsoft so the build for Android is possible? Thanks in advance!

Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(1391,2): error : Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'System.Web.Extensions, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Perhaps it doesn't exist in the Mono for Android profile?
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(1391,2): error : File name: 'System.Web.Extensions.dll'
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(1391,2): error :   at Java.Interop.Tools.Cecil.DirectoryAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference reference, Mono.Cecil.ReaderParameters parameters) [0x000c2] in /Users/builder/data/lanes/4695/9dbc4c53/source/xamarin-android/external/Java.Interop/src/Java.Interop.Tools.Cecil/Java.Interop.Tools.Cecil/DirectoryAssemblyResolver.cs:225
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(1391,2): error :   at Java.Interop.Tools.Cecil.DirectoryAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference reference) [0x00001] in /Users/builder/data/lanes/4695/9dbc4c53/source/xamarin-android/external/Java.Interop/src/Java.Interop.Tools.Cecil/Java.Interop.Tools.Cecil/DirectoryAssemblyResolver.cs:175
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(1391,2): error :   at Xamarin.Android.Tasks.ResolveAssemblies.AddAssemblyReferences (Java.Interop.Tools.Cecil.DirectoryAssemblyResolver resolver, System.Collections.Generic.ICollection`1[T] assemblies, Mono.Cecil.AssemblyDefinition assembly, System.Boolean topLevel) [0x00189] in /Users/builder/data/lanes/4695/9dbc4c53/source/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/ResolveAssemblies.cs:143
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(1391,2): error :   at Xamarin.Android.Tasks.ResolveAssemblies.Execute (Java.Interop.Tools.Cecil.DirectoryAssemblyResolver resolver) [0x001c5] in /Users/builder/data/lanes/4695/9dbc4c53/source/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/ResolveAssemblies.cs:88
0 Warning(s)
1 Error(s)

I managed to work around it by modifying your code.

In HttpRequest and HttpResponse I swapped HttpUtility.UrlDecode for System.Uri.EscapeUriString
Removed your built in functions for deserialization

There's the downside of not having built-in deserialization, but it's working just fine in Xamarin Android now :)

Hi @Tutch thanks for filing these, I will be looking into them over the weekend!  Much appreciated!

Hi @Tutch I'm merging this into master and will publish an updated NuGet package in a moment.  Thank you so much for making the changes and creating the pull request!

Merged and updated to v1.2.2: https://github.com/jchristn/WatsonWebserver/commit/8175e5f6eac1d166f6c30411a4b80a73fe02021b
Thanks again!


Add PR write permissions.

https://github.com/peter-evans/create-or-update-comment/issues/103
https://docs.github.com/en/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions#changing-github_token-permissions

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
9

Relevant Lines:
9

💛  - Coveralls


Header of HTML-enabled column should render using v-html

Issue Type (delete the irrelevant ones)

[x] Enhancement Request

Specs
What version are you using?
2.16.3
What browser?
Google Chrome Version 73.0.3683.103 (Official Build) (64-bit)
Expected Behavior
What did you expect to happen?
Header cell of HTML-enabled column should be render using v-html.
Actual Behavior
What actually happened?
The header cell is render as normal text without HTML parsing and styling.
Steps to Reproduce the Problem
Please detail your steps here

Set column html property to true
Pass HTML string in label property

jsfiddle
https://jsfiddle.net/rn9s7ye6/
Please see the "name" column, the 3 was not rendered correctly.

Hey @ton212 for customized headers please use the respective slots:
https://xaksis.github.io/vue-good-table/guide/advanced/#custom-column-headers
closing.


CLOUD-53353 fixed events on ui

@biharitomi pls review

Jenkins build failed.
Refer to this link for build results: http://ci.sequenceiq.com/job/cloudbreak-pull-request/2182/

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/cloudbreak-pull-request/2184/

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/cloudbreak-pull-request/2185/

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/cloudbreak-pull-request/2186/


Re-enable MacOS cache

The cache was previously disabled because it caused build failures.  The hope is no longer happens.


Add an api to make the contact form work

i want to add an api which lets user contact you via email by filling the  contact form

please assign this issue to me @subhadipbhowmik

this should be atleast level2 @subhadipbhowmik


Fee plan

I want to know the standard of charges in the future

Initial plans: https://twitter.com/OrbStack/status/1656326409995055104


az disk update doesn't increase os disk filesystem size

hello, all
pls. have a look at https://github.com/Azure/azure-cli/issues/3380
you can find a solution for the issue at https://postgrespro.com/products/postgrespro/azure/enterprise#vmconfigurationchange

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

ID: 3ab24f5b-50fd-37cc-e031-34301147953d
Version Independent ID: c2bc2467-8743-491c-c84c-f6983772f4da
Content: Tutorial - Manage Azure disks with the Azure CLI
Content Source: articles/virtual-machines/linux/tutorial-manage-disks.md
Service: virtual-machines-linux
GitHub Login: @cynthn
Microsoft Alias: cynthn

@alexeyshishkin01 Thanks for your valuable feedback. I'm afraid that one issue is for one document only. I edited this one so it works for the first article. Would you please create issues for the other two and add the details of the edits you are suggesting.

@alexeyshishkin01 thank you for the feedback! We have another doc that covers resizing and I'm going to use that as the primary version going forward. I'm also creating a work item to make sure that covers OS disk resizing, but it will take a little while for me work on updating that topic to include information on how to update the OS to recognize the OS disk resize. Thanks again!
#please-close

@alexeyshishkin01 We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Add a flag for limiting unlimited dimensions

Followup on #38.
A --limit_dimensions flag to transform UNLIMITED dimensions to limited would help improve compression and speed, in my experience at least. NCO, for example, includes this feature in some of its operators, e.g. nccopy -u.

I'd be open to PR from users to enable this capability.


Protecting async-profiler from corrupt Method pointers

We recently encountered a SEGV in the jdk'sMethod::checked_resolve_jmethod_id, called via async-profiler FrameName::javaMethodName.
We're as yet unsure what caused the corrupt method data, but for what it's worth the offending jmethodID came originally from a jvmti GetStackTrack after an ObjectSampler event.  Casting in the debugger shows a superficially reasonable Method*; the SEGV seems to occur during the evaluation of o->method_holder()->is_loader_alive().  What's also possibly of interest is that the frame is almost surely a lambda.
The program being profiled offers many possible suspects, including custom class loaders and byte-code generation, so we have our work cut out for us.  While we can reproduce the problem with multiple versions of java and of async-profiler, we don't have anything self-contained and shareable at this point.
I saw your comments on https://bugs.openjdk.org/browse/JDK-8313816 and https://github.com/openjdk/jdk/pull/15171, about which I share your skepticism.  However, I did notice
    if (!Method::is_valid_method(method) || is_full(enqueue_buffer)) {
      // we throw away everything we've gathered in this sample since
      // none of it is safe
      return false;
    }

in https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.cpp#L254, which suggests that corrupt method data might be more command than we thought, and that the variously desperate checks in is_valid_method might be sometimes be helpful in recovering from it.  That method is mangled and local to libjvm.so, if we grab it with
VMStructs::libjvm()->findSymbol("_ZN6Method15is_valid_methodEPKS_")
then, in our case, it does seem to be able to detect and elide the frames that were causing our crash.  For obvious reasons, this is not a fully satisfying resolution, but I think it's a worthwhile defensive measure.

The JFR code you pointed to refers to collection of an async stack trace (i.e. outside a safepoint). However, JVM TI GetStackTrace function called from ObjectSampler callback runs at a safepoint and must return valid jmethodIDs. If it doesn't - this is either a serious JVM bug or the initial assumptions are wrong.

It may be a JVM bug to guarantee that jmethodIDs remain valid indefinitely, with "valid" implying that that (*((Method**) jmethodID))->method_holder()->is_loader_alive() is safe to invoke via GetMethodName.  It seems that there have been similar bugs in the past.  In any case, adding the check to javaMethodName seems to be working for us.
I don't have reason to believe that this is related, but I was wondering what ramifications there might be to massive proliferation of unique jmethodIDs for lambdas?  We've found it helpful to strip the hexadecimal suffixes to get them to collapse properly in flame graphs, but won't otherwise identical call stacks still have multiple entries in callTraceStorage?

It may be a JVM bug to guarantee that jmethodIDs remain valid indefinitely

The design of jmethodIDs in HotSpot assumes that any JVM TI call on jmethodID either succeeds or returns one of JVM TI errors (e.g. JVMTI_ERROR_INVALID_METHODID). If it does not work this way - it is a JVM bug that needs to be fixed in the JVM. If would be helpful if you could share more information on how to reproduce or debug the issue.
Blindly applying a non-portable workaround (relying on private symbols) for an unknown bug that might not even fix the issue is not an option.

We've found it helpful to strip the hexadecimal suffixes to get them to collapse properly in flame graphs

I agree. Please file a separate issue, since it's unrelated to the jmethodID segfault.

The design of jmethodIDs in HotSpot assumes that any JVM TI call on jmethodID either succeeds or returns one of JVM TI errors (e.g. JVMTI_ERROR_INVALID_METHODID). If it does not work this way - it is a JVM bug that needs to be fixed in the JVM. If would be helpful if you could share more information on how to reproduce or debug the issue.

Running for a while with our workaround in place and inserting a detectable error frame when it's triggered may give us a more precise idea of how to repro this portably.  I understand that it might not be palatable for general distribution.

The design of jmethodIDs in HotSpot assumes that any JVM TI call on jmethodID either succeeds or returns one of JVM TI errors (e.g. JVMTI_ERROR_INVALID_METHODID). If it does not work this way - it is a JVM bug that needs to be fixed in the JVM. If would be helpful if you could share more information on how to reproduce or debug the issue.

This is valid only as long as there is an existing strong reference to the class containing the method to which the jmethodid points to. Which is not true for stacktraces collected by JVMTI for eg. allocation profiles - the lifecycle of the jmethodids contained in the stacktraces can be very different from the lifecycle of the classes containing the methods those jmethodids are pointing to.
I have a pretty reliable reproducer (which I, unfortunately, can not share because it is basically a heavily mocking test fixture of one of our internal projects) where the crash due to messed up jmethodid is guaranteed within few minutes.
@pnf I came to to this workaround as well - I don't want to cross-post to potentially a competing product (although I don't think it is ...) but one can also use the vmstructs to do more exhaustive checks on the method/class/classloader structures used by various JVMTI calls to eg. resolve defining class etc.
However, all these checks are just bandaids on the fact that a jmethodid is safe to use only while the containing class is strongly referenced (eg. only within the same C function where you take the stacktrace or otherwise you need to create and manage global reference, which is pretty costly). There are places in the code dealing with class unloading and metaspace cleanup (and, interestingly CDS) which can blow up when the cleanup happens to be running concurrently to your native code. Eg. in Method::deallocate_contents the memory is first deallocated and only then the pointer to that memory is nulled. I know that the source code order does not guarantee the execution order because compiler might reorder the function calls but that does not make the situation any better. There are similar patterns for InstanceKlass etc.
I confirmed the hypothesis of method and class metadata being partially cleaned when trying to use a jmethodid in the JVMTI calls by building a heavily instrumented JDK with many more assertions in place checking for validity of the pointers the code assumes are fine to use - and low-and-behold, the assertions are triggering as often as I was used to see the jmethodid related crashes, so there is definitely something going on there.
Also, when you try and disable concurrent class unloading and CDS the jmethodid usage becomes stable again.
Ok, these are just my 2c in case this info might help someone.

@apangin I totally agree that the proposed change is a flimsy workaround and it will not guarantee never touching corrupted jmethodid. The word from the JVM runtime folks (David Holmes, Dan Daugherty) is that this is kind of known but not easy to fix - https://mail.openjdk.org/pipermail/serviceability-dev/2023-June/049711.html (at least that's my understanding of what they are saying).
As for reproducing - I am only able to reproduce where there are really many classes generated on-the-fly (Mockito mocks) and so far I have only of our internal projects as a testbed. I might attempt to create a reproducer which will try to mimic what  mockito does but, TBH, this feels like a lot of work for a very slim chance that this will get ever fixed.
TL;DR the teardown/cleanup would need to be made atomic with the jmethodid/method pointer - the memory must not be released while someone is actively using the jmethodid and the nulling of the pointer and the cleanup must be done in exact and predictable order. This would require eg. an API to atomically create a strong reference to a class containing the method the jmethodid is pointing to such that the method/class structures remain immutable while we are operating on that particuarl jmethodid 🤷

the memory must not be released while someone is actively using the jmethodid

IIUC, the approach to achieve this in HotSpot was to postpone releasing memory after cleanup until a global safepoint happens. At least, this is how it was designed. Since methodIDs are resolved in in_vm thread state, safepoint acts as a barrier to prevent concurrent use.

FWIW, I did some in-depth research and I think I was able to find the real culprit.
I summed this up in my blog post - https://jbachorik.github.io/posts/mysterious-jmethodid - but TL;DR is that this is caused by redefined/retransformed methods and not by the concurrent class unloading as I (incorrectly) assumed.

FYI: https://git.openjdk.org/jdk/pull/16662

@jbachorik Thank you for the thorough analysis. So it's indeed a JVM bug.
If I have a reliable way to reproduce the crash with the profiler, I'll try to come up with a proper workaround.

I could reproduce the issue using a test case from @jbachorik's PR.
I pushed a workaround that prevents from a crash. Please check if it helps in your case.


Build a user interface to create dictionaries

Goal
A person, who did not develop the code, used the code to create a dictionary.
Motivation: get feedback
Tasks

[ ] Think about use cases

Closed because completion on time is not realistic.


NotImplementedError on USATodayDiversityIndex example

I'm trying to set up my own computation class, but I'm not able to implement the example in the documentation.
At table.compute([ ('diversity_index', USATodayDiversityIndex()) ]) I get:
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "python2.7/site-packages/agate/table.py", line 933, in compute
    column_types.append(computation.get_computed_data_type(self))
  File "python2.7/site-packages/agate/computations.py", line 38, in get_computed_data_type
    raise NotImplementedError()
NotImplementedError

...where USATodayDiversityIndex is taken straight from the documentation:
class USATodayDiversityIndex(agate.Computation):
    def get_computed_column_type(self, table):
        return agate.Number()
    def run(self, row):
        super(USATodayDiversityIndex, self).run(row)
        race_squares = 0
        for race in ['white', 'black', 'asian', 'american_indian', 'pacific_islander']:
            race_squares += (row[race] / row['population']) ** 2
        hispanic_squares = (row['hispanic'] / row['population']) ** 2
        hispanic_squares += (1 - (row['hispanic'] / row['population'])) ** 2
        return (1 - (race_squares * hispanic_squares)) * 100

Agate version is 1.1.0.

Doh! Error in the docs! Please change get_computed_column_type to get_computed_data_type. Then it should work. I'll fix this in the next minor release.


dashboard/config: improve the NetBSD configs

reduce the diff between the configs, remove duplicate options in the KUBSAN config

Looks good!


dep init also checks for relative path

Fixes https://github.com/golang/dep/issues/537
*New to golang and this is my first Pull Request.

Oh, forgot to mention in my previous review - we'll also want some tests to cover this.

will add tests today.


Firefox WebExtension support, using the Foxified Add-on

Steps to reproduce this issue

Install Firefox Quantum
Install the Foxified addon (to allow Firefox to use Chrome extensions)
Install the HN Special extension

Expected result
Should work like it does in Chrome.
Actual result
The page doesn't load. Looking further into the CSS, removing the "hnspecial-theme-preload" class from the html tag makes it behave like expected. The infinite scrolling still doesn't work, though.

Huh, I didn't know about Foxified until this issue, thanks.
There's a couple issues that made this happen. First: back when I first added Firefox support in 2013, the browser did not have Web Extension support, so I needed to add a few "if Chrome, else Firefox" checks around the codebase. The way I did that was by checking for the existence of a global chrome object, which as it turns out became the default way to access browser functions for all Web Extensions. I've gone ahead and those browser checks.
The second issue specifically related to your "actual result" is that I had been relying on the "cascading" part of CSS to take care of showing the site once the page and extension have finished loading. Rather than let CSS have all the fun, it makes sense to use Javascript to remove the hnspecial-theme-preload class after the extension has loaded (link to the change).

I also fixed infinite scrolling in Firefox. For some reason Chrome will happily make requests to relative URLs, but Firefox wants the domain name in the request path. Adding the domain to the current page number fixed the problem. 12987eb0300f2c1b5d9bf222509dd9451dd5f9ba

I published v1.4.9 to the Chrome Web Store, and I validated that it works in Firefox using Foxified. I also tried to resubmit to Firefox Addons, but they are still blocking on our usage of innerHTML (more info in https://github.com/gabrielecirulli/hn-special/issues/88)


Implement PartialEq to compare Vec and Binary directly

Done in #597 (0.11 branch). Will be released as part of 0.11.2 and then merged into master for 0.12.


Renew on HTTP request?

Currently certificate renewal is done in background I think? This creates problem where large number of subdomains are used since the renewal limit is 20 subdomains per domain per week.
Over time as more subdomains are created I have found I cannot get certificates for new subdomains and often cannot renew certs on existing subdomains because 20 is quickly used up.
With background renewal, though the subdomains may be infrequently used to access the site (each site also runs on its own www or root domain), they use up the limit of 20.
Is it possible to have renewal of certificates run only on HTTP request, much like how certificates are issued initially now? I'm pretty sure this would smooth certificate renewal peaks so that they do not use up the 20 per week limit.

Now certificates renew in background, but only when it has http request.
If your domain has certificate, but doesn't requested in half year - it will get new certificate only when it has new request, not by time. But if domain has a request per day - it will renew in 30 days before end of life in background (without additional latency for client).
I don't know about lime limit - when domains count as new after certificate expire - in limit descriptions not information about this. https://letsencrypt.org/docs/rate-limits/
It has 2 way to decition of problem:

cron request once per day to every domain
add background renew function to lets-proxy - for always renew certificates.

And it need to research about renew smart schedule with limits for register new certificates:
To get the maximum possible number of certificates, you must perform all new issuances before renewals during a given time window.

Thanks for clarification on how it works. My inference was it was just based on time not triggered by request - so is it a CRON request that is forcing renewal? Maybe there can be option to disable this?
To explain my usecase better:
For me the subdomain is a little used  form of access - for when the site should not be available on it's main domain (to the public), but it still needs to be edited via a CMS. I would be quite happy if these certificates where only ever renewed when visited by a human via a browser. This is the point that https would be needed again and  the latency on that first request would be acceptable.
When sites are built we need to also create a vhost alias on the subdomain but as stated I'm finding renewals are using up the 20 limit so that I cannot get new certificate on new subdomain at point I need it which puts a spanner in the workflow and is forcing me to remove 301 redirects from .htaccess files on a site by site basis do that at least the subdomain url is accessible via HTTP/80.
If it is CRON triggered then, having the option to disable this would probably help in my circumstances.

I can't distinguish browser from cron or other request source. The information doesn't contain in ssl hello request. I have only domain name at this step.
Now certificate renew when it have any request for domain. But doesn't renew when it haven't request.
If I right understand you use:
https://domain.com - for main website.
https://admin.domain.com - for edit website.
It have two domains (4 with www subdomains, but it obtained in 2 certificates) I doen't see why you need 20 or more certificates per week.

I misunderstood. If request based, and not CRON, it must be organic traffic. I am surprised, but will check the logs
Re why we exceed 20 - we do it like this:
https://customerdomain
https://customerid.admindomain (single domain for server with DNS under our control)
Thanks for confirming it is already request based.

I've discovered that renewals are actually still happening, despite us being over the 20 limit, and reading into Lets Encrypt this is intended, so I think it's the lack of traffic on the subdomain which allows the cert to expire, and then on subsequent request counts as a new certifcate that is causing the issues. I think, as you said, we'll just have to ping these domains to ensure background refresh happens, and cert not allowed to expire.


Small simplifications for spin-app

Small tweaks to spin-app after some spelunking. The following changes were made:

Add some docs. Even though these are internal types, it still helps to have some docs about why they're there.
Unrolled some type aliases. I find type aliases that are not reused generally make things harder to understand.
Made DynSafeDynamicHostComponent::update_data_any take just a &mut Data instead of a &mut Box<dyn Any + Send>. There doesn't seem to be any need for that more complicated type
Made DynamicHostComponents pub(crate)

There doesn't seem to be any need for that more complicated type

Probably not. There is a lot of "tweak it till it works then never touch it again" going on in there :grimacing:

Unrolled some type aliases. I find type aliases that are not reused generally make things harder to understand.
:+1: I probably had these just because I was changing them so frequently trying to understand how to fit things together.


Changes index page to order services descending by max span duration

I figured out what "max" was in the index page. It corresponds to the
longest duration span in the trace, as attributed to a specific service.
This orders the search results descending by the most likely culprit,
using relevant time units to prevent minutes from showing as huge counts
of milliseconds, or short traces showing up as zero.
Before:

After: (notice the slowest service is the first one listed)

ps I asked @narayaruna offline and basically a "don't care" response as this isn't a very important change. I agree that it isn't important for analysis.. the main goal of this specific change is understanding what the code does so that we can complete v2 refactoring (#2217) which will let us do a UI replacement easier as discussed at LINE https://cwiki.apache.org/confluence/display/ZIPKIN/2018-10-29+Zipkin+UI+at+LINE+Tokyo
so yeah, this is in the weeds, likely not much notable help to end users, but it is a part of becoming better in a different sense (the UI revamp by @tacigar)
/me ends blathering

What that duration even meant was confusing to users and a ticket was opened long ago: https://github.com/openzipkin/zipkin/issues/998. I had never really paid much attention to it before, but I agree it isn't clear what it means. This change seems to be an improvement for people who understand what it means in the first place.

merged for reason tommy mentioned. we can kill the confusion beast with each change like this.


Hi,How to use？

Hi, I'm a rookie，How do I run this program step by step？

Hi @boyfoo, I started this project as a cross-platform way to interact with scanners, but I hit a huge roadblock when I tried to get the Data Source stuff working correctly. I couldn't get the dynamic loading and cgo wrapper to behave with shared libraries, so I gave up and ended up building what I needed in Swift and using the macOS ImageCaptureCore APIs.
I should probably make this repo private considering it's not very useful. If I ever end up getting it working though, I'll be sure to let you know. Sorry about that!

Mike, excuse me. I'm not completely sure if I understand your answer. Is this repo still alive? And can be used to do scanning in Go on Windows platform or not (you mention a roadblock but mention mac-os).
Thank you
Mario

Hey @mario-imperato, the short answer is: no, the repo is not still alive, and I'm no longer working on the project. I never tested it on Windows or added any code to get it working on Windows 😢. I'm going to archive it now and add a note to the README. Sorry about that!


feature: Add Filter for "initializing/relocating shards"

I have 8k shards and when the cluster is re-balancing , i have a very hard time finding in what shards Elasticsearch is working on.
Just like you have the "show only unassigned shards", it should also show "show only initializing/relocating shards", so we can easily track those changes

I am pretty sure this filter is failing due to this line: https://github.com/lmenezes/cerebro/blob/master/app/models/overview/Index.scala#L46 its looking for state in the top level shard object returned from elasticsearch, but its actually exists at shard -> routing -> state

@supernomad what i'm requesting is being able to see "all shards", "unassigned shards"  AND "currently initializing/relocating shards" ... what you are reporting looks like the "unassigned shards" is not changing the view from the "all shards"... is this correct?

@danielmotaleite There was never a "show only unassigned shards". There is a "show only affected indices", which sits below of the text that says either XXX unassigned shards, or XX relocating shards.
I did think about having separate filters for relocating/initializing, but decided that this was complicating things too much on the ui, for likely little benefit: unassigned shards will eventually become initializing, and if there are no unassigned, even though the filter would also display indices with unassigned shards, it will make no difference.

@lmenezes sorry, you are right, the text is "show only affected indices", but the effect is the same, i can't see what shards is elasticsearch working on at that time.
My problem is that with 8k shards, when i reboot one server in the cluster, i have thousands of unassigned shards, spreading between hundred of pages and withless than 10 being relocated.
I would like to see those relocating 10 shards names, but right now is almost impossible to find then.
My feature request was changing that link to maybe a drop down list with "all, unassigned, relocating".
For me, relocating everything after a server reboot takes maybe 6 hours, so having some idea what shards is elasticsearch working on it is helpful to report to the users.
If you do not like a drop down list, simply do the first click on the link show the unassigned+relocating, the next one only relocating, the next again showing again everything


Modify hugo.toml in release-1.26 branch to set deprecated as true

Resolves #41399
This PR modifies the hugo.toml file in the release-1.26 branch to update the deprecated field from false to true. This change will activate a deprecation banner in the 1.26 documentation, informing users that the 1.26 version is no longer supported.
Please note that the current latest release is version 1.27.

This change LGTM , thanks @dipesh-rawat
/lgtm

/retitle Fix v1.26 docs incorrectly not marked as stale
/approve


BLAKE3 hash_elements() optimization

This PR switches from vector to array buffer when hashing elements using BLAKE3 hash function. On my machine (Apple M1 Pro), this change results in about 7.5% improvement for the sequential hashing benchmark.

The sample size of the criterion benchmark is super small, couldn't this be just noise?
I added this tiny little wrapper around the function to easily increase the number of elements (it is a quick hack, should probably be added to a benchmark instead):
// src/bin/blake.rs

use miden_crypto::{
    hash::blake::{Blake3Digest, Blake3_256},
    Felt,
};
use std::env::args;

fn blake3_sequential(v: u64) -> Blake3Digest<32> {
    let v = (0..v).into_iter().map(Felt::new).collect::<Vec<Felt>>();
    Blake3_256::hash_elements(v.as_slice())
}

fn main() {
    let v: u64 = args()
        .nth(1)
        .expect("missing argument: blake <num_elements>")
        .parse()
        .expect("argument must be an integer");
    let r = blake3_sequential(v);
    println!("{r:?}");
 To understand why I ran the following on each branch:
for i in $(seq 3); do
  xctrace record --template 'CPU Counters' --append-run --output 'blake_cpu_counters.trace' --launch -- target/release/blake 100000000
  xctrace record --template 'CPU Profiler' --append-run --output 'blake_cpu_profiler.trace' --launch -- target/release/blake 100000000
  xctrace record --template 'Time Profiler' --append-run --output 'blake_time_profiler.trace' --launch -- target/release/blake 100000000
done

and it seems the optimized version of the code is very different, the slow version is doing extra work "inplace":

the fast version is just doing less bookkeeping:

And ran it with 100000000 elements on next and this branch. next executed with 0.67s and this 1.08s

When the input size grows beyond 1KB BLAKE3 will do hashing in parallel (@itzmeanjan mentioned it in the comment above). Our use case is somewhat different - we need to hash a large number of inputs where each input is smaller than 1KB (i.e., about 100 field elements).
But I agree, would be good to gain more confidence in the result and running it on a large data set outside of benchmarks is a very good way to do it.

@hackaugusto has a good point in the sense of how we submit the data to blake.
If we have a single call to blake3::hash, we also just perform this super efficient code here:
https://github.com/BLAKE3-team/BLAKE3/blob/64747d48ffe9d1fbf4b71e94cabeb8a211461081/src/lib.rs#L454-L493
If we perform several blake3::hasher::update, we will call this code multiple times:
https://github.com/BLAKE3-team/BLAKE3/blob/64747d48ffe9d1fbf4b71e94cabeb8a211461081/src/lib.rs#L1108-L1226
The performance gain between the difference of allocating a single big vector compared to allocating small chunks & calling update for each chunk will be relevant only for very small input count (I'm guessing below 10 items).
OTOH, using a main binary endpoint for non-blackboxed inputs will not be as reliable as criterion, as the inputs will be easily optimized for that specific case - and blake3::hash will for sure perform better under such predictable circumstances (of transparent inputs)
If we can reproduce the same results of the main.rs snippets with criterion, then it would be conclusive

I made a small experiment. A couple of heads up:

We don't have rayon activated in our Cargo.toml We should probably do something like

diff --git a/Cargo.toml b/Cargo.toml
index 5886cd0..3e89c6c 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -23,12 +23,14 @@ harness = false
 [features]
 default = ["blake3/default", "std", "winter_crypto/default", "winter_math/default", "winter_utils/defau
lt"]
 std = ["blake3/std", "winter_crypto/std", "winter_math/std", "winter_utils/std"]
+rayon = ["blake3/rayon"]

With the change above, I ran the following code
use miden_crypto::{hash::blake::Blake3_256, Felt};
use std::{env::args, fs::File, io::Read, time::Instant};

fn main() {
    let v: u64 = args()
        .nth(1)
        .unwrap_or_else(|| "1000000".to_string())
        .parse()
        .expect("argument must be an integer");

    let mut random = File::open("/dev/random").unwrap();
    let mut bytes = [0; 8];
    let v = (0..v)
        .into_iter()
        .map(|_| {
            random.read_exact(&mut bytes).unwrap();
            u64::from_le_bytes(bytes)
        })
        .map(Felt::new)
        .collect::<Vec<Felt>>();

    let now = Instant::now();
    let digest = Blake3_256::hash_elements(criterion::black_box(v.as_slice()));
    let elapsed = now.elapsed().as_nanos();

    println!("{digest:x?}");
    println!("{elapsed}");
}

My numbers were
next without rayon
4586864
./target/release/miden-crypto 1000000  0.34s user 0.49s system 99% cpu 0.832 total

next with rayon
4613583
./target/release/miden-crypto 1000000  0.36s user 0.46s system 99% cpu 0.825 total

optimized without rayon
7648258
./target/release/miden-crypto 1000000  0.37s user 0.46s system 99% cpu 0.832 total

optimized with rayon
7476804
./target/release/miden-crypto 1000000  0.34s user 0.47s system 99% cpu 0.814 total

Even with rayon, this case had a hard time to catch up the performance with next. But then it was a massive inputs count. I dropped the count to 100, and got a better performance with this branch, as expected
next without rayon
8929
./target/release/miden-crypto 100  0.00s user 0.00s system 87% cpu 0.003 total

next with rayon
8203
./target/release/miden-crypto 100  0.00s user 0.00s system 90% cpu 0.003 total

optimized without rayon
4765
./target/release/miden-crypto 100  0.00s user 0.00s system 86% cpu 0.003 total

optimized with rayon
4902
./target/release/miden-crypto 100  0.00s user 0.00s system 86% cpu 0.003 total

Curiously, my CPU performed slightly better without rayon hehe

We don't have rayon activated in our Cargo.toml We should probably do something like

That is what I noticed on the tracing too, only one cpu was used.

With the change above, I ran the following code

@vlopes11 - If I understood correctly, this code still benchmarks as single invocation of hash_elements. Could we change it to do n iterations where each iteration calls hash_elements() with an input of 100 elements?

I didn't know we were interested on less than 100 elements so I re-wrote the benchmark code, but it includes that case branch. On my machine this is what I got:
Found 8 outliers among 100 measurements (8.00%)
  3 (3.00%) low severe
  1 (1.00%) high mild
  4 (4.00%) high severe
merge/Blake3/256/1      time:   [72.776 ns 72.836 ns 72.889 ns]
                        change: [+1.2797% +1.6350% +1.9659%] (p = 0.00 < 0.05)
                        Performance has regressed.

@bobbinth for n iterations we get equivalent results. Just as side note, this was just a small experiment and shouldn't be used as reference for the decision
use miden_crypto::{hash::blake::Blake3_256, Felt};
use std::{env::args, fs::File, io::Read, time::Instant};

fn main() {
    let v: u64 = args()
        .nth(1)
        .unwrap_or_else(|| "100".to_string())
        .parse()
        .expect("argument must be an integer");
    let n: u64 = args()
        .nth(2)
        .unwrap_or_else(|| "1000".to_string())
        .parse()
        .expect("argument must be an integer");

    let mut random = File::open("/dev/random").unwrap();
    let mut bytes = [0; 8];

    let mut d = Vec::with_capacity(n as usize);
    for _ in 0..n {
        let v = (0..v)
            .into_iter()
            .map(|_| {
                random.read_exact(&mut bytes).unwrap();
                u64::from_le_bytes(bytes)
            })
            .map(Felt::new)
            .collect::<Vec<Felt>>();
        d.push(v);
    }

    let now = Instant::now();
    for v in d {
        let digest = Blake3_256::hash_elements(criterion::black_box(v.as_slice()));
        println!("{digest:x?}");
    }
    let elapsed = now.elapsed().as_nanos();

    println!("{elapsed}");
}

Results (still better with the proposed changes)
next without rayon
38141291
./target/release/miden-crypto  0.04s user 0.06s system 76% cpu 0.133 total

next with rayon
32099396
./target/release/miden-crypto  0.06s user 0.06s system 81% cpu 0.145 total

optimized without rayon
18334796
./target/release/miden-crypto  0.06s user 0.06s system 92% cpu 0.121 total

optimized with rayon
16927470
./target/release/miden-crypto  0.05s user 0.06s system 94% cpu 0.119 total

It suggests we should activate the rayon feature from blake

Okay, these are better results, since we are only interested on fewer than 100 elements I changed the benchmark to go from $$2^0 .. 2^7$$. The results are odd:
hash_elements/Blake3/256/1/1: Change within noise threshold. [-0.6227% -0.4095% -0.1879%]
hash_elements/Blake3/256/2/2: No change in performance detected. [-0.0507% +0.1768% +0.4045%]
hash_elements/Blake3/256/4/4: Performance has regressed. [+8.2104% +8.5736% +9.0859%]
hash_elements/Blake3/256/8/8: Performance has improved. [-5.1110% -4.8827% -4.6372%]
hash_elements/Blake3/256/16/16: Performance has improved. [-3.6362% -3.4147% -3.1845%]
hash_elements/Blake3/256/32/32: Performance has improved. [-5.2021% -4.9734% -4.7040%]
hash_elements/Blake3/256/64/64: Performance has improved. [-8.7032% -8.4915% -8.2704%]
hash_elements/Blake3/256/128/128: Performance has improved. [-7.2253% -6.9411% -6.6419%]

with --profile release had similar results, 1/2 elements no change, 4 elements regression, then improvement.
This is what I ran
First I rebased this branch on top of the benchmark one. Then ran the following:
cargo clean

git checkout hacka-hash-bench
caffeinate -i cargo bench --bench hash -- --save-baseline ./hash-debug hash_elements/Blake3

git checkout bobbin-blake3-opt
caffeinate -i cargo bench --bench hash -- --baseline ./hash-debug hash_elements/Blake3

git checkout hacka-hash-bench
caffeinate -i cargo bench --profile release --bench hash -- --save-baseline ./hash-release hash_elements/Blake3

git checkout bobbin-blake3-opt
caffeinate -i cargo bench --profile release --bench hash -- --baseline ./hash-release hash_elements/Blake3

It suggests we should activate the rayon feature from blake

@vlopes11  We don't need this as the code will be ran in multiple threads anyway (i.e., when we compute a commitment to an execution trace, we hash 1M rows in parallel where each row is currently 72 elements - though this may increase a bit).
@hackaugusto - As I mentioned above, our sweet spot is probably between 32 and 128 elements per row. Based on the benchmarks, it seems like the change I made does improve things, for this use case - right? (I'll add a note about this in the comments).

We could add an issue to create another bench case that will be as close as possible to our target usage. Maybe not even a bench case, could also be a full script (that will create a matrix and apply the operations to it)

We could add an issue to create another bench case that will be as close as possible to our target usage. Maybe not even a bench case, could also be a full script (that will create a matrix and apply the operations to it)

We could try to integrate it here: https://github.com/bobbinth/stark-bench

Based on the benchmarks, it seems like the change I made does improve things, for this use case - right?

Yep, under those results there was an improvement.
I ran the test that @vlopes11 wrote, on that test I had a regression:
next: 41715667
next w. rayon: 42775625
optimized: 46878625
optimized w. rayon: 45780292

for @vlopes11 he had a 52% and 48% improvements. I had a 12% and 7% regression, which is odd since the results with 100 elements doesn't match the benchmark I did before. I had removed the black_box from the code, just to make my life easier, when I add it back:
next: 45248500
optimized: 44513125
next w rayon: 40457791
optimized w rayon: 46870459

... I guess I'm just going to ignore these results. criterion says there is an improvement and it is removing outliers. And maybe it is just that on M2 the gains are smaller than on intel and a M1.

w. RUSTFLAGS='-C target-cpu=native' seem much worse:

output
branch

142897166
next

142452708
next w. rayon

335225625
optimized

339543584
optimized w. rayon

old output for reference:

output
branch

45248500
next

40457791
next w. rayon

44513125
optimized

46870459
optimized w rayon

script I ran
RUSTFLAGS='-C target-cpu=native' cargo run
RUSTFLAGS='-C target-cpu=native' cargo run --features rayon
git checkout bobbin-blake3-opt
RUSTFLAGS='-C target-cpu=native' cargo run
RUSTFLAGS='-C target-cpu=native' cargo run --features rayon

@hackaugusto we still should have --release there

 script
cargo clean >& /dev/null
git checkout origin/next >& /dev/null

cargo build --profile release >& /dev/null
cargo run --profile release

cargo build --profile release --features rayon >& /dev/null
cargo run --profile release --features rayon

RUSTFLAGS='-C target-cpu=native' cargo build --profile release >& /dev/null
RUSTFLAGS='-C target-cpu=native' cargo run --profile release

RUSTFLAGS='-C target-cpu=native' cargo build --profile release --features rayon >& /dev/null
RUSTFLAGS='-C target-cpu=native' cargo run --profile release --features rayon

git checkout origin/bobbin-blake3-opt

cargo build --profile release >& /dev/null
cargo run --profile release

cargo build --profile release --features rayon >& /dev/null
cargo run --profile release --features rayon

RUSTFLAGS='-C target-cpu=native' cargo build --profile release >& /dev/null
RUSTFLAGS='-C target-cpu=native' cargo run --profile release

RUSTFLAGS='-C target-cpu=native' cargo build --profile release --features rayon >& /dev/null
RUSTFLAGS='-C target-cpu=native' cargo run --profile release --features rayon

result
branch
profile
features
env

6285208
next
release

6265875
next
release
rayon

6188833
next
release

native

6321458
next
release
rayon
native

9707000
optimized
release

9715417
optimized
release
rayon

9794458
optimized
release

native

9779625
optimized
release
rayon
native

I've ran a slightly modified version of @vlopes11 code for n = 100_000, and I'm getting the following results:

next:   120 ms
optimized: 112 ms

This roughly aligns with benchmark results for me (improvement of about 7.5%).
Also, using RUSTFLAGS='-C target-cpu=native' doesn't seem to make any material difference.
code

use miden_crypto::{hash::blake::{Blake3_256, Blake3Digest}, Felt};
use std::{env::args, fs::File, io::Read, time::Instant};

fn main() {
    let v: u64 = args()
        .nth(1)
        .unwrap_or_else(|| "100".to_string())
        .parse()
        .expect("argument must be an integer");
    let n: u64 = args()
        .nth(2)
        .unwrap_or_else(|| "10000".to_string())
        .parse()
        .expect("argument must be an integer");

    let mut random = File::open("/dev/random").unwrap();
    let mut bytes = [0; 8];

    let mut d = Vec::with_capacity(n as usize);
    for _ in 0..n {
        let v = (0..v)
            .into_iter()
            .map(|_| {
                random.read_exact(&mut bytes).unwrap();
                u64::from_le_bytes(bytes)
            })
            .map(Felt::new)
            .collect::<Vec<Felt>>();
        d.push(v);
    }

    let mut results: Vec<Blake3Digest<32>> = Vec::with_capacity(n as usize);

    let now = Instant::now();
    for v in d {
        let digest = Blake3_256::hash_elements(v.as_slice());
        results.push(digest);
    }
    let elapsed = now.elapsed().as_micros();

    println!("n: {}, time: {elapsed} ms", results.len());
}

I benchmarked it on AMD Ryzen 9 5950X and neither the benchmarks nor @vlopes11 code showed any meaningful improvement or degradation. So, I guess so far we get:

Apple M1: ~7.5% improvement
AMD Ryzen 9 5950X: no change

FYI, I was going to open a PR adding rayon support based on this approach. I ran a cpu profiler just to check more than one core as being used, and I found out that update is always single threaded:

This method is always single-threaded. For multithreading support, see update_rayon below (enabled with the rayon Cargo feature).

Since the comment linked above was a diff, I assume it was for the complete change set, so none of the results here were parallelized, meaning there were no real gains and the results were just within noise.
When I did the first example with a simple loop, it was just a simple test to increase the number of loops and reduce noise (that is why the input was so large), since that is not the target use case, I think we should go back to the drawing board and try to get a more reliable measurement before making decisions. At least we shouldn't take a single sample as evidence of performance improvements, and rely more on criterion to make a decision.

I was going to open a PR adding rayon support based on this approach. I

As I mentioned in one of the comments in this thread, we don't need parallelism here - the code that uses hash_elements() is already parallelized.

still would be nice to have more samples to have more certainty in the results

Agreed! I'd like to have more conclusive benchmarks and ran them on more architectures.

Agreed! I'd like to have more conclusive benchmarks and ran them on more architectures.

btw, I did create a PR for this https://github.com/0xPolygonMiden/crypto/pull/77 , we can use that or something similar. Another approach is to merge this now and come back later if we need it :)

I tested how this behaves in the context of the prover and it seems like it does have noticeable (though not big) positive effect. I also benchmarked this using benchmarks in #77 and the results look consistent with the benchmarks we currently have. So, I'm going to merge this.


FileObject status deprecated, is there a replacement?

Confirm this is a Node library issue and not an underlying OpenAI API issue

[X] This is an issue with the Node library

Describe the bug
In #433 the status field here was marked deprecated, but I don't see a mention of another alternative to understanding file status. (To be clear, I'm asking about the file status here in the node library, not the underlying issue with the assistant noted in the community thread)
https://github.com/openai/openai-node/pull/433/files#diff-bb30fd0eac3872e21bc42abbf74bd9501293b1102ecf80ceb3066ea8f2b3d380R146
/**
   * The current status of the file, which can be either `uploaded`, `processed`,
   * `pending`, `error`, `deleting` or `deleted`.
   * Deprecated. The current status of the File, which can be either `uploaded`,
   * `processed`, or `error`.
   */

I'm getting this error when using the assistant, so I wanted to make sure the files i had uploaded were processed and accessible. With this field deprecated, is there another alternative or is this broken?
https://community.openai.com/t/myfiles-browser-tool-is-not-operational-for-these-files/481922/13
To Reproduce

Upload a file
Wait for file to be finished processing
Create an assistant, thread, message with file attached and run
Wait for assistant to finish
Unable to access file

Code snippets
No response
OS
macOS
Node version
Node v18.17.1
Library version
openai 4.17.4

The status property is only needed for the old fine tuning system, for fine tuning jobs the status will always be processed.
Instead the status will be accessible on the object that is operating on the file, for example the fine tuning job status.


Remove getSheetTranslation

We use this getSheetTranslation in some places and in others we use sheetTranslation directly. Since there is no underlying logic for getting the sheet translation value and the method is private, I think it's better to save a method call and just use the field directly in all cases.

looks good

Merging on @emilsjolander's request.


The developer tools become a floating window

Version 1.74.0, when I open the developer tools, it becomes a floating window, which is very unfriendly for extension developers, please add at least one option to use the old layout.

Was caused by an upstream electron bug with WCO https://github.com/electron/electron/issues/34129. Believe there are plans to restore the docking feature in the near future now that the electron issue is resolved.

Workaround
I found that if you toggle off the window.experimental.windowControlsOverlay.enabled setting, docking functionality is restored AND you also still get the WCO experience (perhaps that's a separate bug?).
Suggest docking at the bottom instead of to the right if there's any visual conflict due to the aforementioned electron bug.

It work, thanks!.

The setting window.experimental.windowControlsOverlay.enabled will be removed at one point, keeping the issue open to provide left and bottom dock options when WCO is enabled.

Related Stack Overflow question: How can I change the docking of devtools in VS Code?

This makes working on Windows really awful for me, I think the upstream bug is fixed.

@deepak1556

To give some context, with WCO chromium has a bug in orienting devtools window when docked to the position where the Window controls are

I see this as an issue when you dock the devtools to the right, but why is the ability to dock it at the bottom taken away? This seems to work just fine with WCO.

Say we chose mode: bottom as default and user later reposition it to right or left then this new state will be persisted to

But on Windows, a user is not able to reposition the devtools at all? This functionality seems to be truly gone, so a setting for Windows only would be a decent workaround and good improvement over what we have today.

I am good with a setting to force the bottom position only on Windows. I will see if the runtime behavior can be improved to avoid docking the devtools to the position where the controls are present as part of this issue.

The dock options are back, though setting it to dock on the right looks funny with the WCO in the way.

Yes that is the original bug in chromium which is not addressed.

In the new version, if the developer tools are on the right side, the close button will be blocked, which is not as good as the old version of window.experimental.windowControlsOverlay.enabled.

@cweijan use a dock position that is not overlapping with the window controls, by default the devtools will not dock to the position were the window controls are.

I know, but I always put the developer tools on the right, which is where I'm most productive.

@deepak1556  @bpasero Is it possible to revert "window.experimental.windowControlsOverlay.enabled" to a VS Code new version? #188793
In order for the developer tools to be correctly positioned on the right side, I now have to go back to VS Code version 1.81 and disable updates.

@deepak1556 is there an issue where we are tracking how the WCO is overlapping the devtools?

@andreamah no we are not tracking it in the runtime, unless you have manually docked it to the overlapping position devtools by default would be undocked. The overlapping position in the runtime will not resolved anytime soon.


Improve CodeFix "add missing super.call()"

TypeScript Version:  2.1.1
Actual behavior:
I have started to implement quick fix with Eclipse. Here a short demo:

Expected behavior:
You can see 2 problems:

the codefix generates " super(); although it should generates super(a);
the code fix doesn't respect the formatting.  super(); should be generated in a new line with indentation.

For formatting see https://github.com/Microsoft/TypeScript/issues/12249. the expectation is the host will call format after applying the change.
for the argument, it is not clear what should be added here. so options either do not have a quick fix enabled if the base class constructor has required parameters, or add the same set of parameters to the derived constructor. i do not know what to do if the derived constructor has parameters already.


fix document markdown Lightweight Markup Languages code blocks back quote

[x] I have checked the discussions
[x] I have searched the issues of this repository and believe that this is not a duplicate.
[x] I have checked the FAQ of this repository and believe that this is not a duplicate.

Describe the bug
In document, some markdown's code blocks use 4 back quote ````, some use 3 back quote ```
For example:

https://github.com/apolloconfig/apollo/blob/5bec3e4bfd7e268fe7f991f1e181bd756bf55f8d/docs/en/deployment/quick-start.md?plain=1#L27
https://github.com/apolloconfig/apollo/blob/5bec3e4bfd7e268fe7f991f1e181bd756bf55f8d/docs/en/misc/apollo-benchmark.md?plain=1#L9
https://github.com/apolloconfig/apollo/blob/5bec3e4bfd7e268fe7f991f1e181bd756bf55f8d/docs/en/deployment/deployment-architecture.md?plain=1#L904

Those syntax error will cause some error when tool parse markdown document.
Expected behavior
Normalize all 4 back quote ```` to 3 back quote ```
Screenshots
When open
https://github.com/apolloconfig/apollo/blob/5bec3e4bfd7e268fe7f991f1e181bd756bf55f8d/docs/en/deployment/quick-start.md?plain=1#L27
with vscode

this color should be blue instead of green, 4 back quote ```` broken the syntax.
Additional Details & Logs

Version
Error logs
Configuration
Platform and Operating System

Could I attempt this?


Validate that we don't overlap with the network service CIDRs.

Update validations to ensure we don't overlap with the cluster network
CIDR settings.  Validate no overlapping on update to old network
settings.  Various cleanups.

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/test e2e-kubevirt-gcp-ovn

/test e2e-aws

/test e2e-aws

/test periodics-4.13-images

/test periodics-4.12-images

/retest

/test periodics-4.13-images

/test e2e-aws

Going to close and reopen because of test failures


Add a browser-utils crate

There is a lot of shared logic between the test substrate/polkadot in-browser light clients I've been working on, so I'm putting it in this browser-utils crate.
For clarity: I'm still working out how to best approach certain changes needed to get the light clients to work properly, so I'm merging things piece-by-piece.

IMO we should be more explicit in the keystore. The keystore should have a "memory-only" mode rather than using #[cfg] stuff. Once the keystore can be memory-only, we also no longer need to pass a dummy keystore path in the configuration.
What this PR does is okay-ish but doesn't go in the direction of having clean code.
We can either merge now and fix later, or improve this PR itself.

@tomaka What can be cleaned up?

What I mentioned: not having platform-specific code in the keystore.

This needs a Polkadot PR because of the change in the configuration now though.

tests not passing either

Needs resolving.

Not sure what's causing wasm-bindgen-webidl to not compile - that version seems to work fine on my machine and the build server.


Update MZONDER.toml

prev PRs:
https://github.com/anoma/namada-testnets/pull/829
https://github.com/anoma/namada-testnets/pull/1120
https://github.com/anoma/namada-testnets/pull/2108
Description
All previous genesis validators should name their PRs "Update {validator_alias}.toml for tesntet-15" and provide links to previous PRs merged.
If this is an UPDATE for a previous genesis validator
Checks are made against your net_address. If this has changed since the previous testnet, make sure you provide links of previous prs merged from your previous git username.
Thanks in advance!
Checklist before merging

[ ] Only one toml is added in this PR
[ ] The file being added is indeed a .toml file
[ ] The toml being added is to the correct folder, and only to the correct folder
[ ] The eth_hot_key and eth_cold_key are present
[ ] The email, discord, elements telegram, and twitter fields are present and valid

Successfully validated transactions.toml file for commit hash df7615f


CRM-RCT: mapping Ecoregions to Datasets

From Mike: 'In order to use the vocab web services directly in RCT, I need the datasets codetype to link to the ecoregion code type and there after, the code CRM-RCT should link to all ecoregions.'
https://vocab.ices.dk/?ref=102
to link with
https://vocab.ices.dk/?ref=1414

@mikeydrew done, apologies for the delay


Section Header - Hidden

If you set a section header to "Hidden" all sub sections will also have Hidden titles.
No matter what section header size you assign to them.
Use Case:
Try to do a 2 column layout below a parallax region.
You don't want the container section to have a header title but you can't hide it without hiding all sub section headers.

Sorry that I have to ask again: is it 0.9.2 or 0.9.3? I believe this is fixed in 0.9.3.

Its 0.9.2


Don't commit non ask questions about the repo

"Communism rules!" he posts on Reddit on his $2000 MacBook Pro while playing Clash of Clans on a $1000 iPhone, stopping only to drink an $8 Frappelini Mochano Machiatto at Starbucks which provides free Wi-Fi utilizing privately-owned infrastructure at their own expense. A drip of coffee spills onto their $500 Ambercrombie and Fitch exclusive clothing. The Redditor is triggered; the pain of this PTSD-afflicting incident can only be resolved by downvoting every post on T_D and CringeAnarchy. Now calmed down, the Redditor makes a quick stop to the local hospital.  For $10000, he is now the girl he always wanted to be. Thankfully, she had insurance due to Obamacare, so it wasn't her money that was spent. Later it goes to the bank. "I'd like a $20000 student loan." All of it goes to Bernie's campaign. Match them.

"Don't commit non ask questions"


Update docs fonts and favicon

Cherry picked from https://github.com/medplum/medplum/pull/860

Use woff2 over ttf (https://stackoverflow.com/questions/36105194/are-eot-ttf-and-svg-still-necessary-in-the-font-face-declaration/36110385#36110385)
Font weights now match the www styles
Fixed the favicon so that it is square and not stretched

The diff is messy because prettier changes the hex colors from upper case to lower case.

Coverage remained the same at 94.398% when pulling 744334cc81801134ed02312c2baa2e626e7e235e on cody-update-docs-fonts-and-favicon into 186e23f5b339ddf613c594c33a217ee7d598683b on main.


travis-badge added

Would be good to have this on the readme - going to hold off from merging until the C.I. is working first


Prevent CMake Tools activation when CMakeLists.txt is not in the workspace folder or at cmake.SourceDirectory

Since CMake Tools changed the activation condition from CMakeLists.txt found in the root to anywhere inside the workspace, we get into situations when it activates for non CMake repos. One example is when a non CMake repo contains some tests that have CMake files.
Preventing the activation or programmatically deactivating the extension might not be possible, but at least we would like to disable the features until the state of the workspace changes (it becomes a real valid CMake repo).
Integrate this functionality with the message box asking about QuickStart or cmake.sourceDirectory, providing a third option, to ignore this folder.

This looks great, thank you. It's not clear to me though if this is something I can set in setting.json. I would like to share share my multiroot workspace with my team and they not get the popup about missing CMakeLists at all. Will that be possible?

Not in 1.4.0.  If you want to open a new issue to request we add a setting for it, we can consider doing that for a future release.
You can try out the experience today by installing the beta on our releases page

This fix is available in CMake Tools #1.4.0 which has been released.


Minor fixes to netctl

move EPG under network hierarchy
eliminate 'public' field in network command
add packet tag field to specify clan-id/vni
rename default-gw to gateway
minor fix to json parsing

Appreciate a quick review since "create net" wouldn't work without this change.

LGTM

LGTM after --pkg-tag change


Support embedding variables in json files

Proposal
To allow variables to be embedded in json files for more flexibility as test data.
{
    "code": "{{ vars.code }}",
    "data": {
       "foo": "test",
      "bar": 1
   }
}

Use vars syntax to expand variables when reading json.

Very interesting 👍
I think the following implementation might be difficult

Expansion of Integer and Boolean types

Expansion of Integer and Boolean types

I think I was limited to only within a string to expand a variable, so this problem is difficult.
Other tools seemed to have the same problem. 😓
https://community.postman.com/t/the-path-variable-var-needs-to-be-of-type-integer-but-we-found-var/12714


Licence info visible on the website

Description
As a user, I want to see the licence info on cancermodels.org
All models submitted before this implementation takes place should be marked as EBI Terms of use: https://www.cancermodels.org/about/terms-of-use
All models submitted after: https://creativecommons.org/publicdomain/zero/1.0/
Acceptance criteria

[ ] best implementation discussed within the relevant team members
[ ] deployed

As discussed this change will be at the level of the model. A footer "All models and data in Cancer Models Finder are available either through CC0(link) or EMBL-EBI Terms of Use (link to https://www.ebi.ac.uk/about/terms-of-use)"

Example from GWAS:
General statement - https://www.ebi.ac.uk/gwas/downloads/summary-statistics
Individual study - https://www.ebi.ac.uk/gwas/studies/GCST90134433

License field added to sharing sheet (as decided it needs to be on model level). changes on dev

@Mandloi2309 does this mean that now this is now ready to move to the next step - and who is responsible for it? Many thanks!

Licence info has been added to the FE, both for model detail page and footer across all the site.


docs(concepts): Adding promise syntax example to Module Federation docs

Adds a promise new Promise() example to the Module Federation docs. This makes it so this API is now documented, and gives an example of how to use it's power.

@XiaofengXie16 Hi there, do you think you can help review this pull request just in case you have any similar experience?

@chenxsan I have not personally used this approach before but I just tried to apply this method on top of this example code https://github.com/module-federation/module-federation-examples/tree/master/basic-host-remote and I am getting ReferenceError: require is not defined. I　assume there are some additional settings that we need to configure in order to run it correctly? If that's the case, it would be great to specify them in the example as well.

@chenxsan I have not personally used this approach before but I just tried to apply this method on top of this example code https://github.com/module-federation/module-federation-examples/tree/master/basic-host-remote and I am getting ReferenceError: require is not defined. I assume there are some additional settings that we need to configure in order to run the example code in this PR correctly? (I know this error is not really tied to module federation itself but it will make it more friendly to people who just get started with module federation)If that's the case, it would be great to specify them in the example as well.

Thanks for checking!

@KyleBastien Any suggestion regarding the require is not defined error? Seems webpack won't compile the code defined in remotes of promise new Promise() type. Since there's no require in browser, hence require is not defined.

@chenxsan I'm taking a closer look. I copied the majority of this example from @ScriptedAlchemy's nextjs-mf repo here: https://github.com/module-federation/nextjs-mf/blob/main/withModuleFederation.js#L14. But something must be different in this case. Going to dig in futher.

It seems to be used in server side compilation as per https://github.com/module-federation/nextjs-mf/blob/main/withModuleFederation.js#L66 and https://github.com/vercel/next.js/blob/canary/docs/api-reference/next.config.js/custom-webpack-config.md:
- `isServer`: `Boolean` - It's `true` for server-side compilation, and `false` for client-side compilation

That's why require is available over there.

Require is an example of a node based app.
Client side you could inject a script and onload resolve the interface.
I use this to do api calls to figure out what remote version to inject into the dom

Thanks @chenxsan and @ScriptedAlchemy. I updated my example based on this feedback, and I implemented a basic example here: https://github.com/KyleBastien/module-federation-examples/blob/b43512578fe12c105799682853938fa4f5761bac/basic-host-remote/app1/webpack.config.js#L39
To also show that it works.


JSON Return Expected in SMA-ContinousIntegration

Quick fix in the module to return the result object as a JSON object which is expected in the upstream function.

Cancelling this pull request, as discussed we will pass objects between functions, and not json.


Merge next into master

Contains the following changes:

add control flow to |verb (https://github.com/urbit/arvo/pull/1080)
More accurately represent Ethereum RPC filter topics (https://github.com/urbit/arvo/pull/1079)
Implement %eth-watcher, an app for tracking Ethereum events (https://github.com/urbit/arvo/pull/1081)
Point to the correct topics when decoding Azimuth events (https://github.com/urbit/arvo/pull/1083)
Tiebout - Apple Push Notification Server App (#1084)
added initial image support to udon parser (#1085)
Implement +from-unix for turning Unix timestamps into @da (#1087)
removed hard calls on json blobs (#1094)
Support eth_getBlockByNumber Ethereum RPC call (#1092)
pin to local time because using local desk (https://github.com/urbit/arvo/pull/1074)
Landscape: use same syllable for sigil as mobile (https://github.com/urbit/arvo/commit/dbc9be424302b5ea42b1a95f009ea2af8313a1a1)

LOIG
—
~poldec-tonteg
http://urbit.org
On Thu, Mar 7, 2019 at 12:57 PM benjamin-tlon<EMAIL_ADDRESS>wrote:

@benjamin-tlon approved this pull request.
Looks okay, I guess.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/1101#pullrequestreview-212015591, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABiQ4_peO7_yxTHw693TrnXxSrSZ4W9Iks5vUX0zgaJpZM4bj_fa
.

Sorry, the hoon school guys need this breach right away, because they would like some time to test things out before they begin on monday. I've already delayed this long enough, I was originally supposed to breach yesterday. I apologize, but I can't wait.

That's totally fine, better luck for me next time. (: