text:
Fix resultTransformer for ObservableQuery#currentResult, and deep freeze in more cases

Result transformer was previously not being run when calling currentResult on an ObservableQuery.
This also moves maybeDeepFreeze into transformResult to catch more cases where results are being emitted and not being frozen (queryListenerForObserver )

I'm not very familiar with this but what is the benefit of deep freezing at all? Is it a performance concern?

@Poincare I think it's a safety thing (don't accidentally modify results and then rely on those changes).  See https://github.com/apollostack/apollo-client/commit/41a39195040ca4d8de735a67e66dfe705cc187ba and https://github.com/apollostack/apollo-client/commit/3b60ba3bc4c8158f7a26654e7ab70594eecbf3b7

In case it helps, here's some context on how I've been using resultTransformer. I would be interested to know if your proposal breaks my code.  Esentially, what I'm doing here is converting apollo result objects into class objects (i.e Entity Models). This allows me to add view model behaviour and state to my apollo results directly and allows me to pass Entity typed objects as props into components.
const dataStore = new ApolloClient({
    networkInterface,
    resultTransformer: (result: ApolloQueryResult) => {

        // console.log("transform", result)

        let data = result.data

        let walk = (o) => {
            for (let k in o) {
                let v = o[k]

                if (v) {

                    // Map object to type
                    if (v.hasOwnProperty("__typename")) {
                        let t = Types[v.__typename]
                        if (t) {
                            o[k] = Object.assign({ __proto__: t.prototype }, v);
                        }
                    }

                    if (typeof v === "object") {
                        walk(o[k])
                    }
                }
            }
        }

        walk(data)

        return {
            data: result.data,
            loading: false,
            networkStatus: result.networkStatus
        };
    },
})

@dcworldwide I think @nevir is doing pretty much the same thing. If it's at all possible, I would prefer supporting that kind of functionality with an addon package rather than putting it in the core of Apollo Client.

If it's at all possible, I would prefer supporting that kind of functionality with an addon package rather than putting it in the core of Apollo Client.

I'm not sure how feasible that is today - from what I can tell, we would need to monkey patch QueryManager's prototype at all the points currently being hooked for this.  How stable do you think that interface will be?
(Building a facade around the entire client seems even more fragile, given the sheer number of entry points)

Hopefully this helps give another use case.  I've just stumbled onto resultTransformer, and it does exactly what I need.  I have an API that is returning a JSON string in a field that I only want to parse once (when it's received).  resultTransformer looks like it will let me do that exactly how I was hoping I could.

Unfortunately, not really - resultTransformer is called every time the
result of a query changes, before returning data to the caller (not before
placing the result into the store)
The main reason for this is that Apollo persists state in redux in a
normalized format - it has to reconstruct final objects to pass to callers
every time query results change
On Fri, Jan 27, 2017, 05:45 Ethan Garofolo notifications@github.com wrote:

Hopefully this helps give another use case. I've just stumbled onto
resultTransformer, and it does exactly what I need. I have an API that is
returning a JSON string in a field that I only want to parse once (when
it's received). resultTransformer looks like it will let me do that
exactly how I was hoping I could.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apollostack/apollo-client/pull/1151#issuecomment-275668166,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAChnRdgEsRiXy8wwvDaKu5OUZEapZHfks5rWfT-gaJpZM4LekuG
.

Gotcha.  Thanks for the clarification.

Sorry for the delay on this @nevir. I'm going to close this PR because I don't see the place where you say deep freezing is missing in queryListenerForObserver, and because I'm about to remove resultTransformer from the API for 1.0 RC. However, I do see the use-case for transforming results and I appreciate the difficulty of getting it right, so I'd be happy to assist in creating and recommending an external package that does it. I hope that works for you!

@heifer yeah please do. I'll still need a design to transform my results before I pass them into view props.

So now that result transformer is gone....how do I best transform my apollo data? Using will component update? @heifer .... any other ideas?

authors: Poincare dcworldwide helfer juanpaco nevir

repo: apollostack/apollo-client


text:
refetch should only modify variables on original query

I noticed recently when using refetch that requests kept being made when other changes caused a component to rerender. This was traced back to the refetch method incorrectly changing the options on the query to set forceFetch to be true versus having it only apply to the manual refetch call.
TODO:

[X] If this PR is a new feature, reference an issue where a consensus about the design was reached (not necessary for small changes)
[X] Make sure all of the significant new logic is covered by tests
[X] Rebase your changes on master so that they can be merged easily
[X] Make sure all tests and linter rules pass
[X] Update CHANGELOG.md with your change
[X] Add your name and email to the AUTHORS file (optional)
[X] If this was a change that affects the external API, update the docs and post a link to the PR in the discussion

nice catch @NeoPhi! Thanks a lot!

source: gharchive/pull-request

authors: NeoPhi helfer

license: mit

license_type: permissive

license_source: bigquery


text:
fix: pu name being reveresed when claims are bad

--> When the token is missing or invalid, we mistakenly reverse the pu name and report it.

/build - automatically fired by gogo with following PRs and commit SHAs v1.0.0
[
  {
    "project": "",
    "component": "enforcerd",
    "pr-id": "1559",
    "commit-sha": "be66ef983d16066066a6c086c8350ab2b3978a41",
    "pipeline": "master"
  },
  {
    "project": "",
    "component": "trireme-lib",
    "pr-id": "958",
    "commit-sha": "f6499faa94a16f134c7de907e1dcf0f850db2aaa",
    "pipeline": "master"
  }
]

/build - automatically fired by gogo with following PRs and commit SHAs v1.0.0
[
  {
    "project": "",
    "component": "enforcerd",
    "pr-id": "1567",
    "commit-sha": "0e0f4cfd3c49c71152da486af872071aa789bff7",
    "pipeline": "master"
  },
  {
    "project": "",
    "component": "trireme-lib",
    "pr-id": "958",
    "commit-sha": "f6499faa94a16f134c7de907e1dcf0f850db2aaa",
    "pipeline": "master"
  }
]

/build - automatically fired by gogo with following PRs and commit SHAs v1.0.0
[
  {
    "project": "",
    "component": "enforcerd",
    "pr-id": "1582",
    "commit-sha": "523ed33fd6f27d7ceb602edd200900645bf32ddf",
    "pipeline": "master"
  },
  {
    "project": "",
    "component": "trireme-lib",
    "pr-id": "958",
    "commit-sha": "ffadee9b09c2719d374e2c14eb5a23eb2590ef4d",
    "pipeline": "master"
  }
]

/build - automatically fired by gogo with following PRs and commit SHAs v1.0.0
[
  {
    "project": "",
    "component": "enforcerd",
    "pr-id": "1582",
    "commit-sha": "523ed33fd6f27d7ceb602edd200900645bf32ddf",
    "pipeline": "master"
  },
  {
    "project": "",
    "component": "trireme-lib",
    "pr-id": "958",
    "commit-sha": "ffadee9b09c2719d374e2c14eb5a23eb2590ef4d",
    "pipeline": "master"
  }
]

/build - automatically fired by gogo with following PRs and commit SHAs v1.0.0
[
  {
    "project": "",
    "component": "enforcerd",
    "pr-id": "1582",
    "commit-sha": "523ed33fd6f27d7ceb602edd200900645bf32ddf",
    "pipeline": "master"
  },
  {
    "project": "",
    "component": "trireme-lib",
    "pr-id": "958",
    "commit-sha": "ffadee9b09c2719d374e2c14eb5a23eb2590ef4d",
    "pipeline": "master"
  }
]

/build - automatically fired by gogo with following PRs and commit SHAs v1.0.0
[
  {
    "project": "",
    "component": "enforcerd",
    "pr-id": "1586",
    "commit-sha": "74fdae0273e9e9cf26b86c990f53aa90f6f3dc34",
    "pipeline": "master"
  },
  {
    "project": "",
    "component": "trireme-lib",
    "pr-id": "958",
    "commit-sha": "ffadee9b09c2719d374e2c14eb5a23eb2590ef4d",
    "pipeline": "master"
  }
]

repo: aporeto-inc/trireme-lib

license_source: github-api


text:
update build toolchain

remove build.sh since it cannot include the template file
update gomake. Remove all godep usage, fix upx check
fix blablacar/dist import package

Seems fine to me

repo: appc/acserver


text:
log: introduce Logger interface

This introduces a new Logger interface to allow swappable debug, and
info loggers for consumers of the library.
These loggers are compatible with the "log" stdlib logger.
This PR also does a refactoring/cleanup in preparation for #216.
Fixes #136

I did this in the plane, so let's see, if I pass the CI.

LGTM, thanks for the refactoring!

Needs a rebase

Rebased, LGTM, merging. And thanks :)

authors: euank jonboulle lucab s-urbaniak


text:
APK size due to material-icons-extended dependency

Hi, we recently noticed an increase in the size of our application's debug build by about 6 MB, we looked at dependencies and found androidx.compose.material:material-icons-extended required by AppCues. On developer.android.com we read

contains the full set of Material icons. Due to the very large size of this library, make sure to use R8/Proguard to strip unused icons if you are including this library as a direct dependency

We use R8 to do the release build and we have a doubt that there may be problems by removing the resources.
It seems strange to us that this dependency is needed, is it a bug?

thank you @nelletto for bringing this issue, we overlooked this new inclusion on the project, we actually prefer not including extra dependencies whenever possible since we can conflict with your versions, we actually want two Material icons or similar so we decided to remove the library and manually import the Icons to use it in our Debugger.
#652 is the change proposed here, hopefully that will look better on your end after we publish this small patch.
That said are you on Native android SDK, Segment or any of the x-platforms, so we can plan the patch fix for you.

source: gharchive/issue

authors: andretortolano nelletto

repo: appcues/appcues-android-sdk

license: MIT


text:
Feature Request: Windows Support for Monocore

Problem Statement
Currently, monocore only supports Linux and macOS operating systems. Adding Windows support would significantly expand the user base and enable Windows developers to leverage monocore's lightweight VM orchestration capabilities.
Proposed Solution
Add support for Windows by:

Porting monocore's Unix-specific code to work on Windows
Working with upstream libkrun/libkrunfw projects to add Windows Hypervisor Platform support
Implementing Windows-specific alternatives for Unix features

Detailed Requirements
Monocore Project Changes

Path Handling

Replace Unix-style paths with Windows path handling
Update path separator logic in utils/path.rs
Handle drive letters and UNC paths

Process Management

Replace Unix process management with Windows equivalents
Update supervisor code to use Windows process APIs
Implement alternative for Unix signals (SIGTERM etc.)

File System

Update file permission handling (Unix 0755/0644 style)
Handle Windows-specific file locking
Implement Windows alternatives for symlinks

Networking

Replace Unix socket code with Winsock
Update port mapping for Windows networking stack
Handle Windows firewall integration

Libkrun Changes Required

Hypervisor Integration

Add Windows Hypervisor Platform (WHP) support
Implement WHP-specific VMM functionality
Port virtio device implementations to Windows

File System Support

Implement Windows equivalent for virtio-fs
Handle Windows path mapping in VM
Support NTFS permissions

Networking Stack

Port TSI (Transparent Socket Impersonation) to Windows
Implement Windows networking backend
Support Windows-specific network isolation

System Calls

Replace epoll with Windows IOCP
Handle Windows-specific syscall translation
Implement Windows alternatives for Unix-specific features

Libkrunfw Changes Required

Kernel Support

Add Windows boot support
Implement Windows-specific kernel parameters
Handle Windows firmware requirements

Build System

Add Windows build targets
Support MSVC toolchain
Handle Windows-specific dependencies

Technical Challenges

Core Architecture Differences

Unix vs Windows process model differences
File system permission model differences
Signal handling vs Event model

Hypervisor Integration

Windows Hypervisor Platform API differences
Memory management model differences
Device model compatibility

Build and Distribution

Windows-specific build toolchain
DLL vs SO handling
Windows package management

Implementation Phases

Phase 1: Initial Windows Port

Basic Windows build system setup
Core functionality porting
Essential feature support

Phase 2: Feature Parity

Full Windows API support
Complete networking stack
File system feature parity

Phase 3: Performance Optimization

Windows-specific optimizations
Performance testing and tuning
Production readiness

Success Metrics

Functionality

All core features working on Windows
Feature parity with Unix version
Passing test suite on Windows

Performance

Comparable startup time to Unix version
Similar resource usage metrics
Acceptable VM performance

User Experience

Seamless Windows integration
Native Windows tooling support
Good developer experience

References

Windows Hypervisor Platform API
Libkrun Issue #147 - Windows Support Discussion
Rust-VMM Windows Support Status

Notes
This is a significant undertaking that will require coordination with upstream projects. The main blocker is getting libkrun and libkrunfw working on Windows, as noted in libkrun issue #147. While Windows Hypervisor Platform provides the necessary virtualization capabilities, significant work is needed to port the Unix-specific code and implement Windows alternatives for various system features.
The effort is feasible but will require dedicated resources and coordination with the broader container/virtualization community. It's recommended to approach this in phases, starting with basic Windows support in monocore while working with upstream projects to add Windows support to their codebases.

I’ve been reevaluating my approach to adding Windows support and am considering using QEMU instead of porting libkrun. QEMU is a stable and well-supported virtualization solution on Windows, which could reduce the amount of platform-specific code needed to be maintain. However, monocore project relies on a custom TSI (Transparent Socket Impersonation) implementation, and I’m not sure how QEMU handles TSI on Windows or if we can integrate our version easily. Additionally, integrating our custom TSI with QEMU’s networking stack might require significant adjustments.

repo: appcypher/monocore


text:
Question

Thank you so much for putting this together. This has helped me a lot! One question, where can I do a get call to my api to return some data?
Thank you again!

Hi RaySheikh, thank you for the kind words!
In the App.js file we've got two examples of network requests:
https://github.com/appfoundry/react-adal-authentication-session-sample/blob/82cdbce98a836bba924b289ce5236bf186aa8a33/src/App.js#L8-L12
and
https://github.com/appfoundry/react-adal-authentication-session-sample/blob/82cdbce98a836bba924b289ce5236bf186aa8a33/src/App.js#L24-L30
There are other ways for doing network requests, such as with a state manager(like redux) and a framework for side effects (like saga/mobx), but I would forward you to their respective documentation for that.
I hope this helps you with your question!

authors: CauseOfDev RaySheikh


text:
VS2017 enters break mode during test execution

When running my tests in debug mode, VS2017 suddenly enters break mode, although I did not set any break points. And because it obviously didn't break in my code, it does not show any source code. I can continue, and it typically works, but sometimes this break mode comes right in the middle of an selection or similar, which then fails the whole test.
I'm experiencing this with Appium version v1.7.1 (installed via node.js 6.11.5) on Windows 10 (1709).
My application under test is a Windows WPF / C# application. The Appium.WebDriver is version 3.0.0.2, MSTest.TestAdapter is 1.2.0, Selenium.WebDriver is 3.6.0
It looks to me as if this happens always after the same time, not depending on the test itself. On my PC, it happens after approx. 1 minute, regardless of what test is running. Even if I defer some execution in one test (i.e. Thread.Sleep(20000), it still happens after 1 minute, so it looks to me as if it would be independent from the actual test code.
I asked colleagues to test, and the basically support my findings, but with different times (colleague A around 2:20min, colleague B around 3:50).
Any idea is highly appreciated

@smoeller-liveid were you able to figure this? if not can you send what capabilities you set? a sample test which shows the problem? a screenshot for what you mean by 'break mode' and the appium logs for the test execution?

The capabilities are as follows:
appCapabilities.SetCapability("deviceName", "WindowsPC");
appCapabilities.SetCapability("app", applicationPath);
So I think there's nothing special.
Unfortunately, I could not find time till to create a sample yet, but this is definitively on my list.
In regards to the logs, is there a way to write them to file (I currently just see them flushing through the Powershell window)?

authors: rajfidel smoeller-liveid

repo: appium/appium-dotnet-driver


text:
Can't print from IOS device. No error log

I have a small problem. I can't get printing working from my mobile IOS devices. The devices are finding the printer, en CUPS recieved the job. Under tab Jobs I can see that CUPS recieved the file and that it should be printing but it isn't. I can't find anny error in the log files. Printing from my PC's works fine and reacts in the UI the same as from an IOS device.
Access log:
192.168.2.21 - pi [03/Apr/2018:11:01:32 +0200] "GET /admin/log/error_log? HTTP/1.1" 200 1014 - -
[v1.2a02:a448:f7a2:1:50e4:ec2a:6c3e:d98a] - - [03/Apr/2018:11:01:51 +0200] "POST /printers/Brother_DCP-7030 HTTP/1.1" 200 489 Validate-Job successful-ok
[v1.2a02:a448:f7a2:1:50e4:ec2a:6c3e:d98a] - - [03/Apr/2018:11:01:51 +0200] "POST /printers/Brother_DCP-7030 HTTP/1.1" 200 473 Create-Job successful-ok
[v1.2a02:a448:f7a2:1:50e4:ec2a:6c3e:d98a] - - [03/Apr/2018:11:01:51 +0200] "POST /printers/Brother_DCP-7030 HTTP/1.1" 200 23126 Send-Document successful-ok
192.168.2.21 - pi [03/Apr/2018:11:01:56 +0200] "GET /admin/log/access_log? HTTP/1.1" 200 557 - -
Error log:
W [03/Apr/2018:10:52:11 +0200] Max clients reached, holding new connections...
W [03/Apr/2018:11:02:03 +0200] Max clients reached, holding new connections...
Page log:
Brother_DCP-7030 mobile 54 [03/Apr/2018:11:02:05 +0200] 1 1 - [v1.2a02:a448:f7a2:1:50e4:ec2a:6c3e:d98a] iBooks - one-sided

Sorry, but we don't support using CUPS as a server for iOS or AirPrint - it doesn't support everything needed for it to work reliably.

authors: jerwij michaelrsweet

repo: apple/cups


text:
cups crashes when log options is empty

1, have a wrongly written directive for new way for logging:
#AccessLog syslog
AccessLog
^ no file after this option
2, cups cannot start, coredump
Process Core Dump (PID 21244/UID 0).
START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@3-21244-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
ervice: Main process exited, code=dumped, status=11/SEGV
ervice: Failed with result 'core-dump'.
STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=cups comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
1245]: Process 21236 (cupsd) of user 0 dumped core.
   Stack trace of thread 21236:
   #0  0x000055bd6bbdd8ce cupsdLogRequest (cupsd)
   #1  0x000055bd6bbbf9a1 cupsdWriteClient (cupsd)
   #2  0x000055bd6bbe9c3b cupsdDoSelect (cupsd)
   #3  0x000055bd6bbb724b main (cupsd)
   #4  0x00007ff10863ef6a __libc_start_main (libc.so.6)
   #5  0x000055bd6bbb857a _start (cupsd)

it could say its wrongly used or something

Confirmed.

[master 9dcb503fa] Fix crash when AccessLog is NULL (Issue #5309)
[branch-2.2 dfe519269] Fix crash when AccessLog is NULL (Issue #5309)

authors: michaelrsweet psklenar


text:
[5.7] Empty TextEdits now return nil

Cherry-picks https://github.com/apple/sourcekit-lsp/pull/602 to release/5.7.

This adds a check when creating a TextEdit to return nil if both the fixit and the replacement being used to create a TextEdit are empty. A TextEdit being created like this can cause a crash.
Resolves https://github.com/apple/sourcekit-lsp/issues/635

@swift-ci Please test

repo: apple/sourcekit-lsp


text:
Ignore RST-to-markdown commit when blaming

For comparison, here are links to the tour's blame view with and without this setting.
Without: https://github.com/apple/swift-book/blame/main/TSPL.docc/GuidedTour/GuidedTour.md
With: https://github.com/amartini51/swift-book/blame/ignored_revs/Sources/TSPL/TSPL.docc/GuidedTour/GuidedTour.md
Without this setting, almost half of the lines of the tour are attributed to commit 96f092540, the RST-to-markdown conversion.  With it, we get much more useful blame information:
% git blame GuidedTour.md | cut -d' ' -f 1 | sort | uniq -c | sort -n | tail
   8 a79e857ab
  10 c3e2f1463
  10 dfde955ed
  10 fe966592c
  11 41be57f94
  13 ee49b93bc
  15 cee94fdde
  30 940f17d35
 174 8e84be0fc
1770 96f092540

% git blame --ignore-revs-file .git-blame-ignore-revs GuidedTour.md | cut -d' ' -f 1 | sort | uniq -c | sort -n | tail
  34 ?0b8780e1
  36 ?91f5caa3
  37 ?8a84bcd0
  41 ?4df08a42
  56 ?1ead879d
  63 ?a6b8b6dd
  72 ?63fd3c59
 112 ?e3db956b
 174 8e84be0fc
 603 96f092540

I'll take a more thorough look at the comparison later, but this seems great! Never knew you could configure this.

@krilnon I just found out about this feature recently too, and it seemed like exactly what TSPL needed to reduce the blame noise from RST-to-markdown translation.

repo: apple/swift-book


text:
Remove version number used in 'available' attribute for non-specific platform '*'.

This patch aims to make swift-corelibs-libdispatch adapted to this PR, which warns for version number in 'available' attribute for non-specific platform '*'.

Do we care about watchOS and tvOS too? tvOS version numbers match iOS's, but watchOS's don't.

I agree with Jordan - the tvOS and watchOS deprecations should also be included.

I don't think I or Ding knows for sure what those should be! It's also a little funny that these are just in corelibs-dispatch, which is never used on iOS/tvOS/watchOS. Or did we miss some in the overlays too?

Thank you for the feedbacks, Jordan and Kim!
Can we just remove those lines of @available(*, deprecated: 8.0, ...) here? Just take a look at the relevant part in master. There are attributes for four platforms macOS/iOS/tvOS/watchOS, among which I think keeping only macOS is sufficient for swift-corelibs-libdispatch project.

I suspect that SCD is trying to match the contents of the Darwin overlay exactly for most of these files, and that they should therefore be kept in sync.

Alright, let's keep it in sync. This is a conservative solution anyway.

@swift-ci Please test Linux

authors: dingobye jrose-apple ktopley-apple

repo: apple/swift-corelibs-libdispatch


text:
[5.7] Fix scrollbars not showing for CodeListing in Safari

Rationale: Fixes a bug where codelisting scrollbars are sometimes hidden in Safari, until you resize the screen.
Risk: Low
Risk Detail: Small isolated CSS fix
Reward: Medium
Reward Details: Safari users will always see scrollbars, when they are needed
Original PR: https://github.com/apple/swift-docc-render/pull/305
Issue: rdar://78783950
Code Reviewed By: @mportiz08
Testing Details: Tested manually in the browser

@swift-ci test

repo: apple/swift-docc-render


text:
Development with SourceKit-LSP

Is there any way to configure the project so that development with SourceKit-LSP works correctly?
When opening LadderFilter.swift, an error appears for import VultDSP:
Could not build C module 'VultDSP' SourceKit

And in the errors I get
<wasi/api.h> only supports wasm32; doesn't yet support wasm64
...

In the output from SourceKit-LSP I can see:
sourcekit: [1:getCursorInfo:426.8573] error creating ASTInvocation: warning: option '-incremental' is only supported in swift-driver
<unknown>:0: warning: option '-incremental' is only supported in swift-driver
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:2:10: note: in file included from <module-includes>:2:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/endian.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/endian.h:19:17: error: unknown type name 'uint16_t'
static __inline uint16_t __bswap16(uint16_t __x)
                ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:2:10: note: in file included from <module-includes>:2:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/endian.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/endian.h:19:36: error: unknown type name 'uint16_t'
static __inline uint16_t __bswap16(uint16_t __x)
                                   ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:2:10: note: in file included from <module-includes>:2:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/endian.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/endian.h:24:17: error: unknown type name 'uint32_t'
static __inline uint32_t __bswap32(uint32_t __x)
                ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:2:10: note: in file included from <module-includes>:2:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/endian.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/endian.h:24:36: error: unknown type name 'uint32_t'
static __inline uint32_t __bswap32(uint32_t __x)
                                   ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:2:10: note: in file included from <module-includes>:2:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/endian.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/endian.h:29:17: error: unknown type name 'uint64_t'
static __inline uint64_t __bswap64(uint64_t __x)
                ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:2:10: note: in file included from <module-includes>:2:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/endian.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/endian.h:29:36: error: unknown type name 'uint64_t'
static __inline uint64_t __bswap64(uint64_t __x)
                                   ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:27:2: error: <wasi/api.h> only supports wasm32; doesn't yet support wasm64
#error <wasi/api.h> only supports wasm32; doesn't yet support wasm64
 ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:31:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:31:
#include <stdint.h>
         ^
/home/bastian/Downloads/swift-DEVELOPMENT-SNAPSHOT-2024-05-15-a-ubuntu22.04/usr/lib/swift/clang/include/stdint.h:52:16: note: in file included from /home/bastian/Downloads/swift-DEVELOPMENT-SNAPSHOT-2024-05-15-a-ubuntu22.04/usr/lib/swift/clang/include/stdint.h:52:
# include_next <stdint.h>
               ^
/usr/include/stdint.h:26:10: note: in file included from /usr/include/stdint.h:26:
#include <bits/libc-header-start.h>
         ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:74:5: error: function-like macro '__GLIBC_USE' is not defined
#if __GLIBC_USE (IEC_60559_BFP_EXT) || __GLIBC_USE (ISOC2X)
    ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:31:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:31:
#include <stdint.h>
         ^
/home/bastian/Downloads/swift-DEVELOPMENT-SNAPSHOT-2024-05-15-a-ubuntu22.04/usr/lib/swift/clang/include/stdint.h:52:16: note: in file included from /home/bastian/Downloads/swift-DEVELOPMENT-SNAPSHOT-2024-05-15-a-ubuntu22.04/usr/lib/swift/clang/include/stdint.h:52:
# include_next <stdint.h>
               ^
/usr/include/stdint.h:26:10: note: in file included from /usr/include/stdint.h:26:
#include <bits/libc-header-start.h>
         ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:80:5: error: function-like macro '__GLIBC_USE' is not defined
#if __GLIBC_USE (IEC_60559_BFP_EXT) || defined __STDC_WANT_IEC_60559_EXT__
    ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:31:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:31:
#include <stdint.h>
         ^
/home/bastian/Downloads/swift-DEVELOPMENT-SNAPSHOT-2024-05-15-a-ubuntu22.04/usr/lib/swift/clang/include/stdint.h:52:16: note: in file included from /home/bastian/Downloads/swift-DEVELOPMENT-SNAPSHOT-2024-05-15-a-ubuntu22.04/usr/lib/swift/clang/include/stdint.h:52:
# include_next <stdint.h>
               ^
/usr/include/stdint.h:26:10: note: in file included from /usr/include/stdint.h:26:
#include <bits/libc-header-start.h>
         ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:97:5: error: function-like macro '__GLIBC_USE' is not defined
#if __GLIBC_USE (IEC_60559_FUNCS_EXT) || __GLIBC_USE (ISOC2X)
    ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:31:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:31:
#include <stdint.h>
         ^
/home/bastian/Downloads/swift-DEVELOPMENT-SNAPSHOT-2024-05-15-a-ubuntu22.04/usr/lib/swift/clang/include/stdint.h:52:16: note: in file included from /home/bastian/Downloads/swift-DEVELOPMENT-SNAPSHOT-2024-05-15-a-ubuntu22.04/usr/lib/swift/clang/include/stdint.h:52:
# include_next <stdint.h>
               ^
/usr/include/stdint.h:265:5: error: function-like macro '__GLIBC_USE' is not defined
#if __GLIBC_USE (IEC_60559_BFP_EXT_C2X)
    ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:41:16: error: static assertion failed due to requirement 'alignof(void *) == 4': non-wasi data layout
_Static_assert(_Alignof(void*) == 4, "non-wasi data layout");
               ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:41:32: note: expression evaluates to '8 == 4'
_Static_assert(_Alignof(void*) == 4, "non-wasi data layout");
                               ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:51:16: error: static assertion failed due to requirement 'sizeof(unsigned long) == 4': witx calculated size
_Static_assert(sizeof(__wasi_size_t) == 4, "witx calculated size");
               ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:51:38: note: expression evaluates to '8 == 4'
_Static_assert(sizeof(__wasi_size_t) == 4, "witx calculated size");
                                     ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:52:16: error: static assertion failed due to requirement 'alignof(unsigned long) == 4': witx calculated align
_Static_assert(_Alignof(__wasi_size_t) == 4, "witx calculated align");
               ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:52:40: note: expression evaluates to '8 == 4'
_Static_assert(_Alignof(__wasi_size_t) == 4, "witx calculated align");
                                       ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:689:16: error: static assertion failed due to requirement 'sizeof(__wasi_iovec_t) == 8': witx calculated size
_Static_assert(sizeof(__wasi_iovec_t) == 8, "witx calculated size");
               ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:689:39: note: expression evaluates to '16 == 8'
_Static_assert(sizeof(__wasi_iovec_t) == 8, "witx calculated size");
                                      ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:690:16: error: static assertion failed due to requirement 'alignof(__wasi_iovec_t) == 4': witx calculated align
_Static_assert(_Alignof(__wasi_iovec_t) == 4, "witx calculated align");
               ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:690:41: note: expression evaluates to '8 == 4'
_Static_assert(_Alignof(__wasi_iovec_t) == 4, "witx calculated align");
                                        ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:692:16: error: static assertion failed due to requirement '__builtin_offsetof(__wasi_iovec_t, buf_len) == 4': witx calculated offset
_Static_assert(offsetof(__wasi_iovec_t, buf_len) == 4, "witx calculated offset");
               ^
/home/bastian/Downloads/swift-DEVELOPMENT-SNAPSHOT-2024-05-15-a-ubuntu22.04/usr/lib/swift/clang/include/__stddef_offsetof.h:16:24: note: expanded from macro 'offsetof'
#define offsetof(t, d) __builtin_offsetof(t, d)
                       ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:692:50: note: expression evaluates to '8 == 4'
_Static_assert(offsetof(__wasi_iovec_t, buf_len) == 4, "witx calculated offset");
                                                 ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:710:16: error: static assertion failed due to requirement 'sizeof(__wasi_ciovec_t) == 8': witx calculated size
_Static_assert(sizeof(__wasi_ciovec_t) == 8, "witx calculated size");
               ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:710:40: note: expression evaluates to '16 == 8'
_Static_assert(sizeof(__wasi_ciovec_t) == 8, "witx calculated size");
                                       ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: note: while building module 'dlmalloc' imported from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:
#include <features.h>
         ^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/errno.h:6:
#include <wasi_api.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:711:16: error: static assertion failed due to requirement 'alignof(__wasi_ciovec_t) == 4': witx calculated align
_Static_assert(_Alignof(__wasi_ciovec_t) == 4, "witx calculated align");
               ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/dlmalloc/include/wasi_api.h:711:42: note: expression evaluates to '8 == 4'
_Static_assert(_Alignof(__wasi_ciovec_t) == 4, "witx calculated align");
                                         ^
<unknown>:0: error: too many errors emitted, stopping now
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/VultDSP/include/waveforms.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/VultDSP/include/waveforms.h:1:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/VultDSP/include/waveforms.h:1:
#include "../out.h"
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/VultDSP/include/../out.h:5:10: note: in file included from /home/bastian/Downloads/swift-for-wasm-examples-main/Sources/VultDSP/include/../out.h:5:
#include <stdint.h>
         ^
/home/bastian/Downloads/swift-DEVELOPMENT-SNAPSHOT-2024-05-15-a-ubuntu22.04/usr/lib/swift/clang/include/stdint.h:52:16: note: in file included from /home/bastian/Downloads/swift-DEVELOPMENT-SNAPSHOT-2024-05-15-a-ubuntu22.04/usr/lib/swift/clang/include/stdint.h:52:
# include_next <stdint.h>
               ^
/usr/include/stdint.h:26:10: note: in file included from /usr/include/stdint.h:26:
#include <bits/libc-header-start.h>
         ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33:10: error: could not build module 'dlmalloc'
#include <features.h>
         ^
/home/bastian/Downloads/swift-for-wasm-examples-main/Sources/swift-audio/Effects/LadderFilter.swift:13:8: error: could not build C module 'VultDSP'
import VultDSP
       ^
[org.swift.sourcekit-lsp:request-77] default 2024-05-19 20:53:59.8890 +0000
Succeeded (took 41.36097431182861ms)

It looks like the C flags in Package.swift are not used when building.
I tried creating a compile_flags.txt with target and defines like in the Package.swift, but that doesn't seem to get respected.

I'm not sure the report for this issue should stay in this repository, moving accordingly.

authors: MaxDesiatov turbolent

repo: apple/swift-for-wasm-examples


text:
Replace mapIntoContext with DWARF Archetype name lookup.

This change allows us to retire the last use of ide::getDeclFromMangledSymbolName().
rdar://problem/47798056
(cherry picked from commit 813b062a05a9f27d4f8c620c38e3149f32e693ea)

test with https://github.com/apple/swift/pull/22810
@swift-ci test

repo: apple/swift-lldb


text:
Allow #SWIFT_PACKAGE in Manifest

This defines #SWIFT_PACKAGE for the manifest file, previously it was only defined for all other files built with the package manager.
It’s a fix for part of https://bugs.swift.org/browse/SR-588 although it doesn’t do anything for using getenv() for custom env variables in the manifest.

Why is it useful to have that defined in the Manifest, the expectation is they are only ever parsed by the manager so it should always be true.

Daniel

On Jan 21, 2016, at 4:15 PM, Bastian Rinsche notifications@github.com wrote:
This defines #SWIFT_PACKAGE for the manifest file, previously it was only defined for all other files built with the package manager.
It’s a fix for part of https://bugs.swift.org/browse/SR-588 https://bugs.swift.org/browse/SR-588 although it doesn’t do anything for using getenv() for custom env variables in the manifest.
You can view, comment on, or merge this pull request online at:
https://github.com/apple/swift-package-manager/pull/115 https://github.com/apple/swift-package-manager/pull/115
Commit Summary
Allow #SWIFT_PACKAGE in Manifest
File Changes
M Fixtures/Miscellaneous/-DSWIFT_PACKAGE/Package.swift https://github.com/apple/swift-package-manager/pull/115/files#diff-0 (6)
M Sources/dep/Manifest.swift https://github.com/apple/swift-package-manager/pull/115/files#diff-1 (2)
M Tests/Functional/TestMiscellaneous.swift https://github.com/apple/swift-package-manager/pull/115/files#diff-2 (1)
Patch Links:
https://github.com/apple/swift-package-manager/pull/115.patch https://github.com/apple/swift-package-manager/pull/115.patch
https://github.com/apple/swift-package-manager/pull/115.diff https://github.com/apple/swift-package-manager/pull/115.diff
—
Reply to this email directly or view it on GitHub https://github.com/apple/swift-package-manager/pull/115.

Hm, I guess you're right, maybe just for consistency then? In theory there could be another build tool which tries to use the Package.swift, but I agree it's currently not actually useful.

I'd rather not add complexity without a clear use case. Generally I am fan of consistency, but the use of Swift as a manifest format is disconnected from "how we build your swift sources".

On Jan 21, 2016, at 4:42 PM, Bastian Rinsche notifications@github.com wrote:
Hm, I guess you're right, maybe just for consistency then? In theory there could be another build tool which tries to use the Package.swift, but I agree it's currently not actually useful.
—
Reply to this email directly or view it on GitHub https://github.com/apple/swift-package-manager/pull/115#issuecomment-173762619.

I agree with Daniel. Can you provide a clear use case?

No, sorry, I think I was too excited about understanding enough of the source to do this to actually think about its usefulness.

Hah :) np 👍🏻

authors: Memorion ddunbar mxcl

repo: apple/swift-package-manager


text:
Closure as repetition pattern in pack expansion not allowed

Steps to reproduce
https://github.com/apple/swift/blob/251becbbddd3710a272bbd5291efd419f24643b6/test/Constraints/pack-expansion-expressions.swift#L611-L614
Expected behavior
The above test case and SE-0393, which is marked as implemented and doesn’t place limitations on the kind of expression used as a repetition pattern, suggest this should work.
Subissues

#66917

Environment

Swift version 5.11-dev (LLVM 5601e23279f85d8, Swift 140caf63be3f0fe)

I think we have a few dupes of this already, pack expansions in closures are just not yet implemented.

Yes, I am sure a saw this before, anything reported against pack and closure is effectively the same thing with different manifestation.

Let's have this serve as an umbrella issue so that whoever implements this has easy access to all reported examples.

Sounds good!

I'm not sure if it's related, was just searching for the solution for some other issue, but recently got this one, which seems kinda related to the topic (Xcode doesn't show any description for the error)
I'd like to implement those functions. It might be not possible yet and in that case compiler should return some human readable error, however the code compiles successfully if those functions are not used, and compilation fails as soon as I add a caller.
/// Packs function parameters into a single tuple parameter
func pack<each Arg, Output>(
  _ f: @escaping (repeat each Arg) -> Output
) -> ((repeat each Arg)) -> Output {
  return { (arg: (repeat each Arg)) in
    f(repeat each arg)
  }
}

/// Destructures single tuple function parameter into separate args
func unpack<each Arg, Output>(
  _ f: @escaping ((repeat each Arg)) -> Output
) -> (repeat each Arg) -> Output {
  return { (arg: repeat each Arg) in
    f((repeat each arg))
  }
}

//// Compilation succeeds if this code is commented
//// Fails with "nonzero exit code" otherwise
//
//func test() {
//  typealias OriginalSignatute = (Int, String, Bool) -> Void
//  typealias PackedSignature = ((Int, String, Bool)) -> Void
//  typealias UnpackedSignature = OriginalSignatute
//
//  let f: OriginalSignatute = { int, string, bool in
//    print(int, string, bool)
//  }
//
//  let f_packed: PackedSignature = pack(f)
//  let f_packed_unpacked: UnpackedSignature = unpack(f_packed)
//}

That’s a different beast, opened #69320. This one is about applying repeat to a closure.

UPD: Collected some examples of weirdly failing variadic generics into a package

Thanks! We already have an issue for the first error in Handler.swift (#68369), I’ll handle reporting the rest. Please consider reporting any future issues directly to us as well.

authors: AnthonyLatsis maximkrouk xedin

repo: apple/swift


text:
[Clang importer] Lazily load all named members with a matching base name

When loading the named members for a given name, we want to load all
of the members with that base name... not only the ones that match the
full name, because the lookup table is indexed by base name and
filtering too early drops candidates.
Fixes rdar://problem/36085994.

@swift-ci please smoke test and merge


text:
[stdlib] Dictionary.Keys, .Values: Implement custom iterators

Implement custom iterators for Dictionary's two views.

@swift-ci please test

@swift-ci please smoke benchmark

@swift-ci please test source compatibility

cc @airspeedswift

Build comment file:
Performance: -O

TEST
OLD
NEW
DELTA
RATIO

Regression

StringComparison_fastPrenormal
840
919
+9.4%
0.91x

FloatingPointPrinting_Float_description_uniform
5182
5585
+7.8%
0.93x

Improvement

IterateData
1738
1564
-10.0%
1.11x (?)

CStringLongAscii
3538
3293
-6.9%
1.07x

UTF8Decode_InitFromData
1391
1295
-6.9%
1.07x (?)

Code size: -O

TEST
OLD
NEW
DELTA
RATIO

Regression

DictionarySwap.o
30403
33467
+10.1%
0.91x

Improvement

DictionaryKeysContains.o
20343
19395
-4.7%
1.05x

DictionaryBridgeToObjC.o
7543
7263
-3.7%
1.04x

Performance: -Osize

TEST
OLD
NEW
DELTA
RATIO

Regression

FloatingPointPrinting_Float_description_uniform
5193
5836
+12.4%
0.89x

Improvement

IterateData
1830
1626
-11.1%
1.13x

CStringLongAscii
3547
3295
-7.1%
1.08x

Code size: -Osize

TEST
OLD
NEW
DELTA
RATIO

Regression

DictionarySwap.o
26827
29091
+8.4%
0.92x

Improvement

DictionaryKeysContains.o
17735
17099
-3.6%
1.04x

DictionaryBridgeToObjC.o
7029
6917
-1.6%
1.02x

Performance: -Onone

TEST
OLD
NEW
DELTA
RATIO

Regression

StrToInt
82601
103552
+25.4%
0.80x

Improvement

DictionaryBridgeToObjC_Access
1859
1260
-32.2%
1.48x

CharIndexing_punctuated_unicodeScalars_Backwards
92817
76466
-17.6%
1.21x

CharIndexing_japanese_unicodeScalars
450228
376360
-16.4%
1.20x

CharIndexing_punctuated_unicodeScalars
83261
70008
-15.9%
1.19x

CharIndexing_tweet_unicodeScalars
738707
621306
-15.9%
1.19x

CharIndexing_tweet_unicodeScalars_Backwards
850535
717851
-15.6%
1.18x

CharIndexing_korean_unicodeScalars
359722
304015
-15.5%
1.18x

CharIndexing_ascii_unicodeScalars
370974
313740
-15.4%
1.18x

CharIndexing_chinese_unicodeScalars
279992
237081
-15.3%
1.18x

DropFirstArrayLazy
34391
31161
-9.4%
1.10x

PrefixArrayLazy
34214
31078
-9.2%
1.10x

How to read the data
The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

Source compat failure (fluent) is unrelated; see #19594.

authors: lorentey swift-ci


text:
IRGen: do not use WeakImport on PE/COFF

PE/COFF does not provide weak import semantics.  Fallback to strong
import semantics on PE/COFF.

@swift-ci please test


text:
SwiftRemoteMirror: Fix crash emitting capture descriptors involving i…

When emitting capture descriptors for functions with a smaller number of parameters
than SIL parameters, the compiler can crash indexing into the heap layout's element
types, because the capture index underflows to UINT_MAX.
rdar://problem/26404583

@swift-ci Please test


text:
[WIP] [gardening] Improvements to python-lint and check-incremental

What's in this pull request?
python-lint:

Add more comments, in particular a top-level comment explaining the
purpose and return code of the script.
Add the ability to limit the linting to specific files.
Use arithmetic comparisons when checking return codes.

check-incremental:

Use argparse instead of a homebrew argument parser.
Commonise the code for building and checking the md5/mtime of an
output file.
Use print_function for Python 3 compatibility.

Resolved bug number: (SR-)
Not fixing any Swift bugs that I know of.

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

The python-lint changes are entirely selfish – when I’m making edits, it’s easier to lint if I can restrict the checking to files that I’ve modified. It’s not like the original linter is slow – less than 10 seconds on my Mac – but making it even faster never hurts.

(Lightbulb moment)
If all these arguments are getting passed along to a build step somewhere, we don’t want argparse in the mix, because it chokes on all the extra arguments. Of course that only occurs to me after opening the PR. I’ll rethink and come back with a new PR.

@swift-ci Please Python lint

authors: alexwlchan gribozavr


text:
[SourceKit] Fix flakey completion tests

A previous change updated the checkdep tests to move the sleep before
copying over files. This fixed cases where the modification time would
be the same second as the dependency check. Unfortunately this
introduced a slightly different form of flakiness - if the sleep went
too long, the completion that was meant to re-use the AST would see that
it's time to check dependencies and thus skip the fast completion path.
One fix for that would be to add a smaller sleep before, a longer sleep
after, and increase the dependency check time. That increases the
runtime of the tests even further though, so instead just update the
timestamps manually to be in the past/future in order to invoke the path
we want to test. This also allows a 0 dependency check time (ie. always
check), which makes the tests even faster.
Resolves rdar://71861446

Note: I'm aware this does slightly change what the tests are checking. Given that it's just checking the times against now() though, it is roughly the same - just changing one rather than the other (ie. changing file time rather than current time, if that makes sense).
Another alternative is to keep the sleeps but also add in the touch, ie. move the sleep after the first fast completion and put a touch in there instead.
Let me know which you'd prefer!
@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - e13d800b10cfbc2cf928a0a7da62fbba3f917252

Changed the timestamps to 2100 rather than 3020. Nanoseconds since 1970 stored as a 64 bit signed integer only allows up to 2262.
@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - 34ff514ab19cdf9725fa8679e8288daa5f127c86

@swift-ci please test OS X platform

authors: bnbarham swift-ci


text:
Fix AutoreleasingUnsafeMutablePointer assignment.

Fix the implementation to obey the memory model by
using withMemoryRebound.
Also move toward using Unsafe not Opaque.

@swift-ci Please smoke test and merge.

This failed on an XCTest symbol--the one that's been breaking builds for the past couple days.


text:
[gardening] remove unnecessary condition in symbol extraction logic

This was introduced to avoid indentation changes when making this logic
amenable to testing in #37120 .

@swift-ci please smoke test

@swift-ci Please Build Toolchain

(Using "Hide whitespace changes" should show more clearly which lines are removed and which lines have changed indentation)

Linux Toolchain (Ubuntu 16.04)
Download Toolchain
Git Sha - 11fa67bdf3e2da4dc7d00775083e70fb243d923d
Install command
tar zxf  swift-PR-37428-593-ubuntu16.04.tar.gz
More info

macOS Toolchain
Download Toolchain
Git Sha - 11fa67bdf3e2da4dc7d00775083e70fb243d923d
Install command
tar -zxf  swift-PR-37428-982-osx.tar.gz --directory ~/

Skimmed the log for the toolchain, all the expected files are copied to the symroot, and dsymutil and strip run on those files

Retesting my changes after the test change I did in #37488

@swift-ci please smoke test

authors: edymtt swift-ci


text:
Add a fixit for attempting member lookup on Any.

What's in this pull request?

Add a fixit for attempting member lookup on Any.
Resolved bug number: (rdar://problem/27639935)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is built incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

Suggest casting to AnyObject or a more specific type.
rdar://problem/27639935

@swift-ci Smoke test and merge.

@CodaFi Care to review this version?

@jckarter Any feedback on the wording here?

Rather belated, but still LGTM.  Thanks!

authors: CodaFi rudkx


text:
Revert https://github.com/apple/swift/pull/41940 on release/5.7

Cherry-pick of https://github.com/apple/swift/pull/42234.
Resolves rdar://91382164.

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please test


text:
🍒 [5.7] Add CHANGELOG entry for #41849 and #42332

Original PR: #42360

@AnthonyLatsis do you mind rebasing this to fix the conflict?

Sure.

@swift-ci please test

authors: AnthonyLatsis DougGregor slavapestov


text:
[Parse] Improve error handling in parseList

Skip ahead if seeing any error while parsing list elements.
In most cases, we cannot expect that the following tokens could construct a valid element (with missing separator). Skip them, instead of trying to parse them as a next element.
Bailout if seeing tok::eof or token that can never start a element, after parsing an element.
This silences superfluous expected ',' separator error, or misleading expected declaration error. What we should emit is expected ')' in expression list or expected '}' in struct.
Don't emit missing closing token if we've already emitted any error while parsing elements.
[RFC] about this change: This might be too silence, but some of other places like this don't emit error for missing closing token.

@swift-ci Please smoke test

@swift-ci Please smoke test

@swift-ci Please smoke test

This LGTM, and I'm fine with omitting the closing-token error when there are other errors: we're basically trying to resync to something sane at that point anyway.

@DougGregor Thank you!
I'm going to merge this after re-running CI.

@swift-ci Please smoke test

authors: DougGregor rintaro


text:
SILGen: Skip the value-to-id peephole for types with nontrivial SIL lowering.

The emitNativeToBridgedValue code is not well-factored to pass down the formal type of the value being bridged, which is necessary to build a generic call to _bridgeAnythingToObjectiveC in the fallback case. To work around this issue, disable the expression peephole when the type is not a valid lowered SIL type as is. Short-term fix for rdar://problem/28318984.

@swift-ci Please test


text:
[cxx-interop] Fix foreign reference types with reference counting that live in a namespace.

Before this patch we tried to do lookup in the _ObjC module for the retain/release functions. Now we use the clang module that the reference type lives in.

@swift-ci please test


text:
[SILOptimizer] Fix typo in KeyPathProjector.h

addres -> address

@swift-ci please smoke test

authors: Azoy eltociear


text:
[Concurrency] Downgrade errors about actor-isolated witnesses to warnings until Swift 6 when the witness is a non-Sendable let.

https://github.com/apple/swift/pull/70909 changed actor lets to only be considered nonisolated if the property type conforms to Sendable. This caused new witness checker errors if an actor isolated let witnesses a nonisolated protocol requirement. Compiler versions <= 5.10 only diagnosed this as a Sendable violation under -strict-concurrency=complete, so the new witness checker diagnostic should only be diagnosed as a warning until Swift 6.

@swift-ci please smoke test


text:
[6.0][Features] FullTypedThrows should only be enable-able in asserts builds.

Explanation: The implementation of this experimental feature is not complete and it's not ready to be enabled in production. This experimental feature only gates the source-breaking parts of SE-0413: Typed throws, which will not be enabled by default in the Swift 6 language mode.
Scope: Only impacts which toolchains you can use the FullTypedThrows experimental feature flag in.
Risk: Low.
Testing: Updated existing tests to require asserts.
Main branch PR: https://github.com/apple/swift/pull/74446

@swift-ci please test


text:
[stdlib] Moving the Array.filter to _ArrayProtocol

Resolves ambiguity in the following expression
_ = Array(0..<10).lazy.flatMap { .some($0) }.filter { _ in false }
Fixes: rdar://problem/32316948

Explanation: Introducing Array.filter caused the source compatibility issue
Scope of Issue: Overload resolution could not pick the right set of overloads in an expression like [42].lazy.flatMap { .some($0) }.filter { _ in false }. This fix de-prioritizes Array.filter by moving it to _ArrayProtocol
Risk: Minimal
Reviewed By: Ben Cohen
Testing: Automated test suite + a dedicated test case
Directions for QA: N/A
Radar: rdar://problem/32370364

@swift-ci Please test

@swift-ci Please Test Source Compatibility

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 66ed3aa0805b9adf21445328d4e35cef4ffdf7b7
Test requested by - @moiseev

Similar to: https://github.com/apple/swift/pull/9888

authors: moiseev swift-ci


text:
C API for visualization: Round 1

In progress: C API for visualization. Should build and tests should pass as of this commit, but there is work left to do. If this looks good, please feel free to merge as-is and we can iterate on it in master.

@hoytak Comments addressed; please re-review, thanks!

repo: apple/turicreate


text:
SYNTAX ERROR

Use setState to update state instead of this.state.widget = ...

Unfortunatelly this causes a rerender. Instead we need to call grecaptcha.render() inside ref property or something else.

repo: appleboy/react-recaptcha


text:
Added json files at /test

cú

Adorei esse cú. Gostaria de dar uma sugada forte nesse cú.
Delicioso cú. Cheiroso cú. Adocicado cú. Depilado cú. Gostoso cú. Eu fico fascinado por cú.
Enfim eu estou apaixonado pelo cú dessa mulher. Deve ser um cú bem cheiroso e guloso também.

Esse cu é MTO GOSTOSO, PARECE UM Vectra CD turbo com Turbina Holset HX-35, Válvula de Alívio SPA Compact, Intercooler frontal,Pressurização em Alumínio 2,5",Escape 2,5" com 1 abafador JK, Pistões IASA 87mm (p/ 700cv), Bielas K1 (p/ 700cv), Parafusos ARP, Anéis NPR, Blockguard

authors: appositum douglasJovenil sqdorte

repo: appositum/jason


text:
Network performance tool

https://github.com/solarwinds/containers/blob/master/cnpt/README.md

https://github.com/mrahbar/k8s-testsuite

repo: appscode/pharmer


text:
Potential Issue With VOYAGER_* Environment Variables

Voyager injects environment variables describing IPs, Hosts and Ports for ingress frontends.  As an example for Service xyz and fronted in Voyager with an http frontend redirecting port 80 to frontend 443 Voyager injects these environment variables into (all ?) pods:
VOYAGER_XYZSVC_PORT=tcp://100.0.0.1:443
VOYAGER_XYZSVC_PORT_443_TCP=tcp://100.0.0.1:443
VOYAGER_XYZSVC_PORT_443_TCP_ADDR=100.0.0.1
VOYAGER_XYZSVC_PORT_443_TCP_PORT=443
VOYAGER_XYZSVC_PORT_443_TCP_PROTO=tcp
VOYAGER_XYZSVC_PORT_80_TCP=tcp://100.0.0.1:80
VOYAGER_XYZSVC_PORT_80_TCP_ADDR=100.0.0.1
VOYAGER_XYZSVC_PORT_80_TCP_PORT=80
VOYAGER_XYZSVC_PORT_80_TCP_PROTO=tcp
VOYAGER_XYZSVC_SERVICE_HOST=100.0.0.1
VOYAGER_XYZSVC_SERVICE_PORT=443
VOYAGER_XYZSVC_SERVICE_PORT_TCP_443=443
VOYAGER_XYZSVC_SERVICE_PORT_TCP_80=80
Because voyager creates an elb per voyager ingress, I am trying to use a design that put one voyager ingress in front of each type of service which may have many different service deployments.  This should keep the number of elbs down to a predictable and stable number.
However I am concerned about how many env vars are going to be injected into pods and furthermore weather this leaks information about other pods to an attacker that is able to execute commands in a compromised container.

These environment variables are injected by Kubernetes. See here: https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services
I don't think there is a way to disable this behavior.

authors: RisingPhorce tamalsaha

repo: appscode/voyager


text:
Using request DTOs instead of domain objects in APIs

Summary
While going through the codebase I observed that in controllers, at many places, we are using domain objects instead of a separate DTOs for handling API requests.
For example https://github.com/appsmithorg/appsmith/blob/c1b498f6b81dd67d707fd45c7dd40d6990486438/app/server/appsmith-server/src/main/java/com/appsmith/server/controllers/UserController.java#L54
Moreover, there are no validations in the object. (Ideally, they should not be present on domain objects)
Motivation

The first thing is using DTOs for requests separate the resource/controller layer from the service layer. DTO and domain objects can change independently from each other.
We can avoid littering our domain objects with Jackson and Java bean validation annotations.
Having a request DTO will help a backend engineer or a contributor to quickly understand what this API needs instead of understanding the domain object (In most of the cases domain objects contain some extra fields populated in the service layer).

Additional Context
For example, I wanted to explore the backend system locally (without digging into/running the frontend) so to access many of the APIs I had to create a User through the UserController APIs. But when I went to the create method I had to understand by looking into the User domain object that what fields to set, what is ignored etc. DTOs make this thing simple.

@pc9795 Thanks for opening this issue. You do make a good point.
I have 1 question though: Does creating a request DTO for each API mean that now we'll have to perform a deep copy of the object from the DTO to the domain object on each request? Vice-versa, will we have to perform a deep copy from domain object to DTO ( for GET API calls )? Is there a way to avoid all this copying?
Also, by any chance is there a reference code base you can point me to

@mohanarpit No need for manual copying. You can look into https://mapstruct.org/

Some code reference where I have used it: https://github.com/pc9795/portfolio/blob/master/src/main/java/com/prashantchaubey/dto/mappers/ContactMapper.java

@pc9795 Thanks for the pointer to mapstruct. #TIL
On reading a little more about it, in the generated code section, I can see that MapStruct implicitly creates the implementation class to copy data from the domain class to the DTO. This is the copy that I'm trying to avoid. It creates unnecessary garbage in the JVM and slows things down. A lot of this doesn't show up in the early days, but with a little load on the machine, the cost of these copies become apparent very quickly.
By design, the Appsmith backend server should be as light and performant as possible. Hence, if there's a better way to implement the "separation of concerns" principle that you suggested, I'd be more than willing to do that.

hmmmm, I have not thought in this way. I only used Map struct or wrote mappers by scratch.  For the starters there is this excellent article. I can dig in more but not sure as of now. But yeah using DTOs is debatable but IMO keeping things separate has its own benefits.

Closing this issue for now since we are not prioritizing this code change.

repo: appsmithorg/appsmith


text:
[Bug]: Tooltip of camera widget record button flashes on hover when placed on a modal widget

Is there an existing issue for this?

[X] I have searched the existing issues

Description
When a camera widget is placed on modal and user hovers over the record button, a tooltip appears on the top of the camera widget as seen in the video and blinks on hover. The cursor hovering over the record button flashes as well.
Steps To Reproduce

Drop a camera widget over a modal widget
Hover over the record button and observe the tooltip flash as seen in the video

Public Sample App
No response
Version
Cloud

Removed the tooltips, so closing this issue

authors: dilippitchika ramsaptami


text:
[Bug]: Setting oAuth2 as auth type on SaaS Integration breaks the DS creation flow.

When an integration that has oAuth2 tries to be installed, an error occurs and does not allow using this application.
Step to reproduce:

Creating a new integration in the Saas Manager App.
Add oAuth2 authentication type.
Update the integration.
Install the new integration.
Display an error message.

Video 1
Video 2

Note: oAuth2 has not been tested, since we are not using it on the integrations that are currently being worked on.

We first need to understand if this is caused by an incorrectly configured oAuth2 setup for a SaaS Integration or if the oAuth2 Setup for SaaS Integrations doesn't work at all.
Next steps would be to:

Find an API for testing and make a successful oAuth2 setup using only Authenticated APIs.
Set up the same, but with the SaaS App.
Check if it fails when installed on an Org.
If it doesn't fail and works fine, we might need to improve the validations to avoid broken oAuth2 configs (Related to #11087(


text:
[Bug]: The Unwanted data is displayed in the audit log  json

Is there an existing issue for this?

[X] I have searched the existing issues

Description
The Unwanted data is displayed in the json

Steps To Reproduce

Go to home page
click on members and setting tab
under others tab click on Audit log
Open any one of the event
at the bottom of the  json data
Is open = true data is displayed

Public Sample App
No response
Version
http://ec2-65-2-149-212.ap-south-1.compute.amazonaws.com/applications

The latest code is not deployed.

authors: IAmAnubhavSaini RakshaKShetty


text:
[Bug]: navigateTo parameters are being persistent when switching pages

Is there an existing issue for this?

[X] I have searched the existing issues

Description
I have a JS function which checks if there is a parameter in URL query and optionally shows modal on page load. The problem is argument passed via navigateTo persists when switch to other pages and returning back.
Sample Framework app can be used to reproduce this issue
https://app.appsmith.com/app/framework/navigateto-62566b650d3d384069c05830
Steps To Reproduce

Go to page NavigateTo
Update Current Page's Query Params
Go to any other page
Passed arguments are now appended to every page's URL

Public Sample App
https://app.appsmith.com/app/framework/navigateto-62566b650d3d384069c05830
Environment
Production
Severity
Medium (Frustrating UX)
Issue video log
No response
Version
Cloud

@art-jg thank you for reporting this! I need to validate the expected behaviour and we should indeed debug it, but meanwhile would you please describe your use-case so that I can try to find a way for you?
Easiest if you build a simple app to demonstrate the problem and invite support@appsmith.com as a developer to it.

authors: art-jg rohan-arthur


text:
[Feature] Rename Widgets "Actions" to "Events"

Summary
This feature aims to rename 'Actions' to 'Events' in the property pane
Motivation
Events communicate better the intent of that section in the property pane
https://user-images.githubusercontent.com/17744578/118364523-9d3c0e00-b54d-11eb-8f47-c5a629fbda48.mp4

I think they should be called "event triggers"

Nice suggestion, but that may be too lengthy for the property pane or what do you think?

...and ideally, event triggers refers to the interaction that starts the process (i.e on mouse over or on click) and not the response to the event

Verification not required

authors: cokoghenun hetunandu yatinappsmith


text:
[Bug] After installation through install.sh, restarting the VM stops app working

Description
User followed installation guide to install the app on VM and successfully deployed it, but after VM restart app stopped working
Steps to reproduce the behaviour:

Install app on VM through install.sh
Restart the VM instance

Important Details

Version: Self-Hosted : Oracle cloud
OS: Ubantu 20

This is expected behaviour. The Appsmith instance doesn't come up automatically on restart of the machine. Instead, we have to go to the installation directory and do a docker-compose up -d to bring it up. That command may need a sudo at the start, depending on your operating system.
@abhvsn Can we add this the docs and then close this issue perhaps? Thanks!

@vihar if we have made the changes in docs can we close this?

Surely there is a way to auto start AppSmith when the VM boots up? Making a sysadmin log in manually and doing a docker-compose up -d is not a good solution.
There seem be to be two schools of thought re starting up docker containers automatically on boot. One is to use external tools like cron/systemctl, the other to use a docker restart policy.
I tried adding restart: always to the docker-compose.yml for the nginx service but that didn't work.
So I tried adding restart: always to all the services in the docker-compose.yml and that did work!
Perhaps there is a better way of doing this, but shouldn't this be documented? Everybody that self hosts will probably want to do this.

Hey @abulka, thank you for sharing. I just created PR #6428 with this change. 🎉

@sharat87 cool! By the way, I'm not an expert at Docker, so hopefully the solution I found is 'best practice'!

@abulka, I would think it is. Considering that Docker documentation states that the containers can be manually stopped, and that won't trigger a autostart, it should be fine.
Also, being an expert is overrated. 😉

authors: abhvsn abulka sharat87


text:
fix: New user datasource test 404 issue fixed

Description
When a new user who signs up, creates datasource and tests it before saving it, then the test API is throwing 404 error. This PR fixes that issue
Fixes #19426
Media

A video or a GIF is preferred. when using Loom, don’t embed because it looks like it’s a GIF. instead, just link to the video

Type of change

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

How Has This Been Tested?

Manual
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

[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
[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:

[ ] 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=87f1791

Cypress test LGTM.

/ok-to-test sha=ed75c99


text:
test: flay table header validation

Xpath used to read the header text is flaky.
Solution:
Replacing xpath with css locator to make it stable

/ci-test-limit


text:
chore: add pageId and applicationSlug to all traces

Description
Add pageId and applicationSlug as common attributes to all spans
Fixes #Issue Number
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.Sanity"
:mag: Cypress test results

[!WARNING]
Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/11679770316
Commit: de6069395a4e0c6a92ad1604742f8e525b47ad28
Cypress dashboard.
Tags: @tag.Sanity
Spec:
It seems like no tests ran 😔. We are not able to recognize it, please check workflow here.
Tue, 05 Nov 2024 07:55:42 UTC

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

[ ] Yes
[x] No

/build-deploy-preview skip-tests=true

/build-deploy-preview skip-tests=true


text:
Deprecated API Usage - Apple will stop accepting submissions of apps that use UIWebView APIs

Hello, we have recently gotten this message with the last release of our app.  The only UIWebkit dependency in our app is in apptentive.

We identified one or more issues with a recent delivery for your app, "our app" 0.15.0 (4804). Your delivery was successful, but you may wish to correct the following issues in your next delivery:

ITMS-90809: Deprecated API Usage - Apple will stop accepting submissions of apps that use UIWebView APIs . See https://developer.apple.com/documentation/uikit/uiwebview for more information.
After you've corrected the issues, you can use Xcode or Application Loader to upload a new binary to App Store Connect.
Best regards,
The App Store Team

Thanks for the report. We're aware of this and will be releasing an update to address this within the next few days.

Apptentive team has released a new version 5.2.5 for this issue.

Closing this issue because as @spraveenk91 mentioned, we have released an update that removes references to UIWebView (and supports dark mode).

authors: aanelson frankus spraveenk91

repo: apptentive/apptentive-ios


text:
Added landing end page with full landing page (#21)

Description
Added landing end page and joined it with the footer in the full landing page.

Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] 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 not work as expected)
[ ] This change requires a documentation update

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my 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] Any dependent changes have been merged and published in downstream modules

@mrxshinji please review and merge the PR, this will also have partial web page in landing folder.

repo: appwex/izzy-health


text:
MajorProject

Hackathon Submission: <PROJECT_NAME>
Name of Team Lead
Enter your full name

GitHub handles of Team Members
Enter the GitHub handles of all your team members (including yourself) as separate bullet points

Are all of your team members registered on our Hackathon Signup page?
This is a mandatory step for all participants to be considered eligible for judging

[x] Yes
[ ] No

Rules and Code of Conduct
By submitting this PR, you agree to follow our Rules and Code of Conduct.

[x] Yes

Anything Else?
Any other feedback, queries or information you would like to share with us?

My project is here.

My project is here.

@KunalHarinkhede-27 thank you for submitting your project. I noticed in your submission that you have not used any Appwrite product. Using Appwrite Cloud is mandatory for the hackathon. Without that, your submission won't be considered valid. I would suggest that you spend the next month improving your submission. I am closing the PR for now, you can resubmit this project later once Appwrite is integrated into the project.


text:
🐛 Bug Report: Some icons from heroicons dont work

👟 Reproduction steps

"@appwrite.io/pink-icons" to your project
use

👍 Expected behavior
this icon should appear

👎 Actual Behavior
It's an empty div
🎲 Appwrite version
Version 1.2.x
💻 Operating system
Linux
🧱 Your Environment
@appwrite.io/pink - 0.0.6-rc.9
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Thank you for reporting this issue.

Hi @probablyArth - our team is looking into fixing this, thank you for reporting!

Hello, If the issue is not assigned to someone so can  I try to fix it please.

authors: goswamianshuman joeyouss probablyArth

repo: appwrite/pink


text:
Fixing Footer Of Website

Title and Issue number
Title : fixing footer of website #1145
Issue No. : #1145
Code Stack :
Close #1145

Video (mandatory)

fixed
Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md
[x] I have gone through the  contributing.md file before contributing

Additional context (Mandatory )
Are you contributing under any Open-source programme?

[X] I'm a GSSOC'24 contributor
[ ] I'm a SSOC'24 contributor

@apu52  please merge PR tommorow is last day to contribute


text:
Update index.html #1002

In contact us section after the user submits the form successfully, they see an alert box with the message "Email sent successfully! but the form was not reset. I have enhance the code so that the form will be reset, providing a better user experience.
Title : Enhancing the Contact Page
Issue No. :  #690
Are you contributing under any Open-source programme?
GSSoC'24 (Girlscript Summer of Code)

@apu52 sir please have a look into it. Also please add gssoc and level tag. Plus, you can have a check the form now get reset.
thank you

@apu52 please have a look add gssoc label and assignes my name


text:
Binary committed to the repo?

Hi @simar7 any reason why the trivy-db binary is part of the repo - https://github.com/aquasecurity/trivy-db/blob/master/cmd/trivy-db/trivy-db? I have a PR to remove it, please feel free to close it, if it's irrelevant. Thanks!

Hi @simar7 any reason why the trivy-db binary is part of the repo - https://github.com/aquasecurity/trivy-db/blob/master/cmd/trivy-db/trivy-db? I have a PR to remove it, please feel free to close it, if it's irrelevant. Thanks!

thanks for the PR! - good catch.

repo: aquasecurity/trivy-db


text:
Failed to watch *v1alpha1.ClusterSbomReport: failed to list *v1alpha1.ClusterSbomReport: json: cannot unmarshal array into Go struct field Metadata.items.report.components.metadata.tools of type v1alpha1.Tools

What steps did you take and what happened:
$ kubectl logs --selector "app.kubernetes.io/name=trivy-operator" --all-containers=true --since=4h
...
W0409 10:03:10.264337       1 reflector.go:539] pkg/mod/k8s.io/client-go@v0.29.3/tools/cache/reflector.go:229: failed to list *v1alpha1.ClusterSbomReport: json: cannot unmarshal array into Go struct field Metadata.items.report.components.metadata.tools of type v1alpha1.Tools
E0409 10:03:10.264646       1 reflector.go:147] pkg/mod/k8s.io/client-go@v0.29.3/tools/cache/reflector.go:229: Failed to watch *v1alpha1.ClusterSbomReport: failed to list *v1alpha1.ClusterSbomReport: json: cannot unmarshal array into Go struct field Metadata.items.report.components.metadata.tools of type v1alpha1.Tools
W0409 10:03:13.073809       1 reflector.go:539] pkg/mod/k8s.io/client-go@v0.29.3/tools/cache/reflector.go:229: failed to list *v1alpha1.ClusterSbomReport: json: cannot unmarshal array into Go struct field Metadata.items.report.components.metadata.tools of type v1alpha1.Tools
E0409 10:03:13.073848       1 reflector.go:147] pkg/mod/k8s.io/client-go@v0.29.3/tools/cache/reflector.go:229: Failed to watch *v1alpha1.ClusterSbomReport: failed to list *v1alpha1.ClusterSbomReport: json: cannot unmarshal array into Go struct field Metadata.items.report.components.metadata.tools of type v1alpha1.Tools
W0409 10:03:18.568082       1 reflector.go:539] pkg/mod/k8s.io/client-go@v0.29.3/tools/cache/reflector.go:229: failed to list *v1alpha1.ClusterSbomReport: json: cannot unmarshal array into Go struct field Metadata.items.report.components.metadata.tools of type v1alpha1.Tools
E0409 10:03:18.568125       1 reflector.go:147] pkg/mod/k8s.io/client-go@v0.29.3/tools/cache/reflector.go:229: Failed to watch *v1alpha1.ClusterSbomReport: failed to list *v1alpha1.ClusterSbomReport: json: cannot unmarshal array into Go struct field Metadata.items.report.components.metadata.tools of type v1alpha1.Tools
W0409 10:03:25.448370       1 reflector.go:539] pkg/mod/k8s.io/client-go@v0.29.3/tools/cache/reflector.go:229: failed to list *v1alpha1.ClusterSbomReport: json: cannot unmarshal array into Go struct field Metadata.items.report.components.metadata.tools of type v1alpha1.Tools
E0409 10:03:25.448413       1 reflector.go:147] pkg/mod/k8s.io/client-go@v0.29.3/tools/cache/reflector.go:229: Failed to watch *v1alpha1.ClusterSbomReport: failed to list *v1alpha1.ClusterSbomReport: json: cannot unmarshal array into Go struct field Metadata.items.report.components.metadata.tools of type v1alpha1.Tools
W0409 10:03:47.685700       1 reflector.go:539] pkg/mod/k8s.io/client-go@v0.29.3/tools/cache/reflector.go:229: failed to list *v1alpha1.ClusterSbomReport: json: cannot unmarshal array into Go struct field Metadata.items.report.components.metadata.tools of type v1alpha1.Tools
E0409 10:03:47.685742       1 reflector.go:147] pkg/mod/k8s.io/client-go@v0.29.3/tools/cache/reflector.go:229: Failed to watch *v1alpha1.ClusterSbomReport: failed to list *v1alpha1.ClusterSbomReport: json: cannot unmarshal array into Go struct field Metadata.items.report.components.metadata.tools of type v1alpha1.Tools

What did you expect to happen:
No errrors.
Anything else you would like to add:
None.
Environment:

Trivy-Operator version (use trivy-operator version): v0.19.4
Kubernetes version (use kubectl version): v1.29.3
OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc): macOS 14.4.1

@sheeeng have you upgraded from older version of trivy-operator.
please fully uninstall the trivy-operator installation : helm uninstall trivy-operator -n  trivy-system
and delete all CRDs and re-install again with latest.
kubectl delete crd vulnerabilityreports.aquasecurity.github.io
    kubectl delete crd exposedsecretreports.aquasecurity.github.io
    kubectl delete crd configauditreports.aquasecurity.github.io
    kubectl delete crd clusterconfigauditreports.aquasecurity.github.io
    kubectl delete crd rbacassessmentreports.aquasecurity.github.io
    kubectl delete crd infraassessmentreports.aquasecurity.github.io
    kubectl delete crd clusterrbacassessmentreports.aquasecurity.github.io
    kubectl delete crd clustercompliancereports.aquasecurity.github.io
    kubectl delete crd clusterinfraassessmentreports.aquasecurity.github.io
    kubectl delete crd sbomreports.aquasecurity.github.io
    kubectl delete crd clustersbomreports.aquasecurity.github.io
    kubectl delete crd clustervulnerabilityreports.aquasecurity.github.io

authors: chen-keinan sheeeng

repo: aquasecurity/trivy-operator


text:
erreur à l'installation

salut à tous, j'ai un problème lorsque j'installe le selfbot avec start.bat :

quelqu'un peut m'aider svp ?

en : i have a problem with the installation, three modules can't install, someone can help me ?

You need to restart some times, its normal

Yes I have this problème too

authors: BIDOUNI LaquiosDev Thermidor-1


text:
Update README.md

Fix a typo, inconsistent spelling of iOS (now iOS instead of ios) and fix a code formatting issue.

Thanks

authors: aqwert fbernutz


text:
Improve article : 2307.11045v1

Describe the issue
Description: The links at the point of a citation seem to use labels for the references instead of the standard presentation of authors and year of publication; another common option is to use a bracketed number. In either case, the references list is easy to match with the presentation of the references in the body of an article. Use of keywords seems prone to the whims of the authors, not all of whom will use sensible labels for the works they cite.
Feel free to attach a screenshot (or document) link below:
Auto Fill Data - !!! Please do not edit below this line !!!

Id: 364500a5-ca84-4d6d-9b2d-102d48767bd5

Hi Jonathan, Shamsi here. Your Github feedback is received, thank you!

I'm using this issue to tease out how best to use an issue on GitHub.
Signing in and out is unnecessary because the way GH shares issues exposes the sender etc. (minimising edits as issues are handled is important; some education/training of issue raisers may become a concern.)
The conversation doesn't currently have a meaningful title for tracking purposes. I don't know if that was hard wired or if I missed a chance to append something useful to what has become the subject line of this email.
In the long run, tracking an issue by an identifier for a specific paper may be the most useful starter, but I suspect some issues will quickly be identified as general ones. How the arXiv team watching issues as they come in will be important.
It may also be useful to get the papers' corresponding authors linked to the issues raised on GH about their papers. I would defer that until the structure is better sorted though.

authors: SBBCornell ajrgodfrey


text:
ePillID Dataset: A Low-Shot Fine-Grained Benchmark for Pill Identification

一言でいうと
薬の画像認識のためのベンチマークデータセットを整備。4902種の錠剤が対象。各クラスに与えられる画像数が非常に少ないため、Low-Shot用のアプローチが必要。Multi-Head Metric Loss を用いたモデルで精度92%。
論文リンク
https://arxiv.org/abs/2005.14288
著者/所属機関
Naoto Usuyama, Natalia Larios Delgado, Amanda K. Hall, Jessica Lundin

Microsoft Healthcare

投稿日付(yyyy/MM/dd)
2020/09/07
概要
画像の例
Reference画像: コントロールされた条件で撮られた高品質な画像
Consumer画像: 条件や品質がばらばらな、実際の現場で撮られるような画像

ePillID データセットに含まれる錠剤クラスの分布
多くのクラスはReference画像のみ

エラー分析、間違い例
色、形は同じで、錠剤に書かれた文字が少しだけ違う例

実装: https://github.com/usuyama/ePillID-benchmark

repo: arXivTimes/arXivTimes


text:
Customize Email alerts/ Add exception in email alert

Can we customize Email alert ? Add some exception in the email sent from Cabot ?

Can you give a user story/scenario to illustrate this ticket?

Thanks for your response I want to customize my email alert by throwing actual error or exception rather than saying fail or pass.
I think I got a plugin now (cabot-alert-skeleton) and now I am trying to install it to my dashboard.

I don't really understand what the use case is here. Is this when Cabot fails e.g. to fetch a metric because the server is down?

I am sry for confusing. Lemme explain u, When a http check fails for my service I want an email alert with the status message as below
{"status": "UP"}   or
{"status", "DOWN", "message" : "connection error with kafka"} ...etc

Hi,
I'm a User not a developper, I join this as an enhancement.
We don't have a Template with {{data_replacement}}.
For Exemple Subject and Body HTML of Alerts Services for exemple : Service back to normal : {{service_replacement}} by something else.
Best Regards.
Khalil CHARFI

I am sry for confusing. Lemme explain u, When a http check fails for my service I want an email alert with the status message as below
{"status": "UP"} or
{"status", "DOWN", "message" : "connection error with kafka"} ...etc

I have forked original email plugin and made some customization over template, take a look at https://github.com/onagorodniuk/cabot-alert-email

authors: ckhalilo dbuxton manojDevOps onagorodniuk

repo: arachnys/cabot


text:
rtinst.log file not created

Not sure if this is me or something wrong with the rtinst script, but I don't get any log file when passing the -l or --log argument.
sudo rtinst -l
sudo rtinst --log
Checking my home folder, there is no file called rtinst.log.
I'm running Ubuntu 22.04.
Any ideas?

My bad, didn't look in /root. There it was.