Simulator build - AirGoogleMaps dir must be added to your xCode project to support GoogleMaps on iOS

Summary
I'm trying to use React Native Maps with Google as provider for iOS.
I have followed the instructions here: https://docs.expo.dev/versions/latest/sdk/map-view/ creating API-keys etc.
I get the following error:

Reproducible sample code
import MapView, { PROVIDER_GOOGLE } from 'react-native-maps';

<MapView
    provider={PROVIDER_GOOGLE}
>

Steps to reproduce
Start an Expo SDK 50 project with managed flow.
Follow the steps listed here:  https://docs.expo.dev/versions/latest/sdk/map-view
Add Google API Key to field ios.config.googleMapsApiKey in app.json
Run simulator build with npx expo run:ios
Expected result
MapView with Google as the provider
Actual result
Error message as shown above.
React Native Maps Version
1.10.0
What platforms are you seeing the problem on?
iOS (Google Maps)
React Native Version
0.73.4
What version of Expo are you using?
Not using Expo
Device(s)
iPhone 14 Pro Max
Additional information
No response

My bad. All I had to do was delet /ios folder and run npx expo run:ios again.

Same with react native without expo


how do we feed input (video or image ) and generate 3D boxes?

I meant on inference

Hi, thanks for your interest. This is a lidar-only detector. Please see inference.py for usage. Note that the behavior is subject to change.


Accept all RFC3339-compliant timestamps

Issue:
aws_date_time did not accept "2024-02-23 23:06:27+00:00", despite that being a valid RFC 3339 timestamp.
Background:

ISO 8601: is a standard for date and time, but has a lot of options in it.

aws_date_time has enums for ISO_8601, but does not claim to support every single option
One option it did support though, was Basic vs Extended format.

Basic: no separators between "YYYYMMDD" and "HHMMSS"
Extended: has separators between "YYYY-MM-DD" and "HH-MM-SS"

RFC 3339: details a subset of ISO 8601 for use in internet timestamps

Smithy 2.0 says that timestamps should use RFC 3339
aws_date_time does not fully support RFC 3339. The unsupported features in the string above were:

Space instead of "T" between date and time
Offset instead of "Z" after time

I personally found the parsing code for ISO_8601 hard to follow, and the ISO_8601_BASIC code was a big copy/paste of that.

Description of changes:

The code is rewritten to be simpler. It is no longer a state machine.
Combine parsing code for ISO_8601 and ISO_8601_BASIC into 1 function.

The parse is lenient now, accepting Basic or Extended timestamps, regardless of whether the ISO_8601 or ISO_8601_BASIC enum is passed in.

Our ISO_8601 code already allowed separators to be omitted from time, which shows evidence that lenience is good.
This matches the leniency of Python's dateutil.parser.isoparse(str) which allows "2024-02-23T23:06:27Z" or "20240223T230627Z" or "2024-02-23T230627Z" or "20240223T23:06:27Z"

Allow space instead of "T"
Allows lowercase "t" and "z"
Support offsets like "+12:34", instead of just "Z"
Allow ",123" for fractional seconds, not just ".123"

The Basic parse code had a bug where did not expect any characters between seconds and fractional-seconds. This is wrong. Python's dateutil rejects this.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report
Attention: Patch coverage is 96.96970% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 83.04%. Comparing base (15a2534) to head (ebd6f14).

Files
Patch %
Lines

source/date_time.c
96.96%
2 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1093      +/-   ##
==========================================
- Coverage   83.15%   83.04%   -0.12%
==========================================
  Files          56       56
  Lines        5813     5762      -51
==========================================
- Hits         4834     4785      -49
+ Misses        979      977       -2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


json from remote url is not working

Adding the package.json and the component to repro the issue. It is working fine if I give the json in the asset folder. But not when the url for the json is provided.
{
  "name": "LottieSamples",
  "version": "0.0.1",
  "private": true,
  "dependencies": {
    "@types/jest": "^26.0.13",
    "@types/node": "^14.6.4",
    "@types/react": "^16.9.49",
    "@types/react-dom": "^16.9.8",
    "lottie-react-native": "^3.5.0",
    "react": "16.13.1",
    "react-native": "0.63.2",
    "typescript": "^4.0.2"
},
"devDependencies": {
    "@babel/core": "^7.11.6",
    "@babel/runtime": "^7.11.2",
    "@react-native-community/eslint-config": "^2.0.0",
    "babel-jest": "^26.3.0",
    "eslint": "^7.8.1",
    "jest": "^26.4.2",
    "metro-react-native-babel-preset": "^0.63.0",
   "react-test-renderer": "16.13.1"
  },
}

Component.tsx
import React, {Component} from 'react';
import {Text, TouchableOpacity, View} from 'react-native';
import LottieView from 'lottie-react-native';

export default class MyAnimComp extends Component {

render() {
    return (
        <View
            style={{
                flex: 1,
                alignItems: 'center',
                justifyContent: 'center',
                backgroundColor: '#19BAE2',
            }}>
            <Text>Hello</Text>

            <LottieView
                source={{uri: 'https://assets10.lottiefiles.com/datafiles/c56b08b89932c090a0948b53fd58427d/data.json'}}
                autoPlay={true}
                loop={true}
            />
        </View>
    );
}

}
`
Error screen

Steps to Reproduce

[First Step]
[Second Step]
[and so on...]

Expected behavior: Animation should load
Actual behavior: Animation is not loading.
Versions
You can get this information from executing npm version.

can you slove it ?

same to me that upsets me a lot....... having troubles with passing URL for dynamically maping

not working..any soluion...

i find a solution ...
           <LottieView                 source={YOUR_JSON_DATA}                 autoPlay={true}                 loop={true}             />

I guys I have found a solution which is:

store the LottieJson in a variable first after fetching it // let somejson = fetch("")
then render it with a condition like:
{!somejson ? null :  }

and it will all work fine, you just need to fetch it first or cache it or store in a variable

Same here


Backspacing

The original Issue: https://github.com/angular-ui/ui-utils/issues/271
Don't know why this was closed right after opening, but the problem persists.
With ui-mask="QT**********" you can enter any characters and it will work fine. After erasing all the characters with backspace and then continuing  to press backspace the value will start filling up with the first static character of the mask, i.e. "QTQQQQQQ". This can be reproduced on the ui-mask html preview page.

Should be fixed via #98

This problem persists for me exactly as described in android.


Issue 65: Make it easy to access files

Merge Checklist

[x] Have you linked this Pull Request to an Issue?
[x] Have you updated any relevant README files, to explain how this new feature works (with examples)?
[ ] Have you added relevant test cases for your change?
[ ] Do all tests and code style checks pass with ./gradlew check --info?
[ ] Have you successfully run your change in a pipeline in a Jenkins instance?
[x] Have you updated the CHANGELOG?

Codecov Report

Merging #66 (bd44bf6) into master (28ebc17) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #66   +/-   ##
=======================================
  Coverage   89.11%   89.11%
=======================================
  Files          14       14
  Lines         147      147
  Branches       23       23
=======================================
  Hits          131      131
  Partials       16       16

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 28ebc17...bd44bf6. Read the comment docs.


Add configurable decimation support

Add support for decimating the data server-side. This will allow us to immediately decimate in-bound data.
Decimation may either be done automatically, or via input provided from the UI.
This may help resolve https://github.com/quartiq/stabilizer-streaming/issues/6 by limiting the number of samples sent to the frontend.

Closing as not pertinent to the current state of the code.
There is infinitly deep staged decimation implemented and available.


Allow specifying installation directory

Requirements

Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
All new code requires tests to ensure against regressions

Description of the Change
Currently the --install flag of the ./script/build is a boolean flag that either installs atom to some predefined location or skips it. This PR extends the flag so it can accept a value telling the script where to install atom. Passing just --install will behave as it used to so far, so it will install atom to /usr/local on linux and other default locations on darwin and windows. Same with not passing the flag - atom won't be installed. But passing --install=/opt/atom will install atom under the given location.
The documentation is updated accordingly.
Alternate Designs
I haven't considered other designs, extending the --install flag looked natural to me.
Why Should This Be In Core?
It's a part of the builder script, so it can't be a package.
Benefits
One can install the code in the location of choice. (Like for flatpaks, we want to install atom under /app).
Possible Drawbacks
It's backward compatible, so not sure if there are drawbacks.
Applicable Issues
Didn't file any.

https://github.com/atom/atom/issues/13240

Tested on Mac, Linux, Windows.  Only issue I saw was if you use ~, it doesn't work and doesn't do anything.  It even shows like it works on mac but doesn't.
see screenshot:

I tested both default --install and with a path.  Both worked on all.  On CentOs, regular --install didn't work due to permission issue, but I am seeing this on master as well
see:

Since this isn't related,  The only issue is using ~ as I think it's a fairly common scenario and seems to fail silently which isn't great.

Hey, @ungb, thanks for testing! I didn't thought about handling the tilde, probably because I thought that nodejs will handle this itself, but apparently it is not nor is planning to.
I updated the PR - rebased it to recent master, replaced != with !== and added some code for handling tilde (this adds a dep on the passwd-user module). Note that the tilde expansion happens only on linux and mac, and I have tested it only on linux. I checked the following (kv is my user name):

~
~kv
~/
~kv/
~/usr
~kv/usr
~yaddayaddanosuchuser/blah

Error: Failed to expand the tilde in ~yaddayaddanosuchuser/blah - user "yaddayaddanosuchuser" does not exist

You can greatly simplify this by using the untildify package.

@thomasjo That only supports ~/..., not ~user/... AFAICT.

I considered the untildify package, but it didn't do the ~user stuff.
Also, the appveyor failure seems unrelated, it even skips the installation, because --install flag was not passed.

LGTM!  I was able to verify the new changes on linux and mac.

Merging as I don't believe this is causing build failures on appveyor as I see other failures for similar things.


external not exported rename

as the use case for digga expands into downstream
lib expantion the "external" naming is no more
appropriate when downstream lib functions purposefully
bundle and intentionally re-export upstream art.

bors try

bors try

I agree with the reasoning for the name change. I don't love nonExportedModules, I would prefer making this just modules and switching the current modules to exportedModules. It seems like modules have to be written well to be safely exported and such a name change would convey that better.

I really like that reasoning!

Would you mind taking over? i know I won't be able to carve out the slot to amend within the next X weeks.


Nuke fails to publish with two subsets while creating review files for second subset

Describe the bug
Extract burnins fails to make review files with burnin for second subset.
To Reproduce

In Nuke, create main write render, and write render with new subset. Make sure review checkbox is ON.
Locally Publish shot with both outputs
Main subset is correctly rendered, with mov files and burnins
Second subset fails during the publish on creating burnins for second subset. Main subset burnins are created. Looks like burnins are trying to use main subset movs instead of second subset movs as an input.

RuntimeError: Failed to run: "ffprobe" -v quiet -print_format json -show_format -show_streams"//dps150/zback/GFX_storage/T009_pypetestAA/shots/trs001/work/compositing/renders/nuke/renderCompositingMain/renderCompositingMain.baked_h264.mp4"
Expected behavior
Pype should be able to make review files (with burn-ins) for more then one output.
Desktop (please complete the following information):

OS: Windows 10
Host: Nuke 11.3

Additional context
Publish was also failing on log messages in pype/hosts/nuke/lib.py:
https://github.com/pypeclub/pype/blob/a17fa74d4626a5c6d37475fc0c5a84318ea4f0b3/pype/hosts/nuke/lib.py#L1356
https://github.com/pypeclub/pype/blob/a17fa74d4626a5c6d37475fc0c5a84318ea4f0b3/pype/hosts/nuke/lib.py#L1365
https://github.com/pypeclub/pype/blob/a17fa74d4626a5c6d37475fc0c5a84318ea4f0b3/pype/hosts/nuke/lib.py#L1393
https://github.com/pypeclub/pype/blob/a17fa74d4626a5c6d37475fc0c5a84318ea4f0b3/pype/hosts/nuke/lib.py#L1417
Plus there was a try to delete non-existent Nuke nodes:
https://github.com/pypeclub/pype/blob/a17fa74d4626a5c6d37475fc0c5a84318ea4f0b3/pype/hosts/nuke/lib.py#L1170
[cuID:PYPE-1144]

Sending to Deadline has a similar issue with multiple subsets.

This is an old issue - has this been resolved since?

I checked local and farm (Deadline) publish. Both works. It has been resolved.


Ensure future pulls and merges to service branches run CI build

This will be picked up by all future service release branches.

How does it differ from this one?
https://github.com/jakartaee/data/pull/778/files

@otaviojava The other pull request put this change into branch RELEASE-1.0.0.  This pull request puts this change into main


openai, update tsp for *AsPlainText op, request as multipart, and response as text

fix https://github.com/Azure/azure-rest-api-specs/issues/26299
Data Plane API - Pull Request

API Info: The Basics
Most of the information about your service should be captured in the issue that serves as your API Spec engagement record.

Link to API Spec engagement record issue:

Is this review for (select one):

[ ] a private preview
[ ] a public preview
[ ] GA release

Change Scope
This section will help us focus on the specific parts of your API that are new or have been modified. Please share a link to the design document for the new APIs, a link to the previous API Spec document (if applicable), and the root paths that have been updated.

Design Document:
Previous API Spec Doc:
Updated paths:

Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.
Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
Swagger-Suppression-Process
to get approval.
❔Got questions? Need additional info?? We are here to help!

 Contact us!
The Azure API Review Board is dedicated to helping you create amazing APIs. You can read about our mission and learn more about our process on our wiki.

💬 Teams Channel
💌 email

Click here for links to tools, specs, guidelines & other good stuff
Tooling

Open API validation tools were run on this PR. Go here to see how to fix errors
Spectral Linting
Open API Hub

Guidelines & Specifications

Azure REST API Guidelines
OpenAPI Style Guidelines
Azure Breaking Change Policy

Helpful Links

Azure DevTools Wiki

/azp run


Custom OCF apply flow

We designed the process to onboard a fund from the apply button of the OCF homepage

1. Intro
2. Fees
3. Form
4. Success

Check the design file in figma 🎨
@znarf @piamancini @alanna

@Memo-Es if this is not a feature to be worked on internally, I would be excited to implement these designs @Memo-Es @alanna @znarf

For the frontend part, Formik should ideally be used to manage the state of the form since there are many fields.
On the API part, the way we store data should be defined by https://github.com/opencollective/opencollective/issues/3715.

@Betree is this the correct repository for the OCF ?

@vickywane for OCF website, yes. The implementation for this issue however is to be done in Open Collective's codebase.
We're still not sure about the plan for this, but it's a complex project so more likely to be tackled internally or by an existing contractor (outside of the bounty program).

Alright then.

This issue will be resolved by https://github.com/opencollective/opencollective-frontend/pull/5623, but we'll need to iterate with https://github.com/opencollective/opencollective/issues/3844 to make sure we display the form data in the host dashboard.

This issue will be resolved by https://github.com/opencollective/opencollective-frontend/pull/5623, but we'll need to iterate with https://github.com/opencollective/opencollective/issues/3844 to make sure we display the form data in the host dashboard.

@Memo-Es Why do we have 2 times the checkbox for "I agree with the terms of Fiscal Sponsorship"? Step 1 and Step3.

@Memo-Es Why do we have 2 times the checkbox for "I agree with the terms of Fiscal Sponsorship"? Step 1 and Step3.

@Memo-Es @piamancini the copy at Step "success" is weird:

it's implying that the application is gonna be accepted, not that it's gonna be reviewed
if the user created an account in the process, there is no mention of it, do they need to do something? They're gonna receive an email about their account creation and collective/fund creation, what should they do about it?

Generally, what is the expected next step for the User, an email saying that their application was accepted?

@Memo-Es @piamancini the copy at Step "success" is weird:

it's implying that the application is gonna be accepted, not that it's gonna be reviewed
if the user created an account in the process, there is no mention of it, do they need to do something? They're gonna receive an email about their account creation and collective/fund creation, what should they do about it?

Generally, what is the expected next step for the User, an email saying that their application was accepted?

@Memo-Es Why do we have 2 times the checkbox for "I agree with the terms of Fiscal Sponsorship"? Step 1 and Step3.

We wanted to make sure folks take acquaintance of that in those two moments of the process... Seems overkill to you? @znarf
Agree with the success page copy change. I'm gonna wait for Pia's input to put it in the design.

@Memo-Es Why do we have 2 times the checkbox for "I agree with the terms of Fiscal Sponsorship"? Step 1 and Step3.

We wanted to make sure folks take acquaintance of that in those two moments of the process... Seems overkill to you? @znarf
Agree with the success page copy change. I'm gonna wait for Pia's input to put it in the design.

We wanted to make sure folks take acquaintance of that in those two moments of the process... Seems overkill to you?

@Memo-Es I don't know any process where I need to check a box 2 times for the same thing. So yeah, overkill. Or, at least check it by default the second time it appears.

We wanted to make sure folks take acquaintance of that in those two moments of the process... Seems overkill to you?

@Memo-Es I don't know any process where I need to check a box 2 times for the same thing. So yeah, overkill. Or, at least check it by default the second time it appears.

Yeah. I'm removing it from step 3, so the first thing you do is acknowledge the terms of fiscal sponsorship; it also seems less likely that a user reads both links after filling the form
@znarf @flickz

Yeah. I'm removing it from step 3, so the first thing you do is acknowledge the terms of fiscal sponsorship; it also seems less likely that a user reads both links after filling the form
@znarf @flickz

Design update

Included a flow for registered users to apply with an existing collective

1. Intro
2. Fees
3. Form
4. Success

See the production-ready file on figma

Design update

Included a flow for registered users to apply with an existing collective

1. Intro
2. Fees
3. Form
4. Success

See the production-ready file on figma

Implemented in https://github.com/opencollective/opencollective-frontend/pull/5833


Remove file when upload error

I use formidable in my project. When i upload file error i need remove file. Is there any way to prevent uploading when errors? ex: Roll back

What errors ?
By default if maxSize is exceeded the files are removed automatically.
If the error happens afterwards, use fs.rm.

What errors ?
By default if maxSize is exceeded the files are removed automatically.
If the error happens afterwards, use fs.rm.


go app cannot find package and fails deployment

Same project deploys to Heroku, but fails for flynn.
Any ideas what may be wrong here?
v20160504.0```

Heroku

$ git push heroku master
Counting objects: 1031, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (808/808), done.
Writing objects: 100% (847/847), 10.42 MiB | 1.66 MiB/s, done.
Total 847 (delta 438), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Fetching set buildpack https://github.com/kr/heroku-buildpack-go.git... done
remote: -----> Go app detected
remote: -----> Checking Godeps/Godeps.json file.
remote: -----> Installing go1.6... done
remote: -----> Running: godep go install -tags heroku ./...
remote:
remote: -----> Discovering process types
remote:        Procfile declares types -> web
remote:
remote: -----> Compressing...
remote:        Done: 18.8M
remote: -----> Launching...
remote:        Released v61
remote:        https://test123.herokuapp.com/ deployed to Heroku
remote:
remote: Verifying deploy.... done.
To https://git.heroku.com/test123.git
af29cbb..991e336  master -> master

Flynn

$ git push flynn master
Counting objects: 3269, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3034/3034), done.
Writing objects: 100% (3269/3269), 16.34 MiB | 1.81 MiB/s, done.
Total 3269 (delta 1163), reused 0 (delta 0)
-----> Building test123...
-----> Go app detected
-----> Checking Godeps/Godeps.json file.
-----> Installing go1.6... done
-----> Running: go install -v -tags heroku .
remote: model/hub.go:3:2: cannot find package "github.com/dancannon/gorethink" in any of:
remote: 	/tmp/cache/go1.6/go/src/github.com/dancannon/gorethink (from $GOROOT)
remote: 	/tmp/build/.heroku/go/src/github.com/dancannon/gorethink (from $GOPATH)
(...)
remote: Build failed: exec: job exited with status 1
To https://git..flynnhub.com/test.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git..flynnhub.com/test.git'

@thomasmodeneis are you using an explicit buildpack? Flynn uses github.com/heroku/heroku-buildpack-go but from your output it seems you are using github.com/kr/heroku-buildpack-go?

I'm not using any explicit buildpack, is just the same code with a godeps dir and a goproc. Weird is that it works on heroku but fails on flynn for some odd reason.

So I had another cluster that was up and running with an old version of this same software, but flynn there is about 2 months old. So I've deployed my code to this one, and well it worked just fine, what makes me believe this is a new defect on flynn, what do you think?
git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --tags --set-upstream flynn refs/heads/master:refs/heads/master
Pushing to https://git.*.flynnhub.com/test123.git
POST git-receive-pack (958898 bytes)
remote: -----> Building test123...
remote: -----> Go app detected
remote: -----> Checking Godeps/Godeps.json file.
remote: -----> Using go1.6
remote: -----> Running: godep go install -tags heroku ./...
remote: -----> Discovering process types
remote:        Procfile declares types -> web
remote: -----> Compiled slug size is 19M
remote: -----> Creating release...

I think that github.com/dancannon/gorethink is probably cached. It looks like you have godep configured, have you vendored the package properly?

this is a complete new cluster i've created, is just no way it was cached as it could not be cached (its new).
Its all properly configured, if you read the report it says that it works for heroku and for a old version of flynn, but it fails for v20160504.0. :|
I'm not sure what to do here mate, is pretty strange.

Yeah, I mean cached in heroku/the old cluster. Have you checked the vendoring configuration?

I will double check and update all dependencies / retry the cluster creation and install just to be on the safe side.

hi @titanous I've upgraded dependencies and tested to install in other envs and they all work, including heroku, so I'm confused how to inspect further. How can I get access to the server that executed this build? I have a cluster of 3, how can I identify and connect to it?
Thanks

Have you tried deploying to an entirely new app on Heroku? Did that work? There is no easy way to get at the build environment as it is in an ephemeral container that is destroyed at exit.

So I did a test, I've installed an old app with go 1.4.2 and it worked, so then I upgraded this same app to 1.6 and pushed to flynn and failed. Same behavior.
So it seems to be something related to Go 1.6. I've deployed the same app on heroku with no errors:
 git push heroku master
Counting objects: 754, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (679/679), done.
Writing objects: 100% (754/754), 7.48 MiB | 847.00 KiB/s, done.
Total 754 (delta 102), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Go app detected
remote: -----> Checking Godeps/Godeps.json file.
remote: -----> Installing go1.6.2... done
remote:  !!    Installing package '.' (default)
remote: -----> Running: godep go install -v -tags heroku .
remote: github.com/garyburd/redigo/internal
remote: github.com/mikeflynn/golang-instagram/instagram
remote: github.com/garyburd/redigo/redis
remote: github.com/google/google-api-go-client/googleapi/transport
remote: golang.org/x/net/context
remote: github.com/eaigner/shield
remote: golang.org/x/net/context/ctxhttp
remote: google.golang.org/api/googleapi/internal/uritemplates
remote: comentarismo-moody/model
remote: google.golang.org/api/googleapi
remote: google.golang.org/api/gensupport
remote: test/providers/facebook
remote: test/providers/instagram
remote: test/providers/vinevideo
remote: google.golang.org/api/youtube/v3
remote: github.com/facebookgo/grace/gracenet
remote: github.com/facebookgo/clock
remote: github.com/facebookgo/stats
remote: github.com/facebookgo/httpdown
remote: github.com/facebookgo/grace/gracehttp
remote: github.com/gorilla/context
remote: github.com/gorilla/mux
remote: github.com/gorilla/pat
remote: gopkg.in/bsm/ratelimit.v1
remote: gopkg.in/redis.v3/internal/consistenthash
remote: gopkg.in/redis.v3
remote: test/providers/youtube
remote: test/server
remote: test
remote: -----> Discovering process types
remote:        Procfile declares types -> (none)
remote:
remote: -----> Compressing...
remote:        Done: 6.6M
remote: -----> Launching...
remote:        Released v3
remote:        https://*.herokuapp.com/ deployed to Heroku
remote:
remote: Verifying deploy... done.
To https://git.heroku.com/*.git
 * [new branch]      master -> master

1.4.2:
$ git push flynn master
Counting objects: 725, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (656/656), done.
Writing objects: 100% (725/725), 7.47 MiB | 1.30 MiB/s, done.
Total 725 (delta 85), reused 0 (delta 0)
-----> Building test...
-----> Go app detected
-----> Checking Godeps/Godeps.json file.
remote:  !
remote:  !     Deprecated version of go (go1.4.2)
remote:  !     See https://devcenter.heroku.com/articles/go-support#go-versions for supported version information.
remote:  !
-----> Installing go1.4.2... done
-----> Running: godep go install -tags heroku .
-----> Discovering process types
-----> Compiled slug size is 6.4M
-----> Creating release...
=====> Application deployed
To https://git.*.flynnhub.com/test.git
 * [new branch]      master -> master

1.6:
git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --tags flynn refs/heads/master:refs/heads/master
Pushing to https://git.*.flynnhub.com/test.git
POST git-receive-pack (2560 bytes)
remote: -----> Building test...
remote: -----> Go app detected
remote: -----> Checking Godeps/Godeps.json file.
remote: -----> Installing go1.6... done
remote: -----> Running: go install -v -tags heroku .
remote: model/test.go:7:2: cannot find package "github.com/eaigner/shield" in any of:
remote: 	/tmp/cache/go1.6/go/src/github.com/eaigner/shield (from $GOROOT)
remote: 	/tmp/build/.heroku/go/src/github.com/eaigner/shield (from $GOPATH)
remote: server/server.go:9:2: cannot find package "github.com/facebookgo/grace/gracehttp" in any of:
remote: 	/tmp/cache/go1.6/go/src/github.com/facebookgo/grace/gracehttp (from $GOROOT)
remote: 	/tmp/build/.heroku/go/src/github.com/facebookgo/grace/gracehttp (from $GOPATH)
remote: providers/youtube/youtube.go:8:2: cannot find package "github.com/google/google-api-go-client/googleapi/transport" in any of:
remote: 	/tmp/cache/go1.6/go/src/github.com/google/google-api-go-client/googleapi/transport (from $GOROOT)
remote: 	/tmp/build/.heroku/go/src/github.com/google/google-api-go-client/googleapi/transport (from $GOPATH)
remote: server/server.go:8:2: cannot find package "github.com/gorilla/pat" in any of:
remote: 	/tmp/cache/go1.6/go/src/github.com/gorilla/pat (from $GOROOT)
remote: 	/tmp/build/.heroku/go/src/github.com/gorilla/pat (from $GOPATH)
remote: model/instagram.go:8:2: cannot find package "github.com/mikeflynn/golang-instagram/instagram" in any of:
remote: 	/tmp/cache/go1.6/go/src/github.com/mikeflynn/golang-instagram/instagram (from $GOROOT)
remote: 	/tmp/build/.heroku/go/src/github.com/mikeflynn/golang-instagram/instagram (from $GOPATH)
remote: providers/youtube/youtube.go:9:2: cannot find package "google.golang.org/api/youtube/v3" in any of:
remote: 	/tmp/cache/go1.6/go/src/google.golang.org/api/youtube/v3 (from $GOROOT)
remote: 	/tmp/build/.heroku/go/src/google.golang.org/api/youtube/v3 (from $GOPATH)
remote: server/handlers.go:8:2: cannot find package "gopkg.in/redis.v3" in any of:
remote: 	/tmp/cache/go1.6/go/src/gopkg.in/redis.v3 (from $GOROOT)
remote: 	/tmp/build/.heroku/go/src/gopkg.in/redis.v3 (from $GOPATH)
remote: Build failed: exec: job exited with status 1
To https://git.*.flynnhub.com/test.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.*.flynnhub.com/test.git'
Completed with errors, see above

I can see that the command that flynn is running is go install -v -tags heroku . and it fails with errors, but heorku is using godep go install -v -tags heroku . and works fine.

I tried with Go 1.6.2 and it was the same behavior, however I can see that its reporting go 1.6.2 as Deprecated, that must be wrong as heroku buildpack supports it go1.6 (installs go1.6.2)
git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --tags --set-upstream flynn refs/heads/master:refs/heads/master
Pushing to https://git.*.flynnhub.com/test.git
POST git-receive-pack (chunked)
remote: -----> Building test...
remote: -----> Go app detected
remote: -----> Checking Godeps/Godeps.json file.
remote:  !
remote:  !     Deprecated version of go (go1.6.2)
remote:  !     See https://devcenter.heroku.com/articles/go-support#go-versions for supported version information.
remote:  !
remote: -----> Installing go1.6.2... done
remote: -----> Running: go install -v -tags heroku .
(same errors as others)

Then I said ok lets me try 1.5 and see how that goes ? and 1.5 works fine.
git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --tags --set-upstream flynn refs/heads/master:refs/heads/master
Pushing to https://git.*.flynnhub.com/test.git
POST git-receive-pack (chunked)
remote: -----> Building test...
remote: -----> Go app detected
remote: -----> Checking Godeps/Godeps.json file.
remote: -----> Installing go1.5.3... done
remote: -----> Running: godep go install -tags heroku .
remote: -----> Discovering process types
remote:        Procfile declares types -> web
remote: -----> Compiled slug size is 19M
remote: -----> Creating release...
remote: =====> Application deployed
remote: =====> Waiting for web job to start...
remote: =====> Default web formation scaled to 1
To https://git.*.flynnhub.com/test.git
 * [new branch]      master -> master
updating local tracking ref 'refs/remotes/flynn/master'
Branch master set up to track remote branch master from flynn.
Completed successfully

Try running this and deploying again:
flynn env set BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-go

That works, it will be very nice if you could include this step into the flynn docs as this seems to be required in order to have things running :)
Thanks @titanous

I've updated the buildpack in #2806 which should fix this.

Thanks @titanous

Hi @titanous
I'm running into the same problem now after updating it to 1.7.     Installing package '.' (default)
        !!
        !!
-----> Running: go install -v -tags heroku .
       model/hub.go:3:2: cannot find package "github.com/dancannon/gorethink" in any of:
       /tmp/cache/go1.7/go/src/github.com/dancannon/gorethink (from $GOROOT)
remote: ERROR: Build failed: exec: job exited with status 1

After reducing the Godeps.json to go1.6.2 the deployment works fine.
I see the same difference I had last time, after downgrade to 1.6.2 the log says: -----> Running: godep go install -v -tags heroku .
v20160819.0```

Any ideas ?

Thanks

Have you run godep save? Make sure you have the latest version of godep with go get -u github.com/tools/godep. This might have to do with the change in how vendoring works over the past few Go releases.

@titanous you where right, I had to update vendoring to use the vendor folder and kind of "migrate" from godeps to new vendor.
Thanks for the tip :)


sublist: Add JSON test data

The test data is based off the python tests for the sublist example:
https://github.com/exercism/xpython/blob/master/exercises/sublist/sublist_test.py

Thanks!
I did a quick survey of the other languages that implement this problem and have some questions.

Some languages check non-numeric sets (Rust, for example). I think that should be part of the standard test suite, but others might disagree.
Is this API one we want to continue? Most languages will do something like this

assert Sublist.compare([4,3,2],[5,4,3,2,1]) == :sublist

Where some method returns compares two lists and returns a string/constant/symbol/etc.
But Lua does something different where the comparison returns a boolean.
I think the boolean return makes more sense here, honestly. But, not having done the problem myself, I could be missing something.

I don't have strong opinions of the checked of nonnumeric values as well.
I do like the checking for a boolean instead of using a constant or other magic value.

My API question was about whether or not we expect students to return magic strings or booleans. This can be driven by the JSON, since some language tracks can automatically generate their tests from the JSON.
If we want to encourage boolean-returning implementations, then the json should be updated to look something like this:
{
  "#": [
  ],
  "sublist": {
    "description": "",
    "list_one": [1,2,3],
    "list_two": [1,2,3,4,5],
    "expected": true
  },
  "equal": {
    "description": "",
    "list_one": [1,2,3],
    "list_two": [1,2,3],
    "expected": true
  },
  "superlist": {
    "description": "",
    "list_one": [1,2,3,4,5],
    "list_two": [1,2,3],
    "expected": true
 }
}

By breaking out the expected methods (superlist, sublist, equal) and declaring that we expect them to return booleans, we suggest to track maintainers that their tests should look for booleans, not magic strings.

To extend @IanWhitney's suggestion, we would have three sections in the JSON, one for each function, and each section would have multiple tests. I think.

Yeah there are several approaches for an API here. One approach taken by languages with variant types is that you might have a type that can take on the four values Sublist, Superlist, Equal, Unrelated and a single function that has to return one of the four values. It seemed to make sense in Haskell and Rust. That might make less sense for a language that doesn't have variant types. I wonder how the tests should be such that both styles are possible.

Wait...sublist, superlist....Is this exercise a duplicate of Custom Set?

For Custom Set, the order of the members does not matter. For this exercise, it does. From one of the examples in Custom Set:
https://github.com/exercism/x-common/blob/master/custom-set.json#L37

Is there anything we can do to help people understand the difference between lists and sets (ordered vs unordered, can contain duplicates vs all unique)?

The readme could be updated to point out this difference? Or perhaps a definition of a 'list' and 'set' in those readme files?

@IanWhitney what about something like following? According to the readme, several of the
{
  "#": [],
  "cases": [{
    "description": "empty lists",
    "list_one": [],
    "list_two": [],
    "equal": "true",
    "sublist": "true",
    "superlist": "true"
  }, {
    "description": "empty list within non empty list",
    "list_one": [],
    "list_two": [1, 2, 3],
    "equal": "false",
    "sublist": "true",
    "superlist": "false"
  },
...
  ]
}

@callahat
My guess is that will not work with the code that some tracks use to automatically generate tests.

Could you elaborate?

I have not worked on a track that auto-generates tests, so I'm not positive. But I'm guessing that the test-generation code has an expectation that the json looks like
"method1": {
  "cases":  [
    {
    "condition": "",
    "expectation":"",
    }
  ]
},
"method2": {
  "cases":  [
    {
    "condition": "",
    "expectation":"",
    }
  ]
}

Whereas your suggestion was
  "cases":  [
    {
     "condition": "",
     "method1": "",
     "method2": ""
    }
  ]
}

That might work for tracks, I don't know. But it doesn't match the standard I've seen (example, another)

I think the README is the source of all this confusion.
We've mentioned we don't like magic strings, but the README explicitly asks for a single function that indicates the relationship between A and B. (equal, sublist, superlist, none of the previous).
On the other hand, the simplest implementation of sublist function would be to simply test if A is a sublist of B.
If A is a sublist of B, then B is a superlist of A, no?
And if A and B are sublists of each other, they are equal.
Lastly, if neither A nor B are sublists of each other, then you arrive at the "none of the previous" scenario.
README says:
Write a function that given two lists determines if the first list is
contained within the second list, if the second list is contained within
the first list, if both lists are contained within each other or if none
of these are true.

Specifically, a list A is a sublist of list B if by dropping 0 or more elements
from the front of B and 0 or more elements from the back of B you get a list
that's completely equal to A.

Examples:

 * A = [1, 2, 3], B = [1, 2, 3, 4, 5], A is a sublist of B
 * A = [3, 4, 5], B = [1, 2, 3, 4, 5], A is a sublist of B
 * A = [3, 4], B = [1, 2, 3, 4, 5], A is a sublist of B
 * A = [1, 2, 3], B = [1, 2, 3], A is equal to B
 * A = [1, 2, 3, 4, 5], B = [2, 3, 4], A is a superlist of B
 * A = [1, 2, 4], B = [1, 2, 3, 4, 5], A is not a superlist of, sublist of or equal to B

The sublists are straightforward enough. But starting here things get fuzzy:
A = [1, 2, 3], B = [1, 2, 3], A is equal to B

isn't straightforward. A is a sublist of B in addition to being equal, but I guess equality is taking precedence...
A = [1, 2, 3, 4, 5], B = [2, 3, 4], A is a superlist of B

but B is also a sublist of A, I guess the order matters (A is (a sublist of|a superlist of|equal to|none) B)
A = [1, 2, 4], B = [1, 2, 3, 4, 5], A is not a superlist of, sublist of or equal to B

True enough, but what are we supposed to be returning for this?
I think if we agree on what the README should be saying, it will make this PR easier.

It's indeed the case that many solutions to this problem have used, as an internal function, a sublist function. They run A.sublist?(B) and B.sublist?(A) and based on what those two functions return, derive the relationship between A and B.
The function being tested is still a single function that determines the relationship (one of the four choices).
At least that's how I've seen it in Rust and Haskell, the two tracks in which I've worked this problem.

It does seem that a precedent had been set by 7 of the 8 language tracks which have this exercise. The majority do return essentially an enumerable value (not just boolean) that indicates their relationship. The most recently added track, Lua, returns true or false from one method call is_sublist as pointed out by @IanWhitney.
So it looks like decisions are needed on:

[] What should be returned (boolean or enumerable)
[] Rewording of the README to make the exercise more clear

Anything else?

Well, since you are doing the PR, @callahat, what do you think should be done?

I'd vote to stick with the precedent at this point. How do we come to a decision?

I think that's perfectly acceptable. A different PR/issue should address the use of magic strings, if its deemed to be a problem, in my opinion. So unless there are any strong objections (cc: @IanWhitney, @petertseng)... let's move forward with returning magic strings here.

I think the magic string in the JSON could also be used to implement the actual expectation. IE, in Ruby it could reference a constant or enumerable-like thing. But that's more of a discussion for the individual tracks.

So unless there are any strong objections (cc: @IanWhitney, @petertseng)... let's move forward with returning magic strings here.

I'm not objecting, because:

the magic string in the JSON could also be used to implement the actual expectation. IE, in Ruby it could reference a constant or enumerable-like thing.

Right, the simple fact that this is a string in JSON doesn't force any track's version of this problem to use strings. Tracks are free to take advantage of their language's features in whatever way makes sense.
To wit, both Haskell and Rust use their language's respective variant type (Haskell's data and Rust's enum) and not strings.

Ok.

Based on the discussion above it looks like there's only one more thing to clarify before this is ready to merge:

Some languages check non-numeric sets (Rust, for example). I think that should be part of the standard test suite, but others might disagree. - @IanWhitney

Some languages check non-numeric sets (Rust, for example). I think that should be part of the standard test suite, but others might disagree. - @IanWhitney

Adding this requirement would be trivial in languages with dynamic typing... not sure if it would lead to more interesting code or just more boilerplate in Rust, Go, etc. For this reason, I lean towards not requiring this in the metadata... but I'm open to other opinions.
I'd also like ask if unequal is the language we want to use when list A is not equal to, a sublist of, or a superlist of list B. Perhaps instead none or some other alternative? While any language consuming this metadata is free to modify it, I'd like our metadata to be able to say:

I know words, I have the best words.

I know words, I have the best words.

:) Yes, our metadata should have this as its slogan for sure.
Distinct? Disparate?

Unrelated?

I think I love unrelated.

I may have posted on a stack exchange site looking for a good word. :laughing:
I'll report back on my (read: their) findings.

@kotp unrelated might be ambiguous; it might imply that the two things being compared are not actually both lists. 'Disparate' or 'dissimilar' might be more clear.

non-overlapping?

The title reads 'list a and list b are unequal' so 'list a and list b are unrelated' can not imply that these are not lists.
But thinking about the word alone, with perhaps less distinctive wording as actually declaring them to be lists, I think unrelated holds less exclusivity than disparate.  Perhaps "totally unrelated" and "disparate" are pretty close friends.  But I think 'unrelated and disparate' are not.
You and I may be unrelated, yet we are both list... er... people.  "Unrelated" should bring up feelings of potential similarity, more connected than 'disparate'.  And more similar in characteristics than being fundamentally devoid of shared characteristics.
Unrelated has the distinct feeling to me of connected, perhaps similar in most ways, the potential to at least, on the surface, mistake them for 'cousins'.  But definitely the same species.
Disparate has a stronger feeling to it than unrelated, I think. "containing or made up of fundamentally different and often incongruous elements" (Merriam-Webster) though it can be as gentle as simply "different as compared together."

I couldn't find a single term that describes when lists are not sublists/superlists/equal.
We could borrow from set terminology (as we already are) and describe the lists as either disjoint or intersecting (or perhaps some variation like empty intersection and nonempty intersection).
This would make the implementation more involved. And it would also draw more attention to the precedence of the return value.
Currently it is implicitly equal > sublist/superlist. If we adopt disjoint and intersecting our precedence would presumably be equal > sublist/superlist > disjoint/intersecting and would probably need to be explicit.
I'm in favor of either going all the way with the set-like returns or scaling it back to just detecting sublists.

My idea hasn't gained any supporters. With that being the case, let's put it on the back burner and focus on getting this PR across the finish line. Do we have an agreement on what unequal should be changed to? I'm fine with pretty much anything :laughing:

@Cohen-Carlisle I have been at a conference, and haven't looked at any PRs or discussions in the past 4 days. That said, I am not sure whether the disjoint, empty intersection, non-empty intersection thing is worth the complexity. It might be (I haven't done the exercise, so I don't have a lot of context for this one).
Either way, I think you're right: let's get this PR across the finish line.
The current suggestions to replace unequal are:

none
distinct
disparate
unrelated
dissimilar
non-overlapping

I think inequal is the term I see most often in programming. That's also what's used on wikipedia, if that means anything.
There's also almost disjoint, which I mention not as a real suggestion but as a joke.

I :laugh: because I avoided that, due to thinking inequality perhaps had some nuance in regards to the problem domain.

Almost-disjoint is hilarious (but agreed: no!)

non_intersecting

independent

How about complement from set theory: https://en.wikipedia.org/wiki/Complement_(set_theory).

In set theory, a complement of a set A refers to things not in (that is, things outside of) A.

I'm not sure it's clear unless you know about set theory, but I'll put it out there as a suggestion.
❤

From the sublist problem description:

Write a function that given two lists determines if the first list is contained within the second list, if the second list is contained within the first list, if both lists are contained within each other or if none of these are true.

Perhaps the alliterative[1] route:
Sublist, Superlist, Same, Separate.
[1] I'm not trying to start a discussion about whether alliteration is a good practice.

My vote would be for unequal. I think disjoint is appropriate only if the two lists share no elements in common, and I think for a list to be a complement of another list it would have to contain everything that wasn't in the other list.
disjoint([1, 2], [3, 4]) // true
disjoint([1, 2], [2, 3]) // false

complement([1, 2], [3, 4]) // false
complement([1, 2], [3,4 ..] // true, assuming the domain is the positive integers, and [3, 4 ..] creates an infinitely long list

And as @Cohen-Carlisle pointed out, these options aren't all mutually exclusive: a list and its complement are also disjoint, but two disjoint lists aren't necessarily complements. Two disjoint lists can have a subset, superset relationship, but they don't have to. Equal lists always do - unless you're talking about strict superset/subsets.
I think having separate, boolean returning predicate functions for each of the options would make this explicit to the person doing the exercise: for each test case, all the functions could be called, and the return values of each checked for the correct combination of trues and falses. It would remove any ambiguity around the order of precedence.
Oh, and thinking about it, it would also remove the need to worry about what to call the unequal case! Because you would just have an equal function, and expect that it returned false rather than dealing with the double-negative case of expecting unequal to return true. Although I guess most languages will already provide this equality checking function, so it doesn't make for that interesting an exercise.. :-/

Perhaps "parallel" - implies a type of relationship where neither has the same elements.

TLDR: I vote for "disjoint"
In math, we have sets which are collections where the order doesn't matter and uniqueness does, and tuples where order matters and uniqueness doesn't. The operations on each are distinct in important ways.

set
tuple

union : (set, set) → set
concatenate : (tuple, tuple) → tuple

difference : (set, set) → set
replace : (tuple, tuple) → tuple

complement : (set, set) → set
truncate: (tuple, posint) → tuple

intersection : (set, set) → set
search : (tuple, tuple) → posint

member? : (t, set) → boolean
find : (t, tuple) → posint

equal? : (set, set) → boolean
match : (tuple, tuple) → posint

disjoint? : (set, set) → boolean
mismatch : (tuple, tuple) → posint

empty? : (set) → boolean
length : (tuple) → posint`

The semantics of this function in this exercise are much more complex. We're asking for with four different outputs, it's a valid case even when the position of the arguments is swapped--i.e. this isn't a typical operation on tuples. We're also conflating comparative states of sets (subset, superset, equal, disjoint) with those of tuples (found subsequence).
I'm not fault-finding the exercise, I'm just making the case that we shouldn't over-rationalize using set descriptions to describe the comparison of tuples.
sublist (tuple, tuple) → member { "disjoint", "equal", "subset", "superset" }

unequal. do it. merge this sucker.

Yay. Thank you everyone for helping think through all of this.


Seeing EOF/panic with v1.42.1 against MSK (Amazon) <IP_ADDRESS> that is not seen in v1.42.0

Is anyone having trouble with the latest v1.42.1 release? I pulled it in and now my service panics with either a "broken pipe" error or an EOF error when attempting to consume. I reverted back to 1.42.0 and everything works fine.
Originally posted by @JeffBNimble in https://github.com/IBM/sarama/discussions/2712#discussioncomment-7515236
My Kafka information:
Kafka version <IP_ADDRESS>
Provider: MSK (Amazon)
Using SSL (Port 9094)

@JeffBNimble can you add logs from Sarama and/or Kafka to help show your problem? You can set sarama.Logger to a log.Logger to capture Sarama debug output.
Can you also double check and confirm that your apps sarama.Config has sarama.Config{Version: sarama.V2_4_1_1} or lower set?

@JeffBNimble did you manage to resolve this issue? any update?

@JeffBNimble did you manage to resolve this issue? any update?

Hello @dnwe. I'm incredibly sorry for the delay in responding. I saw your response a few weeks ago and have been at an AWS conference and then I'm on PTO through the end of the year. I will verify this in early January when I return and will reply. Thank you for checking back on this.

No worries, enjoy the holidays and lets catch up in the New Year

@JeffBNimble any more we can do here?

We are good. The problem was what you said so good to close this out. Thank
you!
Thank you,
Jeff Roberts
On Sun, Feb 11, 2024 at 8:16 AM Dominic Evans @.***>
wrote:

@JeffBNimble https://github.com/JeffBNimble any more we can do here?
—
Reply to this email directly, view it on GitHub
https://github.com/IBM/sarama/issues/2719#issuecomment-1937767196, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFS4LNEJOWKP5ULLE76CG3YTDHDPAVCNFSM6AAAAAA7FBQR3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXG43DOMJZGY
.
You are receiving this because you were mentioned.Message ID:
@.***>

Cool, thanks Jeff


[FIX][8.0] function with api@multi is already check to one before, an…

…d return true instead of name (I think...)

n.b. this mp resolve a bug in getting name
Traceback (most recent call last):   File "/opt/simplerp/buildout/parts/SimplERP/openerp/http.py", line 544, in _handle_exception     return super(JsonRequest, self)._handle_exception(exception)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/http.py", line 581, in dispatch     result = self._call_function(**self.params)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/http.py", line 317, in _call_function     return checked_call(self.db, *args, **kwargs)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/service/model.py", line 118, in wrapper     return f(dbname, *args, **kwargs)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/http.py", line 314, in checked_call     return self.endpoint(*a, **kw)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/http.py", line 810, in __call__     return self.method(*args, **kw)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/http.py", line 410, in response_wrap     response = f(*args, **kw)   File "/opt/simplerp/buildout/parts/SimplERP/addons/web/controllers/main.py", line 944, in call_kw     return self._call_kw(model, method, args, kwargs)   File "/opt/simplerp/buildout/parts/SimplERP/addons/web/controllers/main.py", line 936, in _call_kw     return getattr(request.registry.get(model), method)(request.cr, request.uid, *args, **kwargs)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/api.py", line 268, in wrapper     return old_api(self, *args, **kwargs)   File "/opt/simplerp/buildout/parts/SimplERP/addons/project_issue/project_issue.py", line 326, in write     return super(project_issue, self).write(cr, uid, ids, vals, context)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/api.py", line 268, in wrapper     return old_api(self, *args, **kwargs)   File "/opt/simplerp/buildout/parts/SimplERP/addons/mail/mail_thread.py", line 432, in write     result = super(mail_thread, self).write(cr, uid, ids, values, context=context)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/api.py", line 268, in wrapper     return old_api(self, *args, **kwargs)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/api.py", line 399, in old_api     result = method(recs, *args, **kwargs)   File "/opt/simplerp/buildout/parts/misc-addons/reminder_base/reminder_base_models.py", line 157, in write     self._update_reminder(vals)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/api.py", line 266, in wrapper     return new_api(self, *args, **kwargs)   File "/opt/simplerp/buildout/parts/misc-addons/reminder_base/reminder_base_models.py", line 55, in _update_reminder     r._update_reminder_one(vals)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/api.py", line 266, in wrapper     return new_api(self, *args, **kwargs)   File "/opt/simplerp/buildout/parts/misc-addons/reminder_base/reminder_base_models.py", line 74, in _update_reminder_one     self._do_update_reminder(update_date=self._reminder_date_field in vals)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/api.py", line 266, in wrapper     return new_api(self, *args, **kwargs)   File "/opt/simplerp/buildout/parts/misc-addons/reminder_base/reminder_base_models.py", line 79, in _do_update_reminder     r._do_update_reminder_one(update_date=True)   File "/opt/simplerp/buildout/parts/SimplERP/openerp/api.py", line 266, in wrapper     return new_api(self, *args, **kwargs)   File "/opt/simplerp/buildout/parts/misc-addons/reminder_base/reminder_base_models.py", line 85, in _do_update_reminder_one     vals = {'name': self._get_reminder_event_name()[0]} TypeError: 'bool' object has no attribute '__getitem__'

Thank you. I applied recently script to fix Lint errors and in introduced this errors. I'll more carefull about it next time.
As for update. I've added a commit to fix lint warning
reminder_base/reminder_base_models.py:180: [C8108(method-compute), ReminderAdminWizard] Name of compute method should starts with "_compute_"

@ilmir-k kindly check reminder modules

:+1:

approved :+1:


Unimplemented rpc error for MaxBlobSize

something wrong rpc error: code = Unimplemented desc = unknown method MaxBlobSize for service da.DAService
10:12AM ERR DA layer submission failed error="unable to get DA max blob size" attempt=11 module=BlockManager

this is happening because celestia-da (main branch and last release) used go-da 57bc36006772 which does not have MaxBlobSize.
we should update this to use 93600f2 which has the api MaxBlobSize.

I have a PR , please review it -> https://github.com/rollkit/celestia-da/pull/40


decision: ui libraries/frameworks

for iteration speed, I'm happiest with react + https://mui.com/ + tsc type-checking of props which works great.


Ensure file structure is there in new Project

I noticed comparing the 2015 to 2016 repositories some stuff is missing.
Stuff like the build folder contents probably doesn't need to be copied over, but we might want to make sure all the folders, etc. are there so that nothing collapses
Especially stuff like the kaulilabs whatever folder which contains stuff for the NavX (are we using this again?)

I won't write this on the other project, because no one will probably see it, but I'm pretty confident that the Robot_2015/src/org/usfirst/frc/team2832/robot is obsolete and somehow kept getting overlooked, unless someone can show me otherwise, ignore that

yeah we added the navx stuff and it seems to work


invalid argument: could not find capabilities for domaintype=kvm

Version Reports:
Distro  version of host:
Debian 9
Terraform Version Report
Terraform v0.11.8
Libvirt version
4.8.0
terraform-provider-libvirt plugin version (git-hash)
 commit 8679775a0117011fbc47b9f3b330015e7779ee29 (HEAD, tag: v0.4.4)

Description of Issue/Question
Setup
resource "libvirt_domain" "jenkinsn" {
  name      = "jenkinsn"
  autostart = true

  cpu {
    mode = "host-passthrough"
  }
  vcpu    = 1
  memory  = 256

  disk {
    volume_id = "${libvirt_volume.jenkinsn_vol_root.id}"
    scsi      = true
  }
}

resource "libvirt_volume" "jenkinsn_vol_root" {
  name   = "jenkinsn_vol_root"
  size   = "${1 * 1024 * 1024 * 1024}"
  format = "qcow2"
}

Steps to Reproduce Issue
(Include debug logs if possible and relevant.)

Additional Infos:
I am running libvirt with qemu (without kvm) inside a VirtualBox VM. According to https://libvirt.org/drvqemu.html#prereq that should be perfectly fine as the host will check against /usr/bin/kvm for kvm capabilities.
However I am getting the following error:
* libvirt_domain.jenkinsn: Error defining libvirt domain: virError(Code=8, Domain=44, Message='invalid argument: could not find capabilities for domaintype=kvm ')

It would be great if one could set the type as specified here: https://libvirt.org/formatdomain.html#elements

https://github.com/dmacvicar/terraform-provider-libvirt/pull/431

for this custom feature we will take care soon on that PR

Hi @lifeofguenter, as @MalloZup mentioned you can change the domain using the xml/xslt feature.
Here's an example that worked for me to use qemu instead of kvm:
resource "libvirt_domain" "terraform_test" {
  name     = "terraform_test"

  xml {
    xslt = <<EOF
<?xml version="1.0" ?>
<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output omit-xml-declaration="yes" indent="yes"/>
  <xsl:template match="node()|@*">
     <xsl:copy>
       <xsl:apply-templates select="node()|@*"/>
     </xsl:copy>
  </xsl:template>

	<xsl:template match="@type[. = 'kvm']">
		<xsl:attribute name="type">
			<xsl:value-of select="'qemu'"/>
		</xsl:attribute>
	</xsl:template>
</xsl:stylesheet>
EOF
  }
}

I believe this issue could be closed?

True. Thx..!

Feel free to ask any add info here

I am not sure if I have the same scenario or not.
I am operating from a Fedora VM where I have also installed libvirt to build this plugins project.
I connect to a remote libvirt using virsh -c "qemu+ssh://<remote system>/system" and all that works fine.
When I try to use terraform to manage that remote libvirt system I get that error.
The remote system is newer and the versions of libvirt etc are newer
.terraform.d/plugins/terraform-provider-libvirt 6828269db97e943dad81219a41a16091b426f954
Compiled against library: libvirt 3.2.1
Using library: libvirt 3.2.1
Running hypervisor: QEMU 2.9.1
Running against daemon: 3.2.1

virsh -c qemu:///system version --daemon
Compiled against library: libvirt 4.0.0
Using library: libvirt 4.0.0
Using API: QEMU 4.0.0
Running hypervisor: QEMU 2.11.1
Running against daemon: 4.0.0

I hope there isn't an incompatibility there.
I have tried the above XML block and that did do the trick. I see though some time has past. Is that still the recommended solution? Or has there been a feature added where I can just call out some parameter in the libvirt_domain block? Either way I am fine, just trying to stay canonical to the plugin as it stands.
Thank you for your time.


Update virtual-machines-size-specs.md

Adding correct ARM naming for Standard tier sizes. (as seen by: azure vm sizes --location "West US").
Correct casing for A0-A4 when in ASM mode.

Hi @stuartpreston, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.
TTYL, AZPRBOT;

Thanks for this contribution - I'm sending for review to the article author.

I'm fine with these changes!


CHAOS-4155 runAsUser and runAsGroup

Describe how to use advanced options in a chaos experiment runAsUser and runAsGroup

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://65dc89138238d7bf718f1d30--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://65dd77dccfa6c0845b83dffb--harness-developer.netlify.app


[Distributed] Add more runtime distributed communication functions

We add the following communication functions related to distributed functionalities:
Runtime API
We mimic the APIs of  PyTorch's distributed package

all_reduce
broadcast
reduce
all_gather
all_gather_into_tensor
gather
scatter
reduce_scatter
reduce_scatter_tensor
barrier
send
recv

Hidet OPs

all_reduce
all_gather
reduce_scatter

We distinguish these two different usages of distributed primitives because many communication primitives cannot be directly viewed as nodes in computational graphs.
Still working on documentation and comments

The PR looks good to me, thanks @soodoshll !


gegl: 0.4.46 → 0.4.48

Description of changes

Fixes https://github.com/NixOS/nixpkgs/issues/290505
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[x] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review reveals no new failures, macos 12 x86_64 & nixos x86_64. pkgsi686Linux variant builds. Builds, aarch64-linux.


#24 Migrate to null-safety

Addressing Issue #24.
Successfully migrated the project to Null-Safety
Please let me know if I have to do further changes to get the Hacktoberfest Approval

No Problem
Thank you for your fast response

@jxstxn1 Sorry to tell you, this cannot be approved AFAIK, It has a big bug. Fix it and your PR will be accepted after the testing 😄

Yes Im fixing the AppTheme bug right now.
If there are any more bugs tell me

@jxstxn1 Sorry to tell you, this cannot be approved AFAIK, It has a big bug. Fix it and your PR will be accepted after the testing 😄

Yes Im fixing the AppTheme bug right now. If there are any more bugs tell me

yes there is. i can't record it(I don't have good app). Ping me in discord or Twitter(find in my profile)

I am sorry, but I don't have time to review the changes. They are a lot and need a lot of time.

I am sorry, but I don't have time to review the changes. They are a lot and need a lot of time.

@YazeedAlKhalaf  LOL, I can handle it but need a fix. This PR is not so stable. It is still buggy. I asked him to check it.

@jxstxn1
This PR has been sitting here for more than 2 months, I will close it for now but if you can enhance it or split it, it will be great.
Thanks a lot!


fix copy ruby version

This is a 🐞 bug fix.

[ ] I've added tests (if it's a bug, feature or enhancement)
[ ] I've adjusted the documentation (if it's a feature or enhancement)
[x] The test suite passes (run bundle exec rspec to verify this)

Summary
Fixes edge case for Jets Afterburner deploy mode. If the rails project has a .ruby-version then the deploy fails. This fixes it.
Context
Report: #363
Related: #317 #316 #313
Version Changes

Released in v2.1.7


--python vs --python-shebang

Hi,
I've looked at the docs and I'm still not clear about the difference between --python and --python-shebang when invoking pex. I'm sure it's obvious to folks intimately familiar with python, but it would be great if the docs explained gave examples of why you might want to set these.
For this example
pex -vv -f /tmp/wheelhouse --no-index \
  --python-shebang='???'
  "--python" "python36" "--python" "python37" "--python" "python38"

So the python shebang as I understand it advises which interpreter should be used, specifically that value given should either be a full path to a binary interpreter e.g. /usr/bin/python3 or a shorthand like python3 if that's already on the path, is there a standard? because what if they don't have it on the path, and how do you know which version the user might have installed? and that interpreter will be used, in which case why do you need the --python environment values?

I think the intent was to allow this pex to work with multiple versions of python, what should the python-shebang value be?
Is the python-shebang mandatory? If so why?
What happens if you set the python-shebang to be python3 as opposed to /usr/local/bin/python3
Is there a recommended value for python-shebang?
If I'm putting requirements together to run this pex for an end user, does the user have to ensure the python-shebang matches their installation location?
If they only have python39 installed, will it still work? If I set the shebang to python3 does that means it might still work as it launches any python3 environment so provided we're backward compatible it'll work?

1st, correcting your example: --python python36 should fail on most systems since Python tends to install its binaries as python, python[MAJ] and python[MAJ].[MIN] where [MAJ] is the major version (like 3 for Python 3.8.6) and [MIN] is the minor version (like 8 for Pyhton 3.8.6). Note that your example is missing the dot between major and minor version.
For convenient reference, the help for the --python option:
    --python=PYTHON     The Python interpreter to use to build the PEX
                        (default: current interpreter). This cannot be used
                        with `--interpreter-constraint`, which will instead
                        cause PEX to search for valid interpreters. Either
                        specify an absolute path to an interpreter, or specify
                        a binary accessible on $PATH like `python3.7`. This
                        option can be passed multiple times to create a multi-
                        interpreter compatible PEX.

On to shebang questions, with the help again for convenient reference:
    --python-shebang=PYTHON_SHEBANG
                        The exact shebang (#!...) line to add at the top of
                        the PEX file minus the #!. This overrides the default
                        behavior, which picks an environment Python
                        interpreter compatible with the one used to build the
                        PEX file.

The fundamental missing context appears to be how binaries get executed on Unix; so I'll lead with that:
Traditionally, on Unix, a file is executable if the appropriate mode bits are set and the contents is either a known executable file format (ELF, COFF, ... depends on the Unix) or else its a script. A script is denoted by #! as the leading bytes with the path to the interpreter to use to execute the script following that and ending in a newline. That line as a holw is commonly referred to as a "shebang" line (https://en.wikipedia.org/wiki/Shebang_(Unix)). So to make a script executable you need to set its mode to executable and insert a 1st line that is an appropriate shebang. Examples:

#!/bin/bash
#!/usr/bin/ruby
#!/usr/bin/python
#!/usr/bin/env bash

The only special thing here with respect to Python is the Python interpreter knows how to "run" a zip file and zipfiles allow arbitrary leading content to be inserted at the head of the zipfile; so Python scripts can be packaged as a zipfile:

https://www.python.org/dev/peps/pep-0441/
https://docs.python.org/3/library/zipapp.html

Now, you may have noticed that the shebang is host-dependant in that you must know the exact absolute path to the script interpreter to run. In example 4, reliance on the path of the env program is used so that the exact location of bash need not be known (env looks it up in the PATH at runtime). Still though, this is fairly non-portable and depends on uniform paths with uniform meanings across machines. To stress the latter point, a given path /usr/bin/python3 could have two different meanings on different machines. The path could refer to a Python 3.6 interpreter on one machine and a Python 3.9 interpreter on another.
You edged up on many of these points in your questions above, but I think the following should now be answered:

I think the intent was to allow this pex to work with multiple versions of python, what should the python-shebang value be?
It needs to be the common denominator. If you build the PEX to run with various Python 3's, say 3.6 through 3.9, then you'd want a shebang of #!/usr/bin/python3 or #!/usr/bin/env python3.
Is the python-shebang mandatory? If so why?:
Yes, since a PEX is just a zipapp and not a valid ELF, COFF, etc executable file.
What happens if you set the python-shebang to be python3 as opposed to /usr/local/bin/python3:
The OS will reject a relative path for the shebang interpreter.
Is there a recommended value for python-shebang?
Not when customizing - no. Since a shebang relies on the setup of a target machine, you need to take that into account when picking a custom shebang. When you let Pex pick the shebang, of course its pick should suffice.
If I'm putting requirements together to run this pex for an end user, does the user have to ensure the python-shebang matches their installation location?:
Yes - sortof. The shebang must match a path on the target machine.

The final question though has little to do with the shebang:

If they only have python39 installed, will it still work? If I set the shebang to python3 does that means it might still work as it launches any python3 environment so provided we're backward compatible it'll work?
It depends. If the PEX includes platform-specific wheels, say numpy, then it will not work. The numpy-1.19.4-cp37-cp37m-manylinux2010_x86_64.whl and numpy-1.19.4-cp38-cp38-manylinux2010_x86_64.whl wheels installed in the PEX file will not be usable for Python 3.9 regardless of shebang.

Resetting and explaining at a high level in sequence of execution:

The shebang is required by the operating system and it is used to run the PEX zipfile.
*2. The PEX main is a bit of Pex code that 1st finds an appropriate interpreter to use if the current one selected by the shebang is not appropriate. If a new interpreter is selected, the PEX file is re-executed with that interpreter.
The PEX main extracts all wheels installed inside the PEX file to the filesystem (under ~/.pex) and adds these locations to sys.path before handing off execution to user code.

Currently step 2 only happends if you use --interpreter-constraint to select interpreters when building the PEX. It does not happend when you use --python to select interpreters. Fixing that will come in #1020.

Sorry for the delay in responding, this is an incredibly detailed response, thank you so much for providing such an excellent guide. I've had a crack at applying the details above, and it seems to work, I'll post a summary of what I picked at some point for completeness in case others are interested.


[Improvement] The consistency update

With more and more contributors joining in and the amount of new syntax being made, I thought this was a good time to make everything consistent again. I basically ordered every syntax class again to match the ordering in the lang package.
I also made some changes to the conventions file to specify this ordering. I know this may limit coding, but for me, it's such a small thing that can actually help future contributors to easily make changes to existing classes.

Going to completely redo this since the new optional branch conflicts with many classes.


azcosmos: it seems that NewQueryItemsPager retrieves documents from multiple partitions

Bug Report

import path of package in question: github.com/Azure/azure-sdk-for-go/sdk/data/azcosmos
SDK version:v0.3.3
output of go version: "1.20.2"

The documentation for NewQueryItemsPager states that it returns results limited to a single partition, and that is the behavior I desire.
However, I am getting results from multiple partitions.
These are (2 of) the test documents within the collection:
{
    "id": "cosmosdb-sidecar-7a0d0502-6acd-4e9a-b80a-23bc5a30a068||bulk-nopk||1",
    "value": "cosmosdb-sidecar-7a0d0502-6acd-4e9a-b80a-23bc5a30a068||bulk-nopk||1",
    "partitionKey": "cosmosdb-sidecar-7a0d0502-6acd-4e9a-b80a-23bc5a30a068||bulk-nopk||1",
}

{
    "id": "cosmosdb-sidecar-7a0d0502-6acd-4e9a-b80a-23bc5a30a068||bulk-pk||1",
    "value": "cosmosdb-sidecar-7a0d0502-6acd-4e9a-b80a-23bc5a30a068||bulk-pk||1",
    "partitionKey": "cosmosdb-sidecar-7a0d0502-6acd-4e9a-b80a-23bc5a30a068",
}

(I've omitted the internal properties)
This is the query I run:
pager := c.client.NewQueryItemsPager("SELECT * FROM r WHERE ARRAY_CONTAINS(@keys, r.id)", pk, queryOpts)

Where:

pk is an object containing the string cosmosdb-sidecar-7a0d0502-6acd-4e9a-b80a-23bc5a30a068
queryOpts defines the query parameter @keys and sets that to []string{"cosmosdb-sidecar-7a0d0502-6acd-4e9a-b80a-23bc5a30a068||bulk-pk||1", "cosmosdb-sidecar-7a0d0502-6acd-4e9a-b80a-23bc5a30a068||bulk-nopk||1"}

I would expect to retrieve only the key containing bulk-pk, since it's the only one with that partition key. Instead, surprisingly I'm getting back the other key too.
It seems that this is performing cross-partition queries.

The REST API request passes the Partition Key header and our tests cover exactly that behavior: https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/data/azcosmos/emulator_cosmos_query_test.go#L86 (the test creates 2 sets of documents and queries on a single pk).
The code is not passing the Cross Partition Queries header (https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/data/azcosmos/cosmos_query_request_options.go#L40-L72)
Query resolution then it's up to the service.
What is the Partition Key Definition for this container?

This is very odd then. Is it because my query uses ARRAY_CONTAINS maybe?

What is the Partition Key Definition for this container?

/partitionKey

I created a test suite that mirrors what is described in the issue and the test only gets 1 document:
https://github.com/ealsur/azure-sdk-for-go/commit/6051edfdfe047c840ea79fbb0dfec71fe96bc8ea

Uhmmm I'd be damned, I can't repro the issue anymore now, even though it happened consistently last night.
Maybe it was a service issue? Something transient?
Anyways, thanks for checking as well. I'll close this issue.

Will do.
In the meanwhile, I've used this as an opportunity to implement some additional checks. So if for whatever reason we were to get back records from a different partition, they'd be ignored and wouldn't cause Dapr to crash like before.

I like to call these fixes "787-style", where we don't know what causes them or how to prevent them, but at least we mitigate them if they were to happen 🤣

@ItalyPaleAle could it be that Dapr is setting the cross-partition header in the request and that might cause this behavior? https://github.com/dapr/components-contrib/blob/8488a78dd7598992ce597e8f7a16ee2824bac97e/state/azure/cosmosdb/cosmosdb.go#L92

@ealsur I think you're right. That was meant to only apply to some scenario, but it looks like it was implemented "globally" on the client.
Good catch, that would explain what's going on. Thanks!


Help: Zeit Now V2 Deployment

Does anyone have experence deploying Yoga 2 to Now V2. I have been trying on and off for a week  now with no avail. Below is my now.json
{
  "name": "api.domain.com",
  "alias": ["api.domain.com"],
  "version": 2,
  "builds": [{ "src": "dist/src/index.js", "use": "@now/node-server" }],
  "routes": [
    { "src": "/.*", "dest": "dist/src/index.js"}
  ]
}

I've been working for about two weeks on deploying to Now v2 also.
I've now gotten a Now customer service employee helping me figure out why the deployment isn't working correctly.
So far, the issues seems to be with NCC and on Now's side. However, they are looking at one more deployment of a yoga2 server that did work.
I might know more today; I'll keep this comment updated as I learn more.

Ok awesome, this has been driving me nuts!!
I am looking in to implementing apollo-server-lambda in to yoga2, do you think that this would be worth while?

Hey 👋,
Could you please provide a bit more context? We have deployed a yoga2 server using the very same now.json file as you do and had no issue doing so

I've been trying to deploy this project. However, an employee at Zeit tells me it keeps erring out due to NCC not working correctly.

Hey @DevanB, Have you heard back from Zeit?

Nope no response. I know another developer I was talking to deployed a yoga2 server with no luck also.
@weakky - I deployed your Prisma e-commerce branch and it deployed, but doesn’t work correctly. For instance, you can’t hit the playground and seems you can’t make any requests into it.

Hey @DevanB, what output do you get when running now dev bear in mind that this only work on mac and linux atm. If you are on windows you can use wsl

@williamluke4 I actually got it working with node dev last night. But still no luck deploying

Running now dev should give you a better idea of why it is not working when deployed. Just want to check to see if it is the same error that I am receiving

Yep, except for running now dev works, but deploying fails with no errors.

On Apr 15, 2019, at 10:48 AM, William Luke<EMAIL_ADDRESS>wrote:
Running now dev should give you a better idea of why it is not working when deployed. Just want to check to see if it is the same error that I am receiving
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/prisma/yoga2/issues/130#issuecomment-483283532, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVpXM6UMrMiiy_q70b28vPPZKFZo6a4ks5vhJFLgaJpZM4cpQCk.

Have you tried accessing the playground after running it

That is very weird as now dev uses ncc

There are two things to take into consideration here:

The playground is disabled by default by apollo-server when NODE_ENV=production
Introspection queries are also disabled when NODE_ENV=production

One workaround for now is to eject and set playground: true in the apollo-server instantiation.
Regarding the ncc error, there's nothing I can do without any logging. Someone recently reached to me for deploying yoga to now2 and succeeded without issue (once he knew he had to manually force playground: true)

@Weakky, Correct... I have tried with both introspection enabled and disabled; The same for the playground

Here are the logs
will@DESKTOP-4LJJ71K:/mnt/c/Users/willi/Documents/Atto-Byte/Development/api-server$ now dev
 > No existing credentials found. Please log in:
We sent an email to<EMAIL_ADDRESS>Please follow the steps provided
inside it and make sure the security code matches Famous Dragon.
✔ Email confirmed
Ready! Authentication token and personal details saved in "~/.now"
will@DESKTOP-4LJJ71K:/mnt/c/Users/willi/Documents/Atto-Byte/Development/api-server$ now dev
Running initial builds
downloading user files...
installing dependencies for user's code...
installing to /tmp/co.zeit.now/dev/workPaths/rrlku858/user/dist/src
 ><EMAIL_ADDRESS>postinstall /tmp/co.zeit.now/dev/workPaths/rrlku858/user/node\_modules/protobufjs
node scripts/postinstall
npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node\_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
added 1029 packages from 704 contributors in 134.974s
writing ncc package.json...
installing dependencies for ncc...
installing to /tmp/co.zeit.now/dev/workPaths/rrlku858/ncc
yarn install v1.10.1
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
warning Your current version of Yarn is out of date. The latest version is "1.15.2", while you're on "1.10.1".
info To upgrade, run the following command:
$ curl --compressed -o- -L https://yarnpkg.com/install.sh | bash
Done in 11.51s.
running user script...
preparing lambda files...
compiling entrypoint with ncc...
ncc: Version 0.17.3
ncc: Compiling file index.js
ncc: Module directory "/tmp/co.zeit.now/dev/workPaths/rrlku858/user/node\_modules/ws/lib" attempted to require "bufferutil" but could not be resolved, assuming external.
ncc: Module directory "/tmp/co.zeit.now/dev/workPaths/rrlku858/user/node\_modules/ws/lib" attempted to require "utf-8-validate" but could not be resolved, assuming external.
ncc: Module directory "/tmp/co.zeit.now/dev/workPaths/rrlku858/user/node\_modules/subscriptions-transport-ws/node\_modules/ws/lib" attempted to require "utf-8-validate" but could not be resolved, assuming external.
ncc: Module directory "/tmp/co.zeit.now/dev/workPaths/rrlku858/user/node\_modules/subscriptions-transport-ws/node\_modules/ws/lib" attempted to require "bufferutil" but could not be resolved, assuming external.
downloading user files...
installing dependencies for user's code...
installing to /tmp/co.zeit.now/dev/workPaths/pemcn11o/user/dist/src
 > Success! Initial builds completey-parser: sill tarball trying<EMAIL_ADDRESS>by hash: sha512-bn71H9+qWoOQKyZDo25mOMVpSmXROAsTJVVVYzrrtol3d4y+AsKjf4Iwl2Q+IuT0kFSQ1qo166UuIwqYq7mGnA==
Ready! Development server running at http://localhost:3000
 ><EMAIL_ADDRESS>postinstall /tmp/co.zeit.now/dev/workPaths/pemcn11o/user/node\_modules/protobufjs
node scripts/postinstall
npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node\_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
added 1029 packages from 704 contributors in 146.816s
writing ncc package.json...
installing dependencies for ncc...
installing to /tmp/co.zeit.now/dev/workPaths/pemcn11o/ncc
yarn install v1.10.1
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 1.21s.
 > GET /
GraphQL Nexus: Unable to find file or module /tmp/zeit-fun-50baea9e77c81/user/dist/src/context.ts, skipping
GraphQL Nexus: Unable to find file or module /tmp/zeit-fun-50baea9e77c81/user/dist/.yoga/prisma-client/index.ts, skipping
Missing required typegen import: ctx
POST /
Error: Body exceeded 1mb limit
at f (/snapshot/repo/dist/index.js:1:2075329)
at module.exports.7487.t.buffer.Promise.resolve.then.a.then.catch.e (/snapshot/repo/dist/index.js:1:2076888)
at process.\_tickCallback (internal/process/next\_tick.js:68:7)
Error: Unexpected /invocation/response response: {"statusCode":413,"headers":{"content-length":"23","date":"Mon, 15 Apr 2019 12:53:35 GMT","connection":"close"},"body":"Body exceeded 1mb limit"}
at /home/will/src/runtimes/nodejs/bootstrap.ts:155:9
at Generator.next (<anonymous>)
at fulfilled (/home/will/.cache/co.zeit.fun/runtimes/nodejs/bootstrap.js:4:58)
at <anonymous>
at process.\_tickCallback (internal/process/next\_tick.js:188:7)
LambdaError: RequestId: 3f2afa08-8744-44d8-9b13-7e15a576dcee Process exited before completing request
at Lambda.<anonymous> (/snapshot/repo/dist/index.js:1:1987524)
at Generator.next (<anonymous>)
at fulfilled (/snapshot/repo/dist/index.js:1:1985705)
at process.\_tickCallback (internal/process/next\_tick.js:68:7)

Error: Body exceeded 1mb limit
Isn't your issue related to that? https://github.com/zeit/now-cli/issues/1127

Yes but this is the error when run locally when deployed the error seems to be different. The Introspection and Playground works when deployed but queries return Only absolute URLs are supported

Not exactly relevant here but because Zeit is moving to serverless with V2 and doesn't exactly fit the GraphQL model right now, I'm going to try moving to Google Cloud Run which is a Serverless Docker offering. A lot like the serverless docker offering that Zeit offered at one point.

@andyk91 Could you let me know how you get on :)

Now + GraphQL are headed in opposite directions and that's ok.
Heroku is a good option for deploying yoga2.

Now + GraphQL are headed in opposite directions and that's ok.
Heroku is a good option for deploying yoga2.

That's not true, why are they heading opposite directions? There is an open issue https://github.com/prisma/yoga2/issues/14 and the plan is to build yoga with ncc, which make the whole thing serverless.
It's not a problem to eject yoga and build it with ncc even now I believe.

@yakovlevyuri I don't get the whole serverless push and then all these monolithic GraphQL servers dotted around. If they can make my resolvers lambdas that would be a great paradigm shift, until then, how's Heroku any different to using @now/node-server?

To each their own, and this isn't an issue to discuss who prefers what. This issue is titled "Help: Zeit Now V2 Deployment", not "Let's discuss open-endedly about the future of GraphQL, Serverless, Hosting, and What Provider We Prefer".
In fact, there a more relevant issue for that discussion over at #14. @williamluke4 and I are on a mission to help the Zeit team, and future yoga2 users deploy to Zeit v2. So no need to muck up this issue with your opinions on non-relevant topics.

 Good luck on your mission!

@DevanB not sure if you figured out how to get it working or not but I believe I did and will post here in case anyone else is looking for help.
You can test the api running on now with the following CURL request:
curl \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{ "query": "{ hello(name: \"Andy\") }" }' \
  https://profile-api.andykay.now.sh

You can also see my setup here: https://github.com/andyk91/profile.im . Yoga2 is in /api.
I might not leave yoga2 in my project though so I think the main two pieces are my now.json file:
{
  "version": 2,
  "name": "profile-api",
  "build": {
    "maxLambdaSize": 50
  },
  "builds": [
    {
      "src": "dist/src/index.js",
      "use": "@now/node-server",
      "config": {
        "maxLambdaSize": "50mb"
      }
    }
  ],
  "routes": [{ "src": "/.*", "dest": "dist/src/index.js" }]
}

and my .nowignore file:
*
!package.json
!dist
!dist/**

I made another repo dedicated to this issue plus a www folder with nextjs + typescript + apollo

I was able to get my server to deploy by adding introspection: true to the ApolloServer options.