text:
Handling Dynamic Data Sources with unknown ABIS

Right now we can't run dynamic data sources for reading symbol() and decimal() and name() for all the tokens on Uniswap.
This is because Uniswap does not do any checking to see what contracts are stored in its Factory contract as a "Uniswap Exchange." This has led to the fact that the Graph Node will crash when trying to read symbol and decimal.
The feature I am requesting is this: have functionality in the mappings to call into a contract and see if a function exists. It might look something like this:
import {functionExists} from '@graphprotocol/graph-ts'
import ......

export function handleNewExchange(event: NewExchange): void {
  let id = event.params.exchange.toHex()
  let exchange = new Exchange(id)
  let erc20contract = ERC20.bind(event.params.token)

  if (erc20contract.functionExists("symbol")) {
    exchange.decimal = erc20contract.symbol()
  } else {
    exchange.decimal = null
  }
}

This is causing a blocker on Uniswap as I can't index all the exchanges for their symbol and decimal and these are important for the data, otherwise it gets confusing what you are looking at. I could hard code them all, but thats over 250 exchanges, and it isn't a long term solution.

First thoughts on this:

erc20contract.symbol() wouldn't work if the ERC20 ABI doesn't have symbol. We can't generate code for functions that don't exist.

functionExists("symbol") won't be good enough, because symbol may have different signatures in different contracts. It would have to be .hasFunction("symbol()"), so a check that includes the full function signature.

I'm not sure yet how we'd even detect whether a contract on chain has a certain function. Is that even possible? If not, how about a different approach:
let result = erc20contract.tryCall("symbol", []) // Parameters are Value[]
if (result !== null)
  exchange.symbol = result.toString()
}

The tryCall function would have to return a low-level Value because we have no type hints without knowing the ABI.

There is another option: Generate try<FunctionName> variants for all functions in all ABIs, add an ABI that includes a definition for symbol(), and then do
let contract = WithSymbol.bind(event.address)
exchange.symbol = contract.trySymbol() // returns `null | string`

@leodasvacas Since we've both worked on the TS API a bunch, what do you think?

@Jannis I searched a bit, to implement functionExists we'd need to somehow get the ABI, which doesn't seem possible in this case. A alternative would be do to bytecode analysis somehow, which would be complicated and probably unreliable. Which leaves us with your suggestion of trying to call the method.
My concern with trying to call is whether we can know if the call failed for a deterministic reason. If we cannot tell transient failures from a missing method failure, that API would bring up the same determinism issue we have with IPFS. But it's probably possible to tell if the web3 error was a network failure or an error returned by the ethereum node, which should be good enough for us.
I don't think codegen bloat is a concern for us, so my preference is for generating try variants for all calls.

Can we push this up the list and get it done this week? The plan right now is to show the updated Uniswap subgraph to them next Monday. Let's figure this out tomorrow morning!

I did a quick test to see what sort of error eth_call returns, and it simply returns 0x on an invalid call. The reasons for this can be non-determinstic. I don't see any tools we can use to reliably and deterministically tell if a contract implements a given method.
@davekaj we need a source of truth for which contracts implement these interfaces, be it hardcoded, in IPFS or on-chain. Ideally Uniswap would have interfaces for those methods and mandate that the exchanges implement ERC-165, but that doesn't seem to be the case.

Yeah, I see your point.
It would be useful if Uniswap had used ERC-165.
Is it possible to still try and call the function, and if it fails - we just leave it out, even though it is non-deterministic?  I am wondering for this reason:

I would guess that 277/280 of the contracts DO have symbol(). Whether or not it fails, or succeeds, I can write the mappings to handle both. The problem is the graph node just crashes.
I could get a source of truth for IPFS or On-chain, or hardcode the 280 myself, but then it wont be able to dynamically add contracts. I just want to run that function call, and if it doesn't return a value, not have the graph node crash, so I can handle it

Is this possible? Or can we not bring in this non-determinism into the graph node?

@davekaj We don't have precedent for successful, non-deterministic indexing. To decide for some sort of exception here, a wider discussion would be necessary.

Okay cool, so the question now becomes:

Can we have this wider discussion this week and come up with a solution that works before Monday when presenting to uniswap. (Also dependant on how long it takes us to implement what we decide)
Or do I just work around it for now. I can work around it - it would make it the subgraph only slightly less good. But it would still be the best way to get data on Uniswap out there so I would be okay releasing it.

I am going to relay this back in the engineering chat so we can decide quickly

Actually I've changed my mind - the subgraph will still be very good, its just a small implementation detail. I can work around it, and then a small update can be pushed in the future. We have pushed small updates to Compound so it is normal for this to happen.
So I am going to say we do not have to figure this out by monday, but we still have to figure it out - the sooner the better though!

👋🏻 noah from uniswap here, just read through the thread, please let me know if there's anything i can do to help on my end!

initially I thought we couldn't solve this since the Geth RPC response is too generic, but depending on what Parity responds it might be possible to solve this.

It turns out that, at least for Parity, the response for a missing method is the same as when the call reverts, so this was the same as #1139 which is fixed. Yay!

authors: Jannis NoahZinsmeister davekaj leodasvacas leoyvens

repo: graphprotocol/graph-node


text:
Add the feature to support theme for button in Banner block and align for image (i.e. left, center, right)

Image should be aligned to left/center/right, because after changing page size we want to able to user focus on specific part of image.

How will this be indicated in the backoffice markup? Сould there be a need to do this vertically too?
We have a MediaView: fit/fill setting in the HeaderBlock https://preview.gravity-ui.com/page-constructor/?path=/story/blocks-header--media-view-fit. Maybe this setting will be useful to you? It's not there now, but it can be reused.

#794

How will this be indicated in the backoffice markup? Сould there be a need to do this vertically too? For example: top; bottom.
We have a MediaView: fit/fill setting in the HeaderBlock https://preview.gravity-ui.com/page-constructor/?path=/story/blocks-header--media-view-fit. Maybe this setting will be useful to you? It's not there now, but it can be reused.
It would be good to implement this within the same approach for similar cases.

ok, we can use MediaView like in Header block, this is acceptable for our requirments. full will work like it works right now. Fit - media content has real sizes and locates in the middle

source: gharchive/issue

repo: gravity-ui/page-constructor

license: MIT

license_type: permissive

license_source: github-api


text:
RequestBodyTooLarge while uploading data into azure storage

I am trying to upload a file of size 260M using stow on azure storage and the operation fails with below error. I was wondering if we have to use multipart upload  or there is something else that can be done.
unable to create or update Item: storage: service returned error: StatusCode=413, ErrorCode=RequestBodyTooLarge, ErrorMessage=The request body is too large and exceeds the maximum permissible limit.

I was using my fork's code and that didn't have the multipart feature from upstream.

repo: graymeta/stow

license_source: bigquery


text:
Check memory consumption on large lists of targets

EMCEE and matplotlib figure instances are possible sources of memory leaks.
Check if this becomes an issue for large jobs ~100 tgts or more.
A small leak may be tolerable.

So I recall from a previous project that, when running a bunch of MCMC stuff in a loop in a Jupyter Notebook, the memory isn't properly recycled until you exit the notebook. I'm not sure whether this is also the case if the MCMC code is done by a package written in .py though.

Never use ipynb for big runs :)
It does get better when running emcee in a .py compared to ipynb, but emcee
still has some issues. Feel like we need to find someone who knows stuff
about memory handling in python.
On Wed, 24 Jul 2019, 12:03 Oliver Hall, notifications@github.com wrote:

So I recall from a previous project that, when running a bunch of MCMC
stuff in a loop in a Jupyter Notebook, the memory isn't properly recycled
until you exit the notebook. I'm not sure whether this is also the case if
the MCMC code is done by a package written in .py though.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/grd349/PBjam/issues/64?email_source=notifications&email_token=AEJWO3YQQYCNRC676YIOLP3QBB4OVA5CNFSM4HT4NOPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2W2BDI#issuecomment-514695309,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEJWO33MG67SX4ZVKK3P5BDQBB4OVANCNFSM4HT4NOPA
.

DFM will be here tomorrow! 😁

I don't think we have seen any issues here - I'm closing until someone says there is a problem.


text:
Create Contribution Template

Create templates for contributions

Add code of conduct file
https://www.contributor-covenant.org/version/2/1/code_of_conduct/code_of_conduct.md

repo: greenchapel-dev/Serverlytics


text:
Add acknowledgements section

This is a proposed acknowledgements section for our manuscript which we'd like to submit to PeerJ Preprints on Monday. @cgreene mentioned that their is a custom to seek approval before mentioning an individual in acknowledgements. While I disagree with this practice, since the contributions were made publicly and our appreciation stands regardless, I thought we might as well ask.
@blahah @rossmounce @gcabanac: please respond whether or not you are okay with being acknowledged in the following way.

@dhimmel I'm happy and grateful to be acknowledged.
I'd add that there are definitely situations when people might not want acknowledgement in a paper even after making public contributions - for example if they are being harassed or sued,  and further mentions on different platforms increase their exposure - so I also appreciate being asked and would urge you to always do this.

I'd add that there are definitely situations when people might not want acknowledgement in a paper even after making public contributions - for example if they are being harassed or sued, and further mentions on different platforms increase their exposure - so I also appreciate being asked and would urge you to always do this.

Thanks for your thoughts @blahah. In that case, I should also add that you can respond privately by emailing me at daniel.himmelstein@gmail.com, as I can imagine circumstances where public discussion may defeat the purpose of the consent process.

very happy to be acknowledged for what little I have contributed so far @dhimmel

Thanks for the acknowledgement. I wish you good luck with this amazing paper!

source: gharchive/pull-request

authors: blahah dhimmel gcabanac rossmounce

repo: greenelab/scihub-manuscript


text:
PR: feature: Implement caddyfile.Unmarshaler interface

The PR #76 brings the implementation of the caddyfile.Unmarshaler{} interface to caddy-auth-jwt.
The same logic as this PR was applied and func parseCaddyfile was split into two subs:

parseCaddyfile creates an instance of authz.Authorizer by parsing the Caddyfile format
getMiddlewareFromParseCaddyfile wraps it in the caddyauth.Authentication middleware

Then the interface implementation UnmarshalCaddyfile(d *caddyfile.Dispenser) only calls the parseCaddyfile() func.
Patch has been tested, and unit tests are still passing:
ok  	github.com/greenpau/caddy-auth-jwt	5.396s
ok  	github.com/greenpau/caddy-auth-jwt/internal/tag	0.164s
?   	github.com/greenpau/caddy-auth-jwt/internal/tests	[no test files]
?   	github.com/greenpau/caddy-auth-jwt/internal/testutils	[no test files]
ok  	github.com/greenpau/caddy-auth-jwt/pkg/acl	0.156s
ok  	github.com/greenpau/caddy-auth-jwt/pkg/authz	0.067s
ok  	github.com/greenpau/caddy-auth-jwt/pkg/cache	0.943s
?   	github.com/greenpau/caddy-auth-jwt/pkg/errors	[no test files]
?   	github.com/greenpau/caddy-auth-jwt/pkg/handlers	[no test files]
ok  	github.com/greenpau/caddy-auth-jwt/pkg/kms	1.097s
ok  	github.com/greenpau/caddy-auth-jwt/pkg/options	0.039s
?   	github.com/greenpau/caddy-auth-jwt/pkg/shared	[no test files]
ok  	github.com/greenpau/caddy-auth-jwt/pkg/user	0.062s
?   	github.com/greenpau/caddy-auth-jwt/pkg/utils	[no test files]
ok  	github.com/greenpau/caddy-auth-jwt/pkg/utils/cfgutils	0.036s
?   	github.com/greenpau/caddy-auth-jwt/pkg/utils/urlutils	[no test files]
ok  	github.com/greenpau/caddy-auth-jwt/pkg/validator	0.347s

@golgeek , thank you! 👍

authors: golgeek greenpau

repo: greenpau/caddy-auth-jwt


text:
Complete the XmlMapping tests for XSD validation in #6728

Fix the DDC889 tests which were failing after the removal of the related XML mapping files.
This commit restores them and also adds more mapping files to test.
Furthermore, a new test is added to check the invalid use cases with DOMDocument.

Thanks! I'll try to take a closer look tonight!


text:
Add Getting Started section to README

README Update
Please add a getting started section to the README so folks know how to start with this project.

Added Getting Started section in README file.


text:
java.lang.reflect.invocationtargetexception

Getting target exception in the XML mentioning library <com.agog.mathdisplay.MTMathView  when compileSdkVersion and targetSdkVersion increasing to 30 and 31  may be in jcenter and maven { url "https://jitpack.io" }  is deprecated in api level 30 and 31.  Dependency is not working increasing api level please take it as a priority and fix the issue.

Can be related to: https://github.com/gregcockroft/AndroidMath/issues/10

authors: iGuru-iOS uburoiubu

repo: gregcockroft/AndroidMath

license: mit


text:
Soundcloud music links no longer working

Looks like we are no longer able to play music from Soundcloud. No matter what is entered, the page displays: not a valid soundcloud url? From the dev tools console, looks like it may be an authorization or CORS policy error.

😢
asking here https://github.com/soundcloud/api/issues/100

Facing the same issue. :(

Shadertoy has the same issue. Might be on soundcloud side...

Hey @greggman !! I went through the soundcloud thread and i know you are working on this issue. :) Just checking, if you can provide any ETA. :P

I can't give you an ETA. I tried to fix it and ran into a brick wall. If you want to help get 1000s of people to complain on this issue

I can try and get few comments on that post, hope that helps. :)
I cloned this repo and hosted it locally.. But i'm unable to play with shaders that are on your website on my local setup.
What is the best way to play shaders present on website on local visualizer

repo: greggman/vertexshaderart


text:
Invalid date format used in serialized JSON

Nuget Package
JsonSchema.Net
Package Version
5.5.0
Operating System
Windows
.Net Target (if relevant, please specify the version in the description)
.Net (5 or after)
A clear and concise description of the bug.
Imagine the following YAML..
Example date: 2023-10-12

.. is deserialized into an object defined as follows:
    public class ExampleClass
    {
        [YamlMember(Alias = "Example date")]
        public DateOnly ExampleDate { get; set; }
    }

With an instance of the above instantiated as "myExample", we convert to JSON as follows:
var serializer = new SerializerBuilder().JsonCompatible().Build();
var json = serializer.Serialize(myExample);

Result:
{"Example date": "10/12/2023"}

The above result is invalid because the date is formatted incorrectly.
What did you expect?
The resultant JSON should pass validation against the following JSON schema:
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "Example date": {
      "type": "string",
      "format": "date"
    }
  },
  "required": ["Example date"]
}

As such, the following result, which passes validation, is expected:
{"Example date":"2023-10-12"}

Please add test code or steps to reproduce the behavior.
I used the following site to validate the JSON in this example:
https://www.jsonschemavalidator.net/
Is there any other information you'd like to share regarding this bug?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hey there. I'm not sure what you're expecting from this library.  It seems you're reporting that the date not being serialized correctly is the bug, but this library doesn't have anything to do with how a date is serialized.

Indeed @gregsdennis, I accidentally opened this issue in the wrong repo, please accept my apologies.

No worries. Let me know if I can help with anything, even wherever this is supposed to go.

repo: gregsdennis/json-everything


text:
error: unknown option `--visualise'

I dont know what Im doing wrong, but i always get this message

what version of parcel are you using?

Not sure how long it'll take for the parcel change so Ive completely removed the --visualise cli arg for now.
Thanks for the heads up on the problem!

thanks @gregtillbrook !

ENV vars for a temp workaround?

@gregtillbrook Honestly I don't think the plugin overhaul will be done anytime soon. 😟
As @TimNZ mentioned, env vars might be the only workaround for now 😬

@TimNZ ENV is an interesting workaround idea - Id rather not have the usage keep changing though so think I'll drop the --visualise bit for now and revisit when parcels updated. If it proves a nuisance and folks complain, i'll look at it again.
Thanks for the heads up @davidnagli

Plenty of tools support CLI and ENV for option setting, you can support both when CLI works?

Hi @davidnagli.  CLI vs ENV comment was for @gregtillbrook
There are definitely other things the Parcel team should be prioritising. Thanks

authors: TimNZ davidnagli gregtillbrook xDae


text:
SNMPv3 support

Hi,
Can I please know whether SNMPv3 will be available soon?
mathew

Thanks for the feedback.  I wrote this a while back and I suppose v3 support should be added.  I'm not sure how soon I'll have some free time to work on that.  I'll try to get around to it in the next few weeks.

authors: grelleum mathewfer


text:
Prevent TypeError from unknown kwarg

Minor change to the kwarg for menu creation as specified in PyQT docs to prevent unknown kwarg errors.
https://doc.qt.io/qt-5/qactiongroup.html#exclusionPolicy-prop
https://doc.qt.io/qt-5/qactiongroup.html#ExclusionPolicy-enum

Thanks for fixing this!

authors: DiiSollertia grero

repo: grero/PanGUI


text:
Add genetic algorithm engine

Hi @greschd, I have a genetic algorithm workflow in my pseudopotential optimization plugin https://github.com/unkcpz/aiida-opsp which share and borrow lots of concept from this repository. I am thinking to separete and implementing genetic algorithm here and call aiida-optimize from my plugin. Leave only pseudo related code in aiida-opsp.
But I working on aiida-opsp from develop branch aiida-core and compatible with just released aiida-core 2.0.0.
What is your opinion on processing this? I can either change my code to be compatible with aiida-1.x (then not compatible with 2.x). Or try to migrate aiida-optimize to compatible with aiida-core 2.x.
I go through the code here and find the difficulty of the second option comes from there are also dependencies of aiida-pytest and aiida-tools. I think some fixture in aiida-pytest is now in aiida-core, but still some are special in aiida-pytest. Could you explain a bit about concept of aiida-pytest and your opinion in how it should be updated? I am happy to help and work on that.

I am thinking to separete and implementing genetic algorithm here and call aiida-optimize from my plugin.

I think that'd be great!

What is your opinion on processing this? I can either change my code to be compatible with aiida-1.x (then not compatible with 2.x). Or try to migrate aiida-optimize to compatible with aiida-core 2.x.

From my point of view, it doesn't make sense to change code which is already 2.x compliant back to 1.x. So, I'd prefer making aiida-optimize 2.x compliant.
I'm not all too familiar with the backwards-incompatible changes in 2.x: Do you think it's feasible to make aiida-optimize compatible with both 1.x and 2.x?
Since aiida-optimize has just had a release, I'd guess we could also drop 1.x on the next one. @bosonie what's your opinion on that?
As for the dependencies:

aiida-pytest was a precursor to the fixtures in aiida-core and aiida-testing. Long-term, the goal is to remove it. For some of the parts in aiida-pytest which have an equivalent in aiida-core, I have already changed aiida-pytest to be just a small wrapper around the built-in fixtures.
If you want to take the time to see how / if the aiida-pytest fixtures could be replaced, I'm all for it. Otherwise, I could have a look at what it takes to migrate aiida-pytest to 2.x.
aiida-tools is just a small collection of helpers I used across some of my plugins. For aiida-optimize, we use check_workchain_step, and the aiida_tools.process_inputs module:

check_workchain_step emits a self.report if an error occurs in a workchain step. I'm wondering if this is still needed, or if the current AiiDA version does this anyway. If memory serves me right, this is pre-1.x code.
process_inputs allows passing a process as an input (converts it to Str, and then back to the object). I would be tempted to just include that code (if it's still needed, I'm not up-to-date with the newest AiiDA changes..) in aiida-optimize directly. There's only one other plugin that uses it AFAIK, and that depends on aiida-optimize anyway.

Hi all,
I completely agree to port aiida-optimize to aiida 2.0. It is actually needed anyway since I'm preparing the aiida-siesta for 2.0 and it will require aiida-optimize to be compatible. The next release can already drop 1.x in my opinion.
I can also contribute to the porting if you have a bit of patience, probably next weekend, otherwise feel free to do it.

Thanks for the quick reply!

Do you think it's feasible to make aiida-optimize compatible with both 1.x and 2.x?

I agree with @bosonie we drop 1.x. There are new entry points and some backward incompatible interface change.

I can also contribute to the porting if you have a bit of patience, probably next weekend, otherwise feel free to do it.

I think I can spend some time looking after it this week. I'll start with aiida-pytest without too much code change and leave remove this dependency for future. Then it would be straightforward for aiida-optimize to 2.x. I think it is not easy to only use aiida-core fixtures since as I know there are no direct fixture that start daemon from custom profile.

authors: bosonie greschd unkcpz

repo: greschd/aiida-optimize


text:
Add current value method to indicators

It would be very nice to have a method that would evaluate an indicator, and return it's current value. Current interface, that returns value only when new item is added is extremely clunky.

Hey! Thanks for creating an issue.
I thought that this may be needed (sometimes I found myself in the situation, when it could be useful).
Probably I'll add a new method:
fn last(&self) -> Self::Output;

What do you think?

@semtexzv What do you think about the suggestion?
It looks like it must return Option<Output>, None is possible if indicator.last() is called, before any of input values were provided to an indicator.

Looks like the discussion is not alive, so I am closing the issue.

authors: greyblake semtexzv

repo: greyblake/ta-rs


text:
Native custom token symbol not recognized correctly

I've built the EOSIO source code with a pre-defined native token symbol by using the following cmd:
./eosio_build.sh -s FST
The option -s enables to change to a new native token symbol.
Everything works fine and I can also create accounts staked with the newly-defined native token symbol.
However, from the attached screenshot, clearly to see that your wallet has some bug that it still displays the 'EOS' symbol for the "Delegated" part.
I've looked into your wallet source code and have found out that, in the file eos-voter-wallet/app/shared/utils/StatsFetcher.js, at line 121 and 122 (master branch):
      cpuWeight: `${totalCpuAmount.minus(selfCpuAmount).toFixed(4)} EOS`,
      netWeight: `${totalNetAmount.minus(selfNetAmount).toFixed(4)} EOS`,

You still hard-code the EOS symbol, right?
I very love your nice wallet and look forward to your fix soon.
Thanks

Yeah we do have a few places that we hardcoded the EOS symbol.
We will go through and replace those with the detected base currency in one of the upcoming builds.

@aaroncox
Many thanks.
Please notify me when you release the fix for this bug.

@aaroncox Hi! See the problem like this one right now when trying to get back the delegated resources.

Don't really sure it is needed to open a new issue. If so - I will do.

authors: Lostrishs aaroncox trungtt1981

repo: greymass/anchor


text:
setTempo parameter in bpm

Actually Track.setTempo must be specified in microseconds per quarter note, this commit change the parameter to bpm.
see  #10
Before:
track.setTempo(500000); // equals 120 bpm
After:
track.setTempo(120); // converts to 500000 microseconds per quarter note

Good idea, I forgot I never did that.  Thanks!

authors: grimmdude lplume

repo: grimmdude/MidiWriterJS


text:
Refactor modules through wrapper

Lot of common in md/asciidoc modules, wrapper to complete/implement inferable functions.
Related #17

#82

repo: grissius/emily-editor


text:
Outdoor temperature & fan speed wrong and characteristic warnings for plugin

Describe Your Problem:
The outdoor temperature sensor on Model 'SYSTXCCITC01-B' is stuck at 32 degrees.  I can see the correct outdoor temperature on the unit (carrier) and on their website when I sign in.  The fan control is also showing off, when it's running. I am also getting characteristic issues for a number of settings.
Logs:
[11/9/2021, 10:53:32 AM] [CarrierInfinity] Adding new accessory:  ZONE 1 Environmental Sensor
[11/9/2021, 10:53:32 AM] [CarrierInfinity] Discovered outdoor temp sensor device serial:xxxxxxxx
[11/9/2021, 10:53:32 AM] [CarrierInfinity] Adding new accessory:  Outdoor Temperature
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Current Heating Cooling State': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Target Heating Cooling State': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Current Temperature': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Target Temperature': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Temperature Display Units': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Cooling Threshold Temperature': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Heating Threshold Temperature': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Filter Life Level': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Filter Change Indication': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Current Relative Humidity': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Active': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Rotation Speed': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Target Fan State': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Current Relative Humidity': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.
[11/9/2021, 10:53:44 AM] [homebridge-carrier-infinity] This plugin generated a warning from the characteristic 'Current Temperature': characteristic value expected valid finite number and received "[object Promise]" (object). See https://git.io/JtMGR for more info.

Plugin Config:
 {
            "username": "username",
            "password": "password",
            "holdBehavior": "activity",
            "showOutdoorTemperatureSensor": true,
            "showFanControl": true,
            "showIndoorHumiditySensors": true,
            "platform": "CarrierInfinity"
        },

Screenshots:

Environment:

Plugin Version: homebridge-carrier-infinity v1.5.4
Homebridge Version:  v1.3.5
Node.js Version: v16.13.0
NPM Version: v8.1.0
Operating System: Docker | Ubuntu Bionic Beaver (18.04.6 LTS)

Hey. Thanks for reporting! This is really weird. It looks like it’s not working at all. It’s just not actually running the code correctly.
Not sure what’s going on here. Ill have to look into it deeper. I see you’re running a newer version of node than I am. I’ll try to see if i can reproduce by running on the version you are.
In the meantime, I’d recommend trying the old standby: uninstalling and reinstalling, and turning it on and off.

Thanks! The old standby didn't work, but thanks for taking a look at this!

Hey,
I'm unfortunately not able to reproduce. By chance are you using any other homebridge plugins, and do they exhibit the same behavior? If not, could you try another plugin and see if it happens to that one too.
High level, for some reason the promise (async code) isn't being executed before it gets passed to the homekit bridge. But that execution is part of what homebridge itself is supposed to do, so I'm wondering if it is maybe an issue with homebridge itself.
If you can confirm other plugins are working, can you update to the latest node version (16.14.0) and see if that works?

No luck - same issue. 32
[image: image.png]
[image: image.png]
Thanks for looking into it.  Any logs I can send?
On Tue, Feb 15, 2022 at 12:06 AM Glenn Rivkees @.***>
wrote:

Hey,
I'm unfortunately not able to reproduce. By chance are you using any other
homebridge plugins, and do they exhibit the same behavior? If not, could
you try another plugin and see if it happens to that one too.
High level, for some reason the promise (async code) isn't being executed
before it gets passed to the homekit bridge. But that execution is part of
what homebridge itself is supposed to do, so I'm wondering if it is maybe
an issue with homebridge itself.
If you can confirm other plugins are working, can you update to the latest
node version (16.14.0) and see if that works?
—
Reply to this email directly, view it on GitHub
https://github.com/grivkees/homebridge-carrier-infinity/issues/132#issuecomment-1039863083,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADUH3RQKPWHEQWQMPSHAAHLU3HNNLANCNFSM5HVWTHUA
.
You are receiving this because you authored the thread.Message ID:
@.***>

Just pushed some changes to the "next" channel. It has some unrelated changes, but its possible it may help indirectly.
Give it a try when you get a chance and let me know if this seems resolved.
npm install -g homebridge-carrier-infinity@next

Hey @tmills1073, when you get a chance, let me know if the latest version helps out at all.
Changes were pushed to latest, so you can try out the stable version now. Either you can click the update button in homebridge ui, or npm update the plugin.

Closing since I think this is fixed and can't reproduce the issue. If you are still experiencing the issue, please reopen and I'll keep investigating. Thanks!

repo: grivkees/homebridge-carrier-infinity


text:
Records with an id which are falsy (like 0 (zero)) aren't updateable

client.defineModel("Todo", {
"table": "t_todo",
"id": {
"column": "todo_id",
"type": "int4",
"constraint": "primary key"
},
"properties": {
"todo": {
"column": "tod_todo",
"type": "varchar(512)"
}
}
}
// importing stuff wanting to preserve id-value (new Todo({id: 0, todo: "Buy tomados"}) would generate a new id)
client.query("insert into todos (id, todo) values (#{id}, #{todo})", { id: 0, todo: "Buy tomados"});
var t = Todo.get(0);
t.todo = "Buy Tomatos";
t.save();
Expected result:
Updated record in the database
Actual result:
Unable to read "todo_id" from undefined

Great, thanks alot!

repo: grob/ringo-pgclient


text:
[Feature Request] Portable Version (non-MSI)

I see there's no Linux version, for those of us that don't want to pollute our Linux systems with an MSI-installation perhaps a portable version could be uploaded? Considering writing a cross-platform Qt-enabled version, little experience with Qt, though. Wondering if you might consider moving all of 'client' Grocy over to Flutter or Electron, they're cross-platform even for use with Android (maybe Apple stuff as well). One code-base, all platforms?

Duplicate of #37.

Seems that clicking a link and going on reading there is too much for a sunday, so of course I'm happy to help out - quoting myself from https://github.com/grocy/grocy-desktop/issues/37#issuecomment-1029127478 (about if Linux will be supported for grocy-desktop):
No, not for grocy-desktop - would be technically also a whole other thing.

You could at least address the notions instead of dismissing without claiming duplicate.

Of course I will then go through every single word you mentioned - changes nothing, but well:

I see there's no Linux version, for those of us that don't want to pollute our Linux systems with an MSI-installation perhaps a portable version could be uploaded?

A portable version will also not work on Linux in the very same way it doesn't currently.
This is a Windows desktop application wrapper for grocy with the goal to have a "just works" managed way to run grocy just like a normal Windows desktop application, for all users preferring that and maybe are not that tech savvy. It works well, since years.
Fun fact: The average target-audience user of grocy-desktop doesn't use Linux on their Desktop (source: reality).

Considering writing a cross-platform Qt-enabled version
Wondering if you might consider moving all of 'client' Grocy over to Flutter or Electron, they're cross-platform even for use with Android (maybe Apple stuff as well). One code-base, all platforms?

No, I don't consider that. grocy-desktop is not only the frontend (which is just a web browser), but also bundles and auto-manages the required PHP runtime and a webserver. This is never something which could be done in a platform agnostic way.
But of course you can build that. Share it, maybe grocy-desktop is then no longer needed, I have no problem with that, looking forward to it. The target for grocy-desktop won't change, everything else is just another project. And if you don't like the tech stack used, which is totally fine, just don't use it.

Once again: The goal of this project is to provide a managed "just works" experience to run grocy on Windows, like a regular Windows desktop application. Let us keep this finally in mind for everything else.

I was asking about a portable version of grocy-desktop
This entire Issue thread was an inquiry of issue asking for a simple non-MSI.

A "managed just works"-way includes an managed installer, so also out of scope of this project.

or on Linux through Wine

You cannot, doesn't matter if it's "portable" or not. It has Windows only dependencies, just try stuff before speculating on it - a MSI can also be easily extracted, or just build everything yourself, the source is here.

I was only suggesting it is possible to rewrite the desktop version onto a cross-platform solution

I've never said that this is technically not possible, I've said that it's out of scope of this and just another project you're free to build.

For your personal happiness, I've built such a "portable ZIP" just for you out of the latest release v2.3.1: ¯\(ツ)/¯
https://nc.berrnd.org/s/t2zqgQ3aNLYM5ae
And just that we don't forget that here, since we tend to: It will not work on Linux.

It seems to me that you'd be able to run / install grocy just on a normal / regular webserver or simply use one of the available Docker images.
So I don't get why you bother with running it in that managed way at all - a managed way also has restrictions for those who maybe want to configure more or want to have control over every environment detail.

@OdinVex I'm still not exactly grasping what the Docker version isn't able to provide for you…?

but I'm guessing you've never heard of or maybe not have experienced things such as running from an external portable drive.

No, I have not - my knowledge on computers / IT and especially Windows is obviously somewhat extremely limited, sorry for that.

Pulling some magic to make the built-in nginx work (changed port from 4010 and 4011 due to permissions, using 32010 and 32011 at binary offsets 0x3848 and 0x3852 [...]

Sounds a lot easier than simply setting up a regular webserver, don't know why not everyone prefers it that way...

Just a lot of re-invention of the same wheels.

That is ironically the whole point that containerization aims to solve, to not reinvent wheels every time you want a specific unique dev environment. While I agree that it's definitely not a one-size-fits-all solution, this is exactly the kind of thing it excels at. If you do in fact have a home stack, it'd be ideal to experiment with containerization. There's nothing stopping you from specifying your data dirs being on any drive you want.

I guess we can continue this here endlessly, so why not:

Perhaps in the future, you could ask why someone might ask for a different format.

This here is a Feature Request for a project of mine. For my projects I naturally define the corresponding goals.
Both (Linux support and a portable version) is out of scope of this project / my defined goals. That's what I basically just said with my first reply. To be honest, the personal life story details behind each request most of the time is not something I'm interested in, since for what.

I'm a hold-over from older days when some DIY-ers kept 'database-like' software on portable drives (or thumb drives)

We have 2023, (secure) "internet facing" services are possible for everything everywhere.
That would mean you'd need to bring your laptop to Aldi to have your grocy shopping list at hand (and, at least here, they don't provide workstation, so the thumb drive way is not an option - but I could be wrong, my limited computer experience and so on you know...).
That's why I (and kind of every not only grocy user) uses / installs an app like that just like any other web app on their "internet facing" (and when it's behind a VPN or whatever for enhanced security) server to have grocy / the corresponding app / data just at hand when needed - so everywhere, since we have 2023 (and I say that while living in Germany, the homeland of Funkloch).

authors: OdinVex Technetium1 berrnd

repo: grocy/grocy-desktop


text:
Remove git suffix from default clone url template

After updating the plugin, the git remote url included two ".git" suffixes.
$  git init
Initialized empty Git repository in /home/core/workspace/aheuermann/test@2/script=node/.git/
$  git remote add origin git@github.com:aheuermann/test.git.git

Looks like this was resolved with 856c7cc.

repo: groupon/DotCi


text:
Compilation error on macOS (issue with boringssl)

Compile error both using CPython 3.6 and PyPy 6.0.0 (3.5.3) from MacPorts
Python 3.5.3 (fdd60ed87e941677e8ea11acf9f1819466521bf2, Jul 30 2018, 08:59:51)
[PyPy 6.0.0 with GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.2)]

Python 3.6.6

Log:
b"In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:115:
/opt/local/include/openssl/e_os2.h:276:11: error: 'OPENSSL_EXPORT' macro redefined [-Werror,-Wmacro-redefined]
#  define OPENSSL_EXPORT extern
          ^
third_party/boringssl/include/openssl/base.h:182:9: note: previous definition is here
#define OPENSSL_EXPORT
        ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:83:31: error: redefinition of typedef 'ASN1_INTEGER' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_INTEGER;
                              ^
third_party/boringssl/include/openssl/base.h:244:31: note: previous definition is here
typedef struct asn1_string_st ASN1_INTEGER;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:84:31: error: redefinition of typedef 'ASN1_ENUMERATED' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_ENUMERATED;
                              ^
third_party/boringssl/include/openssl/base.h:240:31: note: previous definition is here
typedef struct asn1_string_st ASN1_ENUMERATED;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:85:31: error: redefinition of typedef 'ASN1_BIT_STRING' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_BIT_STRING;
                              ^
third_party/boringssl/include/openssl/base.h:238:31: note: previous definition is here
typedef struct asn1_string_st ASN1_BIT_STRING;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:86:31: error: redefinition of typedef 'ASN1_OCTET_STRING' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_OCTET_STRING;
                              ^
third_party/boringssl/include/openssl/base.h:245:31: note: previous definition is here
typedef struct asn1_string_st ASN1_OCTET_STRING;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:87:31: error: redefinition of typedef 'ASN1_PRINTABLESTRING' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_PRINTABLESTRING;
                              ^
third_party/boringssl/include/openssl/base.h:246:31: note: previous definition is here
typedef struct asn1_string_st ASN1_PRINTABLESTRING;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:88:31: error: redefinition of typedef 'ASN1_T61STRING' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_T61STRING;
                              ^
third_party/boringssl/include/openssl/base.h:248:31: note: previous definition is here
typedef struct asn1_string_st ASN1_T61STRING;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:89:31: error: redefinition of typedef 'ASN1_IA5STRING' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_IA5STRING;
                              ^
third_party/boringssl/include/openssl/base.h:243:31: note: previous definition is here
typedef struct asn1_string_st ASN1_IA5STRING;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:90:31: error: redefinition of typedef 'ASN1_GENERALSTRING' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_GENERALSTRING;
                              ^
third_party/boringssl/include/openssl/base.h:242:31: note: previous definition is here
typedef struct asn1_string_st ASN1_GENERALSTRING;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:91:31: error: redefinition of typedef 'ASN1_UNIVERSALSTRING' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_UNIVERSALSTRING;
                              ^
third_party/boringssl/include/openssl/base.h:250:31: note: previous definition is here
typedef struct asn1_string_st ASN1_UNIVERSALSTRING;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:92:31: error: redefinition of typedef 'ASN1_BMPSTRING' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_BMPSTRING;
                              ^
third_party/boringssl/include/openssl/base.h:239:31: note: previous definition is here
typedef struct asn1_string_st ASN1_BMPSTRING;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:93:31: error: redefinition of typedef 'ASN1_UTCTIME' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_UTCTIME;
                              ^
third_party/boringssl/include/openssl/base.h:251:31: note: previous definition is here
typedef struct asn1_string_st ASN1_UTCTIME;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:94:31: error: redefinition of typedef 'ASN1_TIME' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_TIME;
                              ^
third_party/boringssl/include/openssl/base.h:249:31: note: previous definition is here
typedef struct asn1_string_st ASN1_TIME;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:95:31: error: redefinition of typedef 'ASN1_GENERALIZEDTIME' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_GENERALIZEDTIME;
                              ^
third_party/boringssl/include/openssl/base.h:241:31: note: previous definition is here
typedef struct asn1_string_st ASN1_GENERALIZEDTIME;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:96:31: error: redefinition of typedef 'ASN1_VISIBLESTRING' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_VISIBLESTRING;
                              ^
third_party/boringssl/include/openssl/base.h:253:31: note: previous definition is here
typedef struct asn1_string_st ASN1_VISIBLESTRING;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:97:31: error: redefinition of typedef 'ASN1_UTF8STRING' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_UTF8STRING;
                              ^
third_party/boringssl/include/openssl/base.h:252:31: note: previous definition is here
typedef struct asn1_string_st ASN1_UTF8STRING;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:98:31: error: redefinition of typedef 'ASN1_STRING' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct asn1_string_st ASN1_STRING;
                              ^
third_party/boringssl/include/openssl/base.h:247:31: note: previous definition is here
typedef struct asn1_string_st ASN1_STRING;
                              ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:99:13: error: redefinition of typedef 'ASN1_BOOLEAN' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef int ASN1_BOOLEAN;
            ^
third_party/boringssl/include/openssl/base.h:233:13: note: previous definition is here
typedef int ASN1_BOOLEAN;
            ^
In file included from src/boringssl/err_data.c:18:
In file included from /opt/local/include/openssl/err.h:122:
/opt/local/include/openssl/ossl_typ.h:100:13: error: redefinition of typedef 'ASN1_NULL' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef int ASN1_NULL;
            ^
third_party/boringssl/include/openssl/base.h:234:13: note: previous definition is here
typedef int ASN1_NULL;
            ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make: *** [../pip-install-so7ktzhu/grpcio/objs/opt/src/boringssl/err_data.o] Error 1
"

What version of gRPC and what language are you using?
the last commit on the master branch
What operating system (Linux, Windows, …) and version?
macOS, 17.7.0 Darwin Kernel
What runtime / compiler are you using (e.g. python version or version of gcc)
Apple LLVM version 9.1.0 (clang-902.0.39.2)
What did you do?
python3 setup.py build or pypy3 setup.py build
Standalone boringssl from the master branch can be compiled as expected with no errors:
mkdir build
cd build
cmake ..
make

same issue. OSX El Captain 10.11.6,  Python 2.7.11 pyenv
log of pip install -vvv grpcio:
ps://gist.github.com/erickertz/6b04284778bc267b2c1bc38b1755b5d4

So, let's go a bit over this. I'll start with the last mention first.

same issue. OSX El Captain 10.11.6, Python 2.7.11 pyenv
log of pip install -vvv grpcio:
gist.github.com/erickertz/6b04284778bc267b2c1bc38b1755b5d4

I'm guessing you're saying you've installed python through pyenv. I'm also going to assume you have pyenv installed through brew.
So on a clean mac, (unfortunately on High Sierra, I can't rollback to El Captain), I am doing the following:
Install brew following the instructions at https://brew.sh/
Install pyenv using brew install pyenv and modifying my ~/.bash_profile file according to the installation instructions.
Install python 2.7.11 using pyenv install 2.7.11 and activate it using pyenv global 2.7.11. Confirming I am using the pyenv 2.7.11 version by doing pip --version which shows it's running from my local pyenv folder.
Install grpcio using pip install -vvv grpcio.
--> This works properly.
So either this is an El Captain problem since that'd be the only difference, or there are other things about your environment you haven't specified. I had to do a few assumptions in how you got things installed to get there, but following the reproduction steps I just mentioned, grpcio installs fine.

Could you try the same using MacPorts?
sudo port install openssl pypy3
sudo /opt/local/lib/pypy3/bin/pypy3 -m ensurepip
/opt/local/lib/pypy3/bin/pip3 install grpcio --user

And the same for CPython:
git clone git@github.com:grpc/grpc.git
cd grpc
python setup.py build

Yes, I'm currently re-installing XCode to get a fresh Mac installation, this takes some time :-)

I appreciate the assistance.

Tried in High Sierra 10.13.6, Python 2.7.11 (by pyenv) Python 3.4 (compiled) Python 3.7 (package), failed to reproduce this error...
@Mottl
Have you compiled or installed OpenSSL or BoringSSL manually before? Did you update the submodules by git submodule update --init --resursive?

@Mottl Also, can you use command printenv to print the value of environment variables?

I can confirm the problem installing python with macport with an out of the box installation (without pyenv). I wasn't able to reproduce using brew and/or pyenv.
Digging very quickly, this seems to be a macports issue where it will inject OpenSSL's headers into the compilation line, which interferes with our own headers. I'm not sure what we could do right now about it, as it's Bad Practice (tm) from ports... I'll talk with @lidizheng about digging this further.

I think openssl was installed as binary via macports.
This is the info from python36 macports package:
Variants:             optimizations, universal

Description:          Python is an interpreted, interactive, object-oriented programming language.
Homepage:             https://www.python.org/

Extract Dependencies: xz
Build Dependencies:   pkgconfig
Library Dependencies: bzip2, expat, gettext, libedit, libffi, ncurses, openssl, sqlite3, xz, zlib
Runtime Dependencies: python_select, python3_select
Platforms:            darwin
License:              PSF
Maintainers:          Email: jmr@macports.org, GitHub: jmroot
                      Policy: openmaintainer

openssl is listed is a requirement for python36

Have you managed to run grpc with PyPy_ v6.0.0 (3.5.3)? If so, could you just upload pypy3 setup bdist_wheel?

/opt/local/include is the default installation path for headers for MacPorts and
-I /opt/local/include appended to all cc commands for sure.
Conflicting OpenSSL headers live in /opt/local/include/openssl/*

Here is the line that causes the problem:
cc -Ithird_party/protobuf/src -Ithird_party/googletest/googletest/include -Ithird_party/googletest/googlemock/include -I/opt/local/include -Ithird_party/cares -Ithird_party/cares/cares -Ithird_party/address_sorting/include -g -Wall -Wextra -Werror -Wno-long-long -Wno-unused-parameter -DOSATOMIC_USE_INLINED=1 -Wno-deprecated-declarations -Ithird_party/nanopb -DPB_FIELD_32BIT -O2 -Wframe-larger-than=16384 -fPIC -I. -Iinclude -I/Users/user/grpc/gens -I/opt/local/include -I/usr/local/include -DNDEBUG -DINSTALL_PREFIX=\"/usr/local\" -DGRPC_POSIX_FORK_ALLOW_PTHREAD_ATFORK=1   -I/opt/local/include -Ithird_party/boringssl/include -fvisibility=hidden -DOPENSSL_NO_ASM -D_GNU_SOURCE -DWIN32_LEAN_AND_MEAN -D_HAS_EXCEPTIONS=0 -DNOMINMAX -std=c99 -Wsign-conversion -Wconversion -Wshadow -Wextra-semi   -Wno-sign-conversion -Wno-conversion -Wno-unused-value -Wno-unknown-pragmas -Wno-implicit-function-declaration -Wno-unused-variable -Wno-sign-compare -Wno-implicit-fallthrough -Wno-extra-semi -MMD -MF /Users/user/grpc/objs/opt/src/boringssl/err_data.dep -c -o /Users/user/grpc/objs/opt/src/boringssl/err_data.o src/boringssl/err_data.c
if I strip -I/opt/local/include it compiles. Commenting lines around 375 in Makefile doesn't make an effect...

Rawr. I was against putting these in the Makefile in the first place for reasons like these.

Still can't figure out from where else it takes -I/opt/local/include. Any suggestions?

@Mottl It maybe in https://github.com/grpc/grpc/blob/master/setup.py#L183

I still can't reproduce the error locally... I'm using the MacPorts to install openssl and Python3.6.
Can you try to run this setup.py and give me the print out variables?
https://gist.github.com/lidizheng/13c0cc9b09ac1f52a59c85a52ea4c3fd#file-setup-py-L187
It just add couple lines of printing to master's setup.py.

Please keep in mind I'm using python 3...
('src/python/grpcio', 'include', '.', 'third_party/boringssl/include', 'third_party/zlib', 'third_party/nanopb', 'third_party/cares', 'third_party/cares/cares', 'third_party/cares/config_darwin', 'third_party/address_sorting/include')
CORE_INCLUDE : ('include', '.')
SSL_INCLUDE : ('third_party/boringssl/include',)
ZLIB_INCLUDE : ('third_party/zlib',)
NANOPB_INCLUDE : ('third_party/nanopb',)
CARES_INCLUDE : ('third_party/cares', 'third_party/cares/cares', 'third_party/cares/config_darwin')
ADDRESS_SORTING_INCLUDE : ('third_party/address_sorting/include',)
EXTENSION_INCLUDE_DIRECTORIES : ('src/python/grpcio', 'include', '.', 'third_party/boringssl/include', 'third_party/zlib', 'third_party/nanopb', 'third_party/cares', 'third_party/cares/cares', 'third_party/cares/config_darwin', 'third_party/address_sorting/include')```

Just a few updates: I was able to reproduce the problem with pypy3, and I didn't attempt first using your python36 instructions. @lidizheng is going to look at pypy3 now after seeing it repro on my machine.
I just looked at the python36 stuff, and several things to note:

you can't git clone grpc like this. You need to close recursively (add --recursive to the clone command line).
your instructions don't get to a point where you can even run python setup.py build:

# python setup.py build
Traceback (most recent call last):
  File "setup.py", line 21, in <module>
    import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

Just a few updates: I was able to reproduce the problem with pypy3, and I didn't attempt first using your python36 instructions. @lidizheng is going to look at pypy3 now after seeing it repro on my machine.
I just looked at the python36 stuff, and several things to note:

you can't git clone grpc like this. You need to close recursively (add --recursive to the clone command line).

Ok, thanks, will do it...

your instructions don't get to a point where you can even run python setup.py build:

# python setup.py build
Traceback (most recent call last):
  File "setup.py", line 21, in <module>
    import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

pip install setuptools

I ended up doing python -m ensurepip.
The problem reproduces there too in all cases. @lidizheng is going to try reinstalling his work environment to get to the same state as mine :-)

@nicolasnoble, @lidizheng
Multiple -I/opt/local/include are generated by pkg-config --cflags ...
for example
pkg-config --cflags zlib
-I/opt/local/include

Look at Makefile:
CPPFLAGS += $(shell $(PKG_CONFIG) --cflags zlib)

So, let's go a bit over this. I'll start with the last mention first.

same issue. OSX El Captain 10.11.6, Python 2.7.11 pyenv
log of pip install -vvv grpcio:
gist.github.com/erickertz/6b04284778bc267b2c1bc38b1755b5d4

I'm guessing you're saying you've installed python through pyenv. I'm also going to assume you have pyenv installed through brew.
So on a clean mac, (unfortunately on High Sierra, I can't rollback to El Captain), I am doing the following:

Install brew following the instructions at https://brew.sh/
Install pyenv using brew install pyenv and modifying my ~/.bash_profile file according to the installation instructions.
Install python 2.7.11 using pyenv install 2.7.11 and activate it using pyenv global 2.7.11. Confirming I am using the pyenv 2.7.11 version by doing pip --version which shows it's running from my local pyenv folder.
Install grpcio using pip install -vvv grpcio.
--> This works properly.

So either this is an El Captain problem since that'd be the only difference, or there are other things about your environment you haven't specified. I had to do a few assumptions in how you got things installed to get there, but following the reproduction steps I just mentioned, grpcio installs fine.

OK, thanks for testing and trying to reproduce. All of your assumptions seem about right. If there is anything else about my environment you would like to know, just ask. I'm only trying to help.

Hi, @nicolasnoble
are there any news regarding this problem?

@lidizheng, thanks a lot!
Have you tried installing both zlib and openssl using MacPorts? Is that not enough to reproduce the error? Do you need some help from me? The root of the problem is pkg-config --cflags zlib. If you provide me with the updated Makefile with a separate CPPFLAGS for boringssl I will definitely can test it (and improve it to a ready-state if needed).

@Mottl I tried install both zlib and openssl using MacPorts. And then pypy3 and ensurepip, it will indeed trigger building grpcio from source distribution. But in my Mac, the output of pkg-config --cflags zlib is empty... So it compiled successfully.

@lidizheng, here is the contents of zlib package:
port contents zlib
Port zlib contains:
  /opt/local/include/zconf.h
  /opt/local/include/zlib.h
  /opt/local/lib/libz.1.2.11.dylib
  /opt/local/lib/libz.1.dylib
  /opt/local/lib/libz.a
  /opt/local/lib/libz.dylib
  /opt/local/lib/pkgconfig/zlib.pc
  /opt/local/share/doc/zlib/ChangeLog
  /opt/local/share/doc/zlib/FAQ
  /opt/local/share/doc/zlib/README
  /opt/local/share/doc/zlib/zlib.3.pdf
  /opt/local/share/examples/zlib/README.examples
  /opt/local/share/examples/zlib/enough.c
  /opt/local/share/examples/zlib/fitblk.c
  /opt/local/share/examples/zlib/gun.c
  /opt/local/share/examples/zlib/gzappend.c
  /opt/local/share/examples/zlib/gzjoin.c
  /opt/local/share/examples/zlib/gzlog.c
  /opt/local/share/examples/zlib/gzlog.h
  /opt/local/share/examples/zlib/zlib_how.html
  /opt/local/share/examples/zlib/zpipe.c
  /opt/local/share/examples/zlib/zran.c
  /opt/local/share/man/man3/zlib.3.gz

please notice /opt/local/lib/pkgconfig/zlib.pc
The contents of /opt/local/lib/pkgconfig/zlib.pc:
prefix=/opt/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
sharedlibdir=${libdir}
includedir=${prefix}/include

Name: zlib
Description: zlib compression library
Version: 1.2.11

Requires:
Libs: -L${libdir} -L${sharedlibdir} -lz
Cflags: -I${includedir}

May be you just put this /opt/local/lib/pkgconfig/zlib.pc to your system if for some reason it doesn't exists?

The same for openssl:
prefix=/opt/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: OpenSSL
Description: Secure Sockets Layer and cryptography libraries and tools
Version: 1.0.2p
Requires: libssl libcrypto

Makefile uses $(PKG_CONFIG) for these libraries:
CPPFLAGS += $(shell $(PKG_CONFIG) --cflags zlib)
CPPFLAGS += $(shell $(PKG_CONFIG) --cflags libcares)
CPPFLAGS := $(shell $(PKG_CONFIG) --cflags openssl) $(CPPFLAGS)
CPPFLAGS := $(shell $(PKG_CONFIG) --cflags protobuf) $(CPPFLAGS)

@Mottl Thanks for listing the pkg-config files, I have them installed using MacPorts. I guess I installed all of them once before while compiling Python manually.

I don't think there it does matters... Makefile is static (not generated by python) and it just invokes pkg-config --cflags zlib. Do you have zlib.pc, protobuf.pc and openssl.pc in /opt/local/lib/pkgconfig/?

Yes, that could be related. Please, keep in mind that Makefile has also these lines:
ifeq ($(SYSTEM),Darwin)
ifneq ($(wildcard /usr/local/ssl/include),)
INCLUDES += /usr/local/ssl/include
endif
ifneq ($(wildcard /opt/local/include),)
INCLUDES += /opt/local/include
endif
ifneq ($(wildcard /usr/local/include),)
INCLUDES += /usr/local/include
endif
LIBS = m z
ifneq ($(wildcard /usr/local/ssl/lib),)
LDFLAGS += -L/usr/local/ssl/lib
endif
ifneq ($(wildcard /opt/local/lib),)
LDFLAGS += -L/opt/local/lib
endif
ifneq ($(wildcard /usr/local/lib),)
LDFLAGS += -L/usr/local/lib
endif
endif

So /opt/local/include will be added toINCLUDES anyway.

But the Makefile isn't used by setup.py now, is it?

You are right. It is not... The setup.py will use Python setuptools to build the extensions.

Indeed, src/python/grpcio/commands.py line 277:
make_process = subprocess.Popen(
    ['make'] + extra_defines + targets,
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE)
make_out, make_err = make_process.communicate()

@Mottl I managed to reproduce the error (finally) by specify the PKG_CONFIG_PATH=/opt/local/lib/pkgconfig/. I guess if pkg-config is installed by MacPorts, this problem will occur.

Could you clarify, why do you think this is a problem of pkg-config? Setting CPPFLAGS and other flags is the purpose of pkg-config, or not?..

@Mottl There is a conflict between custom libraries and system libraries... If you force the Makefile to compile with the custom libraries (boringSSL etc.), it will work. Can you try this?
REQUIRE_CUSTOM_LIBRARIES_opt=1 /opt/local/bin/pypy3 setup.py build

Great! One second...

The root cause here is a mismatch between Makefile and commands.py. In currently logic, the Makefile will use system libraries as default (https://github.com/grpc/grpc/issues/11655), but in commands.py is forcing to compile libboringssl.a at here.
So, my solution will be:

Making Python build process aware of  REQUIRE_CUSTOM_LIBRARIES_$(CONFIG) variables, and adjust build target accordingly.
While building libboringssl.a detect whether HAS_SYSTEM_OPENSSL_ALPN is true or not, if it is true, log and exit to prevent future problems.

Great, thanks a lot! Are you planning to make a commit/PR?

@Mottl Yep, but it could take some time to ensure it is stable and doesn't break any thing.

Seems like there is a fix in the works here, but just wanted to add that I just updated to Mojave and am still having the same issue.

@erickertz Can you confirm it is the same issue with same error? Can you show the error log by adding -vvv flag?

@lidizheng sure thing:
https://gist.github.com/erickertz/0be9a44a42d2334174156303b72c6ef1

@erickertz The PR just got merged, can you try to install from the master branch, and see if the problem still exists or not? This fix will be included in next release, which will be weeks from now.

@lidizheng
Installed with PyPy 6.0.0 (3.5.3) just fine. Thanks a lot!

@Mottl Thank you for following the issue and providing suggestions ;)

Following build from source instructions from https://github.com/grpc/grpc/tree/master/src/python/grpcio below, which generate a 1.17.0 version still have the make failure on OS X Mojave 10.14.2 with eithe py27 or py36.
I also tried REQUIRE_CUSTOM_LIBRARIES_opt=1 GRPC_PYTHON_BUILD_WITH_CYTHON=1 pip install . too but does not work.
What is the right command to build from source now?
From Source
Building from source requires that you have the Python headers (usually a package named python-dev).

$ export REPO_ROOT=grpc  # REPO_ROOT can be any directory of your choice
$ git clone -b $(curl -L https://grpc.io/release) https://github.com/grpc/grpc $REPO_ROOT
$ cd $REPO_ROOT
$ git submodule update --init

# For the next two commands do `sudo pip install` if you get permission-denied errors
$ pip install -rrequirements.txt
$ GRPC_PYTHON_BUILD_WITH_CYTHON=1 pip install .

Error:
    [AR]      Creating /private/tmp/pip-req-build-AmG3JZ/libs/opt/libaddress_sorting.a
    [C]       Compiling src/boringssl/err_data.c

    src/boringssl/err_data.c:17:10: fatal error: 'openssl/base.h' file not found
    #include <openssl/base.h>
             ^~~~~~~~~~~~~~~~
    1 error generated.
    make: *** [/private/tmp/pip-req-build-AmG3JZ/objs/opt/src/boringssl/err_data.o] Error 1

authors: Mottl erickertz jeffpeiyt lidizheng nicolasnoble

repo: grpc/grpc


text:
XCFramework Support

Is your feature request related to a problem? Please describe.
When importing gRPC via CocoaPods, it is currently only available as a source pod. This means when we import gRPC into our app, we have to rebuild it every time we do a clean build. This adds over 60 seconds to our build times, and is one of the slowest things that happens during our builds.
Describe the solution you'd like
Apple has a native binary format called an xcframework that would allow for gRPC to be distributed as a binary pod, and CocoaPods plugins like cocoapods-pack exist to produce xcframeworks from podspecs. If gRPC was distributed as an xcframework, we would be able to import it as a binary pod and shave a full minute off our clean build times, which would speed up the builds for our app in particular by 15%. This would be a huge boon for every iOS app that imports gRPC.

Hi @dennycd! Any update on this?

Hey @sethfri , we will be adding this support in Q2, stay tuned

Hey @dennycd, I hope all is well! I wanted to check in with a few questions:

Is the team still on track to deliver this for Q2?
Will this include XCFramework support for all of gRPC, gRPC-Core, gRPC-RxLibrary, BoringSSL-GRPC?

For BoringSSL-GRPC, I don't see a public repo for the fork, so I'm not able to open a separate issue. It also appears as though gRPC uses abseil, so I've opened an issue on that repo https://github.com/abseil/abseil-cpp/issues/1154

Is the team still on track to deliver this for Q2?

Hey @sethfri, YES ! that is still the case for us.

Will this include XCFramework support for all of gRPC, gRPC-Core, gRPC-RxLibrary, BoringSSL-GRPC?

We will have 3 stages for this, roughly matching the dependency graph in our current Cocoapod target settings

iOS/ObjC:  gRPC-ProtoRPC, gRPC-RxLibrary,  gRPC
Native C-Core:   gRPC-Core, gRPC-C++
3rd party deps:  BoringSSL-GRPC, Abseil (GRPC) and others

Likely you would see build improvement when we get to stage 2 (Native C-Core) as gRPC-Core is the one taking the largest chunk of build time.   But the goal is to at least have stage 1 & 2 done by end of Q2  ; )  Hope this helps clarify the timelines a bit more.

For BoringSSL-GRPC, I don't see a public repo for the fork, so I'm not able to open a separate issue. It also appears as though gRPC uses abseil, so I've opened an issue on that repo abseil/abseil-cpp#1154

note that we (gRPC/iOS) currently maintains BoringSSL-GRPC and Abseil Cocoapod build & release distribution.

Is the team still on track to deliver this for Q2?

Hey @sethfri, YES ! that is still the case for us.

Will this include XCFramework support for all of gRPC, gRPC-Core, gRPC-RxLibrary, BoringSSL-GRPC?

We will have 3 stages for this, roughly matching the dependency graph in our current Cocoapod target settings

iOS/ObjC:  gRPC-ProtoRPC, gRPC-RxLibrary,  gRPC
Native C-Core:   gRPC-Core, gRPC-C++
3rd party deps:  BoringSSL-GRPC, Abseil (GRPC) and others

Likely you would see build improvement when we get to stage 2 (Native C-Core) as gRPC-Core is the one taking the largest chunk of build time.   But the goal is to at least have stage 1 & 2 done by end of Q2  ; )  Hope this helps clarify the timelines a bit more.

For BoringSSL-GRPC, I don't see a public repo for the fork, so I'm not able to open a separate issue. It also appears as though gRPC uses abseil, so I've opened an issue on that repo abseil/abseil-cpp#1154

note that we (gRPC/iOS) currently maintains BoringSSL-GRPC and Abseil Cocoapod build & release distribution.

Hi @dennycd! Are we still on track for Stage 1 and 2 by end of this week?

Hey @sethfri , the dev preview for the xcframework build should now be available in our v1.48.0 release (see our release notes for more details).   Please give it a try and let us know if your team run into any issues using it. Happy to follow up and address them.

Hey @dennycd, first of all - thank you very much?
Would it be possible to release those xcframeworks as staticlly linked, what you uploaded in the preview is dynamically linked.
This will shave off build times but may slow down launch times since this is indeed a big library

authors: dennycd nadavm391 sethfri


text:
Some false sharing problems in struct grpc_completion_queue.

Seeing some false sharing problems in "struct grpc_completion_queue".
The following is how I identified the problems:

sudo -E ./run_performance_tests.py -l c++ --category scalable -r cpp_protobuf_async_streaming_qps_unconstrained_1cq_secure
Run "perf c2c record  -a -u --ldlat 50 -p $PID -F 2000 -- sleep 10" while the command above is running.
sudo perf c2c report -NN -g --call-graph --full-symbols -c pid,iaddr --stdio > perf_report.txt

Below is the output of "perf c2c report". There are HITMs (Hit modified cache line) at offset 0x0, 0x8, 0x10 and 0x18 of the same cacheline 0x7fff50011d40. It means that there are some false sharings in "struct grpc_completion_queue". I guess we can see some performance improvement if adding some padding in that struct.

@LeiW000 Is this now ready to be closed as PRs got merged?

Yes, close it as the PR has been merged. Thanks.


text:
Mac M2 Pro Max grpc-tools error: symbol not found in flat namespace '_CFRelease'

What version of gRPC and what language are you using?
gRPC 1.57.0 / Python
What operating system (Linux, Windows,...) and version?
Mac M2 Pro Max
What runtime / compiler are you using (e.g. python version or version of gcc)
Python 3.11.4
What did you do?
I install grpc packages:
pip install grpcio grpcio-tools googleapis-common-protos

and generate proto code:
python -m grpc_tools.protoc --proto_path=$grpc_out ./*.proto --python_out=$grpc_out --grpc_python_out=$grpc_out

What did you expect to see?
Generated code success message.
What did you see instead?
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/Users/piotr/.local/lib/python3.11/site-packages/grpc_tools/protoc.py", line 20, in <module>
    from grpc_tools import _protoc_compiler
ImportError: dlopen(/Users/piotr/.local/lib/python3.11/site-packages/grpc_tools/_protoc_compiler.cpython-311-darwin.so, 0x0002): symbol not found in flat namespace '_CFRelease'

Anything else we should know about your project / environment?
conda 23.7.3

Closing as a duplicate of https://github.com/grpc/grpc/issues/33714

Sorry @gnossen but this is not a duplicate. The issue you linked is related to grpcio but I have an issue with grpcio-tools.
I am still unable to generate Python code using grpc-tools package. Please reopen.

Oh we might need take a look again. Did the two workarounds mentioned help?

Unfortunately they did not.

Ok I just tried again, I'm able to reproduce for grpcio-tools and both of the workarounds works for me, you'll need uninstall grpcio-tools (better uninstall grpcio too just to be safe).
After uninstall, you can install grpcio-tool again using one of the following ways:

Using Conda: conda install grpcio-tools
Install using pip: GRPC_PYTHON_LDFLAGS=" -framework CoreFoundation" pip install grpcio-tools --no-binary :all:

Tried multiple times reinstalling, setting env variables, using M1 chip but still getting this error.
I was able to get it working for few times, but unable to reproduce the working solution.
´python3.8/site-packages/grpc_tools/_protoc_compiler.cpython-38-darwin.so, 0x0002): symbol not found in flat namespace '_CFRelease'´
Using different python version and conda to manage env
grpcio                    1.56.2           py38h761d82c_1    conda-forge
grpcio-tools              1.56.2           py38he333c0f_0    conda-forge
libprotobuf               4.23.3               hf32f9b9_1    conda-forge
protobuf                  4.23.3           py38hfca1a1f_0    conda-forge

@XuanWang-Amos I have tried the steps you provided but it didn't work. Same as @Tsopic I tried reinstalling conda and recreating envs, even trying on different env manager.
Eventually I ended up building a custom docker image and run grpcio-tools from the container.

@XuanWang-Amos, I have tried all the steps mentioned above, but I am still unable to resolve it. please provide any other solution to resolve it or any updates.

I'm working on a PR to explicitly link Core Foundation framework for MacOS: #34395, before it's merged, you can try add apply those changes locally.

reinstall grpcio and grpcio-tools with cmd:
GRPC_PYTHON_LDFLAGS=" -framework CoreFoundation" pip install grpcio --no-binary :all:
GRPC_PYTHON_LDFLAGS=" -framework CoreFoundation" pip install grpcio-tools --no-binary :all:
it works for me on py11 with m1 cpu.

reinstall grpcio and grpcio-tools with cmd: GRPC_PYTHON_LDFLAGS=" -framework CoreFoundation" pip install grpcio --no-binary :all:
GRPC_PYTHON_LDFLAGS=" -framework CoreFoundation" pip install grpcio-tools --no-binary :all:
it works for me on py11 with m1 cpu.

You really saved my life!!!
python --version                                                                                ─╯
Python 3.10.6

arch                                                                                ─╯
arm64

# OS Version
sw_vers                                                                                ─╯
ProductName:		macOS
ProductVersion:		14.4
BuildVersion:		23E214

# Xcode Version
xcodebuild -version                                                                                ─╯
Xcode 15.3
Build version 15E204a

# Command Line Tools Version
pkgutil --pkg-info=com.apple.pkg.CLTools_Executables                                                                                ─╯
package-id: com.apple.pkg.CLTools_Executables
version: 15.3.0.0.1.1708646388
volume: /
location: /
install-time: 1719132014

# Install grpcio
GRPC_PYTHON_LDFLAGS=" -framework CoreFoundation" pip install grpcio==1.47.0 --no-binary :all:                                                                                ─╯
Collecting grpcio==1.47.0
  Using cached grpcio-1.47.0.tar.gz (21.9 MB)
  Preparing metadata (setup.py) ... done
Collecting six>=1.5.2
  Downloading six-1.16.0.tar.gz (34 kB)
  Preparing metadata (setup.py) ... done
Skipping wheel build for grpcio, due to binaries being disabled for it.
Skipping wheel build for six, due to binaries being disabled for it.
Installing collected packages: six, grpcio
  Running setup.py install for six ... done
  Running setup.py install for grpcio ... done
Successfully installed grpcio-1.47.0 six-1.16.0

[notice] A new release of pip available: 22.2.1 -> 24.1
[notice] To update, run: python3.10 -m pip install --upgrade pip

# Install grpcio-tools
GRPC_PYTHON_LDFLAGS=" -framework CoreFoundation" pip install grpcio-tools==1.47.0 --no-binary :all:                                                                                ─╯
Collecting grpcio-tools==1.47.0
  Using cached grpcio-tools-1.47.0.tar.gz (2.2 MB)
  Preparing metadata (setup.py) ... done
Collecting protobuf<4.0dev,>=3.12.0
  Downloading protobuf-3.20.3.tar.gz (216 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 216.8/216.8 kB 70.3 kB/s eta 0:00:00
...
Skipping wheel build for grpcio-tools, due to binaries being disabled for it.
Skipping wheel build for protobuf, due to binaries being disabled for it.
Installing collected packages: protobuf, grpcio-tools
  Running setup.py install for protobuf ... done
  Running setup.py install for grpcio-tools ... done
Successfully installed grpcio-tools-1.47.0 protobuf-3.20.3

[notice] A new release of pip available: 22.2.1 -> 24.1
[notice] To update, run: python3.10 -m pip install --upgrade pip

authors: SaiAparna1 Tsopic XuanWang-Amos gnossen hydra1983 piotratlz yufin


text:
How to set thread local variables in c++?

My Service Handler is not thread safe, So I need a Service Handler every processing thread.
But I didn't find the way.

Does anybody use thread local variables?

Help!

Could you elaborate what you want? I am not quite sure your question is about C++ or grpc, but I might not have understood it.

authors: caron-lee yang-g