RCTFatalExceptions are reported when using CodePush

From @andriantosg (split from #35):
Hi, does anyone know why I still got RCTFatalException: Unhandled JS Exception: while using CodePush? I've tried using *main.jsbundle on minified-url but unfortunately It didn't work. Am I missing something?

@andriantosg Which versions of React Native, bugsnag-react-native, and Code Push are you using?

Hi @kattrali, I'm sorry forgot to update here. I've found the solution for this problem. It seems I failed  to set codeBundleId in my RN code so It couldn't mapping to uploaded sourcemaps, but now It works well.
But I got another question now. Before I do any codepush, Bugsnag can visualize me exactly where is error code with file names and line of code. But after I do codepush, Bugsnag only show me file names and line of code. It doesn't visualize where exactly the error code is. Is this expected?
I'm using RN 0.44.0, latest bugsnag and code push version.

Thanks for the update. My guess is that the source file contents are not being uploaded. There's more explanation and a possible fix in the troubleshooting FAQ

Thanks for the information. It suggest me to use the --upload-sources flag in bugsnag-sourcemaps to upload all files referenced by the source map. But I've used it and code context still didn't appear. Is there any workaround?
And how do I ensure that the sourcesContent field in the source map file is populated correctly?
FYI, I used this CLI command to upload my codepush bundle.
bugsnag-sourcemaps upload \
  --api-key [API_KEY] \
  --code-bundle-id [BUNDLE_ID] \
  --minified-url main.jsbundle \
  --source-map ios/build/main.jsbundle.map \
  --minified-file ios/build/main.jsbundle \
  --upload-sources \
  --add-wildcard-prefix \
  --overwrite

The command looks correct to me. 🤔 I'll be able to take a look at what's happening on our end on Monday. I'm working on some improvements to the documentation as well to make this process clearer.

That's great. I'm waiting for your updates. Thank you.

Hi @kattrali, is there any updates?

It looks like this happens if the JavaScript portion of configuration is not completed. Each platform requires the native portion of configuration as well as the JS section. I'm restructuring the docs a bit to better explain how this happens.

Fixed by updating the integration guide to indicate that JS + native config is required for each platform


Document the Broker's versioning strategy

Document broker's compatibility with APBs
Document versioning and branching strategy

 Automation Broker Versioning Strategy and Compatibility Matrix


Change linux/fs include to build with glibc 2.36

glibc 2.36 includes changes (documented at https://sourceware.org/glibc/wiki/Release/2.36#Usage_of_.3Clinux.2Fmount.h.3E_and_.3Csys.2Fmount.h.3E) that create build errors when including linux/fs.h for mount configuration.  sys/mount.h is a more appropriate include here, which works with older glibc as well.

Cherry-picked to v9.2.x


Type inference for object literals with string types and Object.assign

TypeScript Version:  2.4.0
I didn't know if there was an issue open for this already, but this is a tricky one. Consider the following code.
interface Tagged {
    type: 'abc'
}

const x: Tagged = Object.assign({ type: 'abc' }, {})

This code will not compile, because the type inference for the literal {type: 'abc'} ends when being passed to a function call and the type is inferred as {type: string}, which is of course not assignable to {type: 'abc'}, which is a good thing.
Expected behavior:
I expect the literal to instead be inferred as {type: 'abc'}, so the object can be assigned.
Actual behavior:
The literal is inferred as {type: string}, so assignment cannot be done.
Rationale:
Literal types like 'foo' and 3 are narrower types than string and number, so better type checking can be done with those types. If TypeScript can infer narrower types where possible, then assignments like the above will work.
There is a problem with assignments like the following, however.
const x = {type: 'abc'}
const y = Object.assign({type: 'abc'})

If TypeScript were to start inferring {type: 'abc'} in these cases instead of {type: string}, then this could break existing code. So this isn't an easy issue to handle.

There is a way to work around this in some cases. You can replace {type: 'abc'} with {type: 'abc'} as {type: 'abc'}, or write some wrapper functions.

Or this:
const x = Object.assign({ type: 'abc' }, {}) as Tagged;

This is expressly what type coercion is designed for, for dealing with situations where narrower types cannot be reliably contextually inferred.

Yes, that will also work in this case. In my case, I had some existing objects that weren't tagged, and I had some new types where I was creating objects which have tags in them. So the arguments were [{type: 'abc'}, T] producing T & {type: 'abc'}.
I'm wondering if it would be possible to have TypeScript figure out these kinds of expressions automatically. It certainly wouldn't be easy. It might be impossible.

Yeah it would be great if TypeScript allowed you to annotate an object literal in a way that allowed it to choose the narrowest type possible so you don't have to repeat yourself.  Here's something I sometimes use (as a library) when repeating myself feels worse than jumping through hoops:
class LiterallyTypedObjectBuilder<T> {
  obj = {} as T;
  private constructor() {
  }
  and<K extends string, V extends string | number | boolean | {}>(k: K, v: V): LiterallyTypedObjectBuilder<T & Record<K, V>> {
    var that = this as any as LiterallyTypedObjectBuilder<T & Record<K,V>>
    that.obj[k] = v;
    return that;
  }
  build(): T {
    return this.obj;
  }
  static of<K extends string, V extends string | number | boolean | {}>(k: K, v: V): LiterallyTypedObjectBuilder<Record<K,V>> {
    return new LiterallyTypedObjectBuilder<{}>().and(k,v);
  }
}

You'd use it like this:
interface Tagged {
    type: 'abc'
}

const x: Tagged = LiterallyTypedObjectBuilder.of('type', 'abc').build();
const x2: Tagged = Object.assign(LiterallyTypedObjectBuilder.of('type', 'abc').build(), {});

interface Another {
  type: 'def'
  size: 'S' | 'M' | 'L'
  age: number
  happy: boolean
}

const y = LiterallyTypedObjectBuilder.
  of('type', 'def').
  and('size', 'M').
  and('age', 42).
  and('happy', false).
  build();
const yAsAnother: Another = y;

Ugly and obnoxious, but it does infer the literals.

it becomes a chicken-and-egg problem, since the compiler needs to know the types of the inputs to find the return type, but the return type is what provides the contextual type to inform the inference.
related to https://github.com/Microsoft/TypeScript/issues/11152


Integrate dev mode with the Boost plugin

A boost user will be able to directly call Liberty dev mode via:
mvn io.openliberty.tools:liberty-maven-plugin:3.1.M1-SNAPSHOT:dev  (for example)
If the Boost plugin is defined in the pom, Liberty dev mode will call boost:package when changes to the pom are made.

One thing that stands out to me is that we are using the presence of the Boost plugin in the MavenProject in order to decide whether or not we should run the boost mojos. Does this still work if we are invoking Boost dev mode directly from the command line without defining it in the plugin?

One thing that stands out to me is that we are using the presence of the Boost plugin in the MavenProject in order to decide whether or not we should run the boost mojos. Does this still work if we are invoking Boost dev mode directly from the command line without defining it in the pom?

Not sure what you mean by "invoking Boost dev mode directly"... we don't have a 'dev' goal in Boost, only in LMP.

Appveyor is failing with several compilation errors which seem unrelated to this change. Are these known issues?

Appveyor is failing with several compilation errors which seem unrelated to this change. Are these known issues?

Haven't looked at past builds but I see:

[00:11:25] [INFO] [ERROR] Failed to execute goal io.openliberty.tools:liberty-maven-plugin:3.0-M3-SNAPSHOT:clean (clean-server) on project basic-runtime-version-property-override-it: CWWKM2031E: Cannot delete file C:\projects\ci-maven\liberty-maven-plugin\target\it\basic-runtime-version-property-override-it\target\liberty\wlp\usr\servers\defaultServer\logs\console.log. -> [Help 1]
[00:11:25] [INFO] [ERROR]

which, with the fact that it's running on Windows, seems suspiciously like an environmental issue.

I have not seen compilation errors in AppVeyor, but I do see this in many recent builds (also seems like an environment issue):

I rebased and the compilation failures are resolved now, but there is one failing test only on OL <IP_ADDRESS>.  I don't see this failure locally. Might just be a fluke, but am looking into it.


maybe add libfm and libffm to benchmark

http://www.libfm.org/
Factorization machines (FM) are a generic approach that allows to mimic most factorization models by feature engineering.
http://www.csie.ntu.edu.tw/~cjlin/libffm/
LIBFFM is an open source tool for field-aware factorization machines (FFM). For the formulation of FFM, please see these slides. It has been used to win two recent click-through rate prediction competitions (Criteo's and Avazu's).
They are also very interesting tools.

Sure, if someone wants to do this :)

why remove the labels? Is contribution no longer needed?

Sorry, I don't recall why I removed the labels (it was 2 yrs ago). Btw this repo is more like in legacy mode, see https://github.com/szilard/benchm-ml#summary (in short: on a reduced scope, I maintain https://github.com/szilard/GBM-perf for GBMs)


feat: fox farming v6

Description

Notice

[ ] Have you followed the guidelines in our Contributing guide?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #
Risk

Testing

Engineering

Operations

Screenshots (if applicable)

Current dependencies on/for this PR:

develop

PR #4134   👈

This comment was auto-generated by Graphite.


Deprecate Remaining VIP sniffs

To the Files category, and deprecates the old sniff with a warning.
If this PR goes well I hope to do the same to all the other sniffs mentioned in #1409

@tomjn Glad to see the first PR for this.
This sniff in my opinion should not be moved, only deprecated. File system writes being forbidden is a VIP specific requirement which does not easily apply to other projects in the WP ecosphere, so this sniff is a candidate for complete removal in 2.0.0.

Ah, my goal with this PR is mostly to get to grips with the deprecation process for a sniff. This is certainly an issue for VIP, I can't comment on other hosting platforms, but this usually pops up in any situation were the uploads folder doesn't exist on the file system, which is why VIP flags it. But ignoring that, I just want to make sure I'm not making a colossal mess in follow up PRs, so consider this a practice run :)

I can't comment on other hosting platforms

The WPCS ruleset is not for specific hosting platforms. Other hosters can - just like Automattic - create their own PHPCS standard based on WPCS and add additional sniffs to it to facilitate their needs.

consider this a practice run

:+1:

yay travis is happy 🎉

@tomjn Do you mean that this PR is ready for review from your point of view ?

I think I just need to move the content back into the original sniff so
that it's deprecated not migrated, at which point it'll be complete, if all
is good I can apply the same process to the other sniffs. I've set aside
some time later today to go through the rest
On Thu, 5 Jul 2018 at 01:02, Juliette<EMAIL_ADDRESS>wrote:

@tomjn https://github.com/tomjn Do you mean that this PR is ready for
review from your point of view ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/pull/1410#issuecomment-402573858,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADl5_Keb3w-3JUpq_pdI50dFzixhJLcks5uDVeDgaJpZM4VAud5
.

@jrfnl the PR's ready for review, if all is good I'll do the same to the other sniffs mentioned in #1409

@tomjn Just scanned through the latest update related to the FileSystemWrites sniff and - except for missing a @deprecated tag in the class docblock -, all seems good now.

@tomjn I can see you are updating the PR with further changes. Could you please ping me when you are ready for the next review ?

So I believe I'm ready for review, my main concern though is I'm unsure why the one travis check is failing :/

my main concern though is I'm unsure why the one travis check is failing :/ Any help appreciated

The report says:

ERROR: Referenced sniff "WordPress.VIP.AdminBarRemovalSniff.DeprecatedSniff" does not exist

WordPress.VIP.AdminBarRemovalSniff.DeprecatedSniff

Should be: WordPress.VIP.AdminBarRemoval.DeprecatedSniff

Gah such an obvious mistake, fixed

I've addressed a lot of the feedback, integrated the changes suggested in #1403, todo items:

check each sniff for parameters and add appropriate FoundPropertyForDeprecatedSniff notices
update unit tests with new checks, not entirely sure how to do that though for sniff parameters
Figure out squashing c1736c2 and e6b90a2 into eachother

Thanks for being patient, I'm learning a fair amount of PHPCS/Git history adjustments doing this

Basically, you need to make sure that there is a // @codingStandardsChangeSetting line in the unit test file which changes a public property and code after that which triggers the sniff.
The settings changes needs to be reset back to the default value with a second // @codingStandardsChangeSetting line afterwards.

Ah, that makes a lot more sense now :) I was half expecting initially that a 4th file acting as an equivalent to the CSS/PHP.inc files would be appropriate but couldn't see any examples.
Also for reference, interactive rebasing to amend commits ftw, I'm lucky I'm working in a feature branch

Also for reference, interactive rebasing to amend commits ftw

:sunglasses: Yup, I live and breath interactive rebase on a daily basis. Love it.

@tomjn Just checking in... will you be able to finish the work on this PR tomorrow so we can include it in the WPCS 1.0.0 release ? :pray:

Yesterday was my birthday so I took some time AFK, it's on my todo list though for later today

@tomjn :+1: and happy birthday and many happy returns! :tada:

As far as I can tell, all the parameters for the VIP sniffs are already handled, moving on to unit tests

For reference I'm using the VIP Slow DB Query tests as a basis since the majority of what I need to do work wise is near identical
<?php

// @codingStandardsChangeSetting WordPress.VIP.SlowDBQuery exclude something
$query = 'foo=bar&meta_key=foo';

// @codingStandardsChangeSetting WordPress.VIP.SlowDBQuery exclude false

The travis builds seem a bit.. off, hmm, only thing to do is the final wording of the VIP deprecation paragraph

The travis builds seem a bit.. off

I restarted the one build which errored out and Travis is ok now.

@tomjn How can we help you to finish the PR ?

@jrfnl It's just the paragraph for the readme that needs doing, but my mind is blank. I'm also pretty tired out from the last week and have a busy week ahead of me. Chances are I won't be able to do much more on this, and that all that's actually needed is less than 20 characters of prose.

@tomjn Hmm... maybe @GaryJones can come up with some good phrasing ?
The 1.0.0 release is waiting on this PR and is already two weeks overdue now, so it would really help if we can finish this off now.

I'll come up with something today.

@jrfnl If the rest of the PR is good, then let's merge it, and I'll re-do my other PR for the readme - that way, we won't be waiting on Tom to merge readme changes into his branch before merging his branch into develop.

https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/pull/1410/files#r202600970

@jrfnl I've updated the PR with the version @GaryJones wrote, thanks for the wordsmithing :)


Dispatch create error on importing model

I receive an error on importing the model when running dispatch create. The error doesn't provide any further information on what went wrong. The command hangs on importing the model for several minutes before it quits with the error.
To Reproduce
Steps to reproduce the behavior:

Initialize a new dispatch by running dispatch init
Add a LUIS and QnAMaker source using dispatch add
Create the dispatch model with dispatch create
See error

Expected behavior
I would expect the dispatch model in LUIS to be created
Output
The output of running dispatch create:

Additional context
I'm using "authoringRegion": "westeurope". My LUIS model is in west europe and the QnA model is in west us.

Hi, I wonder if import timed out.  Could you retry "dispatch create" command?  Also, could you copy and paste NikkiLUISQnA.json file?  Or you could email NikkiLUISQnA.dispatch file to<EMAIL_ADDRESS> Thanks!

I was able to repro.  We will get this fixed, thanks for reporting!

Latest dispatch is published with fix for this issue.
https://www.npmjs.com/package/botdispatch


backside  unclickable

I want to add click things(not flip ,such as jump to ...) in backside . It does not work!
(我想在背面的view 添加点击事件 ， 但是不能生效)

You can do it by setting flipOnTouch to false like this:
app:flipOnTouch="true"

or in Java like
mYourFlipView.setFlipOntouch(false);

Be default, flipOnTouch is set to true. If you set it to false, then it won't flip. Rather, you will have to flip the card manually in java on any click or any button or wherever you want like this:
// Flips the view with animation
mYourFlipView.flipTheView();
// Flips the view without animation
mYourFlipView.flipTheView(false);

原谅我使用中文了，我用英文描述不清。
我的需求是这样的，我想给背面的view 设置点击事件 用来执行别的操作，而不是旋转整个view.

No Problem.
Here is the way you can do it:
First in XML, set android:flipOnTouch="false"  for your FlipView. Then all the buttons in your views will be clickable.

这样在背面是可以点击，但是获得焦点的是 正面的view

Both sides are clickable. If you want to flip the view now, you can do it by calling mYourFlipView.flipTheView(); from java code on any click event.

please check your gmail ,  thanks<EMAIL_ADDRESS>


Query: invalid sql (expecting search condition) for query projecting a single element from the collection of bool properties

query:
ctx.Gears.Where(g => g.HasSoulPatch && g.Weapons.Distinct().OrderBy(w => w.Id).Select(w => w.IsAutomatic).FirstOrDefault())

sql:
SELECT [g].[Nickname], [g].[SquadId], [g].[AssignedCityName], [g].[CityOrBirthName], [g].[Discriminator], [g].[FullName], [g].[HasSoulPatch], [g].[LeaderNickname], [g].[LeaderSquadId], [g].[Rank]
FROM [Gears] AS [g]
WHERE [g].[Discriminator] IN (N'Gear', N'Officer') AND (([g].[HasSoulPatch] = CAST(1 AS bit)) AND (
    SELECT TOP(1) [t].[IsAutomatic]
    FROM (
        SELECT DISTINCT [w].[Id], [w].[AmmunitionType], [w].[IsAutomatic], [w].[Name], [w].[OwnerFullName], [w].[SynergyWithId]
        FROM [Weapons] AS [w]
        WHERE ([g].[FullName] = [w].[OwnerFullName]) AND [w].[OwnerFullName] IS NOT NULL
    ) AS [t]
    ORDER BY [t].[Id]))

exception:
An expression of non-boolean type specified in a context where a condition is expected, near ')'.

possibly a dupe of https://github.com/aspnet/EntityFrameworkCore/issues/14900


Inline code doesn't work

Inline code =date(this.file.link.end)-date(today)only takes effect on the current page

Another question is can I add inline code to the path? I tried to be able to automatically link media files with the same name in other folders, but the path error was prompted.

You can't currently assign the result of an inline expression to another field; the implementation is pretty tricky to get right so I haven't gotten around to it yet.
For the second, you can do all of it in a single inline expression:
= elink("file://R:/Resources/video/" + this.file.name + "." + this.file.ext)


Update docs for shellac

[x] ensure that this works for our needs: https://mui.com/material-ui/experimental-api/css-theme-variables/usage
[x] build a script to pull that data into a .css file
[x] ship the file in the root of our package
[x] update docs

done for now


Option to render class name scalars using PHP 5.5+ class-keyword.

As proposed in #5.
I thought about adding an option to toggle the autoload usage, but I could not find any reason why you would want to set it. If you want it to be added, let me know.
I did not add a trailing slash to resolved ::class-literals, because:

The rendered output does not include any namespacing.
Even if the rendered output is included in another namespace, PHP does not transfer the context to the included file.

Please add a test case for to assert the default value is false

Probably a getter method will be better.

Disagree on this one, would rather test via reflection than adding API for testing purposes :-\

I also did not want to add implementation only for test purpose. I reverse it and use the phpunit check instead.


MenuList internal DOM node not found when using react suspense, causes error.

[X] This is not a v0.x issue.
[X] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior 🤔

The error should not occur.
Current Behavior 😯

When using React.lazy and React.Suspense an error occurs inside the MenuList component.
Steps to Reproduce 🕹

I have not been able to create a CodeSandbox or github repo to reproduce this issue, which means that it might actually be an issue on my part. I have not been able to find the exact root cause as to why this happens, but I have a guess so I decided submit an issue anyways.
My setup looks something like this:
const LazyLoadedComponent = React.lazy(() => import('./lazyLoadedComponent'))

<React.suspense fallback={...}>
    <div>
        <MenuList />
        <LazyLoadedComponent />
    </div>
</React.suspense>

My theory is that while LazyLoadedComponent is being loaded, React doesn't actually mount to the DOM since the fallback is above the MenuList in the hierarchy. This causes the call to ReactDOM.finDOMNode to return null at this line, which in turn causes the property this.listRef to be null. The error occurs at this line since list is null.
According to this stackoverflow question the preferred way is to simply use the ref directly, and according to this react docs page the use of findDOMNode is discouraged. What is the reason to call ReactDOM.findDOMNode(ref) in this case? Can't we use the ref directly instead, as the react docs seems to suggest?

Tech
Version

Material-UI
v3.4.0

React
v16.6.1

Please understand that findDOMNode was only deprecated in 16.6.0. Getting rid of it will still take some time and effort beyond this package since the current alternative (React.forwardRef) has very poor support throughout the ecosystem.
It is unlikely that this is the cause. The line you specified is only reached after the component is mounted at which point the DOM node should also be mounted? Can you maybe tweak your code so that LazyLoadedComponent simply suspends indefinitely? Maybe that helps.


Switch documentation builds for PRs to readthedocs

EDIT: This PR removes our existing documentation build on GitHub actions in favor of building directly through readthedocs. This has the advantage of providing a nice preview of the docs for each PR.
Closes https://github.com/dask/dask/issues/7395
cc @raybellwaves @jsignell

Cool! Should there be a note about this in develop docs?

You can even use the new documentation preview to see what the changes look like 😎

Should we do the same thing with Distributed?

Should we do the same thing with Distributed?

Yeah, that's my plan after this is merged
Note CI failures are unrelated and fixed by https://github.com/dask/dask/pull/7405


az vm image terms: check for missing version in URN

The Command
az vm image terms and its subcommands.
The Issue
az vm image terms and its subcommands can be issued with either individual options to specify the marketplace product (--offer, --plan, etc.) - or instead provide the fully qualified URN using --urn. However, when passing a malformed URN, such as one that is missing the version component, the command hard fails:
# Example URN which works as intended
$ az vm image terms show --urn Canonical:0001-com-ubuntu-pro-jammy:pro-22_04-lts:22.04.202305310

# Example URN which hard fails with a less than obvious error message
$ az vm image terms show --urn Canonical:0001-com-ubuntu-pro-jammy:pro-22_04-lts:
The command failed with an unexpected error. Here is the traceback:
(", AttributeError: 'list' object has no attribute 'get'", 'Unable to deserialize to object: type', AttributeError("'list' object has no attribute 'get'"))
Traceback (most recent call last):
  File "/opt/az/lib/python3.10/site-packages/azure/mgmt/compute/_serialization.py", line 1430, in _deserialize
    found_value = key_extractor(attr, attr_desc, data)
  File "/opt/az/lib/python3.10/site-packages/azure/mgmt/compute/_serialization.py", line 1177, in rest_key_extractor
    return working_data.get(key)
AttributeError: 'list' object has no attribute 'get'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/az/lib/python3.10/site-packages/knack/cli.py", line 233, in invoke
    cmd_result = self.invocation.execute(args)
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/__init__.py", line 663, in execute
    raise ex
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/__init__.py", line 726, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/__init__.py", line 697, in _run_job
    result = cmd_copy(params)
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/__init__.py", line 333, in __call__
    return self.handler(*args, **kwargs)
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/command_operation.py", line 363, in handler
    show_exception_handler(ex)
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/arm.py", line 429, in show_exception_handler
    raise ex
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/commands/command_operation.py", line 361, in handler
    return op(**command_args)
  File "/opt/az/lib/python3.10/site-packages/azure/cli/command_modules/vm/custom.py", line 2441, in get_terms
    publisher, offer, plan = _terms_prepare(cmd, urn, publisher, offer, plan)
  File "/opt/az/lib/python3.10/site-packages/azure/cli/command_modules/vm/custom.py", line 2377, in _terms_prepare
    image = show_vm_image(cmd, urn)
  File "/opt/az/lib/python3.10/site-packages/azure/cli/command_modules/vm/custom.py", line 2327, in show_vm_image
    return client.virtual_machine_images.get(location, publisher, offer, sku, version)
  File "/opt/az/lib/python3.10/site-packages/azure/core/tracing/decorator.py", line 78, in wrapper_use_tracer
    return func(*args, **kwargs)
  File "/opt/az/lib/python3.10/site-packages/azure/mgmt/compute/v2022_11_01/operations/_virtual_machine_images_operations.py", line 320, in get
    deserialized = self._deserialize("VirtualMachineImage", pipeline_response)
  File "/opt/az/lib/python3.10/site-packages/azure/mgmt/compute/_serialization.py", line 1375, in __call__
    return self._deserialize(target_obj, data)
  File "/opt/az/lib/python3.10/site-packages/azure/mgmt/compute/_serialization.py", line 1445, in _deserialize
    raise_with_traceback(DeserializationError, msg, err)
  File "/opt/az/lib/python3.10/site-packages/azure/core/exceptions.py", line 78, in raise_with_traceback
    raise error.with_traceback(exc_traceback)
  File "/opt/az/lib/python3.10/site-packages/azure/mgmt/compute/_serialization.py", line 1430, in _deserialize
    found_value = key_extractor(attr, attr_desc, data)
  File "/opt/az/lib/python3.10/site-packages/azure/mgmt/compute/_serialization.py", line 1177, in rest_key_extractor
    return working_data.get(key)
azure.core.exceptions.DeserializationError: (", AttributeError: 'list' object has no attribute 'get'", 'Unable to deserialize to object: type', AttributeError("'list' object has no attribute 'get'"))
To check existing issues, please visit: https://github.com/Azure/azure-cli/issues

This issue is not to be confused with an URN with an invalid version. The command also correctly handles some incomplete URNs:
# A better error message
$ az vm image terms show --urn Canonical:0001-com-ubuntu-pro-jammy:
usage error: urn should be in the format of publisher:offer:sku:version.

# Not as good as the previous error, but much better than the one which is being reported
$ az vm image terms show --urn Canonical:0001-com-ubuntu-pro-jammy::
(BadRequest) The request URL is not valid.
Code: BadRequest
Message: The request URL is not valid.
Inner error: {
    "internalErrorCode": "RequestUrlInvalid"
}

The Solution
Azure Marketplace URNs are well defined, and Azure CLI should report that the URN is incomplete:
# An error message that tells the user what the URN is missing
$ az vm image terms show --urn Canonical:0001-com-ubuntu-pro-jammy:pro-22_04-lts:
usage error: urn is missing "version" in the publisher:offer:sku:version format

Other Considerations
This is a low impact enhancement. Users should be smart enough to input a valid URN (once again, the documentation is very clear on what an URN is comprised of), but I can attest to this error message being an issue for those who are less-than-familiar with Azure.

Thank you for opening this issue, we will look into it.


The RenderTexturePool should create renderTextures at resolution of 1

Since internally it has already scaled the requested render texture size within getOptimalTexture
https://github.com/pixijs/pixi.js/issues/5954

[x] Lint process passed (npm run lint)
[x] Tests passed (npm run test)

Codecov Report

Merging #5958 into dev will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##              dev    #5958   +/-   ##
=======================================
  Coverage   70.39%   70.39%
=======================================
  Files         208      208
  Lines       10493    10493
=======================================
  Hits         7387     7387
  Misses       3106     3106

Impacted Files
Coverage Δ

...ckages/core/src/renderTexture/RenderTexturePool.js
44.82% <ø> (ø)
:arrow_up:

packages/core/src/filters/FilterSystem.js
19.04% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Good one.
I suggest to add resolution: 1 here: https://github.com/pixijs/pixi.js/blob/dev/packages/core/src/renderTexture/RenderTexturePool.js#L46
That's real bug, I forgot that we have default resolution.

I like it that you figured everything out. Now I know who to ask to test my changes in FilterSystem's,

I wouldn't go that far ;) But glad to work out the issue!
The 2 options are to have it as an option passed through as in this pr, or hardcode it at the point you suggest. The one I went for had less changes, but putting it as you suggest means it becomes more of a default setting that could still be overridden by the settings. But is a better default than what it does now.
Don't mind changing it over; you've already approved @bigtimebuddy so happy for me to change over the style?

Its hardcode because we need default implementation of that thing do not depend on resolution. Params are named realWidth and realHeight , that functions shouldn't create textures with res=2 by default!

Can you also remove resolution from that doc? I believe that not everything that can be passed should be documented here. resolution will work wrong way.
Its better if I add doc for Type.


Nuxt Bridge breaks on the client side

Environment

Operating System: Darwin
Node Version:     v16.14.2
Nuxt Version:     2.16.0-27616340.013f051b
Nuxt Bridge Version: 3.0.0-27690335.da95eff
Package Manager<EMAIL_ADDRESS>Builder:          webpack

Reproduction
https://codesandbox.io/s/infallible-shamir-2gdft8?file=/pages/index.vue:18-29
Describe the bug
Looks like Nuxt Bridge doesn't run any client side hooks. For example, mounted hook in the reproduction should show "test" in the console. It doesn't show it for Nuxt Bridge , but works fine for Nuxt 3.

It looks like JS even doesn't load to client side

Operating System: Darwin
Node Version:     v18.6.0
Nuxt Version:     2.16.0-27616340.013f051b
Package Manager<EMAIL_ADDRESS>Builder:          webpack


Update Get-PARServer

Corrected property name in output & description in help text.

Codecov Report

Merging #9 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master     #9   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          16     16
  Lines         257    257
=====================================
  Hits          257    257

Continue to review full report at Codecov.

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


[occm] service account cloud-controller-manager cannot patch service object

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
What happened:
Installed the OCCM helm chart and wanted to provision an Octavia load  balancer (via the haproxy-ingress helm chart) but it's stuck in pending.
The error is:
Error syncing load balancer: failed to ensure load balancer: failed to patch service object haproxy-ingress/haproxy-ingress: services "haproxy-ingress" is forbidden: User "system:serviceaccount:kube-system:cloud-controller-manager" cannot patch resource "services" in API group "" in the namespace "haproxy-ingress"

Probably related: #1722
What you expected to happen:
A load balancer.
How to reproduce it:
Install the helm chart: openstack-cloud-controller-manager, version: 2.28.0
Anything else we need to know?:
The helm chart creates a SA which is also used by the openstack-cloud-controller pod. This SA seems to have the correct CRB as far as I can tell.
When the pod starts, I see another SA created, cloud-controller-manager. This SA has no CRB to be able to patch the service object. I am not sure why this is created or when. It doesn't seem to come with the helm chart (see below) and I am not creating it anywhere else as far as I see.
Somewhat a side effect, the created SA (cloud-controller-manager) also blocks helm from doing updates to the OCCM:

UPGRADE FAILED: rendered manifests contain a resource that already exists. Unable to continue with update: ServiceAccount "cloud-controller-manager" in namespace "kube-system" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "openstack-cloud-controller-manager"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"

This should have been fixed in https://github.com/kubernetes/cloud-provider-openstack/pull/2332. The fix is, however, not yet in a stable release, but you can install a pre-release version with:
helm upgrade -n kube-system -i openstack-ccm cpo/openstack-cloud-controller-manager --version 2.29.0-alpha.2 --values openstack-ccm-values.yaml

@wwentland I'll give it a try. Is there a way to see all chart releases and changelogs somewhere? I searched with helm, it looks like what I installed was the latest available.

@wwentland I'll give it a try. Is there a way to see all chart releases and changelogs somewhere? I searched with helm, it looks like what I installed was the latest available.

That version is a pre-release and helm would not install it by default. I'm currently trying to get those changes backported, but for the time being you would have to specify the version explicitly.
Please note that you might have to delete the cloud-controller-manager service account in the kube-system namespace if it exists, as upgrading with helm would fail otherwise.
All releases can be found on https://github.com/kubernetes/cloud-provider-openstack/releases

All releases can be found on https://github.com/kubernetes/cloud-provider-openstack/releases

So it seems like the actual OCCM 1.28.0 has a changelog there, but none of the other releases tell me much about what's going on. As in, is it safe to run the alphas for production?
Or can I mix the alpha helm chart with a (maybe) more stable 1.28.x of the OCCM?
Sorry for asking so many question.

I don't see other tags with helm search either. That's what I was curious about.

You can include pre-releases by passing the --devel option to Helm similar to:
❯ helm search repo cloud-controller-manager --devel
NAME                                  	CHART VERSION 	APP VERSION	DESCRIPTION
cpo/openstack-cloud-controller-manager	2.29.0-alpha.3	v1.28.0    	Openstack Cloud Controller Manager Helm Chart

So it seems like the actual OCCM 1.28.0 has a changelog there, but none of the other releases tell me much about what's going on. As in, is it safe to run the alphas for production?

I would advise against running alpha/pre-releases in production, but it is important to keep in mind that this is primarily about the helm chart itself.
I'll see if we can get those helm chart changes backported, which should alleviate that concern.

Is there anything I can do to help?
Is there a way to review the changes to the helm chart. As in, to figure out how far away it is from a stable release?

@wwentland what needs to happen for the releases? The latest is still 2.28.0. Was looking for a bump.

@wwentland what needs to happen for the releases? The latest is still 2.28.0. Was looking for a bump.

It looks fine here:
❯ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "cpo" chart repository

❯ helm search repo openstack-cloud-controller-manager
NAME                                  	CHART VERSION	APP VERSION	DESCRIPTION
cpo/openstack-cloud-controller-manager	2.28.2       	v1.28.1    	Openstack Cloud Controller Manager Helm Chart

Which is https://github.com/kubernetes/cloud-provider-openstack/releases/tag/openstack-cloud-controller-manager-2.28.2 and what you want.

@till I was wondering if you were able to get it to work with the new version? If so, we should probably close this issue.

Agree! Been meaning to, but Monday. I'll update by tomorrow.

Sorry, took longer than expected. All seems to be working now! Thanks @wwentland

Amazing! Thank you for the follow-up, @till


Feature: Make script versions available through the API

Description
Currently it's possible to see all the scripts via the Django API at botcscripts.com/api/scripts, but I can't find any method to see which versions of a given script are available.
It would be nice with a /versions endpoint or similar so it's easy to programmatically determine which versions exist for a given script.
Additional context
I'm trying to make a generic API for blood on the Clocktower data that is always up to date with the latest characters, announcements and custom scripts.

Thanks for the request, trying to understand the use case a bit more and propose some ideas. Firstly, some background:
The site splits scripts into 2 separate object types, one being the ScriptVersion objects, which is actually what you'd recognise as a script, a JSON file with a set of characters with some metadata attached (including the version of this script iteration). These are collected into Script objects, which is basically a ManyToMany field of ScriptVersions to collect the history of a script. The only identifying field of that is the script name and then the ScriptVersion keys for that script.
The /scripts endpoint is actually the set of ScriptVersion objects that exist in the database.  I don't think it makes much sense to expose that ForeignKey over the API since it's not meaningful to the user and they can't use the key for anything else (since it is a separate key from the ScriptVersion primary key).
I don't however want to expose Script objects over the API for a couple of reasons

It would be a naming nightmare. It would probably end with /script and /scripts which is just eww all over.
They're not really useful from a user perspective.

I think this means a /versions endpoint is out since architecturally, it's only relevant to Script objects and they're not objects presented over the API.
At the moment, you can query the API with the search parameter which will find the closest named script. If you include the all_scripts=on parameter then you'll get all versions so the top results should be the closest match to the search result.
This could be a slightly nicer user experience in allowing you to filter by name (which would then return all the exact name matches).
Is the search function sufficient or is adding the name field for an exact match a requirement?

Thanks for the timely and considered response. 👍
I wasn't aware of the ability to query the api directly and get a json response. If searching by name and getting all versions back in json format is an option then that is all I need. Is this documented anywhere? Which parameters are available etc? I only found out about the API endpoint at all by looking at the source code.


 This was frustrating because I should have immediately gotten a red squiggly line in VSCode to tell me that I messed up. But no red squiggly lines appeared because by default, the schema allows any arbitrary additional properties that you put in there. Frankly, I find this behavior terrible, so I made my own custom schema that is stricter.
Now, when using this schema, I properly get red squiggly lines. However, this partially solves the problem: what if I forget to put the "$schema" in a new "tsconfig.json" file? So, I realized that I need a lint rule in my standard TypeScript linting config that automatically validates that every "tsconfig.json" file has a "$schema" field.
Scope of eslint-plugin-package-json
Does it make sense to expand the scope of this plugin to also include "tsconfig.json" files? Or should this rule belong in a separate project?

Great question. I think TSConfig linting should belong in its own project for now. This one is pretty single-purpose and doesn't yet have all the rules needed for that purpose (#42).

I believe https://github.com/ota-meshi/eslint-plugin-json-schema-validator is the correct tool for this case.


Cross compile from alpine to openbsd: cannot use _Ctype_size_t(len(b)) (value of type _Ctype_ulong) as _Ctype_uint value in argument to (_C2func_getnameinfo)

Go version
go version go1.22.4 linux/amd64
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/me/.cache/go-build'
GOENV='/home/me/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/mccd/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/mccd/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/lib/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.4'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/mccd/builds/sustainably-go/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2635966091=/tmp/go-build -gno-record-gcc-switches'

What did you do?
To cross compile a static binary for OpenBSD when running on Alpine linux, I ran the following
CGO_ENABLED=1 GOOS=openbsd CC=/usr/bin/x86_64-alpine-linux-musl-gcc go build --ldflags '-linkmode external -extldflags -static' .

Cgo was a necessity because of my use of go-sqlite3
What did you see happen?
# net
/usr/lib/go/src/net/cgo_resold.go:20:76: cannot use _Ctype_size_t(len(b)) (value of type _Ctype_ulong) as _Ctype_uint value in argument to (_C2func_getnameinfo)

I got the following error
What did you expect to see?
I expected it to compile without error

Similar Issues

cmd/go: problems with cgo_resnew when cross-compiling on freebsd for linux #66839
cmd/go: build constraints sometimes ineffective for net/cgo_resnew.go on FreeBSD #33101
CGo-enabled cross compilation (amd64 -> arm64) failed #39615
cmd/go: document system setup for cross compiling between linux architectures #47175
internal compiler error: bad type for ... argument: [2]string #45913
cmd/cgo: Wrong types in compiler errors with clang 14 #53013
cmd/cgo: cannot convert from signed char *_Ctype_schar to char *_Ctype_char  #26655
cmd/cgo: When building cgo, I get an error 'could not determine kind of name for var' #23819
cross compiling issue #66642
x/pkgsite: cannot build golang1.9 on centos6 with lib2.10 #59328

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

When you are cross-compiling from Linux to OpenBSD, you must set CC to a C cross-compiler from Linux to OpenBSD.  That C cross-compiler must read the OpenBSD header files, not the Linux ones.


MaxWavesPerSimd in ihipOccupancyMaxActiveBlocksPerMultiprocessor() is not consistent with rocminfo

Here, the MaxWavesPerSimd is set to 8.
https://github.com/ROCm-Developer-Tools/HIP/blob/bc102bb6dbbc7b94218a73e14f6ca9de198069e9/rocclr/hip_platform.cpp#L323
But in rocminfo:
*******
Agent 2
*******
  Name:                    gfx906
  Uuid:                    GPU-19a8190172e626c2
  Marketing Name:          Vega 20
  Vendor Name:             AMD
  Feature:                 KERNEL_DISPATCH
  Profile:                 BASE_PROFILE
  Float Round Mode:        NEAR
  Max Queue Number:        128(0x80)
  Queue Min Size:          4096(0x1000)
  Queue Max Size:          131072(0x20000)
  Queue Type:              MULTI
  Node:                    1
  Device Type:             GPU
  Cache Info:
    L1:                      16(0x10) KB
  Chip ID:                 26273(0x66a1)
  Cacheline Size:          64(0x40)
  Max Clock Freq. (MHz):   1725
  BDFID:                   768
  Internal Node ID:        1
  Compute Unit:            60
  SIMDs per CU:            4
  Shader Engines:          4
  Shader Arrs. per Eng.:   1
  WatchPts on Addr. Ranges:4
  Features:                KERNEL_DISPATCH
  Fast F16 Operation:      FALSE
  Wavefront Size:          64(0x40)
  Workgroup Max Size:      1024(0x400)
  Workgroup Max Size per Dimension:
    x                        1024(0x400)
    y                        1024(0x400)
    z                        1024(0x400)
  Max Waves Per CU:        40(0x28)
  Max Work-item Per CU:    2560(0xa00)
  Grid Max Size:<PHONE_NUMBER>(0xffffffff)
  Grid Max Size per Dimension:
    x<PHONE_NUMBER>(0xffffffff)
    y<PHONE_NUMBER>(0xffffffff)
    z<PHONE_NUMBER>(0xffffffff)
  Max fbarriers/Workgrp:   32
  Pool Info:
    Pool 1
      Segment:                 GLOBAL; FLAGS: COARSE GRAINED
      Size:                    16760832(0xffc000) KB
      Allocatable:             TRUE
      Alloc Granule:           4KB
      Alloc Alignment:         4KB
      Accessible by all:       FALSE
    Pool 2
      Segment:                 GROUP
      Size:                    64(0x40) KB
      Allocatable:             FALSE
      Alloc Granule:           0KB
      Alloc Alignment:         0KB
      Accessible by all:       FALSE
  ISA Info:
    ISA 1
      Name:                    amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-
      Machine Models:          HSA_MACHINE_MODEL_LARGE
      Profiles:                HSA_PROFILE_BASE
      Default Rounding Mode:   NEAR
      Default Rounding Mode:   NEAR
      Fast f16:                TRUE
      Workgroup Max Size:      1024(0x400)
      Workgroup Max Size per Dimension:
        x                        1024(0x400)
        y                        1024(0x400)
        z                        1024(0x400)
      Grid Max Size:<PHONE_NUMBER>(0xffffffff)
      Grid Max Size per Dimension:
        x<PHONE_NUMBER>(0xffffffff)
        y<PHONE_NUMBER>(0xffffffff)
        z<PHONE_NUMBER>(0xffffffff)
      FBarrier Max Size:       32
*** Done ***

 SIMDs per CU is 4  and Max Waves Per CU is 40, which means MaxWavesPerSimd should be 10?
Which one is right?

@francis0407, Sorry for the lack of response. Do you still need assistance with this issue?


posix: Kconfig: Redefine CONFIG_POSIX_API as a convenience masterswitch

It enables individual POSIX components, and sets up environment
suitable to easily port POSIX applications to Zephyr. However, allow
to enable individual components (e.g., only Pthreads) without it.
Fixes: #12965
Signed-off-by: Paul Sokolovsky<EMAIL_ADDRESS>

For context this patch (or similar functionality) is now required e.g. to get cc3220sf_launchxl working, see https://github.com/zephyrproject-rtos/zephyr/pull/18736#issuecomment-526314295.
@vanti: Please give this a try, remove select POSIX_API from Kconfig.simplelink, and see if select PTHREAD_IPC will still have effect (our aim is to make it so). You may need to adjust include paths, etc.

I changed the milestone to 2.0 in hope that we can get this in, so that http_get doesn't stay broken for cc3220sf_launchxl due to #18736 which was recently merged.

@vanti

I changed the milestone to 2.0 in hope that we can get this in for the release

I'm happy to try ;-).

that require this line to be added to lib/CMakeLists.txt:
add_subdirectory_ifdef(CONFIG_PTHREAD_IPC posix)

I'm not sure if that may raise questions why the same dir is added by 2 config options to the build list. And it's definitely just a workaround for Pthreads, somebody may want to enable just FS, mqueue, etc.

@vanti: As an update: I of course hoped to post cheerful "i fixed it!" much earlier, but instead fighting whole day with the usual suspects: ARCH_POSIX and posix vs newlib headers conflicts. This last build finally seems to be going over the summit, keeping fingers crossed. I'll check it later anyway.
If you'd target this for 2.0, probably add Priority: high, and look for someone else to approve it (2 votes required) ;-). Let me also know if you think it would be helpful to merge https://github.com/zephyrproject-rtos/zephyr/pull/18810 into this one (usually it's not a good idea, but otherwise, I guess it would be easier to get 1 PR into the release than 2.)

Ok, indeed it passed. Squashing what's possible together...

So, I actually included https://github.com/zephyrproject-rtos/zephyr/pull/18810 here. And bad news is:
/opt/sdk/zephyr-sdk-0.10.3/arm-zephyr-eabi/arm-zephyr-eabi/sys-include/sys/timespec.h:58:8: error: redefinition of 'struct itimerspec'
 struct itimerspec {
        ^~~~~~~~~~
In file included from ../../../../../../include/posix/pthread.h:12,
                 from /home/buildslave/src/github.com/zephyrproject-rtos/zephyr/lib/posix/pthread_cond.c:10:
../../../../../../include/posix/time.h:58:8: note: originally defined here
 struct itimerspec {

So, there's always something else around the corner to fix in the POSIX subsys... And I've seen the issue above, it's actually why samples/net/sockets/echo_async_select wasn't included in https://github.com/zephyrproject-rtos/zephyr/pull/18736, because it exposed it, and I didn't want to risk putting off PR with big'ish patches. I believe I have a fix now, but it needs to be CIed, and it all bloats the scope of what was supposed to be a simple change.

I believe I have a fix now

And still there was following:
/home/pfalcon/opt/zephyr-sdk-0.10.3-pr-101/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/../../../../arm-zephyr-eabi/bin/ld: ../modules/ti/simplelink/lib..__modules__hal__ti__simplelink.a(device.c.obj): in function `sl_Stop':
/home/pfalcon/projects-3rdparty/Embedded/Zephyr/modules/hal/ti/simplelink/source/ti/drivers/net/wifi/source/device.c:353: undefined reference to `usleep'
/home/pfalcon/opt/zephyr-sdk-0.10.3-pr-101/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/../../../../arm-zephyr-eabi/bin/ld: ../modules/ti/simplelink/lib..__modules__hal__ti__simplelink.a(cc_pal.c.obj): in function `Semaphore_pend_handle':
/home/pfalcon/projects-3rdparty/Embedded/Zephyr/modules/hal/ti/simplelink/source/ti/drivers/net/wifi/porting/cc_pal.c:414: undefined reference to `clock_gettime'
collect2: error: ld returned 1 exit status

Which I'm fixing by introducing CONFIG_POSIX_CLOCK (which I squash into the very first commit). With that and corresponding update to https://github.com/zephyrproject-rtos/zephyr/pull/18810 (which is again, included here, squashed), cc3220sf_launchxl samples finally build for me.

Ok, this is finally green.

@pabigot

newlib presumably is re-using <sys/timespec.h> in POSIX configurations, but fundamentally it is a BSD header: POSIX doesn't describe it.

Nobody says it does.

I'm not really happy about making minimal libc follow that practice by adding another non-private header that somebody might start including.

I'm sorry, you're bit late with this. We already have established practice of resolving that kind of issue, used for a few headers already, and this patch just follows the practice.

Much of the complexity of the POSIX subsystem headers

I'm not sure what complexity you're talking about. In either case, it solved complexity. The real complexity comes when we're trying to make a revolution on empty grounds, e.g. throw away APIs which were there for years for no good reason. On this side, work is done along the way of establishing solutions for missing things (in sustainable, not revolutionary, manner).

If you don't really need that change in this PR in order to solve #12965 I'd rather it not be included.

I'm not sure what you mean. This PR doesn't contain unneeded changes (or I wouldn't make them). The changes in this PR follow the same pattern as in https://github.com/zephyrproject-rtos/zephyr/pull/16626. Kindly please get acquainted with it if you're interested in maintenance of of POSIX subsystem. (Short summary: try to make one-line change, and see cascade of failures. I'm firefighting since the beginning year to converge it to a stable state, and sparks of instability of still happen, as this PR shows. From that, you may imagine why I'm not exactly fancy suggestions of passers-by along the lines of  "just splash petroleum into it, it will surely put out fire!").

sigh.

The real complexity comes when we're trying to make a revolution on empty grounds, e.g. throw away APIs which were there for years for no good reason.

There's a very good reason: a large number of Zephyr target applications have no need for POSIX APIs.
You do, and that's fine.  My intent in #18892 is to simplify your task by suggesting a way to re-use the existing declarations from the underlying libc without having to jump through hoops trying to reconstruct what's already available (minimal libc by design excludes some features, but newlib does not).
I don't really care how you maintain the POSIX system, though the need for #17706 suggests there's a wider concern about it from a Zephyr project perspective.  I do care about libc.  If you need this hack to have something that works with both newlib and minimal libc go ahead--I'm not blocking this PR.
But if/when you get the POSIX subsystem include files a little less ad hoc the minimal libc declaration of interval timer data structures should move directly into <time.h> where it belongs.

sigh.

To not sigh in response, let me just ask a simple question: which was the last POSIX application you ported to Zephyr?

My intent in #18892 is to simplify your task by suggesting

Keeping up with simple questions: which POSIX applications have you tested it with? And may I immediately suggest that to be sure about it, it would be nice to test it with 10-20 more?

There's a very good reason: a large number of Zephyr target applications have no need for POSIX APIs.
If you need this hack

Here we again differ in our perception: I'm working on establishing best practices and interfaces/contracts on how to integrate different Zephyr subsystems (e.g. a libc (which we have multiple!) and POSIX subsys), and suspect your idea of being a premature optimization. While you suggest that the convention being established is a hack, and suggest that hammer you used elsewhere most definitely applies here too, because it all nails. Let the number of ported (and still working!) apps speak, that should be the best way to convince each other (well, me definitely).

But if/when you get the POSIX subsystem include files a little less ad hoc the minimal libc declaration of interval timer data structures should move directly into <time.h> where it belongs.

What you're suggesting is that minimal libc should be treated in adhoc way. What I'm suggesting that there should be conventions which libc's (any libc!) should follow to integrate with the rest of Zephyr (e.g. POSIX subsys) seamlessly. Indeed, let's see how it goes.

I'm not blocking this PR.

Most importantly, thanks for this. And what I'm trying to emphasize in my replies, that there should be more formal and general criteria for reviewing patches than "I like/don't like".

@nashif

agree with @pabigot

Agree with what exactly? As my notifications show, ten minutes before posting this comment, you have posted following comment on the factored-out issue, #18892: "while include_next was used for posix subsys already, I think we should avoid it.". So, in fact, you do not agree with @pabigot. Unless you kindly tell exactly what you agree with (this and other times, thanks in advance!).

It is not late and it is definitely not an established practice.

This pattern is used 3rd time (and yes, it's not supposed to be used too often, only exactly when needed and not a single case beyond that, which are few).

just because you managed to introduce a bug does not mean it should be seen as an established practice.

Excuse me? What are you talking about, can you kindly elaborate again? If I introduced a bug somewhere, please open a separate ticket with relevant details, we'll get it triaged and fixed. This particular PR fixes a bug, using the same pattern as used a few times before. And no bugs are known to be introduced, unless you can pinpoint the exact location (please use inline code comments). Thanks!

@pfalcon @nashif @pabigot I understand there is some disagreement in terms of the direction where we wish to take minimal libc. Is this something that can be hashed out separately as @pabigot suggested? A sample on cc3220sf_launchxl is broken due to the changes from #18736, and it'd be good to at least fix that by merging this PR to unblock the end users. Fixing #12965 is also a good incremental improvement.

@vanti: I fully agree. And this PR fixes matters not only for cc3220sf_launchxl, careful reviewer of https://github.com/zephyrproject-rtos/zephyr/pull/18736 would not notice that I had to skip the echo_async_select sample, because it hit the very same issue fixed here.
Again, this PR does everything in the same way as was done a few times before - reviewed, discussed, approved. It fixes one more missed previously case. We need to merge it, enable missing CI cases, and with better CI coverage, process any further ideas.

Rebased and fixed conflicts otherwise. Re-requested review from @nashif .

Added to dev-review to discuss whether this can proceed despite a change request.


Uncaught TypeError: Cannot set property 'ss' of undefined ('strict mode')

Since 'strict mode' was added in 0.9.2, encountering the following running in the browser.  Here's the output from Chrome:
Uncaught TypeError: Cannot set property 'ss' of undefined [simple_statistics.js:21]
Possible resolution: Change self execution invocation (line 1574) from
})(this);

to
}).call(this);

Some additional information here:
http://stackoverflow.com/questions/13865607/why-do-you-need-to-pass-in-arguments-to-a-self-executing-function-in-javascript

Duplicate of #93


Add rake task to update list of regions

The original list of regions wasn't sorted so this diff looks worse than it is, here is the diff from the sorted list:
+sa-santiago-1:
+  :name: sa-santiago-1
+  :hostname: https://sa-santiago-1.oraclecloud.com
 sa-saopaulo-1:
   :name: sa-saopaulo-1
   :hostname: https://sa-saopaulo-1.oraclecloud.com
+sa-vinhedo-1:
+  :name: sa-vinhedo-1
+  :hostname: https://sa-vinhedo-1.oraclecloud.com
+uk-cardiff-1:
+  :name: uk-cardiff-1
+  :hostname: https://uk-cardiff-1.oraclecloud.com

Out of curiosity, where are these hostnames even used?  The URLs don't seem to be valid, and are built different from, say, get_service_endpoint:
[2] pry(main)> OCI::Regions.get_service_endpoint("ap-chiyoda-1", :IdentityClient)
=> "https://identity.ap-chiyoda-1.oraclecloud8.com"

Out of curiosity, where are these hostnames even used?

Most of the providers add one in, not sure where they are used or even if they are.

The URLs don't seem to be valid, and are built different from, say, get_service_endpoint:

Yeah OCI only provides an interface to get the endpoint for each service, not just the region.  I removed the hostname for now we can follow-up with other providers and see if they're used at all by any

This looks good to me.  I think as a follow up, what we might want to do is change the core method from_file to from_source.  Then, this method wouldn't have to override regions, but would instead override from_source with
      def self.from_source
        require "oci"
        OCI::Regions::REGION_ENUM
          .map      { |name| {:name => name} }
          .index_by { |r| r[:name] }
      end


(Operator): Update ffi_binding to check buffers

Draft pr updating the ffi bindings to handle zero size and null length inputs. @NicolasRampoldi @srosati The Halo2 bindings will need more work and updates within our fork.

This pr now addresses:

Addresses: out of bounds errors from audits
Refactors Halo2 ffi bindings
Updates the merkle_tree ffi test files
Adds ci test for merkle_tree


Cannot read property 'configure' of undefined

Browser: Chrome Version 56.0.2924.87 (64-bit)
OS: Windows 10 x64
Clappr Version: 0.2.65
Steps to reproduce:

copy the following code to demo page

var clapprPlayer = new Clappr.Player({});
clapprPlayer.configure({
  source: "http://example.com/live/livestream.m3u8",
  parentId: "#player",
  autoPlay: true,
});

click "run" button
console prints error:"Cannot read property 'configure' of undefined"

fixed:
var clapprPlayer = new Clappr.Player({});
**_clapprPlayer.attach("#player");_**
clapprPlayer.configure({
  source: "http://example.com/live/livestream.m3u8",
  autoPlay: true,
});


Data integrity is changed after manipulations by sct_qc routine

Version: SCT dfd51cd39921a592f062b326a1d680e43b8ca5e0
Data: sct_testing_data/t2
When running:
sct_get_centerline -i t2.nii.gz -c t2

I obtain a correct centerline, with only one pixel per axial slice. Example here for the most inferior slice:

Now, the problem is that, while working on https://github.com/neuropoly/spinalcordtoolbox/pull/2734, I was debugging sct_qc with sct_get_centerline option, and came across the fact that, when inputting the centerline as output by the command above, the routine that is supposed to find the centerline reports.slice._axial_center() finds two pixels in some slices, including the most inferior one:
data[0, 50, 40:45]
array([0, 1, 1, 0, 0])

There might be something going on, with the re-orientation of the data. Something to watch out for.

I might have found the culprit:
https://github.com/neuropoly/spinalcordtoolbox/blob/6888ea028159024d9a6f5f674463ab366825f880/spinalcordtoolbox/reports/slice.py#L58

Does _resample_slicewise write to disk or is that happening elsewhere?

it does not write to disk-- i generate the nifti file via the debugger (with a nibabel.save())

Ahh I misunderstood the title of the issue, I thought that the issue was that the QC was modifying the test data on disk. Instead this is a discrepancy between running manual and automatic QC of the result centerline.

@cfhammill sorry, my description of the issue was obscure. I've updated the title, and here are some clarifications: the problem is that the QC report does not provide an accurate representation of the results, because during the QC preparation routine (which involves image resampling), the true centerline is slightly displaced.

Closing this issue as a duplicate of https://github.com/spinalcordtoolbox/spinalcordtoolbox/issues/3625.
Both issues identify problematic resampling in the QC reports for single-voxel centerline images.


please ask some problem about result

I trained arah on my custom data; get follow result:

This is the visualization of sphere-tracing/joint-root-finding - for some rays, it might not be able to find intersecting surfaces, thus resulting in holes in visualization. For these rays, we switch back to uniform sampling on the ray, similar to neural body/animable-NeRF/etc.  You can set gen_cano_mesh=True here to enable marching cube extraction of meshes during validation - this will cost extra time though.

This is the visualization of sphere-tracing/joint-root-finding - for some rays, it might not be able to find intersecting surfaces, thus resulting in holes in visualization. For these rays, we switch back to uniform sampling on the ray, similar to neural body/animable-NeRF/etc. You can set gen_cano_mesh=True here to enable marching cube extraction of meshes during validation - this will cost extra time though.

thank you for your reply;i will try it

I set gen_cano_mesh=True in test.py,but  model_outputs['output_normal'] is saved full black image

This is the visualization of sphere-tracing/joint-root-finding - for some rays, it might not be able to find intersecting surfaces, thus resulting in holes in visualization. For these rays, we switch back to uniform sampling on the ray, similar to neural body/animable-NeRF/etc. You can set gen_cano_mesh=True here to enable marching cube extraction of meshes during validation - this will cost extra time though.

this results on test mode, not val mode

I set gen_cano_mesh=True in test.py,but model_outputs['output_normal'] is saved full black image

I have solved this problem by modifying img_size to myself data size


Prevent StackOverflowExceptions in DataTemplate instantation

Fixes #510, #524.

If you used a attached/styled property on the control and do a .ToList on the set of already materialized DataTemplates, then I think most of my perf/memory worries would be addressed.
However I'm still not convinced that adding this logic for an edge case is worth it... It's adding overhead based on the depth of the logical tree for every single DataTemplate instantiation to avoid an edge-case. Data template instantiations are very common and already a source of significant performance problems in Core2D that are going to need to be fixed...

Any more thoughts on this? Should I close? It's out of date after the rename anyway.

We can close this as long as we are still working on a resolution at least for the most basic manifestation (DataTemplate without a DataType). We need to prevent this for at least that case. The rest of the cases we can ignore (same as WPF)

Ok, will close. Yeah, I plan to fix the case of DataTemplate without DataType in a similar manner to WPF: add a template property to ContentControl and ItemsControl and only allow such templates to be placed in there, not in DataTemplates