unmarshal null wrapper types to nil instead of empty values

Unmarshaling now follows proto3 spec, turning JSON null into Go nil for wrapper types. Without this fix, (Type)Value wrappers are only unmarshaled as nil when the relevant key/value pairs are left out of the JSON entirely. Fields with an explicit null are unmarshaled into a struct with an empty value for the struct's Value field.

I signed it!

This is a bit tricky.  Sadly, the spec for JSON mapping is only documented for proto3 at https://developers.google.com/protocol-buffers/docs/proto3#json, which states ...
null is accepted and treated as the default value of the corresponding field type.
And "default value" here is ambiguous.  I can understand your ask for having it nil for proto2 optional fields.  Somehow the current implementation is consistent though for all WKTs by having a zero value instance.  I'm clarifying this with the Protobuf team and hope to get an answer back on this.
Regarding your PR though, it only changes some WKTs but not other ones like Struct, Timestamp, Duration, etc.  If the decision is to have nil value for these optional WKTs, then it may need to be consistent across all.
Although the following case can be tricky ...
message Message {
  optional google.protobuf.Value val = 1;
}

Should the value of val be NullValue or nil?
Anyways, I'll let you know once I hear back from the Protobuf team.

Ah, that's great, thanks! To clarify, this is only intended to cover the null wrapper types. I think my writing "(Type)Value" in my first comment was a poor abbreviation for "FloatValue, Int64Value, UInt64Value, Int32Value, UInt32Value, BoolValue, StringValue, and BytesValue", i.e., the wrapper types, but not NullValue or any of the others.
About wrapper types, the proto3 spec states:

Wrappers use the same representation in JSON as the wrapped primitive type, except that null is allowed and preserved during data conversion and transfer.

Obviously I take this to mean that they default (in Go) to nils, so that they have one-to-one marshalling/unmarshalling (they are currently marshalled as null when they're nil in the Go proto message types and EmitDefaults = true). The general consensus of the internet seems to be that this is the intended use of wrapper types in proto3, but it's true the spec doesn't seem to say anything about it :)
Thanks again!

Ok, here's what I got from the Protobuf team ... for deserializing JSON null to WKT value, it should be "treated as if the field is not set" with the exception for google.protobuf.Value type.  By WKT, it includes Any, Timestamp, Duration, ListValue, Struct and all Wrapper types.
A JSON null value for google.protobuf.Value field should be set to NullValue, this is already done by current implementation.
So, based on above assumptions, a fix for this should pass the following conformance tests that are currently whitelisted ...
Required.JsonInput.AllFieldAcceptNull.JsonOutput
Required.JsonInput.AllFieldAcceptNull.ProtobufOutput
Required.JsonInput.WrapperTypesWithNullValue.JsonOutput
Required.JsonInput.WrapperTypesWithNullValue.ProtobufOutput
The fix should not be just for the Wrapper types, but also includes the rest.  I have such fix already, but if you'd like to continue on this PR, let me know.
Thanks.

Hmm, I'll admit I hadn't looked super closely at the Value type up until now, but now as I understand it, they're used for representing arbitrary types bundled within a Struct, one of the possible values for which is null (i.e., NullValue). However, I don't see how this can fit in with the wrapper types (both their .proto definitions and, for this package, the Go code generated from them):
The wrapper messages in wrappers.proto consist of a message with a field that has a single built-in type (string, bool, etc.), so if a null StringValue field (Go type *wrappers.StringValue) can only end up as nil or *wrappers.StringValue{Value: ""}; there's no other way to represent a null vs. empty dichotomy here.
The Value type in struct.proto, on the other hand, uses oneof, so it cannot represent null vs. a single type, only null vs. any of several other types. Furthermore, for built-in types, it uses those types directly, so it's any of protobuf string, double, bool, or NullValue (plus structs and lists). The wrapper types StringValue etc. are not used here at all.
In other words, nullability for wrappers and nullability for structs using NullValue seem like separate issues, since they're incompatible as it stands.
Without defining new wrapper messages such as NullableString with oneof NullValue/string, and so on for each of the built-in types, the only obvious way I see to get "a particular type or null" semantics is StringValue vs. nil. Since wrappers.proto and struct.proto are shared across protobuf as a whole, not just the Go implementation, creating new oneof wrappers doesn't seem like the right approach in order to support nullability as part of the standard protobuf library.
Am I mistaken here? My apologies if I'm still missing something!

The Value type is different from the wrapper types.   Current implementation is correct with regards to deserializing "null" to the value of "NullValue" for Value type.
My point was that your fix only fixes wrapper types, but misses out on Duration and Timestamp.  One can structure the code to ensure that the fix is applied correctly to all these WKTs.  As mentioned, I do have corresponding fix that does that.  So, let me know if you prefer to pursue this still and I'll comment on your changes.

Oh, I see---sorry, I misunderstood and thought you were saying they are supposed to be the same. Yes please, comments very welcome, and I'd still like to pursue it!

Here's the diff to my fix (line numbers may not match up) ...

@@ -639,6 +639,11 @@

        // Allocate memory for pointer fields.
        if targetType.Kind() == reflect.Ptr {
+               // If input JSON value is "null" and target is a pointer type, it should be treated as not
+               // set EXCEPT for pointer to structpb.Value.
+               if string(inputValue) == "null" && targetType != reflect.TypeOf(&stpb.Value{}) {
+                       return nil
+               }
                target.Set(reflect.New(targetType.Elem()))
                return u.unmarshalValue(target.Elem(), inputValue, prop)
        }
@@ -652,10 +657,6 @@
                switch w.XXX_WellKnownType() {
                case "DoubleValue", "FloatValue", "Int64Value", "UInt64Value",
                        "Int32Value", "UInt32Value", "BoolValue", "StringValue", "BytesValue":
-                       // "Wrappers use the same representation in JSON
-                       //  as the wrapped primitive type, except that null is allowed."
-                       // encoding/json will turn JSON `null` into Go `nil`,
-                       // so we don't have to do any extra work.
                        return u.unmarshalValue(target.Field(0), inputValue, prop)
                case "Any":
                        // Use json.RawMessage pointer type instead of value to support pre-1.8 version.
@@ -716,14 +717,7 @@

                        return nil
                case "Duration":
-                       ivStr := string(inputValue)
-                       if ivStr == "null" {
-                               target.Field(0).SetInt(0)
-                               target.Field(1).SetInt(0)
-                               return nil
-                       }
-
-                       unq, err := strconv.Unquote(ivStr)
+                       unq, err := strconv.Unquote(string(inputValue))
                        if err != nil {
                                return err
                        }
@@ -738,14 +732,7 @@
                        target.Field(1).SetInt(ns)
                        return nil
                case "Timestamp":
-                       ivStr := string(inputValue)
-                       if ivStr == "null" {
-                               target.Field(0).SetInt(0)
-                               target.Field(1).SetInt(0)
-                               return nil
-                       }
-
-                       unq, err := strconv.Unquote(ivStr)
+                       unq, err := strconv.Unquote(string(inputValue))
                        if err != nil {
                                return err
                        }
@@ -757,10 +744,6 @@
                        target.Field(1).SetInt(int64(t.Nanosecond()))
                        return nil
                case "Struct":
-                       if string(inputValue) == "null" {
-                               // Interpret a null struct as empty.
-                               return nil
-                       }
                        var m map[string]json.RawMessage
                        if err := json.Unmarshal(inputValue, &m); err != nil {
                                return fmt.Errorf("bad StructValue: %v", err)
@@ -775,10 +758,6 @@
                        }
                        return nil
                case "ListValue":
-                       if string(inputValue) == "null" {
-                               // Interpret a null ListValue as empty.
-                               return nil
-                       }
                        var s []json.RawMessage
                        if err := json.Unmarshal(inputValue, &s); err != nil {

Feel free to improve on it as I may have missed out certain cases.  You'll need to update the tests to match the consequences of this but it will make sense based on the criteria I mentioned.
I've filed issue #397 to improve running conformance tests but we can treat that as a separate fix some other time.
I won't be able to respond immediately today for this but will try to get back on this PR late tonight or sometime tomorrow.

Revised based on your approach, which I agree is much cleaner.

I've made all suggested changes except for the one to the test cases---please see response on review comment.


Click on 'Scene Tree' == Uncaught TypeError

Repro:

Click on Scene Tree button
Uncaught TypeError is logged:

Uncaught TypeError: Expecting a function in instanceof check, but got undefinedtypeToString @ phaser-debug.js:1292
module.exports.HandlebarsCompiler.template.main @ phaser-debug.js:1021
ret @ phaser-debug.js:732
Scene.rebuildTree @ phaser-debug.js:1222
Scene.show @ phaser-debug.js:1249Panel.toggle @ phaser-debug.js:1073
(anonymous function) @ phaser-debug.js:231
(anonymous function) @ phaser-debug.js:1603

Environment:

Phaser v2.4.4
Chrome Version 46.0.2490.80 (64-bit) (Mac OS X)

According to the Phaser docs:
[readonly] stage : PIXI.Stage
[read-only] The stage the display object is connected to, or undefined if it is not connected to the stage.

This seems to fix it (in typeToString):
-        if (node instanceof PIXI.Stage) {
+        if (typeof PIXI.Stage !== 'undefined' &&
+            node instanceof PIXI.Stage) {

Here's a simple repro case:
git clone -b phaser_debug_repro --single-branch https://github.com/doggan/diablogl.git

Open up ./client/index.html and click on the 'Scene Tree' button. You'll see the error in the console at this line:

Notes:

Code: https://github.com/doggan/diablogl/tree/phaser_debug_repro/client
Note that I'm including Phaser before the Phaser-Debug plugin.
Adding in the change in my PR, and the root object will display as: PIXI DisplayObjectContainer.

The phaser build you have down't look like it includes pixi at all...

I just confirmed using Phaser from CDN: PIXI.Stage is defined in Phaser 2.4.3 but not in Phaser 2.4.4.
Phaser 2.4.3:
https://jsfiddle.net/hn3f22Lm/
2.4.3
(index):29 function

Phaser 2.4.4:
https://jsfiddle.net/rasmz9no/
2.4.4
(index):29 undefined

Perhaps @photonstorm could shed some light?

For what it's worth, I'll second that 2.4.4 throws the above error when clicking on the Scene Tree button. Downgrading to Phaser 2.4.3 works as expected.
Happens on both Chrome 46 and Microsoft Edge 20.10240.16384.0. Using version 1.1.6 of the plugin.
Very nifty plugin, by the way.

https://github.com/photonstorm/phaser/commit/b99c9e22ecc471e40432d544f41e333f2397548b
In your game code just do PIXI.Stage = Phaser.Stage and it should map fine then. Not sure if this plugin does anything special with the stage or not, but I suspect not, probably just iterates it?

@photonstorm It does instanceof on it, it is the "auto determine type" logic.

@englercj Should I close my PR (https://github.com/englercj/phaser-debug/pull/10) if you think this is not the correct fix?
It doesn't affect me one way or the other, as I've been using your plugin with the above workarounds. It would probably be nice to get a fix into master, though, for anyone else who happens to upgrade to Phaser 2.4.4+, as they will run into the same issue.
Thanks again for the great plugin. :sparkles:

I would merge #10 now that I understand the issue, if you also added support for Phaser.Stage in there as well.

Added. Please check it out.


Production questions

I'm evaluating FreeIPA for a new project (micro-installation, 10 users, 15 machines)  and am looking at running it from inside of a docker instance in production.
I'm willing to work through bugs and dragons, but is there anything you know of that is currently a show-stopper for doing this?
I'm new to FreeIPA, so I might be entirely off -- Here's what I'm worried about on first inspection:

It looks like we need to expose 7389, 9443, 9444, 9445 for replication and server-server communication.
Passwords need to be passed in over the command-line. We could do a little better by reading them from files that we mount to the container so that they only show in the command that's internal to the container as opposed to on the host.
We don't expose a meaningful process to the docker host for sending signals to via docker kill.
We run an ssh server (maybe remove?)
We have to workaround systemctl
ntpd in the container

Any insights into what are or will be problems would be helpful. I'd also be happy to help out if there's anything on the roadmap that is open to outside contributors.
Cheers,
ToBeReplaced

Related to production use, I would be grateful for some explicit documentation on persistent storage locations, so that host volumes or data-only containers can be used for data used/served by the container. Some VOLUME directives in the Dockerfile would be a great start.

Some VOLUME directives in the Dockerfile would be a great start.

Please check the master-test-volume branch for the current work in progress.

Related to production use, I would be grateful for some explicit documentation on persistent storage locations, so that host volumes or data-only containers can be used for data used/served by the container. Some VOLUME directives in the Dockerfile would be a great start.

The branches were now updated with content supporting persistence. Please check the README for instructions.

We run an ssh server (maybe remove?)

This was now removed even from master since docker exec can be used for debugging now.

I'm going to close this issue because I believe the concerns have been addressed.
Please open separate (GitHub) issues for separate issues you might encounter or find outstanding.


Use post binning labels in classification

The classification now uses raw classification results, then bins them into the four post-bin categories (slate et al). The classification on TimePoint now uses the raw categories, but should use the more user-friendly categories.
This may take away the need to have a scores property on the TimeFrame.

Was about to close this, but leave it open while me ponder whether this was a good idea.

was reverted in 145807a / v4.2.


fix(source): stdout/err missing source meta

:tada: This PR is included in version 1.72.8 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


triangle faces

nice work！I want to know why i should keep the number of triangle faces within around 40,000?

The pytorch3D module uses a set of rules to allocate the buffers, which might not be enough when the mesh has too many triangles. I have not investigated very much on how to refine the rules to support mesh with more triangles, but instead set it statically to a number that seemed to work well for mesh less than 40000, and at the same time don't hurt the speed.
When the buffer is overwhelmed, you will see missing faces as the face list get truncated.

thanks a lot！


Not rebuilding on save

All of a sudden the rebuild on save stopped working. The only error it throws is this:
2017-11-21 13:42 node[41079] (FSEvents.framework) FSEventStreamStart: ERROR: FSEvents_connect() => (ipc/send) invalid destination port (268435459)
I'm not sure what to do. Any help?

Fixed it. How? Restart... I'm on MacOS and there seems to be an issue with file permissions some times.


[WIP] Travis debian release setup

Work In Progress - Do not Merge

[x] travis setup
[ ] platform-util files search on Linux
[ ] platform-util icon protocol realisation to show file icons in the files search on Linux
[ ] platform-util window focus management on Linux

travis setup

auth on travis with github
create oauth token at https://github.com/settings/tokens with repo scope

npm install travis-encrypt -g
travis-encrypt -r appetizermonster/hain <token>

Token (output from travis-encrypt should be replaced in  https://github.com/ewnd9/hain/blob/94814828dbdbb65759740de417c0dc289b6da026/.travis.yml#L9
Right now there is my token for the test repository https://github.com/ewnd9/hain-travis-publish-playground I had to create separate repo in order to test releases (git tag) handling
Related

travis doc

debian package for latest version is available at https://github.com/ewnd9/hain-travis-publish-playground/releases/tag/v0.3.33 // cc @toXel (https://github.com/appetizermonster/hain/pull/48#issuecomment-202776087)
related to https://github.com/appetizermonster/hain/issues/98

@ewnd9  Apologies, I can't fix the merge conflicts from your repo.  I'll merge as soon as you put merge the conflicts though.

@cpriest Will take a look on the weekend

@cpriest I've updated the pull request, although now without travis-ci setup because it seems it is too cumbersome.

@ewnd9 Thanks for the contribution, I've merged this in.


Added Regex Cheatsheet and updated README file

Hello @gupta-soham
Thanks for your contribution.
Let's connect ->
GitHub -> @Suryansh1720001 (Follow)
LinkedIn -> https://www.linkedin.com/in/suryanshprajapati17
Also Star the repo ⭐

My Pleasure 😄


Save the downloaded datasets to local directory

In cnn and cifar_distributed_cnn examples, the downloaded files are in the /tmp directory, which may be lost after the machine is restarted.

add an arguments for local directory and then save the downloaded files to this directory

changed in example folder https://github.com/apache/singa/tree/dev/examples/cnn/data and https://github.com/apache/singa/tree/dev/examples/cifar_distributed_cnn/data

resolved


6in4 host docker ipv6

Hello. Can anyone suggest the correct settings for docker-ipv6nat? Ipv6 works in docker only if dhcpv6 is disabled for host local clients. Accordingly  i myself am left without ipv6.

del


fix statement.LimitN(0) will delete or update all data

change LimitN from int to *int.

https://github.com/go-xorm/xorm/issues/1117


Store and use revision in tab runtime dependencies

Should fix brew upgrade <pkg> producing broken installs. We were treating two packages with the same version but different revisions as compatible (because we didn't store revision info at all). This was often incorrect and lead to several reports of broken installs.

 @MikeMcQuaid is there a chance to merge this, release and improve it further later?

 @MikeMcQuaid is there a chance to merge this, release and improve it further later?

@SMillerDev Not as-is, no. I agree it's important though and, if no-one else has picked it up by Friday, I'll try to get it merged then.

@Bo98 @apainintheneck I've adjusted this to:

also set pkg_version field in tabs, it's more useful to non-Homebrew consumers this way
implement the conservative logic discussed above based on the table that @apainintheneck came up with
tried to make the formula_installer logic more minimal and upgrade and dependency logic more similar and better documented
fixed up tests and style where needed

@Bo98 @apainintheneck once you're both happy: can one of you merge this? Thanks ❤

(assuming 0.present? will need return false - I forget with that one).

Also pushed so we Version.new wrap the version field since PkgVersion.new actually needs that rather than a string.

Thanks for help before and after, @Bo98!

Thanks for fixing these issues. When and how can we check if these updates will work? In my situation https://github.com/Homebrew/homebrew-core/issues/153593

It will be released probably on Monday. The fix won't do anything to people with already broken installs, however such installs are fixable by updating your out-of-date formulae.
It looks like your particular issue might be bug within platformio formula itself however - I would need to look into it.


unable to fuzzy find file in current directory

attempting to open file using command + t fuzzy find shortcut. file search is not returning files that exist in current directory.
lesson: javascript-intro-to-functions-lab-vfa-2017

update: issue is intermittent (yay!)
i switched batches and opened the same lab in a different batch/track (javascript-intro-to-functions-lab-v-000). then i was able to command + t find any file in my current directory and recently opened files.

Noticed first in 2.5.0-beta0 but I would guess this has likely been an intermittent issue for a while... possibly related files appearing on the local disk after fuzzy search has indexed them? That's a total guess though, I don't know how Atom's fuzzy search works.

somewhat related: #396


feat: check nodes (or peaks) before merge them

Check nodes (or peaks) before merge them.

@yangby-cryptape benches/mmr_benchmark.rs should be modified also


docs(kit): added ecopasskit success story, the battery pass application

Why do we create this PR:
There is the requirement to add the EcoPass Kit Success Story of the Battery Pass
What do we what to do in this PR
We want to add the battery pass success story that contains descriptions of the reference application and what was exposed and built by the association.
Large Files PRs:

[HMI 2023 Battery Pass Video] https://github.com/eclipse-tractusx/eclipse-tractusx.github.io.largefiles/pull/12

What has changed?
Added

Added Battery Pass Application Success Story

Content Review PRs:

https://github.com/eclipse-tractusx/eco-pass-kit/pull/30

Related PRs:

[Adoption View] -> #630
[Software Development View] -> #631
[Software Operation View] -> #633

This is the fourth PR from the EcoPass KIT v2.0.0 Update
Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review:

[x] DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
[x] Copyright and license header are present on all affected files

How to proceed here? Should this be part of the release or is will this be under "next"? And has this be gone through IP clearance from consortia?

It should be in next once we merge it
Att. Mathias Moser

De: Maximilian Ong @.>
Enviado: Tuesday, February 13, 2024 3:36:46 PM
Para: eclipse-tractusx/eclipse-tractusx.github.io @.>
Cc: Mathias Moser @.>; Author @.>
Asunto: Re: [eclipse-tractusx/eclipse-tractusx.github.io] docs(kit): added ecopasskit success story, the battery pass application (PR #634)
How to proceed here? Should this be part of the release or is will this be under "next"? And has this be gone through IP clearance from consortia?
—
Reply to this email directly, view it on GitHubhttps://github.com/eclipse-tractusx/eclipse-tractusx.github.io/pull/634#issuecomment-1941653371, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARDH474COMSOPD4R7EM3OQ3YTN275AVCNFSM6AAAAABCHO44Q6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBRGY2TGMZXGE.
You are receiving this because you authored the thread.Message ID: @.***>

Anyway I need two commiters to approve this for me.
@SebastianBezold and @saudkhan116  could you help me here? Or you also @maximilianong...

It should be in next once we merge it. However I am waiting for the owners of the KIT to give me green light to merge this. The IP Clearance is still on the way 3 signatures missing was my last status.

Hi @matbmoser  - Without IP clearance this should not be published (merged).

It should be in next once we merge it. However I am waiting for the owners of the KIT to give me green light to merge this. The IP Clearance is still on the way 3 signatures missing was my last status.

Hi @matbmoser - Without IP clearance this should not be published (merged).

Sure! Therefore I am waiting for the IP Clearance to be done and then they will give me the green light.

It should be in next once we merge it. However I am waiting for the owners of the KIT to give me green light to merge this. The IP Clearance is still on the way 3 signatures missing was my last status.

Hi @matbmoser - Without IP clearance this should not be published (merged).

Sure @maximilianong! Therefore I am waiting for the IP Clearance to be done and then they will give me the green light. I thought at least it could be in "ready to merge status" with the commiter approvals done.

Cool @matbmoser and will this be part of the 24.03 release?

Yes @maximilianong. What I was told It will be also part of the 24.03

@matbmoser please resolve the conflict.

@maximilianong conflict resolved.


add rename

we need to rename the output filename.

It was added before: https://github.com/kevva/download/commit/a36b04e6a9ff5cca2d52438f5e06853497dd1f37
Is this PR still relevant?

Looks like the module has been rewritten so renaming is probably still relevant. I'd use destination for this though. If destination looks like a filename (based on the ext name maybe), rename to that.

Ping @kevva

need also to rename the file output.
For solving fast the rename, I've changed the code as following:
//const dest = output ? path.join(output, filenamify(path.basename(uri))) : null; 	const dest = output;
but would be good to have an option to do this or auto discover if output indicates a file or a folder.

I think the option name should be filename. rename makes it sound like it accepts a function where you can rename the filename. This will also need a test and documentation updates.

I also need to rename the output filename.
thank you.

Closing this for lack of activity. Opened an issue for it: https://github.com/kevva/download/issues/124 PR welcome.


Which Go compiler versions should Pion support?

This issue was 'inspired' by https://github.com/pion/transport/pull/200 created by @jech which has the effect of broadening the range of Go compiler versions that Pion can be built with. I felt the question of Go compiler support is best answered with substantial community input as it impacts past and future contributors to Pion, as well as third-party software that uses Pion as a dependency.
The core question is: which versions of the Go toolchain should Pion support? Right now there is no clear answer (i.e. nothing is stated explicitly in the docs), and the Pion codebase itself offers a number of contradictory answers:

Pion's CI system tests builds only against 1.17 and 1.18. This is consistent with Go's own support for the current major version, plus the last version, of the toolchain. This means that, in practice, committed changes are only guaranteed to work on 1.17 and 1.18.
go.mod in the main repo targets go 1.13. Some of the other packages e.g. pion/transport target go 1.12 in the go.mod.
Recent changes e.g. inclusion of optimised assembly for crypto functions currently use syntax only available in 1.16 onwards.

The point was raised that the Go toolchain advances faster than some Linux distros are updated, so it is possible/likely that people are developing primary with Go toolchain releases that are now unsupported/EOL.
Some possible options:

We synchronize Pion's support for the Go toolchain with Go's own support schedule, i.e. current version + last major version only. This is effectively what's done by Pion's current CI system, and so this 'change' is simply to state that 1.17 and 1.18 are the only supported Go toolchain releases. We can choose to enforce this in go.mod or not do so, and state that Pion may compile under earlier versions of Go but we do not test or support such usage.
We make a decision to broaden support to e.g. current + last + last-but-one + last-but-two. If we do this we should change Pion's CI process to also build and test under 1.16 and 1.15. This might reveal breakages either due to Go features in use in the codebase that were not supported in 1.15/1.16, or due to compiler bugs whose fixes were not marked for backport. This might be fine, or might open a 'can of worms' - it is hard to tell.

What are people's views on this?

Until recently, Pion has been using a system that apparently works for everyone:

people would submit improvements to Pion, without going out of their way to ensure it works with older copilers;
occasionally, somebody would notice that Pion no longer works on a version of Go that they still care about, and submit a fix;
occasionally, we'd remove obsolete code when we're reasonably sure that nobody cares any longer.

Here's an example of a perfectly friendly exchange fixing breakage on an older version: https://github.com/pion/ice/pull/361.
This system has been working well, and has allowed people who care about older compilers to use a recent version of Pion, which is good for the project since it gets timely testing.  I don't understand why you have suddenly decided to replace it with something different, that is obviously causing pointless friction and that would cause me to stick to an older version of Pion.

@jech - I'm not sure I understand.

I don't understand why you have suddenly decided to replace it with something different

This is exactly what I am not doing. Per my post in pion/transport I do not think that any single individual (including myself) should be making unilateral decisions on versioning policy, because these decisions potentially have wide community impact. That's why I am asking for broader views (beyond me and you), so that whatever the consensus is, we can codify it so there is no ambiguity, and both future contributors and Pion users know what compilers we support.
My point is not that anything done to date is wrong, rather, because we don't have anything written down on what this project's policy is on compiler support, there is the ongoing risk that two people disagree on what the policy actually is. What is happening now is a good example of what I want to avoid in the future. So, I am asking for broader views on what our policy should be, so we can write it down, and then there is no ambiguity. I am not 'replacing it with something different', and in fact I do not have any views on what the policy should be. I would hope this is clear from my above post when I presented a number of different options, without expressing any preference myself. My sole wish is that, as a community, we agree 'a view' and then write it down, so there is no ambiguity.
@Sean-Der, @davidzhao and others - I would appreciate your views.

@adriancable I understand the wish to have an agreement as a community on what compilers Pion supports and I think that what @jech described above worked well in the past. One problem I see with this approach is that it is somewhat unclear when contributors are allowed to use new language features, which most of the time is not a big issue, but might be one soon, now that both of the last supported compiler versions support generics. I don't know how much they are actually used, so maybe that is nothing to worry about, but in the worst case, I think we may lose contributors by requiring them to implement patches without using new language features.
I think we should certainly avoid situations such as in pion/transport where the code is incompatible with what is declared in go.mod.

@mengelbart - thanks for this - I don't have any issue with @jech's proposal for a system at all, but I think we (A) need to reconcile it with what happens on the contributor/CI side, which is currently that we only build and test for 1.17 and 1.18 (this may be 1.18 and 1.19 by now), and (B) write it down. My issue is not with any specific policy but with 'folklore' policies in general that are not written down. This just causes confusion, unless you have been following how things work at Pion for a long time. We shouldn't make 'learning folklore' a requirement to contribute to Pion.
I absolutely agree that code should not use language features that are not supported by what is declared in go.mod. (In the interest of transparency, I am guilty of this in at least one place in pion/transport.) My uncertainty is that there are 2 ways to fix this - remove the language features, or bump the version in go.mod. The former is what @jech would like and appears in line with the 'folklore' policy in effect. The latter would enable us to sync up the module versions with what we actually support, i.e. what the Pion CI system builds and tests against (1.17/1.18).
If we are happy with the policy that @jech described then please let's write it down! We also need to make it consistent with what the CI system does. Some possible wording we could add to the README that might achieve both things:

Pion aims to match Go's own policies on toolchain version support, that is, the current and previous major versions of the compiler. At the time of writing this means that Pion supports Go versions 1.18 and 1.17 (probably 1.19 and 1.18 by now). Pion's CI system builds and tests against these Go versions.
We recognize that older versions of Go are still in use by developers. We cannot guarantee compatibility with EOL versions of the Go toolchain, because we do not build or test against these compiler versions. However, if you do have an issue building or running with an EOL compiler version and have a fix for this, we are open to accepting PRs (provided that they do not break compatibility with supported versions of the toolchain).

Thoughts?

Repeating parts of what I just wrote on pion/transport#200:
I'm running Galène (which depends on this project) as a production server on Debian stable which ships Go 1.15. Since this is a production environment I'd very much prefer to stick with the Go version it was shipped with (which has full security support) rather than using the one from backports (which may or may not get security updates).
If there's significant effort required to continue supporting a Go version for the lifetime of Debian stable (usually about 2 years) I can understand you'd prefer not to. I'll update to Go 1.18 from backports in that case. But at the very least the build should fail in a way that makes it obvious the reason for the failure is that I need a more recent Go version.

Jumping into this late. Been thinking about this one for a bit.
I support having an official "version policy" around Go version support. My reasons are:

set clarity and expectations for contributors around compatibility expectations
stating what we won't support will reduce the perceived difficulty of contributing
it'd be hugely beneficial to adopt a version where newer features like generics could be used. we don't want Pion to be a project to be forever stuck on 1.15.

It's important to make the distinction that this is a developer-impacting decision that does not impact the end-users. As with all Go binaries, there are no dependencies on having a particular toolchain installed for end-users.
What are reasons for folks that develop with Pion to keep using Go 1.15/1.16?

@davidzhao - one of the reasons I have heard is that Linux distros don't tend to update their Go toolchain as often as they could/should.
I'm not sure how much of a practical block this really is, though. The Go toolchain has been designed to be simple to install and update (copy and paste one command line into the terminal). @jech - do you know from Galene users why some people don't want to use more modern / supported versions of Go?

I'm sorry, but I don't have either the time or the inclination to have this discussion.
In the meantime, however, compilation under gccgo is still broken.  So please either apply pion/transport#200 or provide a different but tested fix yourself

@jech - that's a shame. This discussion started, I believe, as a consequence of Galene users being frustrated by the inability to compile under older versions. If you 'drop out' at this point and we lose an understanding of this data point, it makes it harder to make good decisions (= more likely we will continue in this holding pattern for longer than we need to).

This discussion started, I believe, as a consequence of Galene users...

I'm pretty sure that's not the case.  You started this discussion single-handed, thus creating a problem where there was none.

@jech - it's actually the opposite. By actually defining a toolchain support policy we will save people a lot of work in the future (e.g. writing code using generics, and then being told after the fact it isn't allowed). If anyone else feels that I am causing extra work for everyone, they haven't yet said so, so I will disregard that particular comment for the time being, but am always open to hear views from others.

This was discussed at the Pion quarterly meeting in Slack. Consensus was that 1.19 would be an acceptable upgrade

1.19 is what Debian stable is at. This seems to be the platform where users are stuck on older versions
1.19 does give us some features that people are excited for

@edaniels If you are interested want to make https://github.com/pion/.goassets/blob/master/scripts/lint-go-mod-version.sh fail the build. I can help make the PRs across all the repos if you like!
Happy to take the issue myself, but this seemed like something you were passionate about

Yup I'll give it a stab. May need help but I'll lyk

Done! go.mod version is 1.19 across all the repos.
Thank you so much for doing this @edaniels !

Woo! Tag teamed!


Unable to specify scopes before sign in

The new API looks to be a two step sign in -- first step basic sign in and then another one using addScopes to add a scope. This is a departure from previous versions of SDK where we could specify scopes as a property to GIDSignIn.sharedInstance() before sign in. Is this a new behaviour  or is it still possible to do single step sign in?

Duplicate of #23


Promise.done is deprecated.

Atom now uses ES6 Promises instead of Q. Call promise.then instead of promise.done
Promise.done (/Users/anton/Downloads/Atom.app/Contents/Resources/app.asar/src/atom-environment.js:1148:5)
Object.addPreviewForEditor (/Users/anton/.atom/packages/api-blueprint-preview/lib/main.coffee:149:48)
Object.toggle (/Users/anton/.atom/packages/api-blueprint-preview/lib/main.coffee:122:21)
atom-workspace.atom.commands.add.api-blueprint-preview:toggle (/Users/anton/.atom/packages/api-blueprint-preview/lib/main.coffee:54:26)
CommandRegistry.handleCommandEvent (/Users/anton/Downloads/Atom.app/Contents/Resources/app.asar/src/command-registry.js:260:29)
<unknown> (/Users/anton/Downloads/Atom.app/Contents/Resources/app.asar/src/command-registry.js:3:61)

I have same issue too

+1

+1

+1

+1

+1


Make exception message configurable for NoResultException

Currently it's not possible to use a custom exception message for the NoResultException. It would be great to use a custom one. For example you can define what specific result was expected or with what query it was executed, let's say you want to find members with a select query. Then it would be great if the message could be 'No members found for query.', instead of the default message.
This change is backward compatible, because it uses the current message as default value for message. Furthermore it's now possible to loop the parameters $code and $prevision exception throw this NoResultException.
Thanks for the hint Koc.

I don't see a reason to change this, since this exception should only be thrown from the internal scope.

While I understand that you have your own use-case for customizing the exception message, you should instead use your own exception class/interface rather than relying on the ORM ones.
This is indeed a limitation caused by the ORM not having proper exception marker interfaces right now ( doctrine/common#681 )


Function fs_scandir_next creates tables unnecessarily

I think fs_scandir_next is being unnecessarily wasteful here: https://github.com/luvit/luv/blob/master/src/fs.c#L406-L436
Instead of creating a table at each call it could simply return 2 values (name and type). For programs that scan lots of big dirs, this is going to be much faster, and more importantly won't create a lot of garbage and put a lot of pressure on the GC.
The resulting code is also simpler to use. A table only adds complexity here, IMHO.

Good idea.  This will be a breaking change to the API, but probably worth it.

@tbastos could you send a PR, my dev machine is currently out of order.  If not, I'll get to it some time.

Cool I'll work on it... sorry for the delay.


[Question] Get dateString from the instance

With the onChange event we can get a dateString as below (outputs dateString: 2019-01-03). Is there a way to get this same dateString format from the fp instance? Apologies if I'm missing this in the docs.
const fp = flatdate(elStartDate, {
        onChange: (dateObj, dateString) => {
            console.log(`dateString: ${dateString}`);
        },
    });

Thanks for this great project.
Your Environment

flatpickr version used: 4.5.7
Browser name and version: Chrome latest
OS and version: Windows 10

You can get the selected date as an object from the flatpickr instance and there's a formatting method, so this would achieve your call:
fp.formatDate(fp.selectedDates[0], fp.config.dateFormat)

@KayakinKoder another solution: fp.input.value if you don't have allowInput: true.


Shared Kube/Titus job reconciler

@tbak everything other than the grace time for terminations in the reconciliation loop is a minor and can be ignored


Convert to using react hooks in wallet

This is very hacky and reimplements parts of reason-apollo, should be revamped when hooks launches for real.
pls don't look at what we do to get the ppx

@bkase darnit this doesn't work because build-wallet doesn't have the opam switch. How against checking in a precompiled mac exec are you (bs-platform includes one in its npm package)


[Feature Request] Undo branches

Undo branches / undo tree allows you to undo some changes,
then make a new change, while keeping all changes available in the undo tree.
The undo tree can therefore prevent awkward scenarios such as:

Losing all redo futures by accidentally pressing a button during undo
Copying the file or save it with git when trying multiple alternatives

This screen-cap showcases how it works in Emacs with undo-tree.

https://github.com/Zalastax/vscode/commit/c5699711d21dece88c7c608f6d8ae277f72a0081 contains the changes to the model that are needed, but several questions remain to be answered. I'm interested in completing the feature but need further input before proceeding.

How should the UI look? Graphics / ASCII, clickable?
Should the tree be formatted like in Emacs undo-tree (as short tree as possible) or like Vim's Gundo http://screenr.com/M9l (one state per line sorted by time)?
What unit-tests should be added?

You can try out the current changes by compiling my fork and you'll find 'History Tree' in the Edit menu. Clicking the menu item will console.log a function that changes what redo future is selected (just like in the gif).

This would be extremely useful.

Quite cool!
Perhaps I'm biased from looking at git branches too often, but I sort of like Gundo's approach to rendering the undo tree (especially the top->bottom -- present->past sort order).
I'm not sure what the nodes should be, should they be undo stops (perhaps a bit too many of them), should they be time-based, should we change the undo stops themselves to be time based... I think these are a bit too hard to decide upfront. I also think this feature could be useful for linear undo histories (I'd use it even if the undo tree has no "forks" as a way to look back at what I've done)
As for implementing it, I think you're on the right path w.r.t. the data model to represent the undo tree. For the UI, I'd start a new folder in editor/contrib/ and start easy with an editor widget (perhaps an overlay widget). I'd look into rendering the tree using a <canvas>, and I'd try to make the editor core API (what will eventually make it to IModel in editorCommon) as slim as possible -- the idea is the editor can work just fine without any of the /contrib/ (they're sort of plugins) and this should be a plugin in that sense.
Definitely a nice idea!

@alexandrudima I'd like some new feedback or hand the code over. https://github.com/Zalastax/vscode/commit/d7f0b8496c6b17479d92e56cf34479cd37acdf1c implements the model changes and a contrib plugin with nice rendering. Things I know need to be improved are:

No tests have been added (old tests pass though)
Strings are not internationalized
The canvas has to be focused to move between items (arrow up/down)
History Tree can only be ooened using a right click menu
History Tree can only be closed using the ESC key

I have completed the parts I find interesting so I'd be happy to let someone else finish this up, but there would be no problem if I have to do that myself. Let me know what you think and what the next step is!
Render of the history tree using a light theme:

Small improvements and keeping up with upstream in https://github.com/Zalastax/vscode/commit/83359d5e5c5326836a1be04f7af674d51135d426.
Added:

Strings are internationalizable
Positioning of the tree in the x-dimension is now dynamic

@alexandrudima what's the way forward? https://github.com/Zalastax/vscode/commit/faa9fbdcb5bbdaae5f36088451870bcc09685cfd keeps up with upstream, but I can't keep doing that forever.
@kieferrm since you're online at this moment I'm pinging you in case you can help me get attention 😸

Thanks for your hard work on this @Zalastax, we really appreciate the effort you have put into this. Please accept my apologies for not getting back to you earlier.
I think this is a great idea and it is one that I think most people would react positively to when it was described to them.
Crucially though, I wonder if it is something that many people would modify their behaviour to start to use. The UX and UI for this would have to integrate well with current behaviour, otherwise I expect many people just wouldn’t adjust. For example, if, in order to take advantage of this, you had to learn another keybinding on top of ctrl-Z, most people would just keep using ctrl-Z because that is such a habit.
On the other hand, if it was integrated with the undo command today, that would increase usage, but we would need to do it in such a way that people don’t notice it most of the time. Ctrl-Z would continue to work as expected until there is a branch when we would need to get them to tell us which branch to take. This is a challenging UX to design.
So I think if we make it a separate feature to undo, a small number of people might adjust their regular behaviour to start using it. If we worked on the UX so that it integrated with existing usage patterns, more people would use it, but we would run a higher risk of breaking a fundamental editor experience if we didn’t get the UX right.
Unfortunately we do not have the capacity to focus on designing this user experience. So given this, sadly we will have to decline this feature request. I understand that this is disappointing news and I can only apologise again for not responding earlier.

I'm disappointed and perplexed. These news come after I put the work in after getting greenlit. We already have examples of this working in Vim and Emacs, and it's fairly usable already in my fork.
You don't use this feature all the  time, but when you do it's indispensable. Normal undo is undisturbed and when you need it you bring up the undo tree. I think we would only need to polish the mouse and keyboard interaction of what is already there in the fork to provide good value with a small effort.
I really hope you will reconsider.

@stevencl Any way to get you to reconsider? How about a pep talk.
Frankly, I believe you misinterpreted how it might work.
UI wise:

normal C-z and C-r work just as most people expect, they simply stick to the immediate path between the newest leaf and the source. Leaves are only created when changes are made mid-tree, so it would be relatively simple to rearrange the tree to keep the current path on the far left or something to make traversal easier
You've implemented non-standard conventions that stay out of the way by default before. Take multiple cursor support: certainly not a standard feature on most text editors, it's a feature that has to be used explicitly and has keyboard shortcuts to memorize, but now that I use it I can't imagine living without it. It's a true power user feature that differentiates VScode from its competition. I don't know if you came up with it but you implemented it well when others didn't, and you pushed text editing forward. This is what makes you a great editor, your focus on refined and useful tools for putting letters in a text file is the core of who you are. This tool, which few may use at first, is primed to make the leap to GUI text editing. Let it happen.

What if we work more heavily on the UI? I gather this wouldn't be very doable as a plugin, right? I'm actually willing to help maintain and update a fork if @Zalastax's is okay with that. This is the one big feature I've been waiting for. The VSCodeVim plugin maintains its own undo/redo history that diverges from VSCodes, and I know that they have valid reasons for doing so, but it's so occasionally annoying.
even if this doesn't work out, I still love VSCode and all the work the team puts in. Thank you for this beautiful piece of software.

@chuckdries you're very welcome to do so, and I'll be happy to help you maintain a fork. I'll fix my fork so it works on top of master. You can email me if you want to get in touch on some other platform.

I'd be more than happy to chat. As I said, I think this is a great idea.

@stevencl What about exposing the undo tree for extensions and keeping the current UX inside standard vscode unchanged?
I understand from a UX perspective this is a very hard change to make, and there possibly out not be one correct solution to the problem.
The API though (as far as I understand it) is actually rather simple though. All that is needed is a getTree() and setState(node). With a little more thought (and chatting to the vscode-vim group) it might even allow a solution to the VSCodeVim/Vim#1490 regarding syncing their undo stacks.
The VS editor can always walk the right-most edge (which is equivalent to how undo/redo works at the moment) and it'd allow experimentation with the UI from extensions.
Motivation:
For some of us though this undo tree's mean not losing work. Personally I'm using a voice programming system and mistakes are frequent though very rarely destructive. Without having an undo-tree in the editor a mistake during any kind of undo operation runs the risk of being destructive and losing history.

I won't have time to maintain my fork for several months but if anyone wants to step up to make this happen I'll help. There are further details for what needs to be done in the issue section of my fork. I think it's important to have a team member help at least design the API, since the details are quite intricate. For this to get done there needs to be clear and fast communication from all parties, which is not happening now.

I'd like to voice my support for this. It would be an excellent addition to the editor (we've all accidentally blown away our undo history!). As mentioned above, it in no way affects how current undo stack works - it is transparent.  And finally, @Zalastax has kindly implemented the feature!
Seems like a no-brainer?

@stevencl I use undo-tree in Emacs on a daily basis, and the key thing to understand about this feature is that when your editor already has a normal undo stack (as VSCode already does), adding a tree based undo UI on top of it is completely compatible and transparent with the standard undo and redo commands. If the tree is not open, an undo will go up a node in the tree, and a redo will go down the most recently chosen branch. Because the most recently chosen branch is the most recently created branch by default, the default branch chosen will be exactly the same whether or not a tree based undo stack is used in the implementation, even if the undo tree is never used and the user is unaware that it exists. This is not a UX problem because if the undo tree is not opened the editor will behave exactly the same with undo/tree, but an internal undo tree implementation is necessary to allow for this new undo tree UX to be added. Please reconsider.

I'd really like to have this.
One idea for the UI:
When undoing multiple changes I hold Ctrl pressed and press Z as often as necessary.
So when pressing Z we could show an overlay (maybe over the Explorer) that is as simple as the Emacs one and keep it visible as long as Ctrl is held. Pressing Z and Y works as always and navigates through the tree. Using the cursor keys allows selecting alternative branches.
Example:
Pressing Ctrl + Z undoes the last change and shows the undo tree. Still holding Ctrl pressed and pressing the arrow down key undoes another change. Still holding Ctrl pressed and pressing the arrow right key highlights an alternative branch in the undo tree. Still holding Ctrl pressed and pressing the arrow up key redoes the first change from the new branch.
Z and arrow down as well as Y and arrow up can be used interchangeably.

@gralphi that's not a bad idea. I really like how holding control is what  keeps the ui open. However, isn't there a risk that it will feel like the UI is flickering if you just do a normal undo? Having a special key combo to open the UI seems preferable to me, perhaps ctrl+alt+z?
Keep the good ideas coming and we'll have a good base once all parties have time to get involved again!

Having a tree overlay that pops up after a normal undo/redo is an interesting idea, but I don't think it should be enabled by default because undo trees can be confusing and it's not obvious that normal undo/redo works the same in a tree, as per my previous explanation. I also don't think the user should have to hold ctrl to get related undo commands, that would get confusing when the other binds do things unrelated to undo because the keybinds would become modal, and I think that's less intuitive.
By default, the undo-tree Emacs package does not override the main undo bind, instead it only replaces one of the less common keybinds for undo so you can still use both. The alternative keybind then opens the tree without starting an undo yet. I think we should do something similar and add a new keybind for the undo tree to avoid confusing existing users. This would make the feature harder to find, but it could always be added to the documentation and following the principle of least surprise is more important than enabling more advanced features by default in my opinion.

@nickmccurdy I totally agree.
The biggest question marks when I stopped working were:

What APIs do other extensions need? E.g. VSCodeVim.
What APIs can the UI use? previewHTML seems most natural, but is difficult to use.

See https://github.com/Zalastax/vscode/issues for more details.

With the new webview API coming up, the view API seems to be solved. The view can now be a webpage that listens to commands from the main editor and updates the view accordingly.
Thus, the biggest remaining hurdle is designing the API for the undo tree information.
I still don't have much time to commit to this, but I can help discuss your ideas if someone steps up.

Sorry for not responding earlier.
I understand how this can work in addition to regular undo (indeed, I used zalastax's fork to play with the experience before responding back in September last year so I have seen how it might work). And I understand the value that undo branches provides. My reluctance to take on this work is not based on a lack of understanding of undo branches or their value.
As the UX researcher on the team, my goal is to optimise the experience that we ship out of the box for as many users as we possibly can. Adding extra commands and functionality always comes at a cost, no matter how useful the command and functionality is (at the very least, extra commands increase the search space that new users must search through when looking for functionality). So we are always very careful about adding anything to the product. Consequently, my point about investigating how or if this could integrate with the regular undo experience was motivated by this goal.
That being said, I think that the comparison to single cursor/multi cursor is fair and I do believe that undo branches could live alongside regular undo. However, we would need to spend time carefully designing the UX for undo branches. For example, how should they be made visible (in a document/a viewlet/an overlay/a panel/something else)? How can we integrate them in a way that is consistent with other UI in the product? Additionally, we would need to spend time designing the UX for undo branches so that the user is always very clear about the changes that will be made as they navigate the undo tree. We would also need to consider how this would work with other extensions (such as LiveShare: see this issue for example https://github.com/MicrosoftDocs/live-share/issues/7).
This isn't a trivial amount of UX work although none of it is impossibly difficult UX work of course. It's just that we do not have resources to do this work as we are focused on other tasks. In addition, I think that it's not a trivial amount of engineering work to integrate this, although that is not my area of expertise. So unfortunately this is just not something that we are in a position to work on.

I like how IntelliJ handles a similar use-case via local history. Rather than showing a tree of actions/unactions, it shows a linear history of a version of a file, not unlike git reflog:

Basically, there's a separate action to show a history of a file, which allows to revert to any version, showing a helpful diff with the current state as well.

What's so hard about this?
Ctrl + Z = undo.
Ctrl + Y = redo.
Ctrl+Shift + Z = Previous Top undo state
Ctrl+Alt + Z = Next Top undo state.
Every time you change undo branch a small popup (showing a tree as illustrated above) on the bottom or right of the page pops up for 500ms and animates your change, then immediately disappears, and ofc, you can turn it off.

@anActualCow that's a good UI suggestion in my opinion.
Unfortunately, there are other technical questions that need to be answered.
Keep the buzz up and hopefully this will get prioritized one day.

Just want to add another voice in support of this request. It's one of my most missed features coming from neovim (w/ Mundo). I honestly, doubt many people even realize that the write & undo experience of an editor could be so much better. Even for nonpower-users this handles the case of accidentally obliterating the redo-history with a miskey-press.

As a long-time Emacs and undo-tree user, and someone who really misses the ability to easily navigate the undo tree, I'm extremely interested and support this feature as well.

This is one of the killer features of Vim; it would be great to have it in VSCode. Sorry for the noise, but I want to add my voice to the chorus.

Could the the new Timeline view be used to support this feature? Or does Timeline it only support "path graphs" (aka linear graphs), i.e. graphs with one predecessor and  one successor?
Note that the "undo graph" (aka "history graph" aka "undo branches") is usually at least a tree, if not a general graph (if we assume a graph where any nodes with the same text collapse into one node)

Ohhhh yes, please do consider adding the tree view like in Emacs as mentioned by @Zalastax and @amelio-vazquez-reina . It's super intuitive and allows you write and rewrite code much more easily, because you know that what you wrote before can always be retrieved. It's a bit like a git commit for every keystroke. :-) :-) :-)

@thijsbro If you are interested in this feature, I recommend watching / following up on #84297  as well since the new Timeline view as I mentioned above could potentially help here :)

@amelio-vazquez-reina thanks.  Really wanting this feature

@alexdima and @stevencl do we still have technological challenges for implementing this, like LiveShare? I see that https://github.com/MicrosoftDocs/live-share/issues/7 is closed. Let me know if you want to have a second go at this. I think it would bring a lot of value.

I'd like propose another shortcut. Undo/Redo shortcuts should work linearly as they do now. Editor should know which branch the user has backtracked from and upon redoing should go back to it. But have an additional shortcuts to cycle through branches. So one for up and one for down. Pressing these shortcuts will take you leaf nodes of sibling branches.
Summary of shortcuts:

cmd+. z = Undo
cmd + shift + z = Redo
ctrl+alt+cmd+down = Change to previous branch
ctrl+alt+cmd+up = Change to next branch
ctrl+alt+cmd+p = Mark branch to come
ctrl+alt+cmd+[ = Jump to marked branch (for easy jumping back to branch you are actually using)

This doesn't require GUI, GUI is nice to have but not required.
Visual Explanation

There is some vagueness in ordering branch by last modified, probably best figured out by testing it

Local history is now in the timeline.
I think if we enhanced local history to include undo tree, there is a unified ux.
The undo tree would get collapsed into new local history items periodically

Just wanted to add my support for this feature. It's not often used, but very useful when it is.

As a potentially helpful reference, this is the code for the undo feature in neovim: https://github.com/neovim/neovim/blob/master/src/nvim/undo.c

orpheuslummis Gold mine, Thanks

I wanted to voice my support for this as well, there is a lot that is appealing but ultimately there are still bits like this that are missing and I keep finding myself going back to neovim, (neo)vim has undo trees built in, mundo (among other plugins) gives a helpful UI. This may not be a commonly used feature but I would argue that it should be more often and it's definitely one that should be available to those who want to use it.

I'd like to add my support for this feature. I would argue that this feature would be very widely used for a variety of reasons. I would use this feature multiple times a day, possibly hourly for work and personal use. It's something that not only already exists in other IDEs, but also CAD tools from AutoDesk like Affinity, and it's an incredibly helpful feature when you're debugging, or troubleshooting.

I'd like to add my support for this feature. I would argue that this feature would be very widely used for a variety of reasons. I would use this feature multiple times a day, possibly hourly for work and personal use. It's something that not only already exists in other IDEs, but also tools from AutoDesk like Affinity, and it's an incredibly helpful feature when you're debugging, or troubleshooting.

I'd like to add my support for this feature. I would argue that this feature would be very widely used for a variety of reasons. I would use this feature multiple times a day, possibly hourly for work and personal use. It's something that not only already exists in other IDEs, but also tools from Serif like Affinity, and it's an incredibly helpful feature when you're debugging, or troubleshooting.

Given the interest here I wanted to mention an idea I had for implementing undo tree as a standalone utility which I made a a separate gist for. Basic idea is to create an undo tree with some clever git usage.
If anyone wants to discuss the idea please do so there as it is not germane to this thread.

Just want to chime in my support for this feature. I think undo trees can be extremely useful!

just use nvim

+1 for this feature! this is still missing in 2024

this the only thing i miss from vim please heavily consider this !

It's been a while but super keen to see this implemented!


*Game Rules
-Players: The game is suitable for 2 players.
-Objective: Players take turns saying English words that start with the last letter of the previous word. The player who cannot come up with a valid word or repeats a word that has already been used loses the game.
**How to Play:
-Player 1 says any English word.
-Player 2 must say a new word that starts with the last letter of the previous word.
-Continue in this manner until one player cannot come up with a valid word.
***Reward Rules
-Setup: Before starting the game, the rewards are determined and agreed upon by the players. The reward is Klaytn coins agreed upon by the players.
-Conclusion: The losing player does not receive the reward. The winning player claims the entire agreed-upon reward.

Interesting take. Approved to proceed with making the game.


customize the OpenAI API URL

Hello,
May I ask if there is a simple way to customize the OpenAI API URL, as some regions cannot access OpenAI services?
like this:
export OPENAI_BASE_URL={XXX}
Or add to config.py
Thank you!

Hey @stan1233 can you please share more or an example of how you expect this to work? We're using Langchain for this

You should be able to achieve the same by passing the OPENAI_API_BASE env var. Lmk that it works for you

@stan1233 Hi, Luo, I got the same situtation with you. How did you customize the OpenAI URL with "https://xxxxx.com/v1"? Did you get it?


gitignore: Add temporary editor files

.idea stores settings for PyCharm, ~ files are temporary files e.g. used
by gedit. .swp is used by vim. We don't want any of those to be
accidentally committed in the repo.

Ok to merge


fix: adjust default process timeout to 1 minute (previously 15 seconds)

这个 PR 实现什么功能/修复什么问题:
修正：调整缺少请求超时时间从15秒为60秒（1分钟）
是否需要 backport 到之前的 release 分支:

release/2.10.0
release/2.11
release/2.12

/area util

Codecov Report

Merging #2998 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #2998   +/-   ##
======================================
  Coverage    7.05%   7.05%
======================================
  Files         477     477
  Lines       76443   76443
======================================
  Hits         5396    5396
  Misses      70595   70595
  Partials      452     452

Flag
Coverage Δ

#aFlag
7.05% <ø> (ø)
:arrow_up:

Impacted Files
Coverage Δ

pkg/appsrv/appsrv.go
48.16% <ø> (ø)
:arrow_up:

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 921db0c...50fefac. Read the comment docs.

/approve
/lgtm


autoload cursor definitions

TL;DR SUMMARY
With this change, any subclass of pieces with a "lib/cursor.js" will automatically load it. This includes project level.
It must export a moog definition (an object with construct or perhaps afterConstruct functions). The cursor is "self" in these functions. In other words it looks just like a module "index.js" file.
No "extend" property is required, unless you're actually looking to avoid extending the usual thing.
Boom!
No overriding "self.find", no calling "apos.define". Nuttin. It just works.
This addresses the pain point of remembering how to apos.define and require cursors, the one thing we frequently have to manually define on the server side, every time we want to add filters. I think this has been one of the reasons why folks have been slow to stop adding filters in find, which is wrong (it breaks pagination).
BC BREAK
This impacts all the projects that are defining cursors the hard way, or requiring a cursor.js file from find() calls. But the former is unnecessary work and the latter is wrong (it breaks pagination). So let's just fix them. I have fixes standing by for the blog, events, and places modules, plus sci center and urban engineering. I will walk everybody through anything that comes up with this; I really want to land it for 2.x.
IMPORTANT TO KNOW
"So what is cool to do in an override of a find method?
It is OK to CALL filters there, but you should NEVER ADD filters there. Do that in cursor.js.
You know what's better though? Call those filters in afterConstruct in your cursor.js. Don't bother overriding find.
"What if I need access to my module in my filters?"
You can get at the module from the cursor:
self.options.module
HOW MUCH DO YOU TRUST THE CODE?
I tested the code pretty thoroughly. I'm more interested in buy-in for making this change. I feel strongly enough about it that I think we should do it before publishing 2.0. It would definitely be a "3.0" BC break if we didn't.
MORE ANTICIPATED QUESTIONS
"What about other doc type managers?"  Correct, this is actually for all doc type managers, but most folks are generally familiar only with pieces.
"What if your parent class also has a cursor.js?" They both work, they extend like you hope they do.
"So if I put cursor.js in pieces..." Yes, you can have a lib/modules/apostrophe-pieces/lib/cursor.js and that affects all pieces.
"Do I have to have an index.js for the module?" No, you don't have to have an index.js for the module at all, it still just works.
"Is this a special snowflake one-off pattern to clutter up our world?" Nope! If you want to create a cool new "related type" like cursors for your module, check out the new "defineRelatedType" and "createRelatedType" methods, now available on all modules. These kill the weirdness of defining and creating cursors and other things that are objects, but are not modules. You get snazzy autoloading of definitions, just like for cursors.
"What about pages?" Pages break out of this pattern, for reasons (they are loaded by apostrophe-pages-cursor, they are of many different types, it's a bad assumption to think their own cursor will get used).
"What about adding methods to ALL cursors? Even the generic apostrophe-cursor that doesn't care about types at all?" Wow, you really have been paying attention. Yes, we do that sometimes, but it's a big deal and I think explicitly calling apos.define('apostrophe-cursor', require(...)) makes sense for such a momentous occasion.

Here is the corresponding PR for science center, so you can see how simple it is to be compatible with the change:
https://github.com/punkave/science-center/pull/186/commits/e64ad3c83cf97f6bf049e341cf656436cc0cfade

👍


How to cache NDK build directories?

Workflow link: https://github.com/RoyalWizard/Telegram/blob/master/.github/workflows/build.yml
This project (https://github.com/RoyalWizard/Telegram/) has a huge NDK build step when we do gradle build (approx 1 hour it takes). Is there any way to cache the NDK build output folder? (TMessagesProj/.cxx and TMessagesProj/build )
Also one doubt, Is there any image which had gradle and NDK installed by default?

Update even the caching of gradle and ndk is not working in this workflow. Is the code wrong for it?

Hi @omkarnathsingh,
Looking at https://github.com/RoyalWizard/Telegram/actions I only see the Action was triggered once and the logs show the caches being created.  The creation of the cache shows up in the "Post Cache Step" which appears separately in the logs.  See the screenshot below:

The next time you run the action, you should see the cache restore.  There's a "re-run jobs" button in the top-right corner that will let you do this without creating another commit.

Hi @dhadka ,
Thanks for looking into it. I retried it again and yes it worked. Gradle and NDK it took from cache. Thanks.
Can you provide solution for main issue as well? caching the build directory? It will save me 1 hour

I think to cache the build outputs you would need to use a key that was either based on a hash of the source files, or perhaps more simply, use the run_id.
  uses: actions/cache@v2
  with:
    path: TMessagesProj/build
    key: ${{ runner.os }}-build-${{ github.run_id }}
    restore-keys: ${{ runner.os }}-build-

This should restore the build artifacts from the previous run while always creating a new cache with the generated build artifacts.

Thanks, I will try this approach


Minor bugfixes for the BoomerAMG elasticity options

A user got a new seg fault when updating Hypre from v2.19.0 to v2.26.0. We narrowed it down (with the help of @tzanio) to the interp_refine option in SetElasticityOptions.
While looking around, I also noticed that this method did not use the correct ordering for the SetSystemsOptions call.

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#3772
@jamiebramwell
@tzanio
@psocratis + @tzanio + @bslazarov
7/11/23
11/28/23
⌛due 8/1/23

PR Checklist

[ ] Code builds.
[ ] Code passes make style.
[ ] Update CHANGELOG:

[ ] Is this a new feature users need to be aware of? New or updated example or miniapp?
[ ] Does it make sense to create a new section in the CHANGELOG to group with other related features?

[ ] Update INSTALL:

[ ] Had a new optional library been added? If so, what range of versions of this library are required? (Make sure the external library is compatible with our BSD license, e.g. it is not licensed under GPL!)
[ ] Have the version ranges for any required or optional libraries changed?
[ ] Does make or cmake have a new target?
[ ] Did the requirements or the installation process change? (rare)

[ ] Update continuous integration server configurations if necessary (e.g. with new version requirements for each of MFEM's dependencies)

[ ] .github
[ ] .appveyor.yml

[ ] Update .gitignore:

[ ] Check if make distclean; git status shows any files that were generated from the source by the project (not an IDE) but we don't want to track in the repository.
[ ] Add new patterns (just for the new files above) and re-run the above test.

[ ] New examples:

[ ] All sample runs at the top of the example source file work.
[ ] Update examples/makefile:

[ ] Add the example code to the appropriate SEQ_EXAMPLES and PAR_EXAMPLES variables.
[ ] Add any files generated by it to the clean target.
[ ] Add the example binary and any files generated by it to the top-level .gitignore file.

[ ] Update examples/CMakeLists.txt:

[ ] Add the example code to the ALL_EXE_SRCS variable.
[ ] Make sure THIS_TEST_OPTIONS is set correctly for the new example.

[ ] List the new example in doc/CodeDocumentation.dox.
[ ] If new examples directory (e.g.examples/pumi), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add example-specific documentation, see e.g. the src/examples.md.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] In examples.md, list the example under the appropriate categories, add new categories if necessary.
[ ] Add a short description of the example in the "Extensive Examples" section of features.md.

[ ] New miniapps:

[ ] All sample runs at the top of the miniapp source file work.
[ ] Update top-level makefile and makefile in corresponding miniapp directory.
[ ] Add the miniapp binary and any files generated by it to the top-level .gitignore file.
[ ] Update CMake build system:

[ ] Update the CMakeLists.txt file in the miniapps directory, if the new miniapp is in a new directory.
[ ] Add/update the CMakeLists.txt file in the new miniapp directory.
[ ] Consider adding a new test for the new miniapp.

[ ] List the new miniapp in doc/CodeDocumentation.dox
[ ] If new miniapps directory (e.g.miniapps/nurbs), add it to MINIAPP_SUBDIRS in the makefile.
[ ] If new miniapps directory (e.g.miniapps/nurbs), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add miniapp-specific documentation, see e.g. the src/meshing.md and src/electromagnetics.md files.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] The miniapps go at the end of the page, and are usually listed only under a specific "Application (PDE)" category.
[ ] Add a short description of the miniapp in the "Extensive Examples" section of features.md.

[ ] New capability:

[ ] All new public, protected, and private classes, methods, data members, and functions have full Doxygen-style documentation in source comments. Documentation should include descriptions of member data, function arguments and return values, template parameters, and prerequisites for calling new functions.
[ ] Pointer arguments and return values must specify whether ownership is being transferred or lent with the call.
[ ] Any new functions should include descriptions of their intended use e.g. for internal use only, user-facing, etc., along with references to example code whenever possible/appropriate.
[ ] Consider adding new sample runs in existing examples to highlight the new capability.
[ ] Consider saving cool simulation pictures with the new capability in the Confluence gallery (LLNL only) or submitting them, via pull request, to the gallery section of the mfem/web repo.
[ ] If this is a major new feature, consider mentioning it in the short summary inside README (rare).
[ ] List major new classes in doc/CodeDocumentation.dox (rare).

[ ] Update this checklist, if the new pull request affects it.
[ ] Run make unittest to make sure all unit tests pass.
[ ] Run the tests in tests/scripts.
[ ] (LLNL only) After merging:

[ ] Update internal tests to include the new features.

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

Merged in next for testing...

@jamiebramwell, can you confirm that the change in https://github.com/mfem/mfem/pull/3772/commits/d6c7698712ce0c6c7249708478d38a7e41589e48 is acceptible?
(You will have to call SetElasticityOptions(fespace, false) for the cases where the solver crashes)

Re-merged in next for testing...

That change works for me! Thanks!

thanks @psocratis !


Test Bearer token expired

Describe the bug
The JWT Bearer token used in tests expired October 17.
To Reproduce
Run any test  using the Bearer token provided.
Expected behavior
Token should be valid.

Tests were updated in 0.6.1 to use on the fly generated tokens to avoid expiry in the future. All tokens expire 2 hours after initial test run.


Respect core.hooksPath

git lfs install currently puts pre-push into .git/hooks no matter the value of core.hooksPath.
https://github.com/github/git-lfs/blob/c21de411141a7536689a63e1f82bcc02f46fdf83/lfs/hook.go

Thanks for the report. Should be relatively easy to fix in v1.3.1.

@danielbayley Thanks again for opening this. If you install Git LFS v1.3.1, this behavior is now supported. Enjoy! 😄

@ttaylorr @technoweenie That was fast… nice one 👍 I think the Homebrew formula will need a bump first though…

@danielbayley it should be in Homebrew-core as soon as https://github.com/Homebrew/homebrew-core/pull/3551 is merged 😄


Update Kudu to consume VSO web hook payload.

Deployment trace:
<step title="Incoming Request" date="2015-07-06T23:56:41.533" instance="cd11c9" url="/deploy?scmType=VSO" method="POST" type="request" pid="29184,2,10" Connection="Keep-Alive" Content-Length="2934" Content-Type="application/json; charset=utf-8" Expect="100-continue" Host="kudutry.scm.azurewebsites.net" X-SITE-DEPLOYMENT-ID="kudutry" >
    <step title="FetchHandler" date="2015-07-06T23:56:41.548" >
        <step title="Attempting to fetch target branch master" date="2015-07-06T23:56:41.564" />
        <!-- duration: 0ms -->
        <step title="Assuming git repository at D:\home\site\repository" date="2015-07-06T23:56:41.611" />
        <!-- duration: 0ms -->
        <step title="Performing fetch based deployment" date="2015-07-06T23:56:41.689" >
            <step title="Creating temporary deployment" date="2015-07-06T23:56:41.705" />
            <!-- duration: 62ms -->
            <step title="DeploymentManager.Deploy(id)" date="2015-07-06T23:56:44.361" >
                <step title="Collecting changeset information" date="2015-07-06T23:56:44.377" />
                <!-- duration: 78ms -->
                <step title="Updating submodules" date="2015-07-06T23:56:44.455" />
                <!-- duration: 94ms -->
                <step title="Determining deployment builder" date="2015-07-06T23:56:44.970" >
                    <step title="Builder is BasicBuilder" date="2015-07-06T23:56:45.080" />
                    <!-- duration: 31ms -->
                </step>
                <!-- duration: 172ms -->
                <step title="Copying SSH keys" date="2015-07-06T23:56:45.189" />
                <!-- duration: 0ms -->
                <step title="Building" date="2015-07-06T23:56:45.205" >
                    <step title="Generating deployment script" date="2015-07-06T23:56:45.314" >
                        <step title="Using cached version of the deployment script for command: -y --no-dot-deployment -r "D:\home\site\repository" -o "D:\home\site\deployments\tools" --basic --sitePath "D:\home\site\repository"" date="2015-07-06T23:56:45.330" />
                        <!-- duration: 0ms -->
                    </step>
                    <!-- duration: 63ms -->
                    <step title="Executing external process" date="2015-07-06T23:56:45.501" type="process" path="starter.cmd" arguments=""D:\home\site\deployments\tools\deploy.cmd"" />
                    <!-- duration: 2812ms -->
                </step>
                <!-- duration: 3578ms -->
            </step>
            <!-- duration: 4422ms -->
            <step title="Cleaning up temp files" date="2015-07-06T23:56:48.798" />
            <!-- duration: 0ms -->
            <step title="WebHooksManager.PublishEventAsync: PostDeployment" date="2015-07-06T23:56:48.830" />
            <!-- duration: 31ms -->
        </step>
        <!-- duration: 7500ms -->
    </step>
    <!-- duration: 7656ms -->
    <step title="Outgoing response" date="2015-07-06T23:56:49.220" type="response" statusCode="200" statusText="OK" Server="Microsoft-IIS/8.0" Cache-Control="private" X-AspNet-Version="4.0.30319" />
    <!-- duration: 0ms -->
</step>
<!-- duration: 7719ms -->

Would that allow one to easily deploy an Azure WebApp from VSO hosted code (cf. https://github.com/projectkudu/kudu/wiki/VSO-vs-Kudu-deployments#can-i-host-my-git-repo-on-vso-and-have-kudu-build-it)?

@nulltoken that is the plan. not there yet.

@nulltoken that is the plan. not there yet.

@shrimpy  What are the next steps to see this live? (cough asking for a friend :wink: cough)

@nulltoken there is still some work we need to do outside Kudu with the VSO team. And then there is UI work for it to show up in the portal. We'll get there! :)

@davidebbo :heart_eyes: Any chance yuu may update this thread when it's ready to go?

Yes, we shoud do that. There should be a point where it's usable in the backend but with no portal UI, and that would be enough for you to play around.

@davidebbo :beers: :bangbang:

@davidebbo Any update regarding this? :pray:

Yep, that's been there for a while now! See https://github.com/projectkudu/kudu/wiki/Setting-up-a-VSTS-account-so-it-can-deploy-to-a-Web-App for tips on avoiding common issues.


Draft: Add cross page reference text resolving mechanism

This commit adds a feature that allows the resolving of reference texts across pages.
TBD
closes  #17

Hi @tobiasah , excellent, works perfectly. Thanks a lot!


Testing Container for Back-End (#35, #36)

Description of PR

Created an additional container that injects custom bgp updates on the rabbitmq consumers and checks the output of detection and all database inserts/updates.
Closes #35
Closes #36
What component(s) does this PR affect?

[x] Back-End (Database, Microservices, Containers, etc)
[ ] Front-End (Flask, API, etc)
[ ] Docs
[x] Build System

Does the PR require changes on other components? If yes, please mark the components:

[ ] Back-End (Database, Microservices, Containers, etc)
[ ] Front-End (Flask, API, etc)
[ ] Docs
[ ] Build System

Related Issue

#35 #36
Solution

Type

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Docs update
[ ] None of the above

Checklist:

[x] I have read the contributing guide and my code conforms to the guidelines.
[x] This change requires a change in the documentation.
[x] I have updated the documentation accordingly.

@slowr also do not forget to update the CHANGELOG with your changes regarding testing (before merging). To avoid multiple commits, please also do the following changes on the CHANGELOG file:
Move "Bumped PyYAML from 3.13 to 4.2b4 in /backend" from "Changed" to "Security"
Move "Bumped PyYAML from 3.13 to 4.2b4 in /frontend" from "Changed" to "Security"
And add the new testing backend features (with sempahore, etc.) to the "Added" section
I would advise documenting somewhere in the wiki how one can add a new test.
You can edit: https://github.com/FORTH-ICS-INSPIRE/artemis/wiki#adding-new-artemis-tests


Flattened the color/dark mode settings

What

Removed the shadow of the widgets for changing darkmode and color theme of the app in the user preferences screen

Screenshot

Fixes bug(s)

#919

Part of

https://github.com/openfoodfacts/smooth-app/issues/919
(please be as granular as possible)

@sgayangi : the CHANGELOG is generated automatically, as long as your Pull Request is semantic


` breaks TS coloring

Solving Issue #84

Hi @anubmat, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Anubha Mathur). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

I don't think this is the correct fix. Let's discuss offline.


better handling of bad paths

currently providing bad paths will likely give you a TypeError, paths should be checked at instantiation and a meaningful error raised.

resolved in #54


Wait on local-cluster delete before deleting cluster-manager

Jira: https://issues.redhat.com/browse/ACM-2782
After code cutoff. Requires approval.
Signed-off-by: Jakob Gray<EMAIL_ADDRESS>

/lgtm


Add information about the general dev approach

While it is implicitly clear in some places, the general difference between extending and changing the base application is not explained explicitly. To make this crystal clear for everyone, I would like to see this as part of the document

Thanks for your contribution, it makes good sense to update this document as well.

@SusanneWindfeldPedersen perfect, thanks a lot. I already knew this some time ago but forgot: How long does it take for a change to appear on the website after you push to live?

Hi @tfenster - this is submitted through the public repo and we'll have to refresh our private repo with your PR, then I will push it live, so within the next hour or so. Thanks.


Please provide license

Please provide license, thank you

@activestidle the license is updated and now also published on pub.dev


Ground-truth labels on my dataset

Hi, authors
if I want train the model on my own dataset, how can I get the Ground-truth label.
I see you said 'We use dense depth maps and camera parameters to compute ground-truth correspondences. The depth maps are provided by depth sensor (ScanNet) and MVS system (MegaDepth).'    the camera parameters is ?

Hi,
The ground-truth correspondence label is calculated on-the-fly. What you need to provide is the dense depth map and camera parameters.
And there are extrinsic parameters (i.e. relative R, t that reveal camera motion) and intrinsic parameters (focal length, principal point that reveal projective distortion).

thanks, Does the camera parameter refer to the real transformation matrix or other parameters?

I'm not sure about what you're referring to. Maybe this opencv documentation would help you!

thank a lot!

I have a small question, whether it is possible to train the model with only one data set and only use the MegaDepth data set. Is it necessary to provide only the depth map without the camera pose parameters?
In the code, the data processing part：
def _build_concat_dataset(
    self,
    data_root,
    npz_names,
    npz_dir,
    intrinsic_path,
    mode,
    min_overlap_score=0.,
    **pose_dir=None**
):
    datasets = []
    augment_fn = self.augment_fn if mode == 'train' else None
    data_source = self.trainval_data_source if mode in ['train', 'val'] else self.test_data_source
    if str(data_source).lower() == 'megadepth':
        npz_names = [f'{n}.npz' for n in npz_names]
    for npz_name in tqdm(npz_names,
                         desc=f'[rank:{self.rank}] loading {mode} datasets',
                         disable=int(self.rank) != 0):
        # `ScanNetDataset`/`MegaDepthDataset` load all data from npz_path when initialized, which might take time.
        npz_path = osp.join(npz_dir, npz_name)
        **if data_source == 'ScanNet':**
            datasets.append(
                ScanNetDataset(data_root,
                               npz_path,
                               intrinsic_path,
                               mode=mode,
                               min_overlap_score=min_overlap_score,
                               augment_fn=augment_fn,
                               **pose_dir=pose_dir))**
        **elif data_source == 'MegaDepth':**
            datasets.append(
                MegaDepthDataset(data_root,
                                 npz_path,
                                 mode=mode,
                                 min_overlap_score=min_overlap_score,
                                 img_resize=self.mgdpt_img_resize,
                                 df=self.mgdpt_df,
                                 img_padding=self.mgdpt_img_pad,
                                 depth_padding=self.mgdpt_depth_pad,
                                 augment_fn=augment_fn,
                                 coarse_scale=self.coarse_scale))
        else:
            raise NotImplementedError()
    return ConcatDataset(datasets)

When processing the MegaDepth data set, there is no camera pose parameter

Yes, we train indoor model with scannet dataset only, and outdoor model with megadepth only.
The data organization is not the same. For megadepth, intrinsic and extrinsic parameters are in npz.
Check this:
https://github.com/zju3dv/LoFTR/blob/261baf641cb9ada07dd9746e420ada7fe8a03152/src/datasets/megadepth.py#L92


⚠ Jerry Savelle Ministries International Australia has degraded performance

In eb9a7e9, Jerry Savelle Ministries International Australia (https://jsmiaustralia.org) experienced degraded performance:

HTTP code: 200
Response time: 9644 ms

Resolved: Jerry Savelle Ministries International Australia performance has improved in 8b98b7c after 1 hour, 7 minutes.


[Bug report] Default theme: unexpected rem in styles

Bug report
Description
I saw v1 use only padding in styles/code, this line split to margin and padding in v2, and an unexpected character rem was left. Is it on purpose?
https://github.com/vuepress/vuepress-next/blob/55f780c4a516b2c0119328874906647af80ac73b/packages/%40vuepress/theme-default/src/styles/_variables.styl#L29
https://github.com/vuepress/vuepress-next/blob/16d5686db3eab17bbc248f7ce9ceb6703c479fcc/packages/%40vuepress/theme-default/src/styles/code.styl#L105-L106
It works well now, stylus use it to override the unit of variable. However, if user set it with a different unit, this may cause an error:
// stylus
$lineNumbersWrapperWidth: 3.5px;
margin-left: $lineNumbersWrapperWidth rem;

// compiled css
margin-left: 3.5rem;

Or eject default theme and change it to scss/less:
// scss
$lineNumbersWrapperWidth: 3.5px;
margin-left: $lineNumbersWrapperWidth rem;

// compiled css
margin-left: 3.5px rem;

Steps to reproduce
None
Expected behavior
Delete rem:
margin-left: $lineNumbersWrapperWidth;

Screenshots
None
Environment info
<EMAIL_ADDRESS>

Should be a typo


[BUG]: A JavaScript error occurred in the main process after update to 1.6.3 v

How are you running AnythingLLM?
AnythingLLM desktop app
What happened?
I am getting this bug after update to 1.6.3 desktop version, when try open a workspace:

Now my client keep freezing!! it need be fixed with urgency guys!
Thank u very much!
Are there known steps to reproduce?
No response

What OS are you on? Linux?

Patched, download again from the bucket/installer script now

Patched, download again from the bucket/installer script now

thank u very much bro, love you !!!


Collapse.js v4 only toggles one target?

http://www.bootply.com/1lBIRBwnA0
This example, using Bootstrap v3, properly shows the two hidden rows when clicking the first plus button.
The same markup using the v4 source only toggles the first row.

Hi @thecristen!
You appear to have posted a live example (http://s.bootply.com/render/1lBIRBwnA0), which is always a good first step. However, according to the HTML5 validator, your example has some validation errors, which might potentially be causing your issue:

line 56, column 11 thru column 175: The aria-controls attribute must point to an element in the same document.

You'll need to fix these errors and post a revised example before we can proceed further.
Thanks!
(Please note that this is a fully automated comment.)

@fat Is this intentional?

I also ran into this problem. Here's another short example...
Working in v3
Broken in v4

Has anyone found any workarounds for this issue?

v3 was selecting all targets where as v4 is selecting only the first target which explains the difference in behavior.
As I started to refactor v4 to act like v3, the decision to only select the first target seems intentional. In v3, the data used to determine whether to toggle or instantiate is based off only the first element ($target.data('bs.collapse') is really doing $target.first().data('bs.collapse')). The state of your first target is going to be used for every target which could introduce problems. With the v4 implementation, that isn't left to chance.

Has anyone found any workarounds for this issue?

You could use the hide.bs.collapse event and some mix of show/hide calls to recreate the behavior in v4.

The state of your first target is going to be used for every target

@maxbeatty - Maybe I'm misunderstanding what you're saying, but it seems like this v3 example contradicts what you're saying. There are two divs and their toggle states are opposite one another. Any button click shows the hidden div and hides the visible div.
I can achieve the same thing in v4 but I have to use javascript. It's just really nice to accomplish this without scripting.

I don't have a dog in this fight. I could have misunderstood the code and intentions. I was mainly trying to help with v4 issues 🚂

There are two divs and their toggle states are opposite one another.

Before any clicks, those two divs are plain HTML divs with CSS classes dictating their appearance.

On that first click, the first div is asked for data about 'bs.collapse'. There isn't any because it's new (hasn't been used by collapse yet) so the plugin is called with the click event target's data and each data-target uses those options.
Each div has no existing data for 'bs.collapse' so each is instantiated.
The default is to toggle so at the end of each instantiation, toggle is called
toggle calls hide or show based on the element having the in class which is why your "Delete" button hides and your "Yes/No" buttons show.

If in v3 your second div is already instantiated for some reason or another, it behaves the same as v4 https://jsfiddle.net/bnz8sa2L/1/
My outsider opinion is that it's better to declare the behavior as you need to in v4 than to depend on assumptions about how it'll behave like in v3

I ran into the same issue. I'd like to toggle all targets and not the first one. This is the whole point in using CSS selectors... This is how I hacked a fix for it:
--- a/public/js/bootstrap.js
+++ b/public/js/bootstrap.js
@@ -1284,7 +1284,10 @@ var Collapse = (function ($) {
         var selector = '[data-toggle="collapse"][data-parent="' + this._config.parent + '"]';

         $(parent).find(selector).each(function (i, element) {
-          _this6._addAriaAndCollapsedClass(Collapse._getTargetFromElement(element), [element]);
+          var element = element;
+          Collapse._getTargetsFromElement(element).each(function() {
+            _this6._addAriaAndCollapsedClass(this, [element]);
+          });
         });

         return parent;
@@ -1305,10 +1308,10 @@ var Collapse = (function ($) {
       // static

     }], [{
-      key: '_getTargetFromElement',
-      value: function _getTargetFromElement(element) {
+      key: '_getTargetsFromElement',
+      value: function _getTargetsFromElement(element) {
         var selector = Util.getSelectorFromElement(element);
-        return selector ? $(selector)[0] : null;
+        return $(selector ? selector : []);
       }
     }, {
       key: '_jQueryInterface',
@@ -1353,11 +1356,14 @@ var Collapse = (function ($) {
   $(document).on(Event.CLICK_DATA_API, Selector.DATA_TOGGLE, function (event) {
     event.preventDefault();

-    var target = Collapse._getTargetFromElement(this);
-    var data = $(target).data(DATA_KEY);
-    var config = data ? 'toggle' : $(this).data();
-
-    Collapse._jQueryInterface.call($(target), config);
+    var $this = $(this);
+    var targets = Collapse._getTargetsFromElement(this);
+    targets.each(function() {
+           var data = $(this).data(DATA_KEY);
+           var config = data ? 'toggle' : $this.data();
+
+           Collapse._jQueryInterface.call($(this), config);
+    })
   });

   /**

The patch is against the final bootstrap.js file.

I'd definitely welcome a PR to address this in our next alpha. Having multiple targets trigger the same collapse element would be awesome.

X-ref #21692