[WIP] Supports url encode/decode function

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

cc: @cloud-fan , I'm not sure why we don't support url encode\decode function as built-in function, but if we intentionally don't, i will close this title.

@Yikf Please run SPARK_GENERATE_GOLDEN_FILES=1 build/sbt "sql/testOnly *ExpressionsSchemaSuite" to regenerating the result file and update in this pr.

@Yikf Please run SPARK_GENERATE_GOLDEN_FILES=1 build/sbt "sql/testOnly *ExpressionsSchemaSuite" to regenerating the result file and update in this pr.
i
thanks~ i will address those comment if this pr is necessary

@Yikf Please run SPARK_GENERATE_GOLDEN_FILES=1 build/sbt "sql/testOnly *ExpressionsSchemaSuite" to regenerating the result file and update in this pr.

i will address those comment if this pr is necessary

does other databases provide these functions?

Both Trino & Presto have URL-related URL functions, including url_decode/url_encode, reference doc: https://trino.io/docs/current/functions/url.html, However, i don't found similar function with url_encode/url_decode in Hive, Mysql, Oracle, etc., maybe we have to use reflect function instead in hive, It's a bit of a hassle, And often these functions are useful.

do other databases provide these functions?

Both Trino & Presto have URL-related URL functions, including url_decode/url_encode, reference doc: https://trino.io/docs/current/functions/url.html, However, i don't found similar function with url_encode/url_decode in Hive, Mysql, Oracle, etc., maybe we have to use reflect function instead in hive, It's a bit of a hassle, And often these functions are useful.

Can one of the admins verify this patch?

@Yikf Could you update the pr description because I found this pr also includes some refactoring work

@Yikf Could you update the pr description because I found this pr also includes some refactoring work

done

@LuciferYang @cloud-fan Any other comments please?

friendly ping @cloud-fan

thanks, merging to master!

thank you all


Fixed tests and lint errors

Overview
I've fixed failing tests and some small eslint errors.
Next step - hook up CI.

Thanks @adamTrz !


Optionally use convex hull of mesh shapes

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

There are computational advantages to collision detection using convex meshes. It would be useful for users who carefully construct their own convex meshes to be able to declare that they are convex. Then the collision engine can make smarter choices.
@erwincoumans @hsu
See also issue about gazebo-bullet concave mesh support for commentary on the challenges of real-time decomposition of concave meshes to convex. Using a flag will be computationally faster.

I like the idea of using a flag to explicitly indicate that we want to decompose / or simplify the mesh.
One idea is to use a new attribute, simplify (open to suggestion), in <mesh>:
<collision name="my_collision">
  <geometry>
    <mesh simplify="convex">
      <uri>path_to_complex_mesh</uri>
    </mesh>
  </geometry>
</collision>

Ways to simplify a mesh:

convex - decomposes the mesh to one or multiple simple convex meshes. This can be done by the physics engine's if available (e.g. bullet's btConvexHullShape) or use other libraries for decomposition, e.g. https://github.com/kmammou/v-hacd
bounding_box - Most simple option - just use the object's bounding box as the collision.
simple_shapes - decomposes to a set of simple shapes (instead of simple convex meshes)

a //mesh/@optimization attribute has been added in https://github.com/gazebosim/sdformat/pull/1382


Code Coverage Doesn't Reflect Files Which Aren't Included

Seems like a know issue with the --all flag in, nyc our coverage provider. Currently the flag raises an error and stops all tests, but once their issue is fixed we should add it to the unit:coverage and unit:coveralls npm commands to have our PRs more accurately display our code coverage stats.

Should we also add that windows is not supported for the unit:coverage run?


SetBody - How to write multiple line in a class/function.

I don't know if it's issue or not. But I don't how to add multiple line my class function.
I have tried :
 ->setBody('$this->driver = $driver')  ->setBody('$this->driver2 = $driver2');
But it didn't work, it only takes the last one. Sure more would be great, but so far it a pretty system.

Of course it takes the input of the second call as it is a set method and neither add or append. To use new lines simply use standard php:
->setBody("// line one \n//line two");
at best you use template systems for method bodies as mentioned in the docs.

Yeah! But a add or append would be great if it was implemented. Because it will be difficult for indentation, to manage semicolon and lot of a hassle for a foreach.
I've checked the doc and couldn't quite get it how to add or append, probably because of my low English understanding. Could, please paste a similar code.
Here what I want to accomplish in class -> function:
public function name(){         $supervar = 'xyz';          if($supervar != ''){                die('nice indenttion');          } }

There you go:
<?php
$code = "$supervar = 'xyz';\nif($supervar != '') {\n\tdie('nice indenttion');\n}";
$method->setBody($code);

but as mentioned use a template system for method bodies.

Thanks. I will work on that.


ImportError: cannot import name 'core' from 'cupy.core'

I'm experiencing problems when installing the latest version of cupy on two of my arch linux boxes.
I cloned the code from the repository and added the fix for GCC8.2, as suggested in #2147.
When trying to install cupy  with pip install . cupy compiles without any error, but if I run python -c 'import cupy' I get the following error:
python
Python 3.7.3 (default, Mar 26 2019, 21:43:19)
[GCC 8.2.1 20181127] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cupy
Traceback (most recent call last):
  File "/home/christian/workspace/cupy/cupy/__init__.py", line 11, in <module>
    from cupy import core  # NOQA
  File "/home/christian/workspace/cupy/cupy/core/__init__.py", line 1, in <module>
    from cupy.core import core  # NOQA
ImportError: cannot import name 'core' from 'cupy.core' (/home/christian/workspace/cupy/cupy/core/__init__.py)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/christian/workspace/cupy/cupy/__init__.py", line 32, in <module>
    six.reraise(ImportError, ImportError(msg), exc_info[2])
  File "/home/christian/venvs/chainer/lib/python3.7/site-packages/six.py", line 692, in reraise
    raise value.with_traceback(tb)
  File "/home/christian/workspace/cupy/cupy/__init__.py", line 11, in <module>
    from cupy import core  # NOQA
  File "/home/christian/workspace/cupy/cupy/core/__init__.py", line 1, in <module>
    from cupy.core import core  # NOQA
ImportError: CuPy is not correctly installed.

If you are using wheel distribution (cupy-cudaXX), make sure that the version of CuPy you installed matches with the version of CUDA on your host.
Also, confirm that only one CuPy package is installed:
  $ pip freeze

If you are building CuPy from source, please check your environment, uninstall CuPy and reinstall it with:
  $ pip install cupy --no-cache-dir -vvvv

Check the Installation Guide for details:
  https://docs-cupy.chainer.org/en/latest/install.html

original error: cannot import name 'core' from 'cupy.core' (/home/christian/workspace/cupy/cupy/core/__init__.py)

I do not experience this problem, when installing the cupy wheel cupy-cuda101, which uses cupy 5.4.0
Interestingly, the error vanishes and everything works, once I run pip install -e .. Could it be that some files are not correctly copied when not performing the local install? Am I doing something wrong? Might there be any errors in my setup? I can reproduce this error on two independent machines. I'm happy to supply further information for this issue.
More Info for reference:

CuPy Conditions

CuPy Version          : 6.0.0rc1
CUDA Build Version    : 10010
CUDA Driver Version   : 10010
CUDA Runtime Version  : 10010
cuDNN Build Version   : 7500
cuDNN Version         : 7500
NCCL Build Version    : 2305
NCCL Runtime Version  : 2305
OS: Arch Linux
GCC Version: 8.2.1 20181127
nvidia driver version: 418.56
python version: 3.7.3

Code to reproduce

create a new and empty virtualenv (install cython with pip install Cython)
Clone repository (I used commit 01fafe2e5df028b4270b3717cd06e93ed9a99acf)
run pip install .
run python -c 'import cupy'

Error messages, stack traces, or logs
See description above.

Thanks for looking into this :smile:.

This is an expected behavior for Python Extension (i.e. non pure-python) modules (like CuPy and NumPy). You cannot import CuPy at the root directory of the source tree unless you use pip install -e.

Thank you for the clarification!
Could you provide a link to the relevant documentation? I must have missed it while looking for the cause of the problem.

@Bartzi You can import cupy on other directories. You cannot import cupy at the source directory because Python searches the source tree and fails to find compiled modules.
I'm not sure whether there is some documentation.

Omg, I'm not always the smartest :sweat_smile: thanks for the clarification! And sorry for bothering you with this...

i get it.
i run
pip install cupy-cuda12x

error:
import cupy
File "/data/search/bei/SD/stable-diffusion-webui/venv/lib/python3.10/site-packages/cupy/__init__.py", line 17, in
from cupy import _core # NOQA
File "/data/search/bei/SD/stable-diffusion-webui/venv/lib/python3.10/site-packages/cupy/_core/__init__.py", line 3, in
from cupy._core import core # NOQA
File "cupy/_core/core.pyx", line 1, in init cupy._core.core


.data("surveyor-gui-mount-point") gives 'undefined' (null)

therefore, it has to be compared with null not .length

At some point, I tried that, and still errored.  I think a combination of
checking on length>0 and != undefined might be best.  Will modify and push.
On Sat, Jun 20, 2015 at 5:09 AM, okliv<EMAIL_ADDRESS>wrote:

therefore, it has to be compared with null not .length
You can view, comment on, or merge this pull request online at:
https://github.com/kjayma/surveyor_gui/pull/51
Commit Summary

.data("surveyor-gui-mount-point") gives 'undefined' (null)

File Changes

M lib/assets/javascripts/surveyor_gui/surveyor_gui.js
https://github.com/kjayma/surveyor_gui/pull/51/files#diff-0 (4)

Patch Links:

https://github.com/kjayma/surveyor_gui/pull/51.patch
https://github.com/kjayma/surveyor_gui/pull/51.diff

—
Reply to this email directly or view it on GitHub
https://github.com/kjayma/surveyor_gui/pull/51.


Rename public API __elasticsearch__

From my view it not best code @acticle.__elasticsearch__.index_document.
I think make sense to rename __elasticsearch__ to something more readable.

+1

In my opinion the need to use the __elasticsearch__ proxy is quite limited -- most methods are exposed via the regular namespace.
The main motivation to use a name like that was to be 100% sure we don't interfere with any .elasticsearch (or .es or whatever else) method defined by the user in the model. I'd rather pay the price with a slight discomfort in the method name, than force users to change their namespace.
Moreover, if you'd prefer to call the method as elasticsearch, it's one line of code in your model:
alias elasticsearch __elasticsearch__

What do you think?

IMO since most of the other available methods on a Model---there over over 1000 when you tab-complete in a rails console---aren't namespaced, it makes sense to have the __elasticsearch__ clearly delimited to protect against conflicts and ambiguity (import and search are the main source of this).

@SergXIIIth @rosswilson Any news here?

@karmi well, I agree with you re alias elasticsearch __elasticsearch__. But still think if method is mention in documentation it should be named properly - http://www.rubydoc.info/gems/elasticsearch-model/#The___elasticsearch___Proxy.
What about Article.elastic_proxy.client = Elasticsearch::Client.new host: 'api.server.org'?

I like __elasticsearch__ :)

In my opinion the need to use the __elasticsearch__ proxy is quite limited -- most methods are exposed via the regular namespace.

If the above statement is true, then my motivation to get the proxy renamed to something "more ruby like" is lessened. I do like the propsal for elastic_proxy.

I like __elasticsearch__ since there's almost 0% probability of it clashing with something else (vs. e.g. simply elasticsearch). I don't like elastic_proxy, since that's just describes the technical implementation, not the "thing". For example, Article.elastic_proxy.client feels really, really weird to me.

Closing as this discussion is quite old.


Possible Bug with Generics

I was using Zed and noticed that the types in this struct aren't highlighted correctly. Looks like there's an ERROR for the field right after the generic:

I do not know if this is a problem with the grammar or Zed itself, so posting it here just in case.

pretty sure i fixed this in the latest version, zed needs to update tree-sitter-go.

Ok, thanks.


logs for buildkite (pipeline/step runs)

where does buildkite store it's logs for each pipeline/step that has run? (i.e pipeline name, step name, time step run)

I have noticed that agents do record when they run jobs:
2018-07-23 00:18:06 INFO   Assigned job xxx-xxx-xxx. Accepting...
2018-07-23 00:18:07 INFO   Starting job xxx-xxx-xxx
2018-07-23 00:18:09 INFO   [Process] Process is running with PID: 28
2018-07-23 00:18:28 INFO   Process with PID: 28 finished with Exit Status: 128
2018-07-23 00:18:29 INFO   Finished job xxx-xxx-xxx

Is it typical/default when setting up an agent to write these to a logfile (I expected /var/logs/buildkite-agent.log for example)
Is there more detail available (pipeline name, commit, script, user etc)

I don't want to write a log script if one already exists, but at this point I'm considering writing an agent hook that runs pre-command to extract this data.

Hi @akhoury-tyro, the agent outputs logging information like you posted to stdout. It's up to the process manager (upstart, initd, systemd, etc) to then write it to a log in the way that makes sense for the operating system. What operating system are you on and how did you install the agent?
In terms of the output of each job run, we don't log that to disk, but you can use tee to write it locally and then store it yourself. Check out https://buildkite.com/docs/builds/managing-log-output#storing-the-original-log.

Drop us an email at<EMAIL_ADDRESS>if we can assist further!

I went to the trouble to write a golang binary that enriches each build log line with structured data (mostly, the environment variables that buildkite sets), then pumps it into logstash, so it's available within our Elasticsearch/Kibana.
I've been able to use this to:

notify individuals and teams when there is a flaky test

quantify how flaky it is (over the timespan of data that I retain) - this can be used to derive an estimate for engineering hours wasted with retries and debugging, used to justify prioritising fixes where that's not an automatic "oh, yes; of course, we'll fix it since a flaky test is a random number generator" (which is much more normal, here!)
identify when it first flaked, with the commit/PR (if that's within the timespan of data that I retain), reducing the engineering hours spent localising the root cause

I hope to open-source this, it's not a large piece of work.

That sounds really neat @petemounce!


Feature request: overriding sql fragments in mapper inheritance paradigm.

Lets assume I have some abstraction called 'resource'. There may be a lot of different resources, they are stored in different SQL tables, but they have a lot of common columns/properties and share a lot of common operations (create, find etc.).
The only way to reuse now some SQLs is to do something like this.
interface ParentResource {

  List<Resource> find(...);

  Resource get(...);
}

interface ChildResource extends ParentResource {
}

<mapper namespace="ParentResource">
  <sql id="commonFind">
     select ....
        from ....
        ${tableName}
        ........
  </sql>

  <sql id="commonGet">
    select...
       from ...
       ${tableName}
       .....
  </sql>
</mapper>

<mapper namespace="ChildResource">
  <select id="find">
    <include ref-id="commonFind">
      <property name="tableName" value="child_resource"/>
    </include>
  </select>

  <select id="get">
    <include ref-id="commonGet">
      <property name="tableName" value="child_resource"/>
    </include>
  </select>
</mapper>

So <select id="find"> and  <select id="get">  must be repeated in every child mapper xml.
It would be good if sql fragments can be overridden in child mapper xml files and reused in a parent. Something like this.
<mapper namespace="ParentResource">
  <select id="find">
     select ....
        from ....
        <include ref-id="tableName"/>
        .......
  </select>

  <select id="get">
    select...
       from ...
       <include ref-id="tableName"/>
       .....
  </select>
</mapper>

<mapper namespace="ChildResource1">
  <sql id="tableName">child_resource2</sql>
</mapper>

<mapper namespace="ChildResource2">
  <sql id="tableName">child_resource2</sql>
</mapper>

What do you think? Does it sound reasonable? Or did I miss something and it can be achieved right now without any code changes?
Thanks in advance.

In your case, SQL provider seems to be a better fit.
See #1013 and @kazuki43zoo 's demo for the basic idea.


Skeleton of the Reference Application. PoC Activities

Under the dev branch we need to generate the Skeleton of the Reference Application. It shall be ready for unit tests, etc.

no longer applies


Regular scheduled checkpoints needed

There is a problem on the network that doesn't seem to have resolution. Bad nodes are influencing good nodes and making them go corrupt. As we all accept this as part of being a node operator its highly frustrating when the checkpoints are very old (over 2 weeks) and the event happened in the last 2 hours. Or what's even worse is when you are but a few hours from being fully synced and this sort of event happens on your new chain.
We've had to resort to node operators shutting down their nodes and making copies for us to be able to use. This is not a great idea due to a rogue node owner trying to pull off something horrible. But at this point we have but few options so we aren't spending days and days syncing.
Once a week, reliable, checkpoints would be good. Daily would be best. While I understand the technical issues in doing this a simple script to shutdown the node, wait for it to complete shutdown, copy the files needed out, start the node back up, and then zip the result to be posted on BitTorrent and a web server.

I think I can use crontab to organize the daily creation of a checkpoint. There remains only the question of automatic publication somewhere in the public space - I will think about it. I will write about the progress of the work here.

  Or you can make an account for pnet team on there and upload.
https://wasabi.com/

#!/bin/bash
export AWS_ACCESS_KEY_ID="wasabi_key"
export AWS_SECRET_ACCESS_KEY="wasabi_secret"
export AWS_DEFAULT_REGION="us-east-2"
Wherever the pocketcoin dir is for you
cd /home/pnet/.pocketcoin
tar cvf /tmp/checkpoint.tar blocks/ chainstate/ indexes/ pocketdb/
cd /tmp
gzip checkpoint.tar
/usr/bin/aws s3 cp /tmp/checkpoint.tar.gz s3://pnetsnaps/checkpoint.tar.gz --acl public-read --endpoint-url https://s3.us-east-2.wasabisys.com
rm /tmp/checkpoint.tar.gz

@SeditiousSov Great script! There is one nuance, to archive the database, you need to stop the node - something like:

pocketcoin-cli -datadir=/home/poc/.pocketcoin stop
... wait node stopped ...
ps aux | grep "pocketcoind" ... ?

#!/bin/bash
export AWS_ACCESS_KEY_ID="wasabi_key"
export AWS_SECRET_ACCESS_KEY="wasabi_secret"
export AWS_DEFAULT_REGION="us-east-2"
export NODEUSER="pnet"
su - $NODEUSER -c "pocketcoin-cli stop" > /dev/null
retval="1"
while [ $retval -ne 0 ]; do
ps aux | grep "pocketcoind" | grep -v "grep" > /dev/null
if [[ $? -eq 1 ]]; then
retval=0
fi
    sleep 2

done
cd /home/$NODEUSER/.pocketcoin
tar cvf /tmp/checkpoint.tar blocks/ chainstate/ indexes/ pocketdb/
Just noticed there is a -daemon flag
su - $NODEUSER -c "nohup pocketcoind &" > /dev/null
su - $NODEUSER -c "pocketcoind -daemon" > /dev/null
cd /tmp
gzip checkpoint.tar
/usr/bin/aws s3 cp /tmp/checkpoint.tar.gz s3://pnetsnaps/checkpoint.tar.gz --acl public-read --endpoint-url https://s3.us-east-2.wasabisys.com
rm /tmp/checkpoint.tar.gz

A timestamp would be helpful too so we don't download yesterdays checkpoint (guilty)


add DELETE to allowed cors methods

Default cors allowed headers is missing DELETE method, this change sets the AllowMethods explicitly, doesn't rely on cors middleware default.
/cc @adoublebarrel @rdallman

I'll wait for second endorsement before I hit that merge button though.


Does Rexray 0.5.1 support with docker 1.12.1

I have upgraded my docker to 1.12.1 and upgrade rexray 0.5.1.Now I am tying to check AWS EFS.
But when i start rexray ,it automatically failed.I don't understand the exact where is the issue .
ubuntu@ucp-controller:/etc/rexray$ sudo rexray service start Starting REX-Ray...FAILED!
error log
time="2016-10-12T10:24:57Z" level=error msg="default module(s) failed to initialize" error.driver=ec2 time=1476267897033 time="2016-10-12T10:24:57Z" level=error msg="error starting rex-ray" error.driver=ec2 time=1476267897033
`ubuntu@ucp-controller:/etc/rexray$ docker version
Client:
Version:      1.12.1-cs1
API version:  1.24
Go version:   go1.6.3
Git commit:   e7f4338
Built:        Wed Sep 21 21:05:28 2016
OS/Arch:      linux/amd64
Server:
Version:      1.12.1-cs1
API version:  1.24
Go version:   go1.6.3
Git commit:   e7f4338
Built:        Wed Sep 21 21:05:28 2016
OS/Arch:      linux/amd64
 **ubuntu@ucp-controller:/etc/rexray$ rexray version**
REX-Ray
Binary: /usr/bin/rexray
SemVer: 0.5.1
OsArch: Linux-x86_64
Branch: v0.5.1
Commit: e2c3165ce26cdbd8be76c3f6bde31db8618ae306
Formed: Wed, 14 Sep 2016 19:59:58 UTC
libStorage
SemVer: 0.2.1
OsArch: Linux-x86_64
Branch: v0.5.1
Commit: 2f7210c90252a4e1c9fb011ba29158cb0facb516
Formed: Wed, 14 Sep 2016 19:58:39 UTC
`
ubuntu@ucp-controller:/etc/rexray$ cat config.yml
rexray:
logLevel: warn
storageDrivers:

ec2
volume:
mount:
preempt: true
aws:
accessKey: xxxxx
secretKey: xxxxx

Hi @pratapnanda
One thing I immediately notice is that you mention that you are trying to use "AWS EFS", but your output shows that you've tried to configure a driver named ec2.
rexray v0.3.3 and earlier did have an ec2 driver, and that was actually for EBS volumes. Starting with rexray v0.4.0 ec2 was temporarily removed, and is making a comeback in in v0.6.0 (coming out soon, in Release Candidate form right now) as the ebs drivers.  You will need to configure a driver named efs, not ec2.
Docs on the EFS driver are here: http://libstorage.readthedocs.io/en/stable/user-guide/storage-providers/#aws-efs
You may also find the config file generator useful: http://rexrayconfig.codedellemc.com/
A working /etc/rexray/config.yml file for EFS would be more like the following:
rexray:
  logLevel: debug
libstorage:
  service: efs
  integration:
    volume:
      operations:
        mount:
          preempt: true
efs:
  accessKey: xxxx
  secretKey: xxxx

@pratapnanda v0.6.3 is now available. is this solved? can we close the issue?

@kacole2 -Yes ,Please close this issue .Thank you !!!


Unable to add graphql-language-server

Hey thanks for your work on this plugins 👍🏿 .
I've just tried to add in an installer for graphql using the custom installer setup instructions and hit a blocking issue.
function as_utils.lsp.add_custom_installer()
  -- npm install -g graphql-language-service-cli
  local config = require('lspconfig').graphql.document_config
  require('lspconfig.configs').graphql = {default_config = {}} --This errors if nil is set <-------------
  config.default_config.cmd[1] = "./node_modules/.bin/graphql-language-service-cli"

  require('lspinstall.servers').graphql = vim.tbl_extend('error', config, {
      install_script = [[
      ! -f package.json && npm init -y --scope=lspinstall || true
      npm install graphql-language-service-cli@latest
      ]],
      uninstall_script = nil
    })
end

I do this before calling setup of the lspinstall plugin or doing any setup of the lsp itself using lspconfig however I /packer/opt/nvim-lspconfig/lua/lspconfig/configs.lua:10: attempt to index local 'config_def' (a nil value)
Looking at the code in lspconfig it seems to have a validation and looks like expects this field to not be nil so throws errors.
I tried setting it to an empty object which silences the error but doesn't give me the option to install the server

Took me some time to debug. You need to change:
lspconfig.configs -> lspconfig/configs
lspinstall.servers -> lspinstall/servers
Don't ask me why. This could be a bug in neovim, but I'm not a lua expert.

Internally nvim-lspinstall uses require("lspinstall/servers"). When you require("lspinstall.servers") it seems to compare the literal string values of the require call. Since they don't match, the module is loaded twice. Again, I'm not sure if this is a bug or expected behavior in Lua.

@kabouzeid that's quite strange seems like an nvim bug potentially since I don't the choice of separators in a require should cause code to behave differently. Anyway that helped. It seems to work fine now. Just a couple of non blocking issues I noticed.
the -f flag in the example seems to cause an error if run from zsh so maybe somehow the shell used needs to be set explicitly to bash rather than the user's 🤷🏿 not sure what that flag does anyway.
Also the script can be reloaded more than once without causing errors. I use packer and automatically reload my configs on change but if the custom installer setup is called more than once it seems to throw errors about the require('lspconfig').<langserver>. that access returns nil tbh this is probably just a packer related obscure bug so feel free to ignore that one.

I'm happy to contribute the gql installer if you'd like it's not particular different from any of the other npm installers

This was a typo in the README, I fixed it now.
Replace ! -f package.json with [[ ! -f package.json ]] and also [[ with [=[ for the string literal delimiters.
This tests whether the file exists, and if not npm init -y --scope=lspinstall is executed. This works in any POSIX shell such as bash and zsh.
Not sure about the issue with packer, I'm still using Plug. If you send me a small packer config where this is happening, I can look into that.
How to add a bundled npm installer, see diagnosticls in this commit https://github.com/kabouzeid/nvim-lspinstall/commit/94eb7878fc4c7c40666ecfa80a198dcc5aaef8c0


[stack] Fix tutorial

See individual commits in the stack for details.
Note this is dependent on https://review.gerrithub.io/c/cue-lang/cue/+/542692 being merged. For now this stack includes the result of generating against the tip of that CL offline, using a replace directive. When that CL is submitted, we can drop the replace directive in this stack and properly regenerate at which point the build should go green.
TODO:

[] Compare cuelang.org with this preview

https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/packages
https://cuelang.org/docs/tutorials/tour/packages
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/packages/imports
https://cuelang.org/docs/tutorials/tour/packages/imports
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/packages/packages
https://cuelang.org/docs/tutorials/tour/packages/packages
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/expressions
https://cuelang.org/docs/tutorials/tour/expressions
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/expressions/conditional
https://cuelang.org/docs/tutorials/tour/expressions/conditional
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/expressions/operators
https://cuelang.org/docs/tutorials/tour/expressions/operators
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/expressions/regexp
https://cuelang.org/docs/tutorials/tour/expressions/regexp
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/expressions/listcomp
https://cuelang.org/docs/tutorials/tour/expressions/listcomp
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/expressions/interpolation
https://cuelang.org/docs/tutorials/tour/expressions/interpolation
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/expressions/fieldcomp
https://cuelang.org/docs/tutorials/tour/expressions/fieldcomp
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/expressions/interpolfield
https://cuelang.org/docs/tutorials/tour/expressions/interpolfield
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/expressions/coalesce
https://cuelang.org/docs/tutorials/tour/expressions/coalesce
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/intro
https://cuelang.org/docs/tutorials/tour/intro
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/intro/schema
https://cuelang.org/docs/tutorials/tour/intro/schema
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/intro/fold
https://cuelang.org/docs/tutorials/tour/intro/fold
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/intro/validation
https://cuelang.org/docs/tutorials/tour/intro/validation
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/intro/cue
https://cuelang.org/docs/tutorials/tour/intro/cue
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/intro/order
https://cuelang.org/docs/tutorials/tour/intro/order
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/intro/constraints
https://cuelang.org/docs/tutorials/tour/intro/constraints
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/intro/json
https://cuelang.org/docs/tutorials/tour/intro/json
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/intro/duplicates
https://cuelang.org/docs/tutorials/tour/intro/duplicates
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/intro/boilerplate
https://cuelang.org/docs/tutorials/tour/intro/boilerplate
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/references
https://cuelang.org/docs/tutorials/tour/references
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/references/selectors
https://cuelang.org/docs/tutorials/tour/references/selectors
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/references/emit
https://cuelang.org/docs/tutorials/tour/references/emit
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/references/cycleref
https://cuelang.org/docs/tutorials/tour/references/cycleref
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/references/scopes
https://cuelang.org/docs/tutorials/tour/references/scopes
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/references/hidden
https://cuelang.org/docs/tutorials/tour/references/hidden
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/references/cycle
https://cuelang.org/docs/tutorials/tour/references/cycle
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/references/aliases
https://cuelang.org/docs/tutorials/tour/references/aliases
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types
https://cuelang.org/docs/tutorials/tour/types
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/disjunctions
https://cuelang.org/docs/tutorials/tour/types/disjunctions
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/bytes
https://cuelang.org/docs/tutorials/tour/types/bytes
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/defs
https://cuelang.org/docs/tutorials/tour/types/defs
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/sumstruct
https://cuelang.org/docs/tutorials/tour/types/sumstruct
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/closed
https://cuelang.org/docs/tutorials/tour/types/closed
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/templates
https://cuelang.org/docs/tutorials/tour/types/templates
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/numbers
https://cuelang.org/docs/tutorials/tour/types/numbers
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/lists
https://cuelang.org/docs/tutorials/tour/types/lists
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/bounds
https://cuelang.org/docs/tutorials/tour/types/bounds
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/stringraw
https://cuelang.org/docs/tutorials/tour/types/stringraw
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/bounddef
https://cuelang.org/docs/tutorials/tour/types/bounddef
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/defaults
https://cuelang.org/docs/tutorials/tour/types/defaults
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/optional
https://cuelang.org/docs/tutorials/tour/types/optional
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/stringlit
https://cuelang.org/docs/tutorials/tour/types/stringlit
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/bottom
https://cuelang.org/docs/tutorials/tour/types/bottom
https://deploy-preview-267--cue.netlify.app/docs/tutorials/tour/types/types
https://cuelang.org/docs/tutorials/tour/types/types

@mvdan PTAL. This stack current includes a replace directive in the third commit. This is intentional, because it allows us to preview the results of this change on tip. I did this as a replace to ensure that the CI build breaks (rather than updating the cuelang.org/go version in go.mod to be the commit at tip) because we want to revert this.
In addition to looking at the diffs for each commit, please can you also help to review the visual "diff" between cuelang.org and this PR? I generated links in the description above for your convenience in case that's easier. I've also done the visual "diff" and everything looks as expected, but would be good to get a second pair of eyes on it.


Problem with NuGet package HueApi 0.4.42

If I download the NuGet package: https://www.nuget.org/packages/HueApi/0.4.42, the HueApi.dll located in the lib/net461 directory seems to be a .NET 6 assembly rather than a .NET 4.6.1 assembly.

also if I compare the file sizes of the dlls between version 0.3.42 and 0.4.42,  0.4.42 are a lot smaller, so there is definitely something strange with the 0.4.42 package

Thanks I'll have a look. I had to update the GitHub build and publish action because the old one wasn't working anymore. Probably something gone wrong there.

I made some changes to the build, it should be fixed in version 0.5.42. Can you try it?
The file size difference is because the DLL no longer contains embedded PDB/debug files. A proper snupkg file is published for debug sources.

It works now with the 0.5.42 version
Thanks for the quick fix.


Update for 3.0.0-ALPHA8

Please Update!

We've just released a version that is compatible with ALPHA8 - you can either build this from source in the master branch, or download the lasted compiled version from the Buycraft control panel.


Cell and RowClick (with Touch partner events mapped also) Events please

Would be good to have these events officially supported and exposed - any plans ?
Additionally if the amendment to achieve this could be advised until supported, that'd be most appreciated 👍
Steve

Hi,
You have event onselection for cell click, and row click or column click
More information on : https://bossanova.uk/jexcel/v4/docs/events
or here https://jexcel.net/v7/docs/events (Pro version)
onselection support ontouch mobile too

Great thanks Guillaume :-)
Steve


MariaDB persistent Helm Chart

This pull request adds support for MariaDB Helm chart.
It contains also test suite for it.

[test]

[test]

[test]

[test]


linux client

@AurangZ We're close! Just a few things - and would you mind running tslint? There are quite a few little things in util.ts, in particular:
yarn run tslint

@AurangZ Amazing!
I've manually verified that all contributors have signed a CLA.

Where i can download client for linux?)

@LionZXY I hope to add it to our daily builds in the next day or two:
https://github.com/Jigsaw-Code/outline-client/releases

@LionZXY The Linux client is now in our daily build:
https://github.com/Jigsaw-Code/outline-client/releases/tag/daily-2018-12-13
Please consider this beta quality but we would welcome any feedback.

Using Outline-Client.AppImage on my Ubuntu 18.04 Desktop, and works perfect. Thanks!


Correct text

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: martinconstante:x: Francesco FaraoneFrancesco Faraone seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Draft: Linux Only: Add method for reading JNI library for host unit tests.

This allows unit tests running with Roborazzi to use the layout JNI library and successfully run.
This change only adds support for Linux.

@iamralpht How would you prefer I handle the Mac and Windows support? I could try to add something to the DesignCompose plugin to disable unit tests. I could update the known issues page in our documentation, but I'm hesitant to update it without confirming the status of the other issues listed there.
I would also like your recommendation on what to do about the Mac and Windows reference apps checks, which are now failing. They're marked as required so it blocks the merge.

@iamralpht How would you prefer I handle the Mac and Windows support? I could try to add something to the DesignCompose plugin to disable unit tests. I could update the known issues page in our documentation, but I'm hesitant to update it without confirming the status of the other issues listed there.
I would also like your recommendation on what to do about the Mac and Windows reference apps checks, which are now failing. They're marked as required so it blocks the merge.

Let's disable the tests for Mac and Windows right now, and file a ticket to fix these tests on these targets in the future. Linux is where most of our internal & partner developers are (and Win/Mac can still use DC prebuilts through Maven and test on device/emulator).


Fixed safety issues from 2023-08-27

coverage: 25.0%. remained the same when pulling 55bd0df4e133de537588223312d940b91e84a855 on andy/safety-2023-08-27 into 804f07ec9460aed0c3567b6d4ccb7c74eeee311e on master.


Reproduce results

Hi,
Nice work!
I find that the reproduce results fluctuate a little, even with the random seed set.
What could be the cause of this result?
Looking forward to your reply!
best,

Hi,
That's indeed weird as we have set random seeds. We didn't check it carefully. But we think it does not matter as we have reported the averaged results with variances.
Best


Extra argument 'equalTo' in call

This issue is similar to #133, but I get the error with only one .by
Klass.by("attribute", equalTo: "value")
Returns: Extra argument 'equalTo' in call
Figured it had to be a recent commit, and found that rolling back https://github.com/SugarRecord/SugarRecord/commit/a04095dc7ef11322d80d05cef9090d2dad77c5c3 fixes it, so I'm assuming this is also an area where test coverage could be improved.

As a temp workaround i added:
extension String: Printable {
public var description: String { return self }
}

https://github.com/SugarRecord/SugarRecord/commit/a04095dc7ef11322d80d05cef9090d2dad77c5c3 as been reverted. Things should work as expected.

Why was it merged in the first place, and how can these sorts of bugs be prevented in the future?


Failing to link newer object files

I'm trying to modernize the object files used in PreviewSystem to use swift-wasm-5.3.1-RELEASE toolchain and latest JavaScriptKit.
Linking a trivial object file with the prebuilt library fails at relocation.
Inputs.zip
The log
Info: Reading obj.wasm
Warning: Custom section 'target_features' is currently not supported
Info: Reading library.so.wasm
Warning: Linking subsection 'comdatInfo' is not supported now
Warning: Custom section 'producers' is currently not supported
Debug: weak undef stub for _ZTH5errno is synthesized
Debug: weak undef stub for _swift_FORCE_LOAD_$_swiftWASILibc is synthesized
Debug: __start_swift5_typeref is synthesized
Debug: __stop_swift5_typeref is synthesized
Debug: __start_swift5_type_metadata is synthesized
Debug: __stop_swift5_type_metadata is synthesized
Debug: __start_swift5_reflstr is synthesized
Debug: __stop_swift5_reflstr is synthesized
Debug: __start_swift5_protocols is synthesized
Debug: __stop_swift5_protocols is synthesized
Debug: __start_swift5_protocol_conformances is synthesized
Debug: __stop_swift5_protocol_conformances is synthesized
Debug: __start_swift5_fieldmd is synthesized
Debug: __stop_swift5_fieldmd is synthesized
Debug: __start_swift5_entry is synthesized
Debug: __stop_swift5_entry is synthesized
Debug: __start_swift5_capture is synthesized
Debug: __stop_swift5_capture is synthesized
Debug: __start_swift5_builtin is synthesized
Debug: __stop_swift5_builtin is synthesized
Debug: __start_swift5_assocty is synthesized
Debug: __stop_swift5_assocty is synthesized
Debug: __start_.swift_modhash is synthesized
Debug: __stop_.swift_modhash is synthesized
Debug: __start_.swift1_autolink_entries is synthesized
Debug: __stop_.swift1_autolink_entries is synthesized
Debug: __start_.rodata is synthesized
Debug: __stop_.rodata is synthesized
Debug: __start_.note.swift_reflection_metadata is synthesized
Debug: __stop_.note.swift_reflection_metadata is synthesized
Debug: __start_.data is synthesized
Debug: __stop_.data is synthesized
Debug: __start_.bss is synthesized
Debug: __stop_.bss is synthesized
Debug: __dso_handle is synthesized
Debug: __stack_pointer is synthesized
Debug: Print all undefined symbols
Debug: fd_seek
Debug: fd_prestat_dir_name
Debug: path_remove_directory
Debug: swjs_get_subscript
Debug: swjs_call_function_with_this
Debug: __start_swift5_replac2
Debug: swjs_instanceof
Debug: fd_fdstat_set_flags
Debug: fd_read
Debug: $s10Foundation4UUIDVN
Debug: environ_sizes_get
Debug: swjs_decode_string
Debug: $s10Foundation4UUIDVACycfC
Debug: swjs_encode_string
Debug: __stop_swift5_replace
Debug: fd_close
Debug: path_readlink
Debug: args_sizes_get
Debug: path_create_directory
Debug: path_filestat_set_times
Debug: swjs_set_prop
Debug: fd_fdstat_get
Debug: fd_readdir
Debug: swjs_call_function
Debug: __stop_swift5_replac2
Debug: $s10Foundation4UUIDVs23CustomStringConvertibleAAMc
Debug: poll_oneoff
Debug: swjs_set_subscript
Debug: path_rename
Debug: swjs_load_string
Debug: path_open
Debug: $s10Foundation6BundleCMn
Debug: path_unlink_file
Debug: args_get
Debug: swjs_create_typed_array
Debug: proc_exit
Debug: __start_swift5_replace
Debug: fd_prestat_get
Debug: path_link
Debug: swjs_release
Debug: fd_write
Debug: $s10Foundation8TimeZoneV22abbreviationDictionarySDyS2SGvgZ
Debug: $s10Foundation3URLV14absoluteStringSSvg
Debug: $s10Foundation3URLVMn
Debug: swjs_call_throwing_new
Debug: environ_get
Debug: path_filestat_get
Debug: clock_time_get
Debug: swjs_get_prop
Debug: swjs_create_function
Debug: path_symlink
Debug: random_get
Debug: swjs_call_new
Debug: Writing type
Debug: Finish writing type
Debug: Writing import
Debug: Finish writing import
Debug: Writing function
Debug: Finish writing function
Debug: Writing table
Debug: Finish writing table
Debug: Writing memory
Debug: Finish writing memory
Debug: Writing global
Debug: Finish writing global
Debug: Writing export
Debug: Finish writing export
Debug: Writing elem
Debug: Finish writing elem
Debug: Writing code
Fatal error: file ChibiLink/Relocation.swift, line 156
2021-03-11 18:41:37.808576+0800 chibi-link[4359:10072536] Fatal error: file ChibiLink/Relocation.swift, line 156
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = Fatal error
    frame #0: 0x00007fff2ca79890 libswiftCore.dylib`_swift_runtime_on_report
    frame #1: 0x00007fff2caf3ef3 libswiftCore.dylib`_swift_stdlib_reportFatalErrorInFile + 211
    frame #2: 0x00007fff2c7837e5 libswiftCore.dylib`closure #1 (Swift.UnsafeBufferPointer<Swift.UInt8>) -> () in closure #1 (Swift.UnsafeBufferPointer<Swift.UInt8>) -> () in closure #1 (Swift.UnsafeBufferPointer<Swift.UInt8>) -> () in Swift._assertionFailure(_: Swift.StaticString, _: Swift.String, file: Swift.StaticString, line: Swift.UInt, flags: Swift.UInt32) -> Swift.Never + 245
    frame #3: 0x00007fff2c783427 libswiftCore.dylib`closure #1 (Swift.UnsafeBufferPointer<Swift.UInt8>) -> () in closure #1 (Swift.UnsafeBufferPointer<Swift.UInt8>) -> () in Swift._assertionFailure(_: Swift.StaticString, _: Swift.String, file: Swift.StaticString, line: Swift.UInt, flags: Swift.UInt32) -> Swift.Never + 87
    frame #4: 0x00007fff2c783a11 libswiftCore.dylib`function signature specialization <Arg[1] = [Closure Propagated : closure #1 (Swift.UnsafeBufferPointer<Swift.UInt8>) -> () in closure #1 (Swift.UnsafeBufferPointer<Swift.UInt8>) -> () in Swift._assertionFailure(_: Swift.StaticString, _: Swift.String, file: Swift.StaticString, line: Swift.UInt, flags: Swift.UInt32) -> Swift.Never, Argument Types : [Swift.StaticStringSwift.UnsafeBufferPointer<Swift.UInt8>Swift.UIntSwift.UInt32]> of generic specialization <()> of Swift.String.withUTF8<A>((Swift.UnsafeBufferPointer<Swift.UInt8>) throws -> A) throws -> A + 257
    frame #5: 0x00007fff2c7820e7 libswiftCore.dylib`Swift._assertionFailure(_: Swift.StaticString, _: Swift.String, file: Swift.StaticString, line: Swift.UInt, flags: Swift.UInt32) -> Swift.Never + 519
  * frame #6: 0x0000000100048471 chibi-link`Relocator.translate(relocation=ChibiLink.Relocation @ 0x00007ffeefbfcce8, binary=0x0000000107b0fc40, current=0, location=2935, self=0x000000010f9cdaf0) at Relocation.swift:156:17
    frame #7: 0x000000010004b424 chibi-link`Relocator.apply(relocation=ChibiLink.Relocation @ 0x00007ffeefbfd6f8, sectionOffset=968, binary=0x0000000107b0fc40, bytes=8008 values, range=968..<5944, self=0x000000010f9cdaf0) at Relocation.swift:244:21
    frame #8: 0x0000000100046c6c chibi-link`Relocator.relocate(chunk=8008 values, relocations=109 values, binary=0x0000000107b0fc40, range=968..<5944, sectionOffset=968, self=0x000000010f9cdaf0) at Relocation.swift:95:13
    frame #9: 0x00000001000467c8 chibi-link`Relocator.relocate<T>(chunk=0x0000000107b0c070, self=0x000000010f9cdaf0) at Relocation.swift:81:9
    frame #10: 0x000000010002bf19 chibi-link`OutputCodeSection.writeVectorContent(writer=0x000000010fab37d0, relocator=0x000000010f9cdaf0, self=0x000000010f9abd70) at OutputCodeSection.swift:27:34
    frame #11: 0x000000010002c35a chibi-link`protocol witness for OutputVectorSection.writeVectorContent(writer:relocator:) in conformance OutputCodeSection at <compiler-generated>:0
    frame #12: 0x000000010003e6ad chibi-link`OutputVectorSection.writeContent(writer=0x000000010fab37d0, relocator=0x000000010f9cdaf0, self=0x000000010f9abd70) at OutputSection.swift:38:13
    frame #13: 0x000000010002c434 chibi-link`protocol witness for OutputSection.writeContent(writer:relocator:) in conformance OutputCodeSection at <compiler-generated>:0
    frame #14: 0x000000010003e39e chibi-link`OutputSection.write(writer=0x000000010fab37d0, relocator=0x000000010f9cdaf0, self=0x000000010f9abd70) at OutputSection.swift:23:17
    frame #15: 0x000000010002c3ed chibi-link`protocol witness for OutputSection.write(writer:relocator:) in conformance OutputCodeSection at <compiler-generated>:0
    frame #16: 0x00000001000434c1 chibi-link`writeSection #1 <S>(section=0x000000010f9abd70, self=0x000000010fab3830, relocator=0x000000010f9cdaf0) in OutputWriter.writeBinary() at OutputWriter.swift:77:25
    frame #17: 0x00000001000423c1 chibi-link`OutputWriter.writeBinary(self=0x000000010fab3830) at OutputWriter.swift:94:13
    frame #18: 0x000000010002b036 chibi-link`performLinker(filenames=2 values, outputStream=(payload_data_0 = 0x0000000107b0f6c0 -> 0x0000000100076db0 type metadata for ChibiLink.FileOutputByteStream, payload_data_1 = 0x00000001001c0030 dyld`__block_descriptor_tmp, payload_data_2 = 0x00007ffeefbff360, instance_type = ChibiLink.FileOutputByteStream, witness_table_OutputByteStream = 0x0000000100072b38 chibi-link`protocol witness table for ChibiLink.FileOutputByteStream : ChibiLink.OutputByteStream in ChibiLink), exports=0 values) at Linker.swift:16:16
    frame #19: 0x0000000100005523 chibi-link`main at main.swift:23:9
    frame #20: 0x00007fff2039b621 libdyld.dylib`start + 1
    frame #21: 0x00007fff2039b621 libdyld.dylib`start + 1

@yonihemi I improved the error message: https://github.com/kateinoigakukun/chibi-link/commit/1a1b9267b573364692716f2c588d51c05b065ff9
The input object file contains Foundation symbol but library.so.wasm doesn't have Foundation, so relocation failed. I guess you can get same result using wasm-ld

Thanks! I'll try to figure out why Foundation is not there.

As far as I remember, Tokamak doesn't depend on Foundation. So if you want to use Foundation, you need to add -lFoundation -lCoreFoundation -lBlocksRuntime  and so on...  here

I was missing the same 'unarchive and force link in each object' you've done for swiftSwiftOnoneSupport, which I've now done for all libraries (once I get it working I'll see what can be removed).
Now am stuck with swjs_ exports not being linked as exports in library.so.wasm. They're exported correctly in _CJavaScriptKit.c.owhich definitely is linked in. I've tried every permutation of --export-all, --export-dynamic, --export (also --no-entry for good measure).

@yonihemi Good catch! chibi-link doesn't export symbols that have WASM_SYM_EXPORTED flag yet. That's clearly missing implementation of chibi-link.

As far as I remember, Tokamak doesn't depend on Foundation.

It now does, we need Bundle to support the Image view.

I think it's the level before chibi-link, in wasm-ld.
If I wasm2wat production file then swjs_library_version is there as a function, but at my compiled lib it's not there. Uploading 20210315-library.so.wasm.zip…

@yonihemi Hmm, could you tell me which linker options are you using? Are you using https://github.com/swiftwasm/swiftwasm-pad/blob/master/PreviewSystem/build-script.sh ?

Too many attempts to post, this is a random snapshot...
build-script.sh.zip

@yonihemi OK, I got the reason why the latest library.so doesn't have swjs_ prefixed symbols.
wasm-ld doesn't output export section when using --relocatable, so the produced object file doesn't have exported name info like swjs_library_version. So we need to rename internal function names to be the same as the exported names. After that, chibi-link can find swjs_library_version in object file and export it.
Here is a PR to address this issue. https://github.com/swiftwasm/JavaScriptKit/pull/123

Excellent, thanks.
ChibiLink links successfully now, but I'm still not able to run linked module - somehow it's behaving differently (getting attempting to access detached ArrayBuffer errors).
Trying to isolate the source.

Still not sure where the issue is coming from. I'm trying with latest 5.4-SNAPSHOT-2021-03-25.
When building the library I link all except libswift_Concurrency because it has conflicting symbols with libswiftStandaloneRuntime.
Chibi links succesfully, emitting:
Warning: Linking subsection 'comdatInfo' is not supported now
Warning: Custom section 'producers' is currently not supported

20210326.zip
Finally, running the linked wasm breaks with:
TypeError: attempting to access detached ArrayBuffer
    clock_res_get webpack:///./node_modules/@wasmer/wasi/lib/index.esm.js?:111
    start webpack:///./node_modules/@wasmer/wasi/lib/index.esm.js?:131
    startWasiTask webpack:///./entrypoint/dev.js?:94
    async* webpack:///./entrypoint/dev.js?:105
    js http://<IP_ADDRESS>:9616/dev.js:97
    __webpack_require__ http://<IP_ADDRESS>:9616/dev.js:20
    <anonymous> http://<IP_ADDRESS>:9616/dev.js:84
    <anonymous> http://<IP_ADDRESS>:9616/dev.js:87

(clock_res_get is called with (3316844, 3316840))
dist.zip


Add child component

Adding a dedicated component to add new content to a chapter or skill as asked in #217
Please note that clicking the icons and the service behind it hasn't been implemented yet. Also, the little arrow above this component hasn't been added yet.

Bug: I type 3 char, I press "x", the chapter/task button are still displayed


WebVtt captions display for HLS Live stream with 10s segments, but not for stream with 3.8s segments

The setup:
Our customer has a live HLS stream, with 10-segment duration, with VTT subtitles. When playing this stream in the Androidx Media demo, the captions can be selected and displayed. The customer wants to use a shorter segment duration (3.84s), however, for the stream that plays these shorter durations in the demo, captions can be selected, and show in the tracks log output as selected, but do not display.
There are no errors written to the logcat.
I've also observed this behavior with ExoPlayer 2.19.1 (which our SDK is currently using; we are planning to migrate to AndroidX Media later this spring).
I've noticed with the customer's 10s segment feed, that the captions displayed appear to have some minor sync issues with the spoken dialog.
(both 10s and 3.84s URLs will be shared through the dev email)
Questions:

Considering that there are no errors seen in the demo app's logcat, it does not appear that this is a bug, would you agree?
Considering that we're still using ExoPlayer with our SDK, are there any ExoPlayer configuration parameters that might help with this behavior?
Based on this behavior only occurring with the shorter segment duration, we're going to suggest to the customer to test with somewhat longer segment durations, is there a segment duration (less than 10s) that you may have seen elsewhere, where this behavior did not occur?

Thanks in advance for your assistance.

The only class that I could find that has that method is DashMediaSource.

The method is also present on DefaultMediaSourceFactory in the latest release (as I linked above), or on the main branch.

I added that call in the demo's PlayerActivity, line 318:
    return new DefaultMediaSourceFactory(/* context= */ this)
        .experimentalParseSubtitlesDuringExtraction(true)
        .setDataSourceFactory(dataSourceFactory)

and set a breakpoint in DefaultMediaSourceFactory, line 511, since this conditional wraps the conditional for parseSubtitlesDuringExtraction (which evaluates to true, even though it's not reached with either stream):
    List<MediaItem.SubtitleConfiguration> subtitleConfigurations =
        castNonNull(mediaItem.localConfiguration).subtitleConfigurations;
    if (!subtitleConfigurations.isEmpty()) {
      MediaSource[] mediaSources = new MediaSource[subtitleConfigurations.size() + 1];

I'm seeing that for both streams, 10s and 3.84s segments, that the subtitleConfigurations list is empty, however, the captions are displayed when selected in the Media3 demo for the 10s segment stream. For the 3.84s segment stream, they are not displayed when selected.
Looking at logcats for tests with each stream, I'm seeing that on the same device (Samsung S20, Android 12), there is an additional codec listed the text group for the 3.84s segment stream:
For the 10s segment stream:
2024-03-08 11:18:47.327 21093-21093 EventLogger             androidx.media3.demo.main            D    group [
2024-03-08 11:18:47.327 21093-21093 EventLogger             androidx.media3.demo.main            D      [X] Track:0, id=subs_wvtt:ENG_80_888, mimeType=application/x-media3-cues, container=application/x-mpegURL, codecs=text/vtt, language=en, label=ENG_80_888, selectionFlags=[auto], supported=YES
2024-03-08 11:18:47.327 21093-21093 EventLogger             androidx.media3.demo.main            D    ]

For the 3.84s stream:
2024-03-08 11:24:58.584 21093-21093 EventLogger             androidx.media3.demo.main            D    group [
2024-03-08 11:24:58.584 21093-21093 EventLogger             androidx.media3.demo.main            D      [X] Track:0, id=subs_wvtt:ENG_80_888, mimeType=application/x-media3-cues, container=application/x-mpegURL, codecs=text/vtt wvtt, language=en, label=ENG_80_888, selectionFlags=[auto], supported=YES
2024-03-08 11:24:58.584 21093-21093 EventLogger             androidx.media3.demo.main            D    ]

Which version of the library did you use to generate the logs/behaviour in https://github.com/androidx/media/issues/1147#issuecomment-1986189636?

I was testing on the main branch. Just re-checked it to be sure, on both main and the latest release tag, and the same observations apply.

@icbaker Can we transition this to a bug, or should I open a new ticket?

I've opened a bug for this, since I could not transition it directly (and the bug needed a bugreport as well). Please see #1457.


fix: add missing walletIndex when get signer address

Fix #406

hanks for finding and submitting a fix. since this is a one liner, i'm going to add it to the https://github.com/xchainjs/xchainjs-lib/pull/405 , which also needs approval (since last 7 days) can @veado and @davidp94 please have a look?


How to perform this query in Chewy?

I have the following query in ES now:
{
	"query": {
		"bool": {
			"must": [{
				"query_string": {
					"default_field": "project.name",
					"query": "*Pum*"
				}
			}],
			"must_not": [],
			"should": [{
				"term": {
					"allowed_user_ids": "all"
				}
			}, {
				"term": {
					"allowed_user_ids": "2"
				}
			}]
		}
	},
	"from": 0,
	"size": 10,
	"sort": [],
	"aggs": {}
}

This is to search by name and make sure the allowed user ID in the document is either "all" or "2". How can this translate onto Chewy?

I've tried:
ProjectsIndex::Project.filter{ must( q(query_string: {query: '*Pum*'})).should(allowed_user_ids == "all", allowed_users_ids == 2) }

But this outputs:
{: body => {: query => {: filtered => {: query => {: match_all => {}
				}, : filter => {: bool => {: must => [{: query => {: query_string => {: query => "*Pum*"
								}
							}
						}], : should => [{: term => {
								"allowed_user_ids" => "all"
							}
						}, {: term => {
								"allowed_users_ids" => 2
							}
						}]
					}
				}
			}
		}
	}, : index => ["projects"], : type => ["project"]
}

which is not the same.

You have to use ProjectsIndex::Project.query(hash_here) which doesn't provide DSL yet unfortunately

I see. I'm using the close-to-the-metal ElasticSearch gem for this. Thanks anyway!


Fix reference to Sections constructor instance

sections is undefined

Just ran into an issue coming from this! Stoked to see it fixed before I dug in.


How can I exclude specific values from the field?

If the uv vector value is ignore value, I want don't display it.
I think it's getWind.frag where we look up the u, v vector values, right?
sorry bad english..
my dataset
DataSet.txt
exclude area rectangle

I think it's getWind.frag where we look up the u, v vector values, right?
Yes

If you want to exclude specific area, you can refer to this issue
If you want to hide the particles with special uv values, you can simply add an if statement in  "postProcessingSpeed.frag".

Is it possible to get the uvVector value from postProcessingSpeed.frag?
Is particleSpeed's x, y a uv vector value?

Is it possible to get the uvVector value from postProcessingSpeed.frag?
Is particleSpeed's x, y a uv vector value?

Yes, and Yes.
For your problem, I forgot that the calculation and rendering are separate, sorry...
Besides of "postProcessingSpeed.Frag", you also need to modify "segmentDraw.vert" and "segmentDraw.frag".
The postProcessingSpeed will be passed to the segmentDraw for rendering, so you should add a check in segmentDraw.vert/frag, and set the alpha value of RGBA to zero so that the unwanted particles are invisible.

Thank you. I have another question to ask, can I answer it?
The direction currently being displayed is different from the direction I want. How can I do this?
Can I get directions from glsl?

There is no direction in the GLSL code, but you can calculate it since direction = nextPosition - currentPosition

It was corrected as suggested, but the problem was not resolved.
It seems that the speed value is normalized from 0 to 1. But my dataset also contains minus values. What should I do in this case?
In the segmentDraw.vert, assuming that u and v values are normal values, the following code is added.

vec4 particleSpeed = texture2D (postProcessingSpeed, particleIndex);
float rSpeed = sqrt ((particleSpeed.x * particleSpeed.x) + (particleSpeed.y * particleSpeed.y));
if (rSpeed! = ignoreValue) {
    speedNormalization = particleSpeed.a;
} else {
    speedNormalization = 0.0;
}

It seems that the speed value is normalized from 0 to 1. But my dataset also contains minus values. What should I do in this case?

It is okay, because the normalized value of x is calculated by (x - min) / (max - min).

If the calculated speed value is 0, is the next position value the same?

I am afraid not, since the calculation and rendering are separate, hiding particle does not means that it will not move. If you don't want particles to move, change the code in "updatePosition.frag"

updateSpeed.Frag => calcRelativeSpeed seen
float minRelativeSpeed = -speedFactor * pixelSize;
float maxRelativeSpeed = speedFactor * pixelSize;

I found that it is normalized with. If this is the case, should ignoreValue be used for mix normalization as well?

It depends on what you want to do.
If you want to control the particles position, modify "updatePosition.frag"
If you want to control the particles speed and their color(color is used to represent the speed),  modify "updateSpeed.frag"
If you want to control the rendering of particles, check those "xxxDraw" files.


Ap 2371 ccms stg

What
Link to story
Describe what you did and why.
Checklist
Before you ask people to review this PR:

[ ] Tests and rubocop should be passing: bundle exec rake
[ ] Github should not be reporting conflicts; you should have recently run git rebase master.
[ ] There should be no unnecessary whitespace changes. These make diffs harder to read and conflicts more likely.
[ ] The PR description should say what you changed and why, with a link to the JIRA story.
[ ] You should have looked at the diff against master and ensured that nothing unexpected is included in your changes.
[ ] You should have checked that the commit messages say why the change was made.

Codecov Report

Merging #2637 (101736f) into master (afe8bec) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master     #2637   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          527       527
  Lines        10884     10884
=========================================
  Hits         10884     10884

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 afe8bec...101736f. Read the comment docs.


Var/LazyInit/etc annotations can cause problems for Android builds due to reliance on javax.lang.model.element.Modifier

Description of the problem / feature request:
Multiple annotations inside com.google.errorprone:error_prone_annotations use the meta-annotation @IncompatibleModifiers(FINAL).
Here, FINAL references javax.lang.model.element.Modifier.FINAL. However, the android.jar file used to build Android projects does not include javax.lang.model.element.Modifier.
This results in the following error whenever code using @Var, @LazyInit, @ForOverride, etc. is compiled for Android with a -Werror flag (our default setup):
warning: unknown enum constant Modifier.FINAL
  reason: class file for javax.lang.model.element.Modifier not found
error: warnings found and -Werror specified
1 error
1 warning

For an example, here is a simple repro as a standalone Android project using gradle (see below for instructions).
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
git clone https://github.com/lazaroclapp/ep_modifiers_android_repro.git
gradle build

Observe:
warning: unknown enum constant Modifier.FINAL
  reason: class file for javax.lang.model.element.Modifier not found
error: warnings found and -Werror specified
1 error
1 warning

What version of Error Prone are you using?
Can repro on 2.5.1, 2.4, and 2.3.3
Have you found anything relevant by searching the web?
I posted on the mailing list and got prompt help from Liam figuring out the root cause of the issue. Thanks!
My recommended solution
The real problem here is @IncompatibleModifiers and its use of javax.lang.model.element.Modifier's enum values as annotation parameters.
Could com.google.errorprone:error_prone_annotations perhaps include a separate Modifier enum that doesn't depend on javax.lang.model.element.Modifier, and use that for the public API of the @IncompatibleModifiers meta-annotation and for annotating the relevant Error Prone annotations?
This will likely complicate IncompatibleModifiersChecker a bit, or require a mapping from the new custom Modifier enum to javax.lang.model.element.Modifier, but it will make the annotation fully compatible with Android builds.
FYI, if you agree that supporting Android with -Werror is important, and that the above is a reasonable solution, I'd be more than happy to give it a first try at a PR that replaces javax.lang.model.element.Modifier with e.g. com.google.errorprone.annotations.Modifier.

Thanks for the write-up and the suggestions. I agree that, in hindsight, using a different representation of the modifiers would have been a good choice, since javax.lang.model.element.Modifier isn't available on Android.
At this point, my concern is that would be a breaking change to the API of error_prone_annotations. Even if we support both versions of the annotation in the check, users of error_prone_annotations (i.e. who are using @IncompatibleModifiers in their own code) would be broken the next time they upgrade that dependency. It's not a difficult change to make, and I don't think @IncompatibleModifiers has that many uses compared to other annotations in the artifact, but it's still something we'd want to be cautious about.
There are ways to do the change incrementally (like introducing the new way to specify modifiers in parallel with the current one, deprecate the current one, and wait a while before removing it). We could also introduce a separate Android-compatible version of the annotations artifact.
A few other stray thoughts: it would be nice if those javac diagnostics could be controlled by a flag (like -Xlint:-classfile). it would also be nice if there was a finer-grained version of -Werror that allowed opting in to individual javac diagnostics as errors, instead of everything. (Bazel supports something like that, but it isn't supported directly in javac.)
Finally, you mentioned in the thread

Short term, we could possibly fix this by taking that enum into its own jar and adding it as a dependency, then removing it (and the annotations using it) before dexing.

We're actually doing something similar to that, which is why we hadn't noticed this issue in our own code. As long as the dep is removed before dexing, and the annotations referencing the enum are CLASS retention and don't show up in dex anyways, it has been working fine for us.

Thanks for the write-up and the suggestions. I agree that, in hindsight, using a different representation of the modifiers would have been a good choice, since javax.lang.model.element.Modifier isn't available on Android.
At this point, my concern is that would be a breaking change to the API of error_prone_annotations. Even if we support both versions of the annotation in the check, users of error_prone_annotations (i.e. who are using @IncompatibleModifiers in their own code) would be broken the next time they upgrade that dependency. It's not a difficult change to make, and I don't think @IncompatibleModifiers has that many uses compared to other annotations in the artifact, but it's still something we'd want to be cautious about.
There are ways to do the change incrementally (like introducing the new way to specify modifiers in parallel with the current one, deprecate the current one, and wait a while before removing it). We could also introduce a separate Android-compatible version of the annotations artifact.
A few other stray thoughts: it would be nice if those javac diagnostics could be controlled by a flag (like -Xlint:-classfile). it would also be nice if there was a finer-grained version of -Werror that allowed opting in to individual javac diagnostics as errors, instead of everything. (Bazel supports something like that, but it isn't supported directly in javac.)
Finally, you mentioned in the thread

Short term, we could possibly fix this by taking that enum into its own jar and adding it as a dependency, then removing it (and the annotations using it) before dexing.

We're actually doing something similar to that, which is why we hadn't noticed this issue in our own code. As long as the dep is removed before dexing, and the annotations referencing the enum are CLASS retention and don't show up in dex anyways, it has been working fine for us.

There are ways to do the change incrementally (like introducing the new way to specify modifiers in parallel with the current one, deprecate the current one, and wait a while before removing it). We could also introduce a separate Android-compatible version of the annotations artifact.

This would be quite helpful. Something as simple as having a javax.[...].Modifier and com.google.errorprone.annotations.Modifier version of the @IncompatibleModifiers annotation (I believe it would need to have a different name), and using the second for all error_prone_annotations first-party annotations would probably solve the problem for us. Not sure if just having a class referencing Modifier is an issue, but my belief is that the compiler doesn't care at all until it tries to complete the annotation.
The above could theoretically break builds which use one version of the EP checkers and a different version of the EP annotations artifact (e.g. 2.5.1 core and 2.5.2 annotations could result in @Var's compatibility with final not being checked), but I've always assumed that's not a supported configuration to begin with...

A few other stray thoughts: it would be nice if those javac diagnostics could be controlled by a flag (like -Xlint:-classfile). it would also be nice if there was a finer-grained version of -Werror that allowed opting in to individual javac diagnostics as errors, instead of everything.

-Xlint:-xyz does that for a number of warnings, but afaik not for this one. Also, even then, disabling this "unknown enum constant" warning in the general case is probably not what we want either. We'd need something targeted enough to tell it to not warn about a specific enum class.

We're actually doing something similar to that, which is why we hadn't noticed this issue in our own code. As long as the dep is removed before dexing, and the annotations referencing the enum are CLASS retention and don't show up in dex anyways, it has been working fine for us.

So, @Var for example is RUNTIME, but then the @IncompatibleModifiers annotation itself has CLASS retention for the time being, which means the above would work. Annoyingly, though, Modifiers is GPLv2 with the classpath exception, so if we are pulling it in, even just for building, we'll probably need to end up adding safeguards to make sure it never ever gets included into the final application bundle.
Given that, my current thinking as to internal workarounds has evolved to favor forking error_prone_annotations and either doing my proposed patch or just removing the definition and usages of @IncompatibleModifiers, since what we really want to use is @Var and other annotations that use @IncompatibleModifiers as a meta-annotation.
That said, we'd love to have a good way to keep to mainline EP without an internal fork (have done that before, not a huge pain, but not the best either).

There are ways to do the change incrementally (like introducing the new way to specify modifiers in parallel with the current one, deprecate the current one, and wait a while before removing it). We could also introduce a separate Android-compatible version of the annotations artifact.

This would be quite helpful. Something as simple as having a javax.[...].Modifier and com.google.errorprone.annotations.Modifier version of the @IncompatibleModifiers annotation (I believe it would need to have a different name), and using the second for all error_prone_annotations first-party annotations would probably solve the problem for us. Not sure if just having a class referencing Modifier is an issue, but my belief is that the compiler doesn't care at all until it tries to complete the annotation.
The above could theoretically break builds which use one version of the EP checkers and a different version of the EP annotations artifact (e.g. 2.5.1 core and 2.5.2 annotations could result in @Var's compatibility with final not being checked), but I've always assumed that's not a supported configuration to begin with...

A few other stray thoughts: it would be nice if those javac diagnostics could be controlled by a flag (like -Xlint:-classfile). it would also be nice if there was a finer-grained version of -Werror that allowed opting in to individual javac diagnostics as errors, instead of everything.

-Xlint:-xyz does that for a number of warnings, but afaik not for this one. Also, even then, disabling this "unknown enum constant" warning in the general case is probably not what we want either. We'd need something targeted enough to tell it to not warn about a specific enum class.

We're actually doing something similar to that, which is why we hadn't noticed this issue in our own code. As long as the dep is removed before dexing, and the annotations referencing the enum are CLASS retention and don't show up in dex anyways, it has been working fine for us.

So, @Var for example is RUNTIME, but then the @IncompatibleModifiers annotation itself has CLASS retention for the time being, which means the above would work. Annoyingly, though, Modifiers is GPLv2 with the classpath exception, so if we are pulling it in, even just for building, we'll probably need to end up adding safeguards to make sure it never ever gets included into the final application bundle.
Given that, my current thinking as to internal workarounds has evolved to favor forking error_prone_annotations and either doing my proposed patch or just removing the definition and usages of @IncompatibleModifiers, since what we really want to use is @Var and other annotations that use @IncompatibleModifiers as a meta-annotation.
That said, we'd love to have a good way to keep to mainline EP without an internal fork (have done that before, not a huge pain, but not the best either).

Future versions of Android may include java/lang/annotation/*, but there aren't plans for javax.lang.model.element.Modifier. (That would be ideal from my perspective since it avoids the change to the EP version, but even if it happened it'd be a while before we could assume all of our users were on a new enough version of Android to benefit from it...)
We could think about doing something like:
public @interface IncompatibleModifiers {
  /** @deprecated use {@link #modifier} instead. */
  @Deprecated
  javax.lang.model.element.Modifier[] value();
  com.google.errorprone.annotations.Modifier[] modifier();
}

And waiting a few releases, and then deleting value. We could also consider a multi-step migration to eventually make value just refer to the new enum:
public @interface IncompatibleModifiers {
  /** @deprecated use {@link #value} instead. */
  @Deprecated
  com.google.errorprone.annotations.Modifier[] modifier();
  com.google.errorprone.annotations.Modifier[] value();
}

If I had a time machine to use a different Modifier enum in the first place, I would do that. At this point it's enough hassle to fix that I'm not sure this is a super high priority for us, especially since it's at least one breaking API change, and there are work-arounds.
If the change I described happened, do you have any input on how quickly you'd want to see support for the old element be removed? I'm just curious if you have opinions about the rate of breaking changes in the API, we don't get a lot of feedback on that generally.

Given that, my current thinking as to internal workarounds has evolved to favor forking error_prone_annotations and either doing my proposed patch or just removing the definition and usages of @IncompatibleModifiers, since what we really want to use is @Var and other annotations that use @IncompatibleModifiers as a meta-annotation.

That makes sense to me in the short term, FWIW. I'd like to give you an alternative using mainline EP, but also can't promise we're going to have that alternative in the immediate future.

So, I think - but I am not sure - that this might just work immediately for us:
public @interface IncompatibleModifiers {
  /** @deprecated use {@link #modifier} instead. */
  @Deprecated
  javax.lang.model.element.Modifier[] value();
  com.google.errorprone.annotations.Modifier[] modifier();
}

But only if, at the same time the modifier() 'field' is introduced, all usages of @IncompatibleModifiers within Error Prone first party annotations switch to using the modifier = version.
I think it might be worth testing if that would be enough to prevent the compiler from trying to complete e.g. Modifier.FINAL when analyzing @Var, or if just the act of trying to load @IncompatibleModifiers will surface the same problem.
I might do a quick internal experiment on this. If that works, we might even be fine with value() lingering there forever for third-party Error Prone users (although I imagine everyone will be happier if there is a path to having a single way of doing things there eventually, anyways).
I understand this is not super high priority on your end, but would you guys consider a PR implementing the solution you detailed above if that fixed the issue for us?

Given that, my current thinking as to internal workarounds has evolved to favor forking error_prone_annotations and either doing my proposed patch or just removing the definition and usages of @IncompatibleModifiers, since what we really want to use is @Var and other annotations that use @IncompatibleModifiers as a meta-annotation.

That makes sense to me in the short term, FWIW

We are currently doing this, and it does mitigate the problem for us. But we'd love to be able to go back to not forking any part of Error Prone and just being on mainline! (Plus, I suspect we aren't the only ones using EP for Android outside of Google...)

I'm just curious if you have opinions about the rate of breaking changes in the API, we don't get a lot of feedback on that generally.

So, this is separate from the issue at hand, but, since you ask...
We did run into an issue recently where to get NullAway to work with Error Prone 2.5.1, we had to drop compatibility with 2.3.x (https://github.com/uber/NullAway/pull/447). So far, that hasn't been too painful a decision, to be honest. Internally, we are currently on Error Prone 2.4.0. Would have been more complicated if we were lagging further behind, though, and we might yet hear of some NullAway third-party user who has issues upgrading to 0.9.0 because of it.
As for why we aren't on 2.5.1 yet, we build massive monorepos with -Werror, so EP upgrades are unsurprisingly painful :)
However, the main reasons are usually not any changes to core or the APIs (we modify our own checkers to match whichever EP version we are on and that's often <1hr for all of them at worst), or new checkers being introduced (we can always set them to :OFF on the initial code change and then enable them independently).
The true upgrade pain points for us are:
a) dependency changes where upgrading Error Prone can easily involve a cascading upgrade of core deps for us (e.g. Guava), and
b) existing checkers that have been updated to be more precise.
The later is often a trade-off between adding a dozen to a few hundred suppressions or setting to :OFF a checker which we were running before (albeit possibly in a less comprehensive version). For 2.4.0, the javadoc checkers were notorious for us here.
The first issue, (a), just seems like a fact of life to me. Not sure (b) has an easy solution either, but at least in theory could be avoided if big changes to checkers resulted to checkers or in a world where you could say something like -Xep:MissingSummary:WARN:3.3.4 while keeping all other checkers on 2.4.0 by default and upgrading that one as a follow up 😉
We can simulate the later by forking a checker internally and renaming, but this is rarely worth it as an intermediate/mitigation step.
Just to be clear, though, I am not asking you to address any of this stuff. I am more concerned by the original issue. But you asked for feedback on breaking changes and EP versions, hence the brain-dump.

FYI - R8 gives much more detailed warnings about this in AGP 7.0+
> Task :sample:minifyExternalStagingAndroidTestWithR8
WARNING:Missing classes detected while running R8. Please add the missing classes or apply additional keep rules that are generated in /Users/zsweers/dev/slack/keeper/sample/build/outputs/mapping/externalStagingAndroidTest/missing_rules.txt.

WARNING:R8: Missing class androidx.annotation.experimental.Experimental$Level (referenced from: androidx.test.services.storage.ExperimentalTestStorage)
Missing class androidx.annotation.experimental.Experimental (referenced from: androidx.test.services.storage.ExperimentalTestStorage)
Missing class java.awt.Dimension (referenced from: int org.checkerframework.checker.signedness.SignednessUtilExtra.dimensionUnsignedHeight(java.awt.Dimension) and 1 other context)
Missing class java.awt.image.BufferedImage (referenced from: int[] org.checkerframework.checker.signedness.SignednessUtilExtra.getUnsignedRGB(java.awt.image.BufferedImage, int, int, int, int, int[], int, int) and 1 other context)
Missing class javax.lang.model.element.Modifier (referenced from: javax.lang.model.element.Modifier[] com.google.errorprone.annotations.IncompatibleModifiers.value() and 4 other contexts)

I went ahead and deprecated {Required,Incompatible}Modifiers.value, and migrated uses within core Error Prone to a new modifier enum in 26f1f5498321c9e2c25f5546dc9aa026affde16a. I hope to remove the deprecated attributes eventually, but hopefully there's no rush for that.

Really appreciated, I think with this, we should be able to stop forking the annotations artifact after the next EP release! (We shouldn't really care about the deprecated API so long as it's not being used within EP itself)


Repair docker setup / upgrade

Docker does not provide the prebuild docker binaries (1.11.2). Instead a tarball containing a directory 'docker' containing the docker binary with executable bit already set is provided.

thanks a lot @martinhoefling for this one, that missing docker binary was on my ASAP list.
i will test PR tomorrow and cut new version then.

@martinhoefling could you replace curl -o ~/kube-solo/bin/docker https://get.docker.com/builds/Darwin/x86_64/docker-$DOCKER_VERSION.tgz to curl -O https://get.docker.com/builds/Darwin/x86_64/docker-$DOCKER_VERSION.tgz?
as there is not .tgz downloaded.
thanks

no worries, fixed it myself


Correct hex lattice and implement hex u-matrix

Hi there! First of all thank you for developing SOMPY! I have been using SOMPY for some time now and one of the features I think it's missing is the hexagonal grid for the u-matrix plot so I decided to implement it myself and share it here. Let me know of what you think and if this is a feature you want to add to the package or not. Also, I am planning to build an interactive u-matrix visualization in the future with Bokeh, let me know if you would be interested in adding it to the package.

Changed generate_hex_lattice() from sompy/codebook.py such as the
coordinates correspond to a regular hexagon grid (which wasn't the
case previously).
Changed sompy/visualization/umatrix.py such that if the som object has
a hexagonal lattice, then the u-matrix is plotted on a hexagonal grid.
All additional plot features (e.g. contour, blob, etc.) are compatible
with the hexagonal grid. Also added colorbar to the plot.

Sorry for my late reply @DavidSilva98
Thanks for the contribution to add the hexagrid U-matrix.
I think the idea of adding interactive plots could be a bit out of the scope of this library.
Besides, personally not fan of Bokeh. What are you thoughts on building a simple pipeline from data upload, SOM training and interactive visualization using something like Streamlit. This workflow as a web application where users can upload the data and train the SOM and then having a simple interface with Streamlit can give a lot of options for different visualizations.

Hi @sevamoo. Thanks for merging the PR. I have worked on a project where we did something very similar using SOMPY, Bokeh, and Streamlit. We deployed an older version of the project at https://mapintel.herokuapp.com/. There's also a data upload pipeline but it is very simple. Let me know if this is something of your interest.

@DavidSilva98  Great! Yes, I meant something like your project, but perhaps with a bit more generic workflow, that a user can upload a CSV file with arbitrary columns. Something like most AutoML interfaces.
If you are willing to opensource your project, it would be really awesome to refer to it in SOMPY repo.
Best
Vahid


Offensive and Harmful Content Filter and Redirection to HR

Please provide us with the following information:

This issue is for a: (mark with an x)
- [ ] bug report -> please search issues before submitting
- [ x ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

In order to handle offensive and self-destructive language and redirect it to HR, is there a way to create custom responses to hateful, offensive and self-destructive questions, other than the content filter in Azure OpenAI?

Expected/desired behavior

In the context of internal enterprise assistant, create custom responses when harmful and offensive language is used and redirect to HR (could be hardcoded message) instead of an error or generic response as the above. I tried the content filters in the Azure OpenAI studio but it just return an error when set to strict

OS and Version?

Windows 10

azd version?

run azd version and copy paste here.
NA

Versions

GPT-4-32k

Thanks! We'll be in touch soon.

Good question! Assuming you have the latest changes from main, you can start off by changing error_dict in app.py to:
def error_dict(error: Exception) -> dict:
if isinstance(error, openai.error.InvalidRequestError) and error.code == "content_filter":
return {"error": "Your message contains content that was flagged by the OpenAI content filter."}
return {"error": ERROR_MESSAGE.format(error_type=type(error))}
That caught the first example, but I need to do additional testing for the Ask tab and your second example, which likely requires parsing out the content safety results.

I sent a PR in https://github.com/Azure-Samples/azure-search-openai-demo/pull/896

Thank you @pamelafox for the update. However, the intended behavior is to have adaptive responses based on the question (chat) and then depending the emotion/sentiment of the question either close the session (too offensive and hateful) or generate adequate GPT-like answer if the user needs help such as in the case of suicidal thoughts.
Not sure if the intended behavior is clear! but the idea is to add some level intelligence into the answers to the mentioned types of questions


How many and what model of GPUs were used during the training of the HP model?

It feels like training once with my single 3080ti needs a month.

Hello,
When training the ViT-S/8 model on the COCO-stuff27 dataset, it takes approximately a day with a single RTX A6000 GPU. For other models, the time required is significantly less than this.
Thank you.


Placeholder package config reader.

So we can identify macros based on pubspecs while we wait for that to be implemented properly.
Not used yet as that would overlap with other pending PRs, but it should be easy to plug in afterwards.

Thanks!
Comments addressed, and I added another commit that actually uses the new code, PTAL.

Rebasing on top of the CFE PR it turns out the package config class has exactly what I need to remove the hack over there, resolving file:// URIs based on package config. So, updated to add that and also work for the CFE :) PTAL.


Hangs on "Configuring using the "MinGW Makefiles" CMake generator"

Hi,
I am trying to settup a CMake project under VS Code thanks to your extension, but it seems to hang.
At startup I have the following log:
Starting CMake Tools backend
[C:\Users\oooo\Documents\Projets\Tools\cmake-3.10.0-rc5-win64-x64\bin\cmake.exe output]: cmake version 3.10.0-rc5
[C:\Users\oooo\Documents\Projets\Tools\cmake-3.10.0-rc5-win64-x64\bin\cmake.exe output]:
[C:\Users\oooo\Documents\Projets\Tools\cmake-3.10.0-rc5-win64-x64\bin\cmake.exe output]: CMake suite maintained and supported by Kitware (kitware.com/cmake).
C:\Users\oooo\Documents\Projets\Tools\cmake-3.10.0-rc5-win64-x64\bin\cmake.exe exited with return code 0
Loading CMake Tools from c:\Users\oooo\Documents\Projets\Tools\test-cmake-mig\.vscode\.cmaketools.json
VSWhere is not installed. Not searching for VS 2017
Detected available environment "MinGW - C:\MinGW
Started new CMake Server instance with PID 5148
Trying to detect generator supported by system
[vscode] Configuring using the "MinGW Makefiles" CMake generator

Then it stops, I cannot do things like "CMake: configure", nothing happens.
Following is the log from "Developer tools" with two unexpected exception, I do not now if it is relevant.
Thank you for your help !
Oliv'
console.ts:123 [Extension Host] Starting CMake Tools backend
console.ts:123 [Extension Host] [C:\Users\oooo\Documents\Projets\Tools\cmake-3.10.0-rc5-win64-x64\bin\cmake.exe output]: cmake version 3.10.0-rc5
console.ts:123 [Extension Host] [C:\Users\oooo\Documents\Projets\Tools\cmake-3.10.0-rc5-win64-x64\bin\cmake.exe output]:
console.ts:123 [Extension Host] [C:\Users\oooo\Documents\Projets\Tools\cmake-3.10.0-rc5-win64-x64\bin\cmake.exe output]: CMake suite maintained and supported by Kitware (kitware.com/cmake).
console.ts:123 [Extension Host] C:\Users\oooo\Documents\Projets\Tools\cmake-3.10.0-rc5-win64-x64\bin\cmake.exe exited with return code 0
console.ts:123 [Extension Host] Loading environments
console.ts:123 [Extension Host] Loading CMake Tools from c:\Users\oooo\Documents\Projets\Tools\test-cmake-mig\.vscode\.cmaketools.json
console.ts:123 [Extension Host] VSWhere is not installed. Not searching for VS 2017
console.ts:123 [Extension Host] Environments loaded
console.ts:123 [Extension Host] Detected available environment "MinGW - C:\MinGW
console.ts:123 [Extension Host] Started new CMake Server instance with PID 4784
console.ts:123 [Extension Host] rejected promise not handled within 1 second
t.log @ console.ts:123
shell.ts:459 [vector-of-bool.cmake-tools] Invalid backend promise: Error: Invalid backend promise
	at new CMakeToolsWrapper (C:\Users\oooo\.vscode\extensions\vector-of-bool.cmake-tools-0.10.3\out\src\wrapper.js:46:40)
	at C:\Users\oooo\.vscode\extensions\vector-of-bool.cmake-tools-0.10.3\out\src\extension.js:17:23
	at Generator.next (<anonymous>)
	at C:\Users\oooo\.vscode\extensions\vector-of-bool.cmake-tools-0.10.3\out\src\extension.js:7:65
	at Promise (<anonymous>)
	at __awaiter (C:\Users\oooo\.vscode\extensions\vector-of-bool.cmake-tools-0.10.3\out\src\extension.js:3:12)
	at activate (C:\Users\oooo\.vscode\extensions\vector-of-bool.cmake-tools-0.10.3\out\src\extension.js:15:12)
	at Function.t._callActivateOptional (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:4:505706)
	at Function.t._callActivate (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:4:505451)
	at c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\node\extensionHostProcess.js:4:504804
e.onUnexpectedError @ shell.ts:459
console.ts:123 [Extension Host] Received message from cmake-server:
{"supportedProtocolVersions":[{"isExperimental":true,"major":1,"minor":1}],"type":"hello"}

console.ts:123 [Extension Host] Trying to detect generator supported by system
console.ts:123 [Extension Host] [vscode] Configuring using the "MinGW Makefiles" CMake generator
console.ts:123 [Extension Host] Sending message to cmake-server: {"type":"handshake","buildDirectory":"c:/users/oooo/documents/projets/tools/test-cmake-mig/build","protocolVersion":{"isExperimental":true,"major":1,"minor":1},"sourceDirectory":"c:/users/oooo/documents/projets/tools/test-cmake-mig","generator":"MinGW Makefiles","cookie":"0.9213053386548808"}
console.ts:123 [Extension Host] Received message from cmake-server:
{"cookie":"0.9213053386548808","inReplyTo":"handshake","type":"reply"}

console.ts:123 [Extension Host] Sending message to cmake-server: {"type":"globalSettings","cookie":"0.9378025195711566"}
console.ts:123 [Extension Host] Received message from cmake-server:
{"buildDirectory":"c:/users/oooo/documents/projets/tools/test-cmake-mig/build","capabilities":{"generators":[{"extraGenerators":["CodeBlocks","CodeLite","Sublime Text 2","Kate","Eclipse CDT4"],"name":"Ninja","platformSupport":false,"toolsetSupport":false},{"extraGenerators":[],"name":"Visual Studio 15 2017","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 15 2017 ARM","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 12 2013","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Borland Makefiles","platformSupport":false,"toolsetSupport":false},{"extraGenerators":[],"name":"Visual Studio 15 2017 Win64","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 9 2008","platformSupport":true,"toolsetSupport":false},{"extraGenerators":[],"name":"Visual Studio 12 2013 Win64","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 10 2010 Win64","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 12 2013 ARM","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 14 2015","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 11 2012 ARM","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 14 2015 ARM","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 14 2015 Win64","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 11 2012","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 9 2008 Win64","platformSupport":true,"toolsetSupport":false},{"extraGenerators":[],"name":"Visual Studio 11 2012 Win64","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 10 2010","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 10 2010 IA64","platformSupport":true,"toolsetSupport":true},{"extraGenerators":[],"name":"Visual Studio 9 2008 IA64","platformSupport":true,"toolsetSupport":false},{"extraGenerators":[],"name":"Visual Studio 8 2005","platformSupport":true,"toolsetSupport":false},{"extraGenerators":[],"name":"MSYS Makefiles","platformSupport":false,"toolsetSupport":false},{"extraGenerators":[],"name":"Visual Studio 8 2005 Win64","platformSupport":true,"toolsetSupport":false},{"extraGenerators":["CodeBlocks","CodeLite","Sublime Text 2","Kate","Eclipse CDT4"],"name":"NMake Makefiles","platformSupport":false,"toolsetSupport":false},{"extraGenerators":[],"name":"Watcom WMake","platformSupport":false,"toolsetSupport":false},{"extraGenerators":["CodeBlocks"],"name":"NMake Makefiles JOM","platformSupport":false,"toolsetSupport":false},{"extraGenerators":[],"name":"Green Hills MULTI","platformSupport":false,"toolsetSupport":false},{"extraGenerators":["CodeBlocks","CodeLite","Sublime Text 2","Kate","Eclipse CDT4"],"name":"MinGW Makefiles","platformSupport":false,"toolsetSupport":false},{"extraGenerators":["CodeBlocks","CodeLite","Sublime Text 2","Kate","Eclipse CDT4"],"name":"Unix Makefiles","platformSupport":false,"toolsetSupport":false}],"serverMode":true,"version":{"isDirty":false,"major":3,"minor":10,"patch":0,"string":"3.10.0-rc5","suffix":"rc5"}},"checkSystemVars":false,"cookie":"0.9378025195711566","debugOutput":false,"extraGenerator":"","generator":"MinGW Makefiles","inReplyTo":"globalSettings","sourceDirectory":"c:/users/oooo/documents/projets/tools/test-cmake-mig","trace":false,"traceExpand":false,"type":"reply","warnUninitialized":false,"warnUnused":false,"warnUnusedCli":true}

console.ts:123 [Extension Host] Sending message to cmake-server: {"type":"cache","cookie":"0.513476075508333"}
console.ts:123 [Extension Host] Sending message to cmake-server: {"type":"codemodel","cookie":"0.35857727376603754"}
console.ts:123 [Extension Host] Received message from cmake-server:
{"cookie":"","errorMessage":"Failed to parse JSON input.","inReplyTo":"","type":"error"}

shell.ts:459 [vector-of-bool.cmake-tools] Invalid cookie: : Error: Invalid cookie:
	at CMakeServerClient._takePromiseForCookie (C:\Users\oooo\.vscode\extensions\vector-of-bool.cmake-tools-0.10.3\out\src\server-client.js:112:19)
	at CMakeServerClient._onMessage (C:\Users\oooo\.vscode\extensions\vector-of-bool.cmake-tools-0.10.3\out\src\server-client.js:128:26)
	at CMakeServerClient._onMoreData (C:\Users\oooo\.vscode\extensions\vector-of-bool.cmake-tools-0.10.3\out\src\server-client.js:105:18)
	at emitOne (events.js:96:13)
	at Socket.emit (events.js:191:7)
	at readableAddChunk (_stream_readable.js:178:18)
	at Socket.Readable.push (_stream_readable.js:136:10)
	at Pipe.onread (net.js:560:20)
e.onUnexpectedError @ shell.ts:459

Looks like it might be related to #237.

A downgrade from CMake 3.10-rc-5 to 3.8 seems to solve it, I will try with 3.9
I don't know if you want to close the issue as the plugin does not seems to be able to handle the error

Looks to be the same #258. This must be a problem with CMake 3.10

Closing this and moving to the other issue.

Should all work in the 3.10 release.