Race condition causes sender to send incorrect frame header.

It has been very difficult to narrow this bug down, but it is 100% reproducible.  To reproduce:

The server needs to be sending messages faster than the client can receive them.  I need to generate at least 100 messages from server to client, but 200 is more reliable.

The length of the messages needs to be very consistent but gradually increase.  This is so you can observe a long sequence of identically repeating frame headers.  I accomplished this by embedding a counter integer in the message, so when the counter was less than 9, the integer serialized into one byte; when it was between 10 and 99, it required two bytes, etc.  For example, my first 9 messages were each 207 bytes long, then messages 10-99 were each 208 bytes long, then messages 100+ were (or would be) each 209 bytes long ( which would only be correct for a message with counter > 99 ).

What you can observe, either through packet sniffing or by instrumenting the client, is that the frame headers received by the client show a frame length of 207 for 9 message, then 208 for messages 10-99, etc.  At least, that's what you should see.  What actually happens is that, under the right conditions, the receiver will consistently receive an frame length that corresponds to a later message along with the message body for the current body.  In my example, somewhere between message 70-73 (that is, still with a two digit counter in the message body) the sender will use the message length of 209 bytes.

The problem is here: https://github.com/einaros/ws/blob/06121f89f5ab52a242717f68e4d9dc36fe771f2a/lib/Sender.js#L126
The problem goes completely away if I force this line to always create a new Buffer(totalLength).

If I inspect the contents of the outputBuffer just before the call to Socket.send, (https://github.com/einaros/ws/blob/06121f89f5ab52a242717f68e4d9dc36fe771f2a/lib/Sender.js#L172 )
I see correct values, but when the bytes actually hit the wire (as measured using wireshark) the incorrect value is sent.

The eventual symptom in my case was a "invalid utf8 sequence" error, because the message length was one byte too high, so it would read the first byte (129 = finalFragment | opcode) of the next frame and try to validate it as utf8.

Of course, there's a one-liner fix that works, but avoids the use of the _sendCache Buffer.  How important is this cache?  What are the synchronization mechanisms for avoiding this bug?

Note: I cannot reproduce this using a single machine.  I have to use a remote server.
Note2: The actual trigger points are sensitive to the message lengths.  With shorter messages, I can get it to fail around message 80-85, and with longer messages, I can get it to fail around message 60-65.
node version: 0.6.10
ws version: 0.4.7
arch: x86_64 linux

Awesome bug report :) That makes it an easy fix for me. Thanks a bunch!
On Feb 29, 2012 4:17 AM, "Chris Shoemaker" <
<EMAIL_ADDRESS>wrote:

It has been very difficult to narrow this bug down, but it is 100%
reproducible.  To reproduce:

The server needs to be sending messages faster than the client can
receive them.  I need to generate at least 100 messages from server to
client, but 200 is more reliable.

The length of the messages needs to be very consistent but gradually
increase.  This is so you can observe a long sequence of identically
repeating frame headers.  I accomplished this by embedding a counter
integer in the message, so when the counter was less than 9, the integer
serialized into one byte; when it was between 10 and 99, it required two
bytes, etc.  For example, my first 9 messages were each 207 bytes long,
then messages 10-99 were each 208 bytes long, then messages 100+ were (or
would be) each 209 bytes long ( which would only be correct for a message
with counter > 99 ).

What you can observe, either through packet sniffing or by
instrumenting the client, is that the frame headers received by the client
show a frame length of 207 for 9 message, then 208 for messages 10-99, etc.
At least, that's what you should see.  What actually happens is that,
under the right conditions, the receiver will consistently receive an frame
length that corresponds to a later message along with the message body for
the current body.  In my example, somewhere between message 70-73 (that is,
still with a two digit counter in the message body) the sender will use the
message length of 209 bytes.

The problem is here:
https://github.com/einaros/ws/blob/06121f89f5ab52a242717f68e4d9dc36fe771f2a/lib/Sender.js#L126
The problem goes completely away if I force this line to always create a
new Buffer(totalLength).

If I inspect the contents of the outputBuffer just before the call to
Socket.send, (
https://github.com/einaros/ws/blob/06121f89f5ab52a242717f68e4d9dc36fe771f2a/lib/Sender.js#L172)
I see correct values, but when the bytes actually hit the wire (as
measured using wireshark) the incorrect value is sent.

The eventual symptom in my case was a "invalid utf8 sequence" error,
because the message length was one byte too high, so it would read the
first byte (129 = finalFragment | opcode) of the next frame and try to
validate it as utf8.

Of course, there's a one-liner fix that works, but avoids the use of
the _sendCache Buffer.  How important is this cache?  What are the
synchronization mechanisms for avoiding this bug?

Note: I cannot reproduce this using a single machine.  I have to use a
remote server.
Note2: The actual trigger points are sensitive to the message lengths.
With shorter messages, I can get it to fail around message 80-85, and with
longer messages, I can get it to fail around message 60-65.
node version: 0.6.10
ws version: 0.4.7
arch: x86_64 linux

Reply to this email directly or view it on GitHub:
https://github.com/einaros/ws/issues/35

Could you try 0.4.8 and see if it still reproduces?

I confirm.  Bug fixed in 0.4.8.

thanks einaros

I had been pondering exactly why I added this lately. At some point (perhaps earlier in 0.6) I did see a perf gain from running it. With 0.6.11 and a newly written throughput benchmark, no perf difference could be found at all.


change default font family

how to change default font family for all components ?!!

@AntonioRedondo I don't understand your point. We have no <typography> Higher order component. Would you mind providing more detail?

https://material-ui.com/api/typography

@AntonioRedondo I don't understand. What's preventing you from setting a global font? Material-UI tries to promote isolation with this Typography component.

I think what the original poster is asking is about some functionality similar to styled-components createGlobalStyle() with which from the styling library you can set global styles without using conventional classes and CSS.

@AntonioRedondo It's already available:
import { withStyles } from '../styles';

export default withStyles({
  '@global': {
    p: {
      fontFamily: 'Arial',
    },
  },
})(() => null);

This looks 🆒.  I cannot see it on the Material-UI website. Is it documented anywhere?

It's from http://cssinjs.org/jss-global?v=v3.0.0

It's from http://cssinjs.org/jss-global?v=v3.0.0

Here's the new url: https://cssinjs.org/jss-plugin-global/?v=v10.0.0-alpha.10

@oliviertassinari in what file can this be used? I can't seem to find any context in de documentation on the website either.

@jaycc008 ?

import { withStyles } from '@material-ui/core/styles';

export default withStyles({
  '@global': {
    body: {
      fontFamily: 'Arial',
    },
  },
})(() => null);

This above code, how do I implement this in any file? I am trying to change the default font from Roboto to Noto Sans, but I don't understand where I can add this code to make Noto Sans the default font.

@jaycc008 Don't, follow https://github.com/mui-org/material-ui/issues/9988#issuecomment-359438928.


FEATURE REQUEST: force never close tags to render Inline/Block

For example:
<source> element in an xml file is not an html <source ... /> element.
I tried to put source into force inline/block, but it does not work.
so i have to disable neverclose/selfclose feature.
now obviously other neverclose elements wont be closed automatically anymore.
but thats not very important, more custom options here would be nice though.

If you don't want source to be self-closing, you can define a set of self-closing tags that does not include it, then add it to the  force block (if it doesn't render block by default). However, context dependent settings isn't a rabbit hole I intend to go down.
Ultimately this plugin is intended for use with HTML so default settings will skew towards that. I encourage you to create a separate plugin targeted at XML and use this one as a base, if that can provide you the solution you want

While most of what I said previous is still true, I discovered some things that have changed my mind on not being able to do what you want, or at least make the experience a bit better for you. That being said, it might be some time before I get around to implementing so I'm going to reopen this so I remember to keep you informed when I do get around to it.


Rubocop with RVM

Hi,
I am trying to use have VS Code run rubocop when I save.
There are in my workspace settings json file:
"ruby.rubocop.executePath": "/home/sathya/.rvm/bin/rvm-auto-ruby "

When I save however, I get this message:
/home/sathya/.rvm/bin/rvm-auto-ruby rubocop is not executable

If I open the terminal type rvm use 2.3 and then  rubocop in the terminal, rubocop works fine. What should I do to get vscode-ruby-rubocop running properly without errors on saving?
Thanks

HI,
This extension based on one executable.
Two command style like rvm-auto-ruby rubocop is not compatible.
I think rvm use 2.3_ provides a path to terminal only. not vscode.
I tested on rbenv instead of rvm.
It provides a path through desktop.
Same problems are may found rvm with TextMate, Sublime Text, and other editors.

Ah ok. Thanks for letting me know 👍

@SathyaBhat Which was the solution for make that rubocop works with vscode? I've got the same issue.

@betomoretti I didn't get it working, didn't look into it afterwards.

I tested with rvm.
these configs works fine.
"ruby.rubocop.executePath": ""
or
delete "ruby.rubocop.executePath" config (use default == search $PATH)
or
"ruby.rubocop.executePath": "/Users/you/.rvm/gems/ruby-2.3.2/bin/"

Hey all.  I worked around this by creating a shell script called rubocop. I put it in ~/.vscode/bin for convenience and changed the execute path to the same.
#!/bin/bash

export PATH="$PATH:~/.rvm/bin"
source ~/.rvm/scripts/rvm

cd `dirname $1`
exec bundle exec rubocop $@

@jimsynz I gave that a shot.
One thing to note is that you cannot seem to set the Execute Path to ~/.vscode/bin you will need to use the full path it seems.
I get this error when I try that though
dirname: illegal option -- - usage: dirname path Could not locate Gemfile or .bundle/ directory

Another note to anyone coming across this. @jimsynz post didn't fix it for me but it set me on the right track.
I did:
#!/bin/bash

source ~/.bash_profile > /dev/null
rvm ruby-version@my-gemset > /dev/null

exec bundle exec rubocop "$@"

/dev/null was necessary due to rubocop complaining about a non-json output.

@cooljacob204
Do you mind explaining what this line does?
rvm ruby-version@my-gemset > /dev/null

@cooljacob204
Do you mind explaining what this line does?
rvm ruby-version@my-gemset > /dev/null

@CornerstoneII
Sure, /dev/null is a device file that discards all data written to it.
What I am doing is suppressing the output of RVM by redirecting it's output (stdout) to /dev/null that way it's not included in the output from my bash script itself.

@CornerstoneII
Sure, /dev/null is a device file that discards all data written to it.
What I am doing is suppressing the output of RVM by redirecting it's output (stdout) to /dev/null that way it's not included in the output from my bash script itself.

Hey all. I worked around this by creating a shell script called rubocop. I put it in ~/.vscode/bin for convenience and changed the execute path to the same.
#!/bin/bash

export PATH="$PATH:~/.rvm/bin"
source ~/.rvm/scripts/rvm

cd `dirname $1`
exec bundle exec rubocop $@

@jimsynz That saved me, thank you! Adapted the same idea into a script you can run to setup ~/.vscode/bin from a shell script, or a copy & paste.
mkdir -p ~/.vscode/bin

cat <<'EOT' > ~/.vscode/bin/rubocop
#!/bin/bash

export PATH="$PATH:~/.rvm/bin"
source ~/.rvm/scripts/rvm

rvm use >/dev/null 2>&1
exec bundle exec rubocop $@
EOT

chmod +x ~/.vscode/bin/rubocop

Thanks again!


clicking on font tab crash

details: on java 16, using fabric loader 0.12.12, using version 8.0 on mc1.16.1
wtf: launched game, clicked into options > timer options > timer display options, went to click on the "font" tab and then it crashed
crash log: hs_err_pid19772.log

oh and btw, have deleted %appdata%.minecraft\speedrunigt folder completely, and then relaunched it, currently there's only options.txt inside the folder

check this pinned issue #13


WorldService retries world fetch when very first request fails

First contribution.. Let me know if I missed anything.

This PR introduces some basic retry logic for the WorldService, addressing #11819.
Note that the world fetch is only retried if the very first request fails. Any subsequent failures will simply use the 'outdated' world list. This is only meant to address the issue where the world hopper tab is left completely blank after the first fetch for worlds fails.
The retries are limited to three (with increasing delays) as to not send too many requests.
While this closes #11819, it is still possible to get a blank world hopper tab (if all three requests fail), but that's just the nature of network calls..

okhttp has the ability to automatically retry failed requests I believe. I don't know much about it (is it on now? maybe we need to turn it on?). This may be worth investigating first before we try to do something like this.

I'm unsure #11819 is even a bug? It suggests that if the worlds fail to load then they will never ever load in the future, but I don't think that is true based off of what the code does currently?

Honestly don't think it's a bug.. They would reload after 10 minutes (assuming the next request doesn't fail.
As for retries.. f I understand correctly, all API calls from RuneLite and made synchronously. An interceptor can be added to the okhttp client to do simple retries, but that can cause other issues. For example, if your server is already overloaded and dropping requests, you don't want every client retrying request immediately. For retries with backoff, you would want to use some asynchronous calls.

https://square.github.io/okhttp/3.x/okhttp/okhttp3/OkHttpClient.Builder.html#retryOnConnectionFailure-boolean- this is what I was referring to, which looks like it is on by default. I'm unsure if it would apply in this situation though.


New structure according to the palette categories

Purpose
New structure of the node-red-contrib-quantum repository according to the palette structure (2 categories of nodes).
> node-red-contrib-quantum
   > nodes
      > quantum
         > quantum-circuit
         > quantum-register
         ...
      > quantum-algorithms
         > grover
         > short
         ...
      errors.js
      python.js
      snippets.js
      state.js

Changes
No changes were required except changing the paths in package.json.
If you ever think about some code that needs to be updated, please let me know !

The structure of the test/ directory needs to be updated as well, and the require statements used in the tests need to be modified to reflect the new changes.

I've pushed some commits to update the paths for the unit tests, the npm package files listing in package.json, the workflow paths in node.js.yml, and the paths referenced in CONTRIBUTING.md. I think everything should be ready to merge now.

I've pushed some commits to update the paths for the unit tests, the npm package files listing in package.json, the workflow paths in node.js.yml, and the paths referenced in CONTRIBUTING.md. I think everything should be ready to merge now.

Thanks a lot Louis, I did not intend to give you more work, sorry about that.

Thanks a lot Louis, I did not intend to give you more work, sorry about that.

Aha no problem, only took a few minutes 😁


from-args does not work because it is missing from-args

Doing from-args, i.e. without a manifest template spec, just doesn't work. Running it gives:
Incorrect Usage.

NAME:
   /bin/manifest-tool push - push a manifest list entry to a registry with provided image details

USAGE:
   /bin/manifest-tool push command [command options] [arguments...]

COMMANDS:
   from-spec	push a manifest list to a registry via a YAML spec
   from-args	push a manifest list to a registry via CLI arguments
   help, h	Shows a list of commands or help for one command

OPTIONS:
   --help, -h	show help

time="2019-06-06T09:45:53Z" level=fatal msg="flag provided but not defined: -platforms"
2019/06/06 09:45:53 exit status 1

Looking at the code, it appears that it never passes from-args to the /bin/manifest-tool command. It does pass from-spec when needed, but not from-args. It adds from-spec here, but the place to do the same for from-args here has nothing.
Should be a simple fix.

You seem to be right, could you create a PR to fix that? Thanks.

Sure.

I'd really love to see this merged :)

Thanks for the headsup, I simply forgot about this PR/issue ;)

This doesn't seem to be documented.

This doesn't seem to be documented.


fix bug of fetching paging info from Microsoft Graph API

Fix bug of issue #17120
Ref: https://docs.microsoft.com/graph/paging?toc=./ref/toc.json&view=graph-rest-1.0
https://docs.microsoft.com/en-us/previous-versions/azure/ad/graph/howto/azure-ad-graph-api-supported-queries-filters-and-paging-options#paging-support-
Modify the property to receive next page link of membership information from Graph API to support both odata.nextLink(Azure AD Graph API) and @odata.nextLink(Microsoft Graph API).

/azp run java - spring - tests

/azp run java - spring - tests

Hi, @yiliuTo , could you please write unit test for this?
Seems we already have json file for this test:
https://github.com/Azure/azure-sdk-for-java/tree/master/sdk/spring/azure-spring-boot/src/test/resources/aad


Line number should be able to clickable  (like Github) or support custom component

Is your feature request related to a problem? Please describe.
I'm trying to implement a source code viewer which is similar like GitHub.
It should support highlight a single line by clicked.
the url path should added "https://github.com/conorhastings/react-syntax-highlighter-virtualized-renderer/blob/master/package.json#L3"
If we could support multi lines selected that will be great ! example: "https://github.com/conorhastings/react-syntax-highlighter-virtualized-renderer/blob/master/package.json#L3-L15"
Describe the solution you'd like
If this lib could implement same feature like GitHub.
Describe alternatives you've considered
support use custom component for each line number, that will be great

this is supported -- see issue 101


Add 5 various theory of mind tasks

Added the aforementioned theory of mind tasks mentioned in the discord.

Can you remove the double ---'s - it should just be one between each task and its good to go!


Update the documentation for windows

Just a few things I noticed about "Getting Up and Running Locally"
Many commands in the guide don't work for Windows (I'm using Powershell).  For example, creating and activating a virtual environment, the 'export' command doesn't work on windows (must use 'set') One also needs to use a newer version of rcssmin==1.1.0 than what the install script tries to install ( and recent versions of pip don't allow it to be installed with install-option="--without-c-extensions"  )
It would also be useful to have a little more handholding (as I am a newbie) around creating an env file to just get started. Currently, I can't get the app to find my DB (could be that the .env file I created is formatted wrongly or in the wrong directory)

I hardcoded the db settings into thebase.py file and that worked.


Allow for loading dynamic components defined in extensions

Summary
This fixes an issue with rendering components that are lazy loaded via an extension configuration. For example:
  plugin.addCard(
    CardLocation.CLUSTER_DASHBOARD_CARD,
    { cluster: ['local'] },
    {
      label: 'some-label2',
      labelKey: 'plugin-examples.card-title-three',
      component: () => import('./components/MastheadDetailsComponent.vue')
    }
  );

defineAsyncComponent helps Vue handle the asynchronous nature of lazy loading and markRaw prevents Vue from making the component reactive, which can help with performance.

Occurred changes and/or fixed issues

wrap the component property for Card, Tab, and Panel in defineAsyncComponent and markRaw

Areas or cases that should be tested

This has been tested with extensions-api-demo
Other extensions should be tested and verified

Areas which could experience regressions

Loading extensions that might not lazy load components

Checklist

[x] The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
[x] The PR has a Milestone
[x] The PR template has been filled out
[x] The PR has been self reviewed
[x] The PR has a reviewer assigned
[x] The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
[x] The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

Is there any limitation to defining the component without reactivity for this purpose? If so it should probably be more informed in a way that it cannot be missed by other developers, as it may create big headaches, especially for non-Vue experts.

I took the initiative to shove my conversion to TS of the helper since I started to convert it to do some investigations. Please feel free to remove it if bothers you and let me know if I should avoid such actions.

I took the initiative to shove my conversion to TS of the helper since I started to convert it to do some investigations. Please feel free to remove it if bothers you and let me know if I should avoid such actions.

This is fine by me, the included changes don't modify the behavior of this PR at all 🙂


CVE-2021-31566, CVE-2021-23177 on libarchive which affected conda-package-handling

conda-package-handling is built with statis libarchive version 3.4.3, which has the following vulnerabilities:

https://nvd.nist.gov/vuln/detail/CVE-2021-31566
https://nvd.nist.gov/vuln/detail/CVE-2021-23177
It would be great to patch libarchive or update this to 3.5.2 version and rebuild conda-package-handling.

Could you @katietz @tobijk @chenghlee @remkade take a look at this problem?

+@AndresGuzman-Ballen

Just ping @katietz @tobijk @chenghlee @remkade

Would it be difficult to update _libarchive_static_for_cph-feedstock to 3.5.2 and pin conda-package-handling to it?

I'm trying to fix this issue https://github.com/AnacondaRecipes/conda-package-handling-feedstock/pull/7

@ekomarova conda-package-handling 1.9.0 build 1 (with libarchive_static_for_cph 3.6.1) is available on defaults


White overlay not disappearing ( Permission denied to access property "apply" )

In Firefox (tested on 72.0.1), on a plain installation of una, no plugins, in several places the semi-transparent white overlay under popups never disappears, making the page unusable. This happens for example in the app store, after clicking on an app to read its description, and then trying to close the popup. Or when creating a new profile, clicking on upload profile picture, and then trying to close the popup.
There is an error that shows up in the javascript console (this does not show up in chrome, this whole issue doesn't happen in chrome):
Error: Permission denied to access property "apply"gzip_loader.php:5:11594
    trigger gzip_loader.php?file=bx_templ_js_7e0a71557ec662578c267e446a693efe.js:5
    trigger gzip_loader.php?file=bx_templ_js_7e0a71557ec662578c267e446a693efe.js:13
    triggerHandler gzip_loader.php?file=bx_templ_js_7e0a71557ec662578c267e446a693efe.js:5
    oOnHide gzip_loader.php?file=bx_templ_js_7e0a71557ec662578c267e446a693efe.js:330
    complete gzip_loader.php?file=bx_templ_js_7e0a71557ec662578c267e446a693efe.js:6
    i gzip_loader.php?file=bx_templ_js_7e0a71557ec662578c267e446a693efe.js:4
    fireWith gzip_loader.php?file=bx_templ_js_7e0a71557ec662578c267e446a693efe.js:4
    i gzip_loader.php?file=bx_templ_js_7e0a71557ec662578c267e446a693efe.js:6
    tick gzip_loader.php?file=bx_templ_js_7e0a71557ec662578c267e446a693efe.js:6

I can help debugging if needed

I can't reproduce the issue. Please try to clear UNA cache via Studio > Dashboard > Cache, it maybe it'll help.


Error with mutually exclusive tags when applied to two different columns on the same table

Affected module
UI is affected
Describe the bug
We have a tag called "status" that we use to tag assets depending on their validation status. The potential values are: unsolved, pending validation and validated. The values are mutually exclusive.
We were working on Openmetadata 1.0.0, and we were using the tag to label the status of all columns for one specific table. If the description of the column was not done, it was "unsolved", if it was done but not reviewed it was "pending verify" and if it was verified by the table owner, then "verified".
We upgraded openmetadata to to 1.1.7 and then from 1.1.7 to 1.3.2. Since then, the table is locked and we can't update. Anytime we try to add a description, or remove a tag or any change in the table (even change the owner) we get the following error:

To Reproduce
Not sure this will work, but maybe reproducing our scenario:

Create a mutually exclusive tag
Try to add 2 different values to 2 different columns on the same table.

Expected behavior
Be able to add different tag values on each table column.
Version:

OS: [e.g. iOS]
Python version:
OpenMetadata version: 1.3.2
OpenMetadata Ingestion package version: image = [docker.getcollate.io/openmetadata/ingestion:1.3.2]

Additional context
None

You cannot assign a mututally exclusive tag to the same column or table. This was a bug which was fixed. Now you are geting issues because your table has multiple mutually exclusive tags. Remove the mutual exclusivity in the tag category so that you can fix these issues.

Hi @harshach , thanks for your contribution. I have tried to remove the "mutual exclusivity" property on the tag category from the UI but there is no way of doing it. Any idea on how to do that without having to recreate the whole tag?


⚠ Bofrost.at has degraded performance

In 7f571e3, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2277 ms

Resolved: Bofrost.at performance has improved in 13244ff.


semi working for 6.5.4

Semi Working for kibana 6.5.4.
Will fix the relevant bugs in the future.

It will be crash when vis version is 4.16.1.

@porkiz  I close this PR. I push my version with only the useful features. Thank you for helping me 👍


Added more details to project

Added LICENSE file
Removed vendor from checkin items
Added description of project

Signed-off-by: Shubhendu<EMAIL_ADDRESS>

@aruniiird @umangachapagain @cloudbehl please review


Font Curves: Optimize

Figma:
https://www.figma.com/file/xZ0IW0MJO0vnFicmrHiKaY/Components-Post?type=design&node-id=20702%3A14987&mode=design&t=SiIozCQkJVhqkBSu-1
Update and Optimize Curves:
https://www.figma.com/file/ojCcgC5Zd12eUSzq6V5m24/Foundations?node-id=3%3A955&t=6qJsoz9r71BHjnn4-1
Curves use values (15, 17, ...) that are not used elsewhere. Curves are important for automatic responsive type in the implementation and used extensively
Curves lack a description for when to use which curve
Can we map responsive heading size progression to a curve?
Fonts are named atm (big, biggerBig, huge). In future mor like (size16, size18, size20, ...)?
Namings of curves and fonts should have the same system (e.g. names or sizes / sizerange).

No longer needed with tokens


Break wal_craft -> postgres_ffi -> wal_craft dependency cycle

rust-analyzer complained about a dependency cycle for a while

[ERROR project_model::workspace] cyclic deps: wal_craft(CrateId(373)) -> postgres_ffi(CrateId(225)), alternative path: postgres_ffi(CrateId(225)) -> wal_craft(CrateId(373))

I'm not familiar with wal_craft tool, but seems that there are two main usages of it:

the cli, that's now moved under pageserver/src/bin list of binaries, but could as well go into safekeeper. That did not have any src/bin/ subdirectory though, ergo the choice.
the test code in libs/postgres_ffi/src/xlog_utils.rs module

The PR aims to preserve both use cases and clean the dependency tree.
Additionally, it avoids tempfile dependency and creates unix socket tmp dir manually, see first commit.

My biggest reason for pushing this change finally is to unite initdb invocation and its parameters.
3rd initdb call is in wal_craft, which is simpler to fix when it is in postgres_ffi from where the logic of creating the common initdb command could be exported to pageserver as pub fn or similar.

Includes https://github.com/neondatabase/neon/pull/3281 after the review.


Fix frameworks using constant context value

react/angular/angular2/vue/vue3 components call render method using a constant CONTEXT.IFRAME overriding user's defaultContext from create options
Fixes #393

This is by design -- React/angular/etc. components are inline by definition, so need to be in iframe mode. To open a popup you would need to wait for a user event like a click, then manually call MyComponent({ ... }).render()

@bluepnume the render method by default uses an iframe. Forcibly passing the context constant not only overrides the defaultContext option on the component's definition but also makes the docs misleading and this option obselete altogether
https://github.com/krakenjs/zoid/blob/main/docs/api/create.md#defaultcontext-string

Sure but defaultContext means "it will pick this context by default" not "it will pick this context always". If you render a React component, it's like you're implicitly saying "this component should render inline in this case, so I want to override the default".
Example:

You have a component
If a user clicks on a button, you want to open it in a popup -> so you call .render() manually
If there is no click, you want to fall back to an iframe -> so you render using the React driver, knowing that is implicitly inline

I think I'm not quite following -- why would the event listener use the driver in step 3, but then manually call render in step 4 -- wouldn't it pick one or the other consistently? Can you share a small code sample of what you mean here?

you understand my point correctly.
When using the driver pattern, the app cannot control the context in render method as it is using a constant value (iframe) instead of defaultContext option from component def.

I guess let me rephrase the question; what do you want to happen with a driver render in the case that defaultContext is a popup? Do you want zoid to render a popup in that case?

Right, so that's the underlying problem here. Normally browsers only allow you to open a popup on a user-initiated click or keyboard event -- and only synchronously. Whereas many rendering libraries, including I think React, do not synchronously render on click. That will mean a lot of the time your popup is completely blocked from opening.
So if you want to open a popup, my recommendation would be to explicitly listen for a click or keyboard event, then manually call MyComponent({ ... }).render() rather than using a driver.

That's a fair work around. Regardless of how it should be done, the defaultContext value should be coming from component's definition instead being hard coded as it currently.
The default value of defaultContext is iframe. This PR addresses it.

I'm really not sure I agree. The logic as it stands is:

If the caller signals their intent to render to a specific context, use that context. e.g.
a) The caller explicitly passed in a context when rendering, or
b) The caller rendered the component using a driver that is implicitly inline (and does not even work in popup mode)
If there is no intent at render-time, fall back to the defaultContext
If there is no defaultContext, fall back to iframe

Not to mention -- this is a backwards incompatible change, right? Given that there could be zoid components out there which are currently relying on the behavior of "Render to a popup by default, but fall back to an inline iframe if the caller uses a driver and it's not possible to render into a popup".

My use case is I cannot render a popup using the driver pattern as it forces an iframe over component definition options.
The code that I am targeting is only driver.register for all the supported frameworks. Your description is accurate for the rest. In the driver pattern:

The component is rendered as soon as it gets mounted.
a) The driver code explicitly passes iframe context argument to render (as referred above), overriding the defaultContext from component definition options. The default value of defaultContext is always iframe so explicitly passing iframe to render() only overrides the defaultContext option stated in component definition.
b) The component gets in a popup mode just fine and renders the url from component definition.
The driver pattern does not fallback to defaultContext at render-time as the render method was called with context=iframe explicitly.
The default value of defaultContext is iframe so the driver.register should not pass context argument explicitly.

This is backwards compatible in that, it will render to a popup by default, but will fall back to an inline iframe if the caller uses a driver since the default value of defaultContext will be iframe always.
References:
https://github.com/krakenjs/zoid/blob/eb8677a3c41f8ad52158ad946573d0df9a47538d/src/component/component.js#L354
https://github.com/krakenjs/zoid/blob/eb8677a3c41f8ad52158ad946573d0df9a47538d/src/component/component.js#L184

Why do you want to render a popup window using the React driver when it will be blocked by the browser?
This is what happens when I run a test locally to do this:

It's not an artifact, I see the exact same behavior in Chrome, Safari and Firefox:

Which specific browser and version are you testing in? And did you allow an exception in the browser to prevent popup blocking?

https://stackoverflow.com/questions/2587677/avoid-browser-popup-blockers

It is an artifact because this behavior is a result of

User's browser preferences
How the app triggered render on driver component.

Also, notice that I have not allowed the popup by default. I am using chrome and my apps renders the driver component only when the user does an action.
It is problematic because the driver then does not use my defaultContext option. It is an over-generalization to enforce the driver's behavior to use an iframe while the user has different preferences.
Notice that it is not necessary for the driver to explicitly pass iframe to render, as the render method is going to resolve the finalContext from getDefaultContext which will return defaultContext if any with the default value iframe
References:
https://github.com/krakenjs/zoid/blob/eb8677a3c41f8ad52158ad946573d0df9a47538d/src/drivers/angular2.js#L85
https://github.com/krakenjs/zoid/blob/eb8677a3c41f8ad52158ad946573d0df9a47538d/src/component/component.js#L354
https://github.com/krakenjs/zoid/blob/eb8677a3c41f8ad52158ad946573d0df9a47538d/src/component/component.js#L184

It is an artifact because this behavior is a result of
User's browser preferences

Sure, but the default behavior is to block in every browser I've ever used. Are you working in an environment where users of your component will have to change their browser settings before using your component?

How the app triggered render on driver component.

Not really - libraries like React force components to be asynchronously rendered, right? So even using a click event won't help much here.

This sounds like an over generalisation to optimize user experience essentially by handicapping the app to render a popup when using the driver (More at end).
The current design violates two SOLID principles (Learn More):

Single-responsibility principle.

The documentation clearly states that defaultContext is responsible for setting the context during render. The same is not reflected when the driver renders the component thus the driver takes off responsibility to itself handicapping the app of the ability to do so.

Dependency inversion principle

The driver code assumes of a concrete scenario that the user's browser has certain fixed behavior and  changes the abstract behavior of zoid (i.e render should use CONTEXT.IFRAME) that is not the original intent of the app.

FYI; all versions of react do not force asynchronous rendering. Learn More
A Live Demo how with-react-driver renders a popup without the browser blocking and context=iframe not hardcoded inside driver.register

Thanks for the demo! OK I'm convinced. If you can trigger a synchronous render through React, that's good enough for me.
That said: there is still a backwards-compatibility question here; there could be users of zoid who are currently relying on the behavior of defaulting to a popup, but falling back to an iframe when using any one of the drivers.
So let's brainstorm a little on an interface that can allow us to override the default behavior and also preserve backwards compatibility. A few ideas:

A new defaultDriverContext option
Allow passing context as a prop
Allow passing context when calling .driver()

Parent props should have context option so that the app can control the context during render cycle

I think I'd be happy with this solution. It's not really a traditional 'prop' in that it's not needed in the child window/frame. But it avoids any backwards compatibility problems.

Please take a look at the changes now. Here is a brief summary of this PR:

Adds parent prop context
Drivers call render method with context value from component's props
Fix demos to add dimensions. Currently an invalid value undefined is used for height/width causing the component to have no height/width. Environment: MacOS Chrome 98
Fix vue + angular2_Typescript demos to use correct script's bundle url

Codecov Report

Merging #397 (f28473b) into main (eb8677a) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #397   +/-   ##
=======================================
  Coverage   95.51%   95.52%
=======================================
  Files          18       18
  Lines        1182     1184    +2
=======================================
+ Hits         1129     1131    +2
  Misses         53       53

Impacted Files
Coverage Δ

src/component/props.js
93.93% <ø> (ø)

src/drivers/angular.js
95.83% <100.00%> (+0.18%)
:arrow_up:

src/drivers/angular2.js
93.75% <100.00%> (+0.20%)
:arrow_up:

src/drivers/react.js
100.00% <100.00%> (ø)

src/drivers/vue.js
100.00% <100.00%> (ø)

src/drivers/vue3.js
87.50% <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 eb8677a...f28473b. Read the comment docs.

@bluepnume please update on this

Hello sir @artmanque, i'm using zoid with vue3, do you know how i can configure the component correctly? the error that i have say

My configuration is this
`
import * as zoid from 'zoid/dist/zoid.frameworks';
const DemoBreakout = zoid.create({
tag: 'a-simple-tag',
url: 'some-url',
dimensions: {
width: '100%',
height: '100%',
},
attributes: {
iframe: {
scrolling: 'no',
allow: 'camera *; microphone *; display-capture *;',
allowFullScreen: 'true',
allowusermedia: 'true',
},
},
props: {
gamesList: {
type: 'array',
required: false,
},
gameQuestions: { type: 'array', required: false },
dispatchQuestionForGame: {
type: 'function',
required: false,
},
startWithVideo: {
type: 'boolean',
required: false,
},
},
});
const Breakout = DemoBreakout.driver('vue3');
export default Breakout;
`
Your PR is the solution for this or this is something different?. Zoid documentation is really bad and the vue demo is broken

@JoseIsra i suggest you to try running vue3 example from this PR before testing it in your app

@artmanque how can i use zoid from its own repository. Do you have some sample code to follow? I can clone the repo and run the setup script, the package json says that. But after that? I'm new in this library-repository use case u.u


When will the trainable version be out

Look forward to it!

Not sure yet but maybe within a month.


Helper to access to api response object

Implemented throught onSuccess callback, that now has direct access to response object
https://github.com/alambike/eixo-rest/commit/88f23a68d91b0fb706d9d46ae411254e2c1f6880


Always position the window in front

I would like to have the option to "Always position the window in front".
Sometimes it's hidden by other applications window.

Add in PR #61. It will be included in the next release.

Add in PR #61. It will be included in the next release.

Thank you for your quick update. I'm looking forward next release. The timing for closing this issue is up to you.

Thank you for your quick update. I'm looking forward next release. The timing for closing this issue is up to you.

v0.2.0 is released. This release includes the always on top feature.

v0.2.0 is released. This release includes the always on top feature.


More flexible linker support & running from flash

Added ability to use flash/read-only code and data. (This requires usage of a 2nd stage bootloader)
Updated flash script to be able to use bootloader
Added support for RTC memories (and prepared support for external memory)
Added #[ram] attribute to force placement of data in certain type of memory
Added example to showcase #[ram] attribute

This builds on #11, which should be merged first. It also relies on a pull request of the xtensa-lx6-rt crate: https://github.com/esp-rs/xtensa-lx6-rt/pull/10

This one is now based on #15.  It also relies on a pull request of the xtensa-lx6-rt crate: esp-rs/xtensa-lx6-rt#10. (It could be that the commit hash in Cargo.toml needs to be updated once the xtensa-lx6-rt is merged.)

Rebased again after small fixes: This one is now based on #15. It also relies on a pull request of the xtensa-lx6-rt crate: esp-rs/xtensa-lx6-rt#10. (It could be that the commit hash in Cargo.toml needs to be updated once the xtensa-lx6-rt is merged.)

Uses custom bootloader by default, which initialized External RAM: https://github.com/arjanmels/esp32_bootloader_init_extram
Some minor fixes and improvements

Sneaking in some further improvements, while the pull is pending ;-)

Rebased on latest master. First the following pull of the xtensa-lx6-rt crate should be done: esp-rs/xtensa-lx6-rt#10.

Slipped in one minor improvement in flash script.


Laravel 11.23.4 Shift

This pull request includes updates for the recent minor version release of Laravel as well as updates to your package dependencies. Feel free to commit any additional changes to the shift-ci-v11.23.4 branch.
Before merging, you need to:

Checkout the shift-ci-v11.23.4 branch
Review all pull request comments for additional changes
Run composer update
Thoroughly test your application (no tests?, no CI?)

:warning: The Shift build servers run PHP 8.2. If you are running a different version of PHP you should run composer update locally to ensure you have the proper versions of your dependencies to reflect your PHP environment.


Generator create new file without wrapper folder

Describe the bug
hello all
when try to generate new [ screen, model , component  ] or
the generator create new file with out the wrapper folder
& import index.ts file not work anymore
!Hint  create date Fri Sep 16 01:30:31 2022 +0200
npx ignite-cli new
npx ignite-cli g component cart-item
out put
 Generated new files:
   pwd/someappName/app/components/CartItem.story.tsx
   pwd/someappName/app/components/CartItem.tsx

model too

   Generated new files:
   /app/models/Test.test.ts
   /app/models/Test.ts

Ignite version
8.2.0
Additional info
System
  platform           darwin
  arch               x64
  cpu                12 cores      Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  directory          openFashion   /Users/mahmoudhamdy/Desktop/me/p-work/react/openFashion

JavaScript (and globally-installed packages)
  node                  14.19.0      /usr/local/opt/node@14/bin/node
  npm                   6.14.16      /usr/local/opt/node@14/bin/npm
    @sanity/cli         2.23.2
    appcenter           4.2.0
    appcenter-cli       2.9.0
    axios               0.21.1
    detox-cli           18.0.0
    expo-cli            5.3.2
    firebase-tools      11.8.0
    ios-deploy          1.11.3
    npm                 8.4.1
    npm-check-updates   12.5.4
    osmi-cli            1.2.0
    pod-install         0.1.18
    react-devtools      4.10.4
    rtlcss              3.5.0
    typescript          4.5.5
    yarn                1.22.10
  yarn                  1.22.10      /usr/local/bin/yarn
    create-next-app     11.0.0
  pnpm                  -            not installed
  expo                  45.0.8       managed

Ignite
  ignite-cli         8.2.0        /Users/mahmoudhamdy/.npm/_npx/10289/bin/ignite
  ignite src         build        /Users/mahmoudhamdy/.npm/_npx/10289/lib/node_modules/ignite-cli/build

Android
  java               <IP_ADDRESS>    /usr/bin/java
  android home       -            /Users/mahmoudhamdy/Library/Android/sdk

iOS
  xcode              14.0.1
  cocoapods          1.11.3       /usr/local/bin/pod

Tools
  git                git version 2.37.0 (Apple Git-136)   /usr/bin/git

Hi @xforcarlos! Since our new v8 update on Ignite, we restructured the generated files to be added without the folder. Also, I noticed that your generator still adds a story file which shouldn't be the case with the new update either.
Will you please confirm that you have updated the generator templates? If you haven't, please replace your component template file with this?
Once you have the frontmatter you can modify it to generate the files at whatever path you'd like by adding destinationDir: app/navigators like here
Hope this helps!

@kateinkim
thanks for help
i use older version of ignite not maverick
how can i use old version of cli to generate files with old structure

@kateinkim
thanks  i used the old version in g by
npx<EMAIL_ADDRESS>


remove dependency on num_cpus

remove external dependency on num_cpus(), use instead built-in available_parallelism() added in rust 1.59.0
we originally listed requiring a much earlier version of Rust, but Goose wasn't correctly compiling with such an old Rust; bumping up our dependency to something more modern

/ This might totally be unrelated, I'm new to the rust ecosystem /
I tried to build goose yesterday on NixOS and it already required rust version 1.65 because of the dependency on the time crate. See here:
bebe@gulasch:~/goose$ cargo build --example simple
    Updating crates.io index
  Downloaded rustls-pemfile v1.0.2
  Downloaded hyper-rustls v0.23.2
  Downloaded 2 crates (50.3 KB) in 0.77s
error: package `time v0.3.21` cannot be built because it requires rustc 1.65.0 or newer, while the currently active rustc version is 1.64.0

Wouldn't it be appropriate to even tag goose to have rustc version 1.65?


macro output with MSVC

All the compilers present on compiler explorer show the output of a defined macro except MSVC due to a permission denied of a file .i.
Could it me possible to give the access of this file ?
Test case
#define EMPTY()
#define DEFER(id) id EMPTY()
#define A() 123

using MSVC with option /P gives the following error message
Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25017 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.
example.cpp
Internal Compiler Error in Z:\opt\compiler-explorer\windows\19.10.25017\lib\native\bin\amd64\cl.exe.  You will be prompted to send an error report to Microsoft later.
INTERNAL COMPILER ERROR in 'Z:\opt\compiler-explorer\windows\19.10.25017\lib\native\bin\amd64\cl.exe'
    Please choose the Technical Support command on the Visual C++
    Help menu, or open the Technical Support help file for more information
<source>: fatal error C1083: Cannot open compiler generated file: 'example.i': Permission denied
Compiler returned: 2

Argh it works with option /E !!!!


adding config for additional api endpoint to default certs, rh-api.cl…

…uster. Shortening time waiting on DNS propagation from 60 to 30 seconds.

Is there justification anywhere regarding the shorter time for propagation validation?

@dofinn scalability. Each name in the cert is a 1 minute wait timer. If we get to 4 names per control plane cert (we will) then we're waiting 4 minutes for certman to complete the request. This will keep that lower.

/lgtm
/approve
/hold
Is this ready to go in, @c-e-brumm? If so, feel free to /hold cancel

/hold cancel


chore: Add docs for namespace scoped and cluster scoped privileges

What type of PR is this?
This PR updates the docs w.r.t

/kind documentation

What does this PR do / why we need it:
This PR adds docs for the below features

Default Permissions for a namespace scoped Argo CD Installation
How to configure an Argo CD instance to cluster scoped
Default Permissions for a cluster scoped Argo CD Instance
How to extend the permissions of an Argo CD Instance to deploy additional resources
How can Argo CD deploy resources to different namespaces

Have you updated the necessary documentation?

[x] Documentation update is required by this PR.
[x] Documentation has been updated.

How to test changes / Special notes to the reviewer:

Install Mkdocs
Run mkdocs serve

@jaideepr97 can you please review this ?


Annoying "lightbulb" whenever placing cursor into constant js/ts expression

VSCode Version: Insiders
OS Version: macOS

Steps:

open js or ts file
place cursor in any constant expression (e.g. in the "1.16.6" below)

Observe: a "lightbulb" appears:

IMO this is an idiotic suggestion and I find this quite annoying.
Do we have telemetry info that shows that users are actually using this?

@weinand This was just added by TS 2.5. Showing extract method in this location looks like a TS bug to me, but I also think we need to think about what we want the UX to be in other case. I'd argue that we should only show the lightbulb when the user has made a text selection. The CodeActionProvider does not currently support controlling whether or not the light bulb is shown

See #33282

This is a general issue with the light bulb and how we check if it should be shown. There two things;

The "Quick Fix"-command which is bound to Ctrl/Cmd+.
The lightbulb that is trying to sell this feature

To show the light bulb we monitor what is happening in the editor, ask silently for code actions, and iff there are any then we show the light bulb. The monitor-logic today is the following: Check to show lightbulb when the cursor is on a diagnostic, (2) check to show lightbulb when we have a non-empty selection on a "word". The latter is what is annoying and the plan is to change it to check to show lightbulb only when there is non-empty selection.

In Eclipse the light bulb decoration is always there regardless of where the text cursor is. As a result, I was initially very surprised to see that the light bulb only appeared in VS Code when the text cursor entered the range the area that the diagnostic underlined.
I feel that it will become very difficult for new users to realize that quick fixes are available as users will now be forced to make a text selection where the diagnostic is to get the light bulb to appear. The fact that you currently have to place your cursor where the diagnostic is to "check for the existence of quick fixes" is already non-obvious to users in my opinion.
Whereas in Eclipse I can immediately tell visually if quick fixes are available, in VS Code I have to click on every diagnostic to verify this. With the suggested upcoming new behaviour, I will have to double-click every diagnostic to select a word or click inside the diagnostic and then hit Ctrl+. to test if a quick fix is available.

I'm also not excited about code actions becoming less discoverable by requiring a selection - the easy discoverability is what makes code actions so useful to begin with. IntelliJ also doesn't require a selection, and for some code actions, requiring a selection really wouldn't make much sense:

There is one thing that annoys me about code actions always being available, which is them getting in the way of breakpoints (#25564). This can be solved differently though, IntelliJ solves this by showing the light bulb in the editor area, not the gutter:

@rcjsuen and @Gama11 - Thanks for the input! Let me try to slice and dice this into pieces

In Eclipse the light bulb decoration is always there regardless of where the text cursor is. As a result, I was initially very surprised to see that the light bulb only appeared in VS Code when the text cursor entered the range the area that the diagnostic underlined.

Agreed. That is useful and something we will look into for #25149

I feel that it will become very difficult for new users to realize that quick fixes are available as users will now be forced to make a text selection where the diagnostic is to get the light bulb to appear

Nothing will change there: when you are inside an error/warning having an empty selection is enough. Again, we can improve this by showing the lightbulb for errors/warnings more often, e.g. when you are on the line.
This is about getting a lightbulb while you type and, worst, the lightbulb preventing you from setting breakpoints. @Gama11 presents a nice sample for having a lightbulb even for empty selections and while I agree on the usefulness, the lightbulb/breakpoint conflict still exists.
To put this in perspective, this is a "tactical" fix for the August release. We want to ship with TypeScript refactorings but we don't want to steel the ability to set breakpoints. So, while we work on #25174 we will have the slightly changed lightbulb behaviour - not because that's the right thing but because it is less bad.
This is how it looks/behaves with my changes:

We want to ship with TypeScript refactorings but we don't want to steel the ability to set breakpoints.

That's fine and all, but this affects more than just TypeScript. I can't say I like the idea of a temporary (as it seems to be), "tactical fix" (which is really just an embellishment for "hack") for TypeScript affecting all other language servers with code actions.
In the Haxe extension, we've had an "Extract Variable" code action for a while, but one of the reasons we have decided not to include it in releases yet because of this exact issue (it getting it in the way).
It might necessary for code actions to have flag that determines whether they are "selection-based" - some, like "Extract Method" or "Extract Variable" probably don't make sense without a selection. Which raises the question whether they should be code actions in the first place - the other alternative that I can see is to not implement these as code actions, but commands. This is what IntelliJ does - it doesn't implement these as code actions:

The more I think about it, the more I think that's the right approach, because code actions are usually "quick fixes" where the language server can easily tell that something could be improved a bit (remove unused code, replace anonymous function with short lambda, etc). They don't require input from the user, like a selection.
Refactorings like extracting methods or variables are something that require more "intent" by the user. They're usually something you specifically request the editor to do, because they're too complex for the editor to come up with good suggestions. With code actions, it's the other way around: you "stumble" over them and (hopefully) think "good point editor, let's make that a bit nicer".

Thanks @jrieken! With the workaround, should we keep this bug open? In my testing, the original issue seems mitigated

From this discussion, I that our refactoring story needs some more thought. I have opened #33555 to track issues / missing features with our current refactoring support and linked back to the comments here from that issue. Feel free to add your thoughts to the new issue as well

Yeah, I'll close this and we will continue the conceptual work in #33555 and the UX work will happen in #25174

That also means that we will restore the lightbulb with empty selection when having a less annoying UX


Add git:change command

When the package.json changes, an npm install should be made automatically.

is obsolete


v1.6-beta.2: Text Substitutes don't work as expected in symbols

when using Text Placeholders a la {placeholder?} that should be substituted with the default substitute, Sketch 3.7.1 crashes when using the "missing-data" Preset that comes with the demo.

here's a test file – try populating the "item two" symbol with the "missing-data" preset that comes with the demo. re-populate until you run into an empty field.
datapop new symbols.sketch.zip

@nitrada in my testing, substitutes worked without any issues however I've found another issue with missing/invalid image URLs when populating symbols. This could be the cause of the crashes - fixed in the latest commit.

@lukasondrej will check.

@lukasondrej seems to work now. the text formating behavior is a bit strange still, will go into detail sometime later. https://github.com/preciousforever/sketch-data-populator/releases/tag/v1.6-beta.3


macOS: Rename "Open in Explorer" to "Open in Finder"

When system is macOS, rename the command Open in Explorer to Open in Finder.

This change was not also applied to FileManager.sublime-commands.

Oh yeah I didn't realise that. I don't think the platform field is supported in .sublime-commands though, so that means that we'd have to create a "wrapper" command that would only be shown on Mac, and call the actual find in explorer (and the original find in explorer would be enabled but not visible). It's hacky, but I think it'd work... Would you wanna try to implement that @jpcirrus?

Yes, had tried to add a platform key to FileManager.sublime-commands and both commands appeared in the panel ☹ . Unfortunately, I haven't worked in Python since 2013, and only in the last month am coming back to ST after having moved away in 2014 due to "the disappearance" and having been previously burnt with TextMate, so it would take me some time and I have some assignments to submit in the next couple of weeks, so I'm probably not the person for it now.
But, on OSX, to open a path in the Finder you can use the command open -R path. R for reveal.


fix: Fixed warning note

#38  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tazarov and the rest of your teammates on  Graphite


I assume, that public_subnets are designed for the hosts, which have public IP association
Please, correct me if I'm wrong

I guess, I figured it out. It's my lack of expertise in AWS networking


FILTER logic totally broke for my query in 3.4-rc4

I installed anrango 3.4-rc4 and some of my unit tests failed. While fixing some of them I found this bug:
DUMP: debugDump.zip
This is a reduced version of my query:
FOR orderedDish IN OrderedDish
FILTER
  orderedDish._from == @target &&
  orderedDish.cart == @cart &&
  (!orderedDish.isOrdered || orderedDish.isCanceled)

RETURN {
  cartEntry: orderedDish,
  notOrdered: !orderedDish.isOrdered,
  canceled: orderedDish.canceled,
  wrong: orderedDish._from == @target && orderedDish.cart == @cart && (!orderedDish.isOrdered || orderedDish.isCanceled)
}

where the result is:
[
  {
    "cartEntry": {...},
    "notOrdered": false,
    "canceled": null,
    "wrong": false <--- THIS IS THE FILTER STATEMENT!!!
  }
]

checking the execution plan shows this:
 Id   NodeType          Est.   Comment
  1   SingletonNode        1   * ROOT
  7   IndexNode            2     - FOR orderedDish IN OrderedDish   /* edge index scan */
  8   CalculationNode      2       - LET #1 = (orderedDish.`cart` == "cartA")   /* simple expression */   /* collections used: orderedDish : OrderedDish */
  4   FilterNode           2       - FILTER #1
  5   CalculationNode      2       - LET #3 = { "cartEntry" : orderedDish, "notOrdered" : ! orderedDish.`isOrdered`, "canceled" : orderedDish.`canceled`, "wrong" : (((orderedDish.`_from` == "Client/62952180") && (orderedDish.`cart` == "cartA")) && (! orderedDish.`isOrdered` || orderedDish.`isCanceled`)) }   /* simple expression */   /* collections used: orderedDish : OrderedDish */
  6   ReturnNode           2       - RETURN #3

Looking at line 4 4   FilterNode           2       - FILTER #1  you can see that the filter statement is reduced in a wrong way.

a quick fix is:
FOR orderedDish IN OrderedDish
LET a = orderedDish._from == @target
LET b = orderedDish.cart == @cart
LET c = (!orderedDish.isOrdered || orderedDish.isCanceled)
LET d = a&&b&&c
FILTER
  a&&b&&c
RETURN {
  cartEntry: orderedDish,
  notOrdered: !orderedDish.isOrdered,
  canceled: orderedDish.canceled,
  wrong: orderedDish._from == @target && orderedDish.cart == @cart && (!orderedDish.isOrdered || orderedDish.isCanceled)
}

it does not work without LET d = a&&b&&c.

Fixed by https://github.com/arangodb/arangodb/pull/7554

why is 3.4.0-RC.5 released an this issue is not part of it? Or should it be closed?

@konsultaner : what exactly do you mean when you say "this issue is not part of it"?
Do you mean the bugfix is not included in it? Do you have any evidence supporting this claim, i.e. did you try the query with 3.4.0-rc5 and checked the issue is still there? I am asking because I think the fix is included in 3.4.0-rc5.

Please get RC.5 if you haven't, make sure you access the right instance (e.g. in the web interface check the bottom left corner for the server version) and retry the query.
The team will go through all issues with milestone 3.4.0-RC.5 and close them in the next few days now that RC.5 is out. We label issues as 2 Fixed As soon as a fix is in place in the code, but we leave issues open until new binaries become available.

Hi @konsultaner,
did you already have a chance to try 3.4.0-RC.5?

@maxkernbach sorry for not replying. yes, it did work. Thank you!


[SPARK-9454] Change LDASuite tests to use vector comparisons

@jkbradley Changes the current hacky string-comparison for vector compares.

Merged build triggered.

Merged build started.

Test build #38978 has started for   PR 7775 at commit 2f24c13.

Test build #38978 has finished for   PR 7775 at commit 2f24c13.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Looks fine, but as long as you're at it, how about fixing this test as well?
"running and DistributedLDAModel with default Optimizer (EM)"
for roundedTopicSummary, roundedLocalTopicSummary

Merged build triggered.

Merged build started.

Fixed; string conversion is still used to ensure ordering but the actual numeric compares after zipping are vector compares

Test build #39079 has started for   PR 7775 at commit bd91a82.

Test build #39079 has finished for   PR 7775 at commit bd91a82.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

LGTM, merging with master


Patch 1

Fountain is deprecating the www.onboardiq.com apis.  This PR switches the urls so the new api.fountain.com urls are used.

I wouldn't believe that just changing the API URLs will be enough. I would much rather deprecate this project and then form a new project as the company is now called Fountain and their API is already in v2.0.

I wouldn't believe that just changing the API URLs will be enough. I would much rather deprecate this project and then form a new project as the company is now called Fountain and their API is already in v2.0.


core/sdk/frontend: update lockfiles

this pr updates lockfiles and removes package-lock.json from packages/core

👍


improve data streaming

Which issue does this PR close?
Closes #.
Rationale for this change
What changes are included in this PR?
Are there any user-facing changes?

Current dependencies on/for this PR:

main

PR #191   👈

This comment was auto-generated by Graphite.

Codecov Report

Merging #191 (b0d0947) into main (14f73c9) will decrease coverage by 9.75%.
The diff coverage is 68.40%.

@@            Coverage Diff             @@
##             main     #191      +/-   ##
==========================================
- Coverage   39.82%   30.06%   -9.76%
==========================================
  Files          83       68      -15
  Lines        6670     4892    -1778
==========================================
- Hits         2656     1471    -1185
+ Misses       4014     3421     -593

Impacted Files
Coverage Δ

rust/area-store/src/error.rs
0.00% <0.00%> (ø)

rust/area-store/src/lib.rs
100.00% <ø> (ø)

rust/area-store/src/store/utils.rs
0.00% <ø> (-24.33%)
:arrow_down:

rust/file-cache/src/cache/lru.rs
72.22% <ø> (ø)

rust/flight-fusion/src/error.rs
0.00% <0.00%> (ø)

rust/flight-fusion/src/handlers/actions.rs
0.00% <0.00%> (ø)

rust/flight-fusion/src/service.rs
3.20% <0.00%> (-0.26%)
:arrow_down:

rust/fusion-planner/src/query_tree.rs
79.67% <40.00%> (-0.76%)
:arrow_down:

rust/area-store/src/store/mod.rs
58.13% <44.44%> (+11.98%)
:arrow_up:

rust/area-store/src/store/stats.rs
54.27% <50.00%> (ø)

... and 21 more

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Rename of

In the past the of method was nice to read and self-explanatory:
Observable.of(1, 2, 3)

But without Observable in front of of there is hardly any meaning in of. The code was reduced to meaninglessness.
of(1, 2, 3)  // What "1, 2, 3"? Doesn't make sense!

I suggest to either reintroduce Observable.of(...) or to rename it to something like createObservable. However I would prefer the former because it is a bit more concise and you can always start with Observable. and can see what methods are available in your IDE.
Other frameworks like Reactor are following the suggested path with Flux.just(1, 2, 3) (where Flux is an Observable).

This discussion has already been had: https://github.com/ReactiveX/rxjs/issues/3747

@cartant I'm aware of this issue, but it had another goal (rename of to just). It wasn't not about the missing context Observable. in front of of provided. And if you read the comments, you'll see that I'm not the only one finding of without context meaningless.
Imagine more frameworks would follow this route and you would have your code full of of's, and froms and the like without any context. That would be almost impossible to read.

Am I missing something or would we end up in a similar situation with your 'just' renaming?
A project full of justs without context.
Please let me know your thoughts.

just without context (namely Observable) wouldn't be any better than of. Since there are seemingly technical reasons (I guess tree-shaking) for not using Observerble.of anymore, I suggest to go with:
observerbleOf(1, 2, 3)

Closing as a dupe of https://github.com/ReactiveX/rxjs/issues/3747


TabBar with Drawer button

Hi all,
Is it possible to achieve the following setup:

I need one of the tabbar tabs to be a button, which triggers the drawer menu to open. Here is my code:
`
  <Scene key="tabbar"  initial>
    <scene tabs={true} key="main" initial >
      <Scene title="Tab #1" iconName="home" key="scene1" initial component={scene1} icon={TabIcon}  />
      <Scene title="Tab #2" iconName="arrow" key="scene2" component={scene2}  icon={TabIcon}/>
      <Scene title="Tab #3" iconName="inbox" key="scene3" component={scene3} icon={TabIcon}  />
      <Scene title="Tab #4" iconName="account" key="scene4" component={scene4} icon={TabIcon}  />
      <Scene title="drawerMenu" iconName="menu" key="sidebar" icon={TabIcon}  />

    </scene>
  </Scene>
</RouterRedux>`

Realized I posted in react-native-side-menu instead of react-native-router-flux. I need a coffee.


WIP: Prepare for Masonite4

Upgrade to Masonite 4
Partial rewrite to use Middleware as in Laravel adapter
Add testing assertions
Add good testing coverage
Add local demo in package
Fixes #10, Fixes #1, Fixes #6

Codecov Report

Merging #47 (633e47f) into master (78d98e6) will increase coverage by 49.86%.
The diff coverage is 85.22%.

@@             Coverage Diff             @@
##           master      #47       +/-   ##
===========================================
+ Coverage   28.93%   78.79%   +49.86%
===========================================
  Files           6       11        +5
  Lines         197      349      +152
===========================================
+ Hits           57      275      +218
+ Misses        140       74       -66

Impacted Files
Coverage Δ

src/masonite/inertia/commands/DemoCommand.py
27.90% <ø> (+27.90%)
:arrow_up:

src/masonite/inertia/commands/InstallCommand.py
85.71% <75.00%> (+4.46%)
:arrow_up:

...c/masonite/inertia/middleware/InertiaMiddleware.py
79.66% <79.31%> (+40.77%)
:arrow_up:

src/masonite/inertia/core/Inertia.py
81.08% <81.08%> (ø)

src/masonite/inertia/core/InertiaResponse.py
91.66% <90.47%> (+68.19%)
:arrow_up:

...masonite/inertia/testing/InertiaTestingResponse.py
90.90% <90.90%> (ø)

src/masonite/inertia/__init__.py
100.00% <100.00%> (ø)

src/masonite/inertia/core/Lazy.py
100.00% <100.00%> (ø)

src/masonite/inertia/helpers.py
100.00% <100.00%> (ø)

src/masonite/inertia/providers/InertiaProvider.py
100.00% <100.00%> (+31.25%)
:arrow_up:

... and 7 more

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 78d98e6...633e47f. Read the comment docs.


MLKNilLocalModel on iOS

Objective:
Image labelling using custom model done in real-time. Should run on Android & iOS.
Steps done so far:
Used code here: https://github.com/bharat-biradar/Google-Ml-Kit-plugin/blob/master/example/lib/VisionDetectorViews/label_detector_view.dart
With the stated adaptations for using a custom model (e.g. uncommenting processImageWithCustomModel).
As I am building for iOS, the path of the model is assets/ml/model.tflite and not in the android assets as mentions in a comment on the above link.
I experimented with both CustomTrainedModel.asset and CustomTrainedModel.file with no luck.
Please let me know how to solve the below.
Result
When building on iOS, I get the following:
The selected imageFormatGroup is not supported by iOS. Defaulting to brga8888
*** Terminating app due to uncaught exception 'MLKNilLocalModel', reason: 'Local model must not be nil.'
*** First throw call stack:
(0x18135a754 0x195e217a8 0x18124f7e0 0x103655154 0x106199d94 0x10619945c 0x106199190 0x106198f6c 0x108d92d60 0x108aa407c 0x108dad370 0x108d474d4 0x108d49cfc 0x1812d522c 0x1812d4e28 0x1812d4278 0x1812ce02c 0x1812cd360 0x19890b734 0x183d48584 0x183d4ddf4 0x10257275c 0x180f89cf8)
libc++abi: terminating with uncaught exception of type NSException
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00000001af471334 libsystem_kernel.dylib`__pthread_kill + 8
libsystem_kernel.dylib`__pthread_kill:
->  0x1af471334 <+8>:  b.lo   0x1af471354               ; <+40>
    0x1af471338 <+12>: pacibsp
    0x1af47133c <+16>: stp    x29, x30, [sp, #-0x10]!
    0x1af471340 <+20>: mov    x29, sp
Target 0: (Runner) stopped.

@azharj96 Did you take the first step mentioned here  while copying the model.

@azharj96 On taking a second look, I noticed that the problem was on the native side of the code. We'll fix it shortly and get back to you.

@azharj96 : we just merged this PR https://github.com/bharat-biradar/Google-Ml-Kit-plugin/pull/57 . I think this fixes this issue. Could you double check and if yes then let's close this issue.

@fbernaly when attempting to build for ios, I get the following error: Receiver 'MLKLocalModel' for class message is a forward declaration
Full output:
Xcode build done.                                            5.1s
Failed to build iOS app
Error output from Xcode build:
↳
    2021-06-10 11:54:49.636 xcodebuild[4517:35503]  DVTAssertions: Warning in /Library/Caches/com.apple.xbs/Sources/DVTiOSFrameworks/DVTiOSFrameworks-17705/DTDeviceKitBase/DTDKRemoteDeviceData.m:371
    Details:  (null) deviceType from 00008030-0014142826E2802E was NULL when -platform called.
    Object:   <DTDKMobileDeviceToken: 0x7fe406af1b90>
    Method:   -platform
    Thread:   <NSThread: 0x7fe40171c990>{number = 3, name = (null)}
    Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
    2021-06-10 11:54:49.876 xcodebuild[4517:35508]  DVTAssertions: Warning in /Library/Caches/com.apple.xbs/Sources/DVTiOSFrameworks/DVTiOSFrameworks-17705/DTDeviceKitBase/DTDKRemoteDeviceData.m:371
    Details:  (null) deviceType from 00008030-0014142826E2802E was NULL when -platform called.
    Object:   <DTDKMobileDeviceToken: 0x7fe406af1b90>
    Method:   -platform
    Thread:   <NSThread: 0x7fe40212b5b0>{number = 7, name = (null)}
    Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
    ** BUILD FAILED **

Xcode's output:
↳
    /Users/azharjamal/.pub-cache/git/Google-Ml-Kit-plugin-8050b0e251e647c241a85f9be9c60e56c3810cbd/ios/Classes/vision/ImageLabeler.m:83:35: error: receiver 'MLKLocalModel' for class message is a forward declaration
        MLKLocalModel *localModel = [[MLKLocalModel alloc] initWithPath: path];
                                      ^~~~~~~~~~~~~
    In module 'MLKitImageLabelingCustom' imported from /Users/azharjamal/.pub-cache/git/Google-Ml-Kit-plugin-8050b0e251e647c241a85f9be9c60e56c3810cbd/ios/Classes/vision/ImageLabeler.m:4:
    /Users/azharjamal/FlutterProjects/vizor/ios/Pods/MLKitImageLabelingCustom/Frameworks/MLKitImageLabelingCustom.framework/Headers/MLKCustomImageLabelerOptions.h:7:8: note: forward declaration of class here
    @class MLKLocalModel;
           ^
    /Users/azharjamal/.pub-cache/git/Google-Ml-Kit-plugin-8050b0e251e647c241a85f9be9c60e56c3810cbd/ios/Classes/vision/ImageLabeler.m:83:34: error: receiver type 'MLKLocalModel' for instance message is a forward declaration
        MLKLocalModel *localModel = [[MLKLocalModel alloc] initWithPath: path];
                                     ^~~~~~~~~~~~~~~~~~~~~
    In module 'MLKitImageLabelingCustom' imported from /Users/azharjamal/.pub-cache/git/Google-Ml-Kit-plugin-8050b0e251e647c241a85f9be9c60e56c3810cbd/ios/Classes/vision/ImageLabeler.m:4:
    /Users/azharjamal/FlutterProjects/vizor/ios/Pods/MLKitImageLabelingCustom/Frameworks/MLKitImageLabelingCustom.framework/Headers/MLKCustomImageLabelerOptions.h:7:8: note: forward declaration of class here
    @class MLKLocalModel;
           ^
    /Users/azharjamal/.pub-cache/git/Google-Ml-Kit-plugin-8050b0e251e647c241a85f9be9c60e56c3810cbd/ios/Classes/vision/ImageLabeler.m:79:15: warning: unused variable 'modelType' [-Wunused-variable]
        NSString *modelType = optionsData[@"customModel"];
                  ^
    1 warning and 2 errors generated.
    note: Using new build system
    note: Building targets in parallel
    note: Planning build
    note: Constructing build description

Encountered error while building for device.

@fbernaly when attempting to build for ios, I get the following error: Receiver 'MLKLocalModel' for class message is a forward declaration
Full output:
Xcode build done.                                            5.1s
Failed to build iOS app
Error output from Xcode build:
↳
    2021-06-10 11:54:49.636 xcodebuild[4517:35503]  DVTAssertions: Warning in /Library/Caches/com.apple.xbs/Sources/DVTiOSFrameworks/DVTiOSFrameworks-17705/DTDeviceKitBase/DTDKRemoteDeviceData.m:371
    Details:  (null) deviceType from 00008030-0014142826E2802E was NULL when -platform called.
    Object:   <DTDKMobileDeviceToken: 0x7fe406af1b90>
    Method:   -platform
    Thread:   <NSThread: 0x7fe40171c990>{number = 3, name = (null)}
    Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
    2021-06-10 11:54:49.876 xcodebuild[4517:35508]  DVTAssertions: Warning in /Library/Caches/com.apple.xbs/Sources/DVTiOSFrameworks/DVTiOSFrameworks-17705/DTDeviceKitBase/DTDKRemoteDeviceData.m:371
    Details:  (null) deviceType from 00008030-0014142826E2802E was NULL when -platform called.
    Object:   <DTDKMobileDeviceToken: 0x7fe406af1b90>
    Method:   -platform
    Thread:   <NSThread: 0x7fe40212b5b0>{number = 7, name = (null)}
    Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
    ** BUILD FAILED **

Xcode's output:
↳
    /Users/azharjamal/.pub-cache/git/Google-Ml-Kit-plugin-8050b0e251e647c241a85f9be9c60e56c3810cbd/ios/Classes/vision/ImageLabeler.m:83:35: error: receiver 'MLKLocalModel' for class message is a forward declaration
        MLKLocalModel *localModel = [[MLKLocalModel alloc] initWithPath: path];
                                      ^~~~~~~~~~~~~
    In module 'MLKitImageLabelingCustom' imported from /Users/azharjamal/.pub-cache/git/Google-Ml-Kit-plugin-8050b0e251e647c241a85f9be9c60e56c3810cbd/ios/Classes/vision/ImageLabeler.m:4:
    /Users/azharjamal/FlutterProjects/vizor/ios/Pods/MLKitImageLabelingCustom/Frameworks/MLKitImageLabelingCustom.framework/Headers/MLKCustomImageLabelerOptions.h:7:8: note: forward declaration of class here
    @class MLKLocalModel;
           ^
    /Users/azharjamal/.pub-cache/git/Google-Ml-Kit-plugin-8050b0e251e647c241a85f9be9c60e56c3810cbd/ios/Classes/vision/ImageLabeler.m:83:34: error: receiver type 'MLKLocalModel' for instance message is a forward declaration
        MLKLocalModel *localModel = [[MLKLocalModel alloc] initWithPath: path];
                                     ^~~~~~~~~~~~~~~~~~~~~
    In module 'MLKitImageLabelingCustom' imported from /Users/azharjamal/.pub-cache/git/Google-Ml-Kit-plugin-8050b0e251e647c241a85f9be9c60e56c3810cbd/ios/Classes/vision/ImageLabeler.m:4:
    /Users/azharjamal/FlutterProjects/vizor/ios/Pods/MLKitImageLabelingCustom/Frameworks/MLKitImageLabelingCustom.framework/Headers/MLKCustomImageLabelerOptions.h:7:8: note: forward declaration of class here
    @class MLKLocalModel;
           ^
    /Users/azharjamal/.pub-cache/git/Google-Ml-Kit-plugin-8050b0e251e647c241a85f9be9c60e56c3810cbd/ios/Classes/vision/ImageLabeler.m:79:15: warning: unused variable 'modelType' [-Wunused-variable]
        NSString *modelType = optionsData[@"customModel"];
                  ^
    1 warning and 2 errors generated.
    note: Using new build system
    note: Building targets in parallel
    note: Planning build
    note: Constructing build description

Encountered error while building for device.

I can confirm I am getting the same issue.

it was missing an #import . Here is the PR: https://github.com/bharat-biradar/Google-Ml-Kit-plugin/pull/63


Server is down

Hi,
The web server http://<IP_ADDRESS>:8080/ appears to be down.

It is broken again  :(

Huh, http://gluon-lang.org/try/ works though (trailing /)

Well, maybe you can put a redirect from [http://gluon-lang.org/try](http://gluon-lang.org/try/] to http://gluon-lang.org/try/  and it will fix the issue maybe?

Looking into it, must have messed up routing somehow :)


[ci] Remove e2e workflow paths-ignore attribute

It will cause our CI always waitting due to
we requests E2E contexts in .asf.yaml but
we set some ignore path on workflow e2e.
ref: https://github.com/apache/dolphinscheduler/pull/7695

FYI, https://github.com/apache/dolphinscheduler/blob/120c1755a15fcf78df303a67edfa87db0a7ff495/.asf.yaml#L47 we request every PR need E2E context, but we have ignore path in https://github.com/apache/dolphinscheduler/blob/120c1755a15fcf78df303a67edfa87db0a7ff495/.github/workflows/e2e.yml#L19-L28. Releted PR #7612

Codecov Report

Merging #7807 (82003ef) into dev (120c175) will decrease coverage by 0.33%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev    #7807      +/-   ##
============================================
- Coverage     41.18%   40.84%   -0.34%
  Complexity     3669     3669
============================================
  Files           641      637       -4
  Lines         26525    26783     +258
  Branches       2964     3017      +53
============================================
+ Hits          10924    10940      +16
- Misses        14575    14792     +217
- Partials       1026     1051      +25

Impacted Files
Coverage Δ

...he/dolphinscheduler/common/enums/SqoopJobType.java
0.00% <0.00%> (-88.89%)
:arrow_down:

...inscheduler/server/log/LoggerRequestProcessor.java
20.31% <0.00%> (-39.07%)
:arrow_down:

...e/dolphinscheduler/api/aspect/AccessLogAspect.java
67.24% <0.00%> (-13.72%)
:arrow_down:

...er/api/service/impl/TaskDefinitionServiceImpl.java
26.13% <0.00%> (-5.70%)
:arrow_down:

...heduler/api/service/impl/TaskGroupServiceImpl.java
60.17% <0.00%> (-3.83%)
:arrow_down:

...inscheduler/common/task/sqoop/SqoopParameters.java
74.00% <0.00%> (-2.00%)
:arrow_down:

...inscheduler/server/master/config/MasterConfig.java
69.56% <0.00%> (-0.44%)
:arrow_down:

...r/plugin/registry/zookeeper/ZookeeperRegistry.java
48.21% <0.00%> (-0.44%)
:arrow_down:

...api/service/impl/ProcessDefinitionServiceImpl.java
25.70% <0.00%> (-0.34%)
:arrow_down:

...r/server/worker/registry/WorkerRegistryClient.java
3.44% <0.00%> (-0.33%)
:arrow_down:

... and 36 more

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 120c175...82003ef. Read the comment docs.


[dev] bot not spinning forts (or walking to them)

Expected Behavior
Bot walks to forts and spins.
e.g.
[05:23:52] Moving towards fort 41fa8df35089444994e59fcadcd3d080.16, 0.04km left
[05:24:42] Moving towards fort 41fa8df35089444994e59fcadcd3d080.16, 0.04km left
[05:25:32] Moving towards fort 41fa8df35089444994e59fcadcd3d080.16, 0.03km left
[05:26:22] Moving towards fort 41fa8df35089444994e59fcadcd3d080.16, 0.03km left
Actual Behavior
[14:17:47] Scanning area for objects....
[14:17:47] Walking from (52.359787337596416, -1.1691276628263332) to [52.359787337596416, -1.1691276628263332] 0.00km
[14:17:48] Server seems to be busy or offline - try again - 1/5
[14:17:49] Scanning area for objects....
[14:17:49] Walking from (52.359787337596416, -1.1691276628263332) to [52.36158733759642, -1.1691276628263332] 0.20km
[14:19:41] Scanning area for objects....
[14:19:41] Walking from (52.36158733759642, -1.1691276628263332) to [52.36158733759642, -1.1673276628263332] 0.12km
[14:19:42] Server seems to be busy or offline - try again - 1/5
Steps to Reproduce
Every time I run the bot, it eventually ran out of pokeballs because it isn't spinning for items.
Tried changing settings for catching pokemon to false but this does not affect whether the bot looks for forts.
Other Information
OS: Windows 10
Git Commit: 6c6fc59de9ea02a2079cb7548f80937f65894088

Had the same issue. Try to remove last-location and cells file in PokemonGo-Bot/data/ folder and restart bot.
Additionally, try to pull new dev version.

^This worked perfectly

not work for me :(

check that your bag isn't full, its the same as disabling forts

@asnelzin fix didn't work for me either. Bag isn't full and bot was working fine earlier on the same commit.

bag full was my problem, i had 396/400, you need at least 5 open spots


Failed to load system plugin [gz_ros2_control-system]

Hi,
I have the following error when launching  ros2 launch gz_ros2_control_demos diff_drive_example.launch.py :
[ign gazebo-1] Library [/colcon_ws/install/gz_ros2_control/lib/libgz_ros2_control-system.so] does not export any plugins. The symbol [IgnitionPluginHook] is missing, or it is not externally visible.
[ign gazebo-1] [Err] [SystemLoader.cc:87] Failed to load system plugin [gz_ros2_control-system] : couldn't load library on path [/colcon_ws/install/gz_ros2_control/lib/libgz_ros2_control-system.so].
OS Version: WSL with Ubuntu 22.4
Using Docker image : Ubuntu 22.04 + ROS2 Humble + Gazebo Garden (installed from debs)
Behavior :
Gazebo (ex Ignition) launches successfully but with that error message. As such, many controllers and topics are missing and I can't control the robot.
I am also suprised that in the roslaunch console, the node is still called "ign gazebo".

Steps to reproduce :

Clone the repo https://github.com/ros-controls/gz_ros2_control.git and checkout to branch ign_to_gz
colcon build in a ROS2 workspace

I've tried to change different plugin_names and file_names in the  urdf but without success. Any idea ? I see that the branch ign_to_gz has been updated a few hours ago but with the same behavior.
Thanks !
I attach the Dockerfile for reproduction
Dockerfile.humble-full-gz.txt

Please check these two answer https://github.com/ros-controls/gz_ros2_control/pull/67#issuecomment-1322727849 and https://github.com/ros-controls/gz_ros2_control/pull/67#issuecomment-1322727849
For following issues or PR, please don't use images, these are not searchable.
If this solve your problem please close this issue.

Ok, I've rebuilt my humble image and recompiled ros_gz on the humble branch and it now works.
Thanks !


expose walker as public property of Designer

Closes #109

Hello @goldsam! Thanks for this PR. I implemented this in a bit different way, the Designer class exposes the definition walker by using a method, not a property like in your commit. This gives us more flexibility in terms of versioning.


Changed AndroidManifest path for permissions

Flutter generated two AndroidManifest for permissions.
android/app/src/main -> android/app/src/profile

But without permissions, we can retrieve the location 🤔
It's the example on this repository.

@ykws the idea is that the values in the android/app/src/main/AndroidManifest.xml are propagated to the android/app/src/profile/AndroidManifest.xml and android/app/src/debug/AndroidManifest.xml files.
The android/app/src/profile (or android/app/src/debug for that matter) are only used when you execute the App in either Profile or Debug mode. These AndroidManifest.xml files allow you to set settings specific for running in Debug or Profiling mode but you don't want in Release mode (e.g. special logging configuration).
So we on purpose added the permissions to the android/app/src/main version of the AndroidManifest.xml file just to make sure they always end-up in each configuration (Debug, Profile and Release).
There is a known issue which causes settings not being propagated correctly when changes are made to the AndroidManifest.xml file after it has been run on the emulator or real phone. To solve this you should"

Remove the App from the target device (emulator or real phone);
Run flutter clean;
Rerun the app from the IDE.

This should solve all problems and propagate all settings from the android/app/src/main/AndroidManifest.xml file to the profile and debug versions of the same file.
I am closing this issue and the associated PR since this is working as intended. More information can be found here: https://developer.android.com/studio/build/index.html#sourcesets

@mvanbeusekom I got it and appreciate the detail information.


Status of this plugin

Hello
I see that this plugin is not in the official web page demo anymore
Also I tried to use it and had a strange "default is readonly" error
Is this plugin still maintained? Should I insist on debuging my project?
if someone sees this question, thank you for your answer :)

I'd say as lory is not maintained anymore (last commit in  Jan 2019) probably it doesn't make sense to maintain this plugin either (at least from my opinion)

Ok thank you, I'll probably not invest too much time in it then
Maybe for silex i can create a slideshow with https://splidejs.com/
Thank you @artf !


casefix alter job case

should allow task failed, because the previous insert overwrite may not have been canceled

run buildall


RTL support

Pass of RTL fixes as according to #93

@wahidfarid perhaps we could close this PR, since we are now working on TK 3


Use the DocString.Content for ToString

This makes it far easier to debug/visualize or even consume by just doing step.Argument.ToString().

We could add this, but it will become obsolete with #416.

Not familiar with what that other PR entails. Is the entire API changing?

Yes, the API is changing. See:

https://github.com/cucumber/cucumber/issues/425
Roadmap Draft

I'm closing this, as it's updating code that is likely to go away soon.


Refactor release table.

Description
Drawing from the discussion at #352, this patch tries to clarify a couple
confusing things about our release table:

Releases that had a release date after their "Supported Until"
didn't make any sense. Now they have the context of a distinction
between a branch and a release, and when the first release on
on the branch came out (which will always be before "End of
Support").

I tried to formalize language around "branch" vs "release".
Previously we used release to mean both an individual tagged
release, and the line of development it was associated with.
This was confusing as 7.0 will be "a LTS Release" but 7.0.9 is
not "a LTS release" because it is pre-LTS-ification of 7.0.
Honestly, this is still pretty confusing (7.0 probably should have
been LTS all along), but at least the branch metaphor aligns with
what is happening behind the scenes.

Type of change

Internal change (not necessarily a bug fix or a new feature)
This change has a user-facing impact

Linked tickets and other PRs
Contributes to #352.
TODOs

[x] Self-review the change
[x] Perform manual testing
[ ] Address review feedback

Testing done
make run-docs and captured the following screenshot:

I'm not sure I see reframing releases in the terms of branches makes this any clearer. It seems like we're just throwing more information out there.

Releases that had a release date after their "Supported Until"
didn't make any sense. Now they have the context of a distinction
between a branch and a release, and when the first release on
on the branch came out (which will always be before "End of
Support").

While I'm sure it does come up from time to time, I don't believe it's necessarily that uncommon for companies to release patches ontop of unsupported software by customer request. We sort of say that in the comments, but I do see the knee jerk question of why is there a release if it's unsupported. I'm not sure how much true confusion this really causes though. To me, showing three dates, with an original release, doesn't really change the fact that there was a patch after the official end of support.

I tried to formalize language around "branch" vs "release".
Previously we used release to mean both an individual tagged
release, and the line of development it was associated with.
This was confusing as 7.0 will be "a LTS Release" but 7.0.9 is
not "a LTS release" because it is pre-LTS-ification of 7.0.
Honestly, this is still pretty confusing (7.0 probably should have
been LTS all along), but at least the branch metaphor aligns with
what is happening behind the scenes.

I think you're right, that we should have designated 7.0 LTS from the beginning, or when we do designate the LTS release mark it 7.1. But I don't think it's really correct to say that 7.0.9 is not an LTS release if we "promote" the branch to be our LTS release. There isn't an outward facing difference between 7.0.9 LTS and 7.0.9 Non-LTS. Basically from an outside perspective, all we've done is change/extend the supported until date for a major version. While we may do an extended set of tests before we extend the supported date, or contractually do something like run conformance testing, it doesn't mean from an outside perspective there is a substantial difference in the releases, other than when they exit support.

@knisbet  TLDR: You bring up good clarifying points.  Is there anything you would like to see changed in the .md?

I'm not sure I see reframing releases in the terms of branches makes this any clearer.

I stand pretty firmly behind the "branch" vs "release" vocabulary shift. This my attempt to clarify that a branch/line of development is what we provide support for, not any particular build off that release E.g. we won't backport a security fix to each 7.0.x release, only the 7.0 branchline of development as a whole.  Before this patch, we didn't have vocabulary in our documentation for distinguishing between the two -- everything was a release.

While I'm sure it does come up from time to time, I don't believe it's necessarily that uncommon for companies to release patches on top of unsupported software by customer request. We sort of say that in the comments, but I do see the knee jerk question of why is there a release if it's unsupported. I'm not sure how much true confusion this really causes though. To me, showing three dates, with an original release, doesn't really change the fact that there was a patch after the official end of support.

That's fair.  I agree for the extra date column is mostly superfluous info.  If they hurt the scan-ability of the table I'd be glad to remove them.  They have parity with Sasha's suggestion in https://github.com/gravitational/gravity/issues/352 -- and because I agreed with his suggestion due quirks like post-support releases.

I think you're right, that we should have designated 7.0 LTS from the beginning, or when we do designate the LTS release mark it 7.1. But I don't think it's really correct to say that 7.0.9 is not an LTS release if we "promote" the branch to be our LTS release. There isn't an outward facing difference between 7.0.9 LTS and 7.0.9 Non-LTS. Basically from an outside perspective, all we've done is change/extend the supported until date for a major version. While we may do an extended set of tests before we extend the supported date, or contractually do something like run conformance testing, it doesn't mean from an outside perspective there is a substantial difference in the releases, other than when they exit support.

Understood -- I believe the docs reflect this, and any confusion is limited to the discussion in this PR. Perhaps a better example than 7.0 would be what @klizhentas discussed in https://github.com/gravitational/gravity/issues/352#issue-426209051

Every major Gravity version x.0.0 has it's long term support release, e.g. for 3.0.0 version
LTS starts with 3.51.0 with minor backwards compatible changes added over time until the end of support cycle.

"[S]tarts with 3.51.x" connotes 3.x  releases < 3.51.x are not LTS, which is moot (3.x is dead), but also confusing. The current 7.0 situation has echos of 3.x, and I'm not the only one who is confused -- this is the discussion that prompted me to write this patch.

@knisbet TLDR: You bring up good clarifying points. Is there anything you would like to see changed in the .md?

Yes, we need to align on our messaging, otherwise we'll just go back and fourth.

I stand pretty firmly behind the "branch" vs "release" vocabulary shift. This my attempt to clarify that a branch/line of development is what we provide support for, not any particular build off that release E.g. we won't backport a security fix to each 7.0.x release, only the 7.0 branch / line of development as a whole. Before this patch, we didn't have vocabulary in our documentation for distinguishing between the two -- everything was a release.

I don't think using "Branch" as the nomenclature for a Major.Minor version is the best fit. It seems to uplift the VCS terminology for how the code is organized, not reflect an outward facing version policy. So it makes lots of sense to us, because we live it in source code every day, but an outside observer shouldn't be expected to know this.
What we have traditionally indicated, is an outward version policy of SemVer, which operates in terms of Major, Minor, and Patches, where Major.Minor make up a supported version, some of which will have LTS patch cycles.
Polling some well known software to try and see how they communicate similar information, seems to be fairly varied:
Ubuntu: https://wiki.ubuntu.com/Releases
RedHat: https://access.redhat.com/articles/3078
Openshift: https://docs.openshift.com/container-platform/4.2/release_notes/versioning-policy.html
Kubernetes: https://kubernetes.io/docs/setup/release/version-skew-policy/ (Does use release branches)
Oracle: https://en.wikipedia.org/wiki/Oracle_Database#Releases_and_versions
InfluxData: https://docs.influxdata.com/influxdb/v1.8/about_the_project/releasenotes-changelog/ (I don't see a table at cursory glance)
Docker EE: https://docs.mirantis.com/docker-enterprise/v3.0/dockeree-products/docker-ee/release-notes.html (Appears to use version)
Linux Kernel: https://www.kernel.org/category/releases.html
Rancher: https://rancher.com/docs/rancher/v2.x/en/installation/options/server-tags/
Tanzu: https://docs.pivotal.io/pks/1-6/release-notes.html
Overall, I don't think there is any generally accepted terminology here. What I see most often doing a quick survey, is to refer to the Major.Minor as a Version. So if anything, I would consider going the other direction, and from a release cycle perspective, only present the following information:
Version: Major.Minor
LTS: Yes/No
Release Date: Date of the .0 Patch release
Supported Until: 3 years or 4 months above Release Date based on LTS designation. Or preferably we'd get to a point where we separate End of Support versus End of Security, but we don't currently distinguish that when we should as Ubuntu does.
Patches can then be individually dated as they already are, sticking with SemVer nomenclature. When we say LTS release, from a SemVer standpoint, we're talking about the Major.Minor combination.
Example

Version
LTS
Release Date
Supported Until

7.0
Yes
January 1st, 2020
January 1st, 2023

6.3
No
March 3rd, 2019
June 3rd, 1029

6.1
Yes
August 2nd, 2019
November 10th, 2021

This doesn't address how we communicate Kubernetes/Teleport and dependency versions, although there was already a side discussion around this, because we don't communicate other dependencies (etcd as an example). For the short term I'd continue to include Kubernetes/Teleport in this table, but long term a wider variety of dependencies will be communicated in some other type of table, maybe something like Tanzu does.

@knisbet I drafted some changes incorporating your feedback here: https://github.com/gravitational/gravity/pull/1751
We can continue the conversation there.