Add auto registry for service end points

This makes endpoint builders auto register with service discovery.
    final ManagedServiceBuilder managedServiceBuilder =
             ManagedServiceBuilder.managedServiceBuilder();

    managedServiceBuilder.enableConsulServiceDiscovery("dc1");
...
        final ServiceEndpointServer serviceEndpointServer = managedServiceBuilder.getEndpointServerBuilder()
                .setUri("/").setEndpointName("api-services").setTtlSeconds(10)
                .build();

Notice the new methods on EndpointServerBuilder.
  .setEndpointName(...)
  .setTtlSeconds(...)
  .setServiceDiscovery(...)

The ManagedServiceBuilder is a nice class to manage system shutdown, shared stats like statsD, etc.
It is for non-spring users.
It has the following helper methods to enable consul service discovery.

    public void enableConsulServiceDiscovery(String dataCenter) {
        final ConsulServiceDiscoveryBuilder consulServiceDiscoveryBuilder = ConsulServiceDiscoveryBuilder.consulServiceDiscoveryBuilder();
        consulServiceDiscoveryBuilder.setDatacenter(dataCenter);
        serviceDiscoverySupplier = () -> consulServiceDiscoveryBuilder.build();
    }

    public void enableConsulServiceDiscovery(String dataCenter, String host) {
        final ConsulServiceDiscoveryBuilder consulServiceDiscoveryBuilder = ConsulServiceDiscoveryBuilder.consulServiceDiscoveryBuilder();
        consulServiceDiscoveryBuilder.setDatacenter(dataCenter);
        consulServiceDiscoveryBuilder.setConsulHost(host);
        serviceDiscoverySupplier = () -> consulServiceDiscoveryBuilder.build();
    }

    public void enableConsulServiceDiscovery(String dataCenter, String host, int port) {
        final ConsulServiceDiscoveryBuilder consulServiceDiscoveryBuilder = ConsulServiceDiscoveryBuilder.consulServiceDiscoveryBuilder();
        consulServiceDiscoveryBuilder.setDatacenter(dataCenter);
        consulServiceDiscoveryBuilder.setConsulHost(host);
        consulServiceDiscoveryBuilder.setConsulPort(port);
        serviceDiscoverySupplier = () -> consulServiceDiscoveryBuilder.build();
    }

It is similar to the Spring support we are working on but for non-Spring users.
It wires in the write pieces of the puzzle.

This is part of this release. https://github.com/advantageous/qbit/issues/308

This is part of this release. https://github.com/advantageous/qbit/issues/302

This one too. https://github.com/advantageous/qbit/issues/301

added checking with the health service if it is passed.
it even checks the health service to see if everything is ok
if you pass it a health service, it checks automatically.


[INFRA] Remove Travis

Why are the changes needed?

As mentioned in https://github.com/apache/kyuubi/issues/4139, we are not able to use Travis for AMR testing in the future.
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

Thanks, merged to master


Update July 2021

updating the Base image to jupyter/base-notebook:ubuntu-20.04
The old taging was confusing at least for me with a large number; therefore I prefer to have a meaningful tag name.  I checked the size of image and it is even smaller using this named tag. To update the name_tag, we can update the hash digest via @sha256:digest_number
using mamba to make the build process faster
update the dependencies
updated the readme

@jan-janssen, I would like to merge this after the new pyiron_continuum being released and updating the continuum image.

I created an openmpi version for DAMASK https://github.com/conda-forge/damask-feedstock/pull/35

I created an openmpi version for DAMASK conda-forge/damask-feedstock#35

Thanks @jan-janssen. I will update the environment accordingly.

I will merge this to update our docker images, but there are open issues, which I need to take care of soon.


Mark optional and mandatory fields in each cell

Is your feature request related to a problem? Please describe.
Somehow clearly mark  optional and mandatory fields in each smart cell
Describe the solution you'd like
Either add input coloring or mark fields with a colored asterisk next to their label.

This can be done with the :required key. The rest of the BaseComponents need to be checked for this property and enhanced if they don't have it

Completed with 76a9c26


Unable to parse logs (_grokparsefailure).

Hi,
I am using dbmail and while shiping /var/log/mail.log, logstash isn't able to parse the logs and in kibana it is showing [tags : _grokparsefailure]
Below is the snippet of my /var/log/mail.log
Apr 20 10:07:35 dbmail postfix/lmtp[29199]: master_notify: status 1
Apr 20 10:07:35 dbmail postfix/lmtp[29199]: connection closed
Apr 20 10:07:35 dbmail postfix/smtpd[29468]: disconnect from mail-la0-f50.google.com[<IP_ADDRESS>]
Apr 20 10:07:40 dbmail postfix/smtpd[28310]: connect from localhost[<IP_ADDRESS>]
Apr 20 10:07:40 dbmail postfix/smtpd[28310]: disconnect from localhost[<IP_ADDRESS>]
Below is the snippet of logstash log
{:timestamp=>"2015-04-20T06:05:24.332000-0400", :message=>"Exception in lumberjack input", :exception=>#<LogStash::ShutdownSignal: LogStash::ShutdownSignal>, :level=>:error}

This output is not yet supported:
Apr 20 10:07:35 dbmail postfix/lmtp[29199]: master_notify: status 1
Do you have verbose logging enabled?

can you mention any wayout for this.

Actually, after re-reading your question, I don't know. The error indicated by logstash has something to do with lumberjack, which I don't use (and has no relation with this project).
If you think that the problem is related to the patterns in this project, then please post a complete error message copy/pasted from kibana that describes an error while parsing a postfix input line.

I tried to parse logs using grok debugger with the patterns listed, but was unable to get any output.

You said you had error messages in kibana. Please show them, there is no way to help you otherwise.


When searching for users that don't exist, Pull Requests are not filtered

When you search for a user that doesn't exist, all Pull Requests are attributed to that "user".
This includes searching for email addresses, which I think is a contributor to #26 as well. If users have commits under a different email than their account, you effectively can't search for those without also getting incorrect PR counts.
Repro steps

Setup Activity Filters as follows:

Search for a string that isn't a valid user account
Include Created, Closed and/or Reviewed Pull Requests
Include at least one repository

Look at the contributions:

Expected: "0 contributions for the year"
Actual: Shows all pull requests (regardless of user) from any of the selected repositories

Example
Search for the string "non-existing-user" (which obviously doesn't exist)

Even more obvious, comparing "non-existing-user" with myself, both on a specific date:

The PR's I opened and reviewed are visible under both users
Two additional PR's reviewed by others are visible
You can also tell this is just PR's since no commits are visible for "non-existing-user"

Digging a bit, looks like the request is made to /_apis/git/repositories/{repositoryId}/pullrequests?searchCriteria.creatorId={creatorId}
using {creatorId} of "non-existing-user", whereas actual users use the account UUID.
My guess is the Azure DevOps API can't parse the value as a uuid, so it acts like searchCriteria.creatorId wasn't passed at all.

The lookup has a fallback to use uniqueName or displayName:
https://github.com/ostreifel/vsts-contributions/blob/c11f1fb7d8bfadb59aa967cf0950532b4979cf19/scripts/data/git/pullrequests.ts#L80
Seems like a fix for this would be to only ever use filter.identity.id and just return nothing if that value is empty?

Looks to be working. Thanks


New build profiles?

Two new build profiles showed up in GitHub a few days ago:
https://github.com/freenas/freenas-build/tree/master/build/profiles

fn9_head
fn9_stable

They're obviously FreeNAS 9 related, but what are they for? :smile:

This was answered on the freenas-devel mailing list earlier today: :smile:
    http://lists.freenas.org/pipermail/freenas-devel/2017-January/002938.html
They are the same as our current freenas9 build profile, except built
against FreeBSD 11 and FreeBSD 12 (stable/head respectively)

These are highly experimental, only so we can test / debug things like
drivers, updated ZFS, etc, long before it hits the stable branches of
FreeNAS.


Feature request: Add an eviction_callback parameter to the cache builder

Hey there, first and foremost thanks for moka!
I currently have this use case where I have other data structures I need to keep in sync with a moka cache. One way I though of doing this is the cache builder could support a new eviction_callback method which takes a closure that is called every time there is a cache eviction, with ideally both the key and value as parameters to the closure. Do you think that's feasible and if so, is this something you'd be interested in this being added to moka?
I envision something like:
pub fn eviction_callback<F>(&self, predicate: F)
where
    F: Fn(&K, &V) + Send + Sync + 'static,

or
pub fn eviction_callback<F>(&self, predicate: F)
where
    F: Fn(K, &V) + Send + Sync + 'static,
    K: Copy

Hi. Yes, notification on evictions is on our road map ("feat: Notifications on eviction, etc."). I just moved it up to second on the road map list (from sixth). I will start to work on it in next week.

FYI. I started to work on this via the following pull request:

#145

@tatsuya6502 I'm always excitedly curious to see what you do, so took a peek at the work.
I noticed that your eviction listener differs slightly in execution semantics to Caffeine's. I thought it might help if I clarify the history and intent of our api, though freely ignore our semantics.
The cache originally offered a RemovalListener for any cause, which is invoked outside of any cache locks. In CLHM / Guava this is on a calling thread by stashing into a mpmc queue during the write operation and all threads poll the queue at the end of their operation. The caller could defer that to a background pool themselves if expensive work. Caffeine defaults to be async by submitting to Java 8+ shared thread pool, so it avoids having an internal queue that threads might contend on. I'm not a fan of libraries silently creating threads, so this was taking advantage of new platform capability but might not be ideal in Rust. Regardless, when the event is processed and the order of notifications is unspecified.
A complaint is that sometimes the business logic requires key-based ordering of events that are performed synchronously with the operation. For example if removal deletes a local file then a race to add it back might find the file still exists and the listener leaves the cache in an inconsistent state (a cache entry but no file). Therefore, an ability to invoke the listener as part of the map operation was needed.
Since RemovalListener was already defined as non-blocking, we needed some new concept. At first I tried to borrow a concept from distributed caches, CacheWriter, but that was a bad fit, deprecated, and removed. Instead, I added a variant called EvictionListener that reuses the RemovalListener lambda interface and is synchronous. This variant is only called during an automatic removal, e.g. size eviction, and not on a manual (explicit) removal. For a callback on explicit removals, the Map.compute methods allow for rich functionality so a user can invoke their logic explicitly. This evolution minimized the new concepts and used familiar terms, but might not be ideal if designed with the api originally.
It might be that in a new api you would want to register a RemovalListener with a flag / builder method to specify if blocking or non-blocking. The non-blocking might optionally defer to a thread pool, either explicitly or implicitly depending on what is idiomatic to Rust. My guess is that you would prefer to avoid a threadpool, like Guava/CLHM, and require that users to defer it explicitly. Or you might have that pool anyway for async caching, so I am clueless here.
Anyway, I hope that helps you in your api design!

Thanks @ben-manes for sharing your experience and insight. I am learning lots from them!
As you might have already seen, current implementation is similar (but not the same) to Caffeine's RemovalListener:

It is non-blocking.
It defers notifications to a thread pool.

and I noticed that unordered events for a key can cause the issue you said:

For example if removal deletes a local file then a race to add it back might find the file still exists and the listener leaves the cache in an inconsistent state (a cache entry but no file).

So I made the example in the doc to avoid the issue by generating a unique file name on every file creation. I was thinking to add some texts to explain why the file names have to be unique even for the same key.

It might be that in a new api you would want to register a RemovalListener with a flag / builder method to specify if blocking or non-blocking.

I think it is a great idea to have blocking or non-blocking option per cache. I have a feeling that adding blocking option is not very hard, though I have to add per-key writer lock to some places, which could be tricky. I will give it a try now.

The non-blocking might optionally defer to a thread pool, either explicitly or implicitly depending on what is idiomatic to Rust. My guess is that you would prefer to avoid a threadpool, like Guava/CLHM, and require that users to defer it explicitly.

Avoiding a thread pool by default (for non-blocking notification and other housekeeping tasks like entry expiration) is something I wanted to do on Moka cache. I will try to implement it for notification now (hope it is easy enough), and will deffer for other housekeeping tasks to a near future release.

HI @fbernier, Which cache are you using? (sync::Cache or future::Cache?)
I found that supporting blocking notification in future::Cache will require non-trivial amount of work. I will have to duplicate a couple thousands code with regular fns and sync locks and convert them into async fns and async locks. I am still checking if there are any other ways to minimize the changes though.
If you are using sync::Cache, I could soon release a version only with the eviction listener for it, and then a few weeks or a month later, I will release another version for future::Cache.

Hi folks, thanks for your efforts on building such a good lib. 🥰 I'm also a user that needs this feature with future::Cache. I'd like to try it first. Is using the branch of #145 okay now?

Hi @fbernier,

my use-case with the eviction callback is currently with the sync cache, so all good for me on that front.

It is great to hear! Thanks.

Hi @MrCroxx,

I'm also a user that needs this feature with future::Cache. I'd like to try it first. Is using the branch of #145 okay now?

Yes, the branch eviction-listener should be ready for you. I will add few more changes in next few days but it will be good enough now already.
moka = { git = "https://github.com/moka-rs/moka", branch = "eviction-listener", features = ["future"] }`

To use the eviction listener, see the "Eviction Listener" example in the doc comment: https://github.com/moka-rs/moka/blob/eviction-listener/src/future/builder.rs#L55
You may have already read, but in coming release (v0.9.0), future::Cache will only support non-blocking notification mode. With this mode, notifications will be arrived in short delay after the time when the evictions actually occurred, and it will not work for some use cases very well. These unordered events may leave the cache and the external resources inconsistent)
For example:
Non-blocking notification mode
This mode does not guarantee that the notifications for a specific key are ordered.
(Tn means wall clock time)

T1: Create a future cache with time-to-live configuration.
T2: Insert a key, and create an external resource.
T3: The key has been expired, but the key may have not been removed from the cache.
T4: Get the key and no value returned, but the key may have not been removed from the cache.
T5: Insert the key again, and create the external resource again.

But it may notice the external resource from T2 still exists, or it does not notice and overwrites the resource.
This may replace the key (T2) in the cache with another (T5).

T6: The eviction listener is called with the expiration event at T3 (actually triggered at T5).

The listener may remove the external resource created at T2 (correct) or T5 (wrong).

T7: The key has been expired again.
T8: The housekeeping thread removes the key from the cache.
T9: The eviction listener is called with the expiration event at T7 (actually triggered at T8).

The listener may remove the external resource created at T5, but it may have been already removed at T6?

Blocking notification mode
This mode guarantees that the notifications for a specific key are ordered.

T1: Create a future cache with time-to-live configuration.
T2: Insert a key, and create an external resource.
T3: The key has been expired, but the key may have not been removed from the cache.
T4: Get the key, and no value returned, but the key may have not been removed from the cache.
T5: Insert the key again...
T6: Before returning from the insertion at T5, the eviction listener is called with the expiration event at T3.

The listener will remove the external resource created at T2 (correct).

T7: The insertion at T5 will return after the listener returned.

So it will create the external resource again.

T8: The key has been expired again.
T9: The housekeeping thread removes the key from the cache.
T10: The eviction listener is called with the expiration event at T8 (actually triggered at T9).

The listener will remove the external resource created at T7 (correct).

To avoid the issues in above non-blocking example, you could assign unique names to the external resource created at T2 and T5. (See the example in the doc)

I had forgotten about async caches and synchronous removal listening in my earlier message. That’s a great reason to not support a generic synchronous listener for explicit removals. For evictions an in-flight future should probably be skipped so a synchronous callback is viable. That is how Caffeine gets around this, where futures are ineligible for eviction until complete.

Sorry for some delay. I could not find enough time for working on this during weekdays.
But finally, I think https://github.com/moka-rs/moka/pull/145 is now ready for merge. I will self-review it in tomorrow morning (I live in China mainland UTC+0800 and its 10pm now) and will merge it if I do not see any issue.
I implemented the blocking and non-blocking modes to the sync caches, and implemented only non-blocking mode to the future cache. To configure an eviction listener with a mode, I created an enum DeliveryMode with two variants Immediate, meaning blocking, and Queued, meaning non-blocking.
I could not implement non-worker threads version of the immediate/queued modes just because lack of time. So currently both rely on the worker threads.

Closing this issue as I merged PR #145 into the next branch, and then merged the next branch into the master branch.
I will run some pre-release testing, and if everything goes well, I will publish Moka v0.9.0 to crates.io.

@fbernier @MrCroxx
I have published Moka v0.9.0 to crates.io.
Documents:

sync::Cache — Example: Eviction Listener
future::Cache — Example: Eviction Listener

Thanks a lot! Happy to hear that and can't wait to try! 🥰


Add list_context() method

I'd like to be able to list all the contexts in the runtime, this method adds that capability.

Thanks @only-cliches !


Fast corner extraction slower than OpenCV

Hey guys,
Recently compiled ComputeLibrary for iOS arm64 architecture, and did a fast corner keypoint extraction comparison between OpenCV and the ARM Compute routine.
Based on what I'm seeing, for an 8-level image pyramid with the largest resolution of 640x360, I'm seeing a 64ms +/- 50ms performance for the Compute Library, and 17ms +/- 2ms for OpenCV. Both libraries were compiled with O3 and ftree-vectorize flags in XCode, with the same fast corner parameters.
Any clue to the worse performance despite NEON acceleration?

Hi @y22ma
Thanks. We are aware of the performance difference between the two implementations of this function. We will look into this.

Much appreciated.

Checking if there's an update on this? Any hint for me to look into myself?

No, currently our focus is on the machine learning functions, unfortunately we don't have the bandwidth to investigate computer vision performance issues.

Hey guys,
Recently compiled ComputeLibrary for iOS arm64 architecture, and did a fast corner keypoint extraction comparison between OpenCV and the ARM Compute routine.
Based on what I'm seeing, for an 8-level image pyramid with the largest resolution of 640x360, I'm seeing a 64ms +/- 50ms performance for the Compute Library, and 17ms +/- 2ms for OpenCV. Both libraries were compiled with O3 and ftree-vectorize flags in XCode, with the same fast corner parameters.
Any clue to the worse performance despite NEON acceleration?

Hi Yan,
We have met the same issue and we are looking into it and try what was discussed on https://github.com/ARM-software/ComputeLibrary/issues/128
Just a following up, are you guys still using arm ComputeLibrary for frontend computations such as feature extraction in your work?
Best regards

Hello @kanster ,
We are in the process of deprecating our CV functionality as this is something that we don't actively support. Do you use it or is this of concern?
On the fast corners aspect I think the algorithm implemented by Compute Library vs OpenCV is different, that is the reason behind the performance gap.
Regards,
George

Hello @kanster ,
We are in the process of deprecating our CV functionality as this is something that we don't actively support. Do you use it or is this of concern?
On the fast corners aspect I think the algorithm implemented by Compute Library vs OpenCV is different, that is the reason behind the performance gap.
Regards,
George

Hi George,
We were trying to use ComputeLibrary to speed up low-level feature extraction methods to run our SLAM system on mobile devices. We were hoping that this library provided by ARM could provide better performance compared with our implementation using NEON.
So, in my understanding, sooner or later, these functionalities will be deprecated from ComputeLibaray and ComputeLibrary will be focused on DL tasks optimization, is that correct?
Best regards
Kanzhi

Hi @kanster
Yes, that's right. CV functions in ACL will be deprecated in 20.11 and removed in 20.05.


Make Server.accept public

Closes https://github.com/karlseguin/websocket.zig/issues/34

I'm rarely opposed to making things public!


SelectionSort Method in Linked List

The SelectionSort() is not a SelectionSort its a BubbleSort

@AnaMale - just merged your #93 PR, do you want to submit another PR for fixing the DLinkedList data structure in a similar fashion?

Fixed in #118 by @kdimolikas.


[Question] Would this work with flask-restx?

I want to add pydantic data validation to my flask-restx API and have the swagger documentation update accordingly.
Will I be able to do it with this library?
Thank you!

So funnily enough, we are using Flask-RestX in the same Python application, however we haven't found a way to run them on the same resources.
I'm not sure if it would be possible to mix these libraries in the way you suggest - FlaskPydanticSpec is our way of moving away from using FlaskRestX completely.  It's a great framework, but we wanted something a little closer to the Flask way of doing things.
Let me know if you manage to get them to play nicely alongside each other - it would certainly be interesting to me!


FIX: Increase bucket listing limit to 10,000

Fixes #633

@ironman-machine go

Hello @LaurenSpiegel
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "DEFAULT_BRANCH": "master", "SCALITY_S3_BRANCH": "fix/bucketListing"}
Please follow http://ci.ironmann.io/gh/scality/Integration/10101 for CI status.

@ironman-machine with only one before statement

Hello @LaurenSpiegel
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "DEFAULT_BRANCH": "master", "SCALITY_S3_BRANCH": "fix/bucketListing"}
Please follow http://ci.ironmann.io/gh/scality/Integration/10106 for CI status.

@ironman-machine testy...

Hello @LaurenSpiegel
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "DEFAULT_BRANCH": "master", "SCALITY_S3_BRANCH": "fix/bucketListing"}
Please follow http://ci.ironmann.io/gh/scality/Integration/10118 for CI status.

@ThibaultRiviere, yes.  I'm playing with 1001 right now.  once that works, I can increase to 10,000.

@LaurenSpiegel Perfect thanks :)

@ironman-machine without retries

Hello @LaurenSpiegel
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "DEFAULT_BRANCH": "master", "SCALITY_S3_BRANCH": "fix/bucketListing"}
Please follow http://ci.ironmann.io/gh/scality/Integration/10126 for CI status.

@ironman-machine with slower deletes

Hello @LaurenSpiegel
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "DEFAULT_BRANCH": "master", "SCALITY_S3_BRANCH": "fix/bucketListing"}
Please follow http://ci.ironmann.io/gh/scality/Integration/10132 for CI status.

@ironman-machine with 10000 buckets

Hello @LaurenSpiegel
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "DEFAULT_BRANCH": "master", "SCALITY_S3_BRANCH": "fix/bucketListing"}
Please follow http://ci.ironmann.io/gh/scality/Integration/10134 for CI status.

@ironman-machine with concurrency test

Hello @LaurenSpiegel
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "DEFAULT_BRANCH": "master", "SCALITY_S3_BRANCH": "fix/bucketListing"}
Please follow http://ci.ironmann.io/gh/scality/Integration/10151 for CI status.

@ironman-machine just to see again

Hello @LaurenSpiegel
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "DEFAULT_BRANCH": "master", "SCALITY_S3_BRANCH": "fix/bucketListing"}
Please follow http://ci.ironmann.io/gh/scality/Integration/10160 for CI status.

@ironman-machine once more

Hello @LaurenSpiegel
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "DEFAULT_BRANCH": "master", "SCALITY_S3_BRANCH": "fix/bucketListing"}
Please follow http://ci.ironmann.io/gh/scality/Integration/10185 for CI status.


feature request

Hi is there a chance to have an option to turn off the bypass to allow anyone to go past the border.
We currently use an old modified version that achieves this for us but we would like to update to a version that's actually made against 1.16. so I am asking here if this can be done within your update
regards
Scalda

Did not know the current version doesn't allow you to bypass the border, interseting. I'll take a look into it!

You can bypass the border with "wb bypass  [on|off] - let player go beyond border." i think.


Provide ability to define dsc-v3 resource path (Support sxs installation)

Summary of the new feature / enhancement
dscv3 is relying on system variable ($env:path) for resource discovery.  Provide an ability to specify the directory for all dscv3 resources.
- This will enable sxs installation possible.  (GC-Agent supports this)
- DSC is slow locating resources since it is checking a big list of paths in $env:path.
Proposed technical implementation details (optional)
Pass optional DSC_Resouce_Path to DSC .
No response

Overwriting the system $env:path in the process may impact locating executable or other resource dependencies that are already under $env:path

I agree with BerheAbrha. Resources called and the processes spawned calling those may depend on PATH being intact. We will need to support either specifying the search path(s) as an argument or support another ENV var that would be used if specified instead of PATH. (Think something similar to PSModulePath)

We can have a DSC_RESOURCE_PATH env var that, if defined, overrides any search of PATH.


Request For Clarification

I hope you're doing well! I recently came across your project titled "Splash-React-Native-Screens" on your profile, and I noticed that it lacks detailed information about the project. As a potential collaborator or someone interested in the project, it would be helpful to have a clearer understanding of the following aspects:
-Project Overview.
-Technologies/Tools Used.
-Target Audience.
-Project Status.
-Challenges & Solutions.

Hi! Thank you for taking the time to check out my project, I appreciate your interest and your feedback about the need for more detailed information. I'll be sure to update the repository soon to provide a comprehensive view of the project.


chore(Makefile): bump dev-registry to use 0.9.1

@mboersma wasn't there an issue with 0.9.1 during your testing?

@ngpestelos I left this out of the other PR because it crashed on me a couple times, so I left dev-registry at 0.9.0. But I didn't figure out what exactly the problem was. I'll test again with this PR and see if I can reproduce the issue, or if this is good to go. Thanks!

Code LGTM.

I haven't seen any issues recently using registry:0.9.1. Code LGTM.


Emitter is deprecated in Kefir now

We discussed that with @rpominov and I should probably re-implement it inside since it's quite useful for RPD as an API, but not so recommended to common Kefir users :).

Also see: https://github.com/rpominov/kefir/issues/88#issuecomment-99817611 and this: https://github.com/rpominov/kefir/issues/88#issuecomment-102190976

Discussion: https://gitter.im/pozadi/kefir?at=55782efc05c872ce6ac88861 and below


--info-text not displaying in preview window on Raspi OS lite (Bullseye)

Hello, first of all let me apologize if I missed something obvious, but I did search all around and nobody seems to either have the same issue or using my same setup.
I made a very simple but effective timelapse camera setup that uses a Raspberry Pi Zero W and small hdmi monitor to do a preview setup.
When I was using Buster (with the old camera stack) I could use --focus to show a small window with focus information and it worked fine. Now with libcamera, documentation says I can use --info-text "%focus" to do something similar, the issue is that since I am using the lite version of Raspi OS with no window manager the preview image has no title bar, thus no focus info or no info at all when using --info-text "whatever" is this a limitation or is it something that I am missing?
Is there a way to maybe force it to be displayed inside the preview window?
Here is an example when using --verbose=2
 libcamera-hello --info-text "%focus" --verbose=2
Options:
    verbose: 2
    info_text:%focus
    timeout: 5000
    width: 0
    height: 0
    output:
    post_process_file:
    rawfull: 0
    preview: default
    qt-preview: 0
    transform: identity
    roi: all
    metering: centre
    exposure: normal
    ev: 0
    awb: auto
    flush: false
    wrap: 0
    brightness: 0
    contrast: 1
    saturation: 1
    sharpness: 1
    framerate: 30
    denoise: auto
    viewfinder-width: 0
    viewfinder-height: 0
    tuning-file: (libcamera)
    lores-width: 0
    lores-height: 0
    mode: unspecified
    viewfinder-mode: unspecified
No connector ID specified.  Choosing default from list:
Connector 32 (crtc 89): type 11, 1280x800 (chosen)
Made DRM preview window
Opening camera...
[0:51:50.124743166] [1033]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3866-0c55e522
[0:51:50.298528667] [1034]  INFO RPI raspberrypi.cpp:1374 Registered camera /base/soc/i2c0mux/i2c@1/imx477@1a to Unicam device /dev/media3 and ISP device /dev/media0
Acquired camera /base/soc/i2c0mux/i2c@1/imx477@1a
Configuring viewfinder...
Viewfinder size chosen is 2028x1520
Final viewfinder size is 2028x1520
[0:51:50.314258531] [1033]  INFO Camera camera.cpp:1035 configuring streams: (0) 2028x1520-YUV420
[0:51:50.320353478] [1034]  INFO RPI raspberrypi.cpp:761 Sensor: /base/soc/i2c0mux/i2c@1/imx477@1a - Selected sensor format: 2028x1520-SBGGR12_1X12 - Selected unicam format: 2028x1520-pBCC
Camera streams configured
Available controls:
    AeEnable : [false..true]
    ExposureTime : [60..127156999]
    ScalerCrop : [(0, 0)/128x128..(0, 0)/4056x3040]
    AnalogueGain : [1.000000..22.260870]
    AeMeteringMode : [0..3]
    ColourGains : [0.000000..32.000000]
    ExposureValue : [-8.000000..8.000000]
    Sharpness : [0.000000..16.000000]
    Contrast : [0.000000..32.000000]
    NoiseReductionMode : [0..4]
    FrameDurationLimits : [24994..127157333]
    Brightness : [-1.000000..1.000000]
    AwbMode : [0..7]
    AwbEnable : [false..true]
    ColourCorrectionMatrix : [-16.000000..16.000000]
    AeExposureMode : [0..3]
    Saturation : [0.000000..32.000000]
    AeConstraintMode : [0..3]
Buffers allocated and mapped
Viewfinder setup complete
Requests created
Camera started!
Viewfinder frame 0
Viewfinder frame 1
...
Viewfinder frame 123
Closing Libcamera application(frames displayed 123, dropped 0)
Camera stopped!
Tearing down requests, buffers and configuration
Camera closed

Thanks!

Now with libcamera, documentation says I can use --info-text "%focus" to do something similar, the issue is that since I am using the lite version of Raspi OS with no window manager the preview image has no title bar, thus no focus info or no info at all when using --info-text "whatever" is this a limitation or is it something that I am missing?

This is correct.  Since you are using the DRM preview mode when no window manager is present, the info text will not display.  An alternative would be to setup a remote display (with ssh -X) and use the --qt-preview option.  This will allow the remote display to show the titlebar along with the focus values.

Ah that is unfortunate, due to my setup I do not have access to SSH the device easily.
Is adding the information to the DRM preview something that is considered for the future?

This is not something we plan on adding anytime soon unfortunately.  However, you might be able to use the annotate_cv software postprocessing stage to write info-text directly onto the image, if that is a suitable thing to do.  See here for more details.

For DRM preview the libcamera app is the master, and therefore could add an additional layer to take info text. Doing so shouldn't be too tricky, but will require a modicum of coding. If we already have code that writes the text to a layer for GL to render, then that bit can probably be common.

If we already have code that writes the text to a layer for GL to render, then that bit can probably be common.

The text is displayed on the titlebar of the GL window, so we do not have any code to write text to a separate GL layer.

The text is displayed on the titlebar of the GL window, so we do not have any code to write text to a separate GL layer.

OK, text rendering isn't beyond the wit of man to achieve.

This is not something we plan on adding anytime soon unfortunately. However, you might be able to use the annotate_cv software postprocessing stage to write info-text directly onto the image, if that is a suitable thing to do. See here for more details.

Thank you, but if I understand correctly, this is not what I need. This will write the text on the images directly
 This allows other post-processing stages to pass it text strings to be written onto the top of the images.
What I need is to use it in real time before taking any photo so I can adjust the focus

This is not something we plan on adding anytime soon unfortunately.

Thank you, I appreciate your time! I guess my only option is to keep using the old stack.

I'll put DRM preview overlays on the backlog, but it will be some time before I get to it.


adding multiple identical services to an accessory

I tried to add two Service.Lightbulb() to one device
HAP complained about missing subtype (ok, was in a PR some time ago).
But I found

the subtype cannot be used when using the generated types, as the parameter is not passed
when adding the subtypes directly myService.subtype="string1" etc. there appear as much services in legato EVE, but they are all the same (the latest added service).
Broken or did just wreck it myself?

Nice effect however: the Characteristic.Name is shown in EVE if multiple services with same UUID are present. However, as stated above, it is always the latest added, repeated.

You should be able to add multiple Services of the same "type" (like Lightbulb) as long as you specify different display names and subtypes in the constructor - i.e. new Service.Lightbulb("Display Backlight", "backlight")

No, that fails.
The signature in HomeKitTypes.js is
Service.Lightbulb = function(displayName) {

there is no subtype passed to the super constructor.
  Service.call(this, displayName, '00000043-0000-1000-8000-0026BB765291');

JUST AS I WRITE my HAP-nodeJS clone is outdated.
Closing.

npm update helped to get the right signature for the constructor. Sorry for the confusion. I had updated homebridge, but not the dependencies. Something I have still to get acquainted to.

Sorry, changed the behavior but didn't work for me.
I have tried to add
 var light1 = new Service.Lightbulb("Main","main");  and
 var light2 = new Service.Lightbulb("Second","second")
but it shows Second twice in EVE, and the events of both in display belong to the later added (i.e. returned in the platform shim) with return [informationService, light1, light2]

I probably have to re-investigate all this, as it seems yesterday at about 0h UTC iCloud was down or at least very slow and did not always send correct data. Another thing I wrote yesterday (knx thermostat shim) didn't work in the night but does this morning (at 8 UTC).
I'll get back to this.

Even with iCloud being back online and a complete refactoring of my code, adding two services of the same type lead to having the second service twice.

Another similar issue: when I add multiple distinct! services to one device, and try to add homebridge to homekit, it "unpairs" itself after the PIN
  Accessory [Homebridge] Paired with client 9270ACEE-7894-4197-90B5-61EB96D321CD +34ms
  EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished +23ms
  EventedHTTPServer [<IP_ADDRESS>] Client connection closed +17ms
  EventedHTTPServer [<IP_ADDRESS>] HTTP connection was closed +2ms
  EventedHTTPServer [<IP_ADDRESS>] HTTP server was closed +1ms
  EventedHTTPServer [<IP_ADDRESS>] New connection from client +10ms
  EventedHTTPServer [<IP_ADDRESS>] HTTP server listening on port 54826 +1ms
  EventedHTTPServer [<IP_ADDRESS>] HTTP request: /pair-verify +5ms
  HAPServer [CC:22:3D:E3:CE:30] HAP Request: POST /pair-verify +1ms
  HAPServer [CC:22:3D:E3:CE:30] Pair verify step 1/2 +2ms
  EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished +21ms
  EventedHTTPServer [<IP_ADDRESS>] HTTP request: /pair-verify +19ms
  HAPServer [CC:22:3D:E3:CE:30] HAP Request: POST /pair-verify +1ms
  HAPServer [CC:22:3D:E3:CE:30] Pair verify step 2/2 +2ms
  HAPServer [CC:22:3D:E3:CE:30] Client 9270ACEE-7894-4197-90B5-61EB96D321CD verification complete +7ms
  EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished +3ms
  EventedHTTPServer [<IP_ADDRESS>] HTTP request: /accessories +5ms
  HAPServer [CC:22:3D:E3:CE:30] HAP Request: GET /accessories +1ms
  EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished +8ms
  EventedHTTPServer [<IP_ADDRESS>] HTTP request: /pairings +108ms
  HAPServer [CC:22:3D:E3:CE:30] HAP Request: POST /pairings +1ms
  HAPServer [CC:22:3D:E3:CE:30] Removing pairing info for client +2ms
  Accessory [Homebridge] Unpairing with client 9270ACEE-7894-4197-90B5-61EB96D321CD +1ms

Is there a way to identify what HomeKit is complaining about?

So HomeKit will "unpair" if it doesn't like something about the returned accessories/services.

Does it remember that it doesn't like a device/bridge? Because when a add a thermostat service (to a new accessory or to an existing accessory) it stops working, if I remove it again to the status before, it doesn't resume talking to homebridge.
I can only reset HomeKit data and rm persist/*  to start it again.

So there seems to be a "blocked" state where HomeKit will (temporarily?) blacklist a device that it doesn't like. In MyTouchHome, you can press and hold on the bridge and "Unblock" it. I'm not sure how you do that in the other HomeKit apps though.

Cool, I have myTouchHome installed though I didn't use any more, EVE has the more user friendly UI.
Strange thing I found though.
If I add a thermostat accessory with a blank service, i.e. var myService = new Service.Thermostat() I can connect to homebridge. If a add listeners to the CurrentTemperature characteristic, everything is still fine. But if I do exactly the same to TargetTemperature characteristic, HomeKit immediately refuses to talk to me.
I use the same method to bind the characteristic to the events:
https://github.com/snowdd1/homebridge/blob/knx-dev/accessories/knxdevice.js#L373
I am not adding any more characteristics, just get ting the existing and adding events with characteristic.on, and passing the reference to my array of callbacks.
For now I am clueless.

@snowdd1 on the computer you host the Homebridge, can you try open http://<IP_ADDRESS>:51826/accessories and post the JSON here?

@KhaosT I put both versions as Gists.
Without events added : https://gist.github.com/snowdd1/7710b2dba33d7cb4b284
With events : https://gist.github.com/snowdd1/79ecec24dd1345ce1a56
I think they are identical. I am lost :frowning:

In MyTouchHome, you can press and hold on the bridge and "Unblock" it.

@nfarina How do you do that? If I hold the bridge on my iPad it doesn't do anything.

When desperately tried removing and repairing, myTouchHome (more talkative than EVE) stated that the error was a value higher than maximum
I am just wondering which value that could be. Removing the thermostat immediately enables repairing after clearing homekit and persist.

Ok, found it. The TargetTemperature came immediately back with a value of 0, which is below the minimumValue of 10.
Strange values however, it should have been 7 (Default Frost Protection value with my thermostat), but that HK wouldn't have liked either.
So THAT issue is solved.
Did you ever tried to put two lamp services into one accessory - and succeeded?

@snowdd1 you can override the minimal value to 0 or -100 so that HomeKit will pair with the accessory.

@snowdd1 and multiple services works for me ... https://gist.github.com/KhaosT/371bfd8a4c86acd78d2d

override the minimal value
Did that, works fine, plus did a check when values come in on minimum and maximum.

and multiple services works
ARE THERE naming conventions on the subtypes? I tried to put the displayName as subtype as that was already there and unique - I saw you used no-whitespace & lowercase in subtype

var light1 = new Service.Lightbulb("Light 1","1light");
var light2 = new Service.Lightbulb("Light 2","2light");

I had tried with new Service.Lightbulb("Light 1","Light 1") - etc. , and failed.

@snowdd1 subtype can be any string (with/without space)... I'm not sure why your's failed. Does server produce any error when that happens?

No it just looks strange in EVE. I put back in the var myService = new Service.LockMechanism(config.name,config.name); etc. and try again, let's see how it looks in myTouchHome.

hello,
i am new to this homebridge stuff, if i understand this topic right it is about merging 2 lamps into one virtual device right?
after i playing around with homebridge this was the first thing i hoping for, because i have 2 lamps with 3 bulbs.
but the problem is i don't understand how to do it :D

frankly, I do not know what I messed up the last two times, but now it's working like a charm.
In EVE the service names appear neatly next two the accessory name. I had added a device "Office" with "Office lamp" and "Aisle lamp".
While I type HK or EVE gets confused in the background. My two lights first vanished, then reappeared as a duplicates of the latter light - Aisle lamp is there twice, and the Office lamp is gone. If I change the power state, always Aisle lamp is switched.
But in myTouchHome I still see two "Lightbulb"s without names, that control my Office lamp and my Aisle lamp separately.
So I guess it's a bug in EVE after all. Let's wait for the updates for iOS9 then.
Good night :smile:

how do i use the light.js?
i copied it to HAP-NodeJS/accessories/Wohnzimmer_accessory.js and restart the homebridge, what else do i need to do?


Send ic-select-from-response as part of a request?

I checked the fora and the issues, but couldn't find anything of note, so ... is there a reason not to send any ic-select-from-response value attached the the request, as either a header or a querystring parameter? If present, it would allow for the server to potentially pare down the response being delivered based on the client's hint. So the backend service could return a full (or partial) response, and then a middleware could reduce that down further, and then Intercooler could (if necessary) do the same.
As it stands, its possible to return the whole page's (rather than a separate partial) HTML content and use ic-select-from-response to progressively move towards partials. This is nice because it allows for slowly implementing on top of an older system. By allowing the server to have more involvement in the response, it could be further refined.

It's a good idea, but I always like to push back a bit on things like this to see how necessary it is:  when I use intercooler I often check to see if the ic-request request parameter is present and render a stripped down version of the content if so.
Why isn't this good enough?  (I have my reasons, I'd like to hear yours.)

So, ic-request is enough to know on a per-request basis whether a template may be replaced with a partial/stripped down version of the request. But it still requires active intervention to do so; a developer has to opt-in on a per-page/controller/view basis and knowingly make the change.
One of the nicest things (IMHO) about Intercooler's featureset (beyond being a simple declarative attribute way of handling AJAX) is that its possibly to progressively enhance an existing app by leveraging select-from-response. So I can do things like attach an post-to to a form and use select-from-response to replace the whole form, giving the illusion of complex inline validation without doing any, or doing a full page reload (along with the teardown and setup rendering, multiple requests for assets potentially, etc)
If select-from-response were provided to the server, I'd be able to apply a middleware over a response, and if the request were intercooler driven, I could use a library to parse the response and filter out the target, and re-wrap it in a <div> or <span> (so that the inner html is correct) automatically so that Intercooler received the minimal response it needs to fulfil the replacement.
This isn't something I need as such, but it would offer more opportunity for the server to intervene, and is something I'd probably make use of in a reusable Django app I'm writing for Intercooler related functionality (so far just a couple of middlewares), and could offer an easier plug-and-play happy path for integration with extant projects.

As a comparison implementation, the Unpoly.js library as the up-target attribute, so you can do, say, up-target="#blah" and it will replace the element with the id of blah in the current document with the one of blah in the next document, multiples can be separated with spaces, any selector works so if you select, say, ".blah" then it will replace all elements with the class of blah on this page with the ones from the next in the same order that they appear, removing as necessary but will not add.  It would be a useful feature to add here.  :-)
The unpoly.js documentation for up-target:  http://unpoly.com/a-up-target

Alright, I'm convinced.  I'll implement it now.


[stable/nginx-ingress] electionID should be based on release name

Describe the bug
When installing multiple nginx-ingress from the current chart, only one controller will publish services due to electionID not being unique to the release.
Release name not in electionID https://github.com/helm/charts/blob/master/stable/nginx-ingress/templates/controller-deployment.yaml#L61
Version of Helm and Kubernetes:
helm: 2.14.1
k8s: 1.12.8
Which chart:
stable/nginx-ingress
What happened:
First ingress controller only publishes service if the class name matches.
What you expected to happen:
Each ingress controller to work independently based on ingress objects making its class name.
How to reproduce it (as minimally and precisely as possible):
Install two ingress controllers with different class names
Notice only one is publishing services, the other one never gets leader election for kubectl logs | grep status.go
Anything else we need to know:
Tribal knowledge is required to make multiple chart installs work. These should just work. There's a similar problem with class names, but that documentation is far more clear on class annotations.
https://github.com/kubernetes/ingress-nginx/issues/1976#issuecomment-412827125

at a minimum election should be based off class name and possibly even have overrides with a default of either release or class name


HDDS-7425. Add documentation for the new Streaming Pipeline feature.

What changes were proposed in this pull request?
This is to document the new Streaming Pipeline feature (HDDS-4454).
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-7425
How was this patch tested?
NA

@duongkame

@DaveTeng0 , @kerneltime , @duongkame , thanks a lot for reviewing this!


Fix regression when no image features are provided

Describe what this PR does
There is an issue that if the storage class was originally created with no image features (which worked fine), it would fail when upgrading the Ceph CSI.
The regression was introduced by this commit:
https://github.com/ceph/ceph-csi/commit/d8f7b38d3dac9718695ff6c33328f5f6cfce2c2f
Several users have filed issues about this, see listed in related issues below.
Is there anything that requires special attention
This is a regression which really hurts when upgrading (and only noticed when remounting volumes).  It's incredibly hard to fix in production because PVs are read-only.  Users could potentially lose their data if they try and force a replace as the PV is recreated.
Related issues
Fixes: #1937
Fixes: #2049
Future concerns
None for now.

I've added a failing test, I'm investigating the fix now, but it's 100% a problem with that test, seeing locally:
$ go test ./internal/rbd
--- FAIL: TestValidateImageFeatures (0.00s)
    rbd_util_test.go:134:
                Error Trace:    rbd_util_test.go:134
                Error:          Expected nil, but got: &errors.errorString{s:"invalid feature "}
                Test:           TestValidateImageFeatures
FAIL
FAIL    github.com/ceph/ceph-csi/internal/rbd   0.048s
FAIL

OK, so it seems like an empty string being split will result in at least one item:
package main

import (
	"fmt"
	"strings"
)

func main() {
	arr := strings.Split("", ",")
	for x, _ := range arr {
		fmt.Print(x)
	}
}

This is ready and good to go, I believe it should be a quite high priority fix as it's a regression.

Thanks for the PR! Please note that we expect commit messages to have a prefix of the affected component. In this case, you can add rbd:  as a prefix. Please update the commit messages and force-push the updated commits to your fork+branch again.
More details about this can be found in the development guide.

Thanks for the reviews.  I've made the required modifications..

/retest ci/centos/mini-e2e-helm/k8s-1.19

/retest ci/centos/mini-e2e-helm/k8s-1.19

/retest ci/centos/mini-e2e-helm/k8s-1.19

/retest ci/centos/k8s-e2e-external-storage/1.20

/retest all

@mergifyio rebase

@mnaser , did u have any reason for adding trimspace function strings.TrimSpace(imageFeatures)?
Just spaces like imageFeatures: "    " config should also be treated as invalid.
While upgrading, it should not exist and map[string]string should just return empty strings.
This would present an edge case wherein a user can pass just  imageFeatures: "    "  and will not trigger error with #2139 .
If there is no reason for having TrimSpace, I'll remove it.
Thanks
cc @nixpanic @humblec @Madhu-1

Hello,
when will be this fix released? We did an upgrade of rook today and we weren't unable to use csi 3.3.1 because of this bug. We had to rollback to 3.2.2 to have data available again.

Hello,
when will be this fix released? We did an upgrade of rook today and we weren't unable to use csi 3.3.1 because of this bug. We had to rollback to 3.2.2 to have data available again.

This fix is not available in v3.3.1 but is available in v3.4.0
https://github.com/ceph/ceph-csi/compare/v3.3.1...release-v3.3
Should we do a v3.3.2 release ?@Madhu-1 @nixpanic @humblec PTAL

As fix is available in 3.4.0 You can use 3.4.0 in any version of Rook. and 3.4.0 is the default in 1.7.1 of Rook.


Movie App Link

In the previous section, when we were updating the views and layout, there was a line in the tutorial that said that the Movie App link was not yet functional. However, in this part in the Test the App section, when I click on the Movie App link, I get an error that there is no page found. Am I missing the part where we make that link functional, or is that part of registering the database that I am doing incorrectly, or is that part skipped in the tutorial?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 1d975a83-1550-b284-d0d8-7fe2ea206ff5
Version Independent ID: 48e81b42-7c2b-afbf-71e6-d4f442a4bd1f
Content: Add a model to an ASP.NET Core MVC app
Content Source: aspnetcore/tutorials/first-mvc-app/adding-model.md
Product: aspnet-core
Technology: aspnetcore-tutorials
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

keep going


How to connect with Quantum Processor?

Is there any detailed description about how to connect with Quantum Processor? I'm certain that I have run the 'pyquil-config-setup'. Does it mean that my account doesn't have the Privilege to access the QPU?
I run:
import pyquil.api as forest
q = forest.QPUConnection()
but I got :
! ERROR:
!   There was an issue validating your forest account.
!    The server came back with the following information:
{"status": "Error: user does not have access to QPU"}
! If you suspect this to be a bug in pyQuil or Rigetti Forest,
! then please describe the problem in a GitHub issue at:
!
!      https://github.com/rigetticomputing/pyquil/issues

In slack, the stuff told me that the public can't access the GPU for now. We have to wait for update.


Determine whether we want to warn users about not awaiting asynchronous code paths

With an async execute method we need to determine how we want to handle non-awaited code within the execute method.  Do we warn?  Do we not? etc.
Ex:
{code}
public override async Task Execute()
{
// Warning because it's not awaited.
SomethingAsync();
}
{code}
| 147 | 10305 | Reported By: N. Taylor Mullen |

This was fixed by https://github.com/aspnet/Razor/commit/32f6f4df009efeefca4f2ac720efffcc3b5bacfd and is a duplicate of https://github.com/aspnet/Razor/issues/28


Proposal and planning for API framework

Introduction
api framework, or http web framework, is a long standing engineering backlog across caicloud teams. The proposal aims to shed some light on how we want to move forward. This is by no means a thorough design, we hope to gather enough feedback to get going. Feel free to comment.
Background
No guideline is provided at this moment to start up a new apiserver from scratch, results in a divergent approaches of setting up new web projects. No conventions enforced at framework level also results in bugs due to breaking apis, validation errors, etc. On the other hand, engineering effort is wasted on solving the same range of problems which should ideally be solved in an API framework.
Goal

Reduce api level errors and inconsistency
Improve engineering productivity via removing repeated work, adding code generation, etc
Adding new resource type should only require defining struct definition
Adding validation should only require declaring validation method as part of struct definition
Consistent behavior, structure and layout across all golang server projects
Out-of-box server instrumentation, e.g. metrics, tracing, profiling, etc

Proposal
Survey
Below is a short survey on existing projects:

kubernetes-admin style (go-restful), for example, app-admin

routing wrapper around go-restful
a well-defined layout
count for 70% of all related projects

loadbalancer-admin style (gin), for example, loadbalancer-admin

use gin directly
no well-defined project layout
count for 20% of all related projects

liubo style (go-restful), for example, cauth

mirrors closely with kubernetes style
count for 10% of all related projects

Requirements
Following is all the required functionalities for our framework.
Routing, Request & Response

Routes mapping from request to function

support for path parameter (e.g. /api/v1/animals/{id})
support for query parameter (e.g. /api/v1/animals?type=dog)
support regex

Grouping Routes

routes can be grouped for better arragement, but doesn't have to be first class concept

Request/Response API object

to/from structs in json
easy access to path,query,header parameters

Middleware support

general middleware support is required for developer to add custom middleware
required default middleware: request logging, recovery, tracing

Contextual process chain and parameter injection

all handlers accepts a context value representing a request context
requset parameters can be validated and injected into handler, see below

API error convention

define canonical error code and type based on api convention

multipart/urlencoded form support (low priority)
file upload support (low priority)
grpc support (low priority)

Instrumentation

Provide default metrics at well-known endpoints for prometheus to scrape

need to define set of default metrics

Tracing should be provided by default to allow better troubleshooting

follow opentracing, which is industry standard
use jaeger as tracing system

Profiling can be enabled in debug mode for troubleshooting

use go profile

Validation

Provide default validation on api types with json, e.g. required, within a range, etc
Support custom validations defined by developers on api types
support validation on all parameters (path, query, etc)

Usability

A working project should be brought up with few lines using the framework
Framework must  follow engineering conventions to help developers focus on business logic
OpenAPI (swagger 2.0) specification can be generated automatically with no extra work
Provides a well-established layout conforming to golang project layout
Easy and standard configuration
A reasonable support for websocket

Performance

Performance is not a hard requirement for initial stage; but it should not introduce observable latency

None-requirements
A list of functionalities commonly seen in other frameworks that are not in our scope

https support. While it's not hard to serve https in go, https is out of scope since all services are expected to be running behind API gateway
html rendering, orm, etc. Let's stick it to a simple restful framework
testing. testing should be a different library

Design and Implementation
Project Timeline

[x] Due 09.15: launch the project (@ddysher)
[x] Due 09.23: draft feature set (@ddysher)
[x] Due 09.29: finalize feature set and roadmap (@ddysher)
[ ] Due 12.01: check in most features (framework, cli, validation, metrics)
[ ] Due 12.20: check in all features, with reasonable test coverage (openapi, tracing)
[ ] Due 12.31: documentation, examples, website should be ready

Feature Design and Planning
Following is a list of planned features, their respective design and planning.

Basic framework
API Validation
Configuration Management
OpenAPI Generation
Instrumentation and Profiling
Tracing

Meetings
Regular meetings will be held to discuss above topics.

1st meeting
2nd meeting
3rd meeting
4th meeting
5th meeting

Assignees

Project tracking and proposal maintenance (@ddysher)
Overall structure, project layout, etc (@ddysher)
Routing, multiplexing, middleware, API error package, etc (@kdada)
Configuration management (@zuomo)
API validation (@walktall)
OpenAPI generation (@liubog2008 @Jimexist )
Prometheus instrumentation (@caitong93)
tracing (@yejiayu)

References

go-restful
gin
chi
validator
code-generator
prometheus
jaeger

@caicloud/review-framework I've updated our timeline, PTAL.

Done 🚀
I'll create a doc to archive the issue.


add authorized ip range variable for azure

Reference Issues or PRs
Closes #2784

What does this implement/fix?
Put a x in the boxes that apply

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds a feature)
[ ] Breaking change (fix or feature that would cause existing features not to work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] Other (please describe):

Testing

[X] Did you test the pull request locally?
[ ] Did you add new tests?

How to test this PR?
Ensure you can deploy to azure with an existing azure config.
Then
Add a authorized_ip_ranges line to the azure provider of your nebari-config.yaml. Deploy to azure and ensure that access to api server is limited to that ip range.
example config block
azure:
  authorized_ip_ranges: ["<IP_ADDRESS>/32"]  # make this your own ip address
  kubernetes_version: 1.29.2
  region: eastus
  storage_account_postfix: esrr
  node_groups:
    general:
      instance: Standard_D8_v3
      min_nodes: 1
      max_nodes: 1
    user:
      instance: Standard_D4_v3
      min_nodes: 0
      max_nodes: 5
    worker:
      instance: Standard_D4_v3
      min_nodes: 0
      max_nodes: 5

Any other comments?

The failing tests appear unrelated to these changes.

Hi @dcmcand, I am not sure if this will be related at all, but last time we changed something related to IP ranges (specifically for AWS CIDRs blocks) we ended up having issues with Dask (here's some of the discussion points https://github.com/nebari-dev/nebari/issues/828)
So I would just suggest to do a full Azure deploy with these settings and double check if dask can spin correctly.

@viniciusdc tested and dask works fine. Now that 2024.12.1 is out, could I get a review here?


[Bug]: Leaderboard Title & Search Bar Hidden in Desktop View

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug

The Leaderboard title and Search bar are obscured by the navigation bar due to margin issues.
As a result, the Search bar is not visible, preventing users from typing in their search queries, which negatively impacts user experience.

Page Link 👁👁 : https://git-re.vercel.app/leaderboard
Expected behavior

The Leaderboard title and Search bar should be fully visible and not covered by the navigation bar.

Add ScreenShots

On which device are you experiencing this bug?
Windows
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

Thank you for creating this issue! 🎉 We'll look into it as soon as possible. In the meantime, please make sure to provide all the necessary details and context. If you have any questions or additional information, feel free to add them here. Your contributions are highly appreciated! 😊
You can also check our CONTRIBUTING.md for guidelines on contributing to this project.

This issue has been automatically closed because it has been inactive for more than 30 days. If you believe this is still relevant, feel free to reopen it or create a new one. Thank you!

Hello @ChandanKhamitkar! Your issue #451 has been closed. Thank you for your contribution!


fix: The RotateTool does not work on mobile devices.

Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Bug fix: The RotateTool does not work on mobile devices.

What is the current behavior? (You can also link to an open issue here)
The RotateTool does not work on mobile devices.  It will throw an error: "Uncaught TypeError: Cannot read property 'client' of undefined". And viewport.initialRotation is undefined.

What is the new behavior (if this is a feature change)?
The RotateTool works fine on mobile devices.

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Other information:
I modified function defaultStrategy(evt) in RotateTool.js.

Hi @KirisakiAria, i think this tool should have this event handler
postTouchStartCallback(evt) {     this.initialRotation = evt.detail.viewport.rotation;  }


textfaity build on Android Studio in Windows 10

Hello,
Here newbie with Android Studio programming I'm trying to build textfairy for a school project could anyone help me out pointing to resources who could help? Congrats on the great App I find it is amazing work.
Thank you,
G

Hi, unfortunately I don't own a windows pc but it should just work, try building from command line first.
/gradlew app:assemblePlaystoreRelease


Add mkdtemp

Still needs a CHANGELOG entry.

Gentle ping on the author @DBLouis, I am sorry about the late response, would you like to finish this PR, just need to rebase your branch, discard the changes made to the CHANGELOG.md file and add a new file under the changelog directory, then we can merge it:)

file name would be 1297.added.md

 Added `mkdtemp` wrapper

I noticed that the new mkdtemp is behind the feature feature. Is that indended? That feature already existed so seems like it may have been deliberate, but I also can't see what it's intended to mean.
I'm a rust noob, in case that helps contextualise the question.


Bump adm-zip and eslint dependencies

Bump adm-zip from 0.4.13 to 0.4.16
Bump eslint from 6.5.0 to 7.13.0

Thanks for keeping things up to date! 👍


Handling encoding of URL's.

This problem arises when the URL is non-ascii. We can either store the URL's encoding but this introduces performance deterioration. Another option is to convert the URL's to an ascii representation such as - safe_url_string which is also used by scrapy, however this function also affects performance.

It would be good to improve performance on that safe_url_string and use it on Request instantiation, probably.


Text align

This is based on #1026, which should be merged first.

Codecov Report

Merging #1027 into develop will decrease coverage by 0.23%.
The diff coverage is 27.45%.

@@             Coverage Diff             @@
##           develop    #1027      +/-   ##
===========================================
- Coverage    63.98%   63.75%   -0.24%
===========================================
  Files          317      321       +4
  Lines        11687    11752      +65
===========================================
+ Hits          7478     7492      +14
- Misses        4209     4260      +51

Impacted Files
Coverage Δ

model/TextNode.js
100% <ø> (ø)
:arrow_up:

packages/body-scroll-pane/BodyScrollPanePackage.js
100% <ø> (ø)
:arrow_up:

packages/prose-editor/ProseEditorPackage.js
100% <ø> (ø)
:arrow_up:

packages/prose-editor/ProseEditor.js
0% <ø> (ø)

packages/switch-text-type/SwitchTextTypePackage.js
100% <ø> (ø)
:arrow_up:

packages/text-align/TextAlignCommand.js
0% <0%> (ø)

packages/text-align/TextAlignPackage.js
0% <0%> (ø)

ui/Configurator.js
66.22% <0%> (ø)
:arrow_up:

dom/BrowserDOMElement.js
87.61% <100%> (+0.11%)
:arrow_up:

packages/paragraph/ParagraphHTMLConverter.js
80% <66.66%> (-20%)
:arrow_down:

... and 7 more

Continue to review full report at Codecov.

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


OP pulls towards curb due to improper curb detection

Driving in curb lane which doesnt have a solid lane line on curb edge. left lane line is also pretty bleak.  I believe I was driving along a section where there was no raised curb, which OP probably thought the lane widened and pulled towards right. Had to counter steering
Expected behavior
Car shouldn't have pulled towards curb
Device: FreEon
Dongle ID: 59f457ce47259dd2
Route: 59f457ce47259dd2|2021-04-15--03-04-41--4
Timestamp: 20:09:01
Version: 0.8.3 (release 2)
Car make/model: Toyota Sienna 2018
Additional context
gif of the report
https://imgur.com/a/qPVDeUm

This is a pretty weird one, I will have to investigate

Russia - Moscow, similar behavior. Often sees the middle of the curb as a strip. of 0.8.3 the situation is the same.

I have that problem too. If i remember correctly it works better when you turn on laneless.

All the time on this street in Phoenix, AZ, USA ⬇. I have to pull the wheel to the left else it just drifts closer and closer 😱

I can get some routes/segments if useful?

We are only really actively working on improving laneless performance at this point.


Unable to overwrite remote button

Hi,
I'd like to overwrite the remote "i" button to "Home" but doesn't seem to work. My configuration looks like the following:
"remote": [
{
"command": "Home",
"target": "INFORMATION"
}
]

v5.0.2 should fix this issue


Bug: Deleting an image from the image gallery only deletes the parents from the DB. It does not delete the children.

When an image is deleted, the parent image is deleted from the database, but not the children. The children still show up in the KeystoneJS Admin back end.

Clarity: This issue is separate from Issue #4. Issue 4 deals with removal of the file from the server. This issue is dealing with re-sized images orphaned in the database.

Completed and closed.


Add IIFE and Remove Anonymous Functions

Hey, I have created a branch and would like to submit a pull request.

added IIFE around module / directive
removed anonymous function for ngGallery
added $inject for dependency injection

( function () {
	'use strict';
	angular.module(  'jkuri.gallery', []  ).directive(  'ngGallery', ngGallery  );

	ngGallery.$inject = [ '$document', '$timeout', '$q', '$templateCache' ];

	function ngGallery(  $document, $timeout, $q, $templateCache  ) {
        /** CODE OMIT **/
        }
} )();

#11


[REQUEST] Vite module to load narrat scripts with hot code swapping

Is your feature request related to a problem? Please describe.
It would be really useful to be able to use Vite hot code reloading with narrat.
By doing this, we could allow people to develop their game and change code while playing without having to restart the whole game to see changes to labels (very useful when needing to test something in a specific test, or when finding a bug in the middle of a complex playthrough with a lot of state that takes time to reach).
Describe the solution you'd like
This would involve a few changes:

We'd need some sort of Vite plugin to load .nar files
Said .nar files would need to be imported in index.ts instead of being loaded by the game from a list of scripts in the config

Once this is working, reloading a .nar file could simply override the content of all the labels included in said file, which would mean that the next time the game jumps to one of those new labels, the new code is loaded.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Closed by #86


⚠ Samsung has degraded performance

In f4a0b34, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 1753 ms

Resolved: Samsung performance has improved in c006fc4.


Add e-waste emissions of EVs

This issue can be closed when a new entry is added to the table Waste produced accounting for the e-waste emissions of the technology ELCVCL (EVs).

Several FCEV designs count with battery packages as well.
These information should be included in the table.
A new entry should be added to the same table accounting for the e-waste emissions of the technology H2VCL (FCEVs).

Closed by #122


[BUG] Wrong NetworkPolicy labels

The instance-manager NetworkPolicy tries to select pods with longhorn.io/component: instance-manager:
https://github.com/longhorn/longhorn/blob/091256437632f5a0532eafef6462d26381cd2807/chart/templates/network-policies/instance-manager-networking.yaml#L8-L10
But the DaemonSet applies only app: longhorn-manager label:
https://github.com/longhorn/longhorn/blob/7e5b8047ed4acbd8c05264da6a721b4543f539de/chart/templates/daemonset-sa.yaml#L13-L15
In general, the longhorn.io/component label seems to be used only in the network policies, which should all be verified.
Another problem I noticed is that this ports: section should be obviously after the following {{- end }} tag (it does not make sense to gate it by the condition):
https://github.com/longhorn/longhorn/blob/091256437632f5a0532eafef6462d26381cd2807/chart/templates/network-policies/ui-frontend-network-policy.yaml#L40-L45
Btw. why are the network policies duplicated in the examples directory?

Thanks for the report @lahwaacz. I am looking at it.

The instance-manager NetworkPolicy tries to select pods with longhorn.io/component: instance-manager:
But the DaemonSet applies only app: longhorn-manager label:

Is this one causing you problems in practice? The policy is meant to target instance-manager pods. These pods are deployed by the Longhorn system after installation, and their manifests do not appear in the Helm chart by design.

https://github.com/longhorn/longhorn-manager/blob/62cd59c13f793147a33e72fb25f58458cfed785b/controller/instance_manager_controller.go#L1132
https://github.com/longhorn/longhorn-manager/blob/62cd59c13f793147a33e72fb25f58458cfed785b/types/types.go#L317
https://github.com/longhorn/longhorn-manager/blob/62cd59c13f793147a33e72fb25f58458cfed785b/types/types.go#L287
https://github.com/longhorn/longhorn-manager/blob/62cd59c13f793147a33e72fb25f58458cfed785b/types/types.go#L279

eweber@laptop:~/longhorn> kl get pod -oyaml instance-manager-6f29b4b11e7b25924b3046d7da054dbd | grep labels -A 6
  labels:
    longhorn.io/component: instance-manager
    longhorn.io/data-engine: v1
    longhorn.io/instance-manager-image: imi-0b5e7e43
    longhorn.io/instance-manager-type: aio
    longhorn.io/managed-by: longhorn-manager
    longhorn.io/node: eweber-v126-worker-9c1451b4-6464j

Oops, I've confused instance-manager with longhorn-manager...
Can you comment on the other issue with ports and examples?

Can you comment on the other issue with ports and examples?

I think you are right about the ports issue. Doing some testing to verify.
I'm not super familiar with the UI network policy. It's only applicable when using an ingress. It looks like the RKE and RKE2 policies would still work without the ports, but just be a bit more open. I'm bringing up an RKE2 cluster and verifying the UI is still accessible if ports are applied to it.

While we are here, I think we should also remove port 80 from the policy. It is the port for the service, but that shouldn't come into play where network policies are concerned. I have tested k3s without it and seen no issues.
https://github.com/longhorn/longhorn/blob/6c53cdcf058f4d8c9eabb2e2948982682c12bad6/chart/templates/network-policies/ui-frontend-network-policy.yaml#L43-L44

Hmm, most other policies don't specify any port numbers for ingress...
recovery-backend-network-policy.yaml and webhook-network-policy.yaml specify ports, but not namespaceSelector or podSelector. Are they supposed to receive traffic from outside Longhorn components?

I'm also seeing some traffic from longhorn-manager to instance-manager on dest port 8503 which is not specified in https://longhorn.io/docs/1.6.2/references/networking/

Hmm, most other policies don't specify any port numbers for ingress...
recovery-backend-network-policy.yaml and webhook-network-policy.yaml specify ports, but not namespaceSelector or podSelector. Are they supposed to receive traffic from outside Longhorn components?

I think yes:

The recovery backend receives traffic mostly from NFS clients running directly on nodes. I think it would break if we tried to specify some set of pods to communicate with it.
The webhook receives traffic mostly (or entirely) from the Kubernetes API server. While we can generally guess the source of this traffic (e.g. kube-system), not all distros (e.g. k3s) even run the API server as a pod. I think the user should deploy custom policies or wrap the Longhorn chart if they want finer detail, since it will depend on their environment.

I'm also seeing some traffic from longhorn-manager to instance-manager on dest port 8503 which is not specified in https://longhorn.io/docs/1.6.2/references/networking/

Good point. Looks like those docs weren't updated with https://github.com/longhorn/longhorn-instance-manager/pull/218 and other SPDK related features. Would you be willing to open a separate docs ticket for it?

I prepared the following branch that has the changes I think make sense @lahwaacz, but I'd rather you get the contribution credit if you're interested. If so, please submit a similar PR.
https://github.com/longhorn/longhorn/compare/master...ejweber:9067-ui-network-policy

Test plan
Repeat the following steps in both a k3s and rke2 cluster. There should not be a behavioral change, but the cluster is now more secure.

Set networkPolicies.enabled == true, networkPolicies.type == <appropriate>, ingress.enabled == true in the chart.
Upgrade Longhorn.
Access the Longhorn UI using the ingress info returned by kubectl get -n longhorn-system ingress.
Verify the UI generally works.

Hmm, most other policies don't specify any port numbers for ingress...
recovery-backend-network-policy.yaml and webhook-network-policy.yaml specify ports, but not namespaceSelector or podSelector. Are they supposed to receive traffic from outside Longhorn components?

I think yes:

The recovery backend receives traffic mostly from NFS clients running directly on nodes. It would break if we tried to specify some set of pods to communicate with it.
The webhook receives traffic mostly (or entirely) from the Kubernetes API server. While we can generally guess the source of this traffic (e.g. kube-system), not all distros (e.g. k3s) even run the API server as a pod. I think the user should deploy custom policies or wrap the Longhorn chart if they want finer detail, since it will depend on their environment.

Note that traffic to and from the node where a Pod is running is always allowed, regardless of the IP address of the Pod or the node.
As for the communication with Kubernetes API, the same page says "Reply traffic for those allowed connections will also be implicitly allowed." I don't think the API initiates any connections, so there should be no need to cover this in the policy.

Note that traffic to and from the node where a Pod is running is always allowed, regardless of the IP address of the Pod or the node.

The recover backend traffic comes from all nodes in the cluster that mount a RWX volume.

As for the communication with Kubernetes API, the same page says "Reply traffic for those allowed connections will also be implicitly allowed." I don't think the API initiates any connections, so there should be no need to cover this in the policy.

The API server initiates connections to webhooks as configured in a MutatingWebhookConfiguration or ValidatingWebhookConfiguration, which Longhorn uses. It is how the API server decides whether to allow updates to custom resources.

Oh, I see. Then the chart should have a configurable list of CIDRs to explicitly allow traffic to the webhooks. It would be easier to describe this with a Cilium entities-based policy, though.

I prepared the following branch that has the changes I think make sense @lahwaacz, but I'd rather you get the contribution credit if you're interested. If so, please submit a similar PR.

Alright, I've opened https://github.com/longhorn/longhorn/pull/9077

I also just stumbled over this potential vulnerability in the handling of Network Policies, particularly in the UI. When a user enables Network Policies (networkPolicies.enabled = true), the reasonable expectation is that all endpoints would be restricted by default, allowing only necessary connections. Any additional access, like to the UI, should require explicit user configuration. This is especially critical since the UI offers passwordless access (AFAIK there is no native authentication implemented) with elevated permissions.
The ui-frontend-network-policy template configures a Network Policy only for specific ingress controllers used in three Kubernetes distributions (rke1 -> ingress-nginx, rke2 -> rke2-ingress-nginx, and k3s -> traefik). This policy is applied only if, additionally to networkPolicies.enabled = true, both ingress.enabled = true (default is false) and networkPolicies.type is set to anything non-empty (default is k3s). If these conditions are not met, every pod in the cluster and external sources with direct IP connectivity can access the admin UI unrestricted. This setup leaves a substantial security gap, potentially unknown to users who expect secure defaults once Network Policies are enabled.
https://github.com/longhorn/longhorn/blob/cb9eaddb95eb5889f7320cc268c94c8e54d58fb2/chart/templates/network-policies/ui-frontend-network-policy.yaml#L1
I don't see this issue addressed in #9077. If this is not covered, I propose either adjusting the configuration to enforce a default policy that restricts access to the UI independently of ingress.enabled and networkPolicies.type, or having a default ingress policy  (that only depends on networkPolicies.enabled = true) for all pods in the Longhorn namespace like this:
{{- if .Values.networkPolicies.enabled }}
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: longhorn-default
  namespace: {{ include "release_namespace" . }}
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress: []
{{- end }}


Cannot read property 'messages' of undefined

While using xo in atom I added !test/helpers/.setup.js to my ignores array in package.json and all I get is this error. The weirdest bit if the error still happens even if the file is empty.
linter-registry.js [sm]:125 [Linter] Error running XO TypeError: Cannot read property 'messages' of undefined
    at /Users/xo/.atom/packages/linter-xo/lib/format.js:17:19

xo works fine when using it in the cli though; xo test/helpers/.setup.js --ignore-pattern '!test/helpers/.setup.js'.

Can you open this on https://github.com/sindresorhus/atom-linter-xo instead if it's still an issue with the latest version of linter-xo.


Support reason-react

After trying out to interop reasonml bindings for react, reason-react @chenglou found out that eslint was causing this practicular problem.
It is fixed in the newer version of<EMAIL_ADDRESS>this will allow to interop components in reason and plain js.
I have this repo that displays the error found out when running it (in one session yarn start,  in another yarn bsb-watch), and a branch fixing the problem by upgrading the dependency.
I'm sure this will be helpful for a lot of people looking to chime into the future of react.
Thanks!

Hello! I'm a bot that helps facilitate testing pull requests.
Your pull request (commit 07b773f362248f9e235cb0f2aff429b52d634ef8) has been released on npm for testing purposes.
npm i<EMAIL_ADDRESS># or
yarn add<EMAIL_ADDRESS># or
create-react-app<EMAIL_ADDRESS>folder/

Note that the package has not been reviewed or vetted by the maintainers. Only install it at your own risk!
Thanks for your contribution!

Thanks for this PR! I just looked at the releases and it still seems like they're working out some kinks with the 7.3.0 release so maybe we can wait for 7.4.0? It looks to be released soon -- I just see "fixes" in the first 7.4.0 beta and no 7.3.1 release so I don't want to upgrade to something with potential bugs.
Feel free to use the release @react-scripts-dangerous cut temporarily so you don't need to eject. 😄

Hey @Timer, 7.4.0 has been (released)[https://github.com/yannickcr/eslint-plugin-react/releases/tag/v7.4.0], i've updated it, by the way, thanks for all your work in cra :)

Hello! I'm a bot that helps facilitate testing pull requests.
Your pull request (commit d346804e627dc33112bbec4bebb5cd4f7c61b762) has been released on npm for testing purposes.
npm i<EMAIL_ADDRESS># or
yarn add<EMAIL_ADDRESS># or
create-react-app<EMAIL_ADDRESS>folder/

Note that the package has not been reviewed or vetted by the maintainers. Only install it at your own risk!
Thanks for your contribution!

I feel comfortable with this now, thanks a lot!

Thank you!

Should be fixed in<EMAIL_ADDRESS>https://github.com/facebookincubator/create-react-app/releases/tag/v1.0.15

Thanks a lot!


Adding Laravel-Zero

Adding laravel-zero, a micro-framework for console application written in Laravel.
Github:

https://github.com/laravel-zero/laravel-zero
https://github.com/laravel-zero/framework

Docs: https://laravel-zero.com/docs/introduction/
Packagist: https://packagist.org/packages/laravel-zero/laravel-zero

Can you please re-order alphabetically? Ignore the Expressive library which I'll re-order in a separate PR.

@jadb Ok, thanks! Done!

Thanks! 👍

@jadb You're welcome!


proposal: Go 2: expression scoped variables

I propose to extend the expression syntax to allow to declare variables scoped to a sub-expression.
Rationale
Go already allows to declare variables scoped to some statements:
if _, err := check(); err != nil {
    ....
}

switch l := len(x); l {
case 0:
case 1:
default:
}

I propose to allow to define variables scoped to an expression by allowing the same syntax as if/switch in any non-constant expression.
Here is the grammar:
VarDeclExpr = "(" ShortVarDecl ";" Expression ")" .

( v1, v2 := e1, e2 ; expr ) would become a shorter alternative to:
(func() T {
    v1, v2 := e1, e2
    return expr
}())

e1 and e2 are evaluated first. expr can reference variables v1, v2. v1, v2 are not accessible outside expr.
Examples:
ptrTo3 := ( x := 3; &x )
ptrToNow := (now := time.Now(); &now)
squareF := ( x := F(); x*x )
ok := (_, err := f.Write(); err != nil)
fmt.Printf("%T %s\n", V, (b, _ := json.Marshal(V); b))

Note: if and switch allow SimpleStmt (which is more than just ShortVarDecl) as the first part. I think that inside an expression context only the ShortVarDecl is relevant.  However this syntax could be extended later.
Would you consider yourself a novice, intermediate, or experienced Go programmer?
Experienced.
What other languages do you have experience with?
C, Perl, JavaScript, SQL, shell, Rebol, Caml, Prolog, Pascal, x86 assembly...
Would this change make Go easier or harder to learn, and why?
Neither. This change generalizes existing syntax by reusing constructions which were so far limited to specific contexts.
Has this idea, or one like it, been proposed before?
AFAIK, no.
However this provides a more generic alternative to proposals #45624 (expression to create pointer to simple types) and #45653 (allow taking address of value returned by function):
ptrTo3 := (x := 3; &x)
ptrToNow := (now := time.Now(); &now)

Who does this proposal help, and why?
People annoyed by the difficulty of allocating pointers to simple values.
People annoyed by the difficulty of calling a function that returns multiple values in a context where a single value is wanted.
What is the proposed change?
See above.
Is this change backward compatible?
Yes.
Show example code before and after the change.
See above.
What is the cost of this proposal? (Every language change has a cost).
Fairly small compiler update compared to some others underway. Will need to touch documentation, spec, perhaps some examples.
Can you describe a possible implementation?
As this is syntaxic sugar, it might be implemented by the compiler as an AST rewrite:
( v1, v2 := e1, e2 ; expr ) ->
(func() T {
    v1, v2 := e1, e2
    return expr
}())

How would the language spec change?
The definition of Expression would be extended:
PrimaryExpr =
	Operand |
	Conversion |
	MethodExpr |
	PrimaryExpr Selector |
	PrimaryExpr Index |
	PrimaryExpr Slice |
	PrimaryExpr TypeAssertion |
	PrimaryExpr Arguments  |
	VarDeclExpr .                       // <----
VarDeclExpr = "(" ShortVarDecl ";" Expression ")" .

Orthogonality: how does this change interact or overlap with existing features?
As this reuses syntax known to every Go programmer, orthogonality is improved.
Is the goal of this change a performance improvement?
No.
Does this affect error handling?
This could allow to drop values in expressions that return multiple values. This is useful when passing values to functions and either the value or the error is wanted.
justError := (_, err := strconv.ParseInt(s); err)
justValue := (n, _ := strconv.ParseInt(s); n)

fmt.Printf("%T %s\n", V, (b, _ := json.Marshal(V); b))

Is this about generics?
No.

That was just an example.

Well, examples usually tend to help you explain why someone needs this. Basically, what you calling "annoyance" can be called as "clarity" by other people.
Pointer to value and pointer to function result addressed in other issues. In these cases it is something that already exists. Even grammar changes aren't required.
Other ones become unreadable really fast when you start to use parts of real-word code instead of single-characted method names. Especially when used in function calls. Or used rarely in something you might encounter or write.

what about something like this:
jsonStr, err := (b, err := json.MarshalIdent(someObj, "", "  "); string(b), err)

Does this proposal accept multiple return values as var expressions?

I believe this proposal is just a variant of lambda expression (Python / Kotlin) / closure (Rust), and it has been discussed in a separate issue #21498.

@ycalansy No, this proposal isn't about lambda expression. Lambda expression are used to define function. Here, this is about expression to evaluate immediately.

@quenbyako

Does this proposal accept multiple return values as var expressions?

No. I only considered single expressions (called (PrimaryExpr)(https://golang.org/ref/spec#PrimaryExpr) in the Go specification). Because list of expressions (ExpressionList) are not expressions (Expression). For example, you can't wrap a list of expressions in parentheses in the current Go specification.
List of expressions are mostly used in statements (Assignment, VarDecl, ShortVarDecl) and I think that expression-scoped variable bring low value in such context as a separate statement is more readable. Expression-scoped variable are useful when the statement that includes the expression spans multiple lines.

In the proposal I suggested PrimaryExpr as the extension point for the grammar, but Operand is a better place as this is where expressions wrapped in parentheses are defined:
Operand     = Literal | OperandName | "(" Expression ")"  | VarDeclExpr .
VarDeclExpr = "(" ShortVarDecl ";" Expression ")" .

@dolmen Imagine if you have lambda expression in Go, you can simply achieve what you want in this proposal by writing the following code:
Your proposal:
squareF := ( x := F(); x*x )

Rust:
fn main() {
    let nine = (|x: i8| x * x)(do_something());
    println!("{}", nine);
}

fn do_something() -> i8 {
    3
}

Python:
def do_something():
   return 3

nine = (lambda x: x * x)(do_something())
print(nine)

However, I am not a big fan of this kind of syntax because it reduces the readability of the code.

@ycalansy I know what are lambda expressions. And this proposal is NOT about lambda expressions. In fact, I'm against lambda expression (#21498) without the func keyword as they hide function definitions. I like the explicit func keyword used to define function as this is explicit. And I know that lambda expressions will be abused. To keep Go simple to read we must avoid to have 2 syntaxes for the same meaning that allow different writing styles.
But I too often write short lived functions (often closures) just to workaround shortcomings in Go syntax. I call a function short lived if it is defined and immediately executed in the same statement (function declaration followed by a list of arguments).
Here are some use cases of short lived functions:

variable scoping (when I need stricter scope that the englobing function)
defer scoping (when I need stricter scope that the englobing function)
complex expressions which need to save intermediate results for reuse (this proposal is for this use case)

I think that the func keyword is pollution for short lived functions and that syntax would be helpful to remove func from those expressions.
This proposal is about adding syntax for the last case and so remove one misleading use of the func keyword.

I've ran a few times into a situation where a SimpleStmt couldn't have been used, so I needed to nest the code in an outer if, which made the code a bit uglier (IMO). E.g.:
if x != nil {
	if _, ok := x.Foo(); ok {
		// …
	}
}

Under this proposal I could use:
if x != nil && (_, ok := x.Foo(); ok) {
	// …
}

Other times I needed to use the value omitted in the previous snipped:
if x != nil && (v, ok := x.Foo(); ok) {
	v.Bar()
	// …
}

which wouldn't be possible under this proposal:

I propose to allow to define variables scoped to an expression […]

So a question is, whether it needs to be scoped to that expression.

An argument against this proposal is that it introduces yet another way how to achieve the same thing, which is generally a bad thing. In order to return just a single value from a call to a function returning more than one value the idiom is to write something like:
func _() error {
	// …
	_, err := q.Exec()
	return err
}

Now an alternative idiom would be a possibility:
func _() error {
	// …
	return (_, err := q.Exec(); err)
}

for people who find it tempting to reduce the number of lines. Surely one might find many other examples where this proposal makes the language more complex than it needs to be.
I can't decide whether I'd be for or against this proposal.

@mibk well, this example

if x != nil {
	if _, ok := x.Foo(); ok {
		// …
	}
}

could be written as
if _, ok := x.Foo(); ok && x != nil {
    // …
}

So it's not required to accept this proposal for if cases, BUT in this situation

func _() error {
	// …
	_, err := q.Exec()
	return err
}

this feature could be useful.
Main problem is that go is not so expressive as other languages, so i think this is why this proposal exist. But honestly, for last example its way more useful to use if-style in return like return _, err := q.Exec(); err, which is, well, more obvious and it looks more go-way imho

btw, good point, i didn't even think about that.

If I understand it correctly, it can be implemented as a function literal that always inline, except handling with returns and defers.
Interestingly, It reminds me deeply as common lisp's progn macro. This would have effects on how some tools, especially pre-processors that trying to add (lisp style) macros to Go (and code generation as general), as it promised a way to group multiple statements together without introducing an intermediate function and still provides a "returning" value to it.
I don't know how much of this point this proposal concerned with, but I am very interested in it.

Note that this would permit considerable complexity in expressions.
var a int
a = (a := (a := a; a + 1); a + 1))

I think that would set a to 2.
It's true that we have this feature in if and switch statements, but they are syntactically limited there: you can't have a recursive short variable declaration, as this new feature would permit.

It's true that we have this feature in if and switch statements, but they are syntactically limited there: you can't have a recursive short variable declaration, as this new feature would permit.

Well, such obfuscation is already available:
var a int
a = func() int { a := func() int { a := a; return a + 1 }(); return a + 1 }()

Go playground

True, there are many ways to complicate code.  Still, that doesn't really seem comparable to me.

Looks really unreadable to me. For no obvious advantage.

Go is not a language that places a high value on terseness.  It prefers clarity.
One of the primary goals mentioned above (allocation of pointers) can be addressed through helper functions.
Having a shorter notation for function literals may help some of these cases; see #21498.
Based on the discussion above, and the emoji voting, this is a likely decline.  Leaving open for four weeks for final comments.