disable iOS keyboard avoiding view on screens without text input

Details

Fixed Issues
$ https://github.com/Expensify/App/issues/19530
PROPOSAL: https://github.com/Expensify/App/issues/19530#issuecomment-1636136861
Tests
Same as QA step

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

Offline tests
Same as QA step
QA Steps
Case 1:

Go to FAB > Request money
Enter any amount and click Next
On participants select page, Verify that keyboard shows automatically
Click back button while showing keyboard
Verify that Next button keeps fixed position at the bottom, not animating

Case 2:

Go to FAB > Assign task
Enter title and click Next
Click Title menu item
On edit title page, verify that keyboard shows automatically
Click back button
Verify that Confirm task button keeps fixed position at the bottom, not animating

Case 3:

Go to Settings > Security > Two-factor authentication
On Step 1, copy codes and click Next
On Step 2, verify that keyboard shows automatically
Click back button to go back to Step 1
Verify that Next button keeps fixed position at the bottom, not animating

[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] 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
N/A

Mobile Web - Chrome
N/A

Mobile Web - Safari
N/A

Desktop
N/A

iOS

request money

Before:
https://github.com/Expensify/App/assets/108292595/b4b286fc-a44d-4a5b-9394-029ef6bb8f89
After:
https://github.com/Expensify/App/assets/108292595/e1dee86f-9914-4d7b-9c92-ccc312978ba8

assign task

Before:
https://github.com/Expensify/App/assets/108292595/fdfe7593-355b-47ef-9d6a-834a33087bd5
After:
https://github.com/Expensify/App/assets/108292595/689ed07a-d76b-457e-bb47-6240664ad502

2fa code

Before:
https://github.com/Expensify/App/assets/108292595/9035eaa8-bef5-4bcd-ae68-c48b23763853
After:
https://github.com/Expensify/App/assets/108292595/c893cd11-eda7-45a0-a744-c088b2bf857d

Android
N/A

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

🚀 Deployed to staging by https://github.com/joelbettner in version: 1.3.55-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/joelbettner in version: 1.3.56-0 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/roryabraham in version: 1.3.56-24 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Dependency Analytics  conflict with jupyter

VS Code Version: 1.61.0
OS Version: mac 11.6
python: v2021.10.1317843341
pylance: v2021.10.0
jupyter: v2021.9.1001312534
Dependency Analytics: v0.3.4

when i install Dependency Analytics open jupyter file a.ipynb,  code python in Cell cant auto complete and cant use some hotkey(cmd + / ) in cell.  code python in b.py it work well.
when i disable Dependency Analytics jupyter work well.

+1

Thanks for bisect, I encounter the same issue.

the same problem

same issue, cause vscode ipynb jupyter notebook intellisense not working.

Still have the same issue.

+1

Maybe you might close this issue, now that it's fixed too. :-)

Thanks @systematiccaos for fixing this issue :).
Apologies for the delay.
0.3.6 version of extension is published for this fix. Feel free to reopen issue, if it still exists.


feat: unicode support for minus and asterisk operators

What is the previous behavior before this PR?
Unicode minus (−) and asterisk operator (∗) produce "unrecognized Unicode character" and format as \mathord.
What is the new behavior after this PR?
Unicode minus (−) and asterisk operator (∗) produce \mathbin operators just like their ASCII counterparts - and *.
This seems to agree with the \mathbin behavior of https://github.com/wspr/unicode-math/blob/master/unicode-math-table.tex
Fixes #3225

Codecov Report

Merging #3227 (83201a4) into master (a522216) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #3227   +/-   ##
=======================================
  Coverage   93.95%   93.95%
=======================================
  Files          88       88
  Lines        6365     6365
  Branches     1322     1322
=======================================
  Hits         5980     5980
  Misses        355      355
  Partials       30       30

Impacted Files
Coverage Δ

src/symbols.js
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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

@ronkok Thanks for the quick review!


clean up rna topic branches

per PR #836

create new protected topic branch for rna api development off master
remove existing rna branches

Sounds good @saupchurch --- do you have permissions to do this, or do you need me or @dcolligan to create the branches? Ping one of us here or offline if you need anything.

@david4096 has taken care of this and we have a clean rna topic branch now


Rework the documentation about the setup in HA

Is your feature request related to a problem? Please describe.
The documentation of the setup of the Bosch component my deserve a rework to be a bit more complete and consolidate the information in the HA forum.
Describe the solution you'd like
I'd like to work on the Wiki page in Github to provide a complete setup guidance
Describe alternatives you've considered
HA documentation on home-assistant.io is pretty complicated and I would not chose it as the GitHub wiki is more easy to deal with.
Additional context
These are some screenshots I'd like to use:

Installation Guide is reworked and old content removed


Upstream sync for operator-lifecycle-manager

initial sync to copy all upstream commit history

Also, it looks like the staging/operator-lifecycle-manager/go.sum is out-of-date here too.

/retest

This is passing for me locally. I'll throw a hold on for now so we can continue monitoring.
/lgtm
/hold

/test unit-olm

/lgtm

This was reported as a flaky test in the passing e2e-aws-olm job:
/go/src/github.com/openshift/operator-framework-olm/staging/operator-lifecycle-manager/test/e2e/crd_e2e_test.go:345
Unexpected error:
    <*errors.errorString | 0xc00024c6f0>: {
        s: "timed out waiting for the condition",
    }
    timed out waiting for the condition
occurred
/go/src/github.com/openshift/operator-framework-olm/staging/operator-lifecycle-manager/test/e2e/crd_e2e_test.go:494

This looks good to go
/test ci/prow/e2e-aws-console-olm

/test e2e-aws-console-olm

/test e2e-upgrade

/hold cancel


Fix constraints codegen when there are no real resources

Tickets addressed: N/A
Review: By commit
Merge strategy: Merge (no squash)

Description

@ewferg discovered a bug where a mission model with a single enum discrete resource would cause invalid typescript to be generated for the constraints library.
This manifested itself in the following clear-as-mud error message:
[{"errors":[{"location":{"column":329,"line":10},"message":"TypeError: TS1110 Type expected.","stack":"at (10:329)"}],"goal_id":1}]

Upon examining the generated typescript code, I observed the following:
export type RealResourceName = ;

Eric's mission model did not, at the time, export any real resources. It exported just a single discrete resource, of type ENUM.
This PR adds | never the the end of ResourceName and RealResourceName to make sure that valid code is generated even in the empty case. I consulted this stackoverflow answer to confirm that including never in a union type is a no-op.
Verification

I added a new minimal-mission-model that exhibits this behavior, and wrote a scheduling integration test that loads this model. In the second commit of this PR, that test should fail. After the third, it should pass.
(I pushed the second commit first, so the test failure is apparent: https://github.com/NASA-AMMOS/aerie/actions/runs/4809268807/jobs/8560283793)
I'm open to suggestions if people think this level of test is too high up the stack - it was simply the easiest way I could think of to make a mission model, and witness a typescript compilation error. Perhaps something in ConstraintsDSLCompilationTests would be more appropriate.
Documentation

This is a bugfix - no existing documentation should be invalidated.
Future work

The root cause of this error was awfully difficult to see, in part because the user code runner obscures the source of the error. I would like to see us improve the debuggability of our DSLs - it is unfortunately not reasonable to assume that the generated code is always perfect

Technically this same behavior would happen on DiscreteResource if the model had no resources at all. But like...that seems unlikely.


Makefile: Ensure better consistency between e2e runs

Update the kind-cluster Makefile target and delete the testing kind
cluster if it already exists, then re-create that cluster to ensure
we're not using a potentially stale cluster environment during local/CI
e2e runs.
Signed-off-by: timflannagan<EMAIL_ADDRESS>

cc @joelanford


[fltk] Update to 1.3.6 rc1 and fix osx build

This PR will:

update fltk to 1.3.6 rc1
use github repo
fix osx build using the official changes: https://github.com/fltk/fltk/issues/191
drop support with uwp since the upstream use some desktop only functions:

     4>f:\vcpkg\buildtrees\fltk\src\629d1bd445-dc683240ba\fl\win32.H(52): error C3861: 'DeleteObject': identifier not found (compiling source file F:\vcpkg\buildtrees\fltk\src\629d1bd445-dc683240ba\src\Fl_Bitmap.cxx) [F:\vcpkg\buildtrees\fltk\arm64-uwp-dbg\src\fltk.vcxproj]
     4>f:\vcpkg\buildtrees\fltk\src\629d1bd445-dc683240ba\fl\win32.H(54): error C3861: 'GetRgnBox': identifier not found (compiling source file F:\vcpkg\buildtrees\fltk\src\629d1bd445-dc683240ba\src\Fl_Bitmap.cxx) [F:\vcpkg\buildtrees\fltk\arm64-uwp-dbg\src\fltk.vcxproj]
     4>f:\vcpkg\buildtrees\fltk\src\629d1bd445-dc683240ba\fl\win32.H(87): error C2061: syntax error: identifier 'MINMAXINFO' (compiling source file F:\vcpkg\buildtrees\fltk\src\629d1bd445-dc683240ba\src\Fl_Bitmap.cxx) [F:\vcpkg\buildtrees\fltk\arm64-uwp-dbg\src\fltk.vcxproj]

See https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-deleteobject

@efrainceh Can you please test this PR?
Thanks.

@JackBoosY tested the PR, fltk successfully downloaded and installed (it works, too). Do you need any of the logs?

@efrainceh Nope, I just want to test whether it works.

It appears version 1.36 was officially released yesterday.


new Shuffle operator (issue 470)

:memo: This PR is for #470

I will add a overload that receive Random

I will add a overload that receive Random

done


Arrows submenu indicator when menu is close to the right edge of the screen

In these cases, necessarily, the submenu window appears totally to the left of the root-menu but the arrow indicator remains on the right side. Really a quite negligible issue but, if not too programmatically complicated, it would be pleasant in these cases if even the arrow in the root-menu appeared on the left...

When navigating the menu with the keyboard, the right arrow key activates the sub-menu no matter which side it is displayed on, so having the arrow on the left side might be confusing to keyboard users.

Thanks to you for the brilliant observation, I hadn't really thought of that. At this point the thing would only be functional by also adding a user configurable switch option in jwmrc for that purpose otherwise better to leave things as they are


Use PhyloVelo in regular scRNAseq

Hi Dr. Wang,
Thanks for developing this great tool. I hope to use it in my study. Can I use PhyloVelo in the regular sc-RNAseq of tumor? I check the tutorial but I can't find there is any case to use it in the regular scRNAseq scenario. Or is there any tool to infer the Phylogenetic tree in the regular scRNAseq. Any suggestion is appreciated!

Hello Dr. Xiong,
Thank you for your interest in our work. I’m glad you found it useful.

Can I use PhyloVelo in the regular sc-RNAseq of tumor? I check the tutorial but I can't find there is any case to use it in the regular scRNAseq scenario.

To use PhyloVelo, you need lineage tracing data (such as DNA sequencing or clone barcoding) to identify MEGs and estimate the velocity. This means you cannot use it with only scRNA-seq data for now. However, if your data comes from mouse lung tumor development, you can try transferring the MEGs from the kp_3435 and kp_3726 datasets to your scRNA-seq data.

Or is there any tool to infer the Phylogenetic tree in the regular scRNAseq. Any suggestion is appreciated!

We are trying to find a way to infer the single cell mutations using scRNA-seq, but we have not achieved a satisfactory result.
Best regards,
Kun.

Thanks for your explanation and suggestion.
To infer the Phylogenetic tree from scRNA-seq, have you tried tools like this: https://www.sciencedirect.com/science/article/pii/S0092867419300558


Quicksort should shuffle first

Quicksort should first randomly shuffle the container. If it doesn't and the array is already sorted, then it will actually be O(n^2), which is the worst case. By shuffling, it results in a probabilistic guarantee of О(n log n).
https://github.com/kanwei/algorithms/blob/master/lib/algorithms/sort.rb#L180
See: http://stackoverflow.com/questions/27645471/how-does-random-shuffling-in-quick-sort-helps-in-increasing-the-efficiency-of-th

I looks like this issue can be closed.


IP Address (Public (on Host) IP/Port) is not taken over correctly

When i setup a new stack via rancher ui with a custom docker-compose.yml the ip address is not taken over correctly. When i try to update the container in the ui the ip address is missing in the "Public (on Host) IP/Port" field.
Example docker-compose.yml:
backend:
  image: nginx
  ports:
  - <IP_ADDRESS>:81:80

Useful
Info

Versions
Rancher v1.0.0 Cattle: v0.159.2 UI: v0.100.3

Access
localauth admin

Route
service.containers

Duplicate of https://github.com/rancher/rancher/issues/4425


Remove CAPAS from clusterctl code

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm

/cherrypick release-0.11


Investigate direct sharing support in IntentPickerSheet

https://www.bignerdranch.com/blog/implementing-android-marshmallow-direct-share/

@hzsweers Isn't this only for providing it (to the native intent-chooser), not really showing it in a view of your own?

We would want to replicate that behavior if possible, rather than showing a separate system sheet on top of our sheet.


Add FormatHelper.java

You would need to clear the formatting after you use a formatting code.

Any glaring issues?


Fallback context

@schleichardt @peter-gerhard @butenkor review please
With this functionality the data coming from the Page classes is combined with other sources, doing a fallback effect. In particular, we are using this to use the JSON coming from the sphere-sunrise-design as a fallback when we still don't have the feature implemented in Sunrise, in order to present a filled template all the time.
Some issues:

Currently those parts of the template coming using a {{#with }} are not being rendered for some reason. Will have to report to the dev of Handlebars Java.
I chose to transform the JSON file to a Map because Handlebars Java only allows Maps for the combine function. I've tried to pass the JSON as parent context and works the same, but I feel combine is better oriented to the functionality we are using, while parent context is mostly used to save the context on nested data. Probably inside uses the same functionality, but it is a semantic issue.
I'm using the TemplateLoader as a way to configure the path, so that we use the same system as we do with the Handlebars TemplateLoaders. Actually the JSON file must be called the same and be equivalent, except for the extension, so technically is not that wrong. If you think it's better to change it, please suggest a better option and I'll change it.

:+1:

solves https://github.com/sphereio/sphere-sunrise/issues/144

I will proceed to merge it, as it is a bit old this PR already.
Any objection?

sry lgtm :+1:

:+1:

@schleichardt I already had your thumbsups, but thanks for emphasize it :D ;)

:+1:

Bit late but looks good :)

:+1:

:+1: ;)


Restyling the project card

Is your feature request related to a problem? Please describe.
Style of the project card is not user friendly. the font size of content is too small and even the size of the card does not look good.

Describe the solution you'd like
I would like to restyle the project card to solve the issue I listed above. It will not only make it user friendly but also make the overall website Attractive.
Please assign this issue to me under SSOC 2.0

I would like to work on this issue under SSOC 2.0.

I have made the pull request for this issue. Kindly review my request.


[bug]: vertical separator not rendering

Describe the bug
When using the separator with a "vertical" orientation it does not render properly. Looking at the browser dev tools it appears to have a size of 1x0 pixels.
Changing the default style here to use min-h-full instead of just h-full seems to fix this.
Seems to be the same as this issue encountered in the shadcn-svelte port
Affected component/components
Separator
How to reproduce

Place a Separator in a flex parent with two other components and orientation "vertical"

Foo

          <Separator orientation="vertical" />

Bar

The separator will not appear
Change style within components/ui/separator.tsx

<SeparatorPrimitive.Root
      ref={ref}
      decorative={decorative}
      orientation={orientation}
      className={cn(
        'shrink-0 bg-border',
        orientation === 'horizontal' ? 'h-[1px] w-full' : 'min-h-full w-[1px]',
        className
      )}
      {...props}
    />

Separator will now render

Codesandbox/StackBlitz link
https://stackblitz.com/edit/stackblitz-starters-t7h9sc?file=components%2Fui%2Fseparator.tsx
Logs
No response
System Info
M2 Mac,
Firefox

Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues

Opened a PR to help fix this!

In my case, I had to define the height explicitly in the className prop. Then, it was displayed.

Yes explicitly setting a height does work but the default behavior of the component should be that it fills up the height of the parent which isn't happening. Can always override that with the className prop even with this change

Yes, agree.

it has an easy fix, on the primitive root change:
 className={cn(
    "shrink-0 bg-border",
    orientation === "horizontal" ? "h-[1px] w-full" : "full w-[1px]",
    className,
  )}

  for:

       className={cn(
    "shrink-0 bg-border",
    orientation === "horizontal" ? "h-[1px] w-full" : "min-h-full w-[1px]",
    className,
  )}

setting min-h-full should fix this this issue when set to vertical

Yes that is the fix I used and it's what I have in the PR I opened for this

doesn't seem to work if the parent is display flex and has items-center to center fields

                  Location

                <Separator orientation="vertical" className="h-full" />

                  Color

                <Separator orientation="vertical" />

                  Size

had to go for grid

                  Location

                <Separator orientation="vertical" />

                  Color

                <Separator orientation="vertical" />

                  Size


Add Civilian Population from SpaceDock

This pull request was automatically generated by SpaceDock on behalf of pamynx, to add Civilian Population to CKAN.
Mod details:
name = /mod/1469/Civilian%20Population
author = pamynx
abstract = Turn your Kerbal society into a Type 1 Civilization by adding civilian exploration!
license = CC-BY-4.0
Homepage =
description = Civilian Population

Turn your Kerbal society into a Type 1 Civilization by adding civilian exploration!
Your agency as research goes on gains the ability to have civilians take part on your exploration.
Once build, your ships, orbital or ground station will welcome civilian that will pay a rent to your agency, breed, grow their kids, get aged and die.
You will also be able to train and recruit civilian to become regular kerbonauts.
As this mod is still under development, all the functionnalities are not available yet.
Credits
This mod is a fork from "Newbier Newb's Revamp of Civilian Population" mod.
It exists thanks to the collective work of :

@Tralfagar that can be found here.
@michaelhester07 that can be found here.
@rabidninjawombat that can be found here.
@GGumby that can be found here.

Licenced under CC BY-NC 4.0.
This mod requires Community Resource Pack.
Any kind of help is more than welcome, pick a TODO above, do it, and I will be glad to accept your pull request.
If you need help to understand how to build the mod, just ask !
Electrical parts

Netherdyne Reactor Unit DX-110
Netherdyne Reactor Unit MX-99

Convert Enriched Uranium into Depleted Uranium, Xenon Gas and Electricity !
TODO :

Rebalance cost.
Rebalance conversion speed.

Turn the lights off when the reactors are off.

    [WRN 00:08:25.564] [ShipConstruct for CivPopReactor]: part cost (15000.0) is less than the cost of its resources (432500.0)
    [WRN 00:08:25.598] [ShipConstruct for SmallCivPopReactor]: part cost (8000.0) is less than the cost of its resources (173000.0)

Science parts

Netherdyne University.

A command and research module.
TODO :

Fix EVA problems when there is not ladder.
Implements training module that will allow to turn civilian into regular kerbonauts.

Utility parts : Apartments

Civilian Large House mk2
Civilian Small Apartment Complex
Civilian Large Apartment Complex
Civilian Contractor Dock Mk1
Civilian Small House

Living quarters for civilians.
TODO :

Add behaviour to the Contractor Dock to have civilian pop grow from it (Modules CivilianDockGrowth & KerbalRecruitment).
Cannot go back in Small House.
Add ladder to Small House.

    [LOG 08:21:59.524] Load(Model): CivilianPopulation/Models/Utility/surfaceAttachHouseSmall
    [ERR 08:21:59.599] Triggers on concave MeshColliders are not supported

    [ERR 08:21:59.600] Triggers on concave MeshColliders are not supported

Utility parts : Farms

Hydroponic Garden Biosphere
Small Hydroponic Garden Biosphere
Netherdyne Farm Biodome Mk2
Small Hydroponic Garden Module

Use plants to grow food, purify water and air.
TODO :

Remove biodome top attach point.
Animation on "Small Hydroponic Garden Module" does not work.

Utility parts : Tanks

Small Fertilizer Tank
Small Waste Water Tank
Small Sustenance Tank

TODO :

Calibrate those to a capacity of 1 day / kerbal.

Utility parts : Drill

Netherdyne XL-9000 Mega Laser Drill
Netherdyne Laser Drill

Laser drilling for surface exploitation.
Ground parts

Cruiser Landing Gear
Cruiser Landing Gear Mk2

TODO ;

Fix legs deployments

@see http://forum.kerbalspaceprogram.com/index.php?/topic/135250-landing-legs-in-11/&page=1
@see KerbalPlanetaryBaseSystems - GameData/PlanetaryBaseInc/BaseSystem/Parts/Wheels/LandingLeg.cfg
Structural Parts

truss18x18NoCore
truss6x18
truss6x6Core
truss6x6CoreL
truss6x6CoreT
truss6x6CoreX
truss6x6NoCore
bioSphereBaseNoWalls

All seems ok.

bioSphereWindows
bioSphereWindowsLarge
bioSphereWindowsWide

TODO : Cannot go inside, should improve attach points.

bioDomeBase
bioDomeBaseLarge
bioSphereBase
bioSphereBaseWallRing
parkbioDomeBase
parkbioDomeBaseRock
parkbioDomeBaseMetal

TODO : Attachment point in the air, cannot go "into" the structure.
Agency
TODO : Add Netherdyne as an agency.
@see KerbalPlanetaryBaseSystems - GameData/PlanetaryBaseInc/BaseSystem/Agencies
@see KerbalPlanetaryBaseSystems - Sources/PlanetarySurfaceStructures/SurfaceStructuresCategoryFilter.cs
Configuration for third party addons
TODO : Kerbalism - Configure farms.
Civilian behaviour
DONE :

Rent of civilian : 200 funds per civilian per day (6 hours).
Civilian contractor growth

TODO :

Civilian recruitment process
Civilian breeding growth
Civilian aging and death

Please direct questions about this pull request to pamynx.

Closing in favour of #5740


Allow simpler user level overrides

Without this path, the default overrides provided contains
the common image overrides.
This is a problem, as it means the deployers who want to override
a single image will have to provide the entire list of overrides.
This fixes the problem by ensuring all the templates have all
the content at all time, so users can override the way they want.
To avoid not repeating ourselves, this patch uses a single
common image overrides files, but it becomes very complex to
follow.
A more surgical approach of the images overrides should be taken
in a later patchset.

@kantarun I believe the templates should represent the "SUSE way". (that's why I prefixed them all with suse-). I therefore believe we should provide templates with our opinionated deployment things (ses, caasp, images,...). I would prefer if those overrides per template are more surgical, as it would give us far more flexibility in terms of overriding by default without userspace overrides.
Keep in mind the overrides file IS what we are doing. The difference, is that we are passing a simple file vs a global file. The reason for that is ease of understanding.
Should we have different levels of "suse default overrides" (project and global), the deployer at the end won't really know what to override, and what the precedence is. ("Do I need to template the project file or the global file here?" "Do my overrides apply if I do this..."). Simplifying to a single level (project) would still allow the deployer to do its own thing, by having a simple mechanism for overrides.
For upstream, I was told the global overrides are used for too many things, and could therefore be phased out in some places. Yet, I believe images is a great use case for a 'global', common, override file.
It's indeed easier for consumers of OSH to have all these images in a file.
In upstream, I wanted to get rid of the multiple level override files, and just put the files into overrides, named it appropriately, like leap15-loci-queens.yml. But that's outside this review :)


Added Uganda Public Holidays and  Unit Tests

References:

https://www.edarabia.com/uganda/public-holidays
https://africapay.org/uganda/labour-laws/work-time-holiday/holidays-and-work

Thanks!


Node Panic Handling

When Smapp is configured to manage a local node and it panics (on startup or at any other time) it should:

Get the exit code from the paniciking go-sm process and use it as hint for further action. Exit-code will indicate if restarting the node should fix the issue or not. When go-sm provides exit codes that indicate if the node can be restarted - use these to provide more info about the issue and to determine if restart button should be displayed.

Display a modal dialog box that the p2p2 node crashed and 3 commands:

Restart Node.

Quit.

Submit a bug report (when submission via telemetry or 3rd party bug reporting solution is implemented).

When user chooses restart, display loading anim and attempt restart local node.

When user chooses to quit - quit Smapp.

When user chooses to submit a bug report - use telemetry or 3rd party bug reporting solution to upload node and smapp logs and create a bug report.

Visual design and copy will be provided.

This issue is outdated. I'm going to close it and open another one about handling node errors in smapp 0.2


Timeouts on prod

Out of a sudden (cannot really be sure when it started) I began receiving timeouts on production like the one below. Things that might have changed are

phoenix version 1.6.x => 1.7.2
sentry installed according to https://docs.sentry.io/platforms/elixir/
maybe chromium version

but I tried rolling back all the above changes, removing all Sentry related lines, downgreading chromium, downgrading Phoenix, downgrading ChromicPDF, extending timeout, ...
Also the setup with 1.7.2 and latest chromium works on dev environment. Does anything from the log below ring any bells what might be causing the timeouts? Any clues what else to try?
Mar 23 22:43:10 cld bash[12537]: ** (exit) an exception was raised:
Mar 23 22:43:10 cld bash[12537]:     ** (ChromicPDF.Browser.ExecutionError) Timeout in Channel.run_protocol/3!
Mar 23 22:43:10 cld bash[12537]: The underlying GenServer.call/3 exited with a timeout. This happens when the browser was
Mar 23 22:43:10 cld bash[12537]: not able to complete the current operation (= PDF print job) within the configured
Mar 23 22:43:10 cld bash[12537]: 30000 milliseconds.
Mar 23 22:43:10 cld bash[12537]: If you are printing large PDFs and expect long processing times, please consult the
Mar 23 22:43:10 cld bash[12537]: documentation for the `timeout` option of the session pool.
Mar 23 22:43:10 cld bash[12537]: If you are *not* printing large PDFs but your print jobs still time out, this is likely a
Mar 23 22:43:10 cld bash[12537]: bug in ChromicPDF. Please open an issue on the issue tracker.
 Some people in the past had issues with timeouts in CI in particular, and often only on the first PDF job (see for instance #160 ), but at times Chrome still seems to inexplicable hang and not send us the messages we're waiting for.
A few things

The protocol in your log is waiting for the Page.loadEventFired notification which indicates the page has in fact not fully loaded (or we somehow didn't get the notification) - but 30s timeout seems long enough and I'm assuming you don't try to print 200 pages or so.
A good thing to have (for you and us) would be metrics about to how often this happens, to evaluate the severity of the problem.
In our case, these timeouts are extremely rare, and we often believe they happen around deployments (though we're not sure about that), which makes them less of a problem for us. Also, we generally put ChromicPDF behind a job queue with retries.

I wish I could say I truly had an idea what causes these timeouts, or how to fix them. But unfortunately no :/
hope this helps a bit,
malte

I'm assuming you don't try to print 200 pages or so

Definitely no. Those are the same types of documents, which I was happy to normally get under one second. I only now increased the timeout to 30s from the default five "just in case" but to no change

A good thing to have (for you and us) would be metrics about to how often this happens, to evaluate the severity of the problem

At this very moment this is 100% on prod - no single document gets out. The browser is:
root@954d2755e171:/app# chromium --version
find: ‘/root/.config/chromium/Crash Reports/pending/’: No such file or directory
Chromium 111.0.5563.110 built on Debian 11.6, running on Debian 11.6

yet I tried downgrading to 108.0.5359.124-1 - no change. I wish I could pinpoint the exact moment the problem started but I can't :-(
FWIW - I get this upon starting the  browser:
[0323/225510.025994:ERROR:bus.cc(399)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory

a few times but I believe they were there before too. Pardon a potentially lame question - you don't use dbus to talk to chrome, do you?

We are using the chrome devtools protocol https://chromedevtools.github.io/devtools-protocol/ to talk to chrome through a remote debugging pipeline similar to how it is described here https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md
Not sure if internally chrome uses dbus to support that, but that maybe a good first thing to try.

Not sure if internally chrome uses dbus to support that

We don't have dbus running in any of our containers, and get the same errors from chromium.
ChromicPDF.print_to_pdf({:html, "hello"})

Interactive Elixir (1.14.2) - press Ctrl+C to exit (type h() ENTER for help)
iex(phxapp@954d2755e171)1> ChromicPDF.print_to_pdf({:html, "hello"})
{:ok,
 "JVBERi0xLjQKJdPr6eE[…]aLEiu3xvrYWn9IhGOYR1nNZmpOa8YwjgK6QDm98FKJ6JkPz+7duZT6tMf30VRrud6rud6rud6rv8f99WSLEPSwUgoahj4nC/e3yEd" <> ...}
iex(phxapp@954d2755e171)2>

I guess this says - "OK"

I guess this says - "OK"

It does. Any noteworthy changes to your template recently? Especially JavaScript stuff?

Wondering if that could be somehow caused by the template (which seem to all work fine on dev env) what could this be. There were no changes to the template. The only template-about changes were related to static assets when migrating to PHX1.7 but I think the first container which exhibited the issue had still 1.6.

Is there a way to somehow get the browser's console output, maybe?

FYI - as a matter of fact it must have gotten broken with migration to 1.7 but wasn't noticed immediately as everything works on dev env all the time and errors started flowing once somebody actually needed to generate PDF on prod. Must have something to do with the changes in static assets handling and chrome apparently waited for the css, which was not served anymore. Works now. Thank you for your support and hind with ChromicPDF.print_to_pdf({:html, "hello"}) 🙇

Glad you could resolve your issue. :+1:

@silverdr matter of fact, maybe could you elaborate a bit more into what happen with the static asset request? Maybe we can improve that timeout error message a bit, mentioning this scenario as a possible cause.

the changes in static assets handling and chrome apparently waited for the css

Did the request hang indefinitely?


Turning h2 blue is not letting me pass the challenge even though I have turned h2 element blue

Challenge use-css-selectors-to-style-elements has an issue.
User Agent is: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0.
Please describe how to reproduce this issue, and include links to screenshots if possible.

CatPhotoApp

Click here to view more cat photos.

Things cats love:

cat nip

laser pointers

lasagna

Top 3 things cats hate:

flea treatment

thunder

other cats

  <form action="/submit-cat-photo">
    <input type="radio" name="indoor-outdoor" checked> Indoor
    <input type="radio" name="indoor-outdoor"> Outdoor

    <input type="checkbox" name="personality" checked> Loving
    <input type="checkbox" name="personality"> Lazy
    <input type="checkbox" name="personality"> Energetic

    <input type="text" placeholder="cat photo URL" required>
    <button type="submit">Submit</button>
  </form>

@ryanmaddox thanks for the issue. Using the code you've provided above, I am able to pass the challenge and continue on to the next challenge. Can you explain more how you're unable to move on? Do you get green check marks for the challenge tests?

I was using Firefox and thought I was in chrome.  I'm going through the
beta fcc and once I complete I would like to get involved more with fcc
maybe doing videos or something anything fcc needs.  Fcc has helped me
focus my knowledge and applying technology
On Apr 13, 2017 12:24 PM, "Eric Leung"<EMAIL_ADDRESS>wrote:

@ryanmaddox https://github.com/ryanmaddox thanks for the issue. Using
the code you've provided above, I am able to pass the challenge and
continue on to the next challenge. Can you explain more how you're unable
to move on? Do you get green check marks for the challenge tests?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/14371#issuecomment-293981634,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFA5obnYfYyYINxDARvu2qwZKh5zpuCSks5rvmhogaJpZM4M7Ye5
.

Snap, using Firefox and have the same issue.

Hi! Thank you for reporting this issue.
This is a known issue with CSS tests in Firefox, only in the beta. We're discussing this problem in #10749
I'm closing this as a duplicate. Happy coding!


Cleanup: Use CustomRun instead of RunObject

v1alpha1 Runs are no longer supported by the PipelineRun reconciler. The PipelineRun reconciler currently operates on RunObjects (an interface which is implemented by v1alpha1.Run and v1beta1.CustomRun). However, this code is misleading, since retry behavior differs between v1alpha1.Run and v1beta1.CustomRun, but the controller only supports the behavior of v1beta1.CustomRuns. This commit replaces usages of RunObject with CustomRun, and renames references to runs/runObjects to customRuns for clarity. No functional changes.
/kind cleanup
Partially addresses https://github.com/tektoncd/pipeline/issues/6628
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

n/a Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
[x] Has Tests included if any functionality added or changed
[x] Follows the commit message standard
[x] Meets the Tekton contributor standards (including functionality, content, code)
[x] Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
n/a Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
n/a Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
NONE

/hold cancel


NuGet Bridge DLLs do not build using .NET 4.0

NuGet packages comes with directories:
lib/net40
lib/net45
Which suggests bridge has DLLs dedicated for .NET framework v4.0 and v4.5. Presumably, v4.5.1 projects will use v4.5 libraries from lib/net45.
Creating a project or changing an existing one to .NET v4.0 results in a correct reference to lib/net40 but the built DLLs are for .NET v4.5. Trying to build will then result in:
1>...\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3274: The primary reference "Bridge" could not be resolved because it was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".
1>...\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3275: The primary reference "Bridge.Html5" could not be resolved because it has an indirect dependency on the assembly "Bridge, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null" which was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".
1>...\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3274: The primary reference "Bridge.Html5" could not be resolved because it was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".
1>CSC : error CS0518: Predefined type 'System.Object' is not defined or imported

Probably it would be a good idea just to remove lib/net40 directory from the NuGet package to save on space for the package.

I am changing the <TargetFrameworkVersion> to v4.0 for all Bridge projects.
Only one Framework version will be available in the NuGet package lib directory, which will install to all .NET projects version from .NET 4.0 to vNext.

There used to be a problem causing spurious references to be unconditionally added if targeting framework >2.0 (some system.linq assemblies). I saw this in VS2010, don't know if the problem has been fixed

I should have clarified that I was changing the <TargetFrameworkVersion> from v4.5 to v4.0. We've been running >4 since release and to the best of my knowledge have not run into any wonky VS referencing issues.
Certainly doesn't mean they're not out there. I will create a few VS test projects using .NET40 before final release of v1.8.0.


Implement a social provider for QQ

Issue by iislucas from Thu Apr 17 04:16:02 2014
Originally opened as https://github.com/UWNetworksLab/UProxy/issues/215
see:
https://github.com/Donkil/Dualx
https://chrome.google.com/webstore/detail/dualxbeta/mdmfkkgbifpockljpdagggdaiheefbpp
uses the oauth-based api, which just needs XHRs.

Closing as this is not a priority right now


Black backgroud with no image casting

I am having an issue with the example program in which I can open the application, connect to the clarius via wifi direct and use the buttons with success but the image from the ultrasound does not appear in the main screen with it just showing the black background. I have made no alterations to the code so I don´t really know why this is happening, any ideas?  Thanks
-Pedro

If you're on Windows, double check your firewall settings, a port may be blocked

Thank you for the quick responde, I just checked and apparently the port is not blocked, any other suggestion?

To confirm, tcp connection is ok, and you can get status messages through the cast program?

The connection is successful and the buttons 'Freeze'/'Run', 'Shallower', 'deeper' are working perfectly. Strangely there is just no casting image.

It's likely the UDP port being blocked still. You could try completely disabling firewall temporarily and see if that helps

I completely disabled my windows firewall and it still didn't work.

[Update] - I tried on Linux and it worked so I guess I'll use it from now on

thanks, I was testing again on Windows, and ran into the same issue. Turning completely off the Windows Defender solved it, but so should adding a blanket port exception for the program.

I'm having this exact same issue running on a Ubuntu VM on Windows, even after disabling Windows defender entirely. Any ideas?

For me it only worked when I disabled windows Defender and then restarted my pc.

For me it only worked when I disabled windows Defender and then restarted my pc.

Thanks for the idea. I tried it and unfortunately it didn't work. Maybe because of the VM, but I'm not sure.

We have not tested the Cast API in containers, but generally make sure the hosted system (Ubuntu in your case) has transparent access to the host network (Windows). For example in Docker, try the host network type:

host: For standalone containers, remove network isolation between the container and the Docker host, and use the host’s networking directly. See use the host network.

Thanks. I decided to just run it in a natively in Ubuntu and it seems to be working without issue, so I assume Windows was blocking it somehow.


Write unit tests for User model

Description : Write unit tests to ensure the User model behaves as expected.
Steps :

[ ] Set up a testing framework (e.g., Jest)
[ ] Write tests for each field in the User model
[ ] Ensure all tests pass

[ ] Create a new branch for this feature:

git checkout main
git pull origin main
git checkout -b feature/unit-tests-user-model

[ ] Install the necessary packages for testing (we'll use Jest for this example):

cd backend
npm install --save-dev jest supertest

[ ] Create a Jest configuration file:

touch jest.config.js

[ ] Add the following configuration to jest.config.js:

module.exports = {
  testEnvironment: 'node',
  verbose: true,
};

[ ] Make sure that your package.json uses the new configuration file:

"scripts": {
  "test:backend": "jest --config jest.config.mjs",
  "test": "ng test"  // Existing Angular test script
}

[ ]  Make sure that your package.json uses the new configuration file:

"scripts": {
  "test:backend": "jest --config jest.config.mjs",
  "test": "ng test"  // Existing Angular test script
}

The package.json file that needs to be updated with the Jest configuration is the one in your backend folder, because Jest is being used to test your backend code.
Here's how you can update the package.json file in the backend folder:
Update backend/package.json
Navigate to your backend directory.
Open the package.json file in a text editor.
Add the test script for Jest.
Example backend/package.json
{
  "name": "backend",
  "version": "1.0.0",
  "description": "Backend for the Angular Social Network project",
  "main": "app.js",
  "scripts": {
    "start": "node app.js",
    "test:backend": "jest --config jest.config.mjs"
  },
  "dependencies": {
    "bcrypt": "^5.0.1",
    "cors": "^2.8.5",
    "dotenv": "^10.0.0",
    "express": "^4.17.1",
    "jsonwebtoken": "^8.5.1",
    "mongoose": "^6.0.12"
  },
  "devDependencies": {
    "jest": "^27.0.6",
    "ts-jest": "^27.0.5",
    "@types/jest": "^27.0.1",
    "supertest": "^6.1.6"
  }
}
This configuration adds a test:backend script that you can run to execute your Jest tests.


Missing asterisk?

Should this line:
Note: Windows PowerShell wildcards other than , such as ?, are not supported by the *Filter syntax.
Say this:
Note: Windows PowerShell wildcards other than *, such as ?, are not supported by the *Filter syntax.

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

ID: 7a11d541-b67b-d5e4-6ca3-05db321746cd
Version Independent ID: 3eb1d45a-94e9-239f-613f-19fd837ab24e
Content: Get-ADComputer (addsadministration)
Content Source: docset/windows/addsadministration/get-adcomputer.md
Product: w10
Technology: powershell-windows
GitHub Login: @coreyp-at-msft
Microsoft Alias: coreyp

@officedocsbot assign @e0i

@mossywell Thank you for your feedback. I dont see the note on the document any more. Either It was removed recently or I'm looking at the wrong document. Can you confirm if the doc is question is  https://docs.microsoft.com/en-us/powershell/module/addsadministration/get-adcomputer?view=win10-ps ?
Thanks
Sri

@msbemba It seems both links are equivalent.

@mossywell
The issue is being closed as we haven't been able to identify the source of error within the referenced documentation.
Feel free to re-open this issue with further clarifications and we would gladly assess the content for updates.
Thank you for your feedback.


Use readline api to manipulate process.stdout output.

Current implementation with process.stdout.clearLine and process.stdout.cursorTo throws TypeError: process.stdout.clearLine is not a function and TypeError: process.stdout.cursorTo is not a function when process.stdout is not a tty.

:+1: Just ran into the same thing with the latest version of prettier:
/Users/kvz/code/invig/node_modules/.bin/prettier --single-quote --print-width 100 --write cli.js

   /Users/kvz/code/invig/node_modules/prettier/bin/prettier.js:221
           process.stdout.clearLine();
                          ^

   TypeError: process.stdout.clearLine is not a function
       at fs.readFile (/Users/kvz/code/invig/node_modules/prettier/bin/prettier.js:221:24)
       at tryToString (fs.js:426:3)
       at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:413:12)

Just ran into this issue while trying to run prettier as an external tool from IntelliJ IDEA.

Good catch, sorry about it! I'll publish 0.17.1 with this fix!

https://github.com/jlongster/prettier/commit/74fb4a43b174eb4f2e1ed549ac30a213e406d870

Good catch, sorry about it! I'll publish 0.17.1 with this fix!

Actually it was my PR 😓
https://github.com/jlongster/prettier/pull/584/files#diff-970aecfd974e4b7ebfc40bf6329bb7b2R218
(now i learn more about streams in node)

Don't stress about it, it wasn't obvious that it would cause an issue in a tty-less environment like intellij :) Good thing is that we can fix it quickly and forget about it!


Update MKLDNN v0.16 -> v0.17

TEST NOW

@gaurides test_mnist_opset7 is failing on ONNX CI. Can you check if this passes reliably with MKLDNN v0.16 or if this is a bug introduced with v0.17?

@jbobba: This test passes with v0.16. for quick check I checked the results of recentlly merged PR1963
tests_core/test_zoo_models.py::OnnxBackendZooModelTest::test_mnist_opset7_cpu PASSED

TEST NOW


Improvements on the landing page

This is a...

[ ] Feature Request
[ ] Bug Report
[x] Improvement Report

Problem:
correct and improve content on the main landing page
Proposed Solution:
instead "Since 2001, IFC is a data model structure that makes it possible to hold and exchange relevant data between different software applications"
write "IFC, short for "Industry Foundation Classes", are a data schema enabling the exchange and sharing of relevant data between different software applications in the construction and operation of built facilities. Having the roots back to 1996, the IFC have been continuosly enhanced to support software interoperability for openBIM."
instead "openbim
Digital building data represented in the EXPRESS data modelling language enable the application of an expanding set of building elements for a building."
write "openBIM
Digital construction and operation data representations provided in either the EXPRESS or XML Schema data modeling language to built interfaces to share different model elements for built assets."
instead "BuildingSmart mark of approval
This specification, ISO 16739, developed and updated by Buildingsmart International gives your customers assurance when using your software in their workflows"
write "buildingSMART mark of approval
This specification, ISO 16739, developed and updated by buildingSMART International, and fomally standardized by the International Standard Organization, ISO, gives your customers assurance when using your software in their workflows"
Page to Update:
http://ifc-tech.org

@TLiebich I have made updates as described above.


Datepicker locks in value after spinner stops first time on ipad

When using this plugin in ipad, the value (in my case it's a time selector) is locked in as soon as you release your finger the first time after changing a value of hours or minutes. Then if you move a slider again, it's ignored.
For example, if the time picker opens, and the initial value is 12 | 00 | PM, and you drag the hour wheel to   2 and release, then 2 | 00 | PM is your selected value. Even if you spin the wheel again to another value, you're stuck with the original 2. You have to click away from the popup (no cancel or save buttons for ipad) and then re-open the picker to change the value.

Hi @frey1esm  ,
I have this same problem.

Hopefully the author @VitaliiBlagodir can take a look at this.

+1

+1


[java client] Bugfix prevent dup consumers for same topic subscription

Fixes #3743 issue.
Return previous instance of a consumer in the subscription processed should only
be considered with the scope of the same topic.
Modifications

Filter consumers for the same topic name.
Filter consumers which are connected to broker, this is not necessary to fix
this issue but is a good thing to do.
Add test that verifies that same subscription will allow different consumers
instance for different topics.

Verifying this change

[x] Make sure that the change passes the CI checks.

@jiazhai @sijie I removed this optimization for pattern subscription and for multi topics subscription, which now will only affect single topic subscription.
In order to add this optimization for pattern and multi topics subscription a different approach must be taken, I will push this on a different pr if you agree.

In order to add this optimization for pattern and multi topics subscription a different approach must be taken, I will push this on a different pr if you agree.

@lovelle sounds good to me. +1

@lovelle Agree. use reference-count, and handle it when close is a good way

Thanks for the work @lovelle

run integration tests

@sijie @jiazhai Great! :+1: thanks you both for the feedback.
So when checks are success this pr will be ready to be merged!

run java8 tests
run integration tests

run java8 tests

Merged in 2.3.1 at
cc638d3


Page navigation from search should expand TreeView and select page

Describe the bug
When you search for a page like ItemsRepeater in the sample app you're taken directly to the page, but you have no idea where that page exists in the navigation tree. It would help with the discovery of similar controls if they page is brought forth as the selected/opened page in the NavigationView.
Steps to reproduce the bug

Go to Sample App
Search for a control in the search box
Select a choice to navigate to that page from the dropdown

Expected behavior
Page selected in NavigationView.
Actual behavior
No indication of which page I'm viewing in hierarchy.
Screenshots

Version Info

Gallery version (found on Settings page):
<IP_ADDRESS>
Windows 10 version:

[x] Insider Build (19624)
[ ] November 2019 Update (18363)
[ ] May 2019 Update (18362)
[ ] October 2018 Update (17763)
[ ] April 2018 Update (17134)
[ ] Fall Creators Update (16299)
[ ] Creators Update (15063)
[ ] Anniversary Update (14393)

Device form factor:

[x] Desktop
[ ] Mobile
[ ] Xbox
[ ] Surface Hub
[ ] IoT

Additional context

@chingucoding do you know if your solution (PR #478) can be applied to the two issues mentioned above?

#613 is partially fixed (the selection indicator is missing), #726 is not fixed.


Moving Pictures tutorial references core-metrics --p-counts-per-sample

The new name is --p-sampling-depth.

Put this in the wrong repo. Moved to https://github.com/qiime2/docs/issues/22


fix(docker-entrypoint): clean-up dangling unix sockets

This change adds a clean-up step to remove all sockets that a previous Kong run may have left in $PREFIX directory.
Dangling unix sockets have been a pain point in recent Kong versions and was dealt in traditional Kong in Kong/kong#9254, but the kong script is not called when starting Kong inside a container, so a similar change to docker-entrypoint.sh was added here.
FTI-4525

There's a nearly identical entrypoint script at ubuntu/docker-entrypoint.sh. Do these changes need to be added there as well?

There's a nearly identical entrypoint script at ubuntu/docker-entrypoint.sh. Do these changes need to be added there as well?

Yes, they should.

There's a nearly identical entrypoint script at ubuntu/docker-entrypoint.sh. Do these changes need to be added there as well?

Good catch! Added the same set of changes to that file.


stability issue

ensure that you reset prev_loc to zero for every fuzz attempt, as otherwise the first edge ID calculated is always different, resulting in "new paths" being found that are not.

Thanks for the advice!

is the stability now 100% or did it just slightly improve?

Also you read the fuzz data from stdin, correct? There is also the feature of shared memory fuzz data. the forksever in fpicker only has to set a specific bit on the intial status sent and map the shmem for it (from its specific env var). this is quite faster and has no kernel overhead. the length of a specific fuzz case is in the first 4 byte of the memory, and the memory size is MAX_FILE + 4.


Group Sync Permission Bug [Solution]

Known bug, while doing ur group sync permissions all OP get the permission ofc,
TO FIX you do a minus permission in ur permissions manager.

Fixed bug in https://github.com/NamelessMC/Nameless-Plugin/commit/d909f009133e61826d8a145a7b88297439e09411

Also fixed at https://github.com/NamelessMC/Nameless-Plugin/commit/60d90400a1ae1bcf9216480c5b7506449dcf69f2

This did not fix the issue for me. Also - non op players groups don't update on the website..


Add built-in metrics to TOC

Fixes #29790
Don't merge until #29760 merges.

Copy/paste your changes after https://github.com/dotnet/AspNetCore.Docs/pull/29760 merges.

It's an easy copy/paste to the current aspnetcore/toc.yml
You can reopen when https://github.com/dotnet/AspNetCore.Docs/pull/29760 merges and see if there are merge conflicts. I don't like to keep aspnetcore/toc.yml PR's open so long, that goes double when there are build errors.


feat: Allow non 204 status for null JSON responses

Introduces a new application option emptyBodyAs204 that must be set explictly to false when creating the Koa app to prevent Koa from treating null body as 204.
Set it via
new Koa({
  response: {
    emptyBodyAs204: false
  }
});

Closes #998
I'll provide documentation updates when we decided on a final name.

why not set the status after setting body = null?

null should do mean no-content actually, I guess what @damianobarbati want is a option to disable the automatic reset on .status?

@jonathanong @yorkie I'm not sure 204 is correct: there's a body because there's a payload, a json-serializable payload.
The payload holds the content null (not undefined).
The response of the API call is null. Nothing more, no object wrapping.
I'm not sure whether you are understanding what I mean 🤔

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/null

The value null represents the intentional absence of any object value.

I think the primitive null means there is no content(absence) on the body, if someone wants to respond the "null", I think ctx.body = 'null' is necessary to specify it's a string.
@damianobarbati as I mentioned before, how about adding an option to disable the automatic status reset globally, which will make the status will not be set to 204 when you set the body to null, and it might be more useful usually.

@damianobarbati as I mentioned before, how about adding an option to disable the automatic status reset globally, which will make the status will not be set to 204 when you set the body to null, and it might be more useful usually.

That's what this PR provides, isn't it?

This PR is just adding an option for a specific case

I don't think add this option is a good idea, it is easy to implement a middleware to handle this.
(ctx, next) => {
  await next();
  if (ctx.body === null) {
    ctx.body = 'null';
  }
}

Great idea! I think that should work for you @damianobarbati?

@pke @dead-horse thanks but I did already try before opening the issue a very long time ago and I had no way to overcome the 204: I suspect Koa is doing something when body is null preventing me from setting any body.
In the following snippet am I doing something wrong? Is it supposed to work?
And I guess I have to set the content-type manually too, right..? 😔
import koa from 'koa';
const app = new koa();

app.use(async (ctx, next) => {
    await next();

    if (ctx.body === null) {
        ctx.set('Content-Type', 'application/json; charset=utf-8');
        ctx.body = 'null';
    }
});

app.use(async ctx => ctx.body = null);

app.listen(80)

@yorkie yes I think an option to prevent the aforementioned (default) behaviour of Koa would work.
My concern isn't only about the inability to provide a null json, I guess it's rather a philosophical concern.
The 204 on json payload of null looks like a (smart) bias to me.
It's definitely the best move because typically when a you set body to null you are returning... nothing.
But here the payload is not null: the payload is a JSON string.
The value expressed by the payload is the primitive null.
It's ambiguous when it comes to API request and response:

consumer request the content of something
producer response the content is null

But the producer must return a message (json string) expressing the content is null (null value encoded) to consumer.
The consumer shouldn't be inferring the content (null) from the http headers (204), because it expects a payload in the agreed format (json) expressing null (string) and not an empty response.
Koa has a right default behaviour covering most of cases, still I think an opt-out should be given to developers.
But I'm just discussing/brainstorming guys! It's not my intention to start a flame 😅

community didn't raise this so far and I can find some kind of workaround
koa is great and your work is amazing 😈


app hang's iPhone (iOS)

Using Jason app this url works the first time, then hangs the phone
http://kadist-ios.herokuapp.com/knews_with_templates?channel=kadist&lang=en
steps:

open above link in jason
after a few seconds template is evaluated and replaces body, all good
then click the top/left back link (in header)
open above link
hangs on jason.body never replaced by template evaluation, even though I see the networking completed.

Sometimes I can't even open my phone for a while after this happens.
Thank You!!

Could you post a quick video?
I just followed your instruction but couldn't replicate it, maybe I misunderstand the instruction. Thanks!

I can make a video. I just tried it again just now and it reproduces for me. The second time coming into the app the initial animated gif never gets replaced by the real content and I can't even kill Jason for a while. It always recovers and I can restart Jason. All I do is open the json URL and then back out once the content proper loads and open it again. I have the latest Jason app.

On May 5, 2017, at 7:45 AM, gliechtenstein<EMAIL_ADDRESS>wrote:
Could you post a quick video?
I just followed your instruction but couldn't replicate it, maybe I misunderstand the instruction. Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@gliechtenstein -
gif/video

demo attached.

on Android this works fine, just tried that. If you can help with a few possible breakpoints I can try to debug it.

Just fixed this with https://github.com/Jasonette/JASONETTE-iOS/commit/17a10af24349aaf3d8257fce998e34c0747f6cff
This was caused by a bug in SDWebImage library where the completion handler was not being called reliably (as reported here https://github.com/rs/SDWebImage/issues/1209)
The solution was to directly use the SDWebImageDownloader.sharedDownloader.
Please try it out and let me know if it works!


docs(tabs): fix the Tabs example to work properly and without type errors

Closes #76
📝 Description
Modified the example for custom Tabs and removed the broken parts. Replaced them with the useMultiStylesConfig API.
⛳ Current behavior (updates)
Type errors when using the factory with themeKey the example.
🚀 New behavior
No more type errors and example working as expected when pasting.
💣 Is this a breaking change (Yes/No):
No
📝 Additional Information

@nikolovlazar Ready to review again :)


Discussion on *WU instructions

Continuation of off-topic discussion in #10.
Quick summary:
@jhauser-us:

[T]here's a whole category of instructions that would have more impact but aren't currently included, and that is the unsigned equivalents of the existing RV64I *W instructions: ADDWU, SUBWU, SLLWU, etc. These would be just like the existing *W instructions but instead zeroing the upper 32 bits, as appropriate for an unsigned int or uint32_t result type rather than int or int32_t. We hardly need to run any experiments to know that such *WU instructions would be used far more frequently than the *W instructions proposed for the B extension.

@cliffordwolf:

The idea behind *W instructions is simply that they operate on the lower 32 bits. It makes sense to have a consistent scheme for how to fill the upper bits, but it doesn't matter much what this scheme is exactly, if that scheme is sign-extend or zero-extend.

@brucehoult:

If you provide *W operations you have to decide what to do with the upper bits. You can leave then alone (x86), zero extend them (Aarch64), or sign extend them (RISC-V). If you leave them alone then casting a 32 bit value to a 64 bit value requires a sext or zext every time. If you sign extend them then only unsigned values require a zext, signed ones are already correct. If you zero extend them then only signed values require a sext, unsigned ones are already correct. It's hard to say which is better. Most normal application code uses signed more than unsigned, favouring sign extension

@jhauser-us:

Andrew has told me he wants to keep open the option for *WU instructions for now, which implies to me we should devise a system to reserve the encoding space now, even if the idea eventually gets dropped. I haven't run this particular system by him yet, but I intend to do so soon.
Naturally, we would want any system that's adopted to be fully compatible with the B extension, by tweaking either or both as necessary. I'll be looking into this question soon. And now you or anyone else can do so too, if you're so inclined.
But this is getting off-topic for this GitHub issue, so we should move the discussion elsewhere if you'd like to continue.

@brucehoult:

I agree that there is merit in systematically adding *WU versions of R-type instructions that have *W versions. If you do it at all then it should be for BOTH the base instruction set and for any new *W instructions in the BitManip extension.
This is easily affordable in terms of opcode space by, as has been pointed out, using something in the hi bits of the instruction, keeping the identical opcode and func3 to the *W version. It's also very cheap to implement.
Probably the only OP-IMM-32 instruction that can be justified is ADDIWU. That does need a new opcode.

@jhauser-us:

Interestingly, in a message to me yesterday where we talked about possible *WU instructions, Andrew literally wrote:

I’m not opposed to putting them in B.

To be sure, that expresses ambivalence more than advocacy. But as far as "could be persuaded" goes, I believe yes.

After that I conceded that there is a reasonable way to add *WU instructions and described the encoding that I would prefer.
I hope everyone feels like this summary treats them fairly. Please post your corrections below.

I've been think a lot about this the last two days. Here are some thoughts.
A *WU instruction would get rid of a single PACK whenever we convert (in C, typecast) a 32-bit unsigned int to a 64-bit in (signed or unsigned). In this case we could use *WU instead of *W for a 32-bit DAG, and could replace the final ALU+PACK with just one final ALU op.
You might ask why I'm talking about DAGs here instead of just the final operation before the cast to a 64 bit datatype. It's because of this:
uint32_t a = some_32_bit_expression + 3;
uint32_t b = another_32_bit_expression * a;
uint32_t c = a | b;
uint64_t x = c;

right now that would be:
ADDIW a0, a0, 3
MULW a1, a1, a0
OR a0, a0, a1
PACK a0, zero, a0

and with *WU:
ADDIWU a0, a0, 3
MULWU a1, a1, a0
OR a0, a0, a1

So what I'm trying to illustrate here is that this is really all-or-nothing. There are certain instructions, such as OR, that just preserve the W-ness or WU-ness or their arguments, and therefore didn't get their own *W variants. Because of this we can't just implement *WU for the most common ops that appear directly before a typecast. We have to provide *WU instructions for essentially all OP opcodes that do not preserve WU-ness. That means *WU would cost a lot of encoding space. But of course it also makes the HW decoder implementation simpler.
So far so good.
But we can't mess with the RISC-V calling convention of course. So whenever we pass an uint32_t to another function we still need to make sure it's properly sign extended.
So let's add a function call:
uint32_t f32(uint32_t);
uint32_t a = some_32_bit_expression + 3;
uint32_t b = another_32_bit_expression * a;
uint32_t c = (a | b)  ^ f(a);
uint64_t x = c;

right now that would be:
ADDIW a0, a0, 3
MULW a1, a1, a0
OR s1, a0, a1
CALL f32
XOR a0, s1, a0
PACK a0, zero, a0

And maybe I'm just not trying hard enough but I can't see any way how *WU could help here to make that sequence shorter (assuming f32() is an external function that the compiler can't see into).
Same of course if we are processing function arguments:
uint64_t foo(uint32_t a, uint32_t b) {
  uint64_t x = a, y = b;
  return x + y;
}

Right now:
foo:
PACK a0, zero, a0
PACK a1, zero, a1
ADD a0, a0, a1
RET

And nothing *WU can do for us here afaict.
Similarly, using the same 32-bit value signed in one expression and unsigned in another can mean we can't actually reduce the code size with *WU.
Idk. Am I focusing on the wrong cases? To me this looks like a compressed PACK-zero instruction would be more helpful than the entire set of *WU instructions (but idk if this is frequent enough to warrant spending a compressed instruction on it).
@asb Can you add something from the compiler perspective to this discussion?
@aswaterman Can you maybe post a few lines what added value *WU instructions would need to deliver in order to warrant the encoding space, in your opinion?

Hey @cliffordwolf, I've been meaning to get engaged in this discussion but haven't made time for it yet.
As @jhauser-us alluded to on the other thread, it's not the case that I'm strongly advocating for these instructions.  It's just that their potential utility has crossed my mind, and if they are indeed worthwhile, it seems pragmatic to package them with the B extension.  They deserve the same quantitative evaluation as any other compiler-targetable candidate instruction in the B extension.
My intuition is that ADD[I]WU and SUBWU are the most interesting candidates, but I agree with @jhauser-us that it's worth going through the exercise of laying out the opcode map for the entire set of candidate instructions.
I agree with you that PACK can do most of the heavy lifting.
My main motivation is to improve address-calculation sequences, because they are ubiquitous and can have a material impact on dynamic instruction count in loop-based code.  For this reason, I don't concur with the "all-or-nothing" assessment: these sequences are almost never terminated in a bitwise operation, for example.
Here's a somewhat contrived example where ADDIWU helps but, as far as I can see, PACK does not:
uint64_t *array = foo();
uint32_t index = bar();
return array[index + 1];

The address-calculation part of that code compiles to
addiw a0, a0, 1
slli a0, a0, 32
srli a0, a0, 29
add a0, s0, a0

whereas instead it could compile to
addiwu a0, a0, 1
slli a0, a0, 3
add a0, s0, a0

Without the "+ 1", PACK would work equally well, of course.
Later today, I'll try to look over some real code sequences where I believe there is a benefit.
Two more notes in the mean time:

I don't think SLL[I]WU helps in address-calculation sequences, because the cast occurs prior to the shift.  More generally, it could be beneficial to have instructions that zero-extend their inputs instead of their outputs.  Of course, such instructions might add datapath cost, whereas the *WU instructions are essentially costless in that respect.

I am happy to volunteer time to conduct GCC-based compiler experiments for these instructions.  I can also help with evaluating other aspects of the B extension (but only for the operations that the GCC middle-end already understands).

Hey @aswaterman

My main motivation is to improve address-calculation sequences, because they are ubiquitous and can have a material impact on dynamic instruction count in loop-based code. For this reason, I don't concur with the "all-or-nothing" assessment: these sequences are almost never terminated in a bitwise operation, for example.
Here's a somewhat contrived example where ADDIWU helps but, as far as I can see, PACK does not:

That's very helpful. Thanks.

My intuition is that ADD[I]WU and SUBWU are the most interesting candidates

I've been playing in compiler explorer a bit and I can see what you mean.
To me it looks like ADD[I]WU, SUBWU, and SLLI and ADD with one "WU-input" would be most useful.
int8_t f(int8_t array[][3], uint32_t index) {
   return array[index][0];
}

Is now:
  pack a1,zero,a1
  slli a2,a1,1
  add a1,a1,a2
  add a0,a0,a1

and could be:
  slli_rs1wu a2,a1,1
  add_rs1wu a1,a1,a2
  add a0,a0,a1

I agree with @jhauser-us that it's worth going through the exercise of laying out the opcode map for the entire set of candidate instructions.

In this context I would propose that the "entire set of candidate instructions" isn't necessarily a complete WU-mirror of W, but instead a richer set of variations (WU-inputs and/or WU-outputs) over a smaller set of underlying instructions. Most of the instructions in the current B spec I would not consider candidates. I think MINUWU/MAXUWU is the only one that would make sense to consider.

More instructions worth debating imo: MULI MULIW MULIWU MULWU

The add[i]/sll[i]/sub variants that zero-extend their rs1 inputs are worth considering.  Still want the add[i]/sub variants that zero-extend their outputs instead, but probably not the corresponding sll[i] ones.
For completeness I'll also mention the following option, though it is less attractive for datapath design reasons.  We could instead provide shift-by-small-constant-then-add instructions, i.e., rs1 + (rs2 << {0, 1, 2, 3}).  Alpha has this feature in the form of S4ADDQ and S8ADDQ, and x86 has it in the form of LEA.  We could consider adding three such instructions (zero-extend rs1, sign-extend rs1, and pass rs1 through unmodified).
MULI is harder to swallow, given that it will perform worse than short shift-and-add sequences in some implementations.

MULI is harder to swallow, given that it will perform worse than short shift-and-add sequences in some implementations.

I was thinking about MULI* in addition to the add and shift instructions, for the cases where the MUL is unavoidable.
int8_t f(int8_t array[][52], uint32_t index) {
   return array[index][0];
}

Right now:
  pack a1, zero, a1
  li a2,52
  mul a1,a1,a2
  add a1,a0,a1

Could be:
  muli_rs1wu a1,a1,52
  add a1,a0,a1

So I guess I'm proposing to consider something like the following instructions:
ADDWU
SUBWU
ADDIWU
ADD_RS1WU
SSLI_RS1WU
MUL_RS1WU
MULI
MULIW
MULI_RS1WU

The encoding space requirement for all the MULI* scare me a bit. But I would guess that all three of them would be used quite a lot in address calculation code.

My intuition is that MULI etc. won't have sufficient benefit to justify their encoding space, especially since the constant load can be hosted out of a loop.  But, as usual, we should favor the quantitative approach over the intuitive one.  I can help run experiments on these instructions, too.

I agree, both with your intuition that it's probably not worth it, and that we should favor the quantitative approach over the intuitive one.

I can help run experiments on these instructions, too.

A quick initial experiment, just patching the compiler a bit to get a quick initial estimate for how much use we'd get out of those instructions, would help a lot.
If that initial experiment already shows negative results we probably don't need to bother with MULI any further. Otherwise I'd be happy to include them in the B draft so we can collect more data in a more systematic way.
Anything to add to the remaining list of candidates?
ADDWU
SUBWU
ADDIWU
ADD_RS1WU
SSLI_RS1WU
MUL_RS1WU

I think those three *_RS1WU should cover every case where we want to do something after the unsigned conversion to 64-bit and before the final LB/LW/SW/etc.
I'd guess ADDWU, SUBWU, and ADDIWU cover most of the cases where we would want to merge the conversion into the output node of the expression within [...], but we should probably consider more instructions. Obvious additional candidates imo are MULWU and SLL[I]WU, possibly even MINWU/MAXWU, but realistically I wouldn't expect any of them to be worth it.

Okay, I'll try to run that experiment soon.  I have a flow for measuring the impact on static code size for SPEC 2006, which isn't perfect, but at least it's a lot of code.

Here are some initial results.  The static instruction count savings is probably understated, because there are more tricks GCC could be taught.  The static code size savings should be taken with a grain of salt because GCC doesn't do a wonderful job at RVC-aware instruction selection.

A ZEXT.W instruction (e.g. PACK) saves 0.27% static instructions and 0.11% static code size.  (The code-size savings is smaller because PACK only reduces code size when one of the shifts isn't compressible.)
An SLLI_RS1WU instruction saves an additional 0.21% static instructions and 0.13% static code size (total 0.48% / 0.24%)
ADDIWU, ADDWU, and SUBWU collectively save an additional 0.10% static and 0.17% static code size, with ADDIWU accounting for a significant majority.  (Presumably the code-size savings exceeds the instruction-count savings because these instructions changed some other code-generation decision.)
An SLLIWU instruction has almost no discernible effect.
ADDI_RS1WU and ADD_RS1WU are not much better--less than 0.01% in both metrics.
I did not look at any of the MUL instructions, because they account for under 0.2% of static instructions in SPEC.  Given that only a few percent could be optimized, they wouldn't make a measurable difference in these static metrics.

One way of thinking about this is that ZEXT.W provides only about half of the benefit that SLLI_RS1WU, ADDIWU, ADDWU, and SUBWU collectively provide.

Thanks for performing the test. I think that helps a lot.
Right now in the B draft spec, C.NOT operates on rd, not rd'. I've been thinking about changing this for RV64/RV128 so that it operates on rd' there, with free space to add compressed ZEXTW (RV64/RV128) and ZEXTD (RV128). Your thoughts?
They say never do math in public. Especially when using dodgy approximating assumptions. I'll ignore that advise for now. Large likelihood of facepalm-worthy math mistakes ahead..
(Those percentages are all very close to 0%, so I'll just act as if percentages add, i.e. I'll assume a 0.5% reduction ontop of a 0.5% reduction is a 1% change, when in fact it's only a 0.9975% change.)

ZEXT.W instruction (e.g. PACK) saves 0.27% static instructions

Since one ZEXTW replaces two shift, I'd assume this means 0.27% static instructions of the compiler output is ZEXTW instructions.
Assuming 50% of overall instructions are compressed, 0.27% static instructions that are all uncompressed means approx 0.40% of static code size (0.27*1.5=0.405). Therefore, adding C.ZEXTW should further reduce code size by 0.20%.
So combined with the gain from an uncompressed ZEXTW, adding ZEXTW+C.ZEXTW should get us a static code size improvement of 0.31%.

SLLI_RS1WU instruction saves an additional 0.21% static instructions and 0.13% static code size

If we compress ZEXTW, then combining ZEXTW+SLLI is 50% less effective. So I guess this would then only be a 0.065% improvement in static code size.

ADDIWU, ADDWU, and SUBWU collectively save an additional 0.10% static and 0.17% static code size

Same argument as above should give us 0.085% improvement for ADDIWU, ADDWU, SUBWU.
So in summary, only looking at code size reduction:

Extensions
Uncompressed ZEXTW
Compressed ZEXTW

ZEXT
0.110%
0.310%

SLLI_RS1WU
0.130%
0.065%

ADDWU
0.170%
0.085%

And accumulative:

Extensions
Uncompressed ZEXTW
Compressed ZEXTW

ZEXT
0.110%
0.310%

ZEXT+SLLI_RS1WU
0.240%
0.375%

ZEXT+SLLI_RS1WU+ADDWU
0.410%
0.460%

Or, assuming SLLI_RS1WU and ADDWU are independent:

Extensions
Uncompressed ZEXTW
Compressed ZEXTW

ZEXT
0.110%
0.310%

ZEXT+ADDWU
0.280%
0.395%

ZEXT+ADDWU+SLLI_RS1WU
0.410%
0.460%

with ADDIWU accounting for a significant majority.

I think C.ZEXTW+ADDIWU (maybe even without ADDWU/SUBWU) sound like an interesting option. It's fairly simple, easy to implement, and gets us pretty close to the results of the "everything" option.
I'd prefer only-ADDIWU over only-SLLI_RS1WU because it's the simpler instruction, easier to implement, and possibly slightly more effective. ADDIWU requires more encoding space than SLLI_RS1WU, but on the other hand it's a very simple encoding.
PS: To be honest I'm kinda disappointed that SLLI_RS1WU seems to perform so well in your test.  So I might be a bit biased against poor SLLI_RS1WU.   :)

Add-with-small-shift will increase latency in some implementations, so is a harder sell.
SLLI_RS1WU is ungainly for sure. Should look at dynamic instruction counts before ruling it out, though.
C.NOT targeting rd instead of rd’ seems like overkill. Having a ZEXT there will probably help more.

ADDI_RS1WU and ADD_RS1WU are not much better--less than 0.01% in both metrics.

That result kind of puzzles me. Is it possible that this code base contains no byte-arrays? (char-arrays? strings?) I would have expected ADD_RS1WU utilization for that.
void example(char *dst, char *src) {
  unsigned i = 0;
  while (src[i]) dst[i] = src[i] ^ 6, i++;
  dst[i] = 0;
}

(ADDI_RS1WU I would have expected to be worthless.)

Yeah, not sure what the explanation is.  Not too many byte arrays surely has something to do with it.  In your particular example, GCC makes a strange choice, but if I simplify the example to use only one array, it does use ADD_RS1WU.  So it's not that the compiler is broken.

(I'm now calling the instructions that zero-extend at the input *UW and the ones that zero-extend at the output *WU. Not perfect, but prettier than *_RS1WU.)
My current thinking is to include the following instructions in the draft spec and then see what a more thorough evaluation will show:
ADDIWU
ADDWU, SUBWU  (?)
ADDUW, RSUBUW
SLLIUW

Afaict ADDUW, RSUBUW and SSLIUW should actually be sufficient for all the address calculation cases that don't need MUL. Am I missing something? Would be interesting to see what results you get with just those three instructions.
Even though we don't "subtract" in address calculations after the cast, we need RSUBUW because we might want to subtract the un-shifted value as part of the shift-add/sub pattern for simple multiplies.
And it needs to be RSUB, otherwise we'd zero-extend the wrong argument. Or we move the zero extend to rs2 for ADD/SUB (but of course leave it on rs1 for SLL).
I'm ambivalent about ADDWU and SUBWU.

ADDIWU, ADDWU, and SUBWU collectively save ..., with ADDIWU accounting for a significant majority.

How significant? I'm currently leaning a bit towards including ADDIWU, but not bothering with ADDWU and SUBWU.

Like 70%, IIRC.  ADDWU and SUBWU are very cheap to provide in terms of both opcode space, and including them has no effect on the datapath and will likely reduce control cost.  So I think they should be included if ADDIWU is included.
RSUBUW is a lot more costly than the other instructions, as it requires conditionally inverting an ALU input that doesn't currently require it.  Given that addition is vastly more common than subtraction in address calculations, I don't think it can be justified.  I think RSUBUW also has a special case for when rs1[31:0] == -1; need to suppress the carry into bit 32.
ADDUW is quite a bit easier to swallow than RSUBUW, as the zero-extension can be folded into the operand muxing at only control cost.

RSUBUW is a lot more costly than the other instructions, as it requires conditionally inverting an ALU input that doesn't currently require it.

That's why I suggested performing the zero-extension on rs2. XLEN/2 ANDs is significantly cheaper than XLEN XORs.

Given that addition is vastly more common than subtraction in address calculations, I don't think it can be justified.

One address calculation has at most one RSUBUW, but can have multiple ADDUW. But if you need an explicit zero-extend for the SUB then there is no gain from having the ADD with built-in zero-extend.

I think RSUBUW also has a special case for when rs1[31:0] == -1; need to suppress the carry into bit 32.

I don't think so. The following seems to do the expected thing when compiled and run, and passes formal verification for all x values with cbmc --function demo demo.c:
#include <stdio.h>
#include <stdint.h>
#include <assert.h>

int64_t ssliuw(int64_t rs1, int shamt)
{
        int64_t rs1_zext = (uint32_t)rs1;
        return rs1_zext << shamt;
}

int64_t rsubuw(int64_t rs1, int64_t rs2)
{
        int64_t rs1_zext = (uint32_t)rs1;
        return rs2 - rs1_zext;
}

void demo(int32_t x)
{
        int64_t sx = x;
        int64_t ux = (uint32_t)x;

        printf("X:   0x%016llx\n", (long long)x);
        printf("SX:  0x%016llx\n", (long long)sx);
        printf("UX:  0x%016llx\n", (long long)ux);

        int64_t ref = ux*7;
        int64_t tst = rsubuw(sx, ssliuw(sx, 3));

        printf("REF: 0x%016llx\n", (long long)ref);
        printf("TST: 0x%016llx\n", (long long)tst);

        assert(ref == tst);
}

int main() {
        demo(-1);
        return 0;
}

Like 70%, IIRC. ADDWU and SUBWU are very cheap to provide in terms of both opcode space, and including them has no effect on the datapath and will likely reduce control cost. So I think they should be included if ADDIWU is included.

I was hoping for more like 90%. I'm not worried about opcode space or datapath complexity. More about finding nice encodings for all those ADD/SUB instructions without trampling over yet untouched funct7 space. But I think I have a good plan for how to add ADDWU and SUBWU. I will write it up later today.

You’re right, there’s no special case, you just need to perform the
truncation before the complement when computing rs1 + ~(trunc)rs2 + 1
On Fri, May 17, 2019 at 2:14 AM Clifford Wolf<EMAIL_ADDRESS>wrote:

RSUBUW is a lot more costly than the other instructions, as it requires
conditionally inverting an ALU input that doesn't currently require it.
That's why I suggested performing the zero-extension on rs2. XLEN/2 ANDs
is significantly cheaper than XLEN XORs.
Given that addition is vastly more common than subtraction in address
calculations, I don't think it can be justified.
One address calculation has at most one RSUBUW, but can have multiple
ADDUW. But if you need an explicit zero-extend for the SUB then there is no
gain from having the ADD with built-in zero-extend.
I think RSUBUW also has a special case for when rs1[31:0] == -1; need to
suppress the carry into bit 32.
I don't think so. The following seems to do the expected thing when
compiled and run, and passes formal verification for all x values with cbmc
--function demo demo.c:
#include <stdio.h>
#include <stdint.h>
#include <assert.h>
int64_t ssliuw(int64_t rs1, int shamt)
{
int64_t rs1_zext = (uint32_t)rs1;
return rs1_zext << shamt;
}
int64_t rsubuw(int64_t rs1, int64_t rs2)
{
int64_t rs1_zext = (uint32_t)rs1;
return rs2 - rs1_zext;
}
void demo(int32_t x)
{
int64_t sx = x;
int64_t ux = (uint32_t)x;
    printf("X:   0x%016llx\n", (long long)x);
    printf("SX:  0x%016llx\n", (long long)sx);
    printf("UX:  0x%016llx\n", (long long)ux);

    int64_t ref = ux*7;
    int64_t tst = rsubuw(sx, ssliuw(sx, 3));

    printf("REF: 0x%016llx\n", (long long)ref);
    printf("TST: 0x%016llx\n", (long long)tst);

    assert(ref == tst);

}
int main() {
demo(-1);
return 0;
}
Like 70%, IIRC. ADDWU and SUBWU are very cheap to provide in terms of both
opcode space, and including them has no effect on the datapath and will
likely reduce control cost. So I think they should be included if ADDIWU is
included.
I was hoping for more like 90%. I'm not worried about opcode space or
datapath complexity. More about finding nice encodings for all those
ADD/SUB instructions without trampling over yet untouched funct7 space. But
I think I have a good plan for how to add ADDWU and SUBWU. I will write it
up later today.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-bitmanip/issues/14?email_source=notifications&email_token=AAH3XQS65CCH7TZJQMBVDQLPVZZO7A5CNFSM4HMK24H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVUHBOY#issuecomment-493383867,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH3XQWNG64MPTEERLCHSETPVZZO7ANCNFSM4HMK24HQ
.

The latest draft now contains ADDWU, SUBWU, ADDIWU, ADDU.W, SUBU.W, and SLLIU.W instructions that address above issues with 64-bit address calculation with 32-bit indices. Looking forward to a more detailed analysis when there's proper compiler support.


Color appears darker

Hi,
it seems that i have a huge color difference between the things i send from unity and what i receive in the receiver, everything appears darker. I don't know if it comes from me or from Spout. When i look at the render texture in Unity the colors are ok in the scene but not in the texture preview. Any ideas on that?

Is it similar to this ?
http://spout.zeal.co/forums/topic/creating-spout-sender-for-vbs3/#post-1748
I would first suspect a a texture format problem.

Yes it is. I tried all allowed format in unity but it does not change anything

What do you mean with render texture preview? Do you select the rendertexture asset in the Project view and look at the inspector preview? If there is a differenc to the scene view output you have to be aware that every spout sender uses a separate camera to render.If you use the demo scene then just open the hierachy on the Main Camera. There are the separate Spout render cams. So if you change something on your scene camera you have to adjust the spout cams!


Library ignores the capitalized map_D in material file.

I came across with a material containing map_D(note the capitalized D). I wander if the library could identify such words(making them all lower cases, for example). For now, it seems that the library just ignore this.

Currently tinyobjloader distinguish upper and lower case strings. Thus map_d is supported but map_D is not supported.
PR for lowering string is welcome.


[Juno CI]: Problems with jspm cert

in asset-server build there is a problem with the download step
[generate_importmap]::downloadFile: error with url<EMAIL_ADDRESS>node:internal/process/promises:288
            triggerUncaughtException(err, true /* fromPromise */);
            ^

Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames: Host: ga.jspm.io. is not in the cert's altnames: DNS:*.rbxcdn.com, DNS:*.cachefly.net, DNS:rbxcdn.com
    at new NodeError (node:internal/errors:405:5)
    at Object.checkServerIdentity (node:tls:337:12)
    at TLSSocket.onConnectSecure (node:_tls_wrap:1610:27)
    at TLSSocket.emit (node:events:517:28)
    at TLSSocket._finishInit (node:_tls_wrap:1017:8)
    at ssl.onhandshakedone (node:_tls_wrap:803:12) {
  reason: "Host: ga.jspm.io. is not in the cert's altnames: DNS:*.rbxcdn.com, DNS:*.cachefly.net, DNS:rbxcdn.com",
  host: 'ga.jspm.io',

there was a problem at jspm
https://github.com/jspm/project/issues/311
but something is now broken in our asset-server image

Fixed adding a retry on the DonwloadFile method which fetch the packages from jsmp. See commit:

https://github.com/sapcc/juno/commit/317076c2896544c600108af654211cbc7dd176b6
https://github.com/sapcc/juno/commit/72d4969cfbe7b4f675d8c3c3b524db4251c56cf8

We should observe if JSPM can or will fix the issue:
https://github.com/jspm/project/issues/311


Consider adding Python version of Wang-Landau example

This would not be too difficult, and would probably be useful, although it would be challenging to run the code long enough to get results comparable with the Fortran version.

Programs written and tested, using a more modest example of N=6 rather than N=13.


Package support: flutter_processing

Pub package: https://pub.dev/packages/flutter_processing
I believe flutter_processing would enable a new world of visual samples for DartPad

This is now available in production DartPad


make it compile on the latest Nim devel

https://github.com/nim-lang/Nim/commit/c86b1fbcac11520380ad15e103a8ec429228d735 introduced some breakages all over the place. This should make rosencrantz compile again on the latest Nim devel

Wow, you were quick! I test daily and I had not even yet realized this! :-D Thank you very much!

Wow, you were quick!

That's what she said :P

I test daily

That's good to hear. We test couple of your packages, but if there's something we break and we don't catch it, let us know.