I think this is the same issue as this one: URL The complication there is that a mid-stream error appears as part of the results, _and_ it is also format-dependant.

Unfortunately, the HTTP interface fixes in 24.11+ did not improve the situation in these scenarios.

We are currently discussing internally what could be the best approach there, as there are a few major complications:

- The client needs to somehow parse the error from the response body, as due to HTTP protocol limitations, the exception can only go there if the error occurs after the response headers are sent, as it is not possible to send additional headers during the streaming. The way the error is printed by CH in the body stream is format dependent, e.g., `JSONEachRow` will have an object with an `exception` field, `JSONCompactEachRow` = just an exception as a single element in the array, etc., etc. The most complicated part is streaming into files with formats like `Parquet`.
- There are awkward corner cases like this (if someone has a field named `exception`):

 curl " URL --data-binary "select throwIf(number = 5, 'There was an error in the stream!') AS _, randomPrintableASCII(20) AS exception from system.numbers limit 30000 SETTINGS max_block_size=1 FORMAT JSONEachRow"

 {"_":0,"exception":"&vn]M\"\/B]c=Z1FFF\\u,Z"}
 {"_":0,"exception":"\"y}oIU\/ ~Q47B3hg>928"}
 {"exception": "Code: 395. DB::Exception: There was an error in the stream!: while executing 'FUNCTION throwIf(equals(__table1.number, 5_UInt8) :: 3, 'There was an error in the stream!'_String :: 2) -> throwIf(equals(__table1.number, 5_UInt8), 'There was an error in the stream!'_String) UInt8 : 0'. (FUNCTION_THROW_IF_VALUE_IS_NON_ZERO) (version 24.12.2.29 (official build))"}

Currently, the only reliable way to avoid this is to use the `wait_end_of_query=1` setting, which causes the response to be buffered in memory or temp files on the server side before the streaming starts; in this case, the error will be thrown at the very beginning.

ts
import { createClient } from '@clickhouse/client'

void (async () => {
 const client = createClient()
 try {
 let rowsCount = 0
 const rs = await client.query({
 query: `
 SELECT
 number,
 if(number > 420000, throwIf(1, 'Intentional Error Triggered'), number) AS value
 FROM
 numbers(1000000)
 `,
 format: 'JSONEachRow',
 clickhouse_settings: {
 max_block_size: '1000',
 wait_end_of_query: 1,
 },
 }) // if(greater(__table1.number, 420000_UInt32), throwIf(1_UInt8, 'Intentional Error Triggered'_String), __table1.number) UInt64 : 2'.
 at parseError (/home/serge/work/clickhouse-js/examples/node_modules/packages/client-common/src/error/parse_error.ts:30:12)
 at ClientRequest.onResponse (/home/serge/work/clickhouse-js/examples/node_modules/packages/client-node/src/connection/node_base_connection.ts:474:28)
 at processTicksAndRejections (node:internal/process/task_queues:95:5) {
 code: '395',
 type: 'FUNCTION_THROW_IF_VALUE_IS_NON_ZERO'
}

However, this might not be an option if the result sets are too large.


Thanks for replying @slvrtrn . We don't really need the error to be thrown at the beginning of the query. It might process and return 1B rows before encountering the row with the error. We'd just like the error to be surfaced _if and when_ it happens.

We have huge result sets, and I can't imagine buffering is practical -- not to mention, we really do want results to start flowing as soon as possible, since "time to first byte" is critical for our use case.

I completely understand the factors you mentioned. This isn't trivial. I'm glad you & others are already considering it. Thank you!!


Question about the API. Should Paraglide JS 2.0

1⃣ prefix `locale` suff with "Available"

ts
import { availableLocales, type AvailableLocale, assertAvailableLocale } from "./paraglide/runtime.js"

const locale: AvailableLocale = "en"

if (availableLocales.includes("de")){
 //
}

const x = assertAvailableLocale("fr")

2⃣ or drop the `available` prefix

ts
import { locales, type Locale, assertLocale } from "./paraglide/runtime.js"

const locale: Locale = "en"

if (locales.includes("de")){
 //
}

const x = assertLocale("fr")

Vote with 1⃣ for `available` prefix or 2⃣ for no prefix


If the issue is with the underscore in names, since those are not considered valid, we can update the regex to something like:

`^name:[a-z]{2,3}(-[A-Z][a-z]{3})?((-[a-z]{2,}|x-[a-z]{2,})(-[a-z]{2,})?)?(-([A-Z]{2}|\d{3}))?$` the result looks like 👉 URL


Awesome thanks @nickiles , if you have the custom component installed it should be able to connect to the same address as the client does.


Yes, that looks fine to me. Besides, these are all codes for romanizations and transliterations, which are more appropriate for geocoding than for rendering.


Custom component issue resolved- had missed the need to add the HA Shopping List first. Resolution was to delete the hub and then recreate it.

Brilliant to have it working at last- coffee on its way!


Any word on when this fix will be released? I too have the SizLablrs.ImageSharp nuget package and I'm getting this error. Unfortunately, I can't remove that package.


URL is now merged into the servicing branch for 9. It should go out with the next release (Feb). Assuming you're hitting the same problem the fix is for.


## Progress update

**Jan 12 - Jan 17**

✅ paraglide js 2.0 beta

✅ astro adapter beta

❌ sveltekit adapter beta

✅ metaframework adapter overhaul approach

**Focus in Jan 20 - Jan 24**

- sveltekit adapter beta
- metaframework adapter overhaul implementation

**Targets for end of january**

- [on track] GA paraglide js 2.0
- [on track] GA adapters
- [on track] GA metaframework overhaul

 URL


Had to diable the configuration cache (`gradle-8.12`) as build was failing with the following error. Is this issue still blocked by URL ?

Configuration cache state could not be cached: field `repository` of `org.gradle.api.publish.maven.tasks.PublishToMavenRepository$PublishSpec` bean found in field `value` of `org.gradle.internal.Try$Success` bean found in field `result` of `org.gradle.internal.serialization.Cached$Fixed` bean found in field `spec` of task `:catalog:publishMavenPublicationToMavenCentralRepository` of type `org.gradle.api.publish.maven.tasks.PublishToMavenRepository`: error writing value of type 'org.gradle.api.publish.maven.tasks.PublishToMavenRepository$RepositorySpec$Configured'


I'll add to this that functions appear to do the same thing. `FUN_ ` instead of the external function. This appears to be new to 15.2? I've only noticed it recently.

Apple seems to have dropped some of their shared cache builder code in dyld-1231.3 (which was released with 15.0): URL

A later release, dyld-1235.2, seems to touch a "NewSharedCacheBuilder":
 URL

Not sure if any of this has to do with these potential regressions, but I thought I'd mention it.


@kassasin

I just ran the colab using a colab instance, and can't repro. Does everything train as expected or is JIT hanging for too long?


For a workaround at the moment. I can compile in Debug and Publish, but the Publish hangs. If you watch the folder "/Users/{Username}/Library/Developer/Xcode/Archives" on your Mac. A folder will be created with a date stamp "YYYY-MM-DD" format with an archive file located inside. From there I have to end Visual Studio via Task Manager. Canceling causes issues with the file, perhaps it's trying to roll back. Double clicking the file will open XCode to Validate and/or Distribute the app to the Store. My app is still in TestFlight for the moment so this is workable until this issue can be resolved.


:package: This should now be resolved with hotfix v2.11.2.1.zip (see instructions for applying).
      CRCs: Zip = `F6A3BA15` Exe = `8197E679`

Please let me know how it goes, if you apply the hotfix.


Yes， it has running two days！
I am using 4090 to run this tutorial .


I know I'm not the original reporter, but I too had this issue on 2 recurring meetings and 2 seperate meetings I'd added after moving to the new Aplha.
The fix has resolved the issue for me. The meetings have returned to their correct time.


Ok that's super interesting and also a bummer. I can't repro on 1x RTX 4090. This sounds like it's related to URL Will have to open a bug with the JAX team.

Can you try lowering `num_evals_envs` to something like 32 in the brax PPO call for now?


Hi @villasenor - I'd be happy to make it easy to do a custom component for testing. I'll try to get something out today or tomorrow!


Hi Again @villasenor!

I went ahead and did it

 URL

Added a few more platforms than what the core version has (as I can only do one platform at a time)

This is still missing some functionality and I will try to add it so that you can test it for me!

Namely
- Events when the baby cries
- Turn snoo on
- Turn snoo off
- Set intensity level
- Other various things to enable/disable.

My baby isn't actually born yet, so all my testing has been very limited, so i'm sure you will find bugs.


I can also confirm hotfix resolved this issue. Needed to do a full sync to revert to the correct times.


Thanks so much for putting a HACS repo together so quickly! We use the Snoo a lot and I'm happy to test! I just tried setting it up and got an error - I opened an issue in the repo URL


Sorry about that - oddly enough a file was incorrectly copied over from my dev instance! I just tested on my real instance and it worked, so it should work for you now as well!


That worked! Thanks! Here is what I get for the Snoo when it is stopped, which I assume is expected.

Image


Hello, I still meet this problem.
My ppo_params is:

action_repeat: 1
batch_size: 512
discounting: 0.97
entropy_cost: 0.02
episode_length: 150
learning_rate: 0.001
network_factory:
 policy_hidden_layer_sizes: !!python/tuple
 - 32
 - 32
 - 32
 - 32
 policy_obs_key: state
 value_hidden_layer_sizes: !!python/tuple
 - 256
 - 256
 - 256
 - 256
 - 256
 value_obs_key: state
normalize_observations: true
num_envs: 32
num_evals: 4
num_minibatches: 32
num_timesteps: 20000000
num_updates_per_batch: 8
reward_scaling: 1.0
unroll_length: 10


The issue has been split to Receive (this one, original) and new Send URL


Missing Cardano Send feature is something that has to be handled here. And even if we unblock the ADA send and implemented, it will probably be available only on 2.8.7 FW and not older (since the ADA send flow has been changed in that version). URL


Hello - this is a known issue. running `sudo sof-elk_update.sh` will address it - see URL


Yep! State should update as it runs. You can click on the entity to see everything it can be.

Sticky white noise is white noise without the snoo running

Time left should(?) update as it times out from one level down. i.e. it goes up to level 3 for 480 seconds, the baby is calming down, it will set a timer for 480 seconds and then go down to level 2.


@atykhyy could it be that you do the computation in FP64? Your graphics card has very poor FP64 performance. Switching to FP32 should speed up the computation but has an effect on the convergence of the algorithm and could result into more iterations. You can see the number of iterations and used precision by enabling cuSOLVER logs by setting environment variable `CUSOLVERDN_LOG_MASK=18`.


Awesome! Will we be able to change the Snoo level at some point in the future? (in other words, have you figured out the API spec for that?)


Yes!

I have that figured out in the python library. and I can set the level very easily

The tricky thing is just that I need the current value which gets a bit weird in their event based system as it shares its value with other things - so HA would get confused when the level suddenly changes to 'sticky_white_noise' instead of 'level1'.

They have a 'up_transition' and a 'down_transition' entry in the event and I think I can use those to determine what the current level is reliably. I'll try to add it when i can!


It looks like there's a new target field that might help here.


Thanks! Sorry for the long delay— I just got back from a long break (had exams, was sick for a bit, also been working on a new project for Camoufox). I'll start working on bug fixes this week. 👍

Using `.route()` changes the behavior of network caching in the browser. Resources like JavaScript, CSS files, and images are fetched from the network on every request rather than being loaded into/from the cache. I think this issue happens because of changes introduced in FF133 that cause caching to affect the behavior of iframes (Camoufox is a couple versions ahead of the base Playwright FF release). Unfortunately, Playwright hasn't updated their Firefox fork since November 13th. I'll implement the route solution you provided in the Python library as a temporary fix (Thank you btw!)


Hi guys, I try to replicate the code example and I got into endless loop of verification. Did you encounter the same behavior?


I have an additional problem described here: URL
Even after the full sync, I still get these offset errors.
Also I think the time shift is sometimes still wrong. But have to check that again tomorrow. Will add more information, if it's really still wrong.


Interesting, definitely worth adding as an option. I plan to add settings, so I could probably add such feature there.


Is this behavior if implemented can somehow affect the performance? I know it is hard to say, but I tested and comparing to AeroSpace, I can see FlashSpace changes faster even in the v0.2.3 version (early project development).

Are you relying in different APIs than AeroSpace to the core of its APP? I know it is hard to compare as the tools try to solve different problems (AeroSpace adds window management behavior, but I am not interested in that). I ask that, because I couldn't really find quickly these infos and I am not Swift Developer to understand the code basis in a hurry, I'd need to take a time to onboard, so asking seems easier.


The hotfix corrected the bug for me. Thanks for all your hard work!


This change shouldn't affect the performance.

The performance is the main goal of this project, I started it because Aerospace is too slow and there is no plan to fix it. See more here: #1

Yes, I use native hiding, Aerospace hides apps by hiding them in screen corners, but I think the main issue with Aerospace is that it checks all windows every time you try changing something which is inefficient but probably necessary to implement tiling management. This project doesn't need to care about windows placement so it's easier to make it faster.


Really enjoyed the app UNIX philosophy (not sure if it was intended): do 1 thing and do it the best way possible: Workspaces management. I am not interested in window tiling and I can see how AeroSpace is interested in that, but not my use case. Thanks for the overview. I can't wait this project to grow :-)


Thanks everyone for confirming the fix 👍🏻

As this is a high impact bug, I've quietly patched the ZIP and setup.exe on v2.11.2.0 for new installers; unfortunately upgraders will have to apply the hotfix on this page.

@lemonbutter we'll track your issue over on #1978, as it predates the bug that caused the problem on this issue.


According to this the languages is requesting from taginfo , we may need to run updates in the tiler query every month to retrieve the languages. Since we are currently evaluating the number of objects that have a name:* tag, we might also need to implement a mechanism to automatically request new languages. For now, I am going to close this ticket.


Thanks I'll see if I can add a step for Linux where it changes those file perms.

Did you have to flag anything as executable also? Or just marking them as 755?


I've isolated the issue to this line of code

`rlist, _, _ = select([sock_fd], [], [], 5.0)`

Select starts off detecting some of the received messages, allowing the subsequent calls to `self.recv_fragment()`. However it usually reaches a point where it fails to detect the remaining messages in the socket buffer, and hangs forever.

If I comment out `rlist, _, _ = select([sock_fd], [], [], 5.0)` and `if rlist:`, the previously posted example (`ws_curl_cffi()`) works correctly every time. I'm in no way suggesting this as a solution, it merely demonstrates that all messages are being received.

I've tried replacing select with other event listeners including `select.poll()` and `selectors.DefaultSelector()` (I believe this uses `select.epoll()` on Linux), however the same issues were present.

I also came across `curl_multi_wait` but didn't try it.


Looks like this is due to `from_file` calling `from_dict` with `migrate = true` (o = cls.from_dict(d, href=href, migrate=True, preserve_dict=False)) but the actual default value (which **pystac-client** uses) is `False` (migrate: bool = False,). I thinking defaulting to `True` in `from_dict` _should_ make sense, as migration will become a more-and-more common operation as there is more hetergenous STAC (and STAC extension) versions in the wild. I'll cook up a PR.


We will revisit the ws implementation later, perhaps adding your case to the unit tests, thanks for your experiments.


Looks like a new commit for the latest FF has been pushed on Playwright's repo a few days ago:
 URL

I'll implement it into Camoufox after class and check if this issue still exists.


Hi, thank you for the feedback!

Ad 1. I'm not sure if I understand it correctly. Would you like to have an option in the app to turn on the 3-fingers swipe to change spaces? Or would you like the app to expose some interface so that you can integrate another app that recognizes swipes? In any case, it sounds pretty cool and I'd like to add it.

Ad 2. Another great idea, I will try adding it.

Ad 3. Hmm, I'm not sure about this one. The key point is that I would like to keep the experience that FlashSpace is to help you but doesn't interfere too much with your actions. So if you call some app it appears as expected, as if FlashSpace didn't exist. Regarding auto assignments, I'm worried about ending up like most tiling managers with everything blinking and jumping when a new window appears and gets assigned somewhere, especially small windows :D. However, I understand the point here, I'll think about it.

Thanks for valuable ideas 🍻


For #1 just keyboard shortcuts to cycle spaces is fine and keeps this tool keyboard focused. BetterTouchTool is already great at binding a gesture to a keyboard shortcut so it makes sense to keep those separate.

For #3 I do agree it starts to get into full on window management which does seem out of scope. I think this was just onboarding, after a few hours I am pretty used to how it works already.


**The adapters have been released as beta. Try them out and give feedback.**

- SvelteKit URL
- NextJS URL (look into the next.config.js && src/app/layout.tsx)
- Astro URL

**Target for next week**

- [ ] configurable strategy (i18n routing, cookies, domain based, something else)
- [ ] per locale splitting URL
- [ ] URL

If everything goes well, have the release candidate for paraglide js 2.0 by next Friday 🔥


Hi! I added the features you asked for. I really love both, great suggestions! 🍻

Regarding the cursor warp, I added two modes separately. One is for hotkeys changing focus and one is for hotkeys changing workspaces.


Hello,

I've merged the latest changes from Playwright's upstream patches, and it turned out their commit is still not compatible with FF133+ (turns out they're still patching FF132 release from Oct 21, 2024). However, I found a commit this FF commit made 4 days later that could have caused the regression in how `GetBoxQuads` functions. I will look into a potential workaround, or maybe reverting this commit and seeing if it fixes the issue.


This is an error I am encountering when running `npx next dev` in my Next.js project

node:internal/modules/esm/resolve:303
 return new ERR_PACKAGE_PATH_NOT_EXPORTED(
 ^

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './plugin' is not defined by "exports" in C:\dev\project\node_modules\@inlang\paraglide-next\package.json imported from C:\dev\project\next.config.js
 at exportsNotFound (node:internal/modules/esm/resolve:303:10)
 at packageExportsResolve (node:internal/modules/esm/resolve:650:9)
 at packageResolve (node:internal/modules/esm/resolve:828:14)
 at moduleResolve (node:internal/modules/esm/resolve:918:18)
 at defaultResolve (node:internal/modules/esm/resolve:1148:11)
 at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:528:12)
 at ModuleLoader.resolve (node:internal/modules/esm/loader:497:25)
 at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:231:38)
 at ModuleWrap. (node:internal/modules/esm/module_job:97:39)
 at link (node:internal/modules/esm/module_job:96:36) {
 code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}

Using `"@inlang/paraglide-js": "2.0.0-beta.13"` and `"@inlang/paraglide-next": "1.0.0-beta.2"`. `1.0.0-beta.1` has the same problem, but `0.7.9` works fine


I can find In-page footnotes but not end-of-chapter. I also tried a menu search.


Could there be an option to relegate them to the end of the epub, please? Like treat them as endnotes?


We can't relegate them at the end of the EPUB: they are part of the book rendering flow where they are set, we can't just reorder the pages :) We just can "hide" some parts.
Except in the first case described below, we can't automatically do anything that you wish for :)

But _you_ can mark some continuous set of pages as "hidden flows", so they are skipped when using prev/next page navigation.
This can be done either:

- automatically, if the publisher has set some xhtml file in the .opf with `linear="no"`- #6847 #6809 - you'll have a menu item in the first menu:
Image

- with a style tweak, if you can target the DocFragment or any other block section, you can yourself tag them as being non-linear - see URL
A page break will be forced before and after, and these sections marked as non-linear, and that menu item will appear on next book reload.

- manually on any book, including PDF by enabling in the first menu's `Settings> [x] Custom hidden flows` - see #10982.


Not a problem, looking forward to the updates.

Separately, adding an optional message timeout parameter to the `WebSocket` class would be very useful. When dealing with the `select` bug, it would prevent indefinite hanging. More generally, if a server isn't sending data, I wouldn't want my scripts waiting too long. Let me know if you would like me to create a feature request for this.


Can you try renaming your next config to .mjs? I encountered several esm related issues with nextjs that went away after renaming the config to mjs


It should but on my machine a `next.config.ts` led to module resolution errors.

If you get a `.ts` config to work, make a PR as long as Paraglide JS does not need to be compiled to CJS. Introducing CJS is too much overhead. With the new node feature to import ESM from CJS, the problem might resolve itself.


Hello,

I figured out that reason this issue doesn't happen when using the route solution is because headers aren't being passed to `route.fulfill`.

python
async def handle_route(route):
 response = await route.fetch()
 await route.fulfill(
 body=await response.body(),
 headers=response.headers,
 status=response.status
 )

Specifically, the reason Turnstile passes is due because the `Cross-Origin-Opener-Policy` (or COOP) header is being removed. Seems like Playwright's click function does not support the latest security changes in FF133+.

A workaround for this could be to use this preference which disables COOP from being handled:

python
firefox_user_prefs={
 'browser.tabs.remote.useCrossOriginOpenerPolicy': False,
}

However, this could potentially be detected by anti-bots, though I haven't seen this used in a production environment (all of the Camoufox testing sites still pass). I will consider adding a COOP toggle in the Python library until Playwright bumps to FF133+ 👍


Nice job @daijro ! I have just tested it on the same script without routing and it worked!


As far as I understand, current solution is a workaround where the dashboard is just configured to look for the main.log in specific places (bucket and path key format). It’s not the main.log URI stored as part of the KFP Step.

Should we reopen until we have a more robust solution (like storing the main.log as a step artefact) or we should create another issue to track it as another feature?


Oh right, I have probably forgotten to read release notes or similar. In my next config I had this:

ts
import { paraglide } from "@inlang/paraglide-next/plugin";
// ^ note the ./plugin import, hence the error mentioning "./plugin"

export default paraglide({
 paraglide: {
 project: "./project.inlang",
 outdir: "./paraglide",
 },
 // ...other settings
})

But now I need to change it to

import { withParaglideNext } from "@inlang/paraglide-next";
// ^ removed /plugin, imported the new function

export default withParaglideNext({
 paraglide: {
 project: "./project.inlang",
 outdir: "./paraglide",
 },
 // ...other settings
})

I was also amused to see that there were no other exports from the next adapter package, and seemingly no replacement of ` `, `useRouter`, `middleware` and other stuff inside paraglide-js.

Despite that, it works flawlessly now!!


After poking around a bit more, I found #1503. It looks very likely that was the cause of my problem. It seems that you fine folks have already found and fixed this issue, and I missed it when searching the issues earlier. Sorry to raise a false alarm, and thanks for all your work.


Looking more into this, this appears to be (in some respects) at least two different issues:

1. All of the trampolines in `__objc_stubs` use pointers to selector strings that are all in one big array in virtual memory. These pointers can be resolved by loading that memory into the `Program`, but I think it might be easier to repoint them back to the strings in `__objc_methname`. They don't start until somewhat in the middle of that section (I'm not sure what the indicators are), but otherwise they selector strings and trampolines appear to be in the same order.
2. External symbols and functions are not resolved to names, due to other optimizations.

Issue 1 is the only one I have looked into deeply, although I would not be surprised if Issue 2 is similar.


Acctually, it seems like the default output has changed to `./src/paraglide`, while in my project I used the `./paraglide` path for my output. There is an `--output` option you can run, for example `npx paraglide-js --project my-project.inlang --output ./paraglide`, but I don't see a way to configure the output in the `my-project.inlang/settings.json` file. This means I'll have to run the compiler manually, which is unfortunate


@phanikumv suggested we try this with the nightly image. We can check with Rahul


No worries at all, and thanks for the detailed report. I'm hoping to release the bugfix (and probably an implementation for URL which should also help) early this week.


Hi, I have the same problem. I ran it on Colab and my local RTX4090 and had the same problem. On my local RTX4090, there is one more warning about "Very slow compile".

action_repeat: 1
action_scale: 0.04
ctrl_dt: 0.02
episode_length: 150
reward_config:
 scales:
 box_target: 8.0
 gripper_box: 4.0
 no_floor_collision: 0.25
 robot_target_qpos: 0.3
sim_dt: 0.005

action_repeat: 1
batch_size: 512
discounting: 0.97
entropy_cost: 0.02
episode_length: 150
learning_rate: 0.001
network_factory:
 policy_hidden_layer_sizes: !!python/tuple
 - 32
 - 32
 - 32
 - 32
 policy_obs_key: state
 value_hidden_layer_sizes: !!python/tuple
 - 256
 - 256
 - 256
 - 256
 - 256
 value_obs_key: state
normalize_observations: true
num_envs: 2048
num_evals: 4
num_minibatches: 32
num_timesteps: 20000000
num_updates_per_batch: 8
reward_scaling: 1.0
unroll_length: 10

/home/ /anaconda3/envs/ mjc/lib/python3.13/site-packages/jax/_src/interpreters/xla.py:132: RuntimeWarning: overflow encountered in cast
 return np.asarray(x, dtypes.canonicalize_dtype(x.dtype))
2025-01-27 17:01:38.465476: E external/xla/xla/service/slow_operation_alarm.cc:73]
********************************
[Compiling module jit_generate_eval_unroll] Very slow compile? If you want to file a bug, run with envvar XLA_FLAGS=--xla_dump_to=/tmp/foo and attach the results.
********************************


Not 100% sure, but don't think this is configured in this plugin or in itellij. Check out colorama, I also use structlog (which uses colorama)


I am trying to upgrade to Paraglide V2 with the nextjs adapter but I am currently getting this issue in my middleware.ts file:

[{
 "resource": "/Users/User/code/next-project/middleware.ts",
 "owner": "typescript",
 "code": "2307",
 "severity": 8,
 "message": "Cannot find module './paraglide/adapter' or its corresponding type declarations.",
 "source": "ts",
 "startLineNumber": 2,
 "startColumn": 28,
 "endLineNumber": 2,
 "endColumn": 49,
 "modelVersionId": 106
}]

I am using the same next config and middleware from this example URL

 "scripts": {
 "dev": "next dev --turbopack",
 "build": "paraglide-js compile --project ./project.inlang --outdir ./paraglide && next build",
 "start": "next start",
 "lint": "next lint",
 "postinstall": "paraglide-js compile --project ./project.inlang --outdir ./paraglide",
 "drizzle": "npx drizzle-kit studio --config drizzle.config.ts"
 },

 "devDependencies": {
 "@inlang/paraglide-js": "^2.0.0-beta.13",
 "@inlang/paraglide-next": "^1.0.0-beta.2",

Any help would be greatly appreciated. Thanks!


Tables of interest:
- dag_run:
- dag_version:
- serialized_dag:
- dag_code:

1. Run Cosmos DAG - v X
2. Without changing Cosmos DAG, re-run v X
3. Change Cosmos python code, re-run v Y
4. Change dbt project, re-run, v Z

We need to use a version backend. We need to use the Git Repo

TODO:
- add diagram
- add reference on GitRepo

This is expected to work with local executors only.

This is likely not expected to run using DAG test.


Hi @Elfits and @kassasin , I just tried on my RTX 4090 locally, and I cannot reproduce. I tried multiple environments (PandaRobotiqPushCube, PandaPickCubeOrientation, LeapCubeReorient).

Can y'all give a minimal reproducible example, and ideally open an issue here with the XLA dump: URL using latest JAX version?


Ok never mind! Was able to repro with `PandaRobotiqPushCube`. Will open a bug and post here.


Seems like there is a new issue to this?
I've tried using the exact same setup as you guys, with the new routing, and it doesnt want to click at all.

import asyncio
from camoufox.async_api import AsyncCamoufox

async def handle_route(route):
 response = await route.fetch()
 await route.fulfill(
 body=await response.body(),
 headers=response.headers, # Missing in example
 status=response.status
 )

async def main():
 async with AsyncCamoufox(headless=False, humanize=True, window=(1280, 720)) as browser:
 page = await browser.new_page()
 await page.route("**/*", handle_route)
 await page.goto(' URL
 await page.wait_for_load_state(state="domcontentloaded")
 await page.wait_for_load_state('networkidle')

 await asyncio.sleep(5)
 await page.mouse.click(210, 290)
 await page.wait_for_timeout(30000)
 input('Press enter to close')
 await browser.close()

if __name__ == "__main__":
 asyncio.run(main())


Hi @Elfits that warning has been happening for some time and is mostly benign


Will include this in the request endpoint. Blocked until Jon is done building that.


Partially blocked on this until ART finalizes their models. There's a stack of inflight work that will significantly change their modeling and that makes it difficult to create requests at this time.

In the meantime, we can make a generic endpoint for submission so that the front end has that integration ready to go. we can put in a temporary way to force errors to surface that to users, and we can test the success email.


Thanks for opening an issue. Looking at the code there is a bug in the Extended Case Standoff placement. As you already figured out, the PCB Standoffs are fixed to the PCB hole locations and work as designed. Changing the PCB Standoff Support Size is the way to address the issue you encountered.

The extended case standoffs were originally fixed as well, at 10mm from the corners. When variable standoff sizes(3mm, 2.5mm, etc) were implemented their location was changed to be relative to the Standoff Support Size. This change allowed them to be placed closer to the corner of the case and why they move when you change the support size. I 'll make any corrections that are needed for the Extended Standoff placement and post the fix once completed and tested. It's late evening here now so I anticipate 24 hours time should be sufficient unless I run into some unforeseen problem.

Regarding the Union verse Subtraction, a hole is first created in the case that is slightly smaller then the Standoff Support Size and then the standoff geometry is placed at the same location. This is required so that the type of fastener end( blind, countersunk, recessed, etc) can be accommodated in the case geometry, otherwise they would be covered by the case geometry and not visible.

Regarding contributing your Rock 4c+ model, that would be welcomed and appreciated. Knowing that Radxa doesn't do a very good job with their documentation IMO, I am confused. There is already a Rock 4c+ in SBC Model Framework which I thought was version 1.4. So are these corrections to the existing model, a new model version or something else? If I remember correctly the current model was created based on the STEP model from their Wiki and is unverified(yellow) and may need corrections. Regardless, it would be good to have a verified model of the Radxa 4c+ since I don't own one, so your help in adding or updating the current version would be appreciated. The program sbc_models_viewer.scad within SBC Model Framework can be used to view the current models using a customizer GUI.

Regarding the process, SBC models for SBC Case Builder are added to SBC Model Framework in a separate repository. The technical process to add a model you seemed to have figured out already, add appropriate entries to sbc_models.cfg. For reference, there is information in the README.md for SBC Model Framework that explicitly explains the technical process.

So to add or update a model, start by forking SBC Model Framework, add or modify the SBC model in sbc_models.cfg and then issue a Pull Request. I'll handle the changes necessary for SBC Case Builder and update along with the sub-module linkage to pull the latest version of SBC Model Framework. Once this is done any one that installs either will get the updated models. Those with existing SBCCB installations will need to update SBC Case Builder and it's sub-module SBC Model Framework, as noted in the SBC Case Builder README.md. If it is easier for you, instead of a PR you can open an issue in SBC Model Framework and post your entry from sbc_model.cfg for the Rock 4c+. The only down side with this approach is you wouldn't be shown as a contributor to the project.


@daijro it's giving this error: TypeError: BrowserType.launch() got an unexpected keyword argument 'disable_coop'

I have to pass this instead: firefox_user_prefs = {'browser.tabs.remote.useCrossOriginOpenerPolicy': False}


I think your version is out of date. Try running `pip install -U camoufox` 👍


That's odd, I did python -m camoufox fetch and checked version, but apparently that didnt do the trick. Oh well, it works now.

Now I just have issues with being sent straight back to the same challenge page after clicking #170


Hi.
I just wanted to mention that I am getting an Error while running npm install when using the:
 "@inlang/paraglide-js": "2.0.0-beta.14",
 "@inlang/paraglide-sveltekit": "1.0.0-beta.4",

The Error:
npm error Could not resolve dependency:
npm error peer @inlang/paraglide-js@"^2" from @inlang/paraglide-sveltekit@1.0.0-beta.4

Image


We had also had the UnsatisfiedLinkError when starting rive. Which was caused due to having multiple dependencies which have native libraries

In our case we have both mapbox and rive as a dependency and both try to add libc++_shared.so.
Mapbox uses the ndk23 to compile their native code so libc++_shared.so is not using 16kb page size yet.

We were using:

kotlin
packagingOptions {
 jniLibs.pickFirsts += setOf("**/libc++_shared.so")
}

fix the error

* What went wrong:
Execution failed for task ':android:vriendenloterij:mergeAccDebugNativeLibs'.

 - /Users/user/.gradle/caches/8.12.1/transforms/40386025456db6d0cd93126c8a44ec07/transformed/common-24.9.0/jni/arm64-v8a/libc++_shared.so
 - /Users/user/.gradle/caches/8.12.1/transforms/6f1af6f97dcf0effdcb3e9de2c15ce67/transformed/rive-android-9.13.10/jni/arm64-v8a/libc++_shared.so
 If you are using jniLibs and CMake IMPORTED targets, see
 URL

So it always picks the first .so file which is found so in this case the Mapbox one.

The fix is to ensure all native libraries are compiled with ndk27. For mapbox it was easy since the provide a separate artifact `com.mapbox.maps:android-ndk27`

So would recommend Rive to revert the change the made in 9.13.1 where they update the NDK which seems a breaking change, not perse for Rive but for other native libraries. and if the want to also build a NDK27 version make a separate artifact. To ensure its backwards compatible and once NDK28 is released the artifacts should be reversed with a specific artifact targeting ndk26 or lower. Since 16kb pages will be enabled by default then.


Arghhhhh why are beta releases so broken on NPM? Will fix this today


Ok, I changed the code so as not to interfere with case side wall geometry for any of the standoffs. Don't forget to save your case entry in the sbc_case_builder.json file, if you saved it, otherwise it will be over written when you update SBC Case Builder.

Also let me know if you have any more problems and the answers to my questions above about the Rock4c+ model. If your print is good I'll change the status to verified(green) based on the answer to the model questions. If you haven't found the current Rock 4c+ model in SBC Case Builder take a look at my response to this past closed issue.


New batch of beta's released:

- paraglide js 2.0.0-beta.16
- paraglide next 1.0.0-beta.6
- paraglide astro 1.0.0-beta.4
- paraglide sveltekit 1.0.0-beta.5

The new beta's have the #346 API:

diff
strategy: ["pathname", "cookie", "baseLocale"]

Please try it out and give feedback. If you encounter issues, please open separate issues to keep this thread clean with updates on the beta.

**Next steps**

- try top level await approach in #88
- prepare release candidate (docs)


HLO reproducer: URL

bazel run --config=cuda //xla/tools:run_hlo_module -c opt -- --xla_disable_all_hlo_passes --input_format=hlo --random_init_input_literals --platform=CUDA /opt/repro.hlo

I'll take a look which pass is blowing up. Hopefully it's not in LLVM :-).


The quick hack did not work. I'll try to migrate us to the indexing maps next week.


Maybe this is helpful. It would be nice to have something baked in but this `Sync-ModulePreferences`. It solves the original issue and is pretty flexible. No way that I know of to automatically grab the full list of preference variables but hard coded works. You could even pass `Sync-ModulePreferences *` if you wanted to cover all loaded modules but like others, I'm a bit skittish going that far.

powershell
function Sync-ModulePreferences {
 [CmdletBinding(DefaultParameterSetName='Names')]
 param(
 [Parameter(Mandatory,ValueFromPipeline,ParameterSetName='Names')]
 [ValidateNotNullOrEmpty()]
 [string[]] $ModuleName,

 [Parameter(Mandatory,ValueFromPipeline,ParameterSetName='Objects')]
 [System.Management.Automation.PSModuleInfo[]] $ModuleObject,

 [Parameter(HelpMessage='Subset of preferences to sync')]
 [string[]] $Include,

 [Parameter(HelpMessage='Subset of preferences to exclude from sync')]
 [string[]] $Exclude,

 [ValidateNotNull()]
 [System.Management.Automation.SessionState] $SessionState = $ExecutionContext.SessionState
 )

 $Preferences = @(
 'ConfirmPreference', 'DebugPreference', 'ErrorActionPreference'
 'ErrorView', 'FormatEnumerationLimit', 'InformationPreference'
 'Log*Event', 'MaximumHistoryCount', 'OFS'
 'OutputEncoding', 'ProgressPreference', 'PSDefaultParameterValues'
 'PSEmailServer', 'PSModuleAutoloadingPreference', 'PSNativeCommandArgumentPassing'
 'PSSessionApplicationName', 'PSSessionConfigurationName', 'PSSessionOption'
 'PSStyle', 'Transcript', 'VerbosePreference'
 'WarningPreference', 'WhatIfPreference', 'PSNativeCommandUseErrorActionPreference'
 ) |
 Where-Object {
 $IsIncluded = if ($Include) { $_ -in $Include } else { $True }
 $IsExcluded = if ($Exclude) { $_ -in $Exclude } else { $False }
 $IsIncluded -and -not $IsExcluded
 }

 $Preferences

 $Modules = if ($PSCmdlet.ParameterSetName -eq 'Names') { Get-Module $ModuleName } else { $ModuleObject }

 foreach($Module in $Modules) {
 Write-Verbose "Updating Module '$Module'"
 foreach ($Preference in $Preferences) {
 $CallerValue = $SessionState.PSVariable.GetValue($Preference)
 $ModuleValue = $Module.SessionState.PSVariable.GetValue($Preference)

 if ($CallerValue -is [Hashtable]) {
 foreach ($CallPair in $CallerValue.GetEnumerator()) {
 $ModPairValue = if ($ModuleValue.($CallPair.Name)) { $ModuleValue.($CallPair.Name) }

 if ($CallPair.Value -ne $ModPairValue) {
 Write-Verbose "Updating Preference '$Preference.$($CallPair.Name)' from '$ModPairValue' to '$($CallPair.Value)'"
 $ModuleValue[$CallPair.Name] = $CallPair.Value
 }
 }
 } elseif ($CallerValue -ne $ModuleValue) {
 Write-Verbose "Updating Preference '$Preference' from '$ModuleValue' to '$CallerValue'"
 $Module.SessionState.PSVariable.Set($Preference, $CallerValue)
 }
 }
 }
}

# Define an in-memory module with a single function Foo() that provokes
# a non-terminating error.
$Mod = New-Module {
 function Foo {
 [CmdletBinding()] param()
 Write-Host "NoNewLine"

 # Provoke a non-terminating error.
 Get-Item /Nosuch

 Write-Verbose "Foo"
 }
}

$ErrorActionPreference = 'SilentlyContinue'
$VerbosePreference = 'Continue'
$PSDefaultParameterValues.Add('Write-Host:NoNewLine', $True)

Sync-ModulePreferences `
 -Verbose `
 -ModuleObject $Mod `
 -Include @('ErrorActionPreference', 'VerbosePreference', 'PSDefaultParameterValues', 'ConfirmPreference') `
 -Exclude ('ConfirmPreference')

Foo

## Update modules on import
# Import-Module Pester -PassThru | Sync-ModulePreferences

## Example Output
#VERBOSE: Updating Module 'Pester'
#VERBOSE: Updating Preference 'ErrorActionPreference' from 'Continue' to 'SilentlyContinue'
#VERBOSE: Updating Preference 'PSDefaultParameterValues.Write-Host:NoNewLine' from '' to 'True'
#VERBOSE: Updating Preference 'VerbosePreference' from 'SilentlyContinue' to 'Continue'


Thanks @jreiffers and @pifon2a for taking a look, really appreciate it!


I am getting this too with .NET 8.0 on IOS when using VS 17.13 preview 4.0. Rollbacking to preview 1.0 fixes it.

Will the fix in .net 9.0 will apply to .net 8.0 as well?

-Mat


@ryanmkurtz I've been doing a bit of digging into this on my own and I think I found a bug that might be the root cause of this (or at least part of it).

1. The `SymbolTableCommand` represents a load command in a Mach-O that points to the _file offset_ of the symbol table and the symbol strings.
2. Given that these are file offsets, it wouldn't make sense for them to be negative.
3. However, when playing around with the parsing code, I found that, in some cases, the `symoff` and `stroff` will be negative values.

I'm honestly not sure why that doesn't make it crash, but it does seem to end up with a symbol table that has the right number of symbols (`nsyms` is never big enough to be misinterpreted), but they are all the empty string.

In Kotlin, I can re-parse the symbols like so, and get proper symbol strings:

kotlin
val (symbolsFileOffset, stringsFileOffset) =
 symbolTableCommand.let {
 Pair(
 it.symbolOffset.toUInt(),
 it.stringTableOffset.toUInt(),
 )
 }
var symbolTable = mutableListOf ()
for (i in 0 until symbolTableCommand.numberOfSymbols) {
 val nList = NList(readerForSymbolTable, machHeader.is32bit)
 nList.initString(readerForSymbolTable, symbolsFileOffset.toLong())
 symbolTable += nList
}

I don't think Java has `.toUInt()`, but I think if you change

java
 symoff = loadCommandReader.readNextInt();
 nsyms = loadCommandReader.readNextInt();
 stroff = loadCommandReader.readNextInt();
 strsize = loadCommandReader.readNextInt();

to

java
 symoff = loadCommandReader.readNextUnsignedInt();
 nsyms = loadCommandReader.readNextInt();
 stroff = loadCommandReader.readNextUnsignedInt();
 strsize = loadCommandReader.readNextInt();

it might solve things.

Honestly, they could all be interpreted as unsigned integers, as I don't think any of them would ever be negative.


In the paraglide sveltekit beta, it seems that the logic to replace `%lang%` with the current language in the `app.html` template is gone.

This logic : URL


Many thanks for the incredible fast reply and fix! Just saw it on my mobile. I will test tomorrow ;-) In regard to adding the 4c+ v1.4 model I will give it a try as you described. I will also check the .step file they provided. The major difference though was a few mm here and there plus the stacked USB ports being on the wrong side. Stay tuned ;-) Thanks again!


Also I can't find the way to translate pathnames in the paraglide sveltekit beta?


Our telemetry indicates **high** amount of _hanging_ `Office.context.mailbox.item.saveAsync` requests.

Internally we **Timeout** and Cancel them after **30 seconds**, but this API is a crucial peace of our UX, and we wish we could see less of such hanging calls.

Similar situation is with the following APIs:

**`Office.CustomProperties.saveAsync`
`Office.context.mailbox.item.loadCustomPropertiesAsync`
`Office.context.mailbox.item.to.getAsync`
`Office.context.mailbox.item.cc.getAsync`
`Office.context.mailbox.item.bcc.getAsync`**

It comes together with the

"Error: [Office API error] name: Internal Error, code: 5001, message: An internal error has occurred., diagnostics: undefined"

and

"Error: [Office API error] name: GenericResponseError, code: 9020, message: An internal error has occurred., diagnostics: undefined"

errors codes.


Thank you @victorcalarasu for reporting this.
While we check this from our end, could you please share the logs by following the process: URL and give the access to exextoc?


I'm concerned at the amount of extra steps someone has to go through just to host the ui extension for harvester in an airgap.

It was something that was built-in and worked in an airgap now has unannounced dependencies like hosting the chart internally and creating a manual Extension resource to point at it.

Whatever solution is chosen, can we possibly tie it into existing airgap-friendly flags that Rancher's helmchart already makes use of? `useSystemBundledCharts` is a good example. Adding extra steps to host a chart breaks a lot of airgapping processes and will require not-insignificant engineering hours that the customer has to spend to fix it.

I think its best to follow this:
1. Harvester cluster
2. Rancher
3. Private registry hosting rancher images
4. UI extension charts hosted internally by Rancher just like other charts


@patilganesh-msft Thank you for your response, I will ask for permissions to share the logs with exextoc.
Please keep me posted if you find anything in the meantime.


+3 to @bcdurden comments about implementing an automated fix using existing components of the helm chart like `useSystemBundledCharts=true`


@patilganesh-msft I've added exextoc to my private repository containing some logs. Let me know if I can help in any other way.


Do you guys think it would make sense if it just brought in `libobjc.dylib` by default? I could have a load option to have it not do that but it seems like you would always want it since there is so much objc stuff everywhere.


I wouldn't be against this. It's what I'm playing around with in GhidraApple already. Especially for cached dylibs and their `__objc_*list` sections, those often reference `libobjc`. And given that the Objective-C 2 Class analyzer doesn't have a "soft fail" path (as we discussed in #7361), not including `libobjc` would lead to Class analysis failing for a lot of cached dylibs.


**Progress on customizable localized pathnames #359 **

 URL

API will enable you to match any localized route of your choice. The example below prefixes every path with the locales, even for en. The syntax is uses the web standard URLPattern URL

ts
pathnames: {
 "/:path*": {
 en: "/en/:path",
 de: "/de/:path",
 },
},

This pattern will not prefix the locale for en

ts
pathnames: {
 "/:path*": {
 en: "/:path",
 de: "/de/:path",
 },
},

Or go fully custom

ts
pathnames: {
 "/blog/:id": {
 en: "/english/blog/:id",
 de: "/deutsch/artikel/:id",
 },
},


Any updates regarding this topic? it's a bit important for us


#14961 added a test, pointing out how `cargo install --path foo.rs` behaviors (errors). I've added support for this as an open question. I lean towards supporting it as it seems relatively innocuous and our overall goal is "behaves like a regular package" with cases like workspace membership, packaging support, etc being explicitly deferred out.

@Rustin170506 since you were just dealing with that stuff, would be interested in your thoughts and if you want to pick that work up.


Now that the submission endpoint is done I can continue working on the data model for the email and can put the code that calls it in that new endpoint. That calling code will probably be moved elsewhere eventually.


Another failure was detected on this sample with the 9.0.2 service release (due in February). An additional fix was required URL which will be included in 9.0.3 release (due in March from my understanding). Sorry about the delay.

@BleuBleu A fix for these AOT compilation issues was introduced on .NET9 and these subsequent fixes expand on that work so they are only relevant for .NET9. There is nothing planned for .NET8.


Calling out the work related to this, in case we need to reconsider any other approaches once the ARF models are finalized:
1. #99802
2. #99804
3. #99973
4. #99803
5. #101322


Hi, can you have a look at #487, is this the same kind of issue?


Gonna go with a bundled version of path-to-regex for #359.

I won't work tomorrow and Thursday on Paraglide 2.0 as I am attending a conference. A release candidate at the end of the week is thereby unlikely but a new beta with the pathname API on Friday is likely.

 URL


Hey, I don't think so, my script doesn't really have points where `recv()` hangs and I'm utilising `Websocket.run_forever()` (I could try to see what happens when I use Websocket.recv() in a for loop to see if it's the same issue). I've traced it back to `Curl.ws_recv()` in `curl.py` where it chunks data up into 1024 bytes and collates them, but I can't see anything that is restricting the whole message. It just seems to gather the first 8192 bytes (which would be 8 iterations of `Curl.ws_recv()`), waits a while then sends the rest of the same message.
Fortunately this only happens at the start of my script, I can send some of it but it's a UK site and I'm not sure if it has location blocking.


Hi, this has fixed the problem when viewing items in the calendar that are synced from google cal to outlook cal.
The entries are now at the correct time - so amazing and Thankyou!

But there may still bepart of the bug not fixed - ie. in the csv's produced and in the OGCS sync verbose output, the timestamp on the text displayed/logged is still incorrect.
It seems to be not respecting the timezone offset - eg. in the outlook_create.csv, the "starttime" and "Endtime" shows eg. "5/02/2025 6:50:00 AM +00:00" which maybe in my example should really likely read as something like "5/02/2025 6:50:00 AM +08:00"?
And the sync log shows "And the OGCS app sync log tab (with verbose logging ticked) shows "5/02/2025 6:50:00 AM " but should show "5/02/2025 2:50:00 PM ".


The data object that takes the PDF/digital form submission and extracts the info used in the email template is done. I need to write some tests for it and it'll be ready to go.


Hello,

A fix for this issue has been added in v135.0-beta.21 (without having to disable COOP).

Camoufox won't have any issues interacting with cross origin iframes anymore. 👍


Hello,

A fix for this issue has been added in v135.0-beta.21 👍


@tomball: Good to see that J2ObjC now builds with JDK 17 👍 I'll try it soon and update #2095 and the Requirements section of the root-level README file if it works.


Looking into this a bit further, what I've found is that if another, separate message comes through then the end of the last message is attached to the start of the new message, it comes through quicker but can be a bit irritating separating it all and making sure I have full messages


At least for us it is not a concern. Albeit it is always nice to have a sample.


FYI, I'm still working on support for switch expressions. With the Java 21
added support for patterns, the ASTs javac returns are different between
Java 17 and 21.

On Thu, Feb 6, 2025 at 1:27 AM Adil Hussain ***@***.***>
wrote:


Having the same problem here in the Netherlands (time zone Amsterdam; UTC +1). **Not only new Google meetings are shifted one hour back in Outlook, but also excisting ones!!**

Checked time zones in Outlook and Google, also the time zone mapping in OGCS. They all use UTC +1. No alterations made in the systems timezone settings.

Can't retrieve the date I upgraded to 2.11.2.0.

Pls, pls, pls advice! Happy OGCS user for years!

OGcalsync.log


@joedotbloggs You are indeed correct and I had already coded a fix, but just not built a hotfix for it as no one had spotted it yet!

:package: If you would like to confirm hotfix v2.11.2.6.zip does indeed resolve it, it would appreciated though (see instructions for applying).
      CRCs: Zip = `7BFFA637` Exe = `6A844883`


Hello, getting this behaviour as well - any ideas on what might be causing this or any fix or workaround that could facilitate the current situation..?


This hotfix (2.11.2.6) works - fixes both the CSV's and the Verbose Log!
Thank you :)


another data point, I am experiencing the same issue when running `PandaRobotiqPushCube ` with RTX 4090.


Dear Paul @phw198 , thank you very much! It runs like clockwork again! 👍 #veryhappy


Thanks a lot…

Jean-Michel LÉVÊQUE

14 rue des Caves Basses

34210 CESSERAS

*06 45 52 06 47

***@***.*** ***@***.***>

De : Paul Woolcock ***@***.***>
Envoyé : jeudi 6 février 2025 19:14
À : phw198/OutlookGoogleCalendarSync ***@***.***>
Cc : Beth-Salem ***@***.***>; Author ***@***.***>
Objet : Re: [phw198/OutlookGoogleCalendarSync] Time zone problem (Issue #2065)

Duplicate of #2047 >


Hi @victorcalarasu

Thank you for providing the logs.
I can see repeated POST requests to " URL
".
This endpoint if for Telemetry collection.
NO_AUTH also suggests that requests are unauthenticated.
Is the add-in explicitly sending excessive analytics data using Office.js APIs? You may re-try disabling them.


Just looking at this again. Dan, are you suggesting that if we made this change:

ctx = Domain

to:

ctx = Domain || Hash(PublicKey1 || PublicKey2)

We should allow re-use of the ML-DSA key (or any other context-supporting algorithm) in some other context?

An attacker could still construct the above ctx and pass that to a regular ML-DSA verifier (with context) and get the stripped signature validated. We recently added a prefix to mitigate this issue in traditional verifiers, #86 but I suppose it could be used by a pure ML-DSA verifier to determine if it is coming from a composite. Then a setting whether a composite validation is being attempted or not would be needed.


Thank you for your response @exextoc !
Regarding the sending of excessive analytics, aren't these automatic diagnostic events? From the best of my knowledge, we don't do this manually. How do I disable them?

This still makes me wonder about this: Why did our code, between the 30th/31st of January stop working so suddenly? And why is it working fine through the Task Pane or if we save the draft manually?


Did that adapter ever work? or it's something new after you changed something?


I’ve had the adapter since ‘23 and I’ve always had this issue with every firmware I’ve used


Not necessary to include this CI flow in v1.5.0. Update milestone to v1.6.0.


Could the release on the 30th of January impact this in any way? ( URL


How did you import SafariCore? Was that extracted from the cache or does it reside on your system somewhere?


We extracted it from the cache using blacktop's ipsw with the following
command line: ipsw dyld extract -a --objc --stubs
The slide option wasn't working for 24D60.

On ma 10-2-2025 13:56, Ryan Kurtz wrote:


Ok. I'll say up front that Ghidra may not play nicely with dylb's extracted from other tools. Ghidra can also extract...did you try that?


Haven't tried that yet, going to now. Thanks for getting back to me so
quickly.

On ma 10-2-2025 14:13, Ryan Kurtz wrote:


@opticbob confirming I've removed the times from the email template:

Image


Having the same issue here... Saving the item from a side panel works fine but saving the item from the OnSend event causes the same issue. Error: 9021

And like @victorcalarasu said, our code was working fine earlier but it stopped working around the 30/31 of January.

Any work arounds?


@kevin-mark-rn Thank you for using the plugin! You can configure log colors as written here.


We are facing exactly the same issue. It's quite concerning because this is not the first time we are encountering problems of this kind. It used to work, but suddenly, from one day to the next, nothing works anymore. I understand that there is a big system behind it, but are you able to guarantee stability for your product to your clients?

Without wanting to sound accusatory, are you ready to welcome millions of users, or are you still in a testing phase?


I spoke to @jedcunningham, and he suggested we try out the alpha, since this has been released since we first wrote this ticket - it would make our lives easier. He'll share the info with us


Ok I just tried Smash on my Everdrive and I don't have this issue.

Do you some kind of HDMI mod with a OSD? Those are known to create inteference with BlueRetro.


This is still in team review. Platform has reminded me that they can't review it until it's been team reviewed.


I'm using MAUI on .NET 9 with ImageSharp as well, and @electro-logic workaround worked for me.

While MtouchInterpreter -all didn't.


Need re-prioritize to include this CI flow in v1.5.0 or not.


@a110605 We need every item that can ease the extension deployment for our users.
What's the drawback if this issue is not implemented?


It does work, but makes the app very very slow.
It's already slow with Maui but with the interpréter it's horrible.


Hey @victorcalarasu , thanks for reporting this issue- we are able to reproduce the same. We have tracked this item in our backlog. However, we have no timelines to share at this point.

@dmitriikashin-outreach - We have only tracked the issue with `item.saveAsync` failing. The issue with the latency with these and other APIs seem to be a different issue- it would be great if you could open a different Github issue for the same, with some telemetry numbers that you observe and other details you think would help.

Internal Tracking ID: 5372914


@softlion true. I read that this option should still perform aot for everything it can, and fallback to interpreter mode. But my build used to take 20+ minutes and now it finishes in 5 mins. So I guess no aot is taking place.


hello @mobisw-msft , thank you for you response.
This issue has a huge impact on us and we would greatly appreciate if you could prioritize this issue.
Please keep me posted about its status and when it is fixed.


I've had a quick look at this and it seems that it's not so much work to get this working with pcre2. I'll likely send a pull request in the next few days.


Hello, I'm closing this one, this is now tagged with a label and also present in the wiki:
 URL

Thanks you


I concur with @victorcalarasu , this issue is impacting around 2000 of our users.
Please keep us updated. Thank you


First pr is in review. It will need ART and Platform approval to merge


Also forgot mentioning, but this warning was not there until a week ago.


Well, it seems to be working as expected. If you bring in `libobjc.dylib` before starting any analysis, it won't complain about the missing string at `0x7ff81f6fd197`.


@mobisw-msft We are also getting issues with `saveAsync` method in `onSend` function. In our case, we are not getting any error but the current message is not getting saved. As per description,) this method should saves the current message as a draft. But nothing is saved. However, calling it via EBA or taskpane is working properly. We also changed nothing in our codebase. It was working fine previously.


I am going to play with bringing in `libobjc.dylib` by default, along with some other pieces that seem essential for proper analysis.


Also forgot to mention, but like @gauravsoni119 said, when saving from a taskpane it works properly. Its only from the ItemSent event that the issue is present.


The PR for this is team and Platform reviewed and ready to merge. I haven't merged it yet because I can't figure out how to add the staging template id to the vsp-infra-application-manifests repo. The staging file I added to last time no longer contains those values and I can't find it in the repo. I confirmed that the email is still sending just fine from staging.

I've asked the VA Notify team for assistance, details on slack.


## On issue 3:
I personally think that we should strive to converge and use the same standard. I think that the standard from point 3 is the closest we've gotten so far. It is used in several places now:
 - Fiona: Global Antimicrobial Resistance, IGME, ...
 - Veronika: Country Activity Tracker: Artificial Intelligence, WHO Mortality Database - Cancer Deaths, ...
 - Pablo Arriagada: Global Multidimensional Poverty index, ...
 - Lucas: UN WPP, UCDP, ...
 - Mojmir: Global Health Observatory - World Health Organization, ...

However, it is not error-free. One issue it has is that sometimes there might be collisions since `__` (double underscore) is used to replace special characters! See the indicator URI of this example.

### Possible solution
We could leverage the information stored in `tb.['column_name'].metadata.additional_info["dimensions"]`, which contains the dimension information. This would prevent us from (i) accessing DB, and (ii) assuming any specific column naming.

py

{'originalShortName': 'trend',
 'originalName': 'Trend - Place: Grocery and pharmacy',
 'filters': [{'name': 'place', 'value': 'Grocery and pharmacy'}]}

One thing that we will need to solve is for those steps where long-format is not used. My guess is that this information on dimensions is not generated, since there is no place to look for it. In such cases, we should have some functions to manually add this information.


oh thanks I didn't know that is what configured them, thanks! Love the plugin


### URL based localization (pathname, domain based, multi-tenancy) likely nailed!

I spent over 1 week on coming up with this API, and I think it nails any URL-based use case. Will make a decision tomorrow on whether to use URLPattern or path-to-regexp v8, which depends on URL

- one API to rule any url based needs
- not >10 flags are different APIs that interfere in behavior (!)

**Next steps**

- [ ] determine if path-to-regexp v8 can work with a `baseLocale` setting per pattern to combat ambiguous matches
- [ ] else, try adoption of URLPattern

 URL


Any update on this?
Since ASC will be retired for SharePoint we'll have to use an Entra App Registration.
But that still doesn't seem to work...


Hello @mobisw-msft , This issue is highly impactful for us as well, and we would greatly appreciate it if you could prioritize its resolution. It's impacting thousands of users using our add-in and is critical.


## On issue 1
Martin shared a workaround for the time being. It consists on "hacking" the config fields for each view, so that they contain information on all the indicators present.

For this, we need to figure out how this combination should play out. I'd say, we have to implement some custom function that does this. Eventually, this is will no longer be needed because the MDIM page design will allow for multiple indicators shown.


Hi @lucasrodes, thanks for this summary!
I'd say issues 1 and 2 should possibly be moved to `owid-grapher`. Or is there anything that can be done from the ETL side?

Regarding issue 3, as far as I know, we have never established a standard for naming indicators. However, I agree that over the years, certain ad-hoc criteria have emerged.

Your suggestion is fine, but we have at least two problems:
* As you pointed out, our `underscore` method creates `__` to replace punctuation (e.g. `,`, or `)`). This is unfortunate (and I remember I suggested long ago that we should avoid it). So this means we can't have a robust way to distinguish dimension using simply double underscores.
* With this format, it's not particularly easy to visually discern the dimensions from the name (especially due to the previous problem). This is not a technical problem, but it would be more convenient to have short names that are easy for us to visually parse.

Maybe we could consider other possibilities, e.g.:
`indicator||dimension1Name|dimension1Value||dimension2Name|dimension2Value||...`
This is similar to what I've used for FAOSTAT. I think the pipes `|` help distinguish dimensions visually. And this would not depend on whether we use single or double underscores.

Ideally, we would change our `underscore` function to use only `_`, but this would probably require a big refactor, which may not be worth it.

We can discuss it on our next call. But whatever we decide, I think adapting our function `generate_views_for_dimensions ` would be easy.


Thanks for weighing in, @pabloarosado !

I agree that points 1 and 2 are suitable for `owid-grapher`. Still, I think is good that we discuss them here, and find some shorter-term solution for us. I'll add a clarification to the issue description.

An example is for point 1, I will start implementing some function to "hack" the config of the view to fit in all different metadata fields from indicators present in that view. This is not intended as a final solution, but my impression is that point 1 can be long before resolved (involves design and engineering work).

My suggestion is mostly motivated by trying to reduce the maintenance burden. I am not particularly attached to the status quo, but I think it is the best that we have at the moment. I don't particularly like your approach in having indicators named `indicator_dimension1Value_dimension2Value_...`, I think that is more susceptible to collisions, and it is also hard to distinguish indicator names from dimension values/names.

Now, I totally agree that that using `__` comes with its own perks. It is also true that several parts of our tooling (e.g. long-to-wide format change functions) are based on this current naming. So, even if it has perks, it has become the closest thing we have to a standard. I think that if we all follow this criterion, even if suboptimal, it can make our lives easier (e.g., tooling maintenance). An example is your recent function `multidim.generate_views_for_dimensions`, which is a great resource but unsuitable for most of us. Instead, `multidim.expand_views` was suitable for most of us (even if accessing the DB, which I agree we shouldn't)

Having said all of this, again, I am very open to revisiting how the URIs are created for multidimensional indicators. I actually think we should use something else in the long term. I am unsure how these would affect existing charts, etc., so we should pay attention when doing that.

As per format examples, I personally would go with something easier to understand and closer to common standards (e.g. in query URLs):

indicator_dimension1Name=dimension1Value_dimension2Name=dimension2Value

or

indicator&dimension1Name=dimension1Value&dimension2Name=dimension2Value

For that, I'd ban symbols like `=` and `&` from our indicator names (e.g., have a check in the pipeline to prevent their usage).


On issue 1, one possible solution from the ETL side would be to warn the user when a view uses multiple indicators, to ensure a combined metadata is used (unclear exactly how and whether this could be come annoying).


FWIW, I am currently working on solutions for points 1 and 3.

1: Interim methods to combine metadata in views with multiple indicators
3: update `expand_views` to use only ETL files, and exploit the internally stored information on dimensions.


On issue 2, looking at this mdim page, I see your point, but I'm wondering if this is a common scenario, or whether this dropdown is showing two different indicators, and hence they should not be in the same mdim page (they have different entities). This may need some discussion.


@pabloarosado yup, it's an edge case. I can see this totally being an issue though. In this case, the two indicators are a bit different, but imagine the following example:

- You plot an indicator in absolute and relative terms.
- For absolute terms, you have values for regions. But for relative numbers you don't.
- You want to show data for continents (or world) as default for absolute. In relative, you can't so you want to choose a set of countries / make map the default, etc.

I see how you could try to choose default entities in both; but still, I think there could be instances (few ones) where there could be none.


Mmh... I think it can be valuable to start drafting something. Otherwise I find it hard to tackle this problem. We can improve later on.


Hey @lucasrodes, a few comments:
1) In the energy prices multidim page I show a view with multiple indicators, and the way I handled that special case was quite manual and suboptimal. It would be great to figure out some generic function to combine metadata. I'm wondering what the default behaviour should be. For example, what should we do with key description points, combine them all, remove them all...?

2) On the default entities, we also need to keep in mind user experience. If someone selects certain entities, it's odd if that choice is not respected. But I understand that, in some cases, it may be the best strategy. This may need further discussion (and it's more on the grapher or design side of things).

3) Regarding the criterion for flattened short names, I think the (not ideal, but) least painful solution would be indeed what you proposed, which is to separate dimensions with `__`. There will be oddities, but hopefully it won't cause many headaches. We need to also keep in mind that these names should be URL-friendly, in case we want to surface them anywhere. So having pipes or other symbols could be problematic too. Feel free to change the function I created for this purpose (I designed it with only my current case in mind, so I'm happy to generalize it with a specific criterion). I'm happy to adapt the `energy_prices` step if needed, to adhere to this criterion.


1: description_key is a tricky one, unclear to me. I haven't yet started tackling it (I am looking at point 3), feel free to start drafting if you feel like. Otherwise i'll tackle it later.
2: Agree, it can be confusing for end-user.
3: I'm working on a solution to exploit the information from `tb.['column_name'].metadata.additional_info["dimensions"]`. I think that's the most robust solution. I'll ping you when I have that ready so you can try it out.


Wow. This is a P0; not being able to send message or last information added to an email because save operation failed blocks all users from all operations and even a data leak risk. Can you ensure @exextoc and @mobisw-msft that this get's te highest prio, or let us know where to escalate to management, because all customers for all add-ins in the world being affected should be fixed within hours, not 13 days later still open....!


Feel free to break this tracking issue into smaller pieces as needed.

Regarding the URL format for short names, I think they should meet two conditions:
(i) They should be directly usable in a URL without requiring encoding (i.e., avoiding characters that need to be escaped).
(ii) They should not conflict with standard URL behaviors. For example, using `&` in an indicator short name could cause issues when navigating pages. These choices should be aligned with Grapher's logic to avoid unintended behavior. A safer approach would be to restrict short names to symbols that don't have special meanings in URLs.

Our current `underscore` method fulfils these criteria (with the unfortunate downside of arbitrary use of single and double underscores). I hope that makes sense!


I see; mmh.

Are you thinking of cases like

url/?indicator=...¶m1=...¶m2=...

where having `&` and `=` in the value for `indicator` would conflict with other bits of the query in the url? I guess I am not sure this use case actually occurs at the moment. But I see your point.

Having said all of this, I am now thinking that maybe we don't really need to do anything at all here. Identifying the dimensions from the column names is not great, and we should instead use `tb.['column_name'].metadata.additional_info["dimensions"]` as I mentioned above. As long as that field is present, we don't really care about the column name


If the attacker can control the context used by a signer or verifier then the context parameter has no value and we shouldn't use it anywhere. Wherever a signature context is used, it should be a value entirely controlled by the signer or a protocol-specific value.

The extra context data doesn't have to be derived from the public key, it just has to be something unique to the composite keypair. It could even be some random bytes that is encoded into the composite private and public key formats so both signer and verifier have the same value. The important thing is that it is unique to a single composite keypair.

I am asking:
- Do you think, despite key reuse being forbidden, people will try to do it? I think that fact that draft-hu-ipsecme-pqt-hybrid-auth/ already exists suggests yes.
- If we think people will try to do key reuse, should this draft try to protect them as best it can, despite having told them not to do it?
- Alternately, if we have a way to do composites in a way that allows key reuse, should we?

My idea above would not protect ECDSA/RSA from key reuse, but this comment from a different issue is interesting: URL but was never addressed. It claims to give strong non-separability, although if the component keys were mixed and matched into different composites I think you could still get some separability-adjacent issues. If you took that idea and used a unique context per pair of composite keys (public key hashes, or random bytes encoded in the private and public key) then I think you could fix the mix-and-match problem.


Can you please include the phone model you are seeing this problem on? This is probably a device specific problem, and sounds similar to :

 URL
 URL
 URL


@exextoc and @mobisw-msft ?! The lack of communication is also concerning tbh, as you guys push the new outlook as default now, these things CANNOT break / should be fixed ASAP!


Absolutely, `additional_info["dimensions"]` should contain everything we need. De-constructing underscored names would be too tricky. Just for some context - we went for alphanumeric & `_` to have valid SQL column names and to be able to query it. We haven't used it as much as we thought, but we should keep it in mind if we decide to switch (I personally don't have any issues with `_` and `__`.)


Hey everyone, we have picked up the fix for this item on priority and the fix is in progress. We will share updates on it soon.


Thanks for chiming in @Marigold. Yes, if we have dimensions info stored somewhere in the metadata, that's clearly a better option than extracting it from short names. This works well with the common approach e.g. in some of the datasets mentioned by Lucas above.

There's one downside, though. As far as I understand, this is generated **in the grapher step**. In principle, our goal has always been to keep our best data in garden, and let grapher be a step of minimal changes to adjust to our data viz needs. Using jinja templates in garden is shifting our best data to grapher (the resulting metadata is not human-readable in those garden steps). The consequence of this is that, currently, our best data is sometimes in garden, and sometimes in grapher. Maybe this is the direction we want to go, but we should be explicit about this choice, instead of letting our technical limitations make this decision for us.

I know this goes beyond the scope of this issue, but maybe we should clarify as soon as possible our long-term vision of garden and grapher. I think it should be possible to achieve both: (1) having our best data in garden, and (2) handling multidimensional data.


My two cents on your points, @pabloarosado:

This metadata on dimensions is generated automatically when formatting long-format (from Garden) to wide format (in Grapher), which occurs in the `grapher` step.

I think it's totally fine to keep it like this. I don't see any problem in having Jinja in the YAML files of Garden. Someone that looks into our codebase, should expect to encounter things like that. For end consumers that are not interested in "how we build" things, they can just access the metadata that is exported to JSON files. That metadata is public-ready, and won't contain any Jinja templating.

Having said this, we need to find a way to ingest the metadata on dimensions whenever one uses a wide format. If using long-format, it will be automatically generated (since the dimensional information is already in the index), but it won't be the case otherwise. In those cases, I think you need some way to manually add this layer of information. I never use this structure, but I know you do, so it'd be very valuable if you come with a strategy to add the metadata on dimension in those cases. Happy to help!

Also, more than happy to discuss further steps any time.


@DivyaPatidar Logs are shared with @exextoc in a private repository.


Thanks for the synthesis, @lucasrodes, you have phrased the situation very well, and I agree with your conclusions. Just one clarification: embracing long formats also implies additional tooling (they clash with our current data structure, where metadata is stored at the column level).
So let's try to allocate some time in our upcoming discussions to decide a roadmap on where to go in terms of (1) our preferred data (and metadata) structures, and (2) our data catalog.


Thanks for reaching out, @mgmarino. We'll work this out and keep you posted about any progress.


URL this one? Can you confirm its running Android 9.0. If so this is not similar to the other issues, as this device is having problems on the OpenGLES backend.


So, i have a new version of a computation partitioner that completely relies on indexing maps. That did not help and it even outlines the same number of functions. Disabling the inliner helps and it compiles quickly. I will check, what's happening there.


I was facing a similar issue as described in #160804, where the rendering was blank, and videos were only playing audio without displaying visuals. After following the suggestions here, I was able to fix the issue by disabling Impeller.

It worked like a charm! 🎉
Thank you so much @jonahwilliams

For now, disabling Impeller is the recommended workaround until the PR mentioned by Jonah (#163265) is merged into the main branch and included in a new Flutter release.

Hope this helps others facing the same problem! 🚀


Issue Description:
After upgrading Flutter, the WebView in your app stopped displaying content correctly on devices running Android API 30 or lower (like OPPO F11 with Android 11 and OPPO A15 with Android 10). Instead of showing the web content, the WebView displays a blank screen or becomes blurry with no rendered content.

However, this issue does not occur on devices with API 32 or higher (like Android 12L).

Steps Taken:
Flutter Upgrade: Upgraded Flutter to the latest version.
webview_flutter Update: The webview_flutter package was also updated to the latest version.
Device Testing: The issue was observed on OPPO F11 (Android 11, API 30) and OPPO A15 (Android 10, API 29), while WebView functions fine on devices with API 32 and above.
Temporary Workaround:
To fix the issue temporarily, I disabled Impeller as a rendering engine. This workaround was effective, but it's not ideal long-term because Impeller is being phased out.

Logs and Errors:
I tried updating the webview_flutter package and modifying your AndroidManifest.xml, but the issue persists. The behavior observed is similar to the one discussed in issue #160804, where rendering issues occurred due to a blank screen, and videos were playing audio without visuals.

Conclusion:
While the workaround is currently functional, the problem appears to be related to the interaction between Flutter, WebView, and certain Android versions, especially on devices with API 30 and lower. I'm seeking a permanent solution and asking for insights into how this can be fixed without relying on the Impeller workaround.

Additional Information:
Device Models: OPPO A15 (Android 10, API 29) and OPPO F11 (Android 11, API 30).
The issue is observed when the app is launched on these devices, with WebView failing to display content, and the display breaking or being blurry.

While that is a good workaround, we need information on how to fix the bug, because long term we plan to remove the ability to disable impeller


Thanks for the update, @jonahwilliams. I’m seeing the same issue on OPPO F11 (API 30) and OPPO A15 (API 29) with WebView and video playback. The Impeller workaround works temporarily, but I'd prefer a long-term solution since it doesn’t work on all devices, especially those with API 30 and lower. Is there an upcoming fix for this?


The code for sending the email is done, I haven't added the template id to the manifests repo where that value can be used from within `vets-api`. The PR to do that is waiting on feedback from Platform.


We've started to break down the remaining data work for MDIMs in smaller issues.

**On issue 1:**
- #3981

**On issue 3:**
This is now possible! This still needs to be documented, but we have the following PR as a reference for now:

- URL

**Other issues**
- #3976
- #3977
- #3979
- #3980


The RLBench simulator provides groundtruth segmentation masks. These numbers are the instance ids of the object in the groundtruth mask. We manually annotated the labels.


Ahh yes I do. I have the N64 digital hdmi/RGB mod installed. Is that something unlikely to be fixed down the line through a firmware update? (Either blueretro or retro GEM)


See this post
 URL

You can do as a document it or try get a replacement flex from the hdmi mod vendor.
Or you can simply disconnect the OSD line going to the pif


#378 is shipped 🛥. This was the last big development effort that was needed.

Next up are simple bugfixes or features and write documentation. GA release by the end of February (2 weeks) is on track.

Image


It's hard to say where to draw the line. Python uses under_score and MySQL & TS camelCase. ETL uses mix of both - in most cases underscore, but for instance `display` is in camelCase because it's directly inserted into db.

As far as I know, this hasn't caused that many problems, as most of them were caught by our YAML linter. I'll leave it up to @lucasrodes and other data managers to decide what is the preferred casing and whether it's worth changing it.


Hey @SE-Hubert ,

Thank you for reporting this issue. It has been put in our backlog. Unfortunately, we have no timelines to share at this point.
Here are a few points I wanted to call out:

1. This issue does not reproduce for "OnMessageSend" using LaunchEvents, but only for `ItemSend`. Do you see this issue in `OnMessageSend`? If not, can this be used as a workaround?
2. The documentation does call out that `item.close()` should not be called in on-send handler (although I agree that the reasoning might not be the same).

I wanted to understand your reason for using `item.close()` instead of (for instance) `.completed({ allowEvent: false })` in this scenario.

Internal tracking ID: 5412251


@SE-Hubert - One clarification on the message above- the issue we are tracking relates to the dialog that appears with `{discardItem: true}` in this case. Do note, that calling `item.close()` is expected to show the dialog if there are unsaved changes as per our documentation). This should be the case regardless from where this is called.


Sorry, I have another confusion. I referred to a solution mentioned in an issue from RLBench: URL and I tried to obtain the instance IDs of the object in task `take_shoes_out_of_box`. However, the result I generated seems to not match the values in the script you provided.

I obtained a total of 37 object IDs, and the ID for the box lid is 35,

Image

but in the script you provided, it is 96.

"take_shoes_out_of_box+0": [
 {
 "action": "grasp",
 "object": {
 "name": "box lid",
 "fine": [96],
 "coarse": [92, 96]
 }
 },
 {
 "action": "move grasped object up"
 },
 {
 "action": "grasp",
 "object": {
 "name": "shoe",
 "fine": [82],
 "coarse": [82]
 }
 },
 {
 "action": "move grasped object out"
 },
 {
 "action": "grasp",
 "object": {
 "name": "shoe",
 "fine": [102],
 "coarse": [102]
 }
 },
 {
 "action": "move grasped object out"
 }
 ]

I would like to ask again, how are these instance IDs obtained?

Looking forward to your reply and would greatly appreciate it!


@exextoc @mobisw-msft We need a concrete update on the progress of the issue. This has been outstanding for far too long, and the lack of resolution is now impacting our customers. Despite previous follow-ups, we have not yet seen meaningful movement or a clear ETA. Thanks!


Please follow the instruction in our dataset generation to get the groundtruth segmentation masks. Our annotated ids are related to these masks.


@mobisw-msft To answer your points, this issue is also present using the "OnMessageSend" from the "LauchEvents". Like you said I tried it as a workaround.

Like you mentioned, it is not recommended to do `item.close()` on an `ItemSend` event, but in our case there is no other way of doing it. Since there is no background script available and the add-in can only be in `Read` or `Compose` mode, we are using a `Service Worker` to send the emails. We are doing end-to-end encryption and processing the email can take quite sometime depending on files , recipients and other.

So we basically collect all the data needed from the `ItemSend` event and then send it to the `Service Worker` will send the processed email through the `Graph API`. With this approach, we are unable to use the default `.completed({ allowEvent: false })` since it unload the function file declared in our `Manifest`, and we are unable to use the `.completed({ allowEvent: true })` since we only want the email to be sent later by the `Service Worker`.

So this is the reason why we are using the the `item.close()` and not the other recommended methods.

Also just to clarify, but before collecting and sending the email data to our `Service Worker`, we `SaveAsync` the current state of the email and keep the normal behavior of the drafts. So there should be no unsaved changes when we use `item.close()`. Could the `ItemSent` event not save the current changes like mentioned in the #5345 issue ?


It could be the case, because ever since issue #5345 has been reproducible, I also started seeing this message.


Yeah it's a shame the 2 languages have different conventions here.

I'm more than happy to close this immediately if it's not a problem for anyone - Lucas just suggested I create a ticket for it after I remarked on it in our DMs. I think the actually impactful thing is making sure that topic tags are validated consistently, but consistent casing isn't a requirement for that.


Platform has responded, I've updated the PR and that is back in front of them to review.


not sure if a coincidence but since yesterday my iOS azure pipeline started to fail with.

/Users/runner/hostedtoolcache/dotnet/packs/Microsoft.iOS.Sdk.net9.0_18.2/18.2.9173/targets/Xamarin.Shared.Sdk.targets(1279,3): error : Failed to AOT compile aot-instances.dll, the AOT compiler exited with code 139
Failed to AOT compile SkiaSharp.Views.iOS.dll, the AOT compiler exited with code 139

I am using .net 9 and on sunday with maui 9.0.30 worked then upgraded to 9.0.40 and crashed, then reverted to 9.0.30 and still broken.. I am confused! And we are supposed to go to prod in a week , any suggestions @rolfbjarne ?


In my case, an update to VS 17.13 was to blame.
After a rollback to 17.12.4, it worked again.

This behavior, that an iOS build via Windows->Mac suddenly no longer works from one day to the next, has been annoying me for a long time.
The team behind Xamarin.iOS is not doing a very good job with version coupling here


@baaaaif oh thanks for that , now that makes sense because I downgraded to maui 9.0.30 and I still got the error and I have 17.12.5
I will try to rollback to 17.12.4 hopefully its easily done . I was looking also at this thread URL


A new version of .NET (9.0.2) was released last week, that might be why it started failing recently, so it might work if you force the previous version (9.0.1) in your Azure pipeline.


@rolfbjarne thanks for your suggestion , but for some reasons I cannot seem to force 9.0.1 in the pipeline it says
I have tried both with macOS14 and 15 Hosted agent.. Am I missing something?

 **##[error]sdk version matching: 9.0.1 could not be found**

and I have

 - task: UseDotNet@2
 displayName: .NET Version
 inputs:
 packageType: 'sdk'
 version: '9.0.1'
 includePreviewVersions: false


Anyone from the Maui team ? we are stuck and tried forcing .net install 9.0.1 but the hosted agent did not allow it. We cannot deliver to production next week.

any work around?


I've oriented myself on
 URL
using a global.json and

steps:
- task: UseDotNet@2
 displayName: 'Use .NET Core sdk '
 inputs:
 useGlobalJson: true

in the pipeline. Hope this helps and works for you


@baaaaif I dont have a global.json, not sure what that changes compared to what I have tried in the pipeline , may be my code to install 9.0.1 is wrong


Ok, the issue was within the inliner itself. I will upload the fix today.


still very very confused

16st Feb Sunday (last success pipeline) was using .net 9.0.200. and all was building..
Monday starts failing...

 _IL stripping assemblies
 Tool /Users/runner/hostedtoolcache/dotnet/packs/Microsoft.NETCore.App.Runtime.AOT.osx-x64.Cross.ios-arm64/9.0.2/Sdk/../tools/mono-aot-cross execution finished (exit code = 139)._

installed .net 9.0.100 but still makes no difference!

what Am I missing? very grateful for any insight


Hey all, the fix has been checked in, pending rollout. It will be available in Outlook for Web build `20250217008` onwards.


Up to you, I don't mind having it on our eyes for some time. Either we figure it out or owidbot closes it.


The hotfix is not fixing the issue for EXISTING items in Google. ONLY if I am changing them a bit - like adding 5 minutes and re-syncing - it is fixing the wrong entry in outlook!


The second PR with actual implementation is here: URL So please reopen the issue


@rafi-d For fixing already syncing items you either need to edit the Outlook item(s), or run a full sync from O->G.


What about from G to O? Your bug was in Outlook times (in my use case)


coming in paraglide js 2.0:

auto-import when writing `m`.

no more manual `import * as m`

Image


The fix makes compilation of one of the tests in JAX slow. Everything else became better... Looking.


That looks fantastic, I'm curious how this works, so far couldn't find anything on how to enable auto-import for `import * as X` 🤔


Yea I am also facing this same issue, after the message reaches a certain size, the order of the messages changes, the messages gets chunked at random positions etc any fix or potential clues where I can look into to try to fix this issue?


I'm still having the issue that @rafi-d had, with past appointments not updating. I tried hotfixes 2.11.2.1, 2.11.2.3, 2.11.2.4, and 2.11.2.6. It comparies all of the entries and says that none of them need to be updated, even though the past Google Calendar entries are in the correct time and the same past Outlook entries are not. The sync is set Outlook <-- Google. Any ideas?


Hi, did you check #2? It should not involve too many modifications to the original PyTorch grad-cam implementation. We will provide an example soon.


@buckaroo54 You're running a full sync or a delta sync? Either press `Shift` and click `Sync`, or use the dropdown on the Sync button...


I was _not_ running a full sync 🙃 Thank you for the guidance, all's well now! 😁👍


regex-pcre2 is now on Hackage and soon hopefully on Stackage as well. It links against libpcre2.


We have been affected too and none of the solutions mentioned on this thread works apart setting the interpreter to true which defeats the point alltogether.

Do we know if this is been worked on? Is there any chance of a quick fix and deploy?


That would be great as I rolled back to net8 to workaround that. But that can't be a long term solution given that Maui is not tied to the LTS of dotnet.


If you have any build logs from a working build, you could compare them with the current build logs to see if there are any version differences anywhere.


for me commenting these lines prevented the hanging issue:
 URL


Could you indicate when you expect this build to be rolled out?


I might found a bug in this - when trying to send ERC20 token from the dashboard, it opens ETH send form instead for me.


Removing the Hadoop classpath fixed `async_task`, although this is in the logs:

SLF4J: Failed to load class "org.slf4j.impl.StaticMDCBinder".
SLF4J: Defaulting to no-operation MDCAdapter implementation.
SLF4J: See URL for further details.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See URL for further details.


I’ve added a fix for this and issue **#495** on my fork. You can check if it works for you.

**Before video:**
Before

**After video:**
After


@rolfbjarne Hi, looked at the azure pipeline logs and I get as follows

**Success last week**

 Optimizing assemblies for size may change the behavior of the app. Be sure to test after publishing. See: URL
 Optimizing assemblies for size. This process might take a while.
 IL stripping assemblies
 Created the package: /Users/runner/work/1/s/Clients/ClientA/artifacts/ClientA.ipa

**Failure**

 IL stripping assemblies
 Tool /Users/runner/hostedtoolcache/dotnet/packs/Microsoft.NETCore.App.Runtime.AOT.osx-x64.Cross.ios-arm64/9.0.2/Sdk/../tools/mono-aot-cross execution finished (exit code = 139).

/Users/runner/hostedtoolcache/dotnet/packs/Microsoft.iOS.Sdk.net9.0_18.2/18.2.9173/targets/Xamarin.Shared.Sdk.targets(1279,3): error : Failed to AOT compile aot-instances.dll, the AOT compiler exited with code 139. [/Users/runner/work/1/s/Clients/ClientA/src/MyApp/MyApp.csproj::TargetFramework=net9.0-ios]
 Tool /Users/runner/hostedtoolcache/dotnet/packs/Microsoft.NETCore.App.Runtime.AOT.osx-x64.Cross.ios-arm64/9.0.2/Sdk/../tools/mono-aot-cross execution finished (exit code = 139).

/Users/runner/hostedtoolcache/dotnet/packs/Microsoft.iOS.Sdk.net9.0_18.2/18.2.9173/targets/Xamarin.Shared.Sdk.targets(1279,3): error : Failed to AOT compile SkiaSharp.Views.iOS.dll, the AOT compiler exited with code 139. [/Users/runner/work/1/s/Clients/ClientA/src/MyApp/MyApp.csproj::TargetFramework=net9.0-ios]

Both they were using

Image

Is there any preview version that we could try? Or is there a fix in the works? grateful for any suggestions, we cannot revert to .net 8, to many changes to our code,


Just to confirm, the only update is VS?

Are you able to attach a binlog? URL


@mattleibow locally everything works fine! but for some reasons when building the iOS app via Azure Pipeline we get

 IL stripping assemblies
 Tool /Users/runner/hostedtoolcache/dotnet/packs/Microsoft.NETCore.App.Runtime.AOT.osx-x64.Cross.ios-arm64/9.0.2/Sdk/../tools/mono-aot-cross execution finished (exit code = 139).

/Users/runner/hostedtoolcache/dotnet/packs/Microsoft.iOS.Sdk.net9.0_18.2/18.2.9173/targets/Xamarin.Shared.Sdk.targets(1279,3): error : Failed to AOT compile aot-instances.dll, the AOT compiler exited with code 139. [/Users/runner/work/1/s/Clients/ClientA/src/MyApp/MyApp.csproj::TargetFramework=net9.0-ios]
 Tool /Users/runner/hostedtoolcache/dotnet/packs/Microsoft.NETCore.App.Runtime.AOT.osx-x64.Cross.ios-arm64/9.0.2/Sdk/../tools/mono-aot-cross execution finished (exit code = 139).

/Users/runner/hostedtoolcache/dotnet/packs/Microsoft.iOS.Sdk.net9.0_18.2/18.2.9173/targets/Xamarin.Shared.Sdk.targets(1279,3): error : Failed to AOT compile SkiaSharp.Views.iOS.dll, the AOT compiler exited with code 139. [/Users/runner/work/1/s/Clients/ClientA/src/MyApp/MyApp.csproj::TargetFramework=net9.0-ios]

till sunday this was building fine in azure , then started to fail , I think I did an upgrade of VS to 17.3 but not sure now but rolledback to 17.2.2 and nothing still fails , I am not the only one with this issue as you can see URL


@chrisonline This looks like issue 1685 "The specified module could not be found". Recently there were major upgrades in the Python that may help. Would you please test one of these options?

1. BleachBit 4.9.0 alpha is based on Python 3.10 and is digitally signed
2. BleachBit 4.9.1 CI build 2775 , based in Python 3.11, is newer but is not digitally signed.

Both have known issues, so may not be ideal for everyday use. However, testing would tell us a lot about whether the Python upgrade fixed the issue.

A third option is to install BleachBit in a folder without a space such as
* `c:\bleachbit`
* `d:\bleachbit
* `d:\program_files_x86\bleachbit`

Please let me know what you find out.


@mr-brunes
@harkinhails

Recently there were major upgrades in the Python framework that may help. Would you please test one of these options?

1. BleachBit 4.9.0 alpha is based on Python 3.10 and is digitally signed
2. BleachBit 4.9.1 CI build 2775 , based in Python 3.11, is newer but is not digitally signed.

Both have known issues, so may not be ideal for everyday use. However, testing would tell us a lot about whether the Python upgrade fixed the issue.

A workaround is install BleachBit in a folder without a space such as
* `c:\bleachbit`
* `d:\bleachbit
* `d:\program_files_x86\bleachbit`

Please let me know what you find out.


Your ComfyUI version is too old. Please update your ComfyUI and try again.


From URL it appears that maybe `@JsonValue` is not really supported. If that is still the case, it would be good to at least be able to compile (like in micronaut 3), rather than blow up.