Add support for serving precompressed .br and .gz files

It's a common practice to have static resources compressed with Gzip and/or Brotli and stored in the same directory with .gz/.br extensions respectively:

largetext.txt - uncompressed file
largetext.txt.gz - Gzip-compressed largetext.txt
largetext.txt.br - Brotli-compressed largetext.txt

When a client requests largetext.txt, server checks the Accept-Encoding header for supported compression methods:

if client supports Brotli, server responds with the contents of largetext.txt.br and header Content-Encoding: br
client supports Gzip - largetext.txt.gz and Content-Encoding: gzip
client supports neither - original largetext.txt

It would be great to have Simple Web Server support this scenario. And also to have one or two knobs in the options to switch these on and off to measure bandwidth in cases when different compression algorithms are used or no compression at all.

@ethanaobrien I think this would be really easy to implement. Just need to check the accept-encoding header and see if .gz or .br versions of the files exist. Do you think you could do it?
This would just be a single checkbox option that defaults to on.

And also to have one or two knobs in the options to switch these on and off

This would be easier to change/experiment with on the client side via the accept-encoding request header, no?

Just need to check the accept-encoding header and see if .gz or .br versions of the files exist. Do you think you could do it?

Yeah, this would be pretty easy. Just another option.

This would be easier to change/experiment with on the client side via the accept-encoding request header, no?

Well, possible - yes, easier - ah, wouldn't really say so😅
Usually a client is a browser, and these are not very friendly when it comes to exposing compression settings: they are buried deep down, have global scope and require manual editing of a text field. So, having simple switches in the UI at a touch of one's hand would be definitely more comfortable:relaxed:
But I realize that this is probably a niche request. So, maybe it's a good idea to settle for a single toggle for now:

[ ] Use Precompressed Files

And later, if you decide to add more compression options (e.g., on-the-fly compression with Gzip and Brotli, etc.), then incorporate more fine-grained control over precompressed files as well:
Gzip Compression

[ ] Use Precompressed .gz Files (if available)
[ ] Use On-The-Fly Compression
On-The-Fly Compression Level [1..9]
Caching Settings for On-The-Fly Compression:
...

Brotli Compression

[ ] Use Precompressed .br Files (if available)
[ ] Use On-The-Fly Compression
On-The-Fly Compression Level [1..11]
Caching Settings for On-The-Fly Compression:
...

e.g., on-the-fly compression with Gzip and Brotli, etc.

This is already implemented actually, but was deemed too slow for production

Well, possible - yes, easier - ah, wouldn't really say so😅 Usually a client is a browser, and these are not very friendly when it comes to exposing compression settings: they are buried deep down, have global scope and require manual editing of a text field. So, having simple switches in the UI at a touch of one's hand would be definitely more comfortable☺
But I realize that this is probably a niche request. So, maybe it's a good idea to settle for a single toggle for now:

I think it's too niche to add, and I think this option belongs on the client side anyway. I found a couple chrome extensions that allow you to modify http request headers here and here. I'm pretty sure Chrome just added a feature to override http response headers in DevTools, so it wouldn't surprise me if they added a similar feature for request headers in the future.

See this. Technically you can enable it in the config.json manually. It supports br, gzip, and deflate compression

It still works, right? I think I'll add it to the documentation (as a hidden option) just in case anyone still wants to use it.

Yeah, this would be pretty easy. Just another option.

Do you think you could add it? I suggest the option name be precompression.

It still works, right? I think I'll add it to the documentation (as a hidden option) just in case anyone still wants to use it.

I don't think I've changed anything that would've broken it.

Do you think you could add it? I suggest the option name be precompression.

Yeah, I can probably add this sometime next week.

Yeah, I can probably add this sometime next week.

Wonderful. We can release 1.2.9 with this and #147.

I think it's too niche to add, and I think this option belongs on the client side anyway. I found a couple chrome extensions that allow you to modify http request headers here and here.

Agreed, niche it is👐 Thanks for the browser extensions👍

@ethanaobrien Do you want to implement this soon? No pressure, just want to know if I should wait to release 1.2.9 so we can include this or not.

Sorry, been a little busy lately. I should be able to implement this before the next release.
What option name are we going to be using for this feature? Once I get that I'll get it implemented right away.

How about precompression?

Landed in 1.2.9.


A fix for the backslash bugs (plus front/... alias)

Once again for issue: https://github.com/michael-lazar/rtv/issues/17
Fixes everything in issue except for the multireddits.
As far as I can tell there are no more errors dealing with backslashes that won't be caught. Couldn't come up with anything anyways.
Also makes front into a sort of alias (where front/new goes to new)

Updated


Make sync API consistent: always (before, after)

Also update all call sites so that code behavior remains the same.
Fix #1293.

Whoops. Didn't see that #1267 hasn't been merged yet. Closing this one, as merging it before merging #1267 risks ending up with bugs as a result of merge resolution.


Cant move on with the challanges... may anybody help?

HI all,
I got stuck on setting the font size (font-size: 16px), I can see the font size change, so I believe I've put it in the right place... but when I press the run button nothing happens. I've tried changing my browser zoom to 100% && still nothing. can any one set me on the correct path? thanks in advance.
Challenge Change the Font Size of an Element has an issue.
User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393.
Please describe how to reproduce this issue, and include links to screenshots if possible.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/FreeCodeCamp/FreeCodeCamp/issues/12421#issuecomment-271100641,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AV2xQvKX590VKWLC1SoXeq63tfb1XgM2ks5rP9iHgaJpZM4LdfIH
.


[AIRFLOW-552] upgrade funcsigs to 1.0.2

Dear Airflow Maintainers,
Please accept this PR that addresses the following:

https://issues.apache.org/jira/browse/AIRFLOW-552

Testing Done:

Did not add tests because no functionality has changed. Existing tests should ensure that upgrade is successful

Current coverage is 65.96% (diff: 100%)

Merging #1826 into master will increase coverage by 0.05%

@@             master      #1826   diff @@
==========================================
  Files           127        127
  Lines          9674       9674
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           6376       6381     +5
+ Misses         3298       3293     -5
  Partials          0          0

Powered by Codecov. Last update 4d567f4...07fd4a3

Please make sure to add the jira issue to your commit message.

+1


When running on macOS via ramalama run we were throwing exceptions

Because in the "run" flow, generate isn't even a present argument
Summary by Sourcery
Bug Fixes:

Fix exception thrown on macOS when running via ramalama by checking for the presence of the 'generate' argument.

I think  #434 is a better solution.
We need a way to test run before opening PRs.


Installing 1.1.9 actually installs 1.1.7

Issue:
I downloaded the 1.1.9 setup ZIP and ran the EXE, but it only seems to install 1.1.7.
Even tried running 1.1.9 update and it doesn't install 1.1.9.
Expected Behavior:
I expect 1.1.9 to be installed.

uninstall nvm
erase C:\ProgramData
install again

I tried this and successed.

The download files contain 1.1.9, but your system may not be recognizing the change.
Uninstalling an old version prior to installing a new version will work.
You can also download the no-install zip file. Copy the elevate.cmd, elevate.vbs, install.cmd, and nvm.exe to the old directory.

There have been 100,000+ downloads since this issue was opened (with no other indicators that the wrong version is packaged). I do not think this is an issue with the download.

I just fresh installed nvm, used the 1.1.9 installer and when I ran nvm --version it has installed 0.33.2. Clearly I've done something wrong here?


fix: regression 23735

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/23735
$ https://github.com/Expensify/App/issues/24596
PROPOSAL:
Tests

Go to staging.new.expensify.com
Log in with account with many conversations
Copy link to any chat
Log out
Navigate to the copied link in Step 3
Log in
Right after the chat is loaded, return to LHN
The opened chat in Step 6 will appear in LHN while the rest of the chats is loading

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

Offline tests

QA Steps

Go to staging.new.expensify.com
Log in with account with many conversations
Copy link to any chat
Log out
Navigate to the copied link in Step 3
Log in
Right after the chat is loaded, return to LHN
The opened chat in Step 6 will appear in LHN while the rest of the chats is loading

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

PR Author Checklist

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Screenshots/Videos

Web
https://github.com/Expensify/App/assets/113963320/d97aeb8a-bb27-479f-b6e1-542cf88d2488

Mobile Web - Chrome

https://github.com/Expensify/App/assets/113963320/3247009a-ca18-4ebd-9a97-3dd6121ae33f

Mobile Web - Safari

https://github.com/Expensify/App/assets/113963320/d35db1be-5904-459b-aade-5435cceb2be9

Desktop

https://github.com/Expensify/App/assets/113963320/418caa10-ac94-47ad-8e57-f3a23b59a80d

iOS

https://github.com/Expensify/App/assets/113963320/25f37c45-a985-4580-bd19-4c9b2ce60de5

Android

https://github.com/Expensify/App/assets/113963320/0bc1bc53-9935-4e02-9cd0-9d69837ebb60

@tienifr I'm trying to reproduce but only successfully on ios/mWeb safari/web/mWeb chrome, I can't open the deep link on native android and desktop. What steps are to reproduce it on these platforms?

I see, from what I see it looks like firstLoadedReportID comes from getTopmostReportId, which takes reportID from params (URL). Could you investigate that? Is that value (firstLoadedReportID) changed?

I'm okay with both, if the value is the same let's stay with firstLoadedReportID.
Maybe not useRef as this is a class component, but it can be set in the constructor as an equivalent, @aldo-expensify any thoughts about the approach used to get the first value from firstLoadedReportID?

Maybe not useRef as this is a class component, but it can be set in the constructor as an equivalent, @aldo-expensify any thoughts about the approach used to get the first value from firstLoadedReportID?

From my understanding, the "equivalent" to useRef in class components would be to store it in this (instance of the component)

I'm okay with both, if the value is the same let's stay with firstLoadedReportID.

What do you mean with this? Are you saying we should revert to the implementation that was using a state?

Maybe not useRef as this is a class component, but it can be set in the constructor as an equivalent, @aldo-expensify any thoughts about the approach used to get the first value from firstLoadedReportID?

Not sure if it answers your question.... I understand that:

SidebarLinksData: wraps SidebarLinks and seems to be getting the data that we pass down to SidebarLinks. Considering that, it makes sense to me to put the logic of figuring out the firstAccessReportID here and pass the ID down to SidebarLinks. Then SidebarLinks doesn't need the HOC to get the currentReportID.
SidebarLinks: Just have to render based on what it got from the props, no responsibility on figuring out if it is the first reportID or not.

I'm fine with the implementation, but I think we should definitely add more comments so this doesn't get removed by mistakes. The code is not enough in this case to understand easily why things are implemented this way.

What do you mean with this? Are you saying we should revert to the implementation that was using a state?

I mean that both firstLoadedReportID and getTopmostReportId() give us the same report ID. So, either one works for what we're trying to do. If they're the same, let's just keep using firstLoadedReportID.

@tienifr I think we are going to go with this PR: https://github.com/Expensify/App/pull/25159#discussion_r1304929882, just letting you know so you hold on spending more time on this for now.


Add ability to specify the API on the command line

Our current workflows have the api endpoint url stored in Context["Execution"]["_manageiq_api_url"].
Before
There is no way to set the api url in exe/floe
After
./exe/floe --context '{"Execution": {"_manageiq_api_url": "http://localhost:3000"}}' workflow.asl "{}"

followup:

[ ] https://github.com/ManageIQ/manageiq-providers-workflows/pull/73

Comments
The input changes per workflow, so it makes sense to specify alongside the workflow in the ARGV.
The api endpoint url, on the other hand, is the same across all executions, so a single value make sense.

@kbrock the API passing is something specific to manageiq, could you just pass the execution as part of the context input that exists already?

context input that exists already?

Looks like we only accept --input on the command-line and build a context from that, I think if we also had a --context option you could do `floe --context '{"Execution": {"_manageiq_api_url": "http://localhost:3000"}} ...'

update:

setting context (allows a partial context)

🍏 , but code climate says this is more complex. Which it is.
But ensuring all these extra fields work.

I take code climate complexity with a grain of salt 😅

@kbrock can you just update the title and description to match what we ended up doing?


Import recommendations can lead to bloated bundle size (tslib)

Is your feature request related to a problem? Please describe.
In the usage docs, it says one should use imports like:
import useToggle from 'react-use/lib/useToggle'

or use babel to convert all import {...} to import ... from .../lib/...
This might be misleading advice for people using tree-shaking bundlers with ESM import like Webpack or frameworks leveraging bundlers like e.g. Next.js.
In this case, it will result in a bigger bundle size than just using import { useMount } from "react-use".
Why is that?

By using lib you are explicitly importing the CommonJS version of the file, not the ESModule-version, which generally prevents tree shaking on the consumer/bundler size! Normally the bundler will be able to detect the ESM version through module and main in package.json, but by using deep imports to lib this is prevented.
On top of that, by going through the Commonjs version explicitly, you also prevent tree shaking on tslib, which would normally work as described here: https://github.com/microsoft/TypeScript/issues/16999
While only 16 ESM-compiled hooks need tslib to work (mainly ES6+ downleveling-feature like __rest which is needed in useMap etc.) , 63 CommonJS-compiled hooks require tslib, because all of them need tslib.__importDefault to import from each other.

Here we import only three tiny hooks, but get a (comparatively) huge bundle, due to tslib.

Describe the solution you'd like

Change the docs to recommend import { useMount } from "react-use, if you use tree shaking, or use import useMount from "react-use/esm/useMount".
Explicitly warn against imports from lib, when using ESM/tree shaking ready bundlers.

Describe alternatives you've considered
I think importHelpers is generally a good thing, because repeating the TS downleveling helpers would bloat the bundle too. So removing that wouldn't be a viable alternative.

Hello, any updates on that? That would be good to have tree shaking

This library is abandoned and no longer maintained. It will not receive any updates at all, see here.
Checkout: @react-hookz/web


bugfix: ScrollController error because of scroll multiple elements

Multiple scroll elements were causing the ScrollController error  like
"The provided ScrollController is currently attached to more than one ScrollPosition"
https://stackoverflow.com/questions/71305700/flutter-web-showing-error-for-scrollposition/71305907#71305907
Check this for more details. Thank you

Thanks 🙏


fix(vite): hide source map from client

By user request, thanks @walber on discord for highlighting this
Before

After

After some research, I can see that Vite was configured to build the source map along with bundling, which is what "shows" the non-minified code on the frontend.
The source map is useful for dev but it's not a big deal because all of this code is client-side, and is completely open source on github, but definitely not best practice to show it.

Thank you


v1.0.0 Fails to compile C code

Error message is:
number of MIR_PHI operands is less 3

Input was attached file
mirbug.c.txt

Thank you for trying it.  I hope people will report more bugs for the new version.  Although I did a lot of testing, only a feedback from real MIR users  will help to create a robust release.  After gathering new bugs and fixing them, I can create v1.0.1 and probably remove the unstable release.
As for the test case.  I can not reproduce the error.  The information is not enough.  The file seems unfinished.  I tried to make it syntactically correct and add missed function  raviV_raise_error (I made it empty). Still I cannot reproduce it.
Could you provide me a standalone test and more info how to reproduce the bug.

Sorry for some reason the file is truncated?
I will post a complete version

For reasons I don't know, the redirection to a file is truncated.
Here is the actual code (please replace manually)
static int __ravifunc_1(lua_State *L) {
int raviX__error_code = 0;
int result = 0;
CallInfo *ci = L->ci;
LClosure *cl = clLvalue(ci->func);
TValue *k = cl->p->k;
StkId base = ci->u.l.base;
lua_Integer raviX__i_0 = 0, raviX__i_1 = 0;
TValue ival0; settt_(&ival0, LUA_TNUMINT);
TValue fval0; settt_(&fval0, LUA_TNUMFLT);
TValue bval0; settt_(&bval0, LUA_TBOOLEAN);
TValue ival1; settt_(&ival1, LUA_TNUMINT);
TValue fval1; settt_(&fval1, LUA_TNUMFLT);
TValue bval1; settt_(&bval1, LUA_TBOOLEAN);
TValue ival2; settt_(&ival2, LUA_TNUMINT);
TValue fval2; settt_(&fval2, LUA_TNUMFLT);
TValue bval2; settt_(&bval2, LUA_TBOOLEAN);
TValue nilval; setnilvalue(&nilval);
L0:
// MOVi {1 Kint(0)} {Tint(0)}
raviX__i_0 = 1;
// MOVi {2 Kint(1)} {Tint(1)}
raviX__i_1 = 2;
// MOV {Tint(0)} {T(0)}
{
 TValue *dst_reg = R(0);
 setivalue(dst_reg, raviX__i_0);
}
// CBR {T(0)} {L3, L2}
{
const TValue *src_reg = R(0);
if (!l_isfalse(src_reg)) goto L3;
else goto L2;
}
L1:
 return result;
Lraise_error:
 raviV_raise_error(L, raviX__error_code); /* does not return */
 return result;
L2:
// MOV {Tint(1)} {T(0)}
{
 TValue *dst_reg = R(0);
 setivalue(dst_reg, raviX__i_1);
}
// BR {L3}
goto L3;
L3:
// RET {T(0)} {L1}
{
 TValue *stackbase = ci->func;
 int wanted = ci->nresults;
 result = wanted == -1 ? 0 : 1;
 int available = 1;
 if (wanted == -1) wanted = available;
 int j = 0;
 if (0 < available) {
{
 const TValue *src_reg = R(0);
 TValue *dst_reg = S(0);
 dst_reg->tt_ = src_reg->tt_;
 dst_reg->value_.n = src_reg->value_.n;
}
 }
 j++;
 while (j < wanted) {
  setnilvalue(S(j));
  j++;
 }
 L->top = S(0) + wanted;
 L->ci = ci->previous;
}
goto L1;
}
EXPORT LClosure *__luachunk_0(lua_State *L) {
 LClosure *cl = luaF_newLclosure(L, 1);
 setclLvalue(L, L->top, cl);
 luaD_inctop(L);
 cl->p = luaF_newproto(L);
 Proto *f = cl->p;
 f->ravi_jit.jit_function = __ravifunc_1;
 f->ravi_jit.jit_status = RAVI_JIT_COMPILED;
 f->numparams = 0;
 f->is_vararg = 0;
 f->maxstacksize = 1;
 f->k = luaM_newvector(L, 0, TValue);
 f->sizek = 0;
 for (int i = 0; i < 0; i++)
  setnilvalue(&f->k[i]);
 f->upvalues = luaM_newvector(L, 1, Upvaldesc);
 f->sizeupvalues = 1;
 f->upvalues[0].instack = 1;
 f->upvalues[0].idx = 0;
 f->upvalues[0].name = NULL; // _ENV
 f->upvalues[0].usertype = NULL;
 f->upvalues[0].ravi_type = 128;
 return cl;
}

Thank you for trying it. I hope people will report more bugs for the new version. Although I did a lot of testing, only a feedback from real MIR users will help to create a robust release. After gathering new bugs and fixing them, I can create v1.0.1 and probably remove the unstable release.

I will run all the tests and report failures.
This one is good as it failed to compile.
Main Lua test crashed with an assertion - which may be harder to debug, as the failure occurred during execution.

I reproduced it and fixed it by b02f955c9d23170ea539d6e955ca4718f83d37ea.  The problem was in a pass doing bb clones.

Thank you - this has improved things a lot, but I have some tests that are failing at execution time, those are harder to debug.
I will open an issue once I can narrow it down.


Gateway: Package cleanup and improvement.

…packs.
:clipboard: Add associated issues, tickets, docs URL here.
Overview
Cleaning up unused commands and script from gateway package.json
Changes
Describe your changes and implementation choices. More details make PRs easier to review.

Cleanup, reorder scripts
Update sentry package
Removed react-env
added env SKIP_PREFLIGHT_CHECK=true to github workflow of test.
Included test:coverage.

Testing
Describe how to test your new feature/bug fix and if possible, a step by step guide on how to demo this.

Codecov Report
Patch coverage has no change and project coverage change: -0.43 :warning:

Comparison is base (dcf9b7e) 52.25% compared to head (c57d8f7) 51.83%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #783      +/-   ##
===========================================
- Coverage    52.25%   51.83%   -0.43%
===========================================
  Files          170      197      +27
  Lines         7687     7991     +304
  Branches      1576     1650      +74
===========================================
+ Hits          4017     4142     +125
- Misses        3670     3849     +179

Flag
Coverage Δ

coverage
51.83% <ø> (-0.43%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 27 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Mass Email

Is your feature request related to a problem? Please describe.
No
Describe the solution you'd like
As an admin, I would like the ability to mass email my users (one-off sends).  For example, if I need to tell them of a new feature I added to be able to request movies and TV shows. ;-)  Different from welcome emails.
Describe alternatives you've considered
Ombi (what I use now)

Yep! I would LOVE the ability to send emails to my users. I recently did a server upgrade and had to take Plex offline for a bit and it would have been nice if I could send them a quick email with a downtime notice.


Integrate previous work done on a previous repo

This big PR (sorry about that) integrates a work that has been conducted on another repo.
It includes

first importation of code from a private repo
some cleaning
including tests
making tests work
adding examples
adding a github workflow to launch tests at each push
adding pre-commit hooks to integrate linters

The workflow is not yet launched for PR (this is done in this PR and will be operational for further PRs). But you can see the result of the workflow on my fork here (it is currently still running).

All green!


[5.9] Fix CMake build to explicitly pick up ar and ranlib from toolchain.

CMake under various conditions will attempt to use llvm-ar and llvm-ranlib when it spots that we're building using clang, and while that works fine on Linux, it doesn't work so well on Darwin, leaving us with a link failure with a perplexing error message.
The rest of the Swift build is resilient to this problem already, but the bootstrap script here doesn't pass the relevant options to CMake, so it's possible to end up with the build failing when trying to link lib/libCYaml.a after the build has mangled the static library with llvm-ranlib.
rdar://112478653

This is a cherry pick of #6721.

@swift-ci please smoke test

@swift-ci clean test windows


Add Regex Checking on Tags

This change adds a method of checking tags on a regex to ensure that arbitrary tags do not kick off a release to PYPI

@eliatcodecov is this going anywhere?


[Help] How do you write acceptance tests?

Just wondering how you'd go about writing acceptance tests / end to end tests with these templates? Specifically, the Angular + .NET Core template - I've attempted to run Kestrel via IWebHost in acceptance tests using a .dll and then run Selenium, but couldn't get this to work and it seems quite messy.
Apologies if this has been answered elsewhere.

Selenium is definitely one way to go, and we use it as well to test the templates here.
Beyond that, we suggest posting your questions to StackOverflow using the asp.net-core tag to get broader views from the community. Thanks!


Can i custom define the scan area?

i will want to draw a rectangle, a area of rectangle for scan qrcode.
i read the API, but look like have not resolve function.

A PR is on the way. Still has some issues.
https://github.com/lwansbrough/react-native-camera/pull/874


v-copy directive does not seems to work on nuxt/vuetify

Does anybody manage to get it to work on nuxt/vuetify? Below is a sample code, which does not work in my case.
<v-btn v-copy="`Text copied`" outlined>
    <v-icon left>mdi-content-copy</v-icon>
    Copy
</v-btn>

This is interesting. I'm taking a look into it now. In the meantime, you can try https://github.com/egoist/v-copy and see if that works. I'll update when I know more.

I don't know if this bug was fixed, but it works fine with me now, are you sure you added the directive.
import { copy } from "vuetensils";
Vue.directive("copy", copy);

@mahmoudyusof I did add the directive as per what you suggest, and it doesn't seem to work on nuxt/vuetify2.

@mahmoudyusof thanks for chiming in on this. I'm glad it's working as intended for you. However, I confirmed the issue that @andrewspy described. Still not sure what is causing it, but there is a conflict on how things work with Vuetify. I hope to find a solution, but have not isolated the problem yet. Sorry @andrewspy  :/

Good news @andrewspy. I had some time to look into this tonight and may have found the issue. I got the code working with Vuetify and a local version of Vuetensils. Just pushed up the latest release v0.4.4 with the fix. If you could give that a shot and let me know, that would be swell.

@Stegosource I have updated to latest release v0.4.4 and everything is working as expected now! Thanks!

Woot!
Sorry for the delay.


Downloading from Musicbed.com doesn't work

Downloading from SoundCloud works in proper way.

So the reason why it doesn't work now is because they force redirect logged user to profile completion page.
In order for it to go away one has to complete his profile. I have no idea of other ways to make it go away.
I completed 2 profiles we use in SoundScrape by default, so the error should not exist for them.
As for custom profiles - I'm making a small PR to notify user that he should complete his profile in case it's not completed.

It seems that it doesn't work again. Or this problem appears only to me?

Works fine here.

Downloading from Musicbed.com doesn't work again. Could you update the script?

Even if I fix it, I doubt PR will make it through...

Thank! I hope that you will fix this.

for example, not all the Hammock's tracks are available for download on the Bandcamp, while on Musicbed are available

While MusicBed support is in there, it's very experimental and dependent on scraping. As with some other services, this code will likely get pulled if it's not working.


Errors logged with .notify are not logged to the console

When I'm developing an application I log some errors manually with .notify and I expect those not just to be sent to bugsnag but also to appear on my console so I can fix them.
Expected behavior
To see errors logged to console.
Observed behavior
Error is sent directly to bugsnag without logging it to the console.
Steps to reproduce
bugsnagClient.notify(new Error('I will not appear on the console :)')

Hi @gaastonsr, it's possible to do this yourself with a wrapper function like so:
function reportError(err) {
  bugsnagClient.notify(err)
  if (IS_DEV_ENV) console.error(err)
}

And replace all of your calls to bugsnagClient.notify(err) with reportError(err).
Meanwhile I've added a note to discuss internally if this is something our notifiers should do by default.
Cheers

That's simple and effective approach, I'll take it :)
Thanks!


ARROW-13956: [C++] Add a RETURN_NOT_OK_ELSE_WITH_STATUS to support changing the Status

Signed-off-by: Junwang Zhao<EMAIL_ADDRESS>

Sorry for the delay. I'm closing as explained on the JIRA.


Update updates-operations.md

Added the final bullet in the document.  We want IT pros to keep QU and FU bundles in sync.

@robinharwood, @Xelu86
Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


Unity Webgl: Unityloader already exists

Hello!
I use UnityWebGL with Vue.
I have a wrapper component for it.
In mounted hook:
this.UnityContext = new UnityWebgl('#canvas', {
      loaderUrl: '/unity/test-customizer/BuildWA.loader.js',
      dataUrl: '/unity/test-customizer/BuildWA.data',
      frameworkUrl: '/unity/test-customizer/BuildWA.framework.js',
      codeUrl: '/unity/test-customizer/BuildWA.wasm',
   })

this.$once('hook:beforeDestroy', function () {
      console.log('hook:beforeDestroy');
      this.UnityContext.destroy()
      this.UnityContext = null
})

beforeDestroy hook works. But when I navigate between pages that use UnityWebGL I still have this warning:
Unity Webgl: Unityloader already exists

Could you please explain, what am I doing wrong?

@OctopussyO
Please show your code.

Thanks for your reply!


Outdated documentation

The framed mechanic only has 4 valid rotations documented: Valid rotations: NONE, CLOCKWISE, FLIPPED, COUNTER_CLOCKWISE
There are currently 8 functional values here: https://hub.spigotmc.org/javadocs/spigot/org/bukkit/Rotation.html
The 8 rotations do work as of denizen developmental snapshot 444.
The document ion for the rotations are just inaccurate.

Tried to do a thing on the thing. I may or may not have made a 'commit' for it. I can't really tell.

Duplicate of #1829


Add Zeal wallet

There are a few @ts-expect-error due to window.ethereum.isZeal not being declared yet in the wagmi version used. This has been fixed in wagmi - merged PR here: https://github.com/wagmi-dev/wagmi/pull/2973/files. We will be able to remove these in short order.

@masm Going forward, RainbowKit will adopt EIP-6963 for injected wallets and won't pull in new wallets to RainbowKit. It is recommended that you begin supporting this standard in your wallet via mipd. This will automatically be supported for dApps in an upcoming release of RainbowKit alongside Wagmi v2. You can test your wallet against a test dApp at eip6963.org in the meantime.

With the upgrade of wagmi, @ts-expect-error no longer required. Anything else preventing merge?

@masm Looking to get this merged. Can you share early access for me to QA? Signed up to the Typeform

@masm When testing, I am seeing an issue with the injection behavior. It is not detected at load-time, possibly because window.ethereum.isZeal is injected too slowly, or the provider is failing Wagmi's ready logic here: https://github.com/wagmi-dev/wagmi/blob/38306606d2fd72a4c6918323bf86a1afda348638/packages/connectors/src/injected.ts#L88

I'll proceed to merge, but note that this is currently not functional for end users on the wallet side


Not working on Colab

Should this be possible?
import graphlite as g
db = g.connect('graph.db', graphs=['knows'])

print(db)
with db.transaction():
  with open('connections.csv', newline='') as csvfile:
    reader = csv.DictReader(csvfile)
    for row in reader:
      f = row['\ufefffrom']
      t = row['to']
      print(f,"-->" , t, row['detail'] )
      db.store(g.V(f).knows(t))

I get ...
AttributeError                            Traceback (most recent call last)
<ipython-input-41-6bc10dc6ac5f> in <module>()
     11       print(f,"-->" , t, row['detail'] )
     12
---> 13       db.store(g.V(f).knows(t))
     14

AttributeError: 'Graph' object has no attribute 'store'

See: https://colab.research.google.com/drive/1Hf2JN6d4QVAD3GvqJ2HfjhVSg17KpQC-#scrollTo=2xwp9DDOvL13&uniqifier=1
Thank you

hi,
you have to use .store on the returned Transaction object, not the database:
with db.transaction() as t:
    # the rest of the stuff
    t.store(...)

hi,
you have to use .store on the returned Transaction object, not the database:
with db.transaction() as t:
    # the rest of the stuff
    t.store(...)

Fabulous.
Now if you could write a script to expose the Tories's  shameful corruption, that'd be great...
https://colab.research.google.com/drive/1Hf2JN6d4QVAD3GvqJ2HfjhVSg17KpQC-?usp=sharing

Fabulous.
Now if you could write a script to expose the Tories's  shameful corruption, that'd be great...
https://colab.research.google.com/drive/1Hf2JN6d4QVAD3GvqJ2HfjhVSg17KpQC-?usp=sharing

Thank you very much

Thank you very much


Add voltage wfuse-ust + renaming of FuseFi to voltage

Added the new wfuse-ust pool (Voltage, ex. FuseFi).
I also renamed the oracle ids of the existing voltage pools. The id's within the app will be adapted in a complementary pull request on the beefy-app.
If you want even deeper renaming including all the file names and other variables regarding FuseFi, please let me know. For now, I didn't want to interfere too much with the existing base.
Currently, only the vaultApr is calculated, while vaultApy is null. This is probably due to missing tradingApr data at the current stage of the pool (I am the only liquidity provider as of writing this PR)

As expected, the missing tradingApr was only a temporary issue and the data is now available.
I now included the second pool LUNA-UST in this PR as well.
FUSE-UST
Want: 0x53B1B8Fb8bE9aA94076e6B29fb9D08bd9ced2D30
RewardPool: 0xe39c87605FeE81b509034E408EC2D2cE592E8B33
LUNA-UST
Want: 0x44cB3a602AE57b60A5dc808a44544Ab9ec8dDB36
RewardPool: 0xE25d7A32903e29F5909d461cD89729aF6f2c9399


INDY-1211 Adds file structure to indy-sdk repo

Adds some of the file structure to the SDK repo. Also adds some rough
draft files of new documents.
Signed-off-by: TechWritingWhiz<EMAIL_ADDRESS>

Closing this PR. I screwed up again. :(


fix: get-schema experience

Do not stop if existing schema is invalid
Do not save an invalid schema

:tada: This PR is included in version 2.16.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


attempt to resolve #835

This attempts to resolve Issue #835.

Both separable and whole program compilation unit tests pass. @jlebar does this fix issue with clang? @jaredhoberock please merge if it's okay.

wfm!

I'm a little confused by the condition of the #if -- do these functions ever return anything other than NULL when the compiler is clang?

Nope, if compiler is clang the return is always NULL. Is this not the intention?

I was expecting the function to return NULL only if the compiler is clang and if the function is called from a __device__ function. In other words, in __host__ code, the clang and nvcc behavior of the function would be identical. Is there something that prevents this behavior?

@jaredhoberock Did you see the last two comments at the bottom of #835.  Would you prefer the guard I posted there?
#if !(defined(__clang__) && defined(__CUDA__)) && (!defined(__CUDA_ARCH__) || (defined(__CUDACC_RDC__) && __CUDA_ARCH__ >= 350))

nvcc doesn't support guarding __global__ functions with __CUDA_ARCH__  and it will result in UB. I suspect the same applies to clang: due to  __CUDA_ARCH__ guard the device compilation pass will not see specialisation code, and will not compile __global__ function (see repro below). @jlebar, can you confirm this?
As it seems the only remaining option is to either change function annotation, to __host__-only in the  clang mode, or permit clang to specialise __global__ function in the device code.
Here  is simple repro that fails with both clang and nvcc w/o -rdc=true:
$ cat test.cu
$ cat test.cu
#include <cstdio>
#include <cassert>

template<class T>
__global__ void kernel(T *ptr)
{
  *ptr = 42;
}

__host__ void foo(int *ptr)
{
#if !(defined(__clang__) && defined(__CUDA__)) && (!defined(__CUDA_ARCH__) || (defined(__CUDACC_RDC__) && __CUDA_ARCH__ >= 350))
  kernel<<<1,1>>>(ptr);
#endif
}

__global__ void set_value(int*ptr)
{
  *ptr = 128;
}

int main()
{
  int *ptr;
  cudaMalloc(&ptr, sizeof(int));
  set_value<<<1,1>>>(ptr);
  int val;
  cudaMemcpy(&val, ptr, sizeof(int), cudaMemcpyDeviceToHost);
  printf("val_init= %d\n", val);
  foo(ptr);
  cudaMemcpy(&val, ptr, sizeof(int), cudaMemcpyDeviceToHost);
  printf("val_after= %d\n", val);
}
$ nvcc test.cu -arch=sm_35 -rdc=true && ./a.out
val_init= 128
val_after= 42
$ nvcc test.cu -arch=sm_35  && ./a.out
val_init= 128
$ clang test.cu  -L/usr/local/cuda/lib64 -lcudart --cuda-gpu-arch=sm_35 && ./a.out
val_init= 128
val_after= 128

If guard is commented, the code works as expected.

Thanks for the explanation. Could we try the following:

for nvcc only, preserve the existing behavior for these functions
for clang only, return NULL in __device__ code, and return the address of the __global__ function in __host__ code
Add a comment to these two sites explaining what's going on here

Is all that doable?

for clang only, return NULL in device code, and return the address of the global function in host code

How do you see this implemented? It does not seem that we can use __CUDA_ARCH__ guard to decide whether to return NULL  or ptr to __global__ function in __host__ __device__ function.  Similarly to nvcc, in clang both __host__ and __device__ code-paths must take pointer of __global__ function for correct behaviour. @jlebar  can you confirm this?
I can only see an option to change function annotation. for clang only, annotate function as __host__ but for nvcc __host__ __device__. This can open, however, other can of worms in clang mode.

Similarly to nvcc, in clang both host and device code-paths must take pointer of global function for correct behaviour.

I see, thanks.

I can only see an option to change function annotation. for clang only, annotate function as host but for nvcc host device.

It seems like modulating the annotation based on the compiler is the best choice here because what we're trying to do cannot be done with __host__ __device__ functions in clang. Do we know what problems are introduced if we change the annotation to __host__ for clang only?

I don't have a handle on what problems this may introduce; worse clang is silent when a __host__ function is called from __host__ __device__ function so we have no visibility if something goes wrong.
We can surely change annotation to __host__ for clang-only, and __host__ __device__ otherwise, and if nothing breaks in clang we can stick with it.
Alternatively, we can annotate it as __host__ or __host__ __device__ depending whether compiler support dynamic parallelism.  But then we have to test Thrust with nvcc and silence all calling __host__ from __host__ __device__ function warnings.
I'd say, ideally, allow clang to take address of  a __global__ function in __device__ mode, which appears to be less invasive. This will maintain backward compatibility with nvcc. There could more codes in the wild that do tricks like that.

I agree it would be ideal if clang would allow taking the address of a __global__ function in __device__ code. Hopefully someday clang will enable that feature.
In the meantime, I suggest making these functions __host__-only for clang. That way, we can make Thrust work to the degree possible with present day clang, and it will preserve Thrust's existing behavior with nvcc. If some future clang enables taking the address of a __global__ function in __device__ code, we can eliminate this workaround.
So I think the remaining question is to figure out what problems are introduced if we make these functions __host__-only for clang only. Has anyone tested that option yet?

I agree it would be ideal if clang would allow taking the address of a global function in device code. Hopefully someday clang will enable that feature.

Clang used to be able to do this. It is seems to be a  recent change that broke this functionality. The repro above with removed guard compiles and runs fine with clang as of Jun 20. I understand it does not compile with clang trunk anymore.
@jlebar, can this change be reverted in clang?

worse clang is silent when a host function is called from host device function so we have no visibility if something goes wrong.

This is actually an intentional design decision, motivated in no small part by projects such as Thrust.
Essentially every large template-metaprogramming-based CUDA project we've looked at calls H or D from HD.  nvcc emits a warning, causing builds of e.g. eigen (and I believe, Thrust) to spew thousands of diagnostics.  Calling D or H from HD may be "not allowed" (as the warning says), and I sort of agree from a moral standpoint that the world might be better if it actually were not allowed, but everybody does it and relies on it working.
In clang, we allow HD to call H, but, when compiling for host, it is a compile error to cause an HD function that calls D to be codegen'ed.  Similarly, when compiling for device, it's a compile error to cause an HD function that calls H to be codegen'ed.
AFAICT, nvcc tries to do roughly the same thing, but it's pretty easy to come up with examples where it does the wrong thing.  For example, nvcc from cuda 8 does not emit an error on the following code:
template<typename T> __device__ T D() { return T(); }
template<typename T> __host__ __device__ T HD() { return D<T>(); }
void host() { HD<int>(); }

In contrast, clang correctly identifies that we're calling a device function from host code and spits out an error.

I'd say, ideally, allow clang to take address of a global function in device mode
@jlebar, can this change be reverted in clang?

We've discussed this at length in previous PRs.  Again: This was an intentional change, and at the moment I don't believe it's a bug.  Specifically, I don't believe it's sound to allow taking the address of a G function when compiling in a mode where nested kernel calls are not allowed.  This follows from the rule in C++ that you cannot take the address of a function you cannot call.  This is a good thing, because otherwise you'd be able to dereference the function pointer and call the thing that you're not supposed to call.
To use a CUDA-specific example, H functions cannot call D functions.  So H functions should not be able to take the address of D functions.  If this were allowed, then the H functions could dereference said function pointer and then "run" the D function.  I have no idea what that should do.
For the same reason, I don't believe that, when compiling in a mode where nested kernel invocations are disallowed, it makes sense to allow taking the address of a G function.

Thanks Justin for details. In this case I agree with Jared, the path of least resistance is to annotate functions with __host__ in clang-mode, and __host__ __device__ otherwise.

Just to confirm I understand it correctly: clang is not worried that it breaks compatibility with nvcc existing feature set, and which may break existing CUDA codes out there that take address of __global__  function in __device__ code.

Evghenii,
As someone who has worked for many months of my life on making a compiler that's compatible with nvcc, I assure you that I take this very seriously.  However, we occasionally have, after careful consideration, decided that clang should reject certain idioms that nvcc accepts.  In my last post to this thread, I gave an example of this.  There are plenty of others.  You have seen many of them go by in the PRs we've sent making Thrust compatible with clang.
We do not take the position that if nvcc accepts a block of code, clang has a bug if it rejects it.  Again, see the example in my previous post, where we believe that nvcc is wrong to accept the code I gave, and so we reject it.  One of the things users have told us that they like about clang is that it's stricter about some things at compile time -- this prevents them from shooting themselves in the foot.
As we've seen with Thrust, large projects often need some amount of porting in order to be compatible with clang.  In general, we've seen that this porting improves the overall quality of the project -- I hope that's the way you see the overall effect of the changes we've made to Thrust to make it compatible with clang.  To answer your question specifically, I am not worried about libraries that choose to support clang having to change code that uses this particular idiom, which I expect to be uncommon compared to the other issues they will have to address.
If it turns out that lots of user code relies on this particular idiom and it is a serious impediment to adoption of clang, I will be happy to revisit this decision.  I suspect that's not the case, but hey, I could be wrong.  We are still the new kid on the block.
Alternatively, I remain open to being convinced that clang is doing the wrong thing here -- but that argument needs to be made on the basis of the semantics of the CUDA language, not on the basis of what nvcc does.  So far, in the three threads where we have discussed this issue, nobody has attempted to explain why it is semantically correct to allow device code to take the address of a global function that it cannot call.  Nor has anyone attempted to explain what semantics this function pointer should have.

I don't have a strong opinion about whether or not it makes sense for a function to take the address of another function that it cannot call. I would note however that __host__ functions can take the address of __global__ functions, but they can't really call __global__ functions directly. The triple chevrons are really just some sugar wrapping something an API providing something similar to a remote procedure call. So, the function pointer has to be laundered through some other API to be usable, and you could imagine building something similar for __device__ functions. For example, a __device__ function could take the address of a __global__ function and communicate with some host thread set aside for launching kernels as directed by a CUDA thread.
What concerns me about the problem discussed in this thread is that there's apparently not a workaround based on __CUDA_ARCH__ to guard __host__ __device__ functions from doing illegal things. If unguarded __host__ __device__ functions aren't allowed to take the address of __global__ functions, that's fine. But it seems like it ought to be legal to do so if we guard on __CUDA_ARCH__ to ensure that it only occurs when executed in the __host__ part of the function.
Anyway, @andrewcorrigan: can you try implementing the workaround suggested here? If everyone agrees it works without introducing any problems, we'll be ready to merge.

@jaredhoberock Your wish is my command. Please see #841

I would note however that host functions can take the address of global functions, but
they can't really call global functions directly. The triple chevrons are really just some sugar
wrapping an API providing something similar to a remote procedure call.

Yes, this is a problem.  I think it would make sense to say that you can't take the address of a __global__ function, or alternatively, if we have to allow it, we could say that the fact that it's a kernel is part of the function's signature, such that it's illegal to call it without triple angle brackets.
Maybe that ship has sailed, but it's something I've thought some about.

For example, a device function could take the address of a global function and
communicate with some host thread set aside for launching kernels as directed by CUDA
threads.

I suppose...  You wouldn't actually be able to use this directly, though, because the address of the global function on the device isn't going to be the same as the address of said function on the host.  You'd have to maintain a mapping from device addresses to host addresses on the host, and at that point...use an enum?

If unguarded host device functions aren't allowed to take the address of global functions, that's fine. But it seems like it ought to be legal to do so if we guard on CUDA_ARCH to ensure that it only occurs when executed in the host part of the function.

So the canonical way of solving this in clang, I think, is to write a __host__ and a __device__ overload of the function in question.  That is, clang lets you do
int f() { return 0; }
__device__ int f() { return 1; }
__host__ __device__ int hd() { f(); }

This will return 0 in host mode and 1 in device mode.
If everything is templated nvcc may accept this, I am not sure.
If that doesn't work, you could try moving the reference to the kernel function into a __host__ function and calling that from your HD function.
__host__ kernel_f_ptr get_ptr_host() {
  return kernel<int>;
}

__host__ __device__ kernel_f_ptr get_ptr()
{

#if !defined(CUDA_ARCH)
return get_ptr_host();
#else
return NULL;
#endif
}
Problem is this doesn't work if get_ptr_host is itself a templated function that we don't observe being instantiated when we compile for device.

Here's a of the code above, if it helps.  This works fine in clang, because we see the kernel being instantiated in the free host function.  https://gist.github.com/3a3024946508d286f3af47e2705b651e

Code works with nvcc as well because kernel is instantiated in non-templated host function. It appears clang has the same behaviour as nvcc when it comes to guarding kernels instantiation with __CUDA_ARCH__. The big advantage of the clang is overload on __host__ and __device__ attribute, something that nvcc lack, and this allows to build a proper solution.
If I may suggest, can we change https://github.com/thrust/thrust/pull/841 to take advantage of this.
In a sense we can have the following
 __host__ __device__
static global_function_pointer_t global_function_pointer()
{
  return launch_by_value<block_size,Function>;
}

to
#if CLANG_DEVICE_COMPILER
 __host__
static global_function_pointer_t global_function_pointer()
{
  return launch_by_value<block_size,Function>;
}
__device__
static global_function_pointer_t global_function_pointer()
{
  return NULL;
}
#else
 __host__ __device__
static global_function_pointer_t global_function_pointer()
{
  return launch_by_value<block_size,Function>;
}
#endif

@egaburov   Looks like I read your mind.

Thanks for the reminder about overloading on __host__ and __device__. I agree that is the best way to handle this problem and it looks like @andrewcorrigan already has a proof of concept. If tests pass, then let's merge pull request #842.


Stevan

Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #232 (f6cbff1) into main (1770873) will decrease coverage by 0.38%.
The diff coverage is 22.38%.

@@             Coverage Diff              @@
##               main     #232      +/-   ##
============================================
- Coverage     38.97%   38.58%   -0.39%
- Complexity      892      898       +6
============================================
  Files           176      176
  Lines          6746     6902     +156
  Branches        823      846      +23
============================================
+ Hits           2629     2663      +34
- Misses         3876     3994     +118
- Partials        241      245       +4

Impacted Files
Coverage Δ

.../securityanalytics/action/GetDetectorResponse.java
20.00% <ø> (+0.55%)
:arrow_up:

...ecurityanalytics/action/IndexDetectorResponse.java
60.60% <ø> (+1.78%)
:arrow_up:

...analytics/resthandler/RestIndexDetectorAction.java
0.00% <0.00%> (ø)

...ytics/transport/TransportDeleteDetectorAction.java
0.00% <0.00%> (ø)

...analytics/transport/TransportDeleteRuleAction.java
0.00% <0.00%> (ø)

...yanalytics/transport/TransportGetAlertsAction.java
0.00% <ø> (ø)

...nalytics/transport/TransportGetFindingsAction.java
0.00% <ø> (ø)

...lytics/transport/TransportIndexDetectorAction.java
0.00% <0.00%> (ø)

...yanalytics/transport/TransportIndexRuleAction.java
0.00% <0.00%> (ø)

...earch/securityanalytics/util/RuleTopicIndices.java
0.00% <0.00%> (ø)

... and 8 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


improvements

I would like to suggest a few improvements for the hexapod here:

the axis position should get a unit (mm, deg)
the limits should be handled via the state of the axis (Alarm)
would be nice to invert the direction of individual axis. either by a boolean or a more general DESY-like conversion-factor.

What do you think?

The way we're currently handling limits is not reliable: we query axis limits and compare the current axis position against these limits. The issue is, that these are theoretical values that are only accurate for the default pivot point and when all other axes are at zero position.
The manual recommends to check whether a target position is reachable before sending the movement command. I implemented this in the linked branch. Unit assignment and inverted flag are also implemented there.
I tested it briefly on our hexapod, please also check it works for yours.


SQLAlias throws error on 32 bit alias

Details of the scenario you tried and the problem that is occurring:
On line 165 of SQLAlias the registry key for the 32 bit alias is created. On a new test environment, the MSSQLServer key (and all child keys) didn't exist yet, resulting in an error when creating the key.
After some troubleshooting I found that New-Item only creates child keys when the parent exists. When the parent does not exist, an error is thrown. This can be resolved by adding the -Force parameter to the cmdlet.
This change is also required for line 152.
The DSC configuration that is using the resource (as detailed as possible):
SQLAlias Alias
{
Ensure               = "Present"
Name                 = "DBServer"
ServerName       = "serverx.domain.com"
Protocol             = 'TCP'
TcpPort              = 1433
}
Version of the Operating System, SQL Server and PowerShell the DSC Target Node is running:
Windows Server 2016
What module (SqlServer or SQLPS) and which version of the module the DSC Target Node is running:
xSQLServer 9.0
Version of the DSC module you're using, or 'dev' if you're using current dev branch:
9.0

I downloaded the modified file from (#950 ) and am still seeing an error:
VERBOSE: [sp05]:                            [[SqlAlias]SqlAlias] Operation 'Enumerate CimInstances' complete.
VERBOSE: [sp05]:                            [[SqlAlias]SqlAlias] Performing the operation "Setting the client alias
(32-bit)" on target "SQLSERVER".
Access to the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\ConnectTo' is denied.
    + CategoryInfo          : PermissionDenied: (HKEY_LOCAL_MACH...lient\ConnectTo:) [], CimException
    + FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.NewItemCommand
    + PSComputerName        : localhost

Cannot find path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\ConnectTo' because it does not exist.
    + CategoryInfo          : ObjectNotFound: (HKLM:\SOFTWARE\...lient\ConnectTo:) [], CimException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetItemPropertyCommand
    + PSComputerName        : localhost

Is this error related to this issue? @ykuijs @johlju

even on latest build with the -force parameter the error persist.


Update or remove vendor folder

When I run GO111MODULE=on go mod vendor a lot of packages get updated in the vendor folder so I suggest to either commit an updated version of the vendor folder or remove it completely.

thanks for the heads up!, looks like I forgot to re-vendor the dependencies I changed yesterday and the binaries for 0.2.3 got built with the old vendor folder, not picking up the new packages.
I've just cut 0.2.4 and should be available as soon as CI finishes.

@frapposelli thanks for your swift feedback and the new release.


ICE bugs 5796 and 6720

Two simple ice-on-invalid-code bugs.
5796 ICE with pragma(msg, ...) after missing ';' in a template
6720 ICE(cod1.c) casting return of void function to bool

Failed the few runs of the pull auto-tester that had a chance to run, one example:
http://d.puremagic.com/test-results/pull.ghtml?runid=46640
So, not surprisingly, it's failing the master branch builds too:
http://d.puremagic.com/test-results/test_data.ghtml?dataid=146447

This just broke runnable/funclit.d

Any idea why in:
auto dg = cast(int function(int))(a => a);
a=>a;  is of type void ?
On 31 January 2012 08:39, Daniel Murphy
<EMAIL_ADDRESS>wrote:

This just broke runnable/funclit.d

Reply to this email directly or view it on GitHub:
https://github.com/D-Programming-Language/dmd/pull/665#issuecomment-3734925

I reverted the 6720 fix until this is investigated.

Any idea why in:
auto dg = cast(int function(int))(a => a);
a=>a;  is of type void ?

Something weird about it being a template declaration instead of an actual type?

void is used as a placeholder when the type of a function literal cannot be inferred during semantic.
See FuncExp::semantic L4978.
I'm not sure what the correct solution is here, probably either special case the check for casting from void to allow casting from function literals, or add a new Ttype to represent them.

On 31 January 2012 15:43, Daniel Murphy
<EMAIL_ADDRESS>wrote:

void is used as a placeholder when the type of a function literal cannot be inferred during semantic.
See FuncExp::semantic L4978.

Thanks!

I'm not sure what the correct solution is here, probably either special case the check for casting from void to allow casting from function literals, or add a new Ttype to represent them.

Hmm. Nasty special case either way. It doesn't seem right to me to use
Tvoid to mean both "void" and "don't yet know". I'd be very surprised
if this is the only place this issue shows up. (I bet there are ICE
bugs when you pass one of these guys as a variadic template tuple
parameter).


GSOC retriever

Closes #22

@jspeed-meyers I (...finally) made a quick pass at this, please let me know what you think when you get a chance! Since it relies entirely on the appearance of a github link in the project text or links, it is imperfect (you can see what I mean if you browse the data, although of course some of these projects really aren't on github) -- very much welcome any ideas for making it better


Core validation: Misleading error reported if no pipeline is bound and app tries to change a dynamic state

Consider the use case below:

Start command buffer recording.
Set dynamic scissor data.

Of course, there's a missing 'bind pipeline' call above which is what should be raised by the layer. However, what I'm seeing with a ToT version of core validation layer is:
vkCmdSetScissor(): pipeline was created without VK_DYNAMIC_STATE_SCISSOR flag. The spec valid usage text states 'The currently bound graphics pipeline must have been created with the VK_DYNAMIC_STATE_SCISSOR dynamic state enabled' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-vkCmdSetScissor-None-00590).
What I believe it should say should be along the lines of:
You've got no GFX pipeline bound, so that vkCmdSetScissor() call of yours makes no sense. Go away.

When this error is encountered, there should be two versions of the prefix string which get combined with the single target VUID depending on whether a pipeline is bound or not.  Then everybody's happy.

I wanted to mess with this, but found the spec is tad too ambiguous to my taste.
You touch on point nr. 5 in https://github.com/KhronosGroup/Vulkan-Docs/issues/620 .
There is a strong indication the dynamic state was meant to be a cmdbuffer state in 1.0.0, so no bound pipeline should even be necessary. And that is how many did use it before.

This does not change the fact that we've got the following VU defined in the spec:
The currently bound graphics pipeline must have been created with the
VK_DYNAMIC_STATE_SCISSOR dynamic state enabled

I see no ambiguity in here in terms of whether or not it is legal to adjust the scissor area without a bound GFX pipeline.

@DominikWitczakAMD That statement was added later to the spec, potentially introducing spec bug.
Also consider this:

Dynamic state not set by binding the pipeline object can be modified at any time and persists for the lifetime of the command buffer, or until modified by another dynamic state command or another pipeline bind.


Configurable sources and simulate volume

Description:
This allows the user to:

Configure the input sources of the AVR
Configure a key interval to sleep between the sending of the key commands
Simulate the volume setter of the AVR (This enables to control the volume through Google Assistant)

Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#9254
Example entry for configuration.yaml (if applicable):
media_player:
  - platform: harman_kardon_avr
    host: IP_HERE
    key_interval: 0.3
    simulate_volume_set: True
    sources:
      - source: TV
        name: Television
      - source: Game
        name: Xbox One

Checklist:

[ ] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[x] The manifest file has all fields filled out correctly (example).
[x] New dependencies have been added to requirements in the manifest (example).
[x] New dependencies are only imported inside functions that use them (example).
[x] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

If the code does not interact with devices:

[x] Tests have been added to verify that the new code works.

Hello @Devqon,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:

b1bed8631e4d088065e38746ee1e687f64ad6127 - This commit has something that looks like an email address (ao609965@achmea.nl). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:

If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

If you only made a single commit you should be able to rungit commit --amend --author="Author Name<EMAIL_ADDRESS>
(substituting Author Name and<EMAIL_ADDRESS>for your actual information) to set the authorship information.
If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:

You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.

Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! :heart:

Hello @Devqon,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:

b1bed8631e4d088065e38746ee1e687f64ad6127 - This commit has something that looks like an email address (ao609965@achmea.nl). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:

If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

If you only made a single commit you should be able to rungit commit --amend --author="Author Name<EMAIL_ADDRESS>
(substituting Author Name and<EMAIL_ADDRESS>for your actual information) to set the authorship information.
If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:

You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.

Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! :heart:

@rohankapoorcom I accidentally pushed with another username, so I closed the pull request. I have fixed the history for the authors, but cannot re-open the pull request (with this method) (no rights?).
Could you please either reopen this pull request or delete it fully?

I am unable to reopen the full request either. It says that there is no source branch anymore. You can feel free to leave this one closed and open a new one with your changes, linking to this one.


Restrict controlled from non-thru registers

For #1304

Only thru registers allowed in Controlled
Prevents triggering the bug in classical simulation where controlled allocations are not supported

Left a comment on the original issue - https://github.com/quantumlib/Qualtran/issues/1304#issuecomment-2297600946

Let's do this and relax later


updated docs, added an install script

Coverage remained the same at 77.851% when pulling 48e79280d38940eb0025a5ebd93fc54b3b9cc41e on update-man-jclc into 366f96906af46759b75f2bf814a181573c97d2bd on master.

Coverage remained the same at 77.851% when pulling 48e79280d38940eb0025a5ebd93fc54b3b9cc41e on update-man-jclc into 366f96906af46759b75f2bf814a181573c97d2bd on master.

Coverage remained the same at 77.851% when pulling dacfc5037442b20073502bc91b2d3ef82f8bf3e2 on update-man-jclc into 366f96906af46759b75f2bf814a181573c97d2bd on master.

LGTM.


How to use it

Hi,
it may be a noob question but how do you use the example on this page ?
after installing this npm package and adding the example i just get a weird error
ode_modules/swagger-test-templates/templates/default/get/get.handlebars'     at Error (native)     at Object.fs.openSync (fs.js:640:18)     at Object.fs.readFileSync (fs.js:508:33)     at testGenResponse (
I am guessing you miss some noob tutorial ?
I also tried following
https://apigee.com/about/blog/developer/swagger-test-templates-test-your-apis
installing all the missing packages but still o do not see how this example is connected to what is in the article.
My question is how to i generate these api tests based on the specification of my swagger api with load testing ?
thank you

You can use it like so:-
var fs = require("fs"),
    stt = require("swagger-test-templates"),
    swagger = require("swagger.json"),
    config = {
        assertionFormat: "expect",
        testModule: "request",
        pathName: [],
        maxLen: -1
    };

var tests = stt.testGen(swagger, config);

tests.forEach(function(element) {
    fs.writeFile("./test/" + element.name, element.test, (err) => {
        if (err) throw err;

        console.log(element.name, " written");
    });
}, this);

This will parse your swagger.json and create several test files in a directory test. At this point you have a folder of tests that can be run with Mocha. So to run them navigate to test then run the following:-
npm install --save mocha
npm install --save chai
npm install --save request
npm install --save z-schema
npm install --save dotenv

mocha

I hope that helps.

How to run this file
var fs = require("fs"),
stt = require("swagger-test-templates"),
swagger = require("swagger.json"),
config = {
assertionFormat: "expect",
testModule: "request",
pathName: [],
maxLen: -1
};
var tests = stt.testGen(swagger, config);
tests.forEach(function(element) {
fs.writeFile("./test/" + element.name, element.test, (err) => {
if (err) throw err;
    console.log(element.name, " written");
});

}, this);


Route53: Dynamic record not being pushed

I have the below configured as a record on a domain:
www:
  dynamic:
    pools:
      na:
        fallback: eu
        values:
        - value: aloadofELBstuffhere.amazonaws.com.
      eu:
        values:
        - value: vif07.example.com.
        - value: vif08.example.com.
    rules:
    - geos:
      - AF
      - EU
      pool: eu
    - geos:
      - NA
      - SA
      pool: na
    - pool: eu
  ttl: 300
  type: CNAME
  value: web.example.com.

When I run octodns-sync --doit, i get the below readout for this domain:
*   Create <CnameRecord CNAME 300, www.example.com., web.example.com.> (config)
As you can see, none of the information provided via the dynamic record is pushed with the sync. I would expect the pool/geo information to be pushed up into this record, as with the geo record type.
I cannot use the geo record type for this, as www has to be a CNAME in order to point to an AWS ELB resource - is there something obviously wrong with my configuration? (Copied from the documentation)?

This was resolved upon updating to 0.9.6.


Too much vmem?

We are running mriqc 0.14.2. Our jobs are killed often while QC-ing our anat/t1w due to too much vmem consumption. I can increase it, but doing so reduces the resources that we can run this App on.. I'd like to know if it's normal that it consumes so much vmem (>18GB)

=>> PBS: job killed: vmem<PHONE_NUMBER>4 exceeded limit<PHONE_NUMBER>4

The program called "fast" seems to be using a lot of memory - although other processes also uses a lot of memory.

Hi @soichih sorry for the very slow turnaround. FAST is part of FSL, so I have very high expectations on #823 where we will stop using it.
But there are many additional measures we can transfer from fMRIPrep here to keep VMEM under control.
The problem roots from the design of memory handling in Python on Linux platforms. Basically, anything that gets imported at some point is kept along the process.

Possibly duplicate of #536


When negative location positions are given but exceeds read lengths, the tags won't be identified

Fix this issue (e.g. if locations column for a tag is 0:-2000:0).

fixed


[BSI][20200601] App Transport Security Partially Disabled

Rating: Informational
Description:
App Transport Security (ATS) is a security feature introduced in iOS
9 to ensure that the app's network connections employ only industry-
standard protocols and ciphers without known weaknesses. ATS is
enabled by default for any iOS app. In this case, ATS is explicitly
disabled for the distribution mock server domain. The configuration
allows connections in plaintext over HTTP for the domain and all its
subdomains.
This exception is currently defined for the mock server and
presumably only required for testing. However, this configuration
should not be present in the production variant of the app or used
for production servers in the CWA ecosystem.
Proof of Concept:
The configuration can be found in the app's Info.plist file starting
on line 38:
<key>NSAppTransportSecurity</key>
<dict>
	<key>NSAllowsArbitraryLoads</key>
	<true/>
	<key>NSExceptionDomains</key>
	<dict>
		<key>distribution-mock-cwa-[...]</key>
		<dict>
			<key>NSExceptionAllowsInsecureHTTPLoads</key>
			<true/>
			<key>NSIncludesSubdomains</key>
			<true/>
		</dict>
	</dict>
</dict>

Fixed in #164

@BSI-TF-CWA This was actually fixed in #160. Feel free to double check the current development branch. :)


Leios crypto

Just some small typos, transposing the table, and adding some wikipedia citations

As a note: If you don't want to merge, I might put this as a PR to the AAA main to supercede your PR. Obviously, you get credit as well if we do that!


[tx] Handle id-literals in the transactor

This is the hardest part of transacting, but I worked out an efficient approach in the Clojure implementation: see #88.  This depends on #169.
Similar to #183, a sophisticated implementation might have multiple regimes depending on the input characteristics.

This is done: https://github.com/mozilla/mentat/commit/16e9740d8a117c4b9384c4be262b0b64fe941d9f.


Scala Native 0.5 is released, a new release of gears

refs: https://scala-native.org/en/stable/changelog/0.5.x/0.5.0.html

I wonder if munit is going to migrate to 0.5.0 soon, so I no longer have to maintain a 1 line change fork :smile_cat:

I wonder if munit is going to migrate to 0.5.0 soon, so I no longer have to maintain a 1 line change fork :smile_cat:

Is there any particular reason you choose munit?

No particular reason to be honest. Maybe I could move to something simpler.
Do you have any suggestions that work cross platform?
Le jeu. 11 avr. 2024 à 18:30, He-Pin(kerr) @.***> a
écrit :

I wonder if munit is going to migrate to 0.5.0 soon, so I no longer have
to maintain a 1 line change fork 😸
Is there any particular reason you choose munit?
—
Reply to this email directly, view it on GitHub
https://github.com/lampepfl/gears/issues/64#issuecomment-2050076277, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACFEK2J37645MO2465SAYJLY423CHAVCNFSM6AAAAABGCTRICWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJQGA3TMMRXG4
.
You are receiving this because you commented.Message ID:
@.***>

I think it's safe to assume that MUnit will support Native 0.5 soon. I've opened https://github.com/scalameta/munit/issues/760 to request it

I back published for 1.0.0-M11. Let me know if you need any other version.

@tgodzik thanks! I tried using the published version and got an error stating that the NIR output was incompatible. sbt gives org.scalameta:munit_native0.5_3:1.0.0-M11 is the package I'm depending on.
The error is
assertion failed: Can't read binary-incompatible version of NIR from 'MUnitRunner$ForeachUnsafeResult.nir' (expected compat=6, got 5; expected revision=10, got 9)

This seems like for some reason the NIR version is still from scala-native 0.4 for some reason...
Full stack trace of the error (last rootNative / Test / nativeLink from sbt)

[debug] Config(
[debug]  - baseDir:          /home/nki/Projects/gears/native/target/scala-3.3.3
[debug]  - testConfig:       true
[debug]  - workDir:          /home/nki/Projects/gears/native/target/scala-3.3.3/native-test
[debug]  - moduleName:       gears
[debug]  - baseName:         gears
[debug]  - artifactName:     gears-test
[debug]  - artifactPath:     /home/nki/Projects/gears/native/target/scala-3.3.3/gears-test
[debug]  - buildPath:        /home/nki/Projects/gears/native/target/scala-3.3.3/native-test/scala.scalanative.testinterface.TestMain-test
[debug]  - mainClass:        Some(scala.scalanative.testinterface.TestMain)
[debug]  - classPath:        List(/home/nki/Projects/gears/native/target/scala-3.3.3/test-classes
[debug]                      /home/nki/Projects/gears/native/target/scala-3.3.3/classes
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala3-library_3/3.3.3/scala3-library_3-3.3.3.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-native/test-interface_native0.5_3/0.5.1/test-interface_native0.5_3-0.5.1.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-native/scala3lib_native0.5_3/3.3.3%2B0.5.1/scala3lib_native0.5_3-3.3.3%2B0.5.1.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-native/nativelib_native0.5_3/0.5.1/nativelib_native0.5_3-0.5.1.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-native/clib_native0.5_3/0.5.1/clib_native0.5_3-0.5.1.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-native/posixlib_native0.5_3/0.5.1/posixlib_native0.5_3-0.5.1.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-native/windowslib_native0.5_3/0.5.1/windowslib_native0.5_3-0.5.1.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-native/javalib_native0.5_3/0.5.1/javalib_native0.5_3-0.5.1.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-native/auxlib_native0.5_3/0.5.1/auxlib_native0.5_3-0.5.1.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scalameta/munit_native0.5_3/1.0.0-M11/munit_native0.5_3-1.0.0-M11.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/com/sourcegraph/semanticdb-javac/0.9.9/semanticdb-javac-0.9.9.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.13/scala-library-2.13.13.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-native/test-interface-sbt-defs_native0.5_3/0.5.1/test-interface-sbt-defs_native0.5_3-0.5.1.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-native/junit-runtime_native0.5_3/0.5.1/junit-runtime_native0.5_3-0.5.1.jar
[debug]                      /home/nki/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-native/scalalib_native0.5_2.13/2.13.13%2B0.5.1/scalalib_native0.5_2.13-2.13.13%2B0.5.1.jar)
[debug]  - sourcesClasspath: List()
[debug]  - compilerConfig:   NativeConfig(
[debug]  - baseName:
[debug]  - clang:                   /nix/store/lnl2zcfs4gd0cj2mpc7744s63babv37g-clang-wrapper-16.0.6/bin/clang
[debug]  - clangPP:                 /nix/store/lnl2zcfs4gd0cj2mpc7744s63babv37g-clang-wrapper-16.0.6/bin/clang++
[debug]  - linkingOptions:          [-L/nix/store/23c1ql0y2cx4817mld3yrw05rnchv9yg-llvm-16.0.6-lib/lib]
[debug]  - compileOptions:          [-I/nix/store/cm7pff6m03irh59rygj6v76jvcbsnpqb-llvm-16.0.6-dev/include, -Qunused-arguments]
[debug]  - targetTriple:            None
[debug]  - GC:                      immix
[debug]  - LTO:                     none
[debug]  - mode:                    debug
[debug]  - buildTarget              Application
[debug]  - check:                   false
[debug]  - checkFatalWarnings:      false
[debug]  - checkFeatures            true
[debug]  - dump:                    false
[debug]  - sanitizer:               none
[debug]  - linkStubs:               false
[debug]  - optimize                 true
[debug]  - incrementalCompilation:  true
[debug]  - multithreading           Some(true)
[debug]  - linktimeProperties:      []
[debug]  - embedResources:          false
[debug]  - resourceIncludePatterns: [**]
[debug]  - resourceExcludePatterns: []
[debug]  - serviceProviders:        []
[debug]  - optimizerConfig:
[debug]     - maxInlineDepth:    32 functions
[debug]     - smallFunctionSize: 12 instructions
[debug]     - maxCallerSize:     2048 instructions
[debug]     - maxCalleeSize:     256 instructions
[debug]
[debug]  - semanticsConfig:         SemanticsConfig(
[debug]     - finalFields: Relaxed
[debug]     - strictExternCallSemantics: false
[debug]     )
[debug]  - sourceLevelDebuggingConfig: SourceLevelDebuggingConfig[Disabled]
[debug]     - customSourceRoots:       []
[debug]     - generateFunctionSourcePositions: false
[debug]     - generateLocalVariables:  false
[debug]     )
[debug] )
[debug] )
[info] Total (262 ms)
[error] java.util.concurrent.ExecutionException: Boxed Error
[error] 	at scala.concurrent.impl.Promise$.resolver(Promise.scala:87)
[error] 	at scala.concurrent.impl.Promise$.scala$concurrent$impl$Promise$$resolveTry(Promise.scala:79)
[error] 	at scala.concurrent.impl.Promise$DefaultPromise.tryComplete(Promise.scala:284)
[error] 	at scala.concurrent.Promise.complete(Promise.scala:53)
[error] 	at scala.concurrent.Promise.complete$(Promise.scala:52)
[error] 	at scala.concurrent.impl.Promise$DefaultPromise.complete(Promise.scala:187)
[error] 	at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:33)
[error] 	at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
[error] 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
[error] 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
[error] 	at java.base/java.lang.Thread.run(Thread.java:1583)
[error] Caused by: java.lang.AssertionError: assertion failed: Can't read binary-incompatible version of NIR from 'MUnitRunner$ForeachUnsafeResult.nir' (expected compat=6, got 5; expected revision=10, got 9).
[error] 	at scala.Predef$.assert(Predef.scala:223)
[error] 	at scala.scalanative.nir.serialization.Prelude$.readFrom(Prelude.scala:39)
[error] 	at scala.scalanative.linker.ClassPath$Impl.$anonfun$classesWithEntryPoints$1(ClassPath.scala:79)
[error] 	at scala.scalanative.linker.ClassPath$Impl.$anonfun$classesWithEntryPoints$1$adapted(ClassPath.scala:75)
[error] 	at scala.collection.TraversableLike.$anonfun$filterImpl$1(TraversableLike.scala:304)
[error] 	at scala.collection.mutable.HashMap.$anonfun$foreach$1(HashMap.scala:149)
[error] 	at scala.collection.mutable.HashTable.foreachEntry(HashTable.scala:237)
[error] 	at scala.collection.mutable.HashTable.foreachEntry$(HashTable.scala:230)
[error] 	at scala.collection.mutable.HashMap.foreachEntry(HashMap.scala:44)
[error] 	at scala.collection.mutable.HashMap.foreach(HashMap.scala:149)
[error] 	at scala.collection.TraversableLike.filterImpl(TraversableLike.scala:303)
[error] 	at scala.collection.TraversableLike.filterImpl$(TraversableLike.scala:297)
[error] 	at scala.collection.AbstractTraversable.filterImpl(Traversable.scala:108)
[error] 	at scala.collection.TraversableLike.filter(TraversableLike.scala:395)
[error] 	at scala.collection.TraversableLike.filter$(TraversableLike.scala:395)
[error] 	at scala.collection.AbstractTraversable.filter(Traversable.scala:108)
[error] 	at scala.scalanative.linker.ClassPath$Impl.classesWithEntryPoints$lzycompute(ClassPath.scala:75)
[error] 	at scala.scalanative.linker.ClassPath$Impl.classesWithEntryPoints(ClassPath.scala:74)
[error] 	at scala.scalanative.linker.ClassLoader$FromDisk.$anonfun$classesWithEntryPoints$1(ClassLoader.scala:32)
[error] 	at scala.collection.immutable.List.flatMap(List.scala:366)
[error] 	at scala.scalanative.linker.ClassLoader$FromDisk.classesWithEntryPoints$lzycompute(ClassLoader.scala:32)
[error] 	at scala.scalanative.linker.ClassLoader$FromDisk.classesWithEntryPoints(ClassLoader.scala:31)
[error] 	at scala.scalanative.linker.Reach.(Reach.scala:59)
[error] 	at scala.scalanative.linker.Reach$.apply(Reach.scala:1166)
[error] 	at scala.scalanative.linker.Link$.apply(Link.scala:12)
[error] 	at scala.scalanative.build.ScalaNative$.$anonfun$link$3(ScalaNative.scala:45)
[error] 	at scala.scalanative.build.Logger.time(Logger.scala:36)
[error] 	at scala.scalanative.build.Logger.time$(Logger.scala:33)
[error] 	at scala.scalanative.build.Logger$$anon$3.time(Logger.scala:102)
[error] 	at scala.scalanative.build.ScalaNative$.$anonfun$link$1(ScalaNative.scala:45)
[error] 	at scala.concurrent.Future$.$anonfun$apply$1(Future.scala:659)
[error] 	at scala.util.Success.$anonfun$map$1(Try.scala:255)
[error] 	at scala.util.Success.map(Try.scala:213)
[error] 	at scala.concurrent.Future.$anonfun$map$1(Future.scala:292)
[error] 	at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:33)
[error] 	at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:33)
[error] 	at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
[error] 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
[error] 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
[error] 	at java.base/java.lang.Thread.run(Thread.java:1583)
[error] (rootNative / Test / nativeLink) java.util.concurrent.ExecutionException: Boxed Error

Looks like I broke that release then :/ I was sure if we released with 0.5.0 set it would just work, but it seems somehow it took artifacts compiled with 0.4.x and just put it under 0.5.x
This is becoming more complex since, I can't update munit to 0.5.0 because we depend on scalacheck, which is released with Scala LTS and munit can't update because it is blocked by an issue in LTS

I released a new milestone (12 :fearful: ) automatically, so things should work fine.

I think it works now, thanks @tgodzik!!

And 0.2 is released using scala-native 0.5.1 :tada:


Arabic url seems not working on "Refresh"

Hi @timdorr  ,
I've been working on An Arabic Web-App, clicking on link such as http://localhost/product/هاتف works just fine but if i click refresh button or hit F5key, the link in the address bar became http://localhost/هاتفand so it render another component :cry:
Is there a fix for this issue ??
Thanks

I'm not aware of anything in this library that would cause that. Please provide a repro.

Related to #3317.
You need to encode the URL before sending it through the router. This comment should help.


Remove trailing spaces from sources and tests

Q
A

Is bugfix?
no

New feature?
no

Breaks BC?
no

Tests pass?
yes

Fixed issues
none

Github thinks that I removed the trailing empty line from the tests/data/ar/Type.php but it seems like it's still there.

Merged. Thanks!


fix fix query result error after delete

convert dictionary code for delete predicates.
Proposed changes
Issue Number: close #11425
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[ ] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[ ] No Need

Does it need to update dependencies:

[ ] Yes
[ ] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[ ] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

Please add regression test from the issue.

done