text:
feat: Migrate Docs to the main repo

I think it would be better to integrate the Documentation directly into the package, while ignoring it when publishing.
The only issue is that it will run the development version of Aplos always, any changes to the source will update the docs, that could lead to breaking it.  An option would be to just use the stable version rather then the development, but I will look into it.

Other projects  like https://github.com/vitejs/vite  and even VitePress already do this, so I don't see why not

I don't think I will push any breaking changes to Aplos while developing. Rather it would be great to see it live, and updating docs would be better. I give it an :+1:

Should be ready. Last steps are to update Codeberg Pages

repo: aplosdev/aplos


text:
Document the purpose of package alias names

The usage of alias names has certain implications that should be explicitly documented.

Documented in version 0.109.0

source: gharchive/issue

repo: aplteam/Tatin

license: MIT

license_type: permissive

license_source: github-api


text:
How to know that the image has been loaded, when i use docker.loadImage?

How to know that the image has been loaded?
docker.listImages in callback, get a null array.

We got the same question. Did you find an answer?

Here is working example.  results can have errors as well.
  loadImageFromStream(stream: NodeJS.ReadableStream): Promise<any[]> {
    return new Promise((resolve, reject) => {
     docker.modem.followProgress(stream, (err, results) => {
        if (err) {
          reject(err);
        } else {
          if (results?.length) {
            const [result] = results;
            if (result.error) {
              reject(new Error(result.error));
            } else {
              resolve(result);
            }
          } else {
            resolve(results);
          }
        }
      });
    });
  }

repo: apocas/dockerode

license_source: bigquery


text:
Write simple arrays to store

Currently there is an issue with writing simple arrays to the store. Arrays of objects work fine ([{}, {},]), but arrays of strings do not (['one', 'two',]). It throws this error:
TypeError: Cannot read property 'selections' of null

I played around in the tests, and it seems there is no issue reading an array of strings from the store once it is in there.
This seems like something it should support, and I'm going to work on a solution. Let me know if it's not. Thanks!

Yeah that makes sense! Just an oversight. Probably step 1 is to write a failing test for this case.

@stubailo already on it :)

This might mean we don't read those out of the store properly either, since the tests usually do both.

If you're going to work on it, please assign the issue to yourself!

@stubailo It doesn't look like I have permission to do that, but feel free to assign me

Just added you, and I made @jbaxleyiii an admin so that he can add additional collaborators if necessary!

Thanks!

@johnthepink this is fixed yes?

@jbaxleyiii yessir. Closed via #66

authors: jbaxleyiii johnthepink stubailo

repo: apollostack/apollo-client

license: mit


text:
#1: add support for horses in database initialization

add hourse in database

/paulo - can you please review this pull request?

/paulo - can you check now?

source: gharchive/pull-request


text:
Better Login/Signup buttons

Description
The current Login or Register buttons do not seem clickable. I would like to make them appear clickable by changing their appearances when the user hovers on them. Please assign me this issue.
Screenshots
No response
Additional information
No response

@kaashikaagrawal They work fine from my side

authors: apoorvaron kaashikaagrawal

repo: apoorvaron/Shorty


text:
Reform throws exception when using I18n error message lookup in custom validation method (but works with lambda)

Hello,
when I use custom validations in a form and rely on the error message lookup of I18n, an exception is thrown. Minimal example (leaving out any actual validation logic):
class UserForm < Reform::Form
  property :email

  # this works
  validate ->{ errors.add :email, :taken }

  # this doesn't  O_o
  validate :uniqueness_of_email
  def uniqueness_of_email
    errors.add :email, :taken
  end
end

UserForm.new(User.new).validate({email: "foo@example.com"})

As commented in the example, when I use a lambda for the validation, it works as expected. But when I use a method, it blows up with:
NoMethodError: undefined method `lookup_ancestors' for UserForm:Class

#lookup_ancestors is defined in the ActiveModel::Translation module, but including it in the form doesn't help.
I have absolutely no idea what is going wrong. This is a new bug in Reform 2.0. Before the update both ways worked as expected.

Additional info:
(1) Using a block also works:
validate do
  errors.add :email, :taken
end

(2) Including Reform::Form::ActiveModel doesn't help. It also shouldn't be necessary in my example since it is meant to be in a Rails app. :smirk:

I know where the problem is, thanks!
Can you do me a favour and paste an excerpt from your locale file, too, or even better, setup a small test so I can see how that goes wrong?
In Reform 2, we do not include AM::Validations into the form itself anymore to avoid importing a hundred methods. This is why in your case it can't find that lookup_ancestors class method. I will try to fix it.
BTW - I will push things towards Lotus::Validations (which are allowed in Reform 2) as the standard validation engine since I want to get rid of Rails and it's madness (which is reflected in this ticket ;) ).

The default translation file(s) by Sven Fuchs (https://github.com/svenfuchs/rails-i18n/blob/master/rails/locale/en.yml) will do. I will send you a PR in a minute where I put the default english translation file in the dummy app and added three tests to the test suite. The first test uses validate do ... end and passes. The second test uses validate ->{ ... } and passes too. The third uses validate :custom_validation_message and blows up like in my example above. However, with another exeception this time:
NoMethodError: undefined method `read_attribute_for_validation' for #<ActiveModelCustomValidationTranslationsTest::SongForm::WithMethod:0x007fee0251fcf0>

But my main problem still applies: It works when used with block and lambda, but not with a method.
While Rails is still a great framework, I am also frustrated by the madness you mentioned. But I have to stick with it. Our app is already to complex to port it to Lotus or another framework. I also find Lotus quite promising but not production ready yet. So would it be possible to use the Lotus validations in a Rails app? And speaking of madness: Being a Reform user for two years and an early adopter of Trailblazer, I must say, you gave my fellow programmers and me a rough ride too. :smirk:

Yeah, you can use Lotus validations in Rails, Reform is completely decoupled and can delegate validating to other "backends". All I need to implement is the error message generation in Lotus.
I am not planning to complete leave Rails or anything, I love it as a low-level framework with app templates, migrations, test integration, etc. I just want to use as less as possible from it in my layers due to problems described in this issue.
Oh, and please don't confuse "madness" with "innovation"! I know that many things have changed in all my gems in the last couple of months, but that's why Trb is versioned ZERO.3.x (that's a leading zero, right) and Reform got a major bump.
I don't change APIs and structures to annoy people but to provide a better product - a strategy that Rails should adopt instead of keeping its 10-year old design flaws for the sake of Basecamp.

@tilod Merci! Please run your code against master, it should be fixed.

Good to know about the Lotus validations.
Sorry about the "madness thing". It wasn't meant as an offence. I also was not referring to the frequent changes in the APIs. Of course this can be annoying, but as you said, it's innovation and I'm not really complaining about that.
What I meant is, on the one hand Reform and Trailblazer (and Cells too) are really great and make a lot of things much easier and cleaner to implement. A definite :+1: and keep up the good work. On the other hand, it is really hard to "bend" Reform when the problem doesn't fit perfectly in the scheme you describe in the Trailblazer book and the readmes of the gems. Reform is indeed usable "as is" in most cases, but when I have to tweak it, it makes me curse everytime. That's what I meant with "rough ride". One example: In a nested form you cannot access the parent form from a child form. I had a validation in a child form that depended on a property in the parent form. I haven't found an intented way to do this and the ways I came up with myself were super ugly – which I have to admit could be totally my own fault. I can give you more details (about the problem, not my issues :smirk:) if you are interested, maybe in a feature request.
Thanks for the fix. I will try out on monday when I'm at work.

I recently ran into something similar (parent form)!!!
Why don't you just ask me instead of cursing? :grimacing: Reform is actually not really as "limited" as it might look, and with the extraction of all the model-related code to Disposable, it is easier to understand. Having a reference to the parent should be simple to implement!

Ups, I'm so sorry for removing the database.sqlite3! I misinterpreted the git output and thought it came in with my PR, but I actually just changed it.
Referencing the parent form is something I need more often. I would be very happy to see this feature in Reform. Our domain is quite complex and so are our validations.

I ran master against my code. It works, bug is fixed. Thanks again!

2.0.1, only for you! :wink:

authors: apotonick tilod

repo: apotonick/reform


text:
APPSRE-6370: Update Terraform AWS provider to version 3.76.0

HashiCorp has released a maintenance version of the Terraform AWS provider from the 3.x family, see

CHANGELOG.md
Milestone: v3.76.0

This particular release includes two backported changes that are of particular interest to us, as per:

release/3.x: Migrate from Keybase's Go OpenPGP crypto fork to ProtonMail's
release/3.x: Backport #25768; Remove Computed from apply_immediately

Thus, update the AWS provider to version 3.76.0 as per the upstream release. Note that this version WILL NOT introduce many unexpected changes, as an upgrade to the 4.x family would most certainly, as this is purely a maintenance release that carries no substantial changes.
Related: APPSRE-6370
Signed-off-by: Krzysztof Wilczyński kwilczynski@redhat.com

To the reviewer:
This has been tested locally to ensure that there aren't any changes being introduced.

repo: app-sre/container-images


text:
[tls.3] Go templates for core service stack files

templating for core stack files
see details in https://techweb.axway.com/confluence/display/AMP/Cluster+with+secured+Docker+API
Verification
automated build

superseded by #1802

repo: appcelerator/amp


text:
Question: Mojang account authentication

Is there a way we can add like Cracked or offline Accounts with the code?
and which file do i need to start with? am pretty much newbie in selecting files...

Cracked:
Comment the password field and in username field paste your nickname
Premium:
Fill all fields.

Not planning to support cracked accounts or offline servers. Minecraft isn't that expensive, I think it's only fair to pay for it.

authors: HarryPuttar5832 INotSleep appenz

repo: appenz/minebot


text:
🛑 Staging Panel Apio is down

In 5fe2a90, Staging Panel Apio (https://stagingpanel.appio.com.mx) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Staging Panel Apio is back up in 17cb2b8.

repo: appio-smart-kitchen/upptime


text:
pkl_eval uses the short_path for entrypoints files

With entrypoint.path in use, we'd see the following error when running pkl eval: Failed processing PKL configuration with entrypoint(s).
By using short_path we receive a path that pkl eval can resolve correctly and evaluate.
This fixes #21.

I'll aim to release 0.3.1 once this is merged.


text:
Don’t include internal parameter names in LSP snippets

When translating editor placeholders to snippets, we should not include internal parameter names into the snippet. The problem is that once you leave snippet editing mode (essentially by moving the cursor to any place that’s not the snippet, eg. by typing a string literal for one of the parameters or moving the cursor), all snippets become verbatim text. And then it’s impossible to tell whether paramName:  was an annotation inside the snippet describing the internal parameter’s name or the external parameter label.
And it turns out that we can do this by just using the placeholder parsing from swift-syntax instead of having our own in SourceKit-LSP.
rdar://123772474

https://github.com/apple/swift-syntax/pull/2519
@swift-ci Please test

repo: apple/sourcekit-lsp


text:
Nate/see help messages

This adds some new messages to error and help output that guide users to find more information.
Validation errors now include a message about using --help:
$ roll --bad-flag
Error: Unknown option '--bad-flag'
Usage: roll [--times <n>] [--sides <m>] [--seed <seed>] [--verbose]
  See 'roll --help' for more information.

The help screen now shows a message about the implicit help subcommand when the help screen contains subcommands:
$ math --help
OVERVIEW: A utility for performing maths.

USAGE: math <subcommand>

OPTIONS:
  --version               Show the version.
  -h, --help              Show help information.

SUBCOMMANDS:
  add                     Print the sum of the values.
  multiply                Print the product of the values.
  stats                   Calculate descriptive statistics.

  See 'math help <subcommand>' for detailed help.

Checklist

[x] I've added at least one test that validates that my change is working, if appropriate
[x] I've followed the code style of the rest of the project
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary

@swift-ci Please test

repo: apple/swift-argument-parser


text:
Unify ArgumentDefinition initialization

Removes unused generic ArgumentDefinition initializer. Updates the
non-generic initializer with an additional allValues argument
defaulted to [] to avoid breaking clients. Updates the construction
of ArgumentDefinition in the help path to include forward
allValueStrings to allValues argument if A conforms to
ExpressibleByArgument. Additionally, adds test converage.

Checklist

[x] I've added at least one test that validates that my change is working, if appropriate
[x] I've followed the code style of the rest of the project
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary

Fixes #340

Thanks for this fix, @rauhul! I'd rather go the other way, and make sure the generic parameter is maintained from the property wrapper initializer through to the ArgumentDefinition.init call. This way we're throwing away the ExpressibleByArgument conformance only to look it up again.

@natecook1000 refactored to propagate the constraint, take a look when you have a moment :)

@swift-ci Please test

@swift-ci please test


text:
Update Swift Crypto and fix RSA keys

This updates Swift Crypto to 2.4.0 and fixes RSA key serialization on all platforms. It also adds a defensive check that we only accept appropriately-formatted RSA keys, and some regression tests.

@swift-server-bot test this please

repo: apple/swift-certificates


text:
Fix wrong role assigned to technology-root articles

Bug/issue #, if applicable: #743
Summary
This PR includes a fix for an error that was causing technology root articles to have the wrong role assigned in their render node.
Dependencies
N/A
Testing
Article.docc.zip
Steps:

Download the attached catalog.
Run docc convert Article.docc -o Article.doccarchive.
Within the generated .doccarchive, navigate to data-> documentation-> article.json
Open article.json
In the JSON file, verify the value associated with the key role is collection

For additional testing, you can perform the same steps for a multiple-article-only catalog where the technology root doesn't have a Topics section.
Checklist
Make sure you check off the following items. If they cannot be completed, provide a reason.

[X] Added tests
[X] Ran the ./bin/test script and it succeeded
[ ] Updated documentation if necessary (N/A)

@swift-ci please test

@swift-ci please test

repo: apple/swift-docc


text:
[Swift][test] Disable SwiftInterface REPL tests on Linux due to flakiness

One or the other is failing every so often in CI with Exit Code: 74
Tracking radars:
rdar://problem/53312825 for lit/SwiftREPL/SwiftInterfaceForceModuleLoadMode.test
rdar://problem/53181277 for lit/SwiftREPL/SwiftInterface.test

@swift-ci please test

repo: apple/swift-lldb


text:
[SourceControl] Use stable hash for filesystem ident

rdar://problem/41863472 Use a stable hash for repository directories
For the suffix, we now use first 8 chars of the url's SHA256 hash.
Technically, this can lead to a collision but that shouldn't matter
anyway because we just need a unique suffix.

@swift-ci please smoke test

repo: apple/swift-package-manager


text:
emit information diagnostics for dependency resolution

motivation: provide transperancy / debug information when needed
changes:

add a new dependency resolver that emits debug diagnostics for resover callbacks, wire it into the observability system
this information will only show when running in verbose mode
deprecate TracingDependencyResolverDelegate which was a bespose solution serving the same need
add test

UX:
~/code/swift/sourcekit-lsp ± ● main
❯ ~/code/swift/swift-package-manager/.build/debug/swift-package update --verbose | grep DependencyResolver
info: [DependencyResolver] derived 'swift-argument-parser' requirement '0.4.1..<0.5.0'
info: [DependencyResolver] derived 'yams' requirement '4.0.0..<4.1.0'
info: [DependencyResolver] derived 'swift-crypto' requirement '1.1.4..<1.2.0'
info: [DependencyResolver] resolving 'swift-crypto'
info: [DependencyResolver] resolved 'swift-crypto' @ '1.1.6'
info: [DependencyResolver] resolving 'swift-argument-parser'
info: [DependencyResolver] resolved 'swift-argument-parser' @ '0.4.4'
info: [DependencyResolver] resolving 'yams'
info: [DependencyResolver] resolved 'yams' @ '4.0.6'
info: [DependencyResolver] solved 'yams' (https://github.com/jpsim/Yams.git) at '4.0.6'
info: [DependencyResolver] solved 'swift-argument-parser' (https://github.com/apple/swift-argument-parser.git) at '0.4.4'
info: [DependencyResolver] solved 'swift-crypto' (https://github.com/apple/swift-crypto.git) at '1.1.6'
info: [DependencyResolver] solved 'swift-package-manager' (https://github.com/apple/swift-package-manager.git) at 'main'
info: [DependencyResolver] solved 'swift-tools-support-core' (https://github.com/apple/swift-tools-support-core.git) at 'main'
info: [DependencyResolver] solved 'sourcekit-lsp' (/Users/tomerd/code/swift/sourcekit-lsp) at 'unversioned'
info: [DependencyResolver] solved 'swift-driver' (https://github.com/apple/swift-driver.git) at 'main'
info: [DependencyResolver] solved 'indexstore-db' (https://github.com/apple/indexstore-db.git) at 'main'
info: [DependencyResolver] solved 'swift-llbuild' (https://github.com/apple/swift-llbuild.git) at 'main'
info: [DependencyResolver] dependency resolution complete!

@swift-ci please smoke test


text:
Remove TestSupportExecutable from BasicTest

Error message on macosx
swift-test: error: the target BasicTests cannot have the executable TestSupportExecutable as a dependency
fix: move the shared logic inside a library, which can be referenced from both the target and the executable

Please review for possible side effects.

This is correct; you have to use a recent toolchain from swift.org and bootstrap swiftpm using Utilities/bootstrap


text:
custom option not supported?

Before opening a new issue, please double check the past issues (both open and
closed ones) to see if your problem has been discussed before and already
contains an answer/solution. Likewise, check the FAQ in the Documentation folder
for some common things -
https://github.com/apple/swift-protobuf/blob/master/Documentation/FAQ.md
I am trying to add a custom option on message level. I followed the doc at https://developers.google.com/protocol-buffers/docs/proto#customoptions
But found that BinaryDecoder has extensions to be nil in decodeMessage method of Google_Protobuf_MessageOptions. So, I cannot read the custom option value. But I do see it in the debug description.
Is it not supported right now or am I missing anything? Thank you!
Please be sure to include:

what OS you are developing on (Linux or macOS, including the version)
macOS

for macOS, what version of Xcode you are using (xcodebuild -version),
for Linux, what version of Swift (swift --version)
Xcode 12.3
Build version 12C33

what version of Swift is your code set to compile with (i.e. from project
settings, etc.)
Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)
Target: x86_64-apple-darwin19.6.0

what branch/tag of SwiftProtobuf you are using (1.0.0, etc.)
1.14.0

if you are getting compile errors, please be sure include all errors/warnings,
sometimes the error before the one you are stuck on is important.
N/A

lastly, if it all possible, provide a snippet of .proto and/or source
that shows the problem.

syntax = "proto3";

import "google/protobuf/descriptor.proto";

extend google.protobuf.MessageOptions {
    string some_option = 10001;
}

message AWEUserModel {
    string some_string_field = 1;
    option (some_option) = "Hello_World!";
}

Thank you!

Duplicate of #761

repo: apple/swift-protobuf


text:
Don't guard assertions behind #if DEBUG

Some assertions were still guarded by a #if DEBUG. Since we are now also enabling assertions in release builds if SWIFTSYNTAX_ENABLE_ASSERTIONS is set, this is no longer correct. Convert most of them to plain preconditions. I have measured and could not detect a performance difference when parsing MovieSwiftU.

@swift-ci Please test

I just tested and couldn’t find a significant performance regression when linting MovieSwiftUI using swift-format.

repo: apple/swift-syntax


text:
Make Expression.expandedDescription(depth:includingTypeNames:includingParenthesesIfNeeded:) -> String SPI

Expose Expression.expandedDescription(depth:includingTypeNames:includingParenthesesIfNeeded:) -> String SPI which is currently IPI as SPI so that it can be used from outside the Testing module.
Motivation:
If you want to inspect issues from outside the Testing library, it would be useful to have that method available since it provides a nice summary of the expression that failed a test.
Modifications:
Added @_spi(ExperimentalSourceCodeCapturing) public to Expression.expandedDescription(depth:includingTypeNames:includingParenthesesIfNeeded:) -> String SPI.
Result:
Expression.expandedDescription(depth:includingTypeNames:includingParenthesesIfNeeded:) -> String SPI is now accessible from outside the Testing module.
Checklist:

[x] Code and documentation should follow the style of the Style Guide.
[x] If public symbols are renamed or modified, DocC references should be updated.

Okay for now, however we probably will want to revisit and provide a proper SPI interface into this functionality in the future.

@swift-ci please test

authors: dennisweissmann grynspan

repo: apple/swift-testing


text:
Updates to conform documentation to API collection style guidelines

Updates to conform to API collection style guidelines:
- Begin titles with a noun.
- Place everything under topic groups.
- Begin topic group headings with a gerund.
- Add symbols alongside articles in the topic groups.
Curation changes:
- Move expected throws content up into expectations and split
known issues into its own collection.
Part 2 of changes for rdar://119702877
Checklist:

[x] Code and documentation should follow the style of the Style Guide.
[x] If public symbols are renamed or modified, DocC references should be updated.

@swift-ci please test Linux

authors: grynspan medreisbach


text:
Path: Handle Windows paths by converting to an internal UNIX-style representation

This is an alternative strategy to the one taken in https://github.com/apple/swift-package-manager/pull/2622; the first commit is just reverting that PR, while the second contains the new changes.
The basic idea is that paths are always stored in UNIX form within AbsolutePath and RelativePath, and that we convert between Windows paths at init at pathString. In most cases, removing any UNC or device path prefix, converting backslashes to forward slashes, and prefixing with a root / is enough to make a Windows path UNIX-like enough for the rest of the AbsolutePath/RelativePath functionality to work.
I've only really tested with DOS paths at the moment. If it turns out we need to distinguish between DOS paths, UNC paths, and device paths, we could look at adding a top-level /windows-device/ or /windows-unc/ directory to the internal path representation as one way to disambiguate.
cc @compnerd, @hartbit

I'm not sure this will work. The path needs to be preserved to be passed to file system APIs afterwards. I think we have no choice but to fully support Windows paths.

Could you elaborate on what you mean by that and what information you think we wouldn’t be preserving? This does at least work for simple cases - I haven’t tried anything involving multiple drives, network paths, or sum links yet, but I don’t see a fundamental reason why this approach wouldn’t also work for those.
Note that there is a conversion out of the internal form when we generate the pathString - we don’t pass the internal representation directly to system APIs.

Well, for example, it seems you drop the drive letter and other UNC prefixes. If I initialize AbsolutePath with a path on a drive that is not the current drive, I doubt this will work.

The drive letter is still in the path - I only drop the \\? or \\, so e.g. C:\Folder\File.swift becomes /C:/Folder/File.swift. The main issue I could see is that it doesn’t distinguish as-is between local and UNC paths, but that could be resolved resolved by name spacing at the root level (e.g. /local/rest-of-path or /unc/rest-of-path).

I understand better now, thanks for explaining! Unfortunately, this feels like a bit of hack, and I think it might be better to truly support Windows paths. I'm working on that, leveraging Windows APIs to avoid reinventing the wheel.

I am also thinking that this approach might end up making it harder to do the right thing. Given the fact that @hartbit is already working on properly handling paths using Windows APIs, it might not be worth handling all the complexity we'll be introducing with this approach.

My view is that this is a very simple approach and shouldn’t be difficult to eventually replace - most of the complexity in the diff is just the first commit reverting @hartbit’s refactoring, and the second commit mostly amounts to a few lines of string manipulation.
This does have a few advantages over a separate implementation, however: it’s much easier to maintain, can largely share the same test suite, and will have the same performance characteristics as on other platforms (plus a small constant factor on certain operations). I’m not convinced it’s worth all the extra work of a Windows-specific implementation when we don’t yet have concrete use cases that this approach doesn’t work for.
With that all said, if @hartbit thinks a “proper” approach wouldn’t take long to implement and would be performant then I’m totally okay with waiting for that.

@compnerd could you please help review this since you worked on this lately

Processing the same test suite is an interesting idea.  Storing the paths as arcs and then converting to the FSR is a very reasonable thing to do, and really effectively what Foundation does to ensure that different path separators are not a concern.  I think that rebasing this and getting it working to the same state as the current tree would be interesting.

I agree with @compnerd, I think it's very interesting to consider whether we need the internal representation to be exactly what the OS wants, or something more suitable for path operations that can then (quickly) be transformed into what the OS wants at the time of file system access.  Even with the current implementation of having a string with Unix-style path separators, there can be encoding differences when calling file system functions.  It's just that with Swift String being UTF-8 backed now, it turns out to be a no-op transformation.
It's worth considering that if AbsolutePath and RelativePath contains the OS native representation, then that does get exposed to clients through methods such as pathString, etc.  That may be what we want, but it will mean that, for example, swift package describe and swift package dump-package will yield different output on different platforms.
At some point we do need to deal with paths that have forward slashes on all host OSs, since we need to support at least relative paths that are read from files such as the package manifest (e.g. subpaths of target source directories, of resource files, of module maps, etc).  So I think the decision is whether to do the transformation as each path is constructed, or to do it on file system access.  I don't have a strong opinion yet, but that seems like the main choice, and either way we go has ramifications.

For what it's worth, it might be a few weeks before I can get back to any implementation work on this.
In response to what @abertelrud has raised: my personal opinion is that any relative paths should stay Unix-style for consistency cross-platform, but any absolute paths should always be exposed to the user in a format that they can copy and paste into an Explorer/Finder window. That doesn't really match up with this PR, which would naively expose any absolute paths as the /-prefixed internal implementation; however, that's also easy enough to work around.

Hi @troughton, the Swift project moved the default branch to main and deleted master branch, so GitHub automatically closed the PR. Please rebase on top of the main and we can reopen.
More detail about the branch update - https://forums.swift.org/t/updating-branch-names/40412

authors: abertelrud aciidb0mb3r compnerd hartbit tomerd troughton

repo: apple/swift-tools-support-core


text:
[WIP] fleshing out Collection.next(Index) -> Index

-removed fatal stub Collection.next(Index)
-added default Collection.next(Index) where Index is Strideable
-added custom next(Index) on some collections
-added fatal stub next(Index) on some collections
@gribozavr I took a stab at building Collection.next(Index) -> Index. As you can see a good number need to be implemented still (those are marked with fatalError("FIXME: swift-3-indexing-model")).

I am moving onto BidirectionalCollection.previous() now unless I hear otherwise from someone.

@shawnce Generally LGTM, modulo the comments.  I'm being picky about leaving these FIXMEs as we go through this, because I know that once we get this thing to compile, the probability of missing these performance improvements is high.
I will merge your PR tomorrow morning, and will start adding fixes for the review comments that you didn't get to fix.

@gribozavr just push some changes that I think hit your bucket list of items and I attempted to implement some of them

I'm going to merge this and will fix any review comments myself later.

@gribozavr pushed a quick fix for things you flagged. Any suggestions on what I should work on next? ...or do you need me to hold on things?

We probably need to gyb three variants of LazyCollection, too.

@shawnce Thank you!  I'd like to take ExistentialCollection.swift.gyb next.  Could you take Flatten.swift.gyb and Reverse.swift?

@gribozavr I will work on Flatten and Reverse next

authors: gribozavr shawnce

repo: apple/swift


text:
[4.2 04-30-2018][SE-0210]  Add a MemoryLayout<T>.offset(of:) method for getting the offset of inline storage

Explanation: Implement SE-0210 "Add an offset(of:) method to MemoryLayout", a minor extension to key paths.
Scope: New API for key paths, which only affects the standard library.
Radar/SR Issue: rdar://problem/38915805
Risk: Almost zero risk; this is new API that did not require changes anywhere else in the standard library or compiler.
Testing: New tests for this functionality; compiler regression tests.
Reviewer: @jckarter

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - f5577ad980865f0c6549d24f4906a70777a4f4b9

@swift-ci please test macOS platform

@swift-ci please test macOS

@swift-ci please nominate

@swift-ci please nominate

authors: DougGregor huonw najacque swift-ci


text:
Adjust access level of inaccessible protocol members in diagnostics.

Otherwise we hit one of the "%error" cases in the diagnostic text,
which results in an assert.
Fixes rdar://problem/40111079.

@swift-ci Please smoke test

@slavapestov @xedin I couldn't find a way to trigger a problem here for TypeCheckType.cpp or CalleeCandidateInfo.cpp, but if you can think of a way to do so let me know. The attempts I tried involving internal protocols all seemed to get caught in PreCheckExpression.


text:
Revert "[4.2] [TypeChecker] Fix crash with Objective C keypaths."

Reverts apple/swift#17504
It's a likely cause of a validation failure during source compatibility testing (CoreStore).
I'm still trying to reproduce the failure, but I'll back this out for the moment to get the builders back on their feet.

@swift-ci Please test

fast-tracking this

thanks!

Build failed
Swift Test Linux Platform
Git Sha - e75489ce9e1351f575b6cee807f0413aa170b040

Build failed
Swift Test OS X Platform
Git Sha - e75489ce9e1351f575b6cee807f0413aa170b040

authors: graydon rudkx swift-ci


text:
do not hoist tensorStartPoint above itself

This fixes test/TensorFlowRuntime/sese_loop_canonicalization.swift in piper.
I can make the test fail in the opensource build by putting public in front of func natSumWithBreak. Perhaps some configuration difference is causing the piper build to partition natSumWithBreak even without public. Anyways, here's what's happening:
Right before TFPartition starts marking natSumWithBreak, it looks like this:
// natSumWithBreak(_:)
sil @$S4sese15natSumWithBreaky10TensorFlow0F0Vys5Int32VGAGF : $@convention(thin) (Int32) -> @owned Tensor<Int32> {
// %0                                             // users: %4, %1
bb0(%0 : $Int32):
  debug_value %0 : $Int32, let, name "breakIndex", argno 1 // id: %1
  %2 = integer_literal $Builtin.Int32, 1          // users: %9, %14, %5, %17
  [TENSOR START POINT] %3 = graph_op "Const"() {dtype: $Int32, value$tensor: i32 0, __device: "ALL_DEVICES"} : $TensorHandle<Int32> // users: %8, %6
  %4 = struct_extract %0 : $Int32, #Int32._value  // users: %9, %28
  %5 = graph_op "tfc.scalarToTensor,s"(%2 : $Builtin.Int32) {__device: "/device:CPU:0"} : $TensorHandle<Int32> // users: %7, %6
  %6 = graph_op "Add,i,i"(%3 : $TensorHandle<Int32>, %5 : $TensorHandle<Int32>) {T: $Int32, __device: "/device:CPU:0"} : $TensorHandle<Int32> // users: %11, %14
  strong_release %5 : $TensorHandle<Int32>        // id: %7
  strong_release %3 : $TensorHandle<Int32>        // id: %8
  %9 = builtin "cmp_eq_Int32"(%4 : $Builtin.Int32, %2 : $Builtin.Int32) : $Builtin.Int1 // user: %10
  cond_br %9, bb1, bb2                            // id: %10
...

Now, sinkValueIntoRegionForPromotion sinks %2 = integer_literal, which makes %2 = integer_literal the new start point.
Eventually, hoistValueAboveStartPoint tries to recursively hoist %9 = builtin "cmp_eq_Int32" and its operands above the start point. Unfortunately, one of the operands is the start point. hoistValueAboveStartPoint does not handle hoisting the start point above itself correctly, so it creates the following result where builtin "cmp_eq_Int32" takes an operand that comes after it:
// natSumWithBreak(_:)
sil @$S4sese15natSumWithBreaky10TensorFlow0F0Vys5Int32VGAGF : $@convention(thin) (Int32) -> @owned Tensor<Int32> {
// %0                                             // users: %2, %1
bb0(%0 : $Int32):
  debug_value %0 : $Int32, let, name "breakIndex", argno 1 // id: %1
  %2 = struct_extract %0 : $Int32, #Int32._value  // users: %3, %28
  %3 = builtin "cmp_eq_Int32"(%2 : $Builtin.Int32, %5 : $Builtin.Int32) : $Builtin.Int1 // user: %11
  %4 = integer_literal $Builtin.Int32, 100        // user: %21
  %5 = integer_literal $Builtin.Int32, 1          // users: %3, %14, %7, %17
  %6 = graph_op "Const"() {dtype: $Int32, value$tensor: i32 0, __device: "ALL_DEVICES"} : $TensorHandle<Int32> // users: %10, %8
  %7 = graph_op "tfc.scalarToTensor,s"(%5 : $Builtin.Int32) {__device: "/device:CPU:0"} : $TensorHandle<Int32> // users: %9, %8
  %8 = graph_op "Add,i,i"(%6 : $TensorHandle<Int32>, %7 : $TensorHandle<Int32>) {T: $Int32, __device: "/device:CPU:0"} : $TensorHandle<Int32> // users: %12, %14
  strong_release %7 : $TensorHandle<Int32>        // id: %9
  strong_release %6 : $TensorHandle<Int32>        // id: %10
  cond_br %3, bb1, bb2                            // id: %11
...

@bgogul, yes, is exactly https://bugs.swift.org/browse/SR-8325. I'll take that and resolve it when I submit this.

@swift-ci please test tensorflow linux cpu


text:
[5.1][Diagnostics] Guard against missing parent initializer in missing unw…

…rap diagnostic
While trying to diagnose missing optional unwrap for single use
vars guard against it not having a parent initializer.
Unfortunately there is no test-case for this but we have
received multiple reports about offerDefaultValueUnwrapFixIt
crashing trying to access locator on passed in expr.
Resolves: rdar://problem/51784793
(cherry picked from commit fca8106f951c0d6c43a70a43053cee42d3e189b8)

@swift-ci please test and merge


text:
[CodeCompletion] Fix a crash in callee analysis

struct Wrap<T> {
  func method<U>(_ fn: (T) -> U) -> Wrap<U> {}
}
func testGenricMethodOnGenericOfArchetype<Val>(value: Wrap<Val>) {
  value.method(#^HERE^#)
}

In this case, the type of value is Wrap<Val[archetype]>. Type::getTypeOfMember() for method(_:) method returns  (Val[archetype]) -> U[generic param]) -> Wrap<U[generic param]> which crashes mapTypeIntoContext() because it already has archetype.
rdar://problem/52386176

@swift-ci Please smoke test

@swift-ci Please Sourcekit Stress test

@swift-ci Please Sourcekit Stress test

Stress tester failure is unrelated (revealed by fixing this). I will update sourcekit-xfails.json.

@swift-ci Please smoke test


text:
Bump the default clang version to 10.0.0

To match the current value in llvm-project. This fixes runnign clang
tests under build-script without explicitly setting the version, where
there is a test passing -fclang-abi-compat=9 that was previously
failing.
rdar://60376468

@swift-ci please test

preset=buildbot_incremental,tools=RA,llvm-only
@swift-ci please test with preset

Build failed
Swift Test OS X Platform
Git Sha - 7710ba7c433c007f50282c98388a84538f610249

@swift-ci please test macOS

authors: benlangmuir swift-ci


text:
[5.5][CodeCompletion] Don't suggest underscored module name

Cherry-pick #37527 into release/5.5 originally reviewed by @benlangmuir
rdar://78232229

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - c76484bcd24b3c7bc93f7a3610e07f00bbf99dce

@swift-ci Please test macOS

authors: rintaro swift-ci


text:
Prefer witnesses with no difference effects to ones that have fewer effects

One can overload on async vs. non-async, and the constraint solver has a
preference rule based on context. Extend that preference rule to
witness matching, so we prefer a witness that exactly matches the
effects of the requirement to one that has fewer effects.
Fixes rdar://84034057.

@swift-ci please smoke test

@swift-ci please smoke test


text:
[CodeCompletion] Complete code completion tokens after if-statement as top-level

Instead of setting the code completion position when parsing the if-statement, which doesn’t create a CodeCompletionExpr, parse it as a new top-level expression.
As far as test-cases are concerned, this removes the “RareKeyword” flair from top-level completions in the modified test case. This makes sense IMO.

I came across this while migrating expression completions to solver-based, which started having issues because we were completing StmtOrExpr without a CodeCompletionExpr.

@swift-ci Please smoke test

Nice find, but this makes completeAfterIfStmt(/*hasElse=*/false) branch non-reachable. I think that is still usable because
if condition {
  ...
}
#^HERE^#

In this case, we want to suggest else and the global expression completions. Otherwise, we should not suggest else (other than after conditions for guard). But that can be done in followups.

@swift-ci Please smoke test

@swift-ci Please smoke test

@swift-ci Please smoke test Linux

authors: ahoppen rintaro


text:
[Compile perf] Make scale-test conditional on assertions, rdar://2909…

Finally reproduced the failure in rdar://29090287, it's just a "release-no-asserts" build which I hardly ever check; turns out that completely disables stats-gathering, so there's no output and the test fails.
Apologies for the delay.

@swift-ci please smoke test and merge


text:
Sema: Fix availability checking in function default argument closure expressions

When building the TypeRefinementContext tree, delay pushing a decl's body context until the body Stmt is actually encountered by the ASTWalker. This ensures that default argument expressions do not automatically inherit the availability context of the function body.
Resolves rdar://95148645

@swift-ci please smoke test

The release/5.7 change is in https://github.com/apple/swift/pull/59472/.


text:
[build-script] Makes build-script to support None and string object SystemExit.code

Makes build-script to support None and string object SystemExit.code when a SystemExit is caught.
A SystemExit's error code may be either None, an int object or a string object. This commit takes all these possibles into consideration and prevents Python from throwing when SystemExit.code is not an int object.
This resolves issue #60684 : https://github.com/apple/swift/issues/60684

@swift-ci Please smoke test and merge

Oops. I don’t want to close.
@swift-ci Please Python Lint

@YOCKOW Hi, I just have fixed the Python lint issue. Pleas try merge again.

@swift-ci Please Python Lint

@swift-ci Please smoke test and merge

authors: WeZZard YOCKOW


text:
[Sema] Restrict reexported SPIs to modules with an export_as relationship

This PR ensures that an @_exported import exports SPIs only when the exported module defines export_as pointing to the exporter module. Other reexports do not reexport SPIs. This is to prevent SPI reexporting to get out of hands with the wide reexports of the Objective-C world.
rdar://102335473

@swift-ci Please smoke test

@swift-ci Please smoke test Linux


text:
Noncopyable diagnostics cleanup

🚧 here be lots of find-replace 🚧

replaces "move-only" terminology with "noncopyable"
replaces compiler jargon like "guaranteed parameters"
and "lvalue" with corresponding language-level notions
simplifies diagnostics about closures.

and probably more.
rdar://109281444

@swift-ci smoke test linux

@swift-ci please test

@swift-ci please test and merge


text:
[DNM] Use less branching in sort's merge algorithm

(Experimental change)

@swift-ci Please benchmark

@swift-ci Please benchmark


text:
[embedded] Move _CustomStringConvertibleOrNone/_LosslessStringConvertibleOrNone to avoid detaching doccomments from their declarations

It turns out that the addition of the _CustomStringConvertibleOrNone/_LosslessStringConvertibleOrNone typealiases happened at a very unfortunate source code location that causes the doccomments to get detached from their declarations. Let's fix that.

@swift-ci please test

I think #68597 might have detached the ObjectIdentifier initializers from their documentation.

Good catch, fixed in this PR too.

@swift-ci please test

I'm not suggesting another change, but can opaque types and metatypes be used?
- public init<Object: AnyObject>(_ x: Object)
+ public init(_ x: some AnyObject)

- public init<Object>(_ x: Object.Type)
+ public init(_ x: (some Any).Type)

Correct me if I'm wrong, but my understanding is that these two options are equivalent in basically all aspects, and they are just two different syntactical options for exactly the same thing. So yes, either can be used, and I thought it's mostly a matter of personal preference -- or is there some official recommendation to use one over the other? (I'd be happy to change it to use "some" if that's the preferred way.)

Right, but those are using "any", and are problematic in embedded Swift. "some" and generics are completely fine. The code snippet we're talking about is not using existentials or metatypes.


text:
Adding CustomDebugStringConvertible conformance to CGVector

rdar://problem/27762451

@swift-ci Please smoke tes

@swift-ci Please smoke test and merge


text:
IDE: Expose a utility to collect argument label ranges from either tuple or paren exprs. NFC

@nathawes does this make sense to you?

@swift-ci please smoke test


text:
[swift-4.0-branch][stdlib] Add a Swift 4 only RangeRepleaceable.filter returning Self

Explanation: This overload allows String.filter to return a String, and not
[Character]. (Partial implementation of  https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md
Scope of Issue: Introduces the new overload in Swift 4 mode only. Tests make sure that the behavior for Swift 3 remains the same.
Risk: Minimal
Reviewed By: Ben Cohen
Testing: Automated test suite + special test cases
Directions for QA: N/A
Radar: rdar://problem/32284321 [swift-4.0-branch]

@swift-ci Please test

Similar to https://github.com/apple/swift/pull/9741 and https://github.com/apple/swift/pull/9748

@swift-ci test source compatibility

authors: moiseev tkremenek


text:
Installing turicreate on MacBook Pro with anaconda with python 3.7

Hi,
I have MacBook Pro with Mojave and latest anaconda which has python3.7.
I have been trying to install turicreate by terminal method using pip install turicreate and by using absolute path of who file, however error during both.
can someone help me in resolving this issue?
Thanks

Turi Create does not yet support Python 3.7. We're still waiting for some of our dependencies to support Python 3.7.
Closing this issue as a dup of #788.

@TobyRoseman Hey, it's been three months. It's still not supported?

@guyandtheworld - It's currently under active development. I even have a work in progress pull request up to support Python 3.7. We're having some issues with a couple of our dependencies. Once those are resolved, we'll release on PyPI. Subscribe to #788 for updates on Python 3.7 support.

authors: TobyRoseman guyandtheworld lalitmach22

repo: apple/turicreate


text:
Use ttl from settings in kvstore/in_memory instead of hardcoded value

Right now the in memory kvstore uses a hard-coded time to live:
https://github.com/applike/gosoline/blob/master/pkg/kvstore/in_memory.go#L135
We should use the property in the settings struct.

Closing as this was already fixed some while ago.

authors: ajscholl willemschots

repo: applike/gosoline


text:
Support for Swift 4

Does this project support swift 4? If not, when do you think you will have a version for swift 4 available?

You can try the swift4 branch.

When will you merge this into master if ever?

Have you tried the swift4 branch? Have you experienced any issues with it?

I have tried it but I have not done any in-depth testing. It worked in a very basic test case but I think I did see an issue in one situation. I will look into it further and get back to you.

repo: apploft/ExpandableLabel


text:
Roll Out strategy

How do we handle exercism? Announce on their discord before any public announcement?
Twitter post?
LinkedIn announcement(@angiemugo) takes ownership of this
Dev Congress Beta channel post?
Share with friends to test?

Going with a roll out to Dev congress and Developerish slack communities

Tasks Done

Announcement on Discord
Shared with friends to test
Dev Congress
Rand leadership slack channel

Pending

LinkedIn announcement
Twitter post

repo: apps-fab/exercism-app


text:
Update repository config

Signed-off-by: 1gtm 1gtm@appscode.com

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

repo: appscodelabs/gomod-gen


text:
[Bug]: Show error message and red accent color when isRequired is enabled for DatePicker widget

Is there an existing issue for this?

[X] I have searched the existing issues

Description

Please have a check around JSONForm date field as well while fixing the date widget
cc: @ashit-rath
Steps To Reproduce

Add a Date Picker widget onto the canvas
From Property Pane enable Required option
Click on the Date Picker widget clear the date from calendar
observe there is no error message appears and no red accent color appears
Default error message must be "The field is required"

Public Sample App
No response
Version
Cloud/ Production

@jsartisan @keyurparalkar could this have regressed due to theming

Hey @somangshu I checked, this isn't happened due to theming. This is also happening in the PROD environment.

authors: chandannkumar keyurparalkar somangshu

repo: appsmithorg/appsmith


text:
[Task]: Add accelerator and isUserCreated properties in execute_ACTION_TRIGGERED event for 1-click binding

SubTasks
Notion doc: https://www.notion.so/appsmith/Add-accelerator-and-isUserCreated-properties-in-execute_ACTION_TRIGGERED-event-for-1-click-binding-02db8353ce9b438d9f27380484eb1c9d?pvs=4

PR is merged, hence closing this one


text:
[Bug]: UX Issues with the new response tab modifications

Is there an existing issue for this?

[X] I have searched the existing issues

Description
I some scenarios user is not able to scroll & view the complete response tab.
Note: This is not reproducible on the latest tagged image.
https://jam.dev/c/2c916945-e62b-4e42-b407-50a452c8c46d
Steps To Reproduce

Go to any app & create a query.
Switch to split panes and run the query.

Expected: The response tab should be clearly visible and the user should be able to scroll.
Public Sample App
No response
Environment
Production
Severity
Medium (Frustrating UX)
Issue video log
No response
Version
Cloud

Today, I can scroll up-down and left-right, but only the horizontal scrollbar shows.

authors: rohan-arthur shadabbuchh


text:
[Bug]: On importing the attached jsons with snowflake db, the password field does not come up on the datasource config page.

Is there an existing issue for this?

[X] I have searched the existing issues

Description
On importing any json containing snowflake datasource, the password field does not show up on the DS config page.
Steps To Reproduce

Create a new workspace on https://nightly-saml-alb-https.appsmith.com/
Import any of the attached jsons
Go to the snowflake db configuration and edit it.
Note that there is no password field

Public Sample App
No response
Environment
Production
Severity
High (Blocker to building or releasing)
Issue video log
https://jam.dev/c/14d371fb-d779-4ce3-ae17-ffdb74f3a2ca
Version
Cloud

try to covermore (2).json


text:
[Bug] Unable to download PNG and JPEG option

Steps to reproduce:

Add an Image widget
Bind image for download 'on click'
click on the image
and observe

Observation:
It is observed that the image does not get downloaded and displays an error "file is empty"
Expectation:
An appropriate  image is added into the image field the file must be downloaded

This is the issue

This issue is solved if the MIME-type is changed to "application/x-binary".  This is probably not ideal. We should be able to use "image/png" But if that is not possible then we map binary files automatically to "application/x-binary" internally?

TODO: We also need to update the documentation for this change.

Fixed with #6179

authors: ajinkyakulkarni hetunandu prapullac


text:
[Bug] Modal is showing out of canvas when view mode is changed

This is not reproducible any more, Closing it for now, @vivekverma2312 please check to see if that is not true.


text:
feat: Adding Navigation Settings Functionality

Description

This PR implements backend model and APIs for Part 1 of Improved App Viewer Navigation Project i.e implementing the navigation configuration settings
Notion Doc
Figma Design

Implements #19163
Implementation
It reuses the following existing APIs to implement storing and fetching navigation settings:
/api/v1/applications/{applicationId} (PUT)
/api/v1/pages?applicationId=<applicationId>(GET)
Additional fields unpublishedNavigationSetting and publishedNavigationSetting have been added to the application collection.
Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Manual

Testing Results

Postman testing results attached below

Update publishedNavigationSetting API

API Route: /api/v1/applications/{applicationId}
API Method: PUT
API JSON Response: http://jsonblob.com/1057577523797573632

Update unpublishedNavigationSetting API

API Route: /api/v1/applications/{applicationId}
API Method: PUT
API JSON Response: http://jsonblob.com/1057578112661078016

Database Record

GET Published and Unpublished Navigation Settings API

API Route: /api/v1/pages?applicationId=<applicationId>
API Method: GET
API JSON Response: http://jsonblob.com/1057580262598393856

Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[x] PR is being merged under a feature flag

QA activity:

[ ] Test plan has been approved by relevant developers
[ ] Test plan has been peer reviewed by QA
[ ] Cypress test cases have been added and approved by either SDET or manual QA
[ ] Organized project review call with relevant stakeholders after Round 1/2 of QA
[ ] Added Test Plan Approved label after reveiwing all Cypress test

/ok-to-test sha=0ba384bb892e0a3aa82553d5f3d11fee2ed6abd6

/ok-to-test sha=6e294e0bd5d60660660ab479b46cc1a306eb28e5

Question more for my understanding, why did we decide against aggregating all unpublished and published fields in an app in one type?
Also, Nilansh, please use the Fixes #foo representation for attaching github issues to your PRs. Otherwise they will not autoclose on PR merge.

/ok-to-test sha=f7610a988b9e058364c689a9d204e88769955f64

authors: NilanshBansal nidhi-nair


text:
hotfix: airtable spec fix

Merging for cypress tests passing to master

/ok-to-test

authors: ayushpahwa trishaanand


text:
fix: changing git repo button to anchor tag

Description
Makes go to button clickable
PR fixes following issue(s)
Fixes #24070
Media
Type of change

Bug fix (non-breaking change which fixes an issue)

Testing
How Has This Been Tested?

[ ] Manual
[ ] Jest
[ ] Cypress

Test Plan

Add Testsmith test cases links that relate to this PR

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/build-deploy-preview

@brayn003 Should we open repository in new tab instead of the same?
https://github.com/appsmithorg/appsmith/assets/80334441/877587ca-823e-4fee-b397-8f56a19e9c0c

yes

/build-deploy-preview

/ok-to-test

/ok-to-test


text:
chore: Changing OpenAI datasource documentation link

Description
Changing the documentation link to https://docs.appsmith.com/connect-data/reference/open-ai
Type of change

Chore (housekeeping or task changes that don't impact user perception)

Testing
How Has This Been Tested?

[x] Manual

Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/ok-to-test

/ok-to-test


text:
fix: rest api body binary tab placeholder updated

Description
This PR updates the REST API body tab binary's placeholder text to indicate that this requires input as file contents in base64 format. This can help users in debugging in case REST API file upload does not work out for them.
New placeholder text changes are as below:

Fixes #33266
or
Fixes Issue URL

[!WARNING]
If no issue exists, please create an issue first, and check with the maintainers if the issue is valid.

Automation
/ok-to-test tags="@tag.Datasource"
:mag: Cypress test results

[!CAUTION]
If you modify the content in this section, you are likely to disrupt the CI result for your PR.

Communication
Should the DevRel and Marketing teams inform users about this change?

[ ] Yes
[ ] No

/build-deploy-preview skip-tests=true


text:
fix: Regex to detect function args

Description
Regex was not working with whitespace characters since we are using .*
Replaced it with [\s\S]* to include whitespace characters.
Arrow function was not matching when space is there between arrow (()  =>  {}) that is also fixed.
Fixes #8169
Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Tested this manually by providing whitespace characters into the argument fields of action selectors.
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

Test coverage results :test_tube:
:green_circle: Total coverage has increased
// Code coverage diff between base branch:release and head branch: fix/action-selector-issue

Status
File
% Stmts
% Branch
% Funcs
% Lines

:green_circle:
total
55.12 (0.03)
37 (0.03)
34 (0.02)
55.63 (0.03)

:green_circle:
app/client/src/components/editorComponents/ActionCreator/Fields.tsx
35.52 (3.78)
25.42 (3.39)
10.39 (2.6)
34.86 (3.67)

:green_circle:
app/client/src/utils/autocomplete/TernServer.ts
52.94 (0.23)
41.67 (0.84)
36.21 (0)
56.99 (0.25)

/ok-to-test sha=f5b3fe7

/ok-to-test sha=d85f92f

/ok-to-test sha=d85f92f

/ok-to-test sha=d85f92f

/ok-to-test sha=7794d49

/ok-to-test sha=7794d49

/ok-to-test sha=7794d49

/ok-to-test sha=9cd6736

@aswathkk Deploy preview is tested and working fine.


text:
Consider modifgying advice for 1.4.13 Content on Hover and Focus

https://appt.org/en/guidelines/wcag/success-criterion-1-4-13
Suggested improvements
The text refers to content that pops up when elements are touched. This is not really what the SC covers, though - it covers mouse hover and keyboard focus receipt.
The solution of adding a close button would not work snce ot would mean users have to move focus to activate it.
The SC applies when apps are used with attached mice or keyboard (even though hover and focus will be rare in apps for obvious reasons).

Hi @detlevhfischer thanks for your suggestion. I'll discuss it with other project members in April, when I'm back from my holiday.

Hi @detlevhfischer , like you mentioned, pointer hover is something that doesn't really happen in apps. Keyboard focus is probably more common. Long press might be most equivalent to 'pointer hover' as intended in the SC. Perhaps we can rename touch/click to 'long press' and/or keyboard focus. What do you think?

Hi @detlevhfischer what do you think of the text suggested on April 11?

@JJdeGroot Hover is definitely an option when a USB or bluetooth mouse is attached to a tablet, even though hover events it will be rarely supported since most users do use touch to interact with the app. But mobile OS become more prevalent and contain more complex applications where the use of keyboard or mouse might make sense. So it is not clear that hover can simply be discounted.
As to your long press idea: There simply are as yet no particular requirements for long press contained in 1.4.13 - so if you include requirements for that, it should be clear that this is not a normative requirement from WCAG 2.X or even the current update of WCAG2ICT, but something you consider worth including on its own merit.

Hi @detlevhfischer  I have changed the sentence to:
English:
Ensure it is possible to hide information which appears automatically after hovering with the pointer or focusing with assistive technologies.
Dutch:
Zorg dat het mogelijk is om informatie te verbergen indien deze automatisch verschijnt na hover met de aanwijzer of focus met hulpmiddelen.
This sentence is now more in line with the official WCAG definition.

@JJdeGroot I think apart from hovering (pointer) focusing should not be restricted to "focusing with assistive technologies". The main case for th ekeyboard focus half of 1.4.13 will be checking keyboard operation of an app by coupling it with an external keyboard, focusing elements with tab (or arrow keys as it may be), and checking that any content that pops up on kb focus can be closed (e.g via ESC). The focus of 1.4.13 is clearly on sighted users, not screenreader users. I agree that content appearing when focusing elements in read mode (e.g. via touch swipe gestures) should probably also meet the requirements, but since WCAG does not spell out if the same requirement applies to content when a screen reader is active, I would avoid any explicit reference to assisitve technology use here.

Hi @detlevhfischer good points, I have changed assistive technologies to keyboard. Also updated some more phrases where assistive technologies were mentioned.

authors: JJdeGroot detlevhfischer

repo: appt-org/appt-org


text:
Added new: cursor in developer tools

Cursor is a code editor designed for pair programming with AI.

Thanks for contributing. Unfortunately cant accept either of these.
At the time of your contribution, the guidelines were not yet written clearly and I am sorry about this. Although have rejected earlier links for the same reason. The guideline is as follows:

We seek projects that stand out due to their popularity, dedication from their contributors, or their unique approach to solving problems within the AI space.
Our focus is on adding open-source tools and resources that foster community growth and learning.
We typically exclude closed-source tools or service-only offerings, unless they're unparalleled leaders in their domain without viable open-source alternatives.

authors: aprxi meetpateltech

repo: aprxi/letsbuild-ai


text:
feat: deprovision environment

feat: change name for environment

Tiny thing - we don't show a label of Confirm Name anywhere for these deprovision blocks, so maybe we remove that to pattern match.

authors: joeclayallday neurosnap

repo: aptible/app-ui


text:
Organization billing section styles

[ ] Overview
[ ] Plan
[ ] Payment Method
[ ] Invoices

@sandersonet I think this is also not part of the immediate/launch organizations milestone, yes? We discussed that this is largely done manually today, and will simply continue to be manual after diesel becomes dashboard.
Dropping from the milestone but please let me know if I've missed something.

You are correct, thanks.

Closing in favor of separate Overview and Invoices screens.

authors: mixonic sandersonet


text:
🛑 Field Service is down

In b83644e, Field Service (https://api.field-services.prd.goaptive.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Field Service is back up in 5243c4c after 30 minutes.

repo: aptive-env/status


text:
[Feature Request]: add dark mode to adventure travel page

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
add dark mode to adventure travel page
Use Case
add dark mode to adventure travel page
Benefits
add dark mode to adventure travel page
Add ScreenShots
https://github.com/user-attachments/assets/983223bd-ac28-4e04-a200-a47d2f121f8a
Priority
High
Record

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

@itsekta please assign me this issue


text:
BUG : CHATBOT

Describe the bug

Hello All,
There is a Chatbot in the webpage & the chatbot is not working upto the mark.
Expected behavior

I just want the chatbot functionable . Make the chatbot functionable even can make it more functionable by adding more elements
Screenshots (Mandatory)

Additional Context (Mandatory )
Those whoever comment first with JWOC mentioned in it  I will assign it to HER/HIM
Are you contributing under any open-source program ?

JWOC'24

i would like to work under jwoc @apu52 kindly assign

@Anushkabh You are assigned. You have 2-3 days to submit your PR.
Happy coding!!!!!!!!!

Hey guys :)
I'm the maker of Conferbot, I see that you have run out of your chat quota for the month.
Since you guys are students, I'll be happy to increase your chat quota to 1500 chats/month for free for 2 months.
A little tip to help you manage better: Try turning off the Bot Auto Open feature. You'll find it under Customizations -> Advanced. This should help prevent using up your chat quota too quickly.
If you'd like to take up this offer, just let me know.
Good luck!

@dPacc Thank you for your concern & the tips  . As now for somedays this repo is under a open source programme JWOC , & this issue is already assigned so , @Anushkabh I think you can take the tips mentioned above

@apu52 yes I have taken into account the tips mentioned .. working on that will push it by eod

@apu52 kindly review the pr #231  and merge if satisfied.

authors: Anushkabh apu52 dPacc


text:
Could you help add the license file to this project?

Hello, I am from the Apache SkyWalking community. By reading this blog, I learned that BTFGen can make eBPF programs portable. This is a great idea, and we'd love to add it to our SkyWalking Rover project.
However, during the integration, we found that the btfhub-archive project did not add the LICENSE file, so we could not add it to the binary LICENSE statement file. So, could we help add the license file to this project?
You could get more information through this PR. Hope to get your reply, thanks!

Hello @mrproliu,
Yes, the license of this repository is the same as btfhub repository. I haven't added it here because this is an archive only repository. Let me see if adding a LICENSE file here won't break any of our builds.

I'm closing this (and issues within this repository) as I'm working only with issues in the main repository (and this is an archive repository only). Would you mind opening the issue there ? Either way, I'm working on it.

authors: mrproliu rafaeldtinoco

repo: aquasecurity/btfhub-archive


text:
bug: google-gke-metadata-endpoints-disabled check resolution is incorrect

Describe the bug

The suggested resolution for the metadata-endpoints-disabled check does not appear to be valid Terraform code for a google_container_cluster.
To Reproduce
Steps to reproduce the behavior:

Starting with a simple google_container_cluster

resource "google_container_cluster" "main" {
  name = "test"
}

which successfully validates:
❯ terraform validate
Success! The configuration is valid.

Add the suggested resolution

resource "google_container_cluster" "main" {
  name = "test"

  metadata {
    disable-legacy-endpoints = true
  }
}

which is no longer valid:
❯ terraform validate
╷
│ Error: Unsupported block type
│
│   on main.tf line 4, in resource "google_container_cluster" "main":
│    4:   metadata {
│
│ Blocks of type "metadata" are not expected here.

Expected behavior
The expected behaviour is for the suggested resolution to fix the tfsec warning and be valid Terraform code.
Screenshots/Output

System Info

tfsec version: v1.15.2
terraform version: v1.1.7
OS: Ubuntu 20.04

Example Code

resource "google_container_cluster" "main" {
  name = "test"

  metadata {
    disable-legacy-endpoints = true
  }
}

Additional context

It appears as though the metadata field needs to be specified inside the node_config block, but in this case the tfsec check continues to fail.

Hello @owenrumney , I'm using v4.15.0.

Thank you

repo: aquasecurity/defsec


text:
Added changes for Registry

Made the following changes -

Modified provider.go to add Registry resources.
Added the following files -
resource_registry.go -> Contains the logic for registry resource.

resource_registry_test.go -> Contains the tests for registry file

data_registry.go -> Contains the logic for registry datasource

data_registry_test.go -> Contains the tests for data_registry file

client/Registry.go -> The Registry SDK

Docs and Examples Updated. Also I have tested the CRUD operations of the registry and they are working fine.

Registry CRUD is working fine but I just noticed there are some issues with data registry

@mavericknavs can you resolve the conflicts? Is it ready to be merged?

Hi Amir,
I have resolved the conflicts and also resolved the issue with data_registry.go file. The Matrix tests are failing because the delete user tests are failing. Changes are ready to be merged from my end.

@jerbia all Tests have now passed. Can you please merge the PR?

authors: jerbia mavericknavs

repo: aquasecurity/terraform-provider-aquasec


text:
Should is_int() return true for all integers? Same for is_number().

Looking at the implementation of MsgPack is_int() it only returns true for int_32_t
To me the logical approach would be to mimic JSON type specification, ie is_int() would return true for all encoded int types (including unsigned) and is_number() should return true for all numbers (floats and ints).
therefore change is_int() to:
is_int(){ return is_int8() || is_int16() || is_int32() || is_int64() || is_uint8 || is_uint16 || is_uint32() || is_uint64();}
and is_number() to:
is_number(){return is_float32() || is_float64() || is_int();}
It might be possible to make this cleaner using bitmasks but I've not had coffee yet so can't think.
But thanks for a nice c++11 friendly implementation!

Additionally once this is then dumped to string data it's encoded as the smallest possible value type. Therefore when an instance of MsgPack is constructed from an int it returns true to is_int(), however when that instance is then encoded and decoded it returns false.

Close this issue by merging this PR.


text:
Numbers are incorrectly highlighted in the name of variables

Description
When the name of a variable contains a number, the number is incorrectly highlighted differently.

Expected behavior
The whole name of the variable should be highlighted the same.

Actually, we currently do not have any specific scope for names of variables, which may explain why we see this problem here.

repo: ara-lang/highlighting


text:
Dx 35 cli create publish plugin script

aragon publish command: publishes the plugin into Aragon OSx protocol and creates a PluginRepo instance containing the plugin’s first version.
video of command
video of failure case

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:

repo: aragon/cli


text:
Reverse Proxy setting 'frontend.trusted-proxy' address parsing broken

My Environment

ArangoDB Version:        3.6.1
Storage Engine:             RocksDB
Deployment Mode:       Active Failover
Deployment Strategy:   ArangoDB Starter
Configuration:               3 hosts in Active Failover
Infrastructure:               AWS
Operating System:        Amazon Linux 2
Total RAM in your machine:        4GB
Disks in use:        SSD, 8GB
Used Package:              .rpm

Component, Query & Data
Affected feature:
Reverse proxy fails because IPv4 addresses are incorrectly parsed
Steps to reproduce

Create 3 nodes, connect them together with starter command via --starter.join "IP1, IP2, IP3"
Specify the following in the starter command:
--all.frontend.proxy-request-check=true
--all.frontend.trusted-proxy=$(StarterProxyIP)
After starting ArangoDB on all 3 nodes, run the following command on the leader:
curl http://localhost:8529/_db/_system/_admin/aardvark.index.html.

Problem:
Server returns 500 internal server error.
Expected result:
Server returns 200, along with the default page.
Explanation and Potential Solution
The following error appears in the log file 'arangod.log' under 'resilientsingle8529' in the specified data directory:
2020-03-11T16:49:55Z [17473] ERROR [24213] Service "/_admin/aardvark" encountered error 500 while handling GET http://localhost:8529/_db/_system/_admin/aardvark/index.html
2020-03-11T16:49:55Z [17473] ERROR [24213] via Error: Invalid byte: ::ffff:127
2020-03-11T16:49:55Z [17473] ERROR [24213]     at ip2long (/usr/share/arangodb3/js/node/node_modules/netmask/lib/netmask.js:23:15)
2020-03-11T16:49:55Z [17473] ERROR [24213]     at Netmask.contains (/usr/share/arangodb3/js/node/node_modules/netmask/lib/netmask.js:106:17)
2020-03-11T16:49:55Z [17473] ERROR [24213]     at trustedProxyBlocks.some (/opt/arangodb/data0/resilientsingle8529/data/js/server/modules/@arangodb/foxx/router/request.js:64:30)
2020-03-11T16:49:55Z [17473] ERROR [24213]     at Array.some (<anonymous>)
2020-03-11T16:49:55Z [17473] ERROR [24213]     at shouldTrustProxy (/opt/arangodb/data0/resilientsingle8529/data/js/server/modules/@arangodb/foxx/router/request.js:64:8)
2020-03-11T16:49:55Z [17473] ERROR [24213]     at new SyntheticRequest (/opt/arangodb/data0/resilientsingle8529/data/js/server/modules/@arangodb/foxx/router/request.js:89:13)
2020-03-11T16:49:55Z [17473] ERROR [24213]     at Tree.dispatch (/opt/arangodb/data0/resilientsingle8529/data/js/server/modules/@arangodb/foxx/router/tree.js:133:19)
2020-03-11T16:49:55Z [17473] ERROR [24213]     at callback (/opt/arangodb/data0/resilientsingle8529/data/js/server/modules/@arangodb/foxx/service.js:346:35)
2020-03-11T16:49:55Z [17473] ERROR [24213]     at execute (/opt/arangodb/data0/resilientsingle8529/data/js/server/modules/@arangodb/actions.js:1234:7)
2020-03-11T16:49:55Z [17473] ERROR [24213]     at routeRequest (/opt/arangodb/data0/resilientsingle8529/data/js/server/modules/@arangodb/actions.js:1253:3)

We can see Error: Invalid byte: ::ffff:127 being the main problem here.
Adding a print statement to 'resilientsingle8529/data/js/server/modules/@arangodb/foxx/router/request.js' within the function 'shouldTrustProxy' to print out the address gives us '::ffff:127.0.0.1'.
The IPv6 prefix is not being removed from the incoming request address.
Modifying the function 'shouldTrustProxy' to that below solves the issue;
function shouldTrustProxy (address) {
  if (address.substr(0, 7) == "::ffff:") {
    address = address.substr(7)
  }
  if (trustedProxyBlocks === undefined) {
    trustedProxyBlocks = generateTrustedProxyBlocks();
  }
  return !trustedProxyBlocks || trustedProxyBlocks
      .some((block) => block.contains(address));
}

After updating the function as above, I can access the default page via my reverse proxy with no issues and no errors in the log as before.

Link to the function itself within the project

repo: arangodb/arangodb