fix #7315 redundant box for boolean and refactor method filterInvoker

#7315
What is the purpose of the change
unboxing boolean and refactor method filterInvoker
Brief changelog
1.org.apache.dubbo.rpc.cluster.router.tag.TagRouter#isForceUseTag
Boolean.valueOf -> Boolean.parseBoolean
2.org.apache.dubbo.rpc.cluster.router.tag.TagRouter#filterInvoker
refactor in stream
3.org.apache.dubbo.rpc.cluster.router.tag.TagRouter#filterUsingStaticTag
remove param(result) initial  value
Verifying this change
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[x] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #7316 (9eca39b) into master (fcc6298) will decrease coverage by 0.05%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master    #7316      +/-   ##
============================================
- Coverage     59.06%   59.00%   -0.06%
+ Complexity      462      460       -2
============================================
  Files          1044     1044
  Lines         42473    42466       -7
  Branches       6228     6224       -4
============================================
- Hits          25085    25056      -29
- Misses        14588    14600      +12
- Partials       2800     2810      +10

Impacted Files
Coverage Δ
Complexity Δ

...apache/dubbo/rpc/cluster/router/tag/TagRouter.java
32.25% <0.00%> (-1.75%)
0.00 <0.00> (ø)

...va/org/apache/dubbo/remoting/TimeoutException.java
22.22% <0.00%> (-11.12%)
0.00% <0.00%> (ø%)

.../apache/dubbo/rpc/protocol/AsyncToSyncInvoker.java
62.06% <0.00%> (-10.35%)
0.00% <0.00%> (ø%)

...dubbo/remoting/exchange/support/DefaultFuture.java
78.63% <0.00%> (-9.41%)
0.00% <0.00%> (ø%)

...e/dubbo/remoting/transport/netty/NettyChannel.java
52.27% <0.00%> (-7.96%)
19.00% <0.00%> (-2.00%)

...he/dubbo/common/threadpool/ThreadlessExecutor.java
94.23% <0.00%> (-1.93%)
0.00% <0.00%> (ø%)

...a/org/apache/dubbo/monitor/dubbo/DubboMonitor.java
86.66% <0.00%> (-1.91%)
16.00% <0.00%> (ø%)

...pache/dubbo/registry/support/AbstractRegistry.java
79.62% <0.00%> (-1.49%)
0.00% <0.00%> (ø%)

...rg/apache/dubbo/common/timer/HashedWheelTimer.java
79.38% <0.00%> (-0.35%)
0.00% <0.00%> (ø%)

...apache/dubbo/common/extension/ExtensionLoader.java
78.29% <0.00%> (+0.22%)
0.00% <0.00%> (ø%)

... and 2 more

Continue to review full report at Codecov.

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

LGTM.


NetSock_Accept may release globalLock but not Acquire it

In function NetSock_Accept()，when check Validate initial addr len (line:4554-4588) error, the function
exit with Net_GlobalLockRelease() from label exit_err_acccept，but the function did not call Net_GlobalLockAcquire() before.

Thanks, jameszxj
This yields no functional issues but it will be addressed.

Duplicate of https://github.com/weston-embedded/uC-TCP-IP/issues/13


Implement flush system

Storage Flushing
Currently higher level abstractions that operate on the contract storage like SyncCell, SyncChunk as well as storage::Vec and storage::HashMap have an image of the storage in memory and keep the storage in sync for every write operation. So the image that is kept in memory is only utilized for read operations.
Rational
The current system of only using the cached storage image is to allow for external contract executions. Executing an external contract means to switch context which in fact requires the currently executing contract to write back any storage modifications. That's why it is important to keep the storage always in sync with the memory but not vice versa.
Other Work
Fleetwood has similar problems and also keeps a storage image in memory.
However, in Fleetwood write operations do not directly write back to storage every time.
Instead there is a flush operation to do the job collectively.
The advantage is that this allows to avoid even more storage accesses.
The obvious downside is that this interferes with external contract execution since flushing of contract storage has to be coordinated then which is currently missing from Fleetwood.
Combining Approaches
To restate our goals:

We want to avoid as many storage accesses as possible.
We want to be able to call external contract during contract execution.

To achieve this we should implement a flushing system in pDSL as well.
However, we have to link it to the system used to call external contracts somehow.
This could be done by including the external-contract-call system into the environment.
Ideas are welcome!

This can be closed since it has been implemented and seem to be stable.


Fix the footer in Contact and Login page

The footer in Contact page is overlapping with the content and there's extra space below the footer in Login page.

Hey @nilisha-jais, can I work on this issue under LGM-SOC??

I want to work on this issue

/assign

@MukulKolpe commented first so he should get a chance to work. You can take any other issue @gunjan-g

@MukulKolpe commented first so he should get a chance to work. You can take any other issue @gunjan-g

yes ok


Add Missing Type Annotations

resolves #11
submitted for review / comment

added guard statement for typing, Union and created Union of Fourwire and I2CDisplay


Remove cursor declaration from Badge component

The user-select declaration is sufficient to remove the cursor styling when you hover the Badge component. Declaring cursor: default explicitly actually overrides the inherited styling when the Badge is placed inside a Button for example, which is not desired.

Fixed in v0.6.6


"pip install secp256k1" fails in python 3.7 venv on FreeBSD

Attempting to do "pip install secp256k1" in a venv on FreeBSD fails with the following error:
(jmvenv) [root@bitcoin /usr/local/bin/joinmarket]# pip install secp256k1
Collecting secp256k1
  Downloading secp256k1-0.13.2.tar.gz (156 kB)
     |████████████████████████████████| 156 kB 3.0 MB/s
Requirement already satisfied: cffi>=1.3.0 in ./jmvenv/lib/python3.7/site-packages (from secp256k1) (1.14.3)
Requirement already satisfied: pycparser in ./jmvenv/lib/python3.7/site-packages (from cffi>=1.3.0->secp256k1) (2.20)
Building wheels for collected packages: secp256k1
  Building wheel for secp256k1 (setup.py) ... error
  ERROR: Command errored out with exit status 1:
   command: /usr/local/bin/joinmarket/jmvenv/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-fk74tgtp/secp256k1/setup.py'"'"'; __file__='"'"'/tmp/pip-install-fk74tgtp/secp256k1/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-dz3qd2p7
       cwd: /tmp/pip-install-fk74tgtp/secp256k1/
  Complete output (24 lines):
  1.7.3
  Installed libsecp256k1 is unusable falling back to bundled version.
  Using bundled libsecp256k1
  running bdist_wheel
  The [wheel] section is deprecated. Use [bdist_wheel] instead.
  running build
  running build_py
  creating build
  creating build/lib.freebsd-12.1-RELEASE-amd64-3.7
  creating build/lib.freebsd-12.1-RELEASE-amd64-3.7/secp256k1
  copying secp256k1/__init__.py -> build/lib.freebsd-12.1-RELEASE-amd64-3.7/secp256k1
  copying secp256k1/__main__.py -> build/lib.freebsd-12.1-RELEASE-amd64-3.7/secp256k1
  running build_ext
  generating cffi module 'build/temp.freebsd-12.1-RELEASE-amd64-3.7/_libsecp256k1.c'
  creating build/temp.freebsd-12.1-RELEASE-amd64-3.7
  building '_libsecp256k1' extension
  creating build/temp.freebsd-12.1-RELEASE-amd64-3.7/build
  creating build/temp.freebsd-12.1-RELEASE-amd64-3.7/build/temp.freebsd-12.1-RELEASE-amd64-3.7
  cc -pthread -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -fPIC -I/usr/local/include/python3.7m -c build/temp.freebsd-12.1-RELEASE-amd64-3.7/_libsecp256k1.c -o build/temp.freebsd-12.1-RELEASE-amd64-3.7/build/temp.freebsd-12.1-RELEASE-amd64-3.7/_libsecp256k1.o
  build/temp.freebsd-12.1-RELEASE-amd64-3.7/_libsecp256k1.c:569:10: fatal error: 'secp256k1.h' file not found
  #include <secp256k1.h>
           ^~~~~~~~~~~~~
  1 error generated.
  error: command 'cc' failed with exit status 1
  ----------------------------------------
  ERROR: Failed building wheel for secp256k1Running setup.py clean for secp256k1
Failed to build secp256k1
Installing collected packages: secp256k1
    Running setup.py install for secp256k1 ... error
    ERROR: Command errored out with exit status 1:
     command: /usr/local/bin/joinmarket/jmvenv/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-fk74tgtp/secp256k1/setup.py'"'"'; __file__='"'"'/tmp/pip-install-fk74tgtp/secp256k1/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record /tmp/pip-record-dkf9tr57/install-record.txt --single-version-externally-managed --compile --install-headers /usr/local/bin/joinmarket/jmvenv/include/site/python3.7/secp256k1
         cwd: /tmp/pip-install-fk74tgtp/secp256k1/
    Complete output (23 lines):
    1.7.3
    Installed libsecp256k1 is unusable falling back to bundled version.
    Using bundled libsecp256k1
    running install
    running build
    running build_py
    creating build
    creating build/lib.freebsd-12.1-RELEASE-amd64-3.7
    creating build/lib.freebsd-12.1-RELEASE-amd64-3.7/secp256k1
    copying secp256k1/__init__.py -> build/lib.freebsd-12.1-RELEASE-amd64-3.7/secp256k1
    copying secp256k1/__main__.py -> build/lib.freebsd-12.1-RELEASE-amd64-3.7/secp256k1
    running build_ext
    generating cffi module 'build/temp.freebsd-12.1-RELEASE-amd64-3.7/_libsecp256k1.c'
    creating build/temp.freebsd-12.1-RELEASE-amd64-3.7
    building '_libsecp256k1' extension
    creating build/temp.freebsd-12.1-RELEASE-amd64-3.7/build
    creating build/temp.freebsd-12.1-RELEASE-amd64-3.7/build/temp.freebsd-12.1-RELEASE-amd64-3.7
    cc -pthread -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -fPIC -I/usr/local/include/python3.7m -c build/temp.freebsd-12.1-RELEASE-amd64-3.7/_libsecp256k1.c -o build/temp.freebsd-12.1-RELEASE-amd64-3.7/build/temp.freebsd-12.1-RELEASE-amd64-3.7/_libsecp256k1.o
    build/temp.freebsd-12.1-RELEASE-amd64-3.7/_libsecp256k1.c:569:10: fatal error: 'secp256k1.h' file not found
    #include <secp256k1.h>
             ^~~~~~~~~~~~~
    1 error generated.
    error: command 'cc' failed with exit status 1
    ----------------------------------------
ERROR: Command errored out with exit status 1: /usr/local/bin/joinmarket/jmvenv/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-fk74tgtp/secp256k1/setup.py'"'"'; __file__='"'"'/tmp/pip-install-fk74tgtp/secp256k1/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record /tmp/pip-record-dkf9tr57/install-record.txt --single-version-externally-managed --compile --install-headers /usr/local/bin/joinmarket/jmvenv/include/site/python3.7/secp256k1 Check the logs for full command output.

Related issue https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/668

Apparently this library has been replaced with coincurve which to my understand has nothing to do with this


Update move_to_spark_2.sh

Fix adam-parent_2.11 SNAPSHOT version
In maven repository, adam-parent-spark2_2.11 is available only in version 0.20.0 and not in version 0.20.1 as coded in the pom.xml
Link:
https://mvnrepository.com/artifact/org.bdgenomics.adam/adam-parent-spark2_2.11

Can one of the admins verify this patch?

@creggian Version 0.20.1 hasn't been released for any artifacts yet
https://mvnrepository.com/artifact/org.bdgenomics.adam/adam-parent_2.10
https://mvnrepository.com/artifact/org.bdgenomics.adam/adam-parent_2.11
https://mvnrepository.com/artifact/org.bdgenomics.adam/adam-parent-spark2_2.10
https://mvnrepository.com/artifact/org.bdgenomics.adam/adam-parent-spark2_2.11
Perhaps I'm missing the issue here?

Thank you very much for opening the issue, and the patch @creggian! I will take a look over the patch today.

Perhaps I'm missing the issue here?

@heuermh This PR addresses SNAPSHOTs, not pushed releases:
https://oss.sonatype.org/content/repositories/snapshots/org/bdgenomics/adam/

In the default pom.xml, adam-parent-spark2_2.11 version is set to  "0.20.1" (line 13). I was not able to install ADAM (git clone & mvn clean package -DskipTests), because maven is not able to retrieve 0.20.1 version of the package from the onlire repository. The only version available is 0.20.0, as you can see form the link provided. So I changed version to 0.20.0 so to successfully install it.
*https://mvnrepository.com/artifact/org.bdgenomics.adam/adam-parent-spark2_2.11
Given the links you provided, version 0.20.1 is not provided in any of the artifacts, so there is actually a better fix. Update pom.xml instead of scripts/move_to_spark_2.sh.
I'll make another pull request with the updated pom.xml, and you can close/reject this one

The version in spark2 SNAPSHOT poms is fine
https://oss.sonatype.org/content/repositories/snapshots/org/bdgenomics/adam/adam-parent-spark2_2.11/0.20.1-SNAPSHOT/adam-parent-spark2_2.11-0.20.1-20161210.021239-152.pom
There are no spark2_2.10 versions however.

Er, actually, I see what you're saying @heuermh. @creggian are you looking for the 0.20.1-SNAPSHOT artifacts, or a 0.20.1 release? To @heuermh's point, we haven't made a 0.20.1 release yet. We are working on a 0.21.0 release which should drop very soon. If you want the latest SNAPSHOT artifacts (i.e., adam version = 0.20.1-SNAPSHOT), you'll need to tell Maven to look at the oss.sonatype.org snapshot repository. You can do this by adding the following configuration to your pom.xml:
  <repositories>
    <repository>
      <id>Sonatype</id>
      <url>http://oss.sonatype.org/content/repositories/snapshots/</url>
    </repository>
  </repositories>

There are no spark2_2.10 versions however.

Yeah, I was just noticing that...

@creggian Sorry, are you saying if you
$ git clone https://github.com/bigdatagenomics/adam.git
$ cd adam
$ ./scripts/move_to_spark_2.sh
$ mvn install

the build complains about missing version 0.20.1 dependencies?  If so maybe something is wrong with the move_to_spark_2.sh script.  In any case, that script shouldn't change the artifact version.

@fnothaft, I was discussing 0.20.1-SNAPSHOT.
By the way, I'm not able to reproduce the error. With
$ git clone https://github.com/bigdatagenomics/adam.git
$ cd adam
$ ./scripts/move_to_spark_2.sh
$ export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=256m"
$ mvn clean package -DskipTests

and
$ git clone https://github.com/bigdatagenomics/adam.git
$ cd adam
$ ./scripts/move_to_spark_2.sh
$ ./scripts/move_to_scala_2.11.sh
$ export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=256m"
$ mvn clean package -DskipTests

the build is successful in both cases.
So, sorry for the pull request, it is not meaningful anymore

No problem!  Thank you for looking into this.
We find the rewriting pom files in place rather sketchy, but couldn't come up with a better alternative.  If interested, you might be able to find a thread on spark-dev@ from last summer.

I have an alternative in my SBT fork / using hammerlab/sbt-parent, where you use -Dspark1 to build against Spark 1.x (default builds against Spark 2.x):
sbt +publishSigned sonatypeRelease           // release {Spark 2.x} ⅹ {2.10,2.11} artifacts.
sbt -Dspark1 +publishSigned sonatypeRelease  // release {Spark 1.x} ⅹ {2.10,2.11} artifacts.

Hopefully I'll have that in evangelization-worthy shape soon.


Model.near broken in 1.4.1

I ran into a regression in 1.4.1 in calls to Model.near.
The following used to work:
Airport.near(some_object, 200).limit(20)
This results in the following query on 1.4.0:
SELECT  airport.*, 6371.0 * 2 * ASIN(SQRT(POWER(SIN((36.623276500595736 - airport.latitude) * PI() / 180 / 2), 2) + COS(36.623276500595736 * PI() / 180) * COS(airport.latitude * PI() / 180) * POWER(SIN((-4.494958519935608 - airport.longitude) * PI() / 180 / 2), 2))) AS distance, MOD(CAST((ATAN2( ((airport.longitude - -4.494958519935608) / 57.2957795), ((airport.latitude - 36.623276500595736) / 57.2957795)) * 57.2957795) + 360 AS decimal), 360) AS bearing FROM airport WHERE (airport.latitude BETWEEN 34.82463328875828 AND 38.421919712433194 AND airport.longitude BETWEEN -6.736048489496704 AND -2.253868550374512 AND (6371.0 * 2 * ASIN(SQRT(POWER(SIN((36.623276500595736 - airport.latitude) * PI() / 180 / 2), 2) + COS(36.623276500595736 * PI() / 180) * COS(airport.latitude * PI() / 180) * POWER(SIN((-4.494958519935608 - airport.longitude) * PI() / 180 / 2), 2)))) BETWEEN 0.0 AND 200) ORDER BY distance ASC LIMIT 20
On 1.4.1 it does this:
SELECT  airport.*, NULL AS distance, NULL AS bearing FROM airport WHERE (false) LIMIT 20
I've reverted my project back to 1.4.0 for now. Would be great if this is fixed in 1.4.2.

I'm having a hard time reproducing this. Could you please give us some information about your environment? eg: Ruby version, Rails version, Geocoder config

I just upgraded to ruby 2.3.3 and have this problem on both geocoder 1.3.7 and 1.4.1.

Rails <IP_ADDRESS>
ruby 2.3.1p112 (2016-04-26) [x86_64-linux-gnu]
Geocoder 1.4.1 has the problem, 1.4.0 does not.
configuration:
Geocoder.configure(
language: :en,
units: :km,
lookup: :nominatim,
use_https: true
)

Had some time to take a look at it today.
Created PR #1134 to fix the issue.

Is this happening on every single request or intermittently? Does it occur when you call .near with an array of coordinates as opposed to an object? (Are you certain that the objects you're passing to the method have both latitude and longitude values?)

Have the same problem when switching from 1.4.0 to 1.4.1
ruby 2.1.2
activerecord <IP_ADDRESS>
pg 0.19.0
Sample request:
model.near(lat, lot, radius, :units => :km)

Not sure if this is working with the latest version of Rails....I am getting a Fixnum error
Model.near([params[:lat], params[:lon]], 15).limit(30)
ArgumentError: Unsupported argument type: 0 (Fixnum)
from /home/hounddog/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/activerecord-5.0.1/lib/active_record/relation/where_clause_factory.rb:27:i
n `build'

@markmcdonald51 can you please copy/paste the full backtrace as well as the exact line of code that's causing the problem? And is this happening on every single request or intermittently?

I'm seeing the same problem—geocoder 1.4.1, no results returned on .near when there should be, and the generated SQL is
SELECT  markets.*, NULL AS distance, NULL AS bearing FROM markets WHERE markets.dormant = 0 AND markets.dps = 1 AND (false) LIMIT 5
from
@nearby = Market.where(dormant: false, dps: true).near([latitude, longitude], 75).limit(5)
Removing the .where call removes the WHERE clause but otherwise generates the same, non-working, SQL call.
I'm running under Ruby 2.4.0 and Rails 5.0.1.

@TrangPham Any luck reproducing this? Or any theories on what's going on here?

I can confirm that on Ruby 2.3.2 and Rails 5.0.1 downgrading from 1.4.1 to 1.4.0 of geocoder resolves the issue.
For me, something as simple as failed:
Address.near([lat, lng], 20).to_sql
# => SELECT * FROM address WHERE (false)

Here are the two commits which I think could have affected this from 1.4.0 to 1.4.1:
https://github.com/alexreisner/geocoder/commit/1c306367588f61b418a0f41f049f73cfd9f94897 OR https://github.com/alexreisner/geocoder/commit/e0ad6c4286f3f7d5ff1707ef1a80f66a59a65b42
Of which I think the second one is more likely to have caused this. Though there are unit tests for these and the unit tests continue to pass...
What I think might be happening is either full_distance in Geocoder::Sql is not being called, therefore returning NULL for that part of the query, or perhaps it's failing silently and returning NULL (doubt it though?). I tired to trace the blames on the different files. And nothing changed in sql.rb or store/active_record.rb recently...

@TrangPham: I agree that those two commits are good candidates. I can't reproduce this at all, which I feel should be a clue, but I'm unsure of how to read it.
@macfanatic et al: Could anyone who's experiencing this problem please try installing from the fix-1130 branch and see if that fixes the problem? Just put this in your Gemfile:
gem 'geocoder', github: "alexreisner/geocoder", branch: "fix-1130"

@alexreisner Using your referenced branch seems to fix the problem, as in I saw no change and are tests still pass (which failed on 1.4.1).

@alexreisner  I can also confirm that the referenced branch resolves the issue for me—Model.near works as expected.

@macfanatic , @kbroderick Thank you!
@TrangPham It looks like 1c30636 was the issue, though I can't say I fully understand why. I guessed that commit because it modifies coordinates_present? which, if returning false incorrectly, could cause the problems that were reported. But I don't understand the kind of inputs that would cause it to return false unexpectedly. Would be good to find them and add a test to prevent this from happening in the future, since it's obviously quite subtle.
New gem release coming shortly.

@alexreisner if it helps, the method where I was seeing the issue starts off pretty simply:
latitude = params[:latitude]
longitude = params[:longitude]

@nearby = Market.where(dormant: false, dps: true).near([latitude, longitude], 75).limit(5)

It's called via JavaScript:
if ("geolocation" in navigator) {
    navigator.geolocation.getCurrentPosition(function(position) {
      loadNearbyMarkets(position.coords.latitude, position.coords.longitude);
    });
}

function loadNearbyMarkets(lat, long) {
    jQuery.get("/nearby_markets_html", {latitude: lat, longitude: long}, function( data ) {
        jQuery(".nearby").append(data);
        jQuery(".check_out .button").on("click", function() {
            jQuery(".other-nearby").toggle();
        });
    });
}

@kbroderick was it happening with all values or only some?

@alexreisner All that I've tried. Unfortunately, we don't have any good testing on the JavaScript side of the house, but under 1.4.1, I was told that our geolocation was not working, and on investigation (using a different set of values than those tried by either the staff member who reported it to me or the franchisee who initially noted it), I was getting an empty return set from the near query regardless of whether the provided location was within 75 miles of one of our markets or not. My testing was done using the "sensors" fake-GPS setting under Chrome, as I'm not physically located close enough to one of our markets to trigger the check.

I think I've found the issue: it occurs when the values in the coordinates array are strings instead of floats. All in this thread who have provided enough application code for me to confirm the theory are getting lat/lon values in the controller, which means they're strings.

078733d22dca783c9b3519d2475605fbb9b60a9d adds a test which fails under 1.4.1 but passes under 1.4.0 and 1.4.2.

Ah, yes our lat and lng are indeed coming from the params hash unmodified and would be strings as well.  Our controller tests were setup with string values in the params as well.

hello

Please help me

Please help me


Compare to Open AI's function calling

I'm wondering how this compares to Open AI's function calling as that's also made "to more reliably get structured data back from the model."
I see that TypeChat aimes to be model-agnostic and lets me pass in TS types.
How does the quality of the answer compare? OpenAI finetuned the models to work for function calling. Are TypeChat results as reliable? Or could it be combined?

+1 to subscribe to this thread 🧵

+1 to subscribe as well

+1 to subscribe as well

It appears to be a comprehensive open-source alternative to OpenAI's function call. I will attempt to integrate TypeChat with this repository (https://github.com/JohannLai/openai-function-calling-tools) in order to make the LLAMA 2 model function similarly to the OpenAI 0613 release.

This is a great question, and it depends on your use-cases.
First off, function calling is currently specific to OpenAI's GPT-3.5 and GPT-4 models, whereas TypeChat programs can theoretically be generated by any sufficiently powerful model (and as usual, I'll give the caveat that the best models here tend to be trained on a mix of both natural language prose and source code). As mentioned, you could use something like Llama 2 or anything else you want.
Second, as of this writing, it appears that gpt-3.5-turbo-0613 and gpt-4-0613 can only specify a single function call per response. That means that each subsequent step would require another request from the underlying model. On the other hand, with TypeChat you can typically get a single response to with each chain stepped together. Of course, the single-function-call-per-response restriction could change in the future.
Finally, there's one more key difference which is that TypeChat's program generation mechanism is both driven by types can be validated on their types. This could help ensure some level of correctness between steps which is crucial if you want to provide guardrails for the sorts of responses your models will generate. Currently TypeChat does not do this, but it could be made to do so.
All this said, the OpenAI functions seem pretty great. We'd love to see if there are good integration points that make sense!

Finally, there's one more key difference which is that TypeChat's program generation mechanism is both driven by types can be validated on their types. This could help ensure some level of correctness between steps which is crucial if you want to provide guardrails for the sorts of responses your models will generate. Currently TypeChat does not do this, but it could be made to do so.

Actually, we do validate type correctness between steps. Unless I'm misunderstanding what you're saying.

Thanks @ahejlsberg I've amended my answer!

Thanks @DanielRosenwasser @steveluc for your in-depth explanation!

Function Calling works by looking at the parameters, it doesn't care about the output of such function, meaning you must executed one by one by asking the LLM what to do next. TypeChat is very very different.
Even though you can specify something like ReturnValueSchema for each function, and the LLM would understand what that means, the number of tokens are quite less if you stick to describing your functions as part of the prompt/message rather than functions. IMO TypeChat approach to describe the API is much better.
That doesn't mean that this project should not use function calling, I think it should use function calling when supported, that way you have the guarantees that you are going to get a good json rather than parsing, or doing gymnastics to understand the response structure. Perhaps some sort of configuration to send a single function called Program that expects the steps as the string argument to be provided.

We do plan to add function as an option for cases (like coffeeshop, calendar) in which a JSON object is output as the final intent summary.  In those cases, we can posit a single function whose body conforms to the JSON type required by the schema for the application.  This can theoretically improve accuracy although we should all measure on a case by case basis because while the fine tuning works toward accuracy, the roughly 5X more tokens of the JSON schema spec works against accuracy.  And of course, a JSON schema is required.  There are npm packages that will convert TypeScript types to JSON schema or a person can author the schema.

And we agree that in the case of Program we could also do it by having a JSON schema for a single Program function with a single argument steps.  That's a lower priority because if you look at a case like music, you then have a mixture of JSON schema and TypeScript schema for the API (because a large API begins to consume many tokens if elaborated as JSON schema and you don't get the benefit of the additional TypeScript typeflow pass).

Finally, there's one more key difference which is that TypeChat's program generation mechanism is both driven by types can be validated on their types. This could help ensure some level of correctness between steps which is crucial if you want to provide guardrails for the sorts of responses your models will generate. Currently TypeChat does not do this, but it could be made to do so.

Actually, we do validate type correctness between steps. Unless I'm misunderstanding what you're saying.

Thanks for clarification, sir.

Any update on this?
I was planning to use openai functions with zod-to-json-schema and a retry mechanism passing zod validations errors to the llm, then found typechat.
Json supports enums to make sure data conforms to my expected values dynamically and not just static typing (such as a list of ids I want to constrain).
Does typechat support this?

It seems the new GPT models released yesterday support multiple function calls (also json mode and other updates).

It seems the new GPT models released yesterday support multiple function calls (also json mode and other updates).

yep.

As I understand it, the GPT function call extensions allow a request to be translated into multiple independent function calls. The function calls are not ordered and no data flows between them. So, it's not as expressive as TypeChat's JSON Programs support.
The new JSON mode ensures responses are well-formed JSON, but there is no schema validation. We haven't really had issues with non-JSON responses, but certainly it's nice to get a stronger guarantee.


feat: allow withdrawal from expired vaults

NOTE: this PR depends on https://github.com/shapeshift/lib/pull/344
commitlint will fail until that's merged
Description
this pr allows users to withdraw assets from expired vaults, #918
Notice
Before submitting a pull request, please make sure you have answered the following:

[x] Have you followed the guidelines in our Contributing guide?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[x] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
closes #918
Testing
Please outline all testing steps

Run locally
Go to your defi overview page
Find an expired vault, the fiat amount of expired vaults will be in red color
Click on the expired vault and withdraw your asset

Screenshots (if applicable)

Looks good - will await product decision on deposit vs withdraw route default before approving.


how to do illuminate while in insert mode

how to do it can illuminate while in insert mode, not only in normal mode.

Currently it can't be done. When I get a chance I can implement since it's a small change, if you want to take a stab at it it would require modifying the illuminate#on_insert_entered function to check some global setting.


CrossMedia.Current.TakeVideoAsync Returns Null on Android 13

Bug Information
Version Number of Plugin: 6.0.1-beta
Device Tested On: Samsung A7 Android 13
Simulator Tested On: Generic Tab but same specs with Samsung A7 Android 13
Version of VS: VS2022 professional 17.5.1
Version of Xamarin: Xamarin Native
Versions of other things you are using:
Steps to reproduce the Behavior
Use CrossMedia.Current.TakeVideoAsync considering the read_media_videos permission is granted by the user
Expected Behavior
It will return a value
Actual Behavior
It returns null
Code snippet
using (var file = await CrossMedia.Current.TakeVideoAsync(new StoreVideoOptions
{
Quality = VideoQuality.Medium
}))
{
if (file != null)
filePath = file.Path;
else
return;
}
Screenshots

Hello @jamesmontemagno. I hope you can check this one. Thank you so much!

This issue is fixed in 6.0.1-beta.

@dartur123 I have not any issue with 6.0.1-beta for Android 13 (Google PIxel 7 Pro)

@ArpitViradiya Do you think there's something I'm missing out why it returns null?

@dartur123 Check your permissions and run your code on main thread like this
Device.BeginInvokeOnMainThread(async () =>{ });

@dartur123 I am having the same issue. Were you able to fix it?

@Samorax I'm not able to fix it the issue on emulator but confirmed it's working on physical device.

@dartur123 Thanks.


implement lifecycle event methods

Feature Request
Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Teachability, Documentation, Adoption, Migration Strategy

https://docs.nestjs.com/fundamentals/lifecycle-events
What is the motivation / use case for changing the behavior?

This is not needed right now

This is not needed right now


avoid isOptional/isNullable

Hey, we've been trying zod-openapi out, but we hit a snag where it uses isOptional because that basically tries to sync parse undefined and throws on our schemas with async transforms.
In that issue I filed with zod I suggested looking at the schema types instead of trying to sync parse, but they may want it to be able to tell if a schema with sync transforms/sync refinements accept undefined...
So in the meantime, how would you feel about a PR to do something like this instead?
function isOptional<T extends z.ZodTypeAny(schema: T): boolean {
  if (schema instanceof z.ZodOptional || schema instanceof z.ZodUndefined /* etc... */) return true;
  if (schema instanceof z.ZodUnion) return schema.options.some(isOptional);
  if (schema instanceof z.ZodIntersection) return isOptional(schema._def.left) && isOptional(schema._def.right);
  if (schema instanceof z.ZodNullable) return isOptional(schema._def.innerType);
  if (schema instanceof z.ZodLazy) return isOptional(schema.schema);
  // etc...
}

I'd be okay with this


Fix for comments with JsonProperty attribute set for properties and fields

+1  will fix my issue.

Incorprate dthis pull request in my local repo. Maybe I am doing something wrong but it doesn't seem to work: It is somehow taking over the wrong comments
/// <summary>
///  VirtualReceipt Container
/// </summary>
public class VirtualReceiptItemContainer
{
    /// <summary>
    /// Dictionary of used Payment methods
    /// </summary>
    [Required]
    public Dictionary<int, string> PaymentMethods { get; set; }
    /// <summary>
    /// Dictionary of used Statuses
    /// </summary>
    [Required]
    public Dictionary<int, string> Statuses { get; set; }
    /// <summary>
    /// Dictionary of used Types
    /// </summary>
    [Required]
    public Dictionary<int, string> Types { get; set; }
    /// <summary>
    /// Dictionary of used CurrencyCodes
    /// </summary>
    [Required]
    public Dictionary<int, string> CurrencyCodes { get; set; }
    /// <summary>
    /// Dictionary of used ServiceTokens
    /// </summary>
    [Required]
    public Dictionary<int, string> ServiceTokens { get; set; }
    /// <summary>
    /// List of <see cref="VirtualReceiptItem"/>
    /// </summary>
    [Required]
    public List<VirtualReceiptItem> Items { get; set; }
}

public class VirtualReceiptItem
{
    /// <summary>
    /// TransactionId
    /// </summary>
    [JsonProperty(PropertyName = "e")]
    [Required]
    public string ExternalTransactionId { get; set; }
    /// <summary>
    /// Amount
    /// </summary>
    [JsonProperty(PropertyName = "a")]
    [Required]
    public int Amount { get; set; }
    /// <summary>
    /// Currency Id, Actual currency located in CurrencyCodes/>
    /// </summary>
    [JsonProperty(PropertyName = "c")]
    [Required]
    public int CurrencyCode { get; set; }
    /// <summary>
    /// PaymentMethod Id, Actual paymentMethod located in PaymentMethods/>
    /// </summary>
    [JsonProperty(PropertyName = "p")]
    [Required]
    public int PaymentMethod { get; set; }
    /// <summary>
    /// ReceiptDate, format: yyyy-MM-dd hh:mm:ss
    /// </summary>
    [Required]
    [JsonProperty(PropertyName = "r")]
    public string ReceiptDate { get; set; }
    /// <summary>
    /// ServiceToken Id, Actual servicetoken located in ServiceTokens/>
    /// </summary>
    [Required]
    [JsonProperty(PropertyName = "s")]
    public int ServiceToken { get; set; }
    /// <summary>
    /// Status Id, Actual status located in Statuses/>
    /// </summary>
    [Required]
    [JsonProperty(PropertyName = "u")]
    public int Status { get; set; }
    /// <summary>
    /// Type Id, Actual type located in Types/>
    /// </summary>
    [Required]
    [JsonProperty(PropertyName = "t")]
    public int Type { get; set; }

    public List<VirtualReceiptLineItem> Items { get; set; }
}

Is resulting in a mixed up swagger page:

This is a known issue with the existing implementation - if you look closely at the code I already have a TODO: comment highlighting the deeper issue ...
Namely, a limitation in the application of ISchemaFilter, which is perfectly highlighted by this issue.
If you consider it's interface ...
void Apply(Schema schema, SchemaRegistry schemaRegistry, Type type);

there's an immediate problem if you need to modify properties on the Schema based on a corresponding MemberInfo on the system Type. There is no reliable way to correlate the two.
I think this interface will need to be adjusted to provide some additional context that maps Type members to their corresponding schema properties. Then, the XmlComments implementation can be easily fixed. Stay tuned for the fix ...

Should be fixed in latest version (pre-release) version
Update-Package Swashbuckle -Pre

Can you please verify if you get a chance?


Update gemspec files setting to include all of maven-home and lib

The gem should include the lib/maven.rb file and all of maven-home. However the current Dir['maven-home/**'] pattern will only generate a 12kb gem without the necessary jars. This commit makes it explicit that all files from maven-home should be included.

Sorry this one got left behind. I'll merge today and see about getting a released gem out.

I need permission to push but once @mkristian grants me that I'll have a release out.

ruby-maven-libs 3.8.9 has been pushed to rubygems.org!

Thank you @headius. For future note, the gem was being versioned according to the version of maven-* jars it includes, which is why #3 bumped the version to 3.8.8 - the latest maven release in the 3.8.x series.
In the future we may want to upgrade this gem to 3.9.6. I didn't do it in #3 since there were a lot of changes to maven code and dependencies since 3.8.x.