IOS add a photo library selection changed callback

Why it is needed?
I have noticed the lack of this feature during a discussion on react-native-image-crop-picker. When the app displays library photos for the user and allows him to change the limited selection, as far as I could tell, there is no way to detect when the selection change has finished in order to update the displayed photos. This leads to a poor user experience and to potential bugs (like trying to access a photo that your app no longer has access to).
Possible implementation
I have no experience with IOS native development, so I can not tell if there is any technical barriers to doing so, but I believe we should have a callback fired when the user finishes editing the allowed photo selection. As I mentioned, I would not know how to do it at first, but I can try making a PR if someone would point me on the right direction.
The result could be something like bellow.
Code sample
import {openLimitedPhotoLibraryPicker} from 'react-native-permissions';

openLimitedPhotoLibraryPicker()
  .catch(() => {
    console.warn('Cannot open photo library picker');
  })
  .then(() => {
    console.log('Limited photo selection changed');
  });

I was just curious so I looked through this, it looks like if you ask for permission again (does this library permit that?) the user can manage the limited set again so a call to action saying "Add Photos?" that re-requests limited permission might do it?

There's no callback in the API that I know of. How do the AppState APIs built-in to react-native react? Might be a foreground to background transition and back.

Hi @mikehardy! Thanks for your fast response and I am sorry for the delay. We are having some problems with this feature on the simulator running on apple silicon, which is my case, so I had to wait for support from my co-worker who has an intel chip to try your suggestion.
Unfortunately it did not work, the app does not seem to transition neither to background nor foreground during the limited selection management.

I did some digging and it looks like the this is the code that opens the file picker using the PHPhotoLibrary class: https://github.com/zoontek/react-native-permissions/blob/master/ios/PhotoLibrary/RNPermissionHandlerPhotoLibrary.m#L62
Looking through the class docs, it would seem that we can use the version of the method to fire a callback: https://developer.apple.com/documentation/photokit/phphotolibrary/3752108-presentlimitedlibrarypicker
Like I said, I am not used to iOS development, so I am not completely sure if this makes sense. If it does, I could open a PR.

Great find!
My previous statement "There's no callback in the API that I know of" is invalidated by that second link I missed it when looking at API docs. It looks like that API would make sense and work for the use case.

@mikehardy It doesn't exist for iOS 14.x (where the limited feature has been added first). So the solution is partial here.

@luizppa I think that is not possible, I suggest you make a listener if there's photo library change.

will you add this feature to detect that window closed?

@luizppa How did you work around this issue in your case?

@mikehardy I think we could listen for PHFetchResultChangeDetails (https://developer.apple.com/documentation/photokit/phfetchresultchangedetails) on iOS < 15, will try to implement it.

@zoontek I'm aware that you'd be having a lot on your plate. But since I don't have experience working with native iOS, would this feature be available anytime soon? I'm also open to other ideas to handle this issue from my end.

@jenipharachel This is the kind of feature I don't personally need, but I'm available for freelancing work if your company really need it! You can contact me via email 🙂

@jenipharachel I made a fork with a callback. I'm not to familiar with native iOS and React Bridge, so it's not the fancy listeners that were suggested, but it is a good enough workaround if you are not too concerned with older iOS versions.
Here is the commit link, it also has an example: https://github.com/luizppa/react-native-permissions/commit/37c8c13c197c2594cd57aedb51a97c28b8da45c7

Just discovered that a similar job has to be done for Android now (https://developer.android.com/about/versions/14/changes/partial-photo-video-access).
I put the feature request on https://polar.sh/zoontek, if companies are interested in it.

Closed as v4.0.0 is out.


Passing headers outside the provider

Is it possible to add the headers outside flowFactoryProvider
Otherwise you would have to burn in to the code the token

I found a way around, setting the parameters flow-init instead of flowFactorProvider


Patron Spawn Controller object

Required for #43
Create a game controller object that can hold an array of patrons and specialty patrons to spawn, publicly exposes some variables a designer or external controller could use to tweak difficultly (spawn rate, total # of basic patrons on screen, total # of special patrons on screen).
A create patron method should exist, and it should randomly pick a patron from those available (considering total patrons in scene, total special patrons in scene).
Refer to the Patron Spawners on the bar objects.  See: https://docs.google.com/document/d/1YmSmHOAYKzmCU9hBz_QsyhOy-GWBxBwKasGI5-ZyYhw/edit#bookmark=id.aatlcob4dihw

The component "Difficulty Scaler" in the Difficulty Scaler object contains an int for Patrons and SpecialPatrons that should be referenced by the spawners so that the number of patrons on the screen at any given time can be controlled.


Push to App Engine when new update to main is performed

Is your feature request related to a problem? Please describe.
Gcloud deployment is only done through CLI right now.
Describe the solution you'd like
When I merge to main, push to a beta endpoint and check it there. If everything checks it, push to prod endpoint.
Describe alternatives you've considered
This can be low-priority as we are still emerging into the MVP stage
Additional context
Use GitHub workflows for CI/CD.

@smburdick, there is an unofficial GitHub integration for the app engine repo. This requires authenticating with the service, which you can only do as this is hosted on your private cloud.

This issue is not relevant anymore. Closing it. See #323 for more details.


Fix Build Issue

Closes issues #36 #25 #28
Before closing:

[ ] Update version number
[ ] integrate with CI build (are we building /dist via the CI)

:shipit:

what's blocking this?

@morenoh149: Will merge shortly :)

can we get an npm release? :)


Hide dots and pagination

Version

react-native-swiper v1.5.13
react-native: 0.50.3

Problem
I have 4 Views inside a Swiper component and showing 4 Dot, one Dot for each View.
I would like to keep 4 Views, but only show 3 Dot. 4th View should not be a visible element of the Pagination but should still be part of the Swiper component. Pagination should be hidden on the 4th View as well.
Example
4 Views but only 3 Dot
1st View
Pagination is visible and has 3 Dots.

1st Dot is active.
2nd Dot is inactive.
3rd Dot is inactive.
4th Dot is not visible.

2nd View
Pagination is visible and has 3 Dots.

1st Dot is inactive.
2nd Dot is active.
3rd Dot is inactive.
4th Dot is not visible.

3rd View
Pagination is visible and has 3 Dots.

1st Dot is inactive.
2nd Dot is inactive.
3rd Dot is active.
4th Dot is not visible.

4th View
Pagination is not visible.

1st Dot is inactive.
2nd Dot is inactive.
3rd Dot is inactive.
4th Dot is not visible.

Research
It seems like this number is responsible for the number of visible Dot components. Here it is being used to build the Dot components.
Summary
Is there any better approach to achieve what i'm asking for without touching these lines?
Maybe a hidden feature i'm missing to hide / remove Dots and Pagination for a given View index?

+1

+1

@mianusmankhalid can you visualize what you mean by that? I somehow don't get it.

3rd View
Pagination is visible and has 3 Dots. When select 3rd View it should slide to left
1st Dot is not visible.
2nd Dot is inactive.
3rd Dot is active.
4th Dot is inactive.
4th View
Pagination is visible and has 3 Dots.
1st Dot is not visible.
2nd Dot is inactive.
3rd Dot is inactive.
4th Dot is active.

Sorry your use case is totally different. I was thinking different use case that is as below.
For example I have total 20 pages but I just want to show 5 dots on screen.
Dots for pages from 6 to 20 will be hidden/not visible on screen,
then if I will swipe right until page 5 then it should slide the paging bar to left to show sixth dot and hide first dot. reverse will be vice versa.

I used local state and check my condition, then use setState to active or inactive.

@havinhthai can you elaborate little bit more ?

@mianusmankhalid This is my code
`
export default class IntroSwipe extends Component {
state = {
showPaginate: true,
}
indexChanged = (index) => {
    if (index === 2) {
        this.setState({ showPaginate: false });
    } else {
        this.setState({ showPaginate: true });
    }
}

render() {
    return (
        <Swiper
            loop={false}
            activeDotStyle={{ backgroundColor: 'transparent', borderWidth: 1, borderColor: '#fff' }}
            onIndexChanged={index => this.indexChanged(index)}
            showsPagination={this.state.showPaginate}
        >
            <View><Text>Section one</Text></View>

            <View><Text>Section two</Text></View>

            <View><Text>Section three</Text></View>
        </Swiper>
    );
}

}
`

But still 4th Dot will be visible because you are hiding whole pagination on index 2, not dot for last index.

@mianusmankhalid You can style them in activeDotStyle or dotStyle prop with condition.

It should be like this.
1st View
Pagination is visible and has 3 Dots.
1st Dot is active.
2nd Dot is inactive.
3rd Dot is inactive.
4th Dot is not visible.
2nd View
Pagination is visible and has 3 Dots.
1st Dot is inactive.
2nd Dot is active.
3rd Dot is inactive.
4th Dot is not visible.
3rd View
Pagination is visible and has 3 Dots. When select 3rd View it should slide to left
1st Dot is not visible.
2nd Dot is inactive.
3rd Dot is active.
4th Dot is inactive.
4th View
Pagination is visible and has 3 Dots.
1st Dot is not visible.
2nd Dot is inactive.
3rd Dot is inactive.
4th Dot is active.

and how would we implement this scenario ??


[HIP] Correct headers and add missing function templates for hip-clang.

Fix 2 runtime API prototypes
hipOccupancyMaxActiveBlocksPerMultiprocessor and
hipOccupancyMaxActiveBlocksPerMultiprocessorWithFlags
Add missing function templates of them in hip-clang.

I believe this is already being addressed in PR #1484.

PR #1560 should be covering these changes. So closing this for now. In case it is still needed please reopen or create a new PR.


Styleguidist

there are bugs and the props for docs are not working because of react lazy import i think will look at this later


Remove v1alpha1 CRDs and related bits

This looks good Dan.  I didn't see anything that would delete the collection controller deployment and friends on an upgrade from 0.9.0 to 0.10.0.  I think we need something in the kabanero controller that makes sure the collections stuff is deleted (deployment/pod, SA, roles, etc).  I'm not sure that stuff would get deleted on an upgrade unless the Kab CR instance was deleted.  Do you agree?
@dacleyra

Maybe. The upgrade scenario doesn't satisfy InstallPlan
    Message:               error missing existing CRD version(s) in new CRD: kabaneros.kabanero.io: New CRD (kabaneros.kabanero.io) must contain existing served versions
(v1alpha1)

https://github.com/operator-framework/operator-lifecycle-manager/blob/fb2879e6ec1f54973f69a2d6136fc99094e2b261/doc/design/dependency-resolution.md#deprecateremove-a-version-of-crd
I don't think we set v1alpha1 served: false in a version previous

Do we just need to introduce an artificial step (like have 0.9.1 set served = false for v1alpha1 and then 0.10.0 can remove it)?

yes

Setting served = false in 0.9.1, and then installing 0.10.0 from the PR worked
InstallPlan was successful
collection controller deployment is gone
the collections CRD sticks around though, but that seems to be normal? I don't think OLM necessarily cleans out CRDs

close in favor of
https://github.com/kabanero-io/kabanero-operator/pull/760


[CAMEL-11495] New Camel website: Incorporate logo

Incorporate the logo in the header section in the header template layout.
Add an images folder with the logo file into the static sources.
Clean unused images.

Thanks @fpapon


Set helm chart version to v0.7.0 ready for release

Follow-up of https://github.com/jetstack/google-cas-issuer/pull/96 and https://github.com/jetstack/google-cas-issuer/pull/110 @SgtCoDFish

@MaesterZ Appreciate this! I've actually already done the release - https://github.com/jetstack/google-cas-issuer/releases/tag/v0.7.1
When a tag is pushed, the version is overridden and so we don't actually need to bump the versions in this chart. I hadn't realised that!
I'll close this as the release is done 😁  Thanks very much for your contribution!

@SgtCoDFish 👋 Hiya
Sorry to resurrect this thread / PR, however I don't think the chart has been released to https://charts.jetstack.io/, the latest version I see available is v0.6.2!

Hey, thanks for raising that! You're correct, I can't see the newer versions on there. Weird, I'd figured that was covered by the automation. I'll take a look 👀

OK, the charts should now be released and available! Thanks for the heads up, I hadn't realised the automation didn't cover that!

Thanks very much for the release!


Pagespeed conflicts with Nginx Headers module

I have compiled pagespeed(1.13.35) with nginx(1.15.1). In the responses from the web server, the name of the app server(in the Server header) is displayed. To avoid the name getting disclosed, I have compiled an additional module with nginx called the headers-more module. This module works fine when pagespeed is turned OFF. However, when we turn ON pagespeed, the name of the server starts getting displayed in the response header in spite of the additional module.
Is it possible to prevent pagespeed from overriding the configurations of the headers more module?

This is a known issue, being tracked elsewhere. See https://groups.google.com/forum/m/#!topic/ngx-pagespeed-discuss/PmKakhMImEQ and specifically POSITION_AUX for a potential resolution. (I'm not sure if that flag still works as intended)

@oschaaf , Compiling nginx with pagespeed as a dynamic module and using the Position_aux flag did not remove the header. Can we expect a fix for this issue sometime?


Display Activity Identifier On Main Activity Screen

As the activity identifer is unique to each activity please could it be displayed on the main activity screen?

In fact it would be useful if the key attributes of most information could be displayed on the main screen, activity dates, contact info, flow type, aid type, etc so you don't have to go in to edit each element to see what it is set to?

This issue will be followed up on issue #49


Remove remaining links to dartlang.org

The last remaining links to dartlang.org have been removed by linking to
either GitHub or pub.dev.
I have found no other mentions of dartlang.org other than in the pubspec.lock which is auto-generated.
This PR fixes #364

@Sgoettschkes Can you pull in the changes made to the main branch or rebase onto that branch. Either one is fine.
I just want to make sure the checks are updated correctly.

@Stargator Done!


Installation doesn't progress

Installation gets here then doesn't move on, using CTRL-C then npm start returns an error saying that sql couldn't be found

Don't know what was happening, but rebooting fixed the issue


feature request: Make coding area scroll independently.

It might be more convenient if the instruction and coding area scrolled independently of each other so you can refer to each section without having to continuously scroll up and down.

Could someone in charge change the title of this issue?

edit: title changed to reflect issue

Adding the css below to class "CodeMirror-scroll"
'''css
overflow: auto;
max-height: 750px;
'''
Height could be anything, I'm sure there's a responsive solution to have it extend the height of browser window. But this solution works decently across all viewport sizes.

For anyone follow the development of this issue i have a fix ready to go here #1153


KotlinNullPointerException on antlr dependency

Reproducer project there: https://github.com/martinbonnin/test-antlr/
Calling ./gradlew buildHealth --stacktrace fails with:
Caused by: kotlin.KotlinNullPointerException
        at com.autonomousapps.internal.ConsoleReport$Companion.from(models.kt:487)
        at com.autonomousapps.tasks.BuildHealthTask.action(BuildHealthTask.kt:46)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:49)

This only happens on current main. The sample projects expects 0.61.1-SNAPSHOT in mavenLocal. 0.61.0 is ok (although it displays "null" for configurations). I guess it has to do with the fact that the antlr plugin adds the dependency automagically.

Huh, that's strange. The antlr project is simple added directly to the jar (see here and here).
The reproducer is appreciated.

Well, I can get it to recognize the antlr configuration, but it still reports the dependency as unused (incorrectly, I assume)
> Task :buildHealth
Advice for root project
Unused dependencies which should be removed:
- antlr("org.antlr:antlr4:4.8-1")

Transitively used dependencies that should be declared directly as indicated:
- api("org.antlr:antlr4-runtime:4.8-1")

I have used antlr, but it's been a while. Do you have an idea why the plugin wouldn't "see" any code from that jar being used? Btw, once I merge to main, you can add this to ignore the false warning
dependencyAnalysis {
  issues {
    all {
      onUnusedDependencies {
        exclude("org.antlr:antlr4")
      }
    }
  }
}

I think it's correct that antlr isn't used. It's the compiler that is used at compile time but at runtime only antlr-runtile is used (transitively)

Ah, I see. So the plugin should probably make it a compileOnly
dependency. Hm. Maybe we can just upstream this.
On October 9, 2020, GitHub<EMAIL_ADDRESS>wrote:

I think it's correct that antlr isn't used. It's the compiler that is

used at compile time but at runtime only antlr-runtile is used
(transitively)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/autonomousapps/dependency-analysis-android-gradle-
plugin/issues/300#issuecomment-706506339>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/ABJG5PL2H46BI7ZOEY3KVT3SKAGPJANCNFSM4SJ6BA2Q>.

While I have merged the PR, this issue is not quite resolved to my satisfaction.

Here it is, the antlr plugin sets the compile configuration as a descendant of the antlr configuration https://github.com/gradle/gradle/blob/master/subprojects/antlr/src/main/java/org/gradle/api/plugins/antlr/AntlrPlugin.java#L67-L68

I'm starting to think what I actually need is special-handling for non-standard configurations. This is now a design question.

Here it is, the antlr plugin sets the compile configuration as a descendant of the antlr configuration

That's interesting... Is there a reason to do this instead of adding antlr-runtime to the compileClasspath configuration, like SQLDelight is doing

I'm starting to think what I actually need is special-handling for non-standard configurations. This is now a design question.

I guess part of why that's hard here because it's hard to tell whether a given dependency was added by the user or by another plugin?...

For me, I think I just need to draw the line somewhere. I can't support every plugin out of the box. But to avoid giving bad information to users, I think I might have the plugin ignore dependencies that are on a custom, not-well-known, configuration.
I can imagine supporting additional plugins (like antlr), but that won't solve the general case, which is what I'm talking about now.

The latest PR resolves this in a more general and satisfying way. The plugin should now ignore all "unusual" configurations. We can add support for them one at a time as it may seem useful.


Improve suppression and copying directories

Build failure in this PR may be caused by https://github.com/gradle/gradle/issues/22484.

Closing in favor of #101.


Add main menu

Main menu would have four choices:

Start New Game
Load Saved Game
Settings
Quit

Start New Game starts new game,
Load Saved Game loads previously saved game (to be added later),
Settings would allow to change data in settings.py,
Quit quits the game

[x] New game
[ ] Load game
[ ] Help Screen
[ ] Settings
[x] Quit
[x] Keyboard controls
[x] Mouse controls
[x] Gamepad controls
[ ] Save game when Esc is pressed

How will saving work?

We could create a class called Savable. Then, all the objects extending it would be saved/loaded automatically. For the actual implementation, we would need to serialize/de-serialize python objects. This could be done using json or pickle.

What should be on the options screen?
Music/Sfx volume sliders
Predefined(?) screen resolution in dropdown list.
Keybindings should have separate screens I think.

I created #40 for it.


Redundent transmute in osmflat_generated

Often times there are accessors that transmute the same time into itself such as:
https://github.com/boxdot/osmflat-rs/blob/011d70a90f784f8e60b1f4903e1367be454445d4/osmflat/src/osmflat_generated.rs#L494-L497
Is there any reason why this is being done, or is it something odd with the code generator? In this instance, the id is already an i64. Why transmute?

This is due to the generator supporting to deserialize enumerations: Those need to be transmuted. The generator could theoretically skip the useless transmute by checking if target type matches source type, but the way it was implemented right now it just always transmutes, even if it is a no-op.

I wonder if there is any performance hit?

Only in debug mode, release mode optimizes everything away. Similarly the flatdata_read_bytes macro is fully optimized to generate code similar to C++ bitfields.


is constraint on target_return really needed?

this post is releted to this open issue: https://github.com/robertmartin8/PyPortfolioOpt/issues/477
I stumbled across the error described in #477 by appling the efficient frontier code on a portfolio where the security returns are:
mu.values
array([ 0.04598439,  0.052016  ,  0.03663621,  0.02208842,  0.06023858,
        0.03231331,  0.09586187,  0.08313241,  0.04043133, -0.10731498,
        0.02416566,  0.02330225, -0.01686913,  0.06442683,  0.06367358,
        0.16949511,  0.05215236,  0.07096311,  0.04112797,  0.00618275,
        0.02787441, -0.12790353,  0.13597   ,  0.08452797,  0.03030415,
       -0.14468394,  0.0537372 ,  0.04336144,  0.04963428, -0.02248067,
        0.01793846,  0.11759868,  0.04622102,  0.01007199,  0.10688818,
        0.07502199])

as you can see some of them are negative. Thus, I decided to debug the plot_efficient_frontier to understand what was going on under the hood.
I found out that what triggers the error is:
https://github.com/robertmartin8/PyPortfolioOpt/blob/6644741ff27fca5f2aaeefd63e31d157cfd718ae/pypfopt/efficient_frontier/efficient_frontier.py#L392
Indeed, having a security with negative returns lead to a target result that sometimes is negative. Is this constraint really needed?
Moreover, when this happens the code doens't raise the right Exception making the error more difficult to spot.
Indeed instead of:
https://github.com/robertmartin8/PyPortfolioOpt/blob/6644741ff27fca5f2aaeefd63e31d157cfd718ae/pypfopt/efficient_frontier/efficient_frontier.py#L393
the exception that is raised is:
https://github.com/robertmartin8/PyPortfolioOpt/blob/6644741ff27fca5f2aaeefd63e31d157cfd718ae/pypfopt/base_optimizer.py#L539
because of:
https://github.com/robertmartin8/PyPortfolioOpt/blob/6644741ff27fca5f2aaeefd63e31d157cfd718ae/pypfopt/plotting.py#L189-L194
I would be happy to create a small PR to solve these small issues :)

yeah perhaps the check isn’t needed

Hi Robert,
I open a very tiny PR to fix it :)

merged, thanks!


Add osx-arm64 (Apple M1) support

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Adds an osx-arm64 build to support systems with Apple M1 processors.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@tomasvanpottelbergh This seems like a duplicate of https://github.com/conda-forge/pmdarima-feedstock/pull/17/files, but let me know if that's incorrect.

That's correct, I triggered that one because I didn't manage to get the build working, but the build of #17 for osx-arm64 has failed as well: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=366023&view=results.
The error seems to be OSError: [Errno 86] Bad CPU type in executable: './test_program', which I think comes from this file: https://github.com/alkaline-ml/pmdarima/blob/5bf84a2a5c42b81b949bd252ad3d4c6c311343f8/pmdarima/_build_utils/pre_build_helpers.py. I think this file might need to be adapted to take the target compilation architecture, as the osx-arm64 builds are built on x86_64.


Firebase Functions doesn't work out-of-the-box

Please provide the environment you discovered this bug in.
macOS 14.2.1
Node 18 or 20
Firebase CLI 13.0.3
create-analog 0.2.67
Which area/package is the issue in?
Docs
Description
At first, I headed directly to the Firebase providers page: https://analogjs.org/docs/features/deployment/providers#firebase.
This sent me down a path of hours of head-banging because I missed the overview page and wasn't aware of nitro or what it did. This page is very easy to miss: https://analogjs.org/docs/features/deployment/overview
Once I configured nitro in vite.config.ts I still ran into an issue with firebase deploy.
Error: An unexpected error has occurred.
TypeError: Cannot read properties of null (reading 'match')

The stack trace was pretty generic. After some searching around, I found the answer on this GitHub thread: https://github.com/nuxt/nuxt/issues/23496#issuecomment-1758748355
It seems like with the different generations and node versions available on Firebase, these must be explicitly stated in the nitro config for things to work properly.
This is the configuration that worked for me:
nitro: {
  preset: 'firebase',
  firebase: {
    nodeVersion: '20',
    gen: 2,
    httpsOptions: {
      region: 'us-east1',
      maxInstances: 100,
    },
  },
},

I think it'd be a significant improvement if every provider listed a Nitro config section. This seems to be required to get Firebase working, but even in other providers it would help avoid many unnecessary headaches if someone misses the overview page.
In addition, the DevEx could be further improved if the npm create tool asked what cloud provider someone would like to select. That'd also provide additional clues hinting at the need for additional configuration.
Please provide the exception or error you saw
Error: An unexpected error has occurred.
TypeError: Cannot read properties of null (reading 'match')

Other information
Also I saw a warning saying:
 ⚠  functions: Couldn't find firebase-functions package in your source code.

This seems to be benign. If this is expected behavior, it should also be documented.
I would be willing to submit a PR to fix this issue

[X] Yes
[ ] No

Thanks @duluca. That would be great to add. When I initially went through the deployment process for Firebase for the guide, this extra configuration wasn't needed.

@duluca  Thank you !!! It works.  I was banging my head all day trying to figure out the right nitro config and I found your post. Thank you for figuring out the nitro config.


[Application] :

Contact Details
Dan
Past Projects
https://www.linkedin.com/mwlite/profile/in/alphageek/
Which disaster risk or issue are you addressing?
I am in the public safety communications business, and I have an engineer who lives in Nepal.  I would like to provide this kit for him to develop a support ecostructure suitable for third world deployment.
We have the means and we have the motivation. This kit is exactly what we need to kick start.
I have several large public safety and disaster communication systems in active service, and I have traveled internationally to design and deploy.
We recently completed a tornado siren migration to secure communications that would be particularly applicable for this, but we have no shortage of use cases.
What we don't have is low cost solutions. Because there's no money in that!  I selected TRL9 below which might not be applicable. We have not vetted a use case for your specific kit yet
It's time to give something back.  I really like your story, and we have deep skills in concert with your mission.
Disaster
other
Where are you from?
North America / United States
Readiness Level of a Project
TRL 9 - Actual System Proven in Operational Environment
Storytelling

[X] I agree to follow this project's will to share my project evolution with documentation and short interviews during the project's deployment

Hello,
Thank you for sharing your proposal, which was very impressive! After careful evaluation, we regret to inform you that we will be moving forward with other candidates.
Our decision was primarily based on the alignment of the project with MissionPack's objectives, as well as the feasibility of achieving these goals with Mission Pack.
We truly appreciate your participation, and we look forward to seeing your projects in the future.
Sincerely,
Seeed Studio / Davide

Oh foo; I shall look forward to reviewing the fruits of your excellent
labors. Thank you for writing back.
On Wed, Dec 27, 2023, 4:33 AM vongomben @.***> wrote:

Hello,
Thank you for sharing your proposal, which was very impressive! After
careful evaluation, we regret to inform you that we will be moving forward
with other candidates.
Our decision was primarily based on the alignment of the project with
MissionPack's objectives, as well as the feasibility of achieving these
goals with Mission Pack.
We truly appreciate your participation, and we look forward to seeing your
projects in the future.
Sincerely,
Seeed Studio / Davide
—
Reply to this email directly, view it on GitHub
https://github.com/Seeed-Studio/Hazard-Response-Mission-Pack/issues/8#issuecomment-1870120582,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACOYVD253TKM2T5A4U6A5M3YLPTODAVCNFSM6AAAAAA6HPSP6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZQGEZDANJYGI
.
You are receiving this because you authored the thread.Message ID:
@.***>


Systemd Dependencies - Kafka after Zookeeper, Schema Registry after Kafka, ...

Hi,
currently when rebooting an one server installation we run into problems - I suspect it might be a problem that they all start independently, getting something like
ERROR Error starting the schema registry (io.confluent.kafka.schemaregistry.rest.SchemaRegistryRestApplication)
io.confluent.kafka.schemaregistry.exceptions.SchemaRegistryInitializationException: Error initializing kafka store while initializing schema registry

in the schema registry log while the kafka server is still booting at that time. Do you consider this also a problem and would a systemd "After" definitition fix this?
Thanks a lot for your time,
Johannes

Hello Johannes,
Thank you for the question.  It's possible that using 'after' in systemd scripts could resolve this if you are running all on one host.  We haven't specifically tested this, as generally speaking you will want to install across multiple hosts, and restart in a rolling fashion.
Thanks

Hi and thanks for the reply. We are using the one-host setup only for our test environment. Maybe we will investigate further into this and provide a pull request, but for now this issue can be closed since the single node setup is not the main focus of the playbooks I think.
Cheers,
Johannes


API versioning strict mode not returning a 406 as expected

I created a very simple endpoint to make it easier to spot this issue. Say I have the following API:
module MyApp
  class API < Grape::API
    format :json
    version 'v1', using: :accept_version_header, strict: true

    get 'healthcheck' do
      status 200
    end
  end
end

And the following tests:
describe 'MyApp::API' do
  def app
    MyApp::API
  end

  describe 'versioning' do
    it 'fails if the client does not specify a version' do
      get '/healthcheck'

      expect(last_response.status).to eq(406)
    end

    it 'returns successfully if a version if specified' do
      header 'Accept-Version', 'v1'

      get '/healthcheck'

      expect(last_response.status).to eq(200)
    end
  end
end

What's happening is that for the first scenario it's returning a 404.
After investigating a bit deeper the issue it seems like that versioner/accept_version_header.rb is doing the right job - I can see a 406 from there, however later in the process Grape::Middleware::Error#error_response appends a X-Cascade: pass to the headers and that seems to be used later by Grape::Router#transaction to search for another match of that route (lines 86 to 90 in lib/grape/router.rb). As the router can't find it ends up returning a 404.
I'm not exactly sure what's suppose to be going on as part of that last stage, so maybe someone with more context on it can help me here.
The workaround for now is commented out as part of https://github.com/ruby-grape/grape/blob/master/lib/grape/middleware/versioner/accept_version_header.rb#L48
So in my example, it would mean that this line:
version 'v1', using: :accept_version_header, strict: true

...would become this:
version 'v1', using: :accept_version_header, strict: true, cascade: false

That work wonders but it's still unclear to me why that behavior is not default.
Thoughts?
Thanks!
Nicholas

After taking another look at the docs, this behavior is actually being mentioned:

When an invalid Accept header is supplied, a 406 Not Acceptable error is returned if the :cascade option is set to false. Otherwise a 404 Not Found error is returned by Rack if no other route matches.

Wouldn't the other way around make more sense? Make the default cascade: false?

It could make more sense, but I bet the reason is historical and I would vote not to change this behavior so that everybody doesn't have to suffer. If you agree I think we should close this?

Yeah, I thought about the historical reasons as well.
Before closing it, could I make a small change to the docs?
I'm thinking about copying these lines from the Header explanation:

When an invalid Accept header is supplied, a 406 Not Acceptable error is returned if the :cascade option is set to false. Otherwise a 404 Not Found error is returned by Rack if no other route matches.

And use them as part of the Accept-Version Header docs - at the moment it only mentions that when using strict: true it will return a 406.

Definitely propose a PR, thanks @nicholaspufal!

Closed via #1417.


add info to runs-on docs + one fix

Fixes #1103
Also, change runs-on on Build Reference Documentation to be runs-on: [ windows-latest ] (instead of runs-on: windows-latest) which means that Update AL-Go System Files will also modify this to the setting of "runs-on"

Yes, I'm pretty sure I did. Nevertheless, I run it again today morning and it gives me just single non-trivial change.

My template repo is: https://github.com/microsoft/AL-Go-PTE@main


add user favorites and collections functions

User collections can be created and deleted. Images can be added and removed from user collections. Limitations of wallhaven mean that images can only be contained within one collection at a time. Also wallhaven return codes for the requests are inconsistent. It is common to receive a HTTP 500 error code even though a request has gone through successfully.

@resonance50 Hello. Thanks for this push request. I'm qute busy and I'll expect to check this at weekend.


Otbr-web fails while running Docker image

Hello,
I am currently trying to run the docker image on Rpi4 with fresh raspbian os. I am connected to internet using wifi connectivity instead of LAN. I have attached nRF52840 as my RCP device.
When I try to run the mqtt-sn OTBR it continues to fail by giving an error unable to start otbr-web.
Before that it was giving error unable to get ipv6tables but I resolved that after googling it.
What could be the issue here ?

Hello @nikhil1983 I am not sure what the issue is. I will try to run it on RPI myself the coming weekend.

Okay @osaether thanks.
Please check because I am facing issues with dhcpcd configuration (dhcpcd[] : wpan0 : IAID conflict with one assigned to wlan0) with the default border router image provided by Nordic.
So I am looking for a tried and tested border router solution compatible with the MQTT-SN example.
Also please let me know how I can change the broker IP address in the mqtt-sn gateway configuration file .
And if possible is there any documents available with you which you can share such as  building the OTBR with RCP design and setting up MQTTSN gateway will be helpful.

Hello @osaether  below are the build and run log of the docker image for reference.
build_log.txt
run_log.txt

Hello @osaether  any update ?

No, sorry I did not get time to look into it this weekend.

No, sorry I did not get time to look into it this weekend.

When can i expect a update ? Is there any documentation available ?


docs: Add link to Google documentation and documentation of underlying libraries

Add link to Google documentation and documentation of underlying libraries

added in #11


Remove phantom submodules

Fixes #35
NOTE: I'm not at all certain that this is the right fix. Maybe you want to add .gitmodules file instead?

Fixed in 49636e0


v0.1 - OCaml on the BEAM

Summary
I have not found an easy way to lay out what a release for Caramel should look like, so I'm sketching out this issue with a a big checklist of stuff that I think could be somewhat usable for pure-OCaml modules.
To do this we need:

the core type language, excluding support for the fancier features of the type system (like GADTs, or universal quantification in records), so variants, records, tuples, and type parameters.

immutable, functional ocaml, excluding all the imperative and object-oriented features, and some features like recursive let bindings which have no direct translation to Erlang

enough pattern matching so we can work with all the values allowed by the core type languages

support for modules, but not as first class values, and without functors or inclusions

This could already be enough to write some OCaml on the BEAM successfully. We'll see once we get there.
Checklist
To make it easier to keep track of what's what and where we currently are, here's a list of the features that are currently working and missing. Where necessary I'll try to make separate issues and link them here.
Idioms

[X] Empty tuple () is a common value in OCaml, this is translated to the atom ok in Erlang. This is not entirely idiomatic, since some functions  are generated that take for last argument the atom ok, but it is much nicer for the returned values.

[x] OCaml let rec's inside of a module-level function definition should be reported as errors. It is common in OCaml to define a recursive helper function to traverse a value using a default accumulator that is hidden from the user, but we can ask the programmer to move this outside for now. See #13

[x] OCaml allows ' (prime) to be used as part of variable names, so it's not uncommon to see x and x' and x''. The equivalent Erlang would be X, X1, and X2, primarily because the single quote is not a valid character to have in a name. See #15

[x] OCaml allows shadowing of names, which is not supported in Erlang. so that let x = 1 in let x = x + 1 in x yields 2. The equivalent Erlang would crash. See #16

Module System
The goal here is to support the basic OCaml module system, with its nesting and aliasing to provide a flexible and safe way of structuring large amounts of code. Module interfaces should be allowed to dictate what is exported and what isn't.

[x] Modules definitions -- we treat files as modules, and we can create nested modules. Nested modules will be flattened out into separate Erlang modules namespacing the module names. Modules without exports should generate no Erlang sources.

[x] Module interfaces -- interface files will be respected and anything that is not exported there will not be exported in the generated Erlang source. This applies to both types and functions.

[X] Module Declarations -- only functions will be allowed at the module level. Defining values should be an compilation error.

Type Language
These are the features of the type-language that I'm aiming to support and compile to Dialyzer specs.

[x] Type variables
[x] Phantom types -- should be turned into an unused type-variable that will be properly named with an underscore.
[x] Variants -- compiled into constructor_atom or {constructor_atom, arg0, arg1,...}
[x] Polymorphic Variants

[x] Explicit constructors -- compiled into constructor_atom or {constructor_atom, arg0, arg1,...}
[x] Inherited constructors

[x] Tuples
[x] Aliases
[x] Records
[x] Function types
[x] Interface files constrain exports of types

Expressions
The following expressions will be supported on the OCaml side

[x] Constant:

[x] Integers
[x] Characters
[x] String -- compiled to Erlang Binary strings
[x] Floats

[x] Values

[x] Records -- compiled to Erlang maps

[x] Creation
[X] Field access
[x] Update (See #23)

[x] Lists

[x] empty list
[x] list prepending / consing

[x] Tuples
[x] Variant constructors -- compiled to tagged tuples with constructor name as atom tag
[x] Polymorphic variant

[x] constructor without argumetns -- compiled to atom
[x] constructors with arguments -- compiled to tagged tuples with constructor name as atom tag

[x] Fun/Function -- compiled to Erlang fun's

[x] Let Bindings
[x] Identifiers

[x] Make sure all variable names translate to valid Erlang variable names (#15 #16)

[x] Functions

[x] References -- in Erlang there is a difference between passing F as a parameter, and passing a reference to a function. Waiting on #10
[x] Local calls (in scope or in module scope)
[x] Qualified calls
[x] Lambda calls

[x] Match expressions

[x] Cascading cases (match x with | 1 | 2 -> true) -- #9

[x] If Expressions -- compiled to case expressions
[x] Sequencing -- compiled to nested let-bindings with an ignore pattern
[x] Guards -- see #17

Patterns
These are the patterns that we can use on the left side of match branches and function headers.

[x] Ignore value
[x] Binding to variables
[x] Tuple
[x] List
[x] Records
[x] Variants
[x] Polymorphic variants
[x] Exact match

Foreign Interfaces

[x] Support for external

[x] without a name override
[x] with name overrides

Checklist
To make it easier to keep track of what's what and where we currently are, here's a list of the features that are currently working and missing. Where necessary I'll try to make separate issues and link them here.
Idioms

[X] Empty tuple () is a common value in OCaml, this is translated to the atom ok in Erlang. This is not entirely idiomatic, since some functions  are generated that take for last argument the atom ok, but it is much nicer for the returned values.

[x] OCaml let rec's inside of a module-level function definition should be reported as errors. It is common in OCaml to define a recursive helper function to traverse a value using a default accumulator that is hidden from the user, but we can ask the programmer to move this outside for now. See #13

[x] OCaml allows ' (prime) to be used as part of variable names, so it's not uncommon to see x and x' and x''. The equivalent Erlang would be X, X1, and X2, primarily because the single quote is not a valid character to have in a name. See #15

[x] OCaml allows shadowing of names, which is not supported in Erlang. so that let x = 1 in let x = x + 1 in x yields 2. The equivalent Erlang would crash. See #16

Module System
The goal here is to support the basic OCaml module system, with its nesting and aliasing to provide a flexible and safe way of structuring large amounts of code. Module interfaces should be allowed to dictate what is exported and what isn't.

[x] Modules definitions -- we treat files as modules, and we can create nested modules. Nested modules will be flattened out into separate Erlang modules namespacing the module names. Modules without exports should generate no Erlang sources.

[x] Module interfaces -- interface files will be respected and anything that is not exported there will not be exported in the generated Erlang source. This applies to both types and functions.

[X] Module Declarations -- only functions will be allowed at the module level. Defining values should be an compilation error.

Type Language
These are the features of the type-language that I'm aiming to support and compile to Dialyzer specs.

[x] Type variables
[x] Phantom types -- should be turned into an unused type-variable that will be properly named with an underscore.
[x] Variants -- compiled into constructor_atom or {constructor_atom, arg0, arg1,...}
[x] Polymorphic Variants

[x] Explicit constructors -- compiled into constructor_atom or {constructor_atom, arg0, arg1,...}
[x] Inherited constructors

[x] Tuples
[x] Aliases
[x] Records
[x] Function types
[x] Interface files constrain exports of types

Expressions
The following expressions will be supported on the OCaml side

[x] Constant:

[x] Integers
[x] Characters
[x] String -- compiled to Erlang Binary strings
[x] Floats

[x] Values

[x] Records -- compiled to Erlang maps

[x] Creation
[X] Field access
[ ] Update

[x] Lists

[x] empty list
[x] list prepending / consing

[x] Tuples
[x] Variant constructors -- compiled to tagged tuples with constructor name as atom tag
[x] Polymorphic variant

[x] constructor without argumetns -- compiled to atom
[x] constructors with arguments -- compiled to tagged tuples with constructor name as atom tag

[x] Fun/Function -- compiled to Erlang fun's

[x] Let Bindings
[x] Identifiers

[x] Make sure all variable names translate to valid Erlang variable names (#15 #16)

[ ] Functions

[x] References -- in Erlang there is a difference between passing F as a parameter, and passing a reference to a function. Waiting on #10
[x] Local calls (in scope or in module scope)
[x] Qualified calls
[ ] Lambda calls -- currently this prints f(A, B) for f(A)(B) since it has no way of knowing that f has arity 1.

[x] Match expressions

[ ] Support for grouping cases together (match x with | 1 | 2 -> true) -- #9

[x] If Expressions -- compiled to case expressions
[x] Sequencing -- compiled to nested let-bindings with an ignore pattern
[ ] Guards -- any guard expression should work on any pattern match case, except at the function clause level where only guards that compile to BEAM NIFs should be allowed.

Patterns
These are the patterns that we can use on the left side of match branches and function headers.

[x] Ignore value
[x] Binding to variables
[x] Tuple
[x] List
[x] Records
[x] Variants
[x] Polymorphic variants
[x] Exact match

Foreign Interfaces

[x] Support for external

[x] without a name override
[x] with name overrides

Aaand we're there. Closing this now.
I'm thinking that the next milestone will include no more work on this particular compilation chain, but rather on the inverse process: parsing and type-checking Erlang.
Thanks @nyaray for the push there to scope things more clearly.


Add test for findContainer

Adds a test for findContainer.
Closes 1/3 of https://github.com/redhat-developer/odo/issues/828

The test failure seems unrelated.
I also saw the same exact thing in another PR, looks like that failing test is flacky

@geoand , rebase with master, test will pass :smile:  :vulcan_salute:

Ready for another review @mik-dass @surajnarwade @sgk