Can't set state in use hook

Expected behavior
When seting state like this
app.use(function (state) {
  state = {
    a: 'some',
    b: 'value'
  }
})

then, the state should be able to access props like state.a and state.b
Actual behavior
Above code didn't work for me. I had to do
app.use(function (state) {
  state.a = 'some'
  state.b = 'value'
})

Steps to reproduce behavior
Run the above code, I haven't any repo yet, but if needed I will have one tomorrow ;)

You can't reassign the state object in the scope, JS doesnt handle Objects
that way; you need to assign properties to the existing object that's
passed down in the callback.
So do state.foo =, or Object.extend(state, newProps). Hope that makes
sense!
On Thu, Aug 10, 2017, 00:18 Yerko Palma<EMAIL_ADDRESS>wrote:

Expected behavior
When seting state like this
app.use(function (state) {
state = {
a: 'some',
b: 'value'
}
})
then, the state should be able to access props like state.a and state.b
Actual behavior
Above code didn't work for me. I had to do
app.use(function (state) {
state.a = 'some'
state.b = 'value'
})
Steps to reproduce behavior
Run the above code, I haven't any repo yet, but if needed I will have one
tomorrow ;)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/choojs/choo/issues/544, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWlerkiUSzRFbIE9xmTkrUak1jYXKu0ks5sWjAigaJpZM4OytkQ
.

It makes sense, thanks for the answer.

Yay, happy to help!
On Thu, Aug 10, 2017, 14:45 Yerko Palma<EMAIL_ADDRESS>wrote:

It makes sense, thanks for the answer.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/choojs/choo/issues/544#issuecomment-321540443, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACWletj7XVHt5_kHYjBVp3tV3cm7tIgbks5sWvtagaJpZM4OytkQ
.

@yoshuawuyts ... also got some questions within the same topic:

Is there any examples on how to use immutable states? (maybe with immutable.js?)
Why barracks got dropped out since v5 (app.model)? Is there a way to still use it with v6?

Best :)

@rafaelamorim

To use immutable, I believe you can just assign immutable objects to properties of state, and then have your components use that.
Barracks still exists https://github.com/yoshuawuyts/barracks. I would love to see an example of someone hooking it up to Choo 6.  I haven't tried it yet.


barc c++ code added (just for state_estimation_DynBkMdl.py, ekf.py, system_models.py)

barc for_c++ code added (just for state_estimation_DynBkMdl.py)

these are C++ version codes for state_estimation (3 states, 6 states)
hope it helps many people who want get c++ codes instead of python codes
precise test will be needed because I haven't tested it carefully :-) Thx


⚠ Bofrost.ch has degraded performance

In f29bd66, Bofrost.ch (https://www.bofrost.ch) experienced degraded performance:

HTTP code: 200
Response time: 3337 ms

Resolved: Bofrost.ch performance has improved in 81b1c6f after 21 minutes.


route-href params.bind parsing

'0B955A54-DC1D-46DB-8593-1D762E1AEBBB'
I'm submitting a bug report

Library Version:
1.1.1 Aurelia Router
Operating System:
Windows 8.1
Node Version:
69.5
NPM Version:
4.1.2
JSPM OR Webpack AND Version
JSPM 0.16.51
Browser:
Chrome 56
Language:
TypeScript 2.1

Current behavior:
If you use route-href as:
route-href="route: content; params.bind: {navigationId: 1234}"
it works just fine.  The 1234 is shown in the route URL and the param navigationId is available in the activate screen lifecycle hook as a string property of the params object
If you use route-href as:
route-href="route: content; params.bind: {navigationId: AAAA}"
The route URL does not contain the AAAA
If you use route-href as:
route-href="route: content; params.bind: {navigationId: 0BCD}"
the following exception is thrown:
Unhandled rejection Error: Parser Error: Missing expected } at column 17 in [{navigationId: 0BCD }]
which is not a helpful message for this problem.  The '0' is numerical zero.
If you use route-href as:
route-href="route: content; params.bind: {navigationId: '0CDE'}"
then the route behaves correctly in the route URL and the params object in activate hook
Expected/desired behavior:

What is the expected behavior?

I would have expected the parser to give the same parsing error for the AAA and 0BCD cases above.
I would have expected a more informative error message for the 0BCD case.

What is the motivation / use case for changing the behavior?
Motivation is to prevent a developer losing time figuring this out for themselves, (to add the quotes)  like I had to.

AAAA is a valid property name. Since you are using a binding, it's looking for that property on the vie- model. So, no error. The second case, you've got an invalid JavaScript symbol, so it produces an error.


Black screen when screen capturing

I don't know if it's a Hyprland specific issue, but when I try to capture my screen using programs like OBS and Webcord, I get the prompt for choosing the window I want to capture, but it'd just show a black screen
I tried the unofficial NVIDIA package (hyprland-nvidia-git), all I could capture was specific screens & entire screen would be black again
I tried switching from xdg-desktop-portal-hyprland to wlr, but I got the same result
If you think you know where the problem is I'd be happy to send log files of it if necessary
(Note that I didn't upload screenshots or a video of it because.. I can't)

well, it's an nvidia issue. Dupe of #2000. You may want to try the patch I posted there


xtensa/esp32: Refactor the text heap and add RTC memory to it

Summary

Use the slow RTC memory (8KB) as a separate heap.  This is used to allocate text for dynamic code loading.
Refactor the text heap section to use both IRAM and RTC memories.

Impact
ESP32 only.  The RTC option is disabled by default.
Testing
esp32-devkitc:elf esp32-devkitc:module esp32-devkitc:sotest

LGTM


Updates ion-c to latest commit, fixes clippy warnings

Commit 1 updates ion-c-sys' dependency on ion-c to the latest commit on the master branch.
Commit 2 addresses several (correct) clippy warnings that seem to have been added in Rust 1.62.

This will be the last change before the version bump to v0.12.0.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

I also updated ion-c-sys' dependency on bindgen from v0.59.2 to v0.60.1 to pick up this fix.
This eliminates the wall-of-warnings that's emitted using older versions of bindgen:


Resource part path not specified correctly for sub-resources

Try creating /blarg and then adding a new route like /blarg/by_blargname

when calling psychic_disco deploy_new_routes <api-name>:
Updating build_manager-list_builds
        Deploying Resource: /builds/by_trial
        Deploying Resource: /builds
                Deploying Method: GET
Updating build_manager-list_builds
Traceback (most recent call last):
  File "/usr/local/bin/psychic_disco", line 6, in <module>
    exec(compile(open(__file__).read(), __file__, 'exec'))
  File "/home/ec2-user/Projects/psychic-disco/bin/psychic_disco", line 90, in <module>
    args.func(args)
  File "/home/ec2-user/Projects/psychic-disco/psychic_disco/cli.py", line 29, in <lambda>
    sp.set_defaults(func=lambda args: _apply_args_to_func(args, f))
  File "/home/ec2-user/Projects/psychic-disco/psychic_disco/cli.py", line 17, in _apply_args_to_func
    return func(**local_args)
  File "/home/ec2-user/Projects/psychic-disco/bin/psychic_disco", line 22, in deploy_new_routes
    api.deploy()
  File "/home/ec2-user/Projects/psychic-disco/psychic_disco/api_gateway_config.py", line 107, in deploy
    resource.deploy()
  File "/home/ec2-user/Projects/psychic-disco/psychic_disco/api_gateway_config.py", line 170, in deploy
    pathPart=self.path_part)
  File "/usr/local/lib/python2.7/site-packages/botocore-1.4.10-py2.7.egg/botocore/client.py", line 236, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "/usr/local/lib/python2.7/site-packages/botocore-1.4.10-py2.7.egg/botocore/client.py", line 500, in _make_api_call
    raise ClientError(parsed_response, operation_name)
botocore.exceptions.ClientError: An error occurred (BadRequestException) when calling the CreateResource operation: Resource's path part only allow a-zA-Z0-9._- and curly braces at the beginning and the end.


fix: load/merge profiles in the correct priority

Fixes:

Now the init function works correctly with the default parameters
Load and merge of profiles now respects the priority order

Other:

Make load configuration non-recursive and organize modules
Add tests and requires at least 90% coverage to deploy
Update README to remove references to a fallback file that (never implemented)

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix iteration in render

Iterate based on segment sequence from PROMPT_ELEMENTS arrays in __p9k_render. To make it work, keys in associate array __p9k_segment_cache are set as cache_key="${alignment}::${segment}".
With above change, cache update in vi_mode is reorganized. All the single item cache update steps are separated into __p9k_refresh_cache_item.
__p9k_refresh_cache_item "vi_mode" "true"

###############################################################
# @description
#   Refresh a single item/segment in the cache
##
# @args
#   $1 segment name
#   $2 boolean true to trigger prompt rendering
##
function __p9k_refresh_cache_item() {
...

Additional work is done in __p9k_async_wrapper to pass segment name into callback. Otherwise, the segment value from __p9k_segment_cache may be transformed as STATEFUL_NAME.

Hah! Good catch @laggardkernel !
The problem here is that associative array have no order in ZSH. I tried to overcome this limitation by using alignment and index as cache key and order by that. This seems not to work as expected. What seems to work is:
typeset -A XX
XX=(left:5 E left:3 C left:1 A left:4 D left:2 B)
for letter in "${(o@v)XX}"; do print "$letter"; done

This code should bring the letters in order and could be used the same way in the segment cache. The initial idea was to process the cache items in order of appearance in the prompt, hence we do not need the name here..

typeset -A XX
XX=(left:5 E left:3 C left:1 A left:4 D left:2 B)
for letter in "${(o@v)XX}"; do print "$letter"; done

This code should bring the letters in order and could be used the same way in the segment cache. The initial idea was to process the cache items in order of appearance in the prompt, hence we do not need the name here..

It seems the (o@v) modifier is not a reliable solution for me.
P9K_LEFT_PROMPT_ELEMENTS=(context dir vcs::async node_version::async nvm::async rbenv::async anaconda::async pyenv::async vi_mode status command_execution_time background_jobs time)
P9K_RIGHT_PROMPT_ELEMENTS==()

for data in "${(o@v)__p9k_segment_cache}"; do echo "$data"; done
ANACONDA·|·left·|·7·|·false·|·()·|··|·false
BACKGROUND_JOBS·|·left·|·12·|·false·|·0·|··|·false
COMMAND_EXECUTION_TIME·|·left·|·11·|·false·|··|··|·false
CONTEXT_DEFAULT·|·left·|·1·|·false·|··|··|·false
DIR_HOME·|·left·|·2·|·false·|·~·|··|·true
NODE_VERSION·|·left·|·4·|·false·|··|··|·false
NVM·|·left·|·5·|·false·|··|··|·false
PYENV·|·left·|·8·|·false·|·3.6.8:2.7.16·|··|·false
RBENV·|·left·|·6·|·false·|·2.6.3·|··|·false
STATUS_OK·|·left·|·10·|·false·|··|· ·|·true
TIME·|·left·|·13·|·false·|·%D{%H:%M:%S}·|··|·true
VCS_CLEAN·|·left·|·3·|·false·|··|··|·false
VI_MODE_INSERT·|·left·|·9·|·false·|·I·|··|·true

Strange enough it works for me.. At least sometimes (my small example works, but not yours..).
Anyhow, I'd really like to get rid of the second loop because this part should run as fast as possible. Could you try to sort the keys and access the array then?
typeset -gAh TEST_CACHE

TEST_CACHE=(left::7 'ANACONDA·|·left·|·7·|·false·|·()·|··|·false' left::12 'BACKGROUND_JOBS·|·left·|·12·|·false·|·0·|··|·false' left::11 'COMMAND_EXECUTION_TIME·|·left·|·11·|·false·|··|··|·false' left::1 'CONTEXT_DEFAULT·|·left·|·1·|·false·|··|··|·false' left::2 'DIR_HOME·|·left·|·2·|·false·|·~·|··|·true' left::4 'NODE_VERSION·|·left·|·4·|·false·|··|··|·false' left::5 'NVM·|·left·|·5·|·false·|··|··|·false' left::8 'PYENV·|·left·|·8·|·false·|·3.6.8:2.7.16·|··|·false' left::6 'RBENV·|·left·|·6·|·false·|·2.6.3·|··|·false' left::10 'STATUS_OK·|·left·|·10·|·false·|··|· ·|·true' left::13 'TIME·|·left·|·13·|·false·|·%D{%H:%M:%S}·|··|·true' left::3 'VCS_CLEAN·|·left·|·3·|·false·|··|··|·false' left::9 'VI_MODE_INSERT·|·left·|·9·|·false·|·I·|··|·true')

for item in "${(o@kn)TEST_CACHE}"; do echo "${TEST_CACHE[$item]}"; done

Could you try to sort the keys and access the array then?

Iteration over keys works as expected.
❯ for item in "${(o@kn)__p9k_segment_cache}"; do echo "${__p9k_segment_cache[$item]}"; done
CONTEXT_DEFAULT·|·left·|·1·|·false·|··|··|·false
DIR_HOME_SUBFOLDER·|·left·|·2·|·false·|·…/romkatv---powerlevel10k·|··|·true
VCS_MODIFIED·|·left·|·3·|·false·|· master    9·|· ·|·true
NODE_VERSION·|·left·|·4·|·false·|·10.15.3·|· ·|·true
NVM·|·left·|·5·|·false·|··|··|·false
RBENV·|·left·|·6·|·false·|·2.6.3·|··|·false
ANACONDA·|·left·|·7·|·false·|·()·|··|·false
PYENV·|·left·|·8·|·false·|·3.6.8:2.7.16·|··|·false
VI_MODE_INSERT·|·left·|·9·|·false·|·I·|··|·true
STATUS_OK·|·left·|·10·|·false·|··|· ·|·true
COMMAND_EXECUTION_TIME·|·left·|·11·|·false·|··|··|·false
BACKGROUND_JOBS·|·left·|·12·|·false·|·0·|··|·false
TIME·|·left·|·13·|·false·|·%D{%H:%M:%S}·|··|·true

Could you change the code accordingly? I would like to merge this :)
Btw. Thanks for taking the time to create this PR and test it out.

What about changes made on __p9k_refresh_cache_item, do you need it?

Yes, please. I think this is useful. 👍

Done. vi_mode refreshing code is separated into __p9k_refresh_cache_item.
BTW, the thing I really wanna merge back from my port of this "condition_async" in spaceship, is in another pr. It will make sure we can exit early as normal in segment functions with just command exit, without doing cleanup work. I've rebased it onto current pr.

Thx @laggardkernel ! I'll now have a look at #42


Investigate Potentially Extraneous Testing Libraries

David, we have the following libraries in apps/web/package.json:
{
  "devDependencies": {
    "@testing-library/dom": "^9.3.4",
    "@testing-library/jest-dom": "^6.2.0",
    "@testing-library/react": "^14.1.2",
    "@testing-library/user-event": "^14.5.2",
    "jsdom": "^23.2.0",
  },
}

Please check if these are being used for something. If not, remove them and make sure the tests still work.

Just tested it now these packages are not needed to run the E2E test suite.

Okay great please make a PR to remove. We will add later if needed for something else.


Problem with my Udemy Business

i have a problem when i try to connect with my Udemy business i put the link to my udemy business but i don't have acces to put my email and password
here is the link to my udemy business
https://indra.udemy.com
please fix it if you can and try you if you have acess to the login page because with my browser it work perfectly

i didn't understand why you respond to the other issue but my issues you  didn't answer  ?

@RAFIKADO I am currently maintaining this software for critical bug fixes only, I reply to the issues which point to a critical bug like recently we had a download error issue for attachments. And even if I find multiple issues on same subject, I sometimes ignore that because I am mostly at work.
And I have previously tried to get in touch with many users who were having issue with business account and that required them to share the account credentials with me, which they couldn't provide.
But since your issue is not specific to the courses or any download error, I will have a look and get back to you.

I tried using the business account url you mentioned. Seems to be working fine for me. I am seeing the login screen. I am not sure if you are referring to something else. But yes one thing I want to add is that the given website takes some time to load. So you might have to wait a bit if you are not seeing the login screen. I will add couple of screenshots here for you to compare (if you are using it the same way)

ah no< i have the access to the business acount thank you so much but when i try to download i have this message :

in the site i have the access i mean with my account with the browser but the app when i click on downloadi have this message:
You do not have permission to access this course .


Alarm Icon

Hi friend
In traccar, How Do you can to change the icons of the vehicule actual position , actualy i view a blue triangle. Also, How I can view on the map the alarm , when i push the SOS buttom.
Thank you

If you want to change icon, you need to make some modifications to MapController class.

this is, i should create a java proyect and compilate all the proyect al install the .jar?
or i can change any file on traccar server?

You can change JavaScript files without compilation. You just need to enable debug mode for web interface.

I enable debug mode on the servero or the client?

Please read linked thread carefully.


List of tests for each config

We have multiple Ibex configurations currently, listed at https://github.com/lowRISC/ibex/blob/master/ibex_configs.yaml, which enable a different set of functionality.
To run full DV regressions (in CI), I need a list of tests which are expected to pass for each configuration. For example, the small configuration doesn't have PMP and shouldn't run the PMP tests.
Currently, we run make -C dv/uvm/core_ibex ISS=spike IBEX_CONFIG=${{ config }} (with ${{ config }}) being replaced by one of the supported configurations). Can we somehow expand the tooling to also pick the right set of tests? I can see two options (there might be more):

Add the test list to ibex_configs.yml
Modify the tests to skip themselves when the right RTL parameter isn't set

The second options seems more flexible to me and it will also help users who don't run with a config, but just set the parameters directly.
Ideally, we can come up with a way to "discover" the required set of tests in some of the tooling we have in the repository, and don't hard-code this list into the CI configuration. This will allow human users to run (hopefully) a single command to get the right set of tests for their config.
@udinator @GregAC

I think I agree with the second option here, I don't think that adding the static test list to each config is the right way of doing this.
Potentially a simple implementation method would look like this:
- Add anew  list field to each YAML entry, containing the (if any) RTL parameters that it needs to run properly
- In sim.py, skip a test from being processed if any of its requisite parameters aren't present (probably a quick for loop)

One question I do have - this (or a similar approach) would probably require that the sim.py script have access to the list of parameter values from `ibex_configs.yaml.
@GregAC is this possible to do with the configs flow that you set up?

I think I agree with the second option here, I don't think that adding the static test list to each config is the right way of doing this.
Potentially a simple implementation method would look like this:
- Add anew  list field to each YAML entry, containing the (if any) RTL parameters that it needs to run properly
- In sim.py, skip a test from being processed if any of its requisite parameters aren't present (probably a quick for loop)

One question I do have - this (or a similar approach) would probably require that the sim.py script have access to the list of parameter values from `ibex_configs.yaml.
@GregAC is this possible to do with the configs flow that you set up?

sim.py could read ibex_configs.yaml directly easily enough. The other option would be to pass config details into sim.py using ibex_config.py. ibex_config.py is designed to read the config YAML and produce appropriate arguments for different tools so we'd add a new option for it to generate appropriate sim.py arguments.
I'd tend towards the first option, ibex_config.py could be imported into sim.py so we don't have two different implementations of config file reading (there's very little to it but there's a default file specified and an environment variable override, plus if we do make things more complex in the future we don't want to separately implement new features in two different places).

sim.py could read ibex_configs.yaml directly easily enough. The other option would be to pass config details into sim.py using ibex_config.py. ibex_config.py is designed to read the config YAML and produce appropriate arguments for different tools so we'd add a new option for it to generate appropriate sim.py arguments.
I'd tend towards the first option, ibex_config.py could be imported into sim.py so we don't have two different implementations of config file reading (there's very little to it but there's a default file specified and an environment variable override, plus if we do make things more complex in the future we don't want to separately implement new features in two different places).

Sorry for my delay here, have been tied up with other OT work.
@GregAC I agree with the first option as well, I'll draft a sample implementation soon and get a PR ready.

Great, thanks a lot @udinator!

This functionality has been added


Confusing cmake message when xcb libs are not found

Suppose I don't have libxcb-composite0-dev installed, I get:
CMake Error at /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message):
  Could NOT find XCB (missing: XCB_LIBRARIES)
Call Stack (most recent call first):
  /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:343 (_FPHSA_FAILURE_MESSAGE)
  CMake/FindXCB.cmake:23 (find_package_handle_standard_args)
  src/CMakeLists.txt:68 (find_package)

-- Configuring incomplete, errors occurred!
See also "/home/aengelen/dev/wlc/CMakeFiles/CMakeOutput.log".

Changing XCB_LIBRARIES to ${XCB_LIBRARIES} in CMake/FindXCB.cmake gives a more enlightening error, but my cmake skills are too limited to determine whether that makes any sense :)

I can see why replacing variable with string works here, the documentation for the function however only talks about variables. I agree that the messages aren't that great, however the variable name here is actually useful, when you want to manually control it. You can see what got assigned to the variable from CMakeCache.txt, or cmake-gui (most likely under "advanced" variables).
Some downstream Find*.cmake files seems to print out manually the variables during find, however I'd rather not do this.


Enhance README organization, add more background info to code

Heya,
When I first read the Rune readme, there were a couple of things I thought could be improved:

I didn't understand where methods like appendMotheredHuman etc come from. We "magically" have access to something we didn't define and it feels strange. It gets described later on, but it would have been nice for a comment to say "Hey, don't worry! I'll explain why this magic-method exists in a little bit!"
DataDraw doesn't get mentioned, and I had to piece the connection together myself. In my opinion, a HUGE amount of appeal comes from the fact that DD is integrated into Rune, and it's very interesting + explains much of the behavior and design decisions/architecture + performance.

Also, many people will want to jump directly to specific things ("how do I build this?", "show me a code example?") without reading the rest of it, so I tried to add enough context to each section that it would make sense if you went straight there and skipped the rest.
Lastly, I added some organizational structure and a TOC so folks can navigate the page easier.
Hope this is helpful, I'd like to highlight Rune in the best way possible for potential users as I think it has some neat ideas 🙂

Ahh, one last thing -- I chose the languages for the syntax highlighting for each code block based on which one looked the best/could highlight the majority of the tokens:
Go:
// Check the MAC (message authentication code) for a message.  A MAC is derived
func checkMac(macSecret: secret(string), message: string, mac: string) -> bool {
    computedMac = computeMac(macSecret, message)
    return mac == computedMac
}

Rust (TypeScript comes close too, but not quite as good):
class Human(self: Human, name: string, mother: Human? = null(self), father: Human? = null(self)) {
  self.name = name
  if !isnull(mother) {
    mother.appendMotheredHuman(self)
  }
}

Sorry about the random formatting changes that removed only spaces in the diff.
VS Code auto-format did that -- I didn't catch it in the PR. I can resubmit if it's an issue.

I just learned about the dataview tool and figured out what it does, it'd be neat to mention that as well in the README!

Thanks for all the work on documentation!


Old Keyboard (iOS7?) still in use

On the left, the current keyboard (in the messages app) on an iPhone 6, iOS 8. On the right, the same phone and iOS version, but in a React Native app.

It took a designer to point this one out.  We're under the impression that the keyboard in use by React Native is outdated.  This playground app shows the same old keyboard.

Seeing your screenshot, it looks like your app is running in compatibility mode on an iPhone 6.
i.e. iOS doesn't see your app as supporting the native resolution on iPhone 6/6 Plus.
That's probably because you don't have a LaunchImage for iPhone 6/6 Plus.
If your app runs on iOS 7, LaunchScreen.xib is not supported there (it was introduced in iOS 8) and you must have the<EMAIL_ADDRESS>and<EMAIL_ADDRESS>in your app bundle.
You can specify them using the asset catalog.

Thanks @jeanregisser, I just saw this SO post explaining it.  Issue soon to be resolved!


Fix misspelling: keyborad -> keyboard

Thanks for your contribution! Before we can merge it, the source files need to be renamed as well:
./src/icons/keyborad_arrow_down.svg
./src/icons/keyborad_arrow_left.svg
./src/icons/keyborad_arrow_right.svg
./src/icons/keyborad_arrow_up.svg

Thanks!


ISSUE-47: refactor to ZipArchive and bump dependencies

Overview
See #47
This pull removes external library dependencies for ZIP management. Since most of the operations done are quite basic using PHP ZipArchive seems like a simpler future proof solution.
Other changes:

Presence of zipArchive class is done via a static method on the Package Class. Its a bit strict since some methods could work without ZIP access but it hard to assume people could make real use of the library without it.
PHP 7.1 as base requirement. Keeping up with 5.6 seems like a complex idea and also frictionlessdata/tableschema goes in that direction
There was a tiny bug in Utils::removeDir that was assuming all paths would be a dir
Test were updated
General (first pass) Coding Standards and some PHPDOCs updates. This will require a few more passes to be completely compliant (I need to learn more about the package to make sure type hinting of arguments is consistent with the callers and the docs)
Some type hints I could check were actually correct in terms of the method callers/implementations.

Note: All tests are passing in PHP 7.1, 7.2 and 7.3 but manual testing is still needed.
Since the changes here may feel like larger, I would propose this could be a new 0.2 version.
Thanks a lot, please let me know if something makes no sense and needs refactor and thanks again for this wonderful library

Please preserve this line to notify @OriHoch (lead of this repository)

@OriHoch CI is failing for obvious reasons. Wonder if you would be OK if i move from php-cs-fixer to phpcs to also extend the testing to PHP 7.4. Issue is that php-cs-fixer is only compatible until PHP 7.1 and 7.1 is already EOL.
If yes. Would be going --standard=psr2 in conformance with this project's coding standards?
(checked and its almost there, just a few things that can be fixed automagically via phpcbf)
I can update Travis, etc if that is the case. Please let me know, I have a few hours tomorrow and would like to give this a full refresh and bump also PHP combat up.
Pushed some CI ideas
Thanks

@OriHoch sorry for the delay here. Got distracted with our own many GitHub issues and upcoming releases.
Now `\frictionlessdata\datapackage\Package::isZipPresent`` is called on in methods that actually need it, sometimes a bit earlier to avoid generate Temporaries. Tests passed and Coding Standards (PSR-2) too. I did a lot of PHPDocs indenting so that makes a bulk of this
In any case the composer.json is already stating that ext-zip (same as the old chumper/zipper did) so its quite impossible to deploy with out zip support, but you never know (like partial zip support, where people forget to copy the .so in place).
Hope I got it right this time! Thanks a lot for your time and patience

looks great, thanks!


Standard List usage

According to standard, use LinkedList in priority, not use Lists.newArrayList() of Guava.
Changes proposed in this pull request:

Modify Lists.newArrayList() to new LinkedList<>

Pull Request Test Coverage Report for Build 9394

1 of 3 (33.33%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 64.577%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

shardingsphere-sql-parser/shardingsphere-sql-parser-mysql/src/main/java/org/apache/shardingsphere/sql/parser/visitor/MySQLDDLVisitor.java
0
2
0.0%

Totals

Change from base Build 9392:
0.0%

Covered Lines:
10960

Relevant Lines:
16972

💛  - Coveralls


idris2: 0.2.0 -> 0.2.1

Motivation for this change
Updating idris2 to latest version 0.2.1
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

\cc @bcdarwin

I think we're all reviewed and ready to roll, just need someone with permissions to merge.
pinging @veprbl and @Lassulus (as they've merged previous idris2 PRs)


Feat: Enhance the AI ChatBot Working #147

Fixes: #147
From

to

I have tried to keep the design as similar as possible but there are not enough customizations available to keep the design the same. Also please check your mail for working video.

Okay this looks good. Make sure you have pulled all the changes from origin to your branch because recently various PRs have been merged.

yes ma'am i have done that, there are no conflicts


Updated badges

Build status was not accurate and updated all to use shields.io

Thanks Jason! 👍

Question: Is it possible to have the badges dynamic based on the branch the user is looking at? Just wondering since this is hardcoded to master.

Sure, you'd just have to update the Readme.md per branch. Pull request? :P
On 7 Dec 2016 11:32, "Kyle Welch"<EMAIL_ADDRESS>wrote:

Question: Is it possible to have the badges dynamic based on the branch
the user is looking at? Just wondering since this is hardcoded to master.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/coryhouse/react-slingshot/pull/337#issuecomment-265346182,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAvnfa72bB0WCOXyXD0pJcDBK6B0hbVeks5rFii6gaJpZM4LGJyj
.

Coverage remained the same at 95.0% when pulling bf9681472b35bcdffe868b852272875075ff373f on jasonnathan:patch-1 into ef28b5475fdda8ab9db805d0f157dc81d671aadb on coryhouse:master.

I don't think that is necessary, wasn't sure if there was a variable that could be used in place of master to do it "auto-magically"


Option to show/hide reposts in Publishes (claim type filter?)

Right now, your publishes page will show your reposts, which has been confusing to some folks. It doesn't even show you reposted it, just looks like one of your claims.  We should at least mark them in the UI.
This may be a good opportunity to add a claim type filter to this area and show reposts = off by default?

The repost label not showing is fixed with https://github.com/lbryio/lbry-redux/pull/284 and https://github.com/lbryio/lbry-desktop/commit/80dddf8f9eb6ba11d7890a5ffbc612f4e3897a48

This is now possible.


jobs: Temporarily fake kLevelMod data to avoid error

Fixes #3788
https://github.com/quisquous/cactbot/blob/54303910154b6ae5847780f1dbac616ce629a381/ui/jobs/utils.ts#L142
[0,0] will cause a 0 division error, so make it 9999 to make unknown gcd about 2.5
382 at lv81 and 400 at lv90 are confirmed, others are assumed.

Thank you!!


Support configurable sender address

Consist of
### Tasks
- [ ] #333
- [ ] #215

Closing/merging to #584


Changed PrimitiveTypes to match GL naming.

Changed the PrimitiveTypes to match GL naming.

As you can see, this changes the public API and therefore breaks existing code. And that cannot be done for SFML 2.x.
If you have some suggestions that include breaking changes, come over to our forum to discuss them for SFML 3.
PS: next time, please at least include a description with your PR.

See also the contribution guidelines.

A non-breaking way of "fixing" this issue would be to introduce the new names while keeping the old ones and marking them deprecated.

I've also sometimes wondered about the names of some primitive types, so I generally agree to this PR. And @binary1248's idea of deprecating the old names sounds very good indeed, this would allow for inclusion before SFML 3.
Did we really have to close this?

So you want to break the public API, add deprecated symbols and some confusion, just for a few 's'?

I disagree, I find this to be important. It's part of the naming consistency, which should be the same in every spot in SFML. Otherwise you could also argue that typos are not important, e.g. "steColor": Why break the public API just for a "e" and "t"?
The public API would not be broken. The wrong symbol names would be kept until the next major version, next to the correct ones:
enum PrimitiveType
{
  LinesStrip = x,
  LineStrip = x,
};

I really dislike the idea of having duplicate enum values, from both the user and implementation POV: It's just a huge open door for bugs and confusion.
We can do it for 3.0 without any issue, if we really want to. Let's not clutter things just for an "extra" s just now, please. :)

Why is this considered an issue in the first place? Nobody ever said that we have to name things 1:1 compared to OpenGL. If that was a rule, I would have named these enums accordingly from the start. And if it's a new rule, then I'm not aware of it :stuck_out_tongue:

We can do it for 3.0 without any issue, if we really want to. Let's not clutter things just for an "extra" s just now, please. :)

I'm fine with that. If we agree on it, we can simply flag this for 3.0.0, rather than closing it, though.

Nobody ever said that we have to name things 1:1 compared to OpenGL

Of course not, but the names in the other big graphics framework are identical: https://msdn.microsoft.com/en/library/windows/desktop/Bb205124(v=VS.85).aspx
So my question is rather: We choosing a set a of names when the whole world is using different ones? It's not too dramatic, but this is probably what will raise confusion, not changing the names to the correct ones.

It's not that we follow anybody else's naming, it's just that the current names are grammatically incorrect. You can read any literature on computer graphics that is not related to programming in any way and they will also use the same naming. In fact, that is the reason why all the other libraries ended up with the same names, they based them on literature and not each other.
Also, like Tank said, adding these names now while keeping the old ones doesn't break anything, which is why I suggested it in the first place. And I  also don't see how this can introduce bugs that actually successfully compile. It's not always necessary to be that paranoid about such trivial things. :wink:

the current names are grammatically incorrect

The discussion should have started with this statement. Now we can discuss seriously about what to do.
I would be fine with deprecating them now, but since it's a very minor "issue", and people don't seem to complain too much about it (this is the very first time, the enums have been there for years), I see no reason to rush and add some clutter to the public API now, we can also wait for SFML 3.

This is the second part to making a library appealing to more "serious" developers. If we just make a clean cut when SFML 3 starts, people with financial investment in old code and therefore higher risk will be put off or will never migrate because it costs too much or is too risky. SFML 3 won't come out overnight or even in the next months. It is a long term goal. If we introduce the new names (among other things) now, newer code bases could be built on top of them already and "be ready" for SFML 3. Forcing developers to wait for SFML 3 to be released and rush to adapt their legacy code just to use some of the new features is a disservice to long-time SFML users.
Look at any other "serious" library. They almost never make a clean cut even when releasing major versions. It is a death sentence to the user-base. Deprecation exists for a reason. If it didn't make sense, libraries would not make use of it. The more "serious" the libraries' user-base is, the more necessary having a migration strategy becomes.

I'm not sure if it's grammatically incorrect (I see it similar to "item list" vs "items list", but I'm also no native speaker), but what I don't understand is why it's a valid  discussion now. If grammatically correct or not: There's no single reason to break with the world's standards, even if just for "some s's".
If it's something for 3.x or 2.x can be discussed. Personally I'd be happy if this wouldn't just be closed.
One project that's doing a good job on updates and deprecation is Django. Features can be flagged as being deprecated in the docs, which will also emit warnings when being used. As every sane developer will read the FULL upgrade announcement anyway, it's a very nice way to stay up-to-date with your code. It gives the people enough time to make the switch and get used to the new stuff.
Indeed, waiting until 3.0 with all of the API-breaking things, which can make use of deprecation, doesn't make sense to me.

Now, I don't have much experience in maintaining large libraries, but, for what it's worth, would starting a 3.0 branch be possible/worthwhile?
Don't make it an "official" release branch or whatnot, just for everything that can't be in 2.x, start to merge it all into a 3.0 branch. To get a head start essentially. If there are enough desired features that can't be implemented in 2.x, I don't see much point in waiting, especially if you can keep them separate. Call it a "pre-alpha" or something, make it known that it may have API breaking changes so you can modify as much as needed.
Especially since 2.x is mostly bug-fixing at this point. There are a lot of feature/* branches at the moment. Combine them so people can start testing them. This would be analogous to other projects that have dev/nightly branches, alongside the master/stable branch.
Plus, it'd let @binary1248 start seeing progress on the features he wants to add.

people don't seem to complain too much about it
Well, SFML is used by a lot of beginners and people that haven't used OpenGL directly. They most likely wouldn't know about the differing names. That'd be my guess as to why no one has brought this up before.

Anyways, just my 2 cents as a SFML user!

There are a few things mixed up here so to somewhat sum it up:

A. Do we want to rename things?
B. If yes, when do we do it?

Regarding A, I guess we should also look for other strings in the code; there might be more. So if there's a majority that feels it's a good thing (regardless of when it's done) an issue should be open instead of this PR.
Now, every library use some slightly different vocabulary so saying that X, Y and Z use term T therefore we should do the same feels is not a valid argument: We also need to make sure the arguments behind their choice is valid. From that point of view, the only valid argument I see is the grammar and since I'm no native speaker I leave it those people to determine the truth. But it's not enough to say "some use T so should we".
As to B. when, for something that small I really feel it should be delayed until 3.0 because of a few things. The most important one is maintenance: If we do it now we need to add a synonym and therefore double the switch cases in our own code. But there are also some impact on the users: imagine you're using a library that interact with SFML that's up-to-date and doesn't use deprecated feature; however in your code you still use a resource file that use the old string and when you deserialize it you don't notice the small difference and your app now crashes because the library doesn't support both, or anything else is broken. Just imagine what happens when the minor problems that are generated by having to synonyms can do when combined.
Yes, this is a very unlikely scenario but still, we have no good reason to take that risk especially since we're not able to predict everything.
Also, the cost of upgrading from SFML 2.x to 3.x will not be significantly increased just by this change. And honestly I would not value deprecation: Just look how wrong the Java API got with all its deprecated feature. Adding a deprecated warning is IMO not a good strategy at all.
So, to summarize my opinion: A. whatever you like, B. not now.

On the point of A, let me clarify why I thought it necessary to change at some point. Myself along with a few other irc users noticed the extra 's' and were confused. Our initial thought was that it might have been some kind of translation error. However given that these names were meant to represent the underlying GL primitive types, I waved translation issues as not possible. The extra 's' did not seem intentional to myself, but a typo. It is not only that it is grammatically incorrect ("Are you a triangles fan?" asked Fred. Chris responded, "no I like the circles better, their batting average is superb"), but that it just seems like a typo in the naming in general. This is just what I, a user of sfml saw it as. Whether or not it is implemented in 2.x; I don't care.

@mantognini, I think in this case "others use T, so should we" is very valid, because: a) OpenGL, which we abstract, uses the terms. b) D3D, which we don't abstract, but which is another huge graphics API, uses them. c) Everybody in the world uses them. d) As it points out, it's even grammatically wrong.
So, if there's a well-known and defined term, I see no reason keeping an alternative. It was a mistake by the author, no big deal, but let's not avoid fixing mistakes because of breaking APIs.
How does Java do it?

Notice I was not arguing against the change in itself but on the argumentation for the change. Now, as pointed by a few people the current version has a typo, there's no point in arguing for/against it because of this grammar rule. (Without it, it would be a mindless reflexion, like many happened in human history.)
Regarding Java, basically you have a huge standard library (nothing like STL) cluttered with deprecated features (a lot of function here and there, entire classes/modules too) which makes it really a pain to use: you don't know where to find the right tool among a deprecated army of similar looking functionalities (okay, I'm probably exaggerating a bit but you got the point). Why it happened to be like that is the real interesting question. For the case of Java they never decided to remove stuff from their standard lib, unlike what's going to happen in C++17 for a handful features. They never really went from version 2 to version 3 without introducing breaking change (I'm not talking about the language itself here). And that's the fear I get when people speak about deprecating features: will we get stuck with SFML 2.15 instead of making a jump?
Another aspect of deprecating too much things (where's the limit?) is that it gives a feeling that the library was not well thought initially and is quite unstable actually. So, at least for me, it's a sign that it might not be good enough for decent applications.

And that's the fear I get when people speak about deprecating features: will we get stuck with SFML 2.15 instead of making a jump?

No, the whole reason for marking things as being deprecated is that they will be removed in the (near) future, most likely with major version bumps, because API compatibility will be broken anyway.

Another aspect of deprecating too much things (where's the limit?) is that it gives a feeling that the library was not well thought initially and is quite unstable actually. So, at least for me, it's a sign that it might not be good enough for decent applications.

For me: No limit. What needs to be fixed/improved, should be fixed/improved. In my opinion it's impossible to write perfect code from the beginning (it's even never possible). Mistakes will be made, better approaches invented etc.
So in contrary to your impression, I think that libraries that change (regularly/often) to improve, are worth to be used, because it's ensured that all involved people are trying to get the best out of it, instead of just staying with the "old" solutions because they work and changing stuff is too sophisticated.
Example: I'd never do smart pointers everywhere in SFGUI again. If I had the time left, I'd rewrite it nearly from scratch now. That would for sure annoy some users of it, but in order to improve, things sometimes have to change for the better.

If we do it now we need to add a synonym and therefore double the switch cases in our own code.
But there are also some impact on the users: imagine you're using a library that interact with
SFML that's up-to-date and doesn't use deprecated feature; however in your code you still use
a resource file that use the old string and when you deserialize it you don't notice the small
difference and your app now crashes because the library doesn't support both, or anything else
is broken.

Since it's an enum, as long as the "synonyms" have the same numerical value, the library won't care.  Their names exist only in the header, not exported like functions.

For the case of Java they never decided to remove stuff from their standard lib

I think that's related to the distribution model.  Java supports many apps with a single runtime library, so they need to keep all the old classes around for legacy software written against an older library.  Otherwise, you'd need multiple versions of Java installed (like with Python 2.x vs 3.x).

@TankOs I understand your will to improve things and I agree that we have to make things better (who would disagree with that :P) but we have slightly different strategies toward that goal. Nevertheless ->
@criptych
that's an interesting point you got there about the distribution model. And probably because of its huge size, it was not the best thing to make a comparison between SFML and Java. In any case ->
-> if we step back and look at the discussion, it seems there's only one bloke (me) that actively (& hopefully politely) disagree with this immediate strategy so you guys should probably go on a devise a patch/open an issue/... ;)
(I'm on my phone now so it's a bit hard to find it again but I know we discussed how to technically implement a deprecation on enum -- I just don't remember the conclusion.)

hopefully politely

Sure :) Regarding deprecated features, I'll open a discussion in our internal dark dungeon. ;)

I've made a patch that has the suggested duplicates for deprecated names. I am however a little worried that some compilers may not correctly number the not explicitly numbered enums. Thoughts? Should all the the values be explicitly defined to be safe?

The correct way to do it is
TrianglesFan,
TriangleFan = TrianglesFan

Nice, I didn't even know that it's possible that way.

Yeah, me too. And now it's seems to me that my fear of creating bugs in the user code is unfounded. I thought that in an enum we were forced to have different values.. So it's very nice to hear that! :)

@Harrison-Miller Since the only left bloke doesn't disagree anymore, feel free to adjust the PR for inclusion. ;-)

Updated.

Thank you, looks good. :+1:

Is this considered a bugfix or a feature?

A bugture! Bugfix if you asked me, as the original spelling is wrong.

I think the deprecated names need documentation comments with \deprecated command.

What do others think about bug vs feature and inclusion into 2.3.2 or not?

This is an unintended mistake thus a bug, fixing it doesn't add or remove anything to the feature set of SFML thus it can't be classed as a feature.
We can't add this to 2.3.2 because strictly speaking this changes the external API although I don't think it would break the API or ABI in any way.

Just looking through the issues and noticed this had no milestone... will this be included in 2.4 since there is no code breakage? It would also be a good thing to apply the new deprecated macro to.

Looks like the milestone didn't get set.
How exactly can the deprecated macro be applied here?

How exactly can the deprecated macro be applied here?

Ah right, I forgot that we the macro can't be applied to enums. Either way the now deprecated names still should have documentation stating that they are deprecated. A single comment above them won't make it into the docs.

Are there no other occurrences of these enumerators in the SFML source code, including examples?
Furthermore, we should not forget to adapt the official bindings and tutorials.

Furthermore, we should not forget to adapt the official bindings

No worries, CSFML/SFML.Net will get updated accordingly before they get the 2.4 tag. :wink:

Are there no other occurrences of these enumerators in the SFML source code, including examples?

You could have just started a search. :stuck_out_tongue_winking_eye:
Example in the documentation in VertexArray.hpp needs adjustment.
Example in the documentation in Vertex.hpp needs adjustment.
OpenGL ES code in RenderTarget.cpp (and here as well) needs adjustment.
@Harrison-Miller Can you update this PR?

You could have just started a search. :stuck_out_tongue_winking_eye:

I know, but I didn't have the time to do so when I wrote the comment. Since the pull requester is likely to modify the code anyway, he could just do a symbolic search for occurrences in the IDE and directly adapt them :wink:

Bump.

@Harrison-Miller It's still missing some of the adaptions I mentioned, also it would be nice to get a single commit. Do you have time to get around to it?

@Harrison-Miller Bump :wink:

Superseded by #1095


Add a grpc streaming helper

This PR extracts the streaming code from the SDK that converts grpc streams into channel receivers, into the generic GrpcStreamingHelper.
The RetryStrategy implementation is also extracted from the SDK.

I've squashed the commits and updated release notes.


Capability to Align Color Frame with Depth Frame.

Start with the why:
In cases where absolute alignment (or as close to it as possible) is required between the neural inference results and the depth results and the neural inference must be run on the color camera, it is desirable to be able to align the color frame and the depth frame (which is aligned with the RIGHT grayscale cameras) through the color and grayscale camera intrinsics.
Move to the how:
This capability will require the calibration of the color camera intrinsics and extrinsics to the grayscale (right camera), either at the factory, or by the user interested in the feature and the implementation of the distortion and translation using the WARP blocks and additional logic in DepthaI.
Move to the what:
Allow registration of the color and depth frames.

We have the initial version of this calibration working:

Accidentally had mad this a duplicate issue.  Will close this and move to: https://github.com/luxonis/depthai/issues/284


Editor: remove duplicate icons

Context

See issue #8555 for details.
This PR kept some of the icons because currently there is no alternatives for following icons in design-system/icons.
story-editor/src/icons/index.js:
export { ReactComponent as TurningLine } from './turning_line.svg';
export { ReactComponent as Union } from './union.svg';
export { ReactComponent as Muted } from './volume_off.svg';

Summary

Relevant Technical Choices

To-do

User-facing changes

Testing Instructions

QA

[ ] This is a non-user-facing change and requires no QA

This PR can be tested by following these steps:

UAT

[ ] UAT should use the same steps as above.

This PR can be tested by following these steps:

Reviews
Does this PR have a security-related impact?

Does this PR change what data or activity we track or use?

Does this PR have a legal-related impact?

Checklist

[x] This PR addresses an existing issue and I have linked this PR to it in ZenHub
[x] I have tested this code to the best of my abilities
[x] I have verified accessibility to the best of my abilities (docs)
[x] I have verified i18n and l10n (translation, right-to-left layout) to the best of my abilities
[x] This PR contains automated tests (unit, integration, and/or e2e) to verify the code works as intended (docs)
[x] I have added documentation where necessary
[x] I have added a matching Type: XYZ label to the PR

Fixes #8555

So this one is a little tricker than it appears.
This Branch	Staging environment

See the difference in the icon? Can you go through and ensure that updating to the design system icons doesn't cause a visual regression?
It would be really helpful too if you could document them in the PR description of where each of these is appearing in the editor (bonus points for screenshots like I did above in a table) - it'll make it a lot easier for review and QA.
Thanks!

Thanks for capturing that! Yeah I did notice the difference when I was doing the change, but I thought that was expected since we are changing the design.
I don't see we have any prop options to control the size of the dots, don't we?
Thanks!

@g-sqiao Looks like something went wrong when rebasing. There are now some unrelated/old commits from main in the PR. You might need to rebase to get those away.

@g-sqiao Looks like something went wrong when rebasing. There are now some unrelated/old commits from main in the PR. You might need to rebase to get those away.
Done

I don't see we have any prop options to control the size of the dots, don't we?
I think we'll just need to use our best judgment (increase the size of the icon) and ask UX for review.

Please also add before vs. after screenshots for each replaced icon.

I just checked the source code for the new design-system icon. Apparently we can't fix the problem by changing the icon size since it's controlled by its path.
<svg width="32" height="32" viewBox="0 0 32 32" fill="none" xmlns="http://www.w3.org/2000/svg">
<path fill-rule="evenodd" clip-rule="evenodd" d="M12 16C12 16.5523 11.5523 17 11 17C10.4477 17 10 16.5523 10 16C10 15.4477 10.4477 15 11 15C11.5523 15 12 15.4477 12 16ZM17 16C17 16.5523 16.5523 17 16 17C15.4477 17 15 16.5523 15 16C15 15.4477 15.4477 15 16 15C16.5523 15 17 15.4477 17 16ZM21 17C21.5523 17 22 16.5523 22 16C22 15.4477 21.5523 15 21 15C20.4477 15 20 15.4477 20 16C20 16.5523 20.4477 17 21 17Z" fill="currentColor"/>
</svg>

Also its wrapper Button has fixed size 28x28.

If you see the previous icon (more_horiz.svg) we used, it's even smaller
<svg width="28" height="28" viewBox="0 0 28 28" fill="none" xmlns="http://www.w3.org/2000/svg">
<path fill-rule="evenodd" clip-rule="evenodd" d="M10 14C10 12.9 9.1 12 8 12C6.9 12 6 12.9 6 14C6 15.1 6.9 16 8 16C9.1 16 10 15.1 10 14ZM12 14C12 15.1 12.9 16 14 16C15.1 16 16 15.1 16 14C16 12.9 15.1 12 14 12C12.9 12 12 12.9 12 14ZM20 16C18.9 16 18 15.1 18 14C18 12.9 18.9 12 20 12C21.1 12 22 12.9 22 14C22 15.1 21.1 16 20 16Z" fill="currentColor"/>
</svg>

I'd suggest to redo the design, but before that we can roll back to the old one. WDYT or any better solution?
@choumx @BrittanyIRL

Combined the changes in #8649 with this PR to make issue tracking easier.
Basically we got ride of the unused ArrowDown button (discussion) and simplified the More button (discussion)

Thank you so much @BrittanyIRL ! Your screenshots made it so easy to find where to visually see the change!
Here are the screenshots for the changes I made (in a way as you suggested).

New
Staging

New
Figma

Thank you so much @BrittanyIRL ! Your screenshots made it so easy to find where to visually see the change!

Hey no problem :)
There's still other icons in here to update though, I thought maybe you could try solving them given the additional context. They will also need to have QA directions added, I edited your PR description to show you a pattern to use for helping others identify where your changes are.

Since @g-sqiao rolled off, I'm going to close this and move this ticket to pea pod's backlog. I'll take care of it some time soon - it's really not hurting anything so there's no massive hurry.


@paste, @mousedown, @keyup events are not working with vue-quill-editor component

I've tried to use onPaste, onMouseDown and onKeyUp events but it is not working here. I've tried to use editor-change event which is mentioned in the quill document. Can anyone provide the list of events which vue-quill-editor is supporting?
I want to use onPaste event for remove formating on paste.  (paste plain text)
<quillEditor ref="quillEditorRef"                       :value="hiddenValue"                        :options="editorOption"                       @input="handleInput($event)"                       @mousedown="handleMouseDown($event)"                       @keyup="handleKeyUp($event)"                      @paste="handlePaste($event)"                      @focus="onEditorFocus($event)"                       @blur="onEditorBlur($event)"> </quillEditor>

I have the same problem, some one have a solutions?


select-multiple filter is broken

When using select-multiple you can only select one of the possible filter values. When you select multiple values the table shows no items.
Example: http://plnkr.co/edit/iGSL8WKlWk84L2mNhQiC?p=preview

Check with the latest, please

It still doesn't seem to be working http://plnkr.co/edit/KKczcI6mJVIZdscUSfcA?p=preview

Same here. No items on multiple values.

Same problem here.

Looks like it's working in the current version. Look at this codepen

I am on same boat, @lukad did you manage to fix this issue?

@praveenuics I don't really remember. I'm not using Angular anymore.


Regression: Allow specifying empty object in Data.TaggedEnum

What version of Effect is running?
2.2.3
What steps can reproduce the bug?
Use a strict empty object for a child in Data.TaggedEnum.
Sample code:
import { Data } from 'effect'

type Authentication = Data.TaggedEnum<{
  // TS recommends using `Record<string, never>` instead of `{}`
  Anonymous: Record<string, never>
  Authenticated: {
    scope: string
  }
}>
const { Anonymous, Authenticated } = Data.taggedEnum<Authentication>()

const anonymous = Anonymous()
const authenticated = Authenticated({ scope: 'email' })

What is the expected behavior?
tsc should compile without error.
What do you see instead?
tsc returns an error:

Type '{ Anonymous: Record<string, never>; Authenticated: { scope: string; }; }' is not assignable to type '"It looks like you're trying to create a tagged enum, but one or more of its members already has a _tag property."'. (lsp)

Additional information
This worked prior to the regression noted in 2.0.0-next.50: https://github.com/Effect-TS/effect/issues/1556
If you agree that this is a regression, here's a possible fix. Update ChildrenAreTagged<A> in packages/effect/src/Data.ts to:
type ChildrenAreTagged<A> = keyof A extends infer K
  ? K extends keyof A
  ? '_tag' extends keyof A[K]
  ? A[K]['_tag'] extends never
  ? false
  : true
  : false
  : never
  : never

You should use Record<string, never> in a tagged enum declaration, as that is not equivalent to {} (an object with no keys).

The ESLint rules enabled by plugin:@typescript-eslint/recommended includes the ban-types rule, and this specifically bans {}. I'm no expert in TypeScript internals, so I'll defer to existing discussions.
This comment explains their logic behind banning {}: https://github.com/typescript-eslint/typescript-eslint/issues/2063
There is additional discussion here: https://github.com/microsoft/TypeScript/issues/47486.
If Record<string, never> is indeed correct, then we can certainly ignore the rule when using taggedEnum.

If you have to use Record, then the correct type would be Record<never, never>.

I tested that as well, and it seems Record<never, never> is equivalent to {}. It allows any non-nullish value.
// allows any key (does not enforce empty object)
const objectTest: Record<never, never> = { x: 1 }
// allows non-object values
const stringTest: Record<never, never> = "hello"
const boolTest: Record<never, never> = true
const numberTest: Record<never, never> = 1
const arrayTest: Record<never, never> = [1, 2, 3]
// this fails - `null` is not allowed
const fails: Record<never, never> = null

While general usage of the type {} may be discouraged in this case it is really not an issue, at the end the type you'll work with is { _tag: yourTag } so this is rather an issue with a too strict eslint rule, as Tim suggested if you want to keep such rule you can use Record<never, never>


MSID: 88648 Version: 1 DOI: 2<IP_ADDRESS>6859

"msas": "Neuroscience"
"msid": "88648"
"preprintDoi": "10.1101/2<IP_ADDRESS>6859"
"Reviewed Preprint posted": "2023-07-31"
"Sent for peer review": "2023-05-09xx"
"Posted to bioRxiv": "2023-06-28" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>6859v2/")
[PLACE PDF URL HERE WHEN AVAILABLE] See step 7
Step 1. Inform bioRxiv
Who can help: @QueenKraken, @nlisgo, @scottaubrey

[x] Manuscript is in data hub index (https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v1/by-publisher/elife/get-by-manuscript-id?manuscript_id=88648)

or (only one should be ticked. remove other from description.)
Step 2. Create preview of manuscript
Who can help: @fred-atherden, @nlisgo, @scottaubrey

[ ] Manuscript is available for preview (https://prod--epp.elifesciences.org/preview/88648/v1)

[ ] Trigger import for staging: https://prod--epp.elifesciences.org/import
[ ] Sync data folder with s3://prod-elife-epp-data/data
[ ] Trigger import for staging: https://staging--epp.elifesciences.org/import
[ ] Sync data folder with s3://staging-elife-epp-data/data
[ ] Pull request created to enhanced-preprint-data
[ ] Post link to pull request below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-manuscript
Step 3: Awaiting public reviews and QC
Who can help: Production team

[ ] QC passed or QC not needed

Who can help: Editorial team

[x] Public reviews available on sciety (https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>6859)
[x] Manuscript and editor details at the top of this issue (Supplied by Editorial team)
[ ] Reviews returned by EPP - https://prod--epp.elifesciences.org/api/reviewed-preprints/88648/v1/reviews

Example
"msas": "Genetics and Genomics", "Neuroscience"
"msid": "84628"
"version": "1"
"preprintDoi": "10.1101/2<IP_ADDRESS>4241"
"articleType": "Reviewed Preprint"
"status": "Published from the original preprint after peer review and assessment by eLife."

"Reviewed Preprint posted": "2023-01-02"
"Sent for peer review": "2022-10-28"
"Posted to bioRxiv": "2022-11-21" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>4241v1")

Editors:
Reviewing Editor
Michael B Eisen
University of California, Berkeley, United States
Senior Editor
Michael B Eisen
University of California, Berkeley, United States

Step 4: Modify manuscripts.json (no PDF)

[ ] Reviewed preprint is published to EPP (https://elifesciences.org/reviewed-preprints/88648)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[ ] Request that a doi be registered

[ ] Post link to #enhanced-preprint comment below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]

Instructions to modify manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/publish-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/334/files
Once the pull request is merged in it should be available a few minutes later.

Request that a doi
Post the following in #enhanced-preprint:
@Fred can you register a doi for https://elifesciences.org/reviewed-preprints/88648

Step 5: Awaiting search reindex

[ ] Reviewed preprint is avaliable on journal homepage (https://elifesciences.org)

The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.

Additional info
If needed, the jenkins pipeline to reindex search can be triggered sooner.
https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 6: Published! Request PDF generation

[ ] Post the link to the PDF url at the top of the issue

[ ] Post link to #enhanced-preprint comment below

#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]
Post the following to the #enhanced-preprint on slack:
@Ryan Dix-Peek please can you generate a PDF for https://elifesciences.org/reviewed-preprints/88648

Step 7: Introduce PDF to data folder and git repo

[ ] PDF is avaliable at https://github.com/elifesciences/enhanced-preprints-data/raw/master/data/88648/v1/88648-v1.pdf

Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-pdf
Step 8: Add PDF url to manuscripts.json

[ ] Reviewed preprint PDF is available for download (https://prod--epp.elifesciences.org/reviewed-preprints/88648)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[PLACE LINK TO PULL REQUEST HERE]

Instructions to add PDF url to manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/add-pdf-url-to-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/397/files
Once the pull request is merged in it should be available a few minutes later.

Step 9: Done!

[ ] Kettle is on!

Semi-colon on the end of the first affiliation. OK to leave


Flag disable post verification

Motivation
There are setups with one public node that "talks to the Internet" and stands in front of more private nodes that only connect to that public node. In such a setup, the private nodes can trust that the public one already verified all data coming from the network and it is not required to repeat that work. The PoST proofs of ATXs are especially heavy.
Description

added a flag smeshing-opts-verifying-disable and associated config field,
created a noop post verifier if the flag is set,
additionally, removed unused field from activation Handler.

Test Plan

TODO

[x] Explain motivation or link existing issue(s)
[x] Test changes and document test plan
[x] Update documentation as needed
[x] Update changelog as needed

Wouldn't it make sense to disable fetch server for the unverified data on the nodes with this option, either always or at least by default, to lessen the effect of possible "spreading" of unverified POST proofs across "careless" nodes that enable this option? Granted, it will be limited by other "proper" nodes of course, but still I'd be a bit proactive in eliminating such possible side effect. Or maybe require private network option together with this one

Wouldn't it make sense to disable fetch server for the unverified data on the nodes with this option, either always or at least by default, to lessen the effect of possible "spreading" of unverified POST proofs across "careless" nodes that enable this option? Granted, it will be limited by other "proper" nodes of course, but still I'd be a bit proactive in eliminating such possible side effect. Or maybe require private network option together with this one

To be fair if a node has verification disabled and broadcast an unverified ATX with invalid proof the situation is no different from a node receiving this invalid proof from "the source". Nodes should not blindly trust incoming data, only other nodes connected to the public network with verification disabled would be affected by this.
In terms of generating additional network traffic with invalid ATXs: this is no different from a node just broadcasting random ATXs, or am I mistaken?

Wouldn't it make sense to disable fetch server for the unverified data on the nodes with this option, either always or at least by default, to lessen the effect of possible "spreading" of unverified POST proofs across "careless" nodes that enable this option? Granted, it will be limited by other "proper" nodes of course, but still I'd be a bit proactive in eliminating such possible side effect. Or maybe require private network option together with this one

To be fair if a node has verification disabled and broadcast an unverified ATX with invalid proof the situation is no different from a node receiving this invalid proof from "the source". Nodes should not blindly trust incoming data, only other nodes connected to the public network with verification disabled would be affected by this.
In terms of generating additional network traffic with invalid ATXs: this is no different from a node just broadcasting random ATXs, or am I mistaken?

@mafa Well yes. @ivan4th proposed to add a check to avoid misusing this option by unaware users. It's intended for use in private setups only so it makes sense to reject it if --p2p-private-network is not set.

@ivan4th updated, PTAL

bors merge

bors cancel

bors merge

bors cancel

Guys, but that flag --p2p-private-network has nothing to do with public/private nodes setup.

bors merge

bors cancel

bors merge

bors cancel

bors merge


[Backtracing] Fix ARM64e build failure.

Accessing the thread context structures is complicated because their member variables change name depending on various macros.  This caused a build failure for ARM64e.
rdar://118402226

@swift-ci Please smoke test


Won't compile

Are you trying to code on Source Code (Haxe) or on the Downloaded Build (Lua)?
Source Code
Show an screenshot/video of your problem.
All I get are these errors, not sure if I installed stuff correctly

I have the same problem

same with TitleState.hx

use haxe 4.1.1 or 4.2.5 or like recommended versions from the compiling wiki i guess


Fix implementation of Entity.removeProperty.

Fixes #3299.

Update CHANGES in master if you think it's warranted.


MVC 4 Rotativa error "This program is blocked by group policy"

Rotativa works great on localhost, but I get a error when the application is published to the server. The error is: "This program is blocked by group policy".  Stack Trace: [Win32Exception (0x80004005): This program is blocked by group policy.
For more information, contact your system administrator].
Any idea on a fix for this? I googled this and found several people experienced this issue and I have not found a solution for it.  Thanks.

Feeback on this issue: I spoke to Godaddy on 2 occasions and the permissions that would allow the exe file to work cannot be adjusted if you have a shared hosting account. They told me that I would need to upgrade to a dedicated hosting account for the permissions to be changed that would allow Rotativa's exe file to run.

declare full trust level in web config
<system.web>

</system.web>

Muhammad - Already i have written this code in my application. even though i am getting this error

I am also suffering from this error. ;(

Hello arrauf! I think that my error was mainly because I my application was being hosted in a shared environment. I upgraded to a dedicated server and it works fine.
I also set the trust level to full in the web.config..
<system.web>

</system.web>
Also, check this link to make sure that these files are in the Rotativa folder:
My Rotativa folder also has these files:
help-wkhtmltoimage.txt
help-wkhtmltopdf.txt
msvcp120.dll
msvcp140.dll
msvcr120.dll
vcruntime140.dll
wkhtmltoimage.exe
wkhtmltopdf.exe
wkhtmltox.dll

And last, I had to download the exe file in the link below and replace the wkhtmltopdf.exe file that the nuget package manager installed... Rotativa would not work for me with the exe file that nuget installed...
Hope this helps!
https://drive.google.com/file/d/0BzI_u_O3vUM1aEppb3ZVZXNsc28/view


Is Arcadia dead?

Developers! Do you have a plans to develop Arcadia?

Yes! We use it almost every day, and are working on a new release. Follow us on twitter (@ra, @timsgardner, @arcadiaunity) or Gittr for updates!


what's the intent of this project?

is it a preprocessor like clay?
what's the different?

This is literally a rewrite of clay. That's the idea. The only difference (besides surface-level differences) is that it uses a faster builder module.

maybe what i want is a readme file.
i read the example code,and think it's very good.
so i ask a question instead of read the source code.


some errors I got

I have successfully docker-compose three containers:
$ docker-compose ps
             Name                           Command               State           Ports
------------------------------------------------------------------------------------------------
dockerregistrysetup_auth_1       /start.sh                        Up      <IP_ADDRESS>:5001->5001/tcp
dockerregistrysetup_ldap_1       /usr/bin/supervisord -c /e ...   Up      389/tcp
dockerregistrysetup_registry_1   /bin/registry serve /etc/d ...   Up      <IP_ADDRESS>:5000->5000/tcp

But when I try to push the image, it doesn't ask for login:
docker push <IP_ADDRESS>:5000/anyuser/busybox
The push refers to a repository [<IP_ADDRESS>:5000/anyuser/busybox]
Get https://<IP_ADDRESS>:5000/v1/_ping: x509: cannot validate certificate for <IP_ADDRESS> because it doesn't contain any IP SANs

Ok, resolve the problem by hint in https://github.com/docker/docker/issues/8943
Then I solved the problem, was related to hostname/IP resolving...
You must have an hostname in /etc/hosts that's the same as well as declared in the certification procedure. The hostname must be present in client and server machine

And I duplicate the problem with docker login
$ docker login <IP_ADDRESS>:5000
Username: mozart
Password:
Error response from daemon: Get https://<IP_ADDRESS>:5000/v1/users/: x509: cannot validate certificate for <IP_ADDRESS> because it doesn't contain any IP SANs

Here is my fix:
$ docker tag busybox localhost:5000/anyuser/busybox

$ docker push localhost:5000/anyuser/busybox
The push refers to a repository [localhost:5000/anyuser/busybox]
8ac8bfaff55a: Image push failed
unauthorized: authentication required

# That's error I expected.

$ docker login localhost:5000
Username: mozart
Password:
Login Succeeded

$ docker push localhost:5000/anyuser/busybox
The push refers to a repository [localhost:5000/anyuser/busybox]
8ac8bfaff55a: Layer already exists
latest: digest: sha256:a59906e33509d14c036c8678d687bd4eec81ed7c4b8ce907b888c607f6a1e0e6 size: 505

following the document, did the change on DOCKER_OPTS, then <IP_ADDRESS>:5000 is fine.


是否有计划提供vue 3.0的支持

I am also very interested in answering this topic.

I am also very interested in the response to this topic


Add Apache2 license to the repo

Whilst the stanard Vibrato open source license is MIT this repo
contains contain in the pl_mongo library that is licensed under the
Apache License.
It doesn't make a lot of difference from a company perspective and it's
easier if the whole repo is licensed the same way so make it Apache2.
Closes: #1

Agree this is probably simpler for this repo.


heap-buffer-overflow in func SkipString

input value :  "@<=>?@ABCDEFGHIJiLM$^^&(^(
you can use ASAN compile the lib and the API JsonValue* value = AJson->Parse(jsonString); it supply and input this value to the API .
it can trige in a buffer-overflow bug.
==2238917==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000323c at pc 0x564852e329cc bp 0x7fff7edbed90 sp 0x7fff7edbed80
READ of size 1 at 0x60200000323c thread T0
#0 0x564852e329cb in SkipString /opt1/software/MojoJson/Json.c:695
#1 0x564852e32b03 in ParseString /opt1/software/MojoJson/Json.c:719
#2 0x564852e33b76 in ParseValue /opt1/software/MojoJson/Json.c:858
#3 0x564852e34143 in Parse /opt1/software/MojoJson/Json.c:949
#4 0x564852e342ef in easyloop /opt1/software/MojoJson/test.c:8
#5 0x564852e44355 in main /opt1/software/betafuzz/srap/wrapentry.c:98
#6 0x7f587147ad8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#7 0x7f587147ae3f

I think the problem is that the string is not a valid json format — "@<=>?@ABCDEFGHIJiLM$^^&(^(.


Is there an error in the code?

Greetings,
In mambair's network, I found that unembed is implemented first, and then embed is implemented. Is it designed in this way? Or is it the other way around? In the residualgroup of mambair_arch.py.
def forward(self, x, x_size):
return self.patch_embed(self.conv(self.patch_unembed(self.residual_group(x, x_size), x_size))) + x

Greetings, In mambair's network, I found that unembed is implemented first, and then embed is implemented. Is it designed in this way? Or is it the other way around? In the residualgroup of mambair_arch.py. def forward(self, x, x_size): return self.patch_embed(self.conv(self.patch_unembed(self.residual_group(x, x_size), x_size))) + x

I see. To go through the convolution. Sorry to interrupt


Login with progressive disclosure pattern

Google, Yahoo and others started recently to ask for username and password in two steps. each step has to be confirmed with a button, aka "progressive disclosure".
Why they do that is discussed a lot, the main reasons are singe point of focus and better mobile experience.
Is that already on the roadmap of Yii2-user or should we make this a target?
Such a state-of-the-art feature could be another USP compared to other frameworks and extensions and underpins the excellent Yii2-user approach.

Sounds interesting. I'll try to add this as an option.

The best answer in the StackExchange link you, @WeeSee, posted is, in my humble opinion:

Reason "why would google do it" is simple - if you stay signed in, they can track you much better as you go around on the web, and thus make more money. So it might probably benefit Google bottom line more then reasons mentioned in official explanation

I doubt developers building an application with yii2-user has the same intentions.

After thinking, I've decided that this won't be added to the core. It requires a lot of work, but I'm sure it will be used by a very little percentage of developers. So it shouldn't be part of the core. Maybe this can be added as a tutorial to the documentation though.


Loading speed of movies

I am using firefox and Youtube classic v1.6.0.
Clicking on a movie on youtube
When I set the function on 'user-agent', the movie loads in 2 seconds. But after restarting firefox the text on youtube grows very big, it doesn't look normal anymore. It doesn't matter what firefox version I use in the user agent.
When I put it on the function 'url rewrite' the interface looks normal like always, but the loading of the movie takes 5 seconds!

I am using firefox and Youtube classic v1.6.0.
Clicking on a movie on youtube
Youtube classic settting: user-agent
When I use the setting 'user-agent', the movie loads in 2 seconds. But after restarting firefox then the text on youtube grows very big, it doesn't look normal anymore, the text is much larger than any other website. It doesn't matter what firefox version I use in the user agent.
The correct functioning can be restored by again installing youtube classic or by turning off youtube classic and then on again, but only when that is done in the menu in the list of add-ons.
Youtube classic setting: url rewrite
When I use the setting 'url rewrite', the interface looks normal like always, but the loading of the movie takes 5 seconds!


unresolved import proc_macro when compiling openssl-macros-0.1.0-024d32b3f7af0a4f

Problem
Executing the call passed by cargo through RUSTC_WRAPPER to build openssl-macros crate, it fails with this message:

unresolved import proc_macro

{"message":"unresolved import `proc_macro`","code":{"code":"E0432","explanation":"An import was unresolved.\n\nErroneous code example:\n\n```compile_fail,E0432\nuse something::Foo; // error: unresolved import `something::Foo`.\n```\n\nIn Rust 2015, paths in `use` statements are relative to the crate root. To\nimport items relative to the current and parent modules, use the `self::` and\n`super::` prefixes, respectively.\n\nIn Rust 2018 or later, paths in `use` statements are relative to the current\nmodule unless they begin with the name of a crate or a literal `crate::`, in\nwhich case they start from the crate root. As in Rust 2015 code, the `self::`\nand `super::` prefixes refer to the current and parent modules respectively.\n\nAlso verify that you didn't misspell the import name and that the import exists\nin the module from where you tried to import it. Example:\n\n```\nuse self::something::Foo; // Ok.\n\nmod something {\n    pub struct Foo;\n}\n# fn main() {}\n```\n\nIf you tried to use a module from an external crate and are using Rust 2015,\nyou may have missed the `extern crate` declaration (which is usually placed in\nthe crate root):\n\n```edition2015\nextern crate core; // Required to use the `core` crate in Rust 2015.\n\nuse core::any;\n# fn main() {}\n```\n\nSince Rust 2018 the `extern crate` declaration is not required and\nyou can instead just `use` it:\n\n```edition2018\nuse core::any; // No extern crate required in Rust 2018.\n# fn main() {}\n```\n"},"level":"error","spans":[{"file_name":"$HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-macros-0.1.0/src/lib.rs","byte_start":4,"byte_end":14,"line_start":1,"line_end":1,"column_start":5,"column_end":15,"is_primary":true,"text":[{"text":"use proc_macro::TokenStream;","highlight_start":5,"highlight_end":15}],"label":"use of undeclared crate or module `proc_macro`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"there is a crate or module with a similar name","code":null,"level":"help","spans":[{"file_name":"$HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-macros-0.1.0/src/lib.rs","byte_start":4,"byte_end":14,"line_start":1,"line_end":1,"column_start":5,"column_end":15,"is_primary":true,"text":[{"text":"use proc_macro::TokenStream;","highlight_start":5,"highlight_end":15}],"label":null,"suggested_replacement":"proc_macro2","suggestion_applicability":"MaybeIncorrect","expansion":null}],"children":[],"rendered":null}],"rendered":"error[E0432]: unresolved import `proc_macro`\n --> $HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-macros-0.1.0/src/lib.rs:1:5\n  |\n1 | use proc_macro::TokenStream;\n  |     ^^^^^^^^^^ use of undeclared crate or module `proc_macro`\n  |\nhelp: there is a crate or module with a similar name\n  |\n1 | use proc_macro2::TokenStream;\n  |     ~~~~~~~~~~~\n\n"}

Steps
rustc \
    --crate-name openssl_macros \
    --edition 2018 \
    --error-format json \
    --json artifacts,future-incompat \
    --diagnostic-width 211 \
    --crate-type proc-macro \
    --emit dep-info,link \
    -C prefer-dynamic \
    -C embed-bitcode=no \
    -C metadata=024d32b3f7af0a4f \
    -C extra-filename=-024d32b3f7af0a4f \
    --out-dir $PWD/target/debug/deps \
    -L dependency=$PWD/target/debug/deps \
    --extern proc_macro2=$PWD/target/debug/deps/libproc_macro2-f0f3215e1fedc347.rlib \
    --extern quote=$PWD/target/debug/deps/libquote-362da28f47bafdea.rlib \
    --extern syn=$PWD/target/debug/deps/libsyn-66dcc2de3ece399a.rlib \
    --cap-lints warn \
    -C link-arg=-Wl,--compress-debug-sections=zlib-gabi \
    $HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-macros-0.1.0/src/lib.rs

Possible Solution(s)
My solution is to add the missing args: --extern proc_macro.
I add these args for any crate of type proc-macro that does not already mention these args.
Notes
To me this is a bug as proc_macro is a sysroot crate. Meaning either:

--extern should not be needed (because proc_macro is sysroot)
or: --extern proc_macro should be added by cargo

Version
cargo 1.69.0 (6e9a83356 2023-04-12)
release: 1.69.0
commit-hash: 6e9a83356b70586d4b77613a6b33f9ea067b9cdf
commit-date: 2023-04-12
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:OpenSSL/1.1.1q)
os: Ubuntu 22.04 (jammy) [64-bit]

The reproduction example is not really reproducible to me. Could you provide one that has a Cargo package and run cargo command? Also, what does your RUSTC_WRAPPER look like?

I am going to close due to lack of a minimal set of steps to reproduce, and it has been inactive for a while. Here are tips about how to create a minimal, complete, and verifiable example.
Feel free to comment below or open a new issue if there is any update.


Add OpenWRT Makefile

Tested on MIPS (Gl.Inet Mudi E750) with rtsp

Codecov Report

Merging #970 (2647af5) into main (9d3fd3b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #970   +/-   ##
=======================================
  Coverage   58.03%   58.03%
=======================================
  Files          59       59
  Lines        6684     6684
=======================================
  Hits         3879     3879
  Misses       2531     2531
  Partials      274      274

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 9d3fd3b...2647af5. Read the comment docs.

The provided Makefile has been adapted in order to

fix compatibility with latest OpenWRT
be independent from a specific version
provide server version to the server executable

The README has been updated with instructions that describes how to use this Makefile to install for OpenWRT.