weixin_39617405的博客

To clarify 's comment, you can import scope from hyperopt.pyll.base and use scope.int to cast quniform to int.

Here is an example (hyperopt version 0.1):

from hyperopt import hp
from hyperopt.pyll.base import scope
from hyperopt.pyll.stochastic import sample
# Returns an integer from 0 to 10, inclusive
sample(scope.int(hp.quniform('example', 0, 10, 1)))

Relevant question on stackoverflow, that gave me the solution. https://stackoverflow.com/questions/34180442/phpmyadmin-gives-export-php-instead-of-database-sql-dump

I have a table structure with roughly 375 tables(highly relational) and I hit the 1000 input vars limit.

I had to set the input vars to 3000 as suggested in the answer(Could have lowballed it, but it's just a dev machine) to get it running.

A check of input vars expected vs max inputvars with a helpful reminder that the php configuration is sub optimal would help a lot of guesswork what caused the issue of the lone 'sql' file download.

this seems duplicate -> #2916

Hi there

+1s in open source are spam, please provide a repro or on a closed issue, open a new issue with full details. We have an example that works fine so this is a project issue most likely

I am using XCode 10.2 on the example app and it is working via the documentation in this repo, if you can reproduce this by cloning our repo, and having a build failure on the example app, we have a problem. Otherwise I can't reproduce

No, sorry, using old Xcode version isn't something I can check since staying up to date is the general recommendation in the iOS ecosystem. The example compiles no problem with Xcode 10.2

That's a fair defense - thanks again for taking the time to submit this

this repository is developed in English - sorry, I have no idea what you are trying to say and github doesn't have any sort of translation facility built in

I requested a change but thank you for noticing this and proposing a change to help others - react-native + iOS + pods is very confusing to folks that aren't very experienced with it and this should help

Thanks for your patience! Big refactor and release coming up as a v3, this will be in it

Man, I guess it's just verbose then. Some things javascript is great at. Some things, not so much...module systems... :man_shrugging:

ok - I will likely merge but I want to think on it just a bit more by looking at other modules to see how they did it (usually I examine react-native-community/netinfo) - maybe there's nothing to be done but maybe there's an organizational trick I/we could use

I like the idea but I wish this didn't add essentially a duplicate entry for each function. Is there any way (breaking or non-breaking) to do this without duplicating each function entry? Just trying to keep the barrier as low as possible for people that propose PRs - we already have like 5 things we ask people to do :-)

auto-linking works fine on android. There's something wrong with your RN60 conversion maybe? Maybe not including the CLI auto-linking part in your build.gradle? I'm not sure but we experience perfect execution on RN60 without manual linking - this is all we do in testing and it works https://github.com/react-native-community/react-native-device-info/blob/master/refresh-example.sh#L29

Cocoapods is now the default for RN60, everything RN60 requires a pod install, so it's just assumed now - any time you do anything with RN60 that touches native code, you'll have to pod install after. At the same time, even though it should be assumed if you want to propose a PR to the README that makes it clear, it might save future people time and I'd be willing to merge

The example is using RN0.60.4 https://github.com/react-native-community/react-native-device-info/blob/master/example/package.json#L12

It is built dynamically in much the way you describe, and works fine?

Maybe you didn't run pod install?

Re-open if you check out this module, run refresh-example.sh then inside example you do a pod install and react-native run-ios and it still doesn't work

yes - and there are some things that react-native-carrier-info seem like would be a great place but that package doesn't seem active and the maintainer hasn't responded to me. netinfo will be well-maintained though so would be a good home for APIs. I'll look through them to see where we duplicate, for a similar sort of deprecate/remove proposal. Thanks for mentioning it

Running a poll with a proposal to defer to -native-community/react-native-localize package where this is likely handled better https://github.com/react-native-community/react-native-device-info/issues/627

that project has listeners so it gets updated information - it's what I was thinking of doing here, but...it's already done! go snag it

thinking further, there is another react-native-community project that handles localization better and this isn't really device specific, we should remove these completely in device-info 2.0 in favor of this module: https://github.com/react-native-community/react-native-localize

+1 comments are spam. Just thumbs up the issue if you have no new info to add please.

The entire hasNotch() implementation is a little silly if you think about it. Copy/paste is no better or worse than anything given how it works now.

What you really want (to know how to display) is handled better by https://github.com/th3rdwave/react-native-safe-area-context

Everyone should really move there but I provide hasNotch here still because it's always been here and doesn't really hurt to maintain as long as the community keeps it working well

you've mentioned it in 3 places now, which takes the same time as a pull request :-), please make a PR and I'll merge it!

-intramuros that is not necessarily correct. Did you make sure the reporter was using pods first? If they are not, this would do nothing except give an error that there was no command "pod" because it wasn't installed.

I just linked this module into an app and everything is fine - this must be a problem with the installation.

The module doesn't include a sample app but I suggest you do a clean test app from react-native init then npm install react-native-device-info and npx react-native link react-native-device-info

Note I did say npx there as you want to make sure you have an up to date react-native-cli package from npm install -g react-native-cli to do the init, but then after that you want to use the one in your app's node_modules.

this should be closed with a user help / not a bug tag or similar, the app installs and links correctly. A PR for a sample app demonstrating correct behavior on iOS and Android would be awesome though...

I think it would be best if they normalized between the three, so they all fed into a call named something like "supportedABIs", and for iOS it just populated one entry in the array, for Windows I have no idea :)