Select AGW SKU via feature flag

Checklist

[x] The title of the PR is clear and informative
[ ] If applicable, the changes made in the PR have proper test coverage
[x] Issues addressed by the PR are mentioned in the description followed by Fixes.

Description
As a user I want to select SKU of AGW. For now, all installations are using Standard_v2 SKU because it is hardcoded.
Fixes
None

@akshaysngupta @3quanfeng can you look at that, please?

@akshaysngupta @3quanfeng  guys, can you take a look, please?

@kvendingoldo @akshaysngupta @3quanfeng any updates here?

LGTM
Thanks for contributing! I will merge after testing.


feat(minirum): allow increasing the sampling rate up to 1/10 for specific use cases

This introduces a new global variable, window.RUM_SAMPLING_RATE, that can be set before loading the library to increase the sampling rate for specific use cases that require more data collected for short-term reporting.
For instance:

when running an experiment in a 2-week time-frame and achieve statistical significance even with low traffic
when running short-lived marketing campaign and wanting to collect enough data over a single weekend

Usage
For instance:
window.SAMPLE_PAGEVIEWS_AT_RATE = 'high';

Or in an HTML context:
  <head>
    <meta name="experiment" content="Foo"/>
    <meta name="experiment-variants" content="/bar,/baz"/>
    <script>window.SAMPLE_PAGEVIEWS_AT_RATE = document.head.querySelector('meta[name="experiment"]') ? 'high' : null</script>
    <script src="/scripts/aem.js" type="module"></script>
    <script src="/scripts/scripts.js" type="module"></script>
    <link rel="stylesheet" href="/styles/styles.css">
  </head>

Related Issues
Fix #156

See https://cq-dev.slack.com/archives/C07198KKQ07/p1717543808221569

Thank you @ramboz. I've added you as a writer to the repository, so you don't need to work off your own fork anymore. On the flip side, please make sure that the change is covered by tests.

Please merge once the conflicts have been resolved.

@trieloff Properly rebased this against the latest main… but I'll need you to re-review before I can actually merge


ndk: Add definitions and bindings for API levels

android/api-levels.h from the NDK defines constants for all (NDK-supported) API levels and both a getter for the "current apps' target API level" as well as the API level of the device the app is running on.  Create bindings to allow users to query this information at runtime from their Rust code as well.
The equivalent of the NDK's __ANDROID_API__ define are our api-level-xx crate features, used to restrict APIs (and inexistant linker symbols) at build-time.
(As there is no full-fledged Android build system involved, users of the  ndk crate are expected to keep this in sync with the minimum/target  API level passed to their build tool of choice.)

CC @daxpedda

error: struct `crash_detail_t` is never constructed
     --> ndk-sys/src/ffi_aarch64.rs:16024:12
      |
16024 | pub struct crash_detail_t {
      |            ^^^^^^^^^^^^^^
      |
      = note: `-D dead-code` implied by `-D warnings`
      = help: to override `-D warnings` add `#[allow(dead_code)]`

error: struct `ACameraOutputTargets` is never constructed
     --> ndk-sys/src/ffi_aarch64.rs:21233:12
      |
21233 | pub struct ACameraOutputTargets {
      |            ^^^^^^^^^^^^^^^^^^^^

I think this is a Rust 1.80 clippy false-positive. The types may not be constructed by us, but they are pub visible and could be used in downstream code.
However, no API currently takes these symbols, so we might as well skip & hide them until they become useful?
(ACameraOutputTarget without -s does exist and is used)

Re-running CI jobs because some changes to dead_code causing these false-positives appear to have been reverted in 1.80.1: https://blog.rust-lang.org/2024/08/08/Rust-1.80.1.html#false-positives-in-the-dead_code-lint


[zh-cn] Add missing required type field to LimitRange example

Porting PR https://github.com/kubernetes/website/pull/38706 as Issue https://github.com/kubernetes/website/issues/38705 also affects zh-cn.

/lgtm
Please resubmit your PR to trigger the test again. Something is wrong with the gate.

/approve


How can I get the docking scores of two heteromer protein interaction which generated by Alphafold-Multimer

What software that I can get the degree of heteromer protein interaction which generated by Alphafold-Multimer.

Hi, I'd suggest using an external tool such as BioPython to analyse the predicted structures.


stm32/usart: Immediate Error::Overrun  when receiving data with embassy_stm32::usart::BufferedUart or RingBufferedUartRx

I'm trying to communicate with a LTE modem and run into a couple of problems with the current UART implementations of embassy_stm32.

When using BufferedUartRx or the new RingBufferedUartRx I run into an immediate Error::Overrun when testing in loopback mode when I send and receive from the same board in parallel. Even with very big rx_buffer and very little transmitted data. This applies to fill_buf() and read(&mut [u8]) methods.

When I try receiving from a serial to UART converter in low speed (because I type in the text to send on my PC) I can receive some text, before I also receive Error::Overrun.

The consume(&self, usize) from BufferedUartRx / RingBufferedUartRx method seems to have no effect in preventing overruns.

UartRx in DMA mode with read_until_idle() kinda works together with embassy time::with_timeout, but this solution is quite cumbersome and suboptimal.

Tested on an old STM32F103C8T6 "BluePill" board with original STM32.

I have also replicated this issue on a STM32f405RG.

Perhaps the problem is in the default RCC configuration. I had the same thing on my STM32F411CEU6 (Black pill), but after manual RCC setup (at least enabling HSE) everything worked fine. My config:
    let mut config = Config::default();
    config.rcc.hse = Some(Hse {
        freq: Hertz(25_000_000),
        mode: HseMode::Oscillator,
    });
    config.rcc.pll_src = PllSource::HSE;
    config.rcc.pll = Some(Pll {
        prediv: PllPreDiv::DIV25,
        mul: PllMul::MUL200,
        divr: Some(PllRDiv::DIV2),
        divp: Some(PllPDiv::DIV2),
        divq: None,
    });
    config.rcc.ahb_pre = AHBPrescaler::DIV1;
    config.rcc.apb1_pre = APBPrescaler::DIV2;
    config.rcc.apb2_pre = APBPrescaler::DIV2;
    config.rcc.sys = Sysclk::PLL1_P;

    let p = embassy_stm32::init(config);

Same issue on STM32F407VET6.


resid_sdk_v0.18.0_win64.exe

I'm looking for a file called "resid_sdk_v0.18.0_win64.exe" .
It should be in "https://github.com/IntelRealSense/RealSenseID/releases" (URL), but for some reason I can't find it on the site, could you tell me where it is?

Added to latest release


refactor: make a standard API to  run tests inside a worker

Description
TODO:

[ ] Fix vm hanging
[ ] Make vmForks pool (already defined at runtime, but nothing references it)

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
[ ] Ideally, include a test that fails without this PR but passes with it.
[ ] Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

[ ] Run the tests with pnpm test:ci.

Documentation

[ ] If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

[ ] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

Something like this should work on main thread's side for single instance of Tinypool. I didn't test it but it might work as is.
import { Tinypool } from 'tinypool'

const pool = new Tinypool({
  filename: 'dist/worker.js',
  // min/max options here. Shared by all pools.
})

async function waitForEmptyQueue() {
  return new Promise<void>((resolve) => {
    if (pool.queueSize === 0) {
      return resolve()
    }

    pool.once('drain', resolve)
  })
}

const runningTasks: Promise<void>[] = [];

// TODO handle vm ones too
async function runTests(files: string[], vitestPool: 'threads' | 'forks') {
  const runtime = vitestPool === 'threads' ? 'worker_threads' : 'child_process'

  await pool.recycleWorkers({ runtime })

  const data = {
    pool,
    files,
    // ... add more options here
  }

  // At this point there may be previous tasks running on different runtime.
  // All tasks that are now pushed to queue with `run` will start with the new runtime.
  // Note that `run` is not await'ed. Empty queue will indicate finished tasks.
  runningTasks.push(pool.run(data))
  await waitForEmptyQueue()
}

type TestFile = string
const testsByPool: ['threads' | 'forks', TestFile[]][] = [
  ['threads', ['... files ...']],
  ['forks', ['... files ...']],
]

// Run tests
for (const [pool, files] of testsByPool) {
  await runTests(files, pool)
}

// Wait for last round's tasks to finish too
await Promise.all(runningTasks);

await pool.recycleWorkers({ runtime })

Is it fast though? What does this mean for a non-isolated environment? Does it mean we would need to wait to start another process/worker and then restart it again? Can we optimize it somehow? Maybe create half workers and half forks, and close/restart other runtimes (so, 2/2 -> 3/1) when they finish running?

Is it fast though?

Calling recycleWorkers will create new worker with given runtime as soon as it's possible. If there are idle workers with previous runtime, those ones will be destroyed and new ones will be spawned. Recycling this many threads/processes is fast.

What does this mean for a non-isolated environment? Does it mean we would need to wait to start another process/worker and then restart it again?

From Tinypool's API's perspective it's identical usage. When we want to change the runtime, recycleWorkers is needed and new process/worker is spawned.
But note that isolateWorkers option cannot change, just like maxThreads and minThreads. If they need changing, we need multiple instances of Tinypool.

Maybe create half workers and half forks, and close/restart other runtimes (so, 2/2 -> 3/1) when they finish running? (So, when there is a workers queue, but forks are idling)

Currently it's working like this:

Imagine we have 5 tasks where 3 are for worker_threads and 2 for child_process. First 3 tasks take 2s, rest 1s. We allocate 2 threads for Tinypool.
First create worker_threads pool with 2 threads. Push 3 tasks there. 2 tasks start running.
2 tasks finish. 1 task from queue is started.
Pool emits pool.drain event and indicates queue is empty.
We call recycleWorkers and change runtime to child_process. Now Tinypool will destroy the one idle worker and spawns a new one.
1 task is started in child_process, 1 task is still running in worker_threads.
Both tasks are finished. worker_thread worker is recycled and new child_process one is spawned. Both take tasks from queue.

Explaining this would be easier with whiteboard :smile:. Hopefully this explains the situation a bit.

Calling recycleWorkers will create new worker with given runtime as soon as it's possible. If there are idle workers with previous runtime, those ones will be destroyed and new ones will be spawned. Recycling this many threads/processes is fast.

But if we call it 100 times at the same time, and isolation is disabled (so, we only need 4 workers for example) - won't it just create new ones and destroy previous instead of reusing them?

won't it just create new ones and destroy previous instead of reusing them

It will destroy workers and create new ones, yes. And that's expected. We are also using this mechanism when looping over environments:
https://github.com/vitest-dev/vitest/blob/7f5022994ec645838d9fa1867602b2f30d51673a/packages/vitest/src/node/pools/threads.ts#L198-L200
But we definitely should not call it 100 times. Instead, we should sort files by pools and their options like done currently.

Push tasks to pool with initial options
Wait for queue to be empty
Call recycleWorkers to change runtime and other options.
Push tasks to queue and repeat 2-4 until no tasks left.

@AriPerkkio looks like vm now takes even more memory :(

I haven't checked the latest changes yet but by comparing --heap-prof outputs between main and PR it might be visible what's consuming the memory now.
export default defineConfig({
  test: {
    pool: "vmThreads",
    poolOptions: {
      vmThreads: {
        execArgv: ["--heap-prof", "--heap-prof-dir=./profiling"],
      },
    },
  },
});

Then open the files in Chrome dev-tools

I haven't checked the latest changes yet but by comparing --heap-prof outputs between main and PR it might be visible what's consuming the memory now.

export default defineConfig({

  test: {

    pool: "vmThreads",

    poolOptions: {

      vmThreads: {

        execArgv: ["--heap-prof", "--heap-prof-dir=./profiling"],

      },

    },

  },

});

Then open the files in Chrome dev-tools

It looks like vite-node test calls mocked process.exit, can't exit and the memory piles up. I will check it with your example, thank you!

It looks like vite-node test calls mocked process.exit, can't exit

I've also run into this during development. Back then it caused some of those 100% CPU spikes and left zombie processes. Maybe we should add some handling for these cases:
process.exit(1)

+ // This is run if exit was overwritten
+ throw new Error('Unable to exit since process.exit is overwritten')

looks like vm now takes even more memory

What kind of setup does reproducing this require? I'm seeing some memory increment on vm.ts's resolveModule.

What kind of setup does reproducing this require? I'm seeing some memory increment on vm.ts's resolveModule.

I don't know actually, but CI always fails here. I didn't start working on it locally yet.

@AriPerkkio this is reproducible 100% on my local machine:
cd test/vite-node
pnpm test --pool=forks --run

It's called because SIGTERM is triggered by someone (tinypool?)

It's called because SIGTERM is triggered by someone (tinypool?).

Tinypool uses first SIGTERM, which is the default signal when calling process.kill(): https://nodejs.org/api/child_process.html#child_processforkmodulepath-args-options. If process doesn't terminate in time (Tinypool default 1000ms), it calls process.kill('SIGKILL'). This is similar to Jest.
If overwriting process.exit becomes issue I think we could store original copy in Tinypool's entrypoints before any user-provided code is even loaded. And when we start to terminate the processes (or threads), we could restore it back to original one. Doing the same thing in Vitest might be a good thing too.
Is this issue still reproducible easily? I'm interested to see where Node hangs when proces/thread is trying to exit in these cases. Might be able to capture that with debugger. 🤔
I'll take a good look at this PR later this week and run some manual tests myself.

Is this issue still reproducible easily? I'm interested to see where Node hangs when proces/thread is trying to exit in these cases. Might be able to capture that with debugger. 🤔

Yes, if you remove the process.exit assignment in the forks worker.

Need to add await vnServer.server.close() in the test/vite-node/test/server.test.ts tests. Then tests will pass without hacking around process.exit. I think following is happening now:

Vite server remains open once tests exit
Tinypool kills process with process.kill() -> SIGTERM is sent to test process
Vite server running inside that child_process has SIGTERM handler which captures this and calls process.exit: https://github.com/vitejs/vite/blob/f43945c1c35de34d64b2b1772b1629aba83cb476/packages/vite/src/node/server/index.ts#L625-L632
Test process's RPC catches process.exit and sends it to main process via onWorkerExit
Main thread exits process: https://github.com/vitest-dev/vitest/blob/c946b1c841c04f27f026c2b10b7b8f16ac12ceab/packages/vitest/src/node/pools/rpc.ts#L10
Other tests that were running become zombie processes, something like https://github.com/nodejs/node/issues/46569. But I think in this case it's child_process running in child_process

I wonder why we exit whole process here instead of ctx.close(). Maybe we should also call ctx.cancelCurrentRun() before that.
https://github.com/vitest-dev/vitest/blob/c946b1c841c04f27f026c2b10b7b8f16ac12ceab/packages/vitest/src/node/pools/rpc.ts#L8-L11


Tweak extensions page texts

Although it makes for clean left/right alignment, the super-wide Install button looks a little odd (you almost miss that it is a button?)

Although it makes for clean left/right alignment, the super-wide Install button looks a little odd (you almost miss that it is a button?)

That button is not part of this PR so maybe open a separate issue?


Implement Copy for StatusKind

I would expect that a simple enum like StatusKind would always implement Copy. Any reasons why this is currently not the case?

Nope, no good reason. Just missed it.


Fix test for existence of go-nyet.

When the file is not found, which returns an empty string,
which passes the -f test. command -v is the most portable alternative
to which per
http://stackoverflow.com/questions/592620/check-if-a-program-exists-from-a-bash-script/677212#677212
@barakmich

Today I learned.
LGTM


pull request for e2e test at 01/27/2017 20:56:17

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


[Add] Error handling for update method in OSS & platform code.

Description
This PR introduces improved error handling in the update method. If a memory_id does not exist, it now handles the situation gracefully without displaying an error. This change enhances the user experience by preventing unnecessary error messages.
Fixes #xxxx
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[x] Refactor (does not change functionality, e.g. code style improvements, linting)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Please delete options that are not relevant.

[x] Unit Test
[x] Test Script

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
[x] I have checked my code and corrected any misspellings

Maintainer Checklist

[ ] closes #xxxx
[x] Made sure Checks passed

Thank you @parshvadaftari for the contribution.


[Form Provider Refactor] EditRequestDescriptionPage

Details

Changed the Form component into the new FormProvider component in EditRequestDescriptionPage
Fixed Issues

$ https://github.com/Expensify/App/issues/30307
Tests

Log in and go into a chat that has a request in it or create a new one.
Press on the request and then go into the description field.
Update the description text and press save.
Confirm that description updated successfully.

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

Offline tests

QA Steps

[x] 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: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb 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 the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[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] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[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 the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[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

Android: Native
https://github.com/Expensify/App/assets/88325488/c8ad06bc-fe66-4cb5-aa37-42d9432445f3

Android: mWeb Chrome
https://github.com/Expensify/App/assets/88325488/7b90486b-b722-4969-8b9e-29c5a7d120cb

iOS: Native
https://github.com/Expensify/App/assets/88325488/1711e386-bb04-4ae1-a27a-19aa005ca86d

iOS: mWeb Safari
https://github.com/Expensify/App/assets/88325488/0aec838f-f403-457b-ab8c-1c149a4593a4

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/88325488/982ecac2-a3c1-4fc9-884c-d25859661d33

MacOS: Desktop
https://github.com/Expensify/App/assets/88325488/729ac5b5-ec9b-43ef-b19c-45b393b9ccc7

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible 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 checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

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

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (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 the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[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] 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 verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[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] 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 reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://github.com/Expensify/App/assets/28352309/39614a79-2e76-4874-90a4-aee9aaa6a231

Mobile Web - Chrome
https://github.com/Expensify/App/assets/28352309/fc9040fe-313a-4afa-8744-49c4a8897073

Mobile Web - Safari
https://github.com/Expensify/App/assets/28352309/7835e51c-766c-47a8-aba7-f04047e37cce

Desktop
https://github.com/Expensify/App/assets/28352309/4d597857-83db-4884-be02-c16bd32fa2a2

iOS
https://github.com/Expensify/App/assets/28352309/45df8a85-2cc5-471f-b5c2-bbcd3c227a4c

Android
https://github.com/Expensify/App/assets/28352309/b169ec0c-36ea-464c-bb64-7c083454bbeb

: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/luacmartins in version: 1.3.94-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/luacmartins in version: 1.3.94-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Beamanator in version: 1.3.94-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/luacmartins in version: 1.3.95-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.3.95-9 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


expose the raw field of context

i'm learning OpenGL and there's a lot of modern opengl functions/features that i would like to try like DSA or MultiDraw or Indirect rendering. but glow doesn't have most of these functions yet.
but if the core context was exposed either through an unsafe function or by just making the raw field of the Context Struct public, i can just use that to try out all the new latest stuff.

I'd prefer to add these functions to glow instead if possible.
One problem with exposing raw is that the current bindings/binding generation is meant to be an internal implementation detail. e.g. if we change how bindings are generated somehow (function names, types, fallbacks between versions/extensions, which parts of the GL API are included, etc.) then we might break any crates relying on raw

Can we have a sort of contributing.md file ? would help some new people to know how to start contributing as this seems like one of the easiest rust projects to contribute to, especially when they are already familiar with opengl.

Yeah absolutely :+1: I'll try to create one sometime soon

oof, 3 months is a long time. but just wanted to see if there is some kind of progress related to separating platform specific functionality https://github.com/grovesNL/glow/issues/76#issuecomment-576321623 . pretty much none of the modern opengl functions exist in webgl(2) and they will all be unimplemented!().
if there's a sort of winit (platformEXT trait) functionality, lets say DesktopEXT, that will allow people to contribute without having to worry about webgl or openglES. the core HasContext can have upto ES or webgl level of core functionality, and the DesktopEXT can have everything up to the latest 4.6 functions. people who use functions from this trait can check whether their minimum opengl core vesion actually has those functions.
Although, I don't know how something like gl functions that are  in ARB extensions are dealt with. maybe another trait? where everything is allowed. a good example is bindless textures. to quote khronos wiki page
not all 4.3 hardware can handle bindless textures. The OpenGL ARB decided to make the functional optional by having it be an extension. It is implemented across much of the OpenGL 4.x hardware spectrum. Intel is mostly absent, but both AMD and NVIDIA have a lot of hardware that can handle it. .
I only added some dsa functions in https://github.com/grovesNL/glow/pull/191 , and before i start playing with more stuff like multidraw or indirectdraws or bindless textures, I wanted to see if i could avoid polluting webgl context code which will be a lot of unimplemented!() and unnecessary autocompletions.

I would suggest that a trait like that might not belong in this crate which, as you've pointed out, is more about bridging the gap between OpenGL and WebGL than creating a Rusty interface for all of OpenGL. Personally, I like that, generally, the API surface defined in this crate approximates the features that are usable on both platforms. I think I'd rather see a, for example, glow-gl4-ext crate that implements the additional functionality (although at that point I'm not sure why you wouldn't just use the generated GL bindings directly).

ah. my bad. my use case of glow is to just have a clean wrapper instead of raw gl bindings with raw pointers and casts flying around everywhere. i asked in the rust gamedev discord and was told that glow allows stuff that is technically not a strict subset of the es/web/desktop gl versions. like https://github.com/grovesNL/glow/pull/175/commits/c0d566ec7bbbd44d7e9157135577edeac6e65c8c . either the trait way or a separate crate glow-gl4-ext way is fine for me.

Yeah, you're 100% right that there are some places where the practical desire for this to be generally useful has overridden the aspirational desire to represent the API available on both platforms. My personal feelings are that a push to implement all of gl46 in this pseudo-Rusty style that glow does might be too big a departure from the generally state goal of this crate.
But, hell, I'm not the maintainer. :P

ah. my bad. my use case of glow is to just have a clean wrapper instead of raw gl bindings with raw pointers and casts flying around everywhere. i asked in the rust gamedev discord and was told that glow allows stuff that is technically not a strict subset of the es/web/desktop gl versions. like https://github.com/grovesNL/glow/pull/175/commits/c0d566ec7bbbd44d7e9157135577edeac6e65c8c . either the trait way or a separate crate glow-gl4-ext way is fine for me.

It's same for me, I don't use the webgl side of glow at all 😅, and I'm well aware that it's the whole point of this crate

@coderedart for now I think it's fine to add them to the regular HasContext trait, and panic in the web backend implementations for those functions.
We could always consider restructuring it later if this eventually causes problems (e.g. bloating the web backend too much, too confusing when referencing documentation, etc.). In that case we could probably move them into a separate GL-only trait (possibly also behind a feature that's off by default or separate crate).
I'd also like to add doc comments to each function to clarify which versions/backends/extensions support it, which would be a simple way to improve ergonomics in general.

Has anything changed regarding this issue in the last two years? like exposing the raw fn pointers behind a feature like unstable-raw-expose or something similar.
If it feels like we should not expose it, then its probably time to close this issue.

Also asking for this half a year later. I am migrating my codebase from gl to glow because the former seems to be abandoned, as well as I hit a roadblock adding imgui to my SDL project, because imgui SDL support uses glow and I use gl here.

Hi @polyzium 👋 Could you provide an example of the problem you're running into, and how the raw field would help? Is there a crate you're using for imgui SDL support?

@grovesNL gl is a crate containing the raw OpenGL API without any abstractions, it's just a 1-to-1 binding to the C API. And during that time I was following learnopengl.com and translating calls to Rust on the fly. However because glow instead provides abstractions to these APIs, I was confused at first to see no equivalent, that is until I looked at the source code later where e.g. glGenBuffers was hidden under Context::create_buffer. It also makes it very hard if not impossible to refer to resources like the OpenGL spec, docs.gl, or the OpenGL wiki by the Khronos Group themselves. And as many people pointed out in the issues, some functions from the original OpenGL C API are missing/have no Rusty abstractions implemented (yet), and there's also a whole different can of worms in regards to extensions.
As for imgui, I am using imgui-sdl2-support which in turn uses imgui-glow-renderer. I was not able to find a renderer that uses the gl crate, and making my own renderer would take a significant chunk of my time and severely hinder my productivity (same thing goes for egui). In the end I stuck with gl, scrapped the idea and wanted to make my own UI instead.
I know what people might ask me, why didn't I use wgpu-rs as it is a more modern way or something like that. The reality of it is that I don't want to use any graphics API abstractions that might introduce their own behaviours, and I want to have full control over the software I write, like the rest of the gaming industry making their own game engines. In fact this very problem is why I started doing software rendering literally around one and a half weeks ago. Yes it's harder (manual perspective correction and zbuffering), yes it's slower (singlethreaded on the CPU), but it taught me a lot about what 3D graphics consist of, free from the wrath of OpenGL/Vulkan/etc.
Excuse me for the rant, but as you can see I am quite lost.

@polyzium I was wondering how exposing the native context itself would help. Is it because the names are slightly different and you want to use the C names?
glow doesn't try to abstract very much, it's just trying to make it a slightly more convenient where it makes sense and find some common naming between the different GL specifications.
glow doesn't use the gl crate internally, so if you're using gl then there's not much glow can help with.

Could you provide an example of the problem you're running into, and how the raw field would help?

One very obvious issue that I faced in the past is following a gl tutorial and writing a basic game/app.
Now, if I wanted to use a library which uses glow, like the above mentioned imgui-glow-renderer, then I have to port my entire app to using the glow api or maintain two different contexts (a raw gl context for my app and a glow context for the libraries which use glow). My functions will need to pass around these two different contexts to the right places, which.. just feels like unneeded complexity.
If glow exposed the raw context, then I could just do
pub struct MyGlContext(glow::Context);
impl AsRef<glow::Context> for MyGlContext {
	fn as_ref(&self) -> &glow::Context {
		&self.0
	}
}
impl AsRef<RawDesktopGlContext> for MyGlContext {
	fn as_ref(&self) -> &RawDesktopGlContext {
		&self.0.raw // something like this
	}
}

Now, glow based libraries which take &glow::Context and my API which takes &RawDesktopGlContext would both use it. renaming parameter/type (if necessary) across the app is just one find_and_replace away. This allows me to just follow most opengl guides (3 years ago, I was learning about DSA stuff when I raised this issue) without any translations (or worrying about missing functions). opengl has confusing names and glow adds more to this confusion by mixing webgl and desktop gl.
eg: glGenBuffers is the usual thing people learn first in opengl. glow doesn't have that. glow provides create_buffer (singular) instead. If i'm learning modern opengl, I will learn about createBuffers (plural). It very much looks like glow's create_buffer, but its not. Instead it is implemented with glGenBuffers behind the scenes.
At this point, I am comfortable enough with gl/glow that I can more or less figure out the glow's API, but back then, it was one more challenge when learning openGl.

Is it because the names are slightly different and you want to use the C names?

Yeah mostly it is exactly that. I am pretty new to OpenGL but I have a basic understanding of graphics, having worked with programs like Blender before, so it would be helpful if I could use C names, or at least snake_case versions of those.
also as @coderedart pointed out this is the exact issue I have faced. Either I port my app to glow or maintain a bridge between gl and glow.

I'm wondering why you're both wanting to use the imgui-glow-renderer if neither of you want or need to use glow? I would expect you to use the imgui renderer backend associated with the backend you're already using. Maybe this one? https://github.com/michaelfairley/rust-imgui-opengl-renderer

I initially thought of using this one, but it seems like it works only with older imgui-rs and I didn't want to downgrade it just to get it to work.

I just cloned it and bumped the allowed version of imgui. It seems to work just fine. I'm not trying to dissuade you, necessarily, from any pedagogical or functional gripes you may have with glow but I feel like your individual easiest path toward what you seem to want is likely to clone that repo, use your fork as a dependency, bump the version of imgui that it allows, and not worry about glow.

Yeah mostly it is exactly that. I am pretty new to OpenGL but I have a basic understanding of graphics, having worked with programs like Blender before, so it would be helpful if I could use C names, or at least snake_case versions of those.

That makes sense, although there are only a few functions like GenBuffers where the snake case versions don't match.
I'd really recommend trying out a switch to glow and glancing at the source if you can't find something that matches the GL function that you're looking for. I'd like to add more docs to show how each glow function ties to the corresponding functions in the GL specifications but most names are already 1:1 anyway.

imgui is just an example. The ecosystem has settled on glow, and going against that will lead to a lot of friction.
Think of eframe (egui). Its official backend is glow. https://github.com/emilk/egui/tree/master/examples/custom_3d_glow shows how to draw something using glow inside a widget. If you wanted to draw using desktop gl functions, there's not really much of choice.
I think focusing on any particular example would be going too offtopic, as there will always be workarounds. This issue was made when I was just learning openGL (right after learning rust) and back then, it would be really hard to think about forking and patching rust code . Even now, This feature is still useful to me, as I am more likely to use a cool modern gl function if its readily available. But its not absolutely necessary. We can simply workaround by having a fork of glow that exposes the gl fns publicly and Override Crates.io Dependencies to point glow to my fork.
This issue is about whether glow would like to expose its raw fns behind an unstable-raw-gl feature. Its hacky/dirty, but will allow easy access to everything behind an unstable feature flag. If not, this issue should probably be closed.
For more general discussion of how to expose platform specific gl functionality, see https://github.com/grovesNL/glow/issues/76#issuecomment-576321623 .


Actually warn when no projector/reactor is registered

I was investigating why none of my events were actually taken into account, and noticed that the event-project:list command didn't actually output anything.
It seems like the intent of whoever wrote that command was to warn the user, stating that no reactor/projector was found, but the actual $this->warn(...) was forgotten.
This PR simply adds them, so that debugging is a little bit easier.

Thanks!


Support for diffraction

Sounds that are occluded by pillars, walls, etc. sound too aggressively attenuated, because diffraction is not simulated. Adding support for simulating diffraction along with reflections should help reduce some of these issues.


Add Download Button

Add a Download button that takes them to #4 .
Time estimate: 1D
Check story #8 for more details/context.

Alonzo completed and tested this.

Done.


Featured post should not appear twice on main page

I want to "feature" some articles on the home page, but featuring the most recent post results in duplicate entries. I hope the theme can be improved so that if article is in featured, it will not appear again next to it:

I'm not sure if this is really the desired behaviour, if you hide the featured articles because they appear in the slider there is a real chance that people won’t be able to see some of those posts, I think there is no issue if people see some post on different places, that's better than not seen some post at all.
If you really want to hide duplicate entries then you can do the following:

Unzip the theme folder.

Open the file partials/loop.hbs with a text/code editor.

Locate the following line:

Replace it with this other line:

This line of code adds the class hide-card to the articles if they are featured, listed in the home page and if their index is less than 5 which is the max number of slides in the featured slider.

Save your changes.

Zip the theme folder and upload it again.

Inject the following style in the Ghost Admin (Settings -> Code injection -> Site Header):

Save your changes.


FODT conversion ignores embedded HTML

Easy way to reproduce:

Insert the following line anywhere in your MMD file:

This paragraph doesn't appear in the output.

Convert it: multimarkdown --to=odf test.txt >test.fodt

Open the output file in LibreOffice. None of the embedded HTML shows up. If you open the file in a text editor, it's not even passed through to the fodt file.

This is important because, while I publish to HTML for production through EPUB, I need a word processor file for editing and beta readers. In more technical (writing) terms, it makes single-sourcing difficult.

Correct.  Because HTML != ODF.  And HTML != LaTeX.
Embedded HTML is ignored when converting to non-HTML formats, because other formats would not "know" what to do with a bunch of raw HTML stuck in the middle.
What is it that you're hoping to accomplish by allowing raw HTML inside an ODF document?  It will (in all likelihood) simple cause the ODF document to not be valid, and to not open in anything other than a text editor.
If you want to allow raw HTML to be viewed inside other formats, they could be fenced so that they would appear as code blocks in the other formats?  That would mean, of course, that they would be code blocks in HTML as well, though.
You could use some file transclusion trickery to cause HTML snippets to work normally in HTML files and appear as code blocks in other formats, but this is going to get pretty complicated.

Your response gave me a hint that led to at least a partial solution: using transclusion with wildcards.
There are a few limitations: using something like • to specify a bullet gets dropped, and using a non-standard style name doesn't get preserved (I had planned to define the style in LibreOffice, whatever).
Thanks for your help, I'll close this.

Non-standard styles would require modifying the MMD source so that they are included.  Not difficult to do, just tedious.
Wildcard transclusion can be quite flexible.  I'm trying to come up with something more flexible for MMD 6:
https://github.com/fletcher/MultiMarkdown-6/issues/38

Looks promising! I have to admit, though, I'm amused at the emphasis on performance. My test document is a 42,000-word novella exported from Scrivener, roughly 250K. Version 5.4.0 takes less than half a second to process the thing, barely enough to notice a pause, and that's with using wildcard transclusions for section breaks. It's tons faster than Jekyll, I can tell you. ;-)

Yeah....   But when the "competition" is 20-40 times faster, it meant there was room for improvement.  I needed to do a rewrite anyway, and figured I might as well push for the performance in addition to accuracy and new features.  Now you can process your document a 1000x over in a second or two.... ;)  Not sure why you'd want to do that, but you could....
(It's more that high performance is useful for servers and for MultiMarkdown Composer, not as much for a single document)

It's tons faster than Jekyll, I can tell you. ;-)

I wonder how much of the difference in speed is inherent from the language itself tough. And there's a lot of design choice behind choosing a language, and Jekyll has a very different emphasis (so do GitHub Markdown/pandoc for example).

I am not a world class coder, or formally trained computer scientist.  But it seems that short of hand-rolled assembly, it's tough to beat C in terms of raw power/speed.  MMD v3 was based on peg-markdown, and at the time it was one of the fastest markdown parsers around.  The use of a PEG to define the grammar was still reasonably fast, and gave the added benefit of making the grammar of the language clear.
A few years later, and hand-rolled parsers are kicking the PEG parsers' A$$.  It took me a while to find a system I like, but MMD 6 is lightning fast, but more important to me -- it still allows for a design that can be understood and easily extended.  It's not so "optimized" that it becomes unintelligible to humans.
Plus, I have to admit it was fun to push myself to keep making it faster and faster, despite adding some fairly complex features.  ;)

But it seems that short of hand-rolled assembly, it's tough to beat C in terms of raw power/speed.

Totally agree. there's a tool in https://godbolt.org that can help you to see how your C code will be transformed into assembly, that even if we don't code in assembly, we can still tune our code such that the compiler can be transformed into better assembly code.
There are a few other languages that can get close to C speed (ignoring the close relatives of C): Cython, Julia, Fortran. The later 2 are really mainly for scientific applications only. Personally Cython is very interesting (you can basically write C in Python syntax given a certain rules are followed, but without#prama, assembly, etc. kind of low level access).
Pardon me for a beginner's question (never study the MMD C code): does it use an internal AST like pandoc did, and would it be feasible to extend MMD in the way similar to pandoc? (i.e. any format to AST to any other format)

Yes - MultiMarkdown 6 (just like every version since 3) uses an AST structure as part of the transformation process. That allows the same model to easily be translated to HTML, LaTeX, ODF, etc. Each export format is coded in a separate file.
It's certainly possible to write parsers for reading other formats (e.g. HTML).
One thing that is different about MultiMarkdown 6 is that for memory and performance reasons, the source text is not copied to the AST, but rather referenced by offset within the source.  This would require some creativity to work around with other document formats but presumably could be done. I haven't needed it myself, but have thought about it if I ever find myself bored. ;)
Sent from my iPhone

On Mar 9, 2017, at 8:52 PM, ickc<EMAIL_ADDRESS>wrote:
But it seems that short of hand-rolled assembly, it's tough to beat C in terms of raw power/speed.
Totally agree. there's a tool in https://godbolt.org that can help you to see how your C code will be transformed into assembly, that even if we don't code in assembly, we can still tune our code such that the compiler can be transformed into better assembly code.
There are a few other languages that can get close to C speed (ignoring the close relatives of C): Cython, Julia, Fortran. The later 2 are really mainly for scientific applications only. Personally Cython is very interesting (you can basically write C in Python syntax given a certain rules are followed, but without#prama, assembly, etc. kind of low level access).
Pardon me for a beginner's question (never study the MMD C code): does it use an internal AST like pandoc did, and would it be feasible to extend MMD in the way similar to pandoc? (i.e. any format to AST to any other format)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

There are so many HTML parsers out there that I can't imagine not just using one of those. But I'm lazy like that---I'm no world-class coder, either, and I figure I couldn't do better.
The outliner I maintain (Tines) includes an XML parser from the original coder. I have it on my list to replace it with xmllib sooner or (more likely) much later.

Another curious question is, is it parallelized? If not, what are the obstacles on parallelizing it? (sorry for digressing but since this issue was digressing I hope it is fine.)

Is what parallelized?  Do you mean can a single MMD text string be simultaneously processed on multiple threads and then re-joined into a single output string at the end?  No.  What would be the benefit of doing this?  20-25 megabytes of data can be processed on a single thread per second (on my laptop and desktop, both of which are several years old).  The average real world use file is MUCH smaller than this.  The overhead and complexity of multithreading this would seem to be very low yield, and migh actually worsen performance in most cases, but that's a guess.

migh actually worsen performance in most cases

Right. If there's a lot of small documents, it should be parallelized on the other side (e.g. makefile). From what you said (and didn't say), it seems there's never a complain that a document is too large that MMD will choke on. In that case there's no point of chopping it into smaller chunks.
One place that could have potential trivial parallelization is from transclusion, except that MMD's transclusion behavior prevents this (which have other benefits).

The main problem is running out of memory on your machine.  I routinely test using 100-110 megabyte files that parse in 4-5 seconds.
I posted a bit of information about performance on the README, and plan on expanding a bit on that in the future.  Some of the development process was pretty interesting.

@larrykollar I checked out a video of Tines -- it looks interesting.  The last thing I need is another rabbit hole right now, but the latest text editing engine for MultiMarkdown Composer is written in C, and designed to be cross-platform.  I've often thought it would be handy to be able to run Composer in a terminal session in order to make editing MD/MMD files easier.....  Your video rekindled my interest in doing that sometime....  Darn you!  ;)

If you ever do it, I'll be glad to beta test it!


VideoStreamPlayer causes random crashes on a Windows export without "Export with Debug"

Godot version
4.1.beta3, 4.0.3.stable
System information
Godot v4.1.beta3 - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 Ti (NVIDIA; <IP_ADDRESS>98) - Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz (6 Threads)
Issue description
The game crashes on a Windows export without "Export with Debug" when I use VideoStreamPlayer node as a background in my scene.
I have created 2 simple scenes with VideoStreamPlayer and a button in each to switch between them. When I run the game in the editor, it works fine, when I export it with debug it works fine. As soon as I untick "Export with Debug" the game crashes randomly, sometimes after a few button clicks(changing scenes), sometimes on the first click... The console gives no errors whatsoever...
Tried to do it in both: Godot 4.0.3 and 4.1 beta3, the result is the same.
I have also recreated this in Godot 3.5.2, the exported game without "Export with Debug" works fine, without crashes at all.
I have spent 4-5 hours yesterday searching internet and trying to fix it, but I couldn't. Tried different ffmpeg builds to convert the video, tried different video framerates, with audio and without audio... Looks like it's a Godot 4 issue.
Steps to reproduce
1 - create a scene, add VideoStreamPlayer node, assign your video to it.
2 - create another scene with a VideoStreamPlayer node and assign your video to it.
3 - create buttons on each scene to switch between them.
4 - export your project for windows without "Export with Debug"
5 - play the game, after switching the scenes a couple of time, the game will crash.
Minimal reproduction project
Crash_Test_3.zip

Tested the MRP on Linux and I can't reproduce a crash with the Linux release export template or the Windows release export template (through Wine), so this may be Windows specific.
With the Linux template, I get these errors raised occasionally when switching scenes, which can relate to what would be causing a crash on Windows:
ERROR: Condition "slot >= slot_max" is true. Returning: nullptr
   at: get_instance (./core/object/object.h:986)

I have just played the exported game on Windows 8.1 and didn't get any crashes, although I have switched scenes about 100 times... Then I closed the game with Alt+F4 and reopened it. I got a crash after 3 clicks... Weird...

Tested the MRP on Linux and I can't reproduce a crash with the Linux release export template or the Windows release export template (through Wine), so this may be Windows specific.
With the Linux template, I get these errors raised occasionally when switching scenes, which can relate to what would be causing a crash on Windows:
ERROR: Condition "slot >= slot_max" is true. Returning: nullptr
   at: get_instance (./core/object/object.h:986)

What is causing this error? Do you know how to fix it?

This error signals an internal engine bug, it's not something you're doing wrong and can fix, at most you can try to change how you change scenes to work it around.
https://github.com/godotengine/godot/blob/9a09ee5d0217c4d5e5668fccddfa477bf16af357/core/object/object.h#L982-L986

You can do something like this:
func _on_button_pressed():
	var new_scn = load("res://scene_2.tscn").instantiate()
	$/root.add_child(new_scn)
	self.queue_free()

And likewise for main.tscn.
This adds the new scene to the root, and then frees the old scene after a delay, which seems to prevent the error in my test, so it might fix the crash on Windows.
change_scene_to_file seems to be too eager freeing the old scene while it's still in use maybe.

You can do something like this:
func _on_button_pressed():
	var new_scn = load("res://scene_2.tscn").instantiate()
	$/root.add_child(new_scn)
	self.queue_free()

And likewise for main.tscn.
This adds the new scene to the root, and then frees the old scene after a delay, which seems to prevent the error in my test, so it might fix the crash on Windows.
change_scene_to_file seems to be too eager freeing the old scene while it's still in use maybe.

Thanks for your reply! Sadly your workaround didn't fix random crashes, checked it on Windows 10 and Windows 8.1.

Reopening, because https://github.com/godotengine/godot/pull/78987 is getting reverted.

This might have been fixed by #78988. At least for me the errors reported in https://github.com/godotengine/godot/issues/78788#issuecomment-1611195492 are no longer reproduced in 4.2-rc1.
Could you test to confirm whether 4.2-rc1 (or any later version when you get to test) solves the crash you had on Windows?

Based on my tests I'll close this as fixed by #78988, but please let us know if you still reproduce that crash in 4.2-rc1 or later.


Calculate Simple-Interest

Project title
(Calculate Simple Interest)
Project Description
(There will container after loading containing different sections as principal, rate, amount, and time in two different sections as in year and month just need to fill corresponding value to the input and by the next moment, you will get the simple interest of your principal.)
Stack:
And in order to tick the check box just but x inside them for example - [x] like this. Please delete options that are not relevant.

[x] Html
[x] CSS
[x] JavaScript

for more details please refer to the attached images.

for live preview refer to this video
https://user-images.githubusercontent.com/73521123/164768409-4ba8358a-6ce6-4c83-bc72-9ac010a54194.mp4

/assign


Fix undefined variables in wow64 exception context

When compiling Geronimo on Windows using MinGW-w64, I got the following error:
[ 76%] Building CXX object CMakeFiles/Geronimo.dir/C_/Persoonlijk/Projecten/SeriousProton2/src/exception/win32/context.cpp.obj
C:\Persoonlijk\Projecten\SeriousProton2\src\exception\win32\context.cpp: In constructor 'sp::exception::Win32StackWalkContext::Win32StackWalkContext(sp::exception::Win32ExceptionContext&)':
C:\Persoonlijk\Projecten\SeriousProton2\src\exception\win32\context.cpp:30:20: error: 'hProcess' was not declared in this scope
     IsWow64Process(hProcess, &wow64);
                    ^~~~~~~~
C:\Persoonlijk\Projecten\SeriousProton2\src\exception\win32\context.cpp:30:20: note: suggested alternative: 'OpenProcess'
     IsWow64Process(hProcess, &wow64);
                    ^~~~~~~~
                    OpenProcess
C:\Persoonlijk\Projecten\SeriousProton2\src\exception\win32\context.cpp:36:36: error: 'thread' was not declared in this scope
         if (!Wow64GetThreadContext(thread, &wow64context))
                                    ^~~~~~
C:\Persoonlijk\Projecten\SeriousProton2\src\exception\win32\context.cpp:36:36: note: suggested alternative: '_hread'
         if (!Wow64GetThreadContext(thread, &wow64context))
                                    ^~~~~~
                                    _hread
mingw32-make[2]: *** [CMakeFiles\Geronimo.dir\build.make:539: CMakeFiles/Geronimo.dir/C_/Persoonlijk/Projecten/SeriousProton2/src/exception/win32/context.cpp.obj] Error 1
mingw32-make[1]: *** [CMakeFiles\Makefile2:299: CMakeFiles/Geronimo.dir/all] Error 2
mingw32-make: *** [Makefile:151: all] Error 2

It seems that these undefined variables need to be obtained from the context in the parameter, though I have little idea of how they work. It compiles now, but did I get that right?

Guess you are building 64bit instead of my 32bit build?

Yes, I'm using MinGW-w64 to build in 64-bit, so that uintptr_t should be 64 bits for me and 32 bits for you.

Note that mingw-w64 comes in 4 flavors:

i686-w64-mingw32-gcc-win32
i686-w64-mingw32-gcc-posix
x86_64-w64-mingw32-gcc-win32
x86_64-w64-mingw32-gcc-posix
So mingw-w64 has both 32bit and 64bit variants. I've been using the 32bit variant i686-w64-mingw32-gcc-posix. The -win32 variants won't work, as they lack std::thread support.

When I use the x86_64-w64-mingw32-gcc-posix, I still the the following error after this patch:
/home/daid/SeriousProton2/src/exception/win32/context.cpp: In constructor 'sp::exception::Win32StackWalkContext::Win32StackWalkContext(sp::exception::Win32ExceptionContext&)':
/home/daid/SeriousProton2/src/exception/win32/context.cpp:36:75: error: 'Wow64GetThreadContext' was not declared in this scope
         if (!Wow64GetThreadContext(exception_context.thread, &wow64context))

When I use the x86_64-w64-mingw32-gcc-posix, I still the the following error after this patch:

Oh yeah I ran into that one as well. It turned out to be a bug in the winbase.h header that was supplied with MinGW (or at least I think so). It was defining _WIN32_WINNT to be 502 or something which was equivalent to Windows Server 2003. Winbase was defining Wow64GetThreadContext only if _WIN32_WINNT was greater than 600. I looked it up and my Windows 8.1 OS should define that to 603, so I set it to 603 in MinGW and then it did find Wow64GetThreadContext and compiled fine.

_WIN32_WINNT defines the minimal version your code will run on, so 502 targets windows 2003 server or newer, I think that's also pretty much the first 64 bit version of windows.
https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-wow64getthreadcontext
This also states Vista is the minimal windows version for this function.


Fix trigger release job only after successful build and test

Fixed an issue where the Release job would run even if the Build and Test job failed. Now, the Release job will only execute after both Build and Test jobs are successful.
This was resolved by using workflow_call to trigger the build-and-test workflow from the release job, adding an extra verification step.
Also, fixed the GLIBC_2.28 not found error on Ubuntu 18.04 and lower versions. Added an env variable to allow the use of an unsecure Node version to resolve this issue.
Reference: https://github.com/actions/checkout/issues/1590

All pipelines have succeeded!


Why is the demo site harvesting phone numbers

^^title^^

@bdmorin
Oh, I stopped hosting this project on the "demo site", which Im using now for another project. Removed the link


Broken link in k8s.io/releases/release-managers/

This is a Bug Report

Problem:
All the Security Response Committee hyperlinks which are pointing to this link are broken.
Proposed Solution:
I suppose it should point to this link now.
Page to Update:
https://kubernetes.io/releases/release-managers/
/language en

Can I work on this?


[AutoPR] alertsmanagement/resource-manager

Created to accumulate context: alertsmanagement/resource-manager

(message created by the CI based on PR content)

@AutorestCI rebuild https://github.com/Azure/azure-rest-api-specs/blob/master/specification/alertsmanagement/resource-manager/readme.md

Working on generating https://github.com/azure/azure-rest-api-specs/blob/master/specification/alertsmanagement/resource-manager/readme.md for you!!!

Nothing to rebuild, this PR is up to date

Codecov Report

Merging #3723 into master will decrease coverage by 3.83%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3723      +/-   ##
==========================================
- Coverage   53.41%   49.57%   -3.84%
==========================================
  Files       10460     6227    -4233
  Lines      219328   174459   -44869
==========================================
- Hits       117153    86489   -30664
+ Misses     102175    87970   -14205

Impacted Files
Coverage Δ

...afactory/azure/mgmt/datafactory/models/__init__.py
50.94% <0%> (-49.06%)
:arrow_down:

...ration/azure/mgmt/datamigration/models/__init__.py
51.78% <0%> (-48.22%)
:arrow_down:

...ure/mgmt/recoveryservicesbackup/models/__init__.py
51.91% <0%> (-48.09%)
:arrow_down:

...ights/azure/applicationinsights/models/__init__.py
53% <0%> (-47%)
:arrow_down:

.../azure/mgmt/compute/v2018_10_01/models/__init__.py
53.16% <0%> (-46.84%)
:arrow_down:

.../azure/mgmt/compute/v2018_06_01/models/__init__.py
53.23% <0%> (-46.77%)
:arrow_down:

...ure-mgmt-media/azure/mgmt/media/models/__init__.py
53.33% <0%> (-46.67%)
:arrow_down:

...t/containerregistry/v2018_09_01/models/__init__.py
53.59% <0%> (-46.41%)
:arrow_down:

...e/cognitiveservices/vision/face/models/__init__.py
53.75% <0%> (-46.25%)
:arrow_down:

...iveservices/search/entitysearch/models/__init__.py
53.75% <0%> (-46.25%)
:arrow_down:

... and 4339 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8f74d43...e321d10. Read the comment docs.

Swagger is incorrect, would need a fix before being updated in Python


Allow unverified metadata servers

This PR adds the ssl_verify flag to the metadata configuration file, which is used to set the verify argument to requests.post in zenodo.post_metadata.
Fixes #52

😆 Yes, but tricky to test because it needs a server to respond. Not sure how that is done. There are no tests for the entire zenodo module at the moment.


custom keybindings fail with urwid 2.0.1 and python3.8

I've installed vit from the 2.x branch and my keybindings seem to be failing because of, what I believe is, an incompatibility with urwid 2.0.1
$ vit --version
2.0.0

Traceback (most recent call last):
  File "/usr/bin/vit", line 11, in <module>
    load_entry_point('vit==2.0.0', 'console_scripts', 'vit')()
  File "/usr/lib/python3.8/site-packages/vit-2.0.0-py3.8.egg/vit/command_line.py", line 5, in main
    Application(options, filters)
  File "/usr/lib/python3.8/site-packages/vit-2.0.0-py3.8.egg/vit/application.py", line 74, in __init__
    self.loop.run()
  File "/usr/lib/python3.8/site-packages/urwid/main_loop.py", line 286, in run
    self._run()
  File "/usr/lib/python3.8/site-packages/urwid/main_loop.py", line 384, in _run
    self.event_loop.run()
  File "/usr/lib/python3.8/site-packages/urwid/main_loop.py", line 788, in run
    self._loop()
  File "/usr/lib/python3.8/site-packages/urwid/main_loop.py", line 825, in _loop
    self._watch_files[fd]()
  File "/usr/lib/python3.8/site-packages/urwid/raw_display.py", line 403, in <lambda>
    wrapper = lambda: self.parse_input(
  File "/usr/lib/python3.8/site-packages/urwid/raw_display.py", line 502, in parse_input
    callback(processed, processed_codes)
  File "/usr/lib/python3.8/site-packages/urwid/main_loop.py", line 411, in _update
    self.process_input(keys)
  File "/usr/lib/python3.8/site-packages/urwid/main_loop.py", line 517, in process_input
    something_handled |= bool(self.unhandled_input(k))
  File "/usr/lib/python3.8/site-packages/urwid/main_loop.py", line 563, in unhandled_input
    return self._unhandled_input(input)
  File "/usr/lib/python3.8/site-packages/vit-2.0.0-py3.8.egg/vit/application.py", line 341, in key_pressed
    self.execute_macro(keys)
  File "/usr/lib/python3.8/site-packages/vit-2.0.0-py3.8.egg/vit/application.py", line 226, in execute_macro
    keypresses = self.prepare_keybinding_keypresses(keybinding['keys'])
  File "/usr/lib/python3.8/site-packages/vit-2.0.0-py3.8.egg/vit/application.py", line 236, in prepare_keybinding_keypresses
    return reduce(reducer, keypresses, [])
  File "/usr/lib/python3.8/site-packages/vit-2.0.0-py3.8.egg/vit/application.py", line 232, in reducer
    accum += list(key())
TypeError: 'bool' object is not iterable

That's a Python error, most likely due to a mis-configuration of your keybindings.

That's a Python error, most likely due to a mis-configuration of your keybindings.

This is the keybinding I'm trying to use (which used to work before I updated to latest master)
o = :!wr /home/flaper87/.bin/task-pr.sh {TASK_UUID}<Enter>
What am I missing?

If that started happening after updating to python 3.8, it may be caused by the same reason that this tasklib bug.
As shown there, it was fixed by this pull request, which was included in version 1.3.0 of tasklib. So if you haven't already, please update to tasklib 1.3.0 and see if that fixes your problem.

If that started happening after updating to python 3.8, it may be caused by the same reason that this tasklib bug.
As shown there, it was fixed by this pull request, which was included in version 1.3.0 of tasklib. So if you haven't already, please update to tasklib 1.3.0 and see if that fixes your problem.

Thanks! I think it's indeed related to the upgrade to 3.8. I'll update tasklib :)


Fix badges for GitHub

Bump

Please use these changes, https://github.com/mitchellh/vagrant-aws/pull/554
The linking does not work with [gem]: http://...
I can close my PR, but I wanted to show what more changes are needed.

The linking DOES work, see the rendered version


simple-watcher.py error: Request Timeout Retry RPC Call on node: https://api.hive.blog

$ python simple-watcher.py
Error: Request Timeout
Retry RPC Call on node: https://api.hive.blog (1/5)

Retrying in 0 seconds

Error: Request Timeout
Retry RPC Call on node: https://api.hive.blog (2/5)

Retrying in 2 seconds

Error: Request Timeout
Retry RPC Call on node: https://api.hive.blog (3/5)

Retrying in 3 seconds

Error: Request Timeout
Retry RPC Call on node: https://api.hive.blog (4/5)

Retrying in 5 seconds

Error: Request Timeout
Retry RPC Call on node: https://api.hive.blog (5/5)

Retrying in 6 seconds

output: None of identifier 81906994
Error: Request Timeout
Retry RPC Call on node: https://api.hive.blog (1/5)

Retrying in 0 seconds

Error: Request Timeout
Retry RPC Call on node: https://api.hive.blog (2/5)

Retrying in 2 seconds

Error: Request Timeout
Retry RPC Call on node: https://api.hive.blog (3/5)

Retrying in 3 seconds

Error: Request Timeout
Retry RPC Call on node: https://api.hive.blog (4/5)

Retrying in 5 seconds

Error: Request Timeout
Retry RPC Call on node: https://api.hive.blog (5/5)

Retrying in 6 seconds

Traceback (most recent call last):
  File "/home/ryan/build/podping-hivewatcher/simple-watcher.py", line 89, in <module>
    main()
  File "/home/ryan/build/podping-hivewatcher/simple-watcher.py", line 56, in main
    start_block = block_num_back_in_minutes(blockchain, 15)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/ryan/build/podping-hivewatcher/simple-watcher.py", line 45, in block_num_back_in_minutes
    block_num = blockchain.get_estimated_block_num(back_time)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/ryan/.local/lib/python3.11/site-packages/beem/blockchain.py", line 325, in get_estimated_block_num
    last_block = self.get_current_block()
                 ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/ryan/.local/lib/python3.11/site-packages/beem/blockchain.py", line 300, in get_current_block
    return Block(
           ^^^^^^
  File "/home/ryan/.local/lib/python3.11/site-packages/beem/block.py", line 70, in __init__
    super(Block, self).__init__(
  File "/home/ryan/.local/lib/python3.11/site-packages/beem/blockchainobject.py", line 137, in __init__
    self.refresh()
  File "/home/ryan/.local/lib/python3.11/site-packages/beem/block.py", line 163, in refresh
    raise BlockDoesNotExistsException("output: %s of identifier %s" % (str(block), str(self.identifier)))
beem.exceptions.BlockDoesNotExistsException: output: None of identifier 81906994

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/ryan/build/podping-hivewatcher/simple-watcher.py", line 92, in <module>
    main()
  File "/home/ryan/build/podping-hivewatcher/simple-watcher.py", line 56, in main
    start_block = block_num_back_in_minutes(blockchain, 15)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/ryan/build/podping-hivewatcher/simple-watcher.py", line 45, in block_num_back_in_minutes
    block_num = blockchain.get_estimated_block_num(back_time)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/ryan/.local/lib/python3.11/site-packages/beem/blockchain.py", line 325, in get_estimated_block_num
    last_block = self.get_current_block()
                 ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/ryan/.local/lib/python3.11/site-packages/beem/blockchain.py", line 300, in get_current_block
    return Block(
           ^^^^^^
  File "/home/ryan/.local/lib/python3.11/site-packages/beem/block.py", line 70, in __init__
    super(Block, self).__init__(
  File "/home/ryan/.local/lib/python3.11/site-packages/beem/blockchainobject.py", line 137, in __init__
    self.refresh()
  File "/home/ryan/.local/lib/python3.11/site-packages/beem/block.py", line 163, in refresh
    raise BlockDoesNotExistsException("output: %s of identifier %s" % (str(block), str(self.identifier)))
beem.exceptions.BlockDoesNotExistsException: output: None of identifier 81907007

@agates Is the simple watcher deprecated at this point?  I think it basically is right?

FYI, the same node also fails in hive-watcher.py among others:
2024-01-16T02:09:14+1100 | INFO backoff MainThread : |  Backing off _req(...) for 0.6s (requests.exceptions.HTTPError: 521 Server Error:  for url: https://rpc.mahdiyari.info/)
2024-01-16T02:09:15+1100 | INFO backoff MainThread : |  Backing off _req(...) for 0.4s (requests.exceptions.HTTPError: 521 Server Error:  for url: https://rpc.mahdiyari.info/)
2024-01-16T02:09:16+1100 | ERROR backoff MainThread : |  Giving up _req(...) after 3 tries (requests.exceptions.HTTPError: 521 Server Error:  for url: https://rpc.mahdiyari.info/)
2024-01-16 02:09:16,325 lighthive    ERROR    521 Server Error:  for url: https://rpc.mahdiyari.info/
2024-01-16T02:09:16+1100 | ERROR lighthive MainThread : |  521 Server Error:  for url: https://rpc.mahdiyari.info/
2024-01-16 02:09:16,325 lighthive    WARNING  Ignoring node https://rpc.mahdiyari.info for 3600 seconds: ('get_dynamic_global_properties',), {}
2024-01-16T02:09:16+1100 | WARNING lighthive MainThread : |  Ignoring node https://rpc.mahdiyari.info for 3600 seconds: ('get_dynamic_global_properties',), {}
2024-01-16T02:09:22+1100 | INFO backoff MainThread : |  Backing off _req(...) for 0.5s (requests.exceptions.HTTPError: 521 Server Error:  for url: https://rpc.mahdiyari.info/)
2024-01-16T02:09:23+1100 | INFO backoff MainThread : |  Backing off _req(...) for 1.0s (requests.exceptions.HTTPError: 521 Server Error:  for url: https://rpc.mahdiyari.info/)
2024-01-16T02:09:24+1100 | ERROR backoff MainThread : |  Giving up _req(...) after 3 tries (requests.exceptions.HTTPError: 521 Server Error:  for url: https://rpc.mahdiyari.info/)
2024-01-16 02:09:24,725 lighthive    ERROR    521 Server Error:  for url: https://rpc.mahdiyari.info/
2024-01-16 02:09:24,725 lighthive    ERROR    521 Server Error:  for url: https://rpc.mahdiyari.info/
2024-01-16T02:09:24+1100 | ERROR lighthive MainThread : |  521 Server Error:  for url: https://rpc.mahdiyari.info/
2024-01-16 02:09:24,726 lighthive    WARNING  Ignoring node https://rpc.mahdiyari.info for 3600 seconds: ('get_block', {'block_num': 81941038}), {}
2024-01-16 02:09:24,726 lighthive    WARNING  Ignoring node https://rpc.mahdiyari.info for 3600 seconds: ('get_block', {'block_num': 81941038}), {}
2024-01-16T02:09:24+1100 | WARNING lighthive MainThread : |  Ignoring node https://rpc.mahdiyari.info for 3600 seconds: ('get_block', {'block_num': 81941038}), {}
2024-01-16T02:09:32+1100 | INFO backoff MainThread : |  Backing off _req(...) for 0.6s (requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='api.hive.blog', port=443): Read timed out. (read timeout=3))
2024-01-16T02:09:37+1100 | INFO backoff MainThread : |  Backing off _req(...) for 0.4s (requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='api.hive.blog', port=443): Read timed out. (read timeout=3))
2024-01-16T02:09:41+1100 | ERROR backoff MainThread : |  Giving up _req(...) after 3 tries (requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='api.hive.blog', port=443): Read timed out. (read timeout=3))
2024-01-16 02:09:41,779 lighthive    ERROR    HTTPSConnectionPool(host='api.hive.blog', port=443): Read timed out. (read timeout=3)
2024-01-16 02:09:41,779 lighthive    ERROR    HTTPSConnectionPool(host='api.hive.blog', port=443): Read timed out. (read timeout=3)
2024-01-16T02:09:41+1100 | ERROR lighthive MainThread : |  HTTPSConnectionPool(host='api.hive.blog', port=443): Read timed out. (read timeout=3)
2024-01-16 02:09:41,780 lighthive    WARNING  Ignoring node https://api.hive.blog for 3600 seconds: ('get_block', {'block_num': 81941039}), {}
2024-01-16 02:09:41,780 lighthive    WARNING  Ignoring node https://api.hive.blog for 3600 seconds: ('get_block', {'block_num': 81941039}), {}
2024-01-16T02:09:41+1100 | WARNING lighthive MainThread : |  Ignoring node https://api.hive.blog for 3600 seconds: ('get_block', {'block_num': 81941039}), {}
2024-01-16T02:09:42+1100 | INFO backoff MainThread : |  Backing off _req(...) for 0.7s (requests.exceptions.HTTPError: 502 Server Error: Bad Gateway for url: https://rpc.ecency.com/)
2024-01-16T02:09:44+1100 | INFO backoff MainThread : |  Backing off _req(...) for 0.7s (requests.exceptions.HTTPError: 502 Server Error: Bad Gateway for url: https://rpc.ecency.com/)
2024-01-16T02:09:46+1100 | ERROR backoff MainThread : |  Giving up _req(...) after 3 tries (requests.exceptions.HTTPError: 502 Server Error: Bad Gateway for url: https://rpc.ecency.com/)
2024-01-16 02:09:46,440 lighthive    ERROR    502 Server Error: Bad Gateway for url: https://rpc.ecency.com/
2024-01-16 02:09:46,440 lighthive    ERROR    502 Server Error: Bad Gateway for url: https://rpc.ecency.com/
2024-01-16T02:09:46+1100 | ERROR lighthive MainThread : |  502 Server Error: Bad Gateway for url: https://rpc.ecency.com/
2024-01-16 02:09:46,440 lighthive    WARNING  Ignoring node https://rpc.ecency.com for 3600 seconds: ('get_block', {'block_num': 81941039}), {'num_retries': 2}
2024-01-16 02:09:46,440 lighthive    WARNING  Ignoring node https://rpc.ecency.com for 3600 seconds: ('get_block', {'block_num': 81941039}), {'num_retries': 2}
2024-01-16T02:09:46+1100 | WARNING lighthive MainThread : |  Ignoring node https://rpc.ecency.com for 3600 seconds: ('get_block', {'block_num': 81941039}), {'num_retries': 2}

I've never used simple-watcher for what it's worth... but it might want to remove the failing server from the accepted node list if it continues.
They come and go, so I'm not surprised.  That's why I added the backoff logic to lighthive.


[FR]: TV app please!

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the problem
I want to learn how to make scalable TV applications with Jetpack Compose, but confused about the overlap between the TV Jetpack libraries, the Leanback libraries and the standard (phone/tablet) Jetpack Compose.
I feel this is the perfect sample app to demonstrate multi-device support in Android, because it is so modular.
Describe the solution
Please add a TV variant of the app using TV Material 3 to browse and watch the Now In Android videos.
Bonus points for using media3, and Picture-in-picture (PiP).
Additional context
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Certainly doable, sometime ago I made a simple prototype 😄

Next steps: Create a design doc for this feature @mmoczkowski and @dturner determine priority (currently setting to P1).


Add require: false to README?

I ran into the issue described here: https://github.com/mkhairi/materialize-sass/issues/34 and had to add require: false when I switched from scss-lint to the scss_lint gem in order to precompile assets.  Is it worth a mention in the README?

Good idea, @golmansax. I've done this in d495bc66b45920023855e76c5b8e8a55b38d3633. Thanks!


Sequence load 1d (Add SequencesLoader class)

Summary Change Description
Implemented the sequences loader, fixed bugs, and added documentation.
Details:

Removed commented code
Removed debug prints
Linted
Added a reading_defaults argument to get_row_val
Made get_row_val able to read defaults data in addition to the one load file.
Added a reading_defaults argument to check_dataframe_headers.
Make get_column_types into an instance method.
Rearranged how headers and defaults are set to be more based on inheritance so that the setter methods can be overridden.
Renamed get_pretty_default_headers to get_pretty_headers.
implemented private merge methods for headers and defaults in TraceBaseLoader.
Added a get_pretty_default_headers exception class.
Added RequiredColumnValuesWhenNovel and RequiredColumnValueWhenNovel exception classes.
Added an init_loader method to LoadFromTableCommand.
Added a traceback print to load_study.py
Added a call to self.set_headers() inside load_data in the load_protocols.py script.  This fixed a bug.
Added a call to self.init_loader() inside the load_data method in load_compounds.py.  This fixed a bug.
Fixed the example_dir path inside load_animals_and_samples.py.

One of the main strategy changes in this commit was to add a step to load_data: create the loader.  This will happen automatically, but if the developer writing the derived class wants to dynamically change the headers or defaults based on command line options (like add a custom argument to the loader class constructor, with a default, or change the headers when for example, an excel file is supplied (versus a tsv), they can not do it separately from calling load_data, so they can do something between the loader instantiation and the call to load_data, if they want (or if they want to supply different params to load_data than the constructor (which was a requirement before).
The superclass code will also automatically call set_headers or set_defaults in the handle method wrapper, if it sees that those methods have been overloaded in the derived class.  The custom headers or defaults can be set this way dynamically.
Affected Issues/Pull Requests

Partially addresses #824

Review Notes

See comments in-line.
Checklist

This pull request will be merged once the following requirements are met.  The
author and/or reviewers should uncheck any unmet requirements:

Review requirements

Minimum approvals: 1
No changes requested
All blocking issues resolved by reviewers
Specific reviewers: @add_username_here

Review period: 2 days

Associated issue/pull request requirements:

[x] All requirements in affected issues marked "resolved" are satisfied
[x] All required pull requests are merged (or none)

Basic requirements

[x] All linters pass
[x] All tests pass
[x] All conflicts resolved

Overhead requirements

[x] New/changed method tests implemented/updated (or no change)
[x] Updated Unreleased section of changelog.md (or no change)
[x] Migrations created & committed (or no change)

This PR implements a SequenceLoader which is a new concept. I would have liked to see that described in the PR summary, esp. since it wasn't immediately clear how this will be used. I can see there is a proposal to add a sheet for sequences to the Excel workbook and this loader will consume that. In that context, it's looks good.

The sequences loader was covered in the design you reviewed in #753, but to document my summary from slack:

There is also another major change, a "sequence loader" which I don't fully understand how it will be used yet.
Basically, the accucor loader is way too complex, and the LCMS metadata file is composed of lots of repeating data, which would be really ugly if they wanted to add a new LC protocol.  Having a separate loader and sheet for the sequences will both help to break up the accucor code and will make the management of study compilation more manageable.  It's not that I expect researchers to often (or ever) create new protocols, but having defaults for things like instrument, LC Protocol, date, and researcher is not sufficient if they want to include more than 1 run(/sequence) in a single submission.  This just makes it possible to have multiple.  I.e. this strategy can scale, but it doesn't have to.

I am curious if this sequence sheet will be required, and when during the loading process the sequence loader will be called, but I presume that will become clearer as we move forward. Or perhaps I'm just missing something from the design proposal.

The current process (for both the validation interface and the command line interface) is that sequences are created automatically, so there's no reason it should not continue to be that way.  However, one thing the current interface does not handle is the MSRunSequence.notes field.  That field had no good location in the current submission format or loaders.  We accept it in the google form, but the text we currently have is long-form, and there's nowhere to put it other than the yaml file.  There's not a command line option for it.  But the whole point of this series of PRs is to make the interface user-friendly, and to empower the user.  That means putting it in the excel file, as a sheet.  When you look at the sheets available before this refactor, there's nowhere appropriate for the notes to go, and of a study included multiple sequences, there was nowhere for the user to specify that, even in the google form, at least not in an elegant way (especially the notes).
That said, the users are already required to manually enter the protocol, date, researcher, etc, and they do so from radio buttons and select lists (where appropriate).  That mechanism is planned continue in the spreadsheets with drop-downs, and the auto-population can at least determine the number of rows necessary.

The sequences loader was covered in the design you reviewed in #753, but to document my summary from slack:

Sorry I didn't find/recall that before. Sounds reasonable. Just a note, though, having that summary at the top of the PR would have been helpful.
I don't know of a use for the MSSequence notes field, it was probably put in there "just in case".


make tests can fail due to github ratelimiting

Description of problem
make tests, among other things, invokes kata-runtime kata-check, which checks the Kata release using the API at https://api.github.com/kata-containers/runtime/releases.  When doing a bunch of make tests runs while wrigint some new unit tests, I hit this problem.
Expected result
make tests succeeds, and in particular doesn't depend on external network resources to complete the unit tests.
Actual result
make tests failed with this cryptic error:
=== RUN   TestCCCheckCLIFunction
time="2020-10-15T16:04:57+11:00" level=info msg="IOMMUPlatform is disabled by default." arch=amd64 container=1 name=kata-runtime pid=189002 sandbox=99999999-9999-9999-99999999999999999 source=katautils
    assertions.go:239:
        Error Trace:    kata-check_test.go:263
                               kata-check_amd64_test.go:64
        Error:          Received unexpected error:
            failed to unpack release details: json: cannot unmarshal object into Go value of type []map[string]interface {}
    assertions.go:239:
        Error Trace:    kata-check_test.go:272
                               kata-check_amd64_test.go:64
        Error:          Should be true
    assertions.go:239:
        Error Trace:    kata-check_test.go:274
                               kata-check_amd64_test.go:64
        Error:          Should be true
    assertions.go:239:
        Error Trace:    kata-check_test.go:274
                               kata-check_amd64_test.go:64
        Error:          Should be true
    assertions.go:239:
        Error Trace:    kata-check_test.go:274
                               kata-check_amd64_test.go:64
         Error:          Should be true
--- FAIL: TestCCCheckCLIFunction (0.18s)

Manually accessing the API URL at the time showed me a rate limiting error from github.

Thanks for reporting @dgibson. The solution for you is probably to simply set KATA_CHECK_NO_NETWORK to any value to disable the kata-check networking check.
We might want to do that in the CI potentially @GabyCT?

@dgibson is this still relevant?

@ariel-adam well, I haven't hit it again, since I haven't had cause to run so many tests in a short time.  AFAIK it would likely happen again if I were to need to do a bisect on a tests failure.  I now know the workaround @jodh-intel suggests, but that doesn't make it any more obvious to anyone else.

This issue is being automatically closed as Kata Containers 1.x has now reached EOL (End of Life). This means it is no longer being maintained.

Important:
All users should switch to the latest Kata Containers 2.x release to ensure they are using a maintained release that contains the latest security fixes, performance improvements and new features.

This decision was discussed by the @kata-containers/architecture-committee and has been announced via the Kata Containers mailing list:

http://lists.katacontainers.io/pipermail/kata-dev/2020-November/001601.html
http://lists.katacontainers.io/pipermail/kata-dev/2021-April/001843.html
http://lists.katacontainers.io/pipermail/kata-dev/2021-May/001896.html

If you believe this issue still applies to Kata Containers 2.x, please open an issue against the Kata Containers 2.x repository, pointing to this one, providing details to allow us to migrate it.


refactor(actions): separate test and publish workflows

Description
This PR separates test and publish workflows for better readability.

I prefer to keep one workflow.


update the README to use web driver.wait instead of driver.wait which is incorrect

The README is incorrect as the wait method comes from webdriver not driver. This had me confused tonight, so thought it would be best to update it :)

Thanks @alisterscott !