Remove redundant check that breaks building on some systems

While trying to build any project that depends on pdfrx, I always get the following error:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
libc++
   linked by target "pdfrx" in directory /Users/tymscar/.pub-cache/hosted/pub.dev/pdfrx-1.0.91/src

Now after hours of trying everything, I stumbled upon this article from developer.android.com stating that:
The default for CMake is c++_static.
Because of this, I decided to remove  ${libc++} from target_link_libraries from pdfrx's CMakeLists.txt and it built without an issue after that.
I don't fully know why find_library(libc++ libc++_static.a) fails for me, and not for everybody, but considering it's redundant and it works without it for everyone, including me, I suggest this PR that removes the need.

I'm very curious about your environment config including version of CMake, SDK, and NDK version because I'm not facing the issue.
And, I'm not sure whether your config is really safe and correct for everyone; only you and the other one are just complaining that.

cmake: version 3.30.5
SDK platform: Android 14
SDK built tools: 35.0.0 (but I've tried 6 different versions)
NDK: 26.1.10909125 (but I've also tried 25.2.8518653, 25.1.8937393, 23.1.7779620)
It's worth mentioning that my colleagues do not get this issue, and they are on the same versions as me, so I did not expect you to have it either, but that being said, the check is redundant, because it's setting libc++ to the static library, which is the default in CMake anyways. So you should not be breaking anything if you do that, and it makes the code shorter.
Have you tried running it with my suggestions on your machine?

@sizeak Sorry, I didn't understand your message. Who do you mean by "you"?
So, should I merge it? Or any notable things?? I'm busy for my work now (it's almost december!!) and could not fully check the build behavior...

Hi @espresso3389!
Sorry, to clarify, I am a colleague of @tymscar. The "You" in "You only really need to consider finding..." is referring to an individual, i.e. "one", not a specific person. So "A library author only really needs to consider finding the path to the standard library when putting together a custom..." would be clearer wording.
The holidays are fast approaching aren't they! I'm sorry you're finding it busy, aren't we all!

As for whether you should merge it, I think that it is a safe and sensible change. My understanding of the Google documentation is that the call find_library call to locate the STL is unnecessary and we have tested this on multiple machines including Macs and Linux machines which could build with & without the change.
The worst case is that you can roll it back and push a bug fix release, but that seems unlikely to be necessary.

Thank you so much

I confirmed flutter build appbundle ran successfully on the following "fresh" env:
[✓] Flutter (Channel stable, 3.24.5, on Ubuntu 24.04.1 LTS <IP_ADDRESS>-microsoft-standard-WSL2, locale C.UTF-8)
    • Flutter version 3.24.5 on channel stable at /home/kawasaki/work/flutter
    • Upstream repository https://github.com/flutter/flutter
    • Framework revision dec2ee5c1f (2 weeks ago), 2024-11-13 11:13:06 -0800
    • Engine revision a18df97ca5
    • Dart version 3.5.4
    • DevTools version 2.37.3

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /usr/lib/android-sdk
    • Platform android-29, build-tools 29.0.3
    • ANDROID_HOME = /usr/lib/android-sdk
    • Java binary at: /usr/bin/java
    • Java version OpenJDK Runtime Environment (build 21.0.5+11-Ubuntu-1ubuntu124.04)
    • All Android licenses accepted.

[✗] Chrome - develop for the web (Cannot find Chrome executable at google-chrome)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.

[✓] Linux toolchain - develop for Linux desktop
    • Ubuntu clang version 18.1.3 (1ubuntu1)
    • cmake version 3.28.3
    • ninja version 1.11.1
    • pkg-config version 1.8.1

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/to/linux-android-setup for detailed instructions).

[✓] Connected device (1 available)
    • Linux (desktop) • linux • linux-x64 • Ubuntu 24.04.1 LTS <IP_ADDRESS>-microsoft-standard-WSL2

[✓] Network resources
    • All expected network resources are available.

1.0.92 is just released!


inspector

Inspectors would hint the user the duality of FormDiagram and ForceDiagram: edge - edge, node - face, face - node.
Inspectors would work either by user moving the mouse on the object (which might not work perfectly with overlapping objects), or by selecting the object manually.

This issue would replace issue #35

I think that to avoid the problem of overlapping, this command should always ask to click.

done


spec: clarify behavior of load statements within toplevel if/for blocks

The spec is unclear about the behavior of load statements outside a function but inside a top-level if/for block. (The Java implementation does not permit top-level if/for blocks at all, so it doesn't provide any precedent.)
Currently, it is not an error:
$ starlark -globalreassign
Welcome to Starlark (go.starlark.net)
>>> for x in ():
...   load("x", "f")
...
>>> if False:
...   load("x", "f")
...

Disallowing it would make load statements behave more like imports in a static language (Go/C++/Java): as declarations of the program structure. Allowing them would allow for delayed or conditional loading, as in Python. However, it would complicate applications (like Bazel) that preprocess all the load statements as they would have to search within if/for blocks to find them.
My inclination is to disallow it, and I'm sure @laurentlb would agree, but I'm a little worried I have inadvertently allowed Go clients to start depending on this feature. Oops.

How about a package flag that defaults to preserve current behavior for go clients?
I’d like my Go client to set the flag to false so would love to have this upstream.
Thanks for catching this

Pierre, do you mean you would set the flag to preserve the current behavior, or to enable the stricter check? If the latter, could you explain what you use this feature for?

Ah I can see how I was unclear, sorry about that.
I'm voting to disallow it and I'd like a way to make sure such loads are forbidden.

Glad to hear it. I'm tempted to make the change and see if anyone complains.


stage1-coreos panics when image has empty exec

My initial experience with rkt was a little jarring:
$ sudo rkt run quay.io/listhub/alpine
rkt: using image from local store for image name coreos.com/rkt/stage1-coreos:0.13.0
rkt: using image from local store for image name quay.io/listhub/alpine
panic: runtime error: index out of range

goroutine 1 [running, locked to thread]:
main.(*Pod).appToSystemd(0xc8200188a0, 0xc820088fc0, 0x0, 0xc82011aa10, 0x6, 0x0, 0x0, 0x0, 0x0)
        /home/alban/go/src/github.com/coreos/rkt/release-build/gopath/src/github.com/coreos/rkt/stage1/init/pod.go:308 +0x5fab
main.(*Pod).PodToSystemd(0xc8200188a0, 0x0, 0xc82011aa10, 0x6, 0x0, 0x0, 0x0, 0x0)
        /home/alban/go/src/github.com/coreos/rkt/release-build/gopath/src/github.com/coreos/rkt/stage1/init/pod.go:465 +0xf9
main.stage1(0x7fcd556703a0)
        /home/alban/go/src/github.com/coreos/rkt/release-build/gopath/src/github.com/coreos/rkt/stage1/init/init.go:617 +0x18e5
main.main()
        /home/alban/go/src/github.com/coreos/rkt/release-build/gopath/src/github.com/coreos/rkt/stage1/init/init.go:908 +0x42

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        /usr/lib/golang/src/runtime/asm_amd64.s:1696 +0x1

I eventually learned that, if I was expecting a shell, I'd have needed to

use --interactive
either use --exec or acbuild myself an image with a non-empty exec

but my first thought was that something was wrong with my rkt installation. :grin:
(rkt version 0.13.0, appc version 0.7.3)

Ooops, thanks for reporting! #1843


List of small form fixes - e.g., fixing typos, moving existing stuff around

[ ] in Workbench -> Specimen form there is a field named PBDB CID and PBDB OCCID. Remove this as this information is captured elsewhere.
[ ] in Workbench -> Specimen move the Collection select box to the TOP of the form. Make it a SEARCH style field instead of a dropdown
[ ] in Workbench -> Specimen the Described_By and idgbio_id should be move to an OPTIONAL accordion. Renamed described by to description.
[ ] in New persons in Workbench -> Person should default to PUBLIC
[ ] Middle initial field/property needs to be added to Person nodes
[ ] Default all accordions to minimised except top-level required accordion.
[ ] In Workbench -> Collection Move PBDB ID field to TOP, move collection type to bottom (but still required)

This is more or less superseded by the ongoing revisions associated with #71, so there is no point keeping this as a separate issue.


Debug message sender :: Feature

Hi @Kiritsu
The below code could be useful for debug purposes where it out puts the request token within log when debugging instead of displaying it on frontend.
Obviously this will need some tweaking to output the otp.
public class DebugMessageSender : IMessageSender
    {
        public void SendMessage(Message message, IReadOnlyCollection<MessageRecipient> recipients, string senderDisplayName = null)
        {
            foreach (var messageRecipient in recipients)
            {
                Debug.WriteLine("From:{0} To: {1} <{2}>\r\nSubject: {3}\r\nMessage: {4}",
                    senderDisplayName, messageRecipient.Name, messageRecipient.EmailAddress, message.Subject, message.Body);
            }
        }
    }

It's not displayed anymore in frontend and if we need to log anything, we'll use Microsoft.Extensions.Logging instead. :)

Sounds good @Kiritsu


Why amplify both node allocatable CPU and CPU Request of POD?

According to the diagram of CPU normalization, the amplified ratio is applied on both  node allocatable CPU in node status and CPU request on scheduler filter, why design as this ?
I suppose amplified ratio only need applies on node allocatable CPU in node status. Can you please explain why CPU request amplified too?
Thanks.

Koordinator version: - v1.4
Kubernetes version (use kubectl version): v1.22.5
docker/containerd version: containerd 1.5.0
OS (e.g: cat /etc/os-release): Ubuntu 20.04.4 LTS
Kernel (e.g. uname -a): Linux 5.10.112-11.al8.x86_64 #1 SMP Tue May 24 16:05:50 CST 2022 x86_64 x86_64 x86_64 GNU/Linux

Anything else we need to know:

@yongming I suppose the "CPU request amplified" you mentioned is the requests of the CPUSet pods (QoS=LSE/LSR). The CPUSet pods' requests are amplified because the current CPU normalization does not support these kinds of pods. The non-CPUSet pods (i.e. CPUShare pods) can scale their real CPU requests/limits by adjusting the CPU slices (i.e. cfs_quota and shares), while scaling the CPUSet pods' requests/limits is not easy since the granularity is the logical core. e.g. When the normalized ratio is 1.2, a CPUSet pod requesting 1 normalized core is hard to allocate 0.83 real core.

Got it，thanks very much!


Fix TimeDate and Period addition.

Fix TimePeriod addition to TimeDate.

Codecov Report

Merging #14 into master will decrease coverage by 6.41%.
The diff coverage is 71.42%.

@@            Coverage Diff             @@
##           master      #14      +/-   ##
==========================================
- Coverage   26.28%   19.86%   -6.42%
==========================================
  Files           9        9
  Lines         487      448      -39
==========================================
- Hits          128       89      -39
  Misses        359      359

Impacted Files
Coverage Δ

src/arith.jl
11.94% <71.42%> (-12.72%)
:arrow_down:

src/TimesDates.jl
0% <0%> (-20%)
:arrow_down:

src/TimeDateZone.jl
31.14% <0%> (-15.83%)
:arrow_down:

src/showstring.jl
40% <0%> (-9.28%)
:arrow_down:

src/select.jl
15% <0%> (-5%)
:arrow_down:

src/periods.jl
15.55% <0%> (-3.13%)
:arrow_down:

src/compare.jl
5.79% <0%> (-2.54%)
:arrow_down:

src/TimeDate.jl
36.95% <0%> (+9.68%)
:arrow_up:

Continue to review full report at Codecov.

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

Thank you

I am sorry -- closed when I was trying to merge.


Fix the type cache with extensibility

Fixes #4428
This PR also fixes the incorrect caching system for CreateCSharpType.
The CreateCSharpType is the entry point, therefore the type cache should work here - and all the invocations in the CreateCSharpTypeCore should be verified that this input is not in the cache, therefore the cache should never be accessed again once we go into this method.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Microsoft.Generator.CSharp


Bug fix 412

Overview
Fixes issue with ComplexOutput and as_reference.
When ComplexOutput was set by a file, it forced as_reference to True.
Binary data was output as string instead of base64.
Also, the raw CDATA content had extra white space.
CDATA tag was used even for XML-based output.
Related Issue / Discussion
#412
Contribution Agreement
(as per https://github.com/geopython/pywps/blob/master/CONTRIBUTING.rst#contributions-and-licensing)

[x] I'd like to contribute [feature X|bugfix Y|docs|something else] to PyWPS. I confirm that my contributions to PyWPS will be compatible with the PyWPS license guidelines at the time of contribution.
[x] I have already previously agreed to the PyWPS Contributions and Licensing Guidelines

Coverage increased (+0.03%) to 74.898% when pulling 68c66105f2f06a283ef25d73afcd6ec8a6206ce5 on lazaa32:bug_fix_412 into dccec7d0f29285185f914ae3c44e068d7c871e46 on geopython:master.

@lazaa32 thanks for this PR :)
It has a python 3.x issue ... see travis tests.

... well, even with six it needs to be handled different, failed now on 2.7
Traceback (most recent call last):
  File "tests/test_inout.py", line 338, in test_base64
    self.complex_out.data = six.binary_type(self.data, 'utf-8')
TypeError: str() takes at most 1 argument (2 given)

Fixed that on https://github.com/huard/pywps/tree/bug_fix_412
@lazaa32 I removed the spacing in the main.xml template because when converting back the data, these spaces end up being part of the response. It makes the xml ugly, but I'm not aware of a workaround.

closing in favor of PR #431.


Substreams: Rust API

Review the Rust APIs section, and its interaction with the documentation living in the docs.rs website. https://substreams.streamingfast.io/reference-and-specs/rust-api
Perhaps the links should point to the docs directly, instead of crates.io, (or in a table view with a direct link to the docs).
The links should be without version, so they are directed to the latest version: https://docs.rs/substreams-ethereum and https://docs.rs/substreams ...

Need additional information and help from the dev team to resolve this.


Kernel error

Hi, when I try to upload big file with Nextcloud (Apache+PHP5) the Rock64 crash with this error:
`
Message from syslogd@Rock64 at Nov  3 00:54:16 ...
kernel:[ 1080.465944] Kernel panic - not syncing: hung_task: blocked tasks
Message from syslogd@Rock64 at Nov  3 00:54:16 ...
kernel:[ 1080.939145] Kernel Offset: disabled
Message from syslogd@Rock64 at Nov  3 00:54:16 ...
kernel:[ 1080.941632] Memory Limit: none
`
This is the complete SysLog of session from boot to crash: https://pastebin.com/AfUvT4WB
PHP is set to keep 16G of files with maximum_execution_time = 3600
What's the problem?

Look here for try fix.....https://bugzilla.redhat.com/show_bug.cgi?id=717633 similar issue

Yes...It's a bug with USB 3.0 (xhci-hcd) because I try to move HDD from USB 3.0 to USB 2.0 and work perfectly.
Fix it please

This should be fixed in recent kernels with increased coherent pool size.


Redisson spring boot starter 3.28.0 - CVE-2023-20873 vulnerability

Hello,
I'm trying to use Redisson Spring Boot Starter library in my project.
When I'm pasting
implementation("org.redisson:redisson-spring-boot-starter:3.28.0")
to build.gradle.kts then I'm getting information about potential vulnerability:

Provides transitive vulnerable dependency maven:org.springframework.boot:spring-boot-actuator-autoconfigure:2.7.4
CVE-2023-20873 9.8 Improper Access Control vulnerability with High severity found
Results powered by Checkmarx(c)
https://devhub.checkmarx.com/cve-details/CVE-2023-20873/

Is this known problem? Do you have any idea how I can handle that? :)
Thanks in advance and have good day

[Solved] Problem was obviously in spring boot version and not in Redisson. 🤦
Interestingly, it was redisson library that highlighted this problem

Should be resolved in https://github.com/redisson/redisson/commit/332c35ccf05ea02cc450a53f9b6dca639ebe86ab


Add support for Java 9+

Add gradle dependency for jaxb-api (removed from the jvm in Java 9)
Upgrade Gradle from v3.2.1 to v6.7.1 to make it build on Java 9+
Bump Gradle plugins and dependencies that breaks either because of JVM changes or changes to the Gradle API

Tested and built successfully on openjdk 14. Backwards compatibility should not be affected.
Fixes #31.

Superseded by https://github.com/schibsted/strongbox/pull/103


Version convention

What convention is used for versioning releases of ObjectMapper?
PR #816 introduced a change to existing public API and was released in version 2.2.7. I did not expect to have failing build after installing 'patch' version update.

@azeff that was just a slip up on my part. ObjectMapper uses Semantic Version so future patches should continue working in your code as expected.

@tristanhimmelman awesome, thanks for clarification.


Remove cwd as a CommandOption and replace with the new `config.root…

Changes

Removes the option to use cwd as a CommandOption
Add new config option root (defaults to process.cwd()) so a user can use it to specify the root of a project using Snowpack either programmatically or as a config option

Testing

No new tests yet. Will be working on this after double-checking that the refactor is complete
All the existing tests pass

Docs

The docs are yet to be updated. Will work on that after double-checking the refactor is complete and new tests are in place

@februarycat this is great! We definitely want to get this in soon to test for v3, so I hope you don't mind that I went ahead and updated the other process.cwd() references across the codebase to now use root.
Would still love your help on some tests and otherwise getting this cleaned up for review!

@februarycat this is great! We definitely want to get this in soon to test for v3, so I hope you don't mind that I went ahead and updated the other process.cwd() references across the codebase to now use root.
As mentioned in the comment above, there are a few remaining references to process.cwd(), mostly around config file loading from the CLI and how we normalize user-given relative config values into absolute paths. Those can remain as-is for now, to be resolved in a follow-up PR. For now, assume all relative URLs in config continue to resolve relative to process.cwd().
Would still love your help on some tests and otherwise getting this cleaned up for review! Actually, I just realized that the best way to test this may be to start moving some tests over from CLI tests to JS API tests (this is one of the big things we've been looking forward to once root support arrives). No tests that use root will pass if root isn't working correctly.
Check out the test that I just converted: ce198a6c. It would be great if you could grab a few more tests and convert them to use the JS API this way. Just getting ~3 done in this PR would give confidence enough to merge then, and then follow up with the remaining tests in follow up PRs.

Okay, so I've updated most of the tests in /test/build and fixed some typos in /plugins. Here's a breakdown of my changes:
/test/build:
Updated most of the tests to use the JS API (create a snowpack config and build programmatically) as in ce198a6 example.
The updates are:

Update test.js file
Remove config file or config from package.json and move that in the test file
Remove testbuild script (following the example commit from @FredKSchott, although I recommend keeping some default command for standalone usage)

There are some tests that still need updating but they rely on extends, proxy, plugin functionality which was not updated with cwd -> root functionality yet:

config-alias (left untouched as it depends on a relative path plugin and the functionality wasn't added)
config-extends-plugin (left untouched as it tests extends functionality which, as I understood it, it might be deprecated and the root functionality wasn't added)
config-instantiated-object (contains relative plugin)
config-out-flag (tests CLI flag)
config-ts-file (tests .ts config which already defaults to root: process.cwd())
css-modules (build is correct but and all files are generated but .proxy are not returned from snowpack.buildProject(), might have to do with the root/cwd updates which are not complete)
html-environment-variables (tests environment variables from the command line)
import-assets (no proxy files in snowpack.buildProject() result)
import-json (no proxy files in snowpack.buildProject() result)
plugin-hook-optimize (contains relative plugin path)
plugin-hook-transform (contains relative plugin path)

I updated package-bootstrap as the tests passes because it's not checking the existence of .proxy files in the result from snowpack.buildProject(). It expects to find _dist_/index.js containing an import to the proxy, which is correctly generated.
Some of the above tests could be upgraded but I decided to skip them as I wasn't sure if they needed a refactor. If any of these could benefit from being updated to use the JS API let me know and I'll update them!
/plugins:

plugin-run-script test was failing because the plugin was instantiated without a config object. I fixed it by passing an empty object so it defaults to process.cwd()
plugin-typescript was failing for the same reason as the tests above. I passed {} as config so the tests pass

plugin-typescript/plugin.js renamed snowpackConfig_ to snowpackConfig to keep naming consistent across all tests

web-test-runner-plugin was failing after @FredKSchott did the initial refactor then decided to revert some changes. The test was failing because cwd was not defined. Fixed it by replacing cwd with snowpackConfig.root || process.cwd() but this needs more checking from @FredKSchott

Huge! This is awesome, will take a look today!
If this PR didn't touch every plugin, I'd say go for it. But, because it's already so sprawling I'd like to keep it scoped as is for now. You don't need to update every test in this PR, especially if you're interested in doing this work in a followup with the remaining tests.
mark as ready for review, and I'll give this a look 👍

Marked as ready for review!
I'd love to keep working on this. I've recently found out about snowpack and instantly loved it. I want to keep contributing 💯

LGTM! I think the test failure is unrelated (or if it is related, it's impossible to tell what's going on from CI). Going to merge this and then will get that last test passing on our end.
Thanks for the change! Looking forward to getting that "everything is relative to cwd instead of the file itself" issue resolved as well!

hmm, it seems like there's something more serious going on in the tests. I couldn't reproduce on my local, but I also couldn't get CI running either.
I went ahead and rolled back out all of the testing changes from main, for now. It would be good to go back and add only 1-3 to confirm that they work on CI long-term, before converting all of them. We also are unlocked to create the automatic fixture test-runner, which could be a better target to convert to (no need to do two separate conversions if we can just jump straight to the final version)

Should I go ahead and open a new PR with base-* tests updated? I think there's only three of them which as you suggested should be enough for now.

Yes, that sounds perfect. I think @drwpow wanted a chance to review the test changes as well so that should be a great PR on its own


delete exec network plugin

update doc since https://github.com/kubernetes/kubernetes/pull/39254 is merged

This change is

LGTM


List index out of range

Hi,
Ran into a weirdness earlier today:
# Sphinx version: 1.7.7
# Python version: 2.7.15 (CPython)
# Docutils version: 0.14
# Jinja2 version: 2.10
# Last messages:
#   done
#   checking consistency...
#   done
#   preparing documents...
#   scanning for assets...
#   done
#   done
#   writing output... [ 33%] guides/aws/autoscaling_applications/index
#   writing output... [ 66%] index
#   writing output... [100%] service_guide/index
# Loaded extensions:
#   alabaster (0.7.11) from /usr/local/lib/python2.7/site-packages/alabaster/__init__.pyc
#   sphinxcontrib.confluencebuilder (unknown version) from /usr/local/lib/python2.7/site-packages/sphinxcontrib_confluencebuilder-0.10.0.dev0-py2.7.egg/sphinxcontrib/confluencebuilder/__init__.pyc
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/sphinx/cmdline.py", line 304, in main
    app.build(args.force_all, filenames)
  File "/usr/local/lib/python2.7/site-packages/sphinx/application.py", line 325, in build
    self.builder.build_all()
  File "/usr/local/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 299, in build_all
    self.build(None, summary='all source files', method='all')
  File "/usr/local/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 403, in build
    self.write(docnames, list(updated_docnames), method)
  File "/usr/local/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 440, in write
    self._write_serial(sorted(docnames))
  File "/usr/local/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 449, in _write_serial
    self.write_doc(docname, doctree)
  File "/usr/local/lib/python2.7/site-packages/sphinxcontrib_confluencebuilder-0.10.0.dev0-py2.7.egg/sphinxcontrib/confluencebuilder/builder.py", line 303, in write_doc
    and node['ids'][0]
IndexError: list index out of range

I hacked up the code to print node['ids'] and saw:
['id5'] output... [100%] service_guide/index
['id6']
['id7']
['id8']
['id9']
['id10']
['id11']
['id12']
['id13']
['id14']
['id15']
['id16']
['id17']
['id18']
['id19']
['id20']
['id21']
['id22']
['id23']
['id24']
['id25']
['id26']
['id27']
['id28']
['id29']
['id30']
['id31']
['id32']
['id33']
['id34']
['id35']
['id36']
['id37']
['id38']
['id39']
['id40']
['id41']
['id42']
['id43']
['id44']
['id45']
['id46']
['id47']
['id48']
['id49']
['id50']
['id51']
['id52']
['id53']
['id54']
['id55']
['id56']
['id57']
['id58']
['id59']
['id60']
['id61']
['id62']
['id63']
['id64']
['id65']
['id66']
['id67']
['id68']
['id69']
['id70']
['id71']
['id72']
['id73']
['id74']
[]

I worked around this with:
                        if ('ids' in node
                                and len(node['ids']) > 0
                                and node['ids'][0] == title_element['refid']):

In builder.py and everything built, published, and looks OK.  I'm not sure what the "right" way to troubleshoot this is.  Any suggestions?! :)

For sure this is an issue with this extension when parsing the document's known references. Thanks for reporting it. The logic assumes that the existence of the ids attribute implies that there are identifiers to work with -- and in most cases, we only deal with the first element. In most cases, there is usually one or more identifiers when the attribute exists. But, for this case, it is not (I've seen this before with citation types as well).
The workaround you have provided works; however, I would suggest a tweak to the check:
                        if ('ids' in node and node['ids']
                                and node['ids'][0] == title_element['refid']):

See also #154.

Version 1.0 of this extension has been released which addresses the title parsing error discussed in this issue; closing.


[Sema] Report use of implicitly imported decls in inlinable code

Implicitly imported decls references from inlinable code can break the module API. This has been known to lead to deserialization crash and could break the generated swiftinterfaces files. Let's explicitly check for such a case, keeping it to a warning until Swift language version 6 where it's an error.
This should address cases crashing the compiler, but it will require more work. Mainly, lookup should not allow any reference to non-imported decls, since this is source breaking we could also report them as a warning in implementation details by adding a similar check to diagnoseDeclAvailability. On the performance side, because we're using more of getRestrictedImportKind we may want to cache its result at this point.
rdar://95816286

@swift-ci Please smoke test

Maybe instead of "implicitly imported" you can be more explicit (hah!) and say "defined in an extension in a transitively-imported module" or something even more specific? Otherwise someone who encounters this diagnostic will have a hard time figuring out what's going on.

@swift-ci Please smoke test

Changed the diagnostic to the more direct 'X' cannot be used in an '@inlinable' function because 'libB' was not imported by this file and removed the special case for __ObjC.

@swift-ci Please smoke test


Add some javadoc comments to give a rough outline

Sorry for the large PR, but I wasn't sure if and where to split it up.
Content
This PR should only contain javadoc, but that for about any public member I could find.
The goal is to hopefully make navigating the API outside of CommandDispatcher a little less annoying and clarify the usage. What is still missing are some proper walkthroughs or tutorials that actually walk you through achieving some goal, but IMHO useful javadoc is a good first step.
I hope the doc I wrote is useful but contributions, questions and clarifications are more than welcome!
Problems
The docs still have around 6 places marked with TODO: XXX, indicating that I had no idea why a certain choice was made and therefore could not write docs for it. The other place is in the Suggestions create/merge methods, as I know how they work but not what they are used for. Here is a list with all TODOs:

[ ] Command#run throws a CommandSyntaxException, but is executed and not parsed here

[ ] CommandContextBuilder contains a CommandDispatcher which is never used and not present in the CommandContext

[ ] Why does the CommandContext(Builder) contain a list of nodes, when the withNode method replaces all relevant fields but only keeps the old node around? And the only use case for getNodes I have found is to get the node for the attached command, so the last one. The only references in the project also just fetch one node.

[ ] StringRange constructor: Why allow ranges where the start is greater than the end? Something like start = 20, end = 5 might not be ideal.

[ ] CommandSyntaxException seems to be more than just a syntax exception. Why is only syntax in the name then?

[ ] Some clarification about how Suggestions#merge and Suggestions#create work/are used for

Other
Clarifications and change requests/comments are welcome!

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

I agree. A java doc is a much needed first step in the right direction. It's especially neccasary if more and more features get merged in, so that the javadoc can be kept up to date as a requirement for future pull requests.
Most of the stuff I looked at so far was looking good. Maybe some of the stuff could be more detailed. I already made a pull request to your branch with some minor stuff I've found.
I know, documentation is what no one likes doing, but I still hope that many more people in here give their feedback.

I think when the @return text is the same as the method description, as it is the case for ImmutableStringReader.java, then only @return should be used. Otherwise it is more work to maintain and more to read despite adding no new information.

Why did you use @literal for some periods, e.g. https://github.com/Mojang/brigadier/pull/47/files#diff-c8e5c02eb71c3fa5ea2330d4f0c9267dR327 ?

Maybe it would be good to replace the Minecraft related documentation

getting in-game data or player names etc

with something more generic or explain this a little bit more, since (if I understand it correctly) this project is intended as a general purpose library.

Not so important, but currently it is a little bit inconsistent whether a period is used at the end of @param and @return

ArgumentBuilder.java and similar classes often call nodes "commands". In my opinion this is misleading since nodes can have a command and I would not consider a node without command a "command". I did not add this as review comment everywhere.

There is no need for links to the enclosing class. For some of them I added review comments but not for all. These links are probably rather distracting. E.g.

class A {
    /**
     * Creates new {@link A}.
     */
    A() {
        ...
    }
}

Sorry if the reviews are not helpful, annoying or unfriendly. I stopped before SuggestionContext.java.

@Marcono1234 That was quite thorough and not annoying or unfriendly. Thank you very much!
I have applied most of it, except for a few where I wasn't sure.
You caught a lot, so again, thank you very much! :)

Thank you for the previous ones! I will go through all of it again when I have more time (quite busy with uni during the week atm) and see what I find. I apologize that the docs had a lot of typos and some inaccuracies, so I greatly appreciate the time you poured into ironing them out!


the new Numpy v2.0.0 break the package

numpy v2.0.0 was released yesterday, and it broke the pythoncall unfortunately. if calling using PythonCall with a brand new environment, numpy v2.0.0 would be automatically installed and then the error would pop up.

Can you please provide some code to reproduce the error you're seeing? I can start PythonCall just fine on Windows and Linux even with Numpy 2 installed.


[flutter-sdk] Fix Autocomplete Widget overflow

When using the Autocomplete Material Widget, if the TextFormField do not touch the left border of the screen, the suggestion overlay will overflow the limits of the screen.
There is a parameter to restrict the height of the overlay but no parameter to restrict the width of the same overlay. This PR intend to fix this discrepancy.
Before

After

Issue related: https://github.com/flutter/flutter/issues/78746
If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

While being able to set the desired width might be a nice to have feature, I believe the actual fix for the linked issue is to automatically set the options view width based on the text input width.

Overall the use of addPostFrameCallback and the 1 frame delay in this PR is not ideal, so I want to make sure we're sure about this solution before we decide to do it.

Since the overlay does not appear until the user start typing, the 1 frame delay is not visible and thus should be acceptable.

@JeyPay I'm closing this as it looks like it's gotten stale, but if you're still around and want to finish it I'm happy to reopen and help review.


Add ability to set custom log functions to mail-notifier and imap module.

add ability to set custom debug for mail-notifier and imap module
add dbg message in stop() about imap.state
add ability to set mail-notifier's instance debug function
fix wrong dbg message when imap connection closed
update Readme.md

Thanks  for your contribution.

Thanks for mail-notifier.


Adding standalone server

Change description
What problem does this solve?
This PR adds a standalone HTTP server (powered by plug cowboy) that can be started under the PromEx supervision tree. PR is still a work in progress.
Issue number: #9
Example usage
You can configure the standalone http server by adding the following to your config.exs, dev.exs, etc file (API subject to change as PR evolves):
config :web_app, WebApp.PromEx,
  ...
  metrics_server_port: 4021,
  metrics_server_path: "/metrics",
  metrics_server_protocol: :http,
  metrics_server_pool_size: 5,
  metrics_server_cowboy_opts: []

Additional details and screenshots
Checklist

[ ] I have added unit tests to cover my changes.
[ ] I have added documentation to cover my changes.
[ ] My changes have passed unit tests and have been tested E2E in an example project.

Pull Request Test Coverage Report for Build 8224b2c88e2305b0753815119123711077fd3c4c-PR-10

8 of 28 (28.57%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-2.8%) to 57.233%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lib/prom_ex/metrics_server/plug.ex
0
6
0.0%

lib/prom_ex.ex
8
22
36.36%

Totals

Change from base Build 185f61634deabd83f26609b7a343e769e34b24ca:
-2.8%

Covered Lines:
182

Relevant Lines:
318

💛  - Coveralls


Create new policy with defined PolicyID

API details for Add Firewall Policy?
My use case needs me to explicitly set policy IDs to maintain configuration drift, and the current implementation doesn't allow for this; I've tested out adding this using the REST method and adding the PolicyID property, but that hasn't seemed to work. So I'm wondering if anyone has access to real documentation on the API and can see whether there's an option to do this?

Hi @poundy, there is more info available https://fndn.fortinet.net but no sure it is possible to set the policy ID...

Developer network is stupidly restrictive. You need two FTNT employees to vouch for you, which I don't have.....
That's a bit of a pain if you can't set the policy ID.  For my use case I have two FGT clusters that have largely matching configurations in terms of Addresses, address groups, VIPs, VIPGRPs, and policies so that if we have an internet link failure that BGP manages, all services will continue to run. We've used a script to detect variance, which is easiest to do comparisons when the policy IDs match. And it's kind of weird because that is the key item within the CLI when you edit a policy or create a new policy....

Yes, i known for access to FTNT...
I will check for Policy ID

From FTNT, it look will be possible :

Yay, I have it (somewhat) working. I had bad capitalisation I think !
I'll amend my fork with the changes, once I test my code (and get the duplicate checking working that's harder than I thought - type confusion!) so it shows up in the PR and hopefully can make it for the 0.5.0 milestone.
And in the meantime I am trying to find an avenue into FNDN

Hi @poundy do you think push this change ? (i will write very soon test for Policy)

Yes please, we should get this incorporated. I use this mode regularly, as I manually maintain two distinct FGTs with matching rules and use the PolicyID as the key (create the policy programmatically on both FGTs at once with same PolicyID, so I know they are strictly matching)
My problem is that I can't figure out how to achieve that, my GIT fu is weak. I think that since my repo has some commits ahead of the main repo, and I did this development in a separate branch, I can't really figure out how to unwind all that and not lose content and not break existing commits. Any and all suggestions welcomed !!!

i reopen the issue for don't forget this issue (and i will also look to can set also uuid
for Github skill, you can look https://lab.github.com/
but on this case, it is easy ! fork this repo (it is already the case)
clone on your local machine
git clone https://github.com/yourusername/PowerFGT.git
go on the PowerFGT folder
cd PowerFGT
create a new local branch
git branch -b MyFeatureBranch
make local change and commit
git commit -a -m "My Feature"
push on your repo
git push"
(may be ask to set origin)
and after go on Github for make PR to this repo
If you need to update to last upstream (this repo)
Add FortiPower to upstream (for update/rebase)
git remote add upstream https://github.com/FortiPower/PowerFGT.git
Update source code (your branch and FortiPower Branch)
git fetch --all
Update your local branch with rebase
git rebase upstream/master
You may need to fix some merge issue (but git will say what command do you need to use !)
@Tuurtje, can be help for you too


Test: SCM API

Test for #2824

[x] Windows - @dbaeumer
[x] OS X - @sandy081
[x] Linux - @chrmarti

Complexity: 5
Good news: you're gonna write an SCM provider! 👊

Go through the docs.
Go through the API itself. There ain't much.
Make something. You don't need to actually implement an SCM provider. But test the API, try to create some resources, some menu items, see what breaks.

After generating a new extension, edit its package.json, change engines.vscode to * and rerun npm install. This will fetch the latest vscode.d.ts from master.
Please provide feedback on the docs, api and issues all through this repository.

Good stuff! You surly have your own test provider, copied mine here for my own convenience (compares against local folder, intense code...): https://github.com/chrmarti/vscode-scm-test-provider


Ally Sign Up Form (in progress

Describe your PR
Related to #  Ally Sign up Form Missing
Fixes #
Basic structure is there, It still needs to be hooked up with a service func and to be touched up with styles.
Currently submit just console logs the info
Pages/Interfaces that will change
AllyFeed.js - I added the AllySignUpForm Component to the ModalBody

@SeHarlan closing this PR for now, we'll revisit your work when we're ready to split from Airtable iframes!


Refreshing goes to 404 URL

Clicking the assignments tab takes me to "http://blockchain-course.org/assignments".  Same for lectures.

This issue is not code dependent but a server configuration problem

Fixed


Add an (optional) pass parameter to --convert-elementwise-to-affine to restrict it to certain dialects and/or operations

Currently, --convert-elementwise-to-affine applies to all ElementwiseMappable operations with RankedTensorType operands.
This is fine for the current intended usage in HEIR, but the pass would be more widely useable with this added feature.

This can probably borrow from the secret-distribute-generic pass. Cf. https://github.com/google/heir/blob/main/lib/Dialect/Secret/Transforms/Passes.td#L38-L39 and https://github.com/google/heir/blob/main/lib/Dialect/Secret/Transforms/DistributeGeneric.cpp#L494-L495 for how we did this before, and adding a dialect option should be straightforward.

Hi, I added the options to restrict the ops and/or dialects for the --convert-elementwise-to-affine pass. Should I add separate tests for this?

Hi, I added the options to restrict the ops and/or dialects for the --convert-elementwise-to-affine pass. Should I add separate tests for this?

Thanks! Yes, adding a test would be great - looking forward to your PR!

Should this be the default behavior to always pass the parameters to restrict which dialects to run the pass on. Or should we also keep the previous behavior so that the pass is run on all dialects and ops when not restricted?

I think it'd be great to have it default to the old behavior if no parameters are specified (i.e., make the parameters optional)


Release additional static binaries to use with cargo binstall

I'd like to request adding more binary releases to the tools published here, especially static binaries (ie: with x86_64-unknown-linux-musl and aarch64-unknown-linux-musl), in order to be able to quickly use the tools without having to compile from source if the released binaries aren't compatible with the target.
More context:
The tools shellcheck-sarif and sarif-fmt are used in MegaLinter to support outputing the results of the linter shellcheck and to convert sarif output into the console. Currently, our docker images build times are long in CI, and these two small tools make up most of the 5-6 minutes for the rust tools installation (all but the first 19 seconds), which represents 20-25% of the 20-30 min build times for the full image, which includes hundreds of tools. And it needs to run for all PRs, and most flavours, and some individual linters need it, plus other CI tasks daily. So it is worth it. In my issue here (I'm part of MegaLinter's team) https://github.com/oxsecurity/megalinter/issues/2382, we are planning on switching to cargo binstall, that this repo is configured to use, but since the docker images are based on alpine, the target triplet is x86_64-unknown-linux-musl, so everything must be recompiled.
I could try and help on working with the CI to accomplish that in the next weekends, but I'm not experienced yet with rust building, so I might have some trouble.
Let me know if you're open to that.

@echoix hi, definitely open to this.
unfortunately the way the CI is written right now is that the target == same as the host it's running on, and it just runs on two separate hosts right now which correspond to each target it releases to (https://github.com/psastras/sarif-rs/blob/main/.github/workflows/main.yml#L138).
it'd need to be reworked a bit to support one host multiple target build and publish.
if you have time and want to dig into this great!
otherwise if / when i find the time i can take a look.

From what I learned, if there isn't any OpenSSL needed in one of the dependencies, the solution might be as simple as expanding the CI config for the matrix to include the added build cases, add the apt package musl-tools (and maybe pkg-config if it's not enough), and add the target with rustup target add x86_64-unknown-linux-musl and rustup target add aarch64-unknown-linux-musl, then build normally.
Of course that means to adapt the workflow in order to have the file names for the outputs to work.
If it doesn't work like this (that was the case that would keep most of your CI config the same), then there are other completely different options that exists, either with some GitHub actions in the marketplace to help out these tasks, or the cargo cross project, that will build the files in a container from an image maintained by that project (before it was from the rust tools team).
The cargo binstall uses a very different and unique building pattern that was changed recently, so it's not really an example.


postgress stuff

(node:8) ExperimentalWarning: buffer.File is an experimental feature and might change at any time
(Use node --trace-warnings ... to show where the warning was created)
{ stripeIsConfigured: false }
{
code: 'PGRST204',
details: null,
hint: null,
message: "Column 'modelId' of relation 'models' does not exist"
}

-- Create the models table first since it's referenced by other tables
CREATE TABLE models (
id INT8 PRIMARY KEY,
name TEXT NOT NULL,
type TEXT NOT NULL,
created_at TIMESTAMPTZ DEFAULT NOW(),
user_id UUID REFERENCES auth.users(id),
status TEXT NOT NULL,
modelId TEXT -- No need for unique constraint on this column anymore
);
-- Create the images table
CREATE TABLE images (
id INT8 PRIMARY KEY,
modelId INT8 REFERENCES models(id),
uri TEXT NOT NULL,
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Create the samples table
CREATE TABLE samples (
id INT8 PRIMARY KEY,
uri TEXT NOT NULL,
modelId INT8 REFERENCES models(id),
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Create the credits table
CREATE TABLE credits (
id INT8 PRIMARY KEY,
created_at TIMESTAMPTZ DEFAULT NOW(),
credits INT8 NOT NULL, -- Assuming credits is an integer field
user_id UUID REFERENCES auth.users(id)
);

Is your link from images modelId to models missing ?

Seems know know how to fix this or do you have a schema I can use ?

Hey @rossman22590 , we just added a migration file for supabase that can handle everything for you. If you want to run this on your Supabase SQL Dashboard, or run it locally while linking to it, it will handle your table creations / policies
https://github.com/leap-ai/headshots-starter/blob/main/supabase/migrations/20231010160942_remote_schema.sql

ok so you are actually amazing ty - it works now

ok now im stuck on the screen it says its training , but i got email saying its done

@rossman22590 The UI could be cached

i wish its been going  for 6 hours and i went to anew machine

how can i fix it ?
i was charged, its pending for 2 days but on leap it has finsihed


Feature support decimal and int128 type to avoid number ov…

…erflow
Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall


Fixes to activation function config

Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context / Related issue

How Has This Been Tested (if it applies)

Checklist

[ ] The documentation is up-to-date with the changes I made.
[ ] I have read the CONTRIBUTING document and completed the CLA (see CONTRIBUTING).
[ ] All tests passed, and additional code has been covered with new tests.

@JARACH-209 I just noticed that you were doing the changes in your "jarach-patch" branch and not on "master", so to keep the other pull request up to date we should commit the latest changes to that branch. Sorry about the confusion.


Feature.extrusion

Added two public extrusion methods :
BASIC
BABYLON.Mesh.ExtrudeShape(name, shape, path, scale, rotation, scene)

shape : the shape to be extruded, an array of successive Vector3,
path : the path to extrude the shape along, an array of successive Vector3,
scale : default 1, the value to scale the initial shape,
rotation : default 0, the step value to rotate the shape at each path point.

ADVANCED
BABYLON.Mesh.ExtrudeShapeCustom(name, shape, path, scaleFunction, rotateFunction, ribbonCloseArray, ribbonClosePath, scene)

scaleFunction : a custom javascript function. This function is called on each path point and is given the i position of the point in the path and its distance from the beginning of the path. It must return a scale numeric value. This value will be the scaling applied to the shape drawn at the i-th  point.
rotationFunction : a custom javascript function. This function is called on each path point and is given the i position of the point in the path and its distance from the beginning of the path. It must return a rotation numeric value. This value will be the rotation applied to the shape drawn at the i-th  point.
ribbonCloseArray : default false, boolean. The underlying ribbon closeArray  parameter. This can be used to close automatically a path with right normals computation.
ribbonClosePath : default false, boolean. The underlying ribbon closePath  parameter. This can be used to close automatically a shape with right normals computation.

Of course the two last optional parameters updatable? and sideOrientation are avalaible but aren't described here, as well as name and scene.
NOTE :
A shape is an array of successive Vector3. This means 2D or 3D shapes can be extruded as well.
The shape is to be designed in the local coordinate system knowing that the z-axis will be the extrusion path axis.
This means if you just want extrude 2D shapes, you will usually only define them in the xOy plane will all z coordinates valued to zero.
example :
var shape = [
  new BABYLON.Vector3(1, -1, 0),
  new BABYLON.Vector3(1, 0, 0),
  new BABYLON.Vector3(0.6, 0.3, 0),
  new BABYLON.Vector3(0.8, 0.8, 0)
];

At last, shapes don't have to be centered in the local coordinate system.
A centered shape will extruded right on the path axis. An un-centered shape will be extruded offset from the path axis.
About the PR ...
Sorry for the bunch of js compiled files coming with ... just couldn't merge upstream/master unless they were commited :-(
Only babylon.mesh.ts is actually edited and modified.

Huge!! will need a doc :)

no, it's not... Bad port today from the original JS playground code due to a too short night :-(
Too bad the compiler didn't shout about this.
Just declare angleStep in the upper level for-loop besides shapePaths, both evolves together/
I just notice scaleRatio  and rotationMatrix can be set in the upper level for-loop also because they only depend upon var i (path point position) and not upon var p (shape points).
Pfffff
Sorry for this... I prefer PR clean things.
Could you please fix it ?
Or I can re-commit and re-PR tomorrow if you prefer.

I'll write the doc with playground examples as soon as it is merged, no worries

I'll take care of this :)

It's online:)

thank you a lot :-D
I should have noticed by myself all those stuffs (wrong loop level, etc), pfff

My pleasure!!!


fix: pass schema on dataset creation

SUMMARY

For some reason we were not passing the schema when creating a dataset from SQL Lab.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

@betodealmeida can you add a test? :)

@betodealmeida can you add a test? :)

Adding it right now!

🏷 preset:2023.29


Let tests use extensions instead of conventions

This PR changes tests to use extensions instead of conventions where available.
This was extracted from a PR that grown too big for a reasonable review:

https://github.com/gradle/gradle/pull/23707

This is the first step.

@bot-gradle help

Currently, the following commands are supported:
@bot-gradle test <BuildTrigger1> <BuildTrigger2> ... <BuildTriggerN>

A trigger is a special build for this PR on TeamCity, common triggers are:

SanityCheck/CompileAll/QuickFeedbackLinux/QuickFeedback/PullRequestFeedback/ReadyForNightly/ReadyForRelease
Shortcuts: SC/CA/QFL/QF/PRF/RFN/RFR
Specific builds:

BD: BuildDistributions/BuildDocs so that you can preview the generated docs/distribution.
PT: PerformanceTest, all performance tests for Ready For Nightly stage.
APT: AllPerformanceTest, all performance tests, including slow performance tests.
AST: AllSmokeTestsPullRequestFeedback
AFT: AllFunctionalTestsPullRequestFeedback
ASB: AllSpecificBuildsPullRequestFeedback
ACC: AllConfigCacheTestsPullRequestFeedback
ACT: AllCrossVersionTestsReadyForNightly
AFTN: AllFunctionalTestsReadyForNightly
ACTR: AllCrossVersionTestsReadyForRelease
AFTR: AllFunctionalTestsReadyForRelease

@bot-gradle test and merge

queues this PR for testing and merges if all tests pass by:

Creating a merge commit from your PR branch HEAD and the target branch
Running a ReadyForNightly build against the merge commit
When it passes, fast-forward the target branch to this merge commit (i.e. merge the PR)

The merge commit is called a pre-tested commit, which means that it fully tests the integration
of your branch HEAD and latest master, instead of only testing your branch HEAD.
@bot-gradle cherrypick to <branch>

Cherrypicks the current PR to another branch.
A new PR will be created and a build will triggered automatically if there is no conflict.

@bot-gradle cancel

cancel a running pre-tested commit build or remove it from queue

@bot-gradle clean

clear the conversation history

@bot-gradle help

display this message

To run a command, simply submit a comment.  For detailed instructions see here.

@bot-gradle test PRF, AFTN, ACTR

I've triggered the following builds for you:

PullRequestFeedback build
AllFunctionalTestsReadyForNightly build
AllCrossVersionTestsReadyForRelease build

@bot-gradle test ACTR

I've triggered the following builds for you:

AllCrossVersionTestsReadyForRelease build

@bot-gradle test ACTR

I've triggered the following builds for you:

AllCrossVersionTestsReadyForRelease build

@bot-gradle test ACTR

I've triggered the following builds for you:

AllCrossVersionTestsReadyForRelease build

@bot-gradle test and merge

There's merge conflict between your PR branch and base branch. Please fix it and try again.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

I've triggered a build for you.


[Apollo Pre6 Branch] [Perception] - FusionComponent not receiving prefused_message from FusionCameraDetectionComponent

Ubuntu 1804
Apollo pre6 branch

hi team, I'm using latest LGSVL with Apollo pre6 branch.
I launch the perception module with this launch file.

inside which, there is camera perception
    <module>
        <name>perception_camera</name>
        <dag_conf>/apollo/modules/perception/production/dag/dag_streaming_perception_camera.dag</dag_conf>
        <!-- if not set, use default process -->
        <process_name>camera_perception</process_name>
        <version>1.0.0</version>
    </module>

However, I noticed that the Fusion Component defined in one of dag file:
  components {
    class_name: "FusionComponent"
    config {
      name: "SensorFusion"
      config_file_path: "/apollo/modules/perception/production/conf/perception/fusion/fusion_component_conf.pb.txt"
      readers {
          channel: "/perception/inner/PrefusedObjects"
        }
    }

is not receiving the prefused_message <SensorFrameMessage> sent by the fusion_camera_detection_component.cc.
I've stopped the Lidar sensor on the LGSVL simulator, leaving only two camera sensors. Below logs are what I have:

The bottom image shows that fusion_ccamera_detection_component.cc keeps sending out the prefused_messages.
But the top image shows that there is no data being received by fusion_component.cc, otherwise, there will be logs printing out from probabilistic_fusion.cc i guess.

Not I understand why fusion component cannot receive the prefused_message sent from camera detection component.
refer to issue

Hi, After reading your reference, I still can't  understand why fusion component cannot receive the prefused_message sent from camera detection component,  Could you explain it in more detail? By the way, Should the sensor fusion module fuse camera sensors? if so,  how to achiene it?  The inconsistency of apollo document and related issue #10495 confused me.

hi @ideasplus , the reason why the fusion component cannot receive the prefused_message is that the prefused_message is communicated via shared pointers (If I'm correct about it) between all the components defined inside ONE dag file.
the prefused_message is not shared communicated via shared memory, meaning that modules defined in other dag files cannot receive it, and the cyber_monitor also cannot see it.
Since the camera detection component is not defined within the same dag file as the fusion component, the fusion component will not be able to receive this prefused_message published by the camera detection component.
The current version of Apollo still does not support fusion of camera obstacle detections. I think it's only fusing obstacles detections by LIdar and Radar.
The cameras are used only for traffic light detection.

@ntutangyun Thank you very much for your detailed explanation:)

I've managed to change the dag_streaming_perception.dag and add the dag_streaming_perception_camera.dag on the beginning of this code and the perception could start both camera and lidar detections. So I have a dag file with two module_config {, one configuring the camera perception and other configuring the lidar 3d perception. Still, the data doesn't seems to be fused. But in fact I could run both modules from one .dag file.

Actually an update, I've written one .dag file with two module_config which are the content of the dag_streaming_perception_camera.dag and dag_streaming_perception.dag and this actually worked. After some adjustments on my extrinsic parameters the data fusion so to fuse camera and LiDAR two main things are necessary:

Have the camera and LiDAR module_config in an unique .dag file
Have a precise extrinsic parameters, otherwise the matches between camera and LiDAR will not be good and the fusion will not happen

hi @ideasplus , the reason why the fusion component cannot receive the prefused_message is that the prefused_message is communicated via shared pointers (If I'm correct about it) between all the components defined inside ONE dag file.
the prefused_message is not shared communicated via shared memory, meaning that modules defined in other dag files cannot receive it, and the cyber_monitor also cannot see it.
Since the camera detection component is not defined within the same dag file as the fusion component, the fusion component will not be able to receive this prefused_message published by the camera detection component.
The current version of Apollo still does not support fusion of camera obstacle detections. I think it's only fusing obstacles detections by LIdar and Radar.
The cameras are used only for traffic light detection.

Thanks for your explanation. But as i know, lgsvl does not send radar data to perform module perception on apollo. Is there anyway  to simulate the fusing obstacle of lidar and radar? I just want to simulate how the data fused (lidar and radar, or camera and lidar).


fix kubernetes hostnames if those contain dot

What this PR does / why we need it: https://serverfault.com/questions/229331/can-i-have-dots-in-a-hostname the recommendation is that we should not use dots in linux hostnames. If we do not have dots in linux hostnames, we should not have those either in kubernetes nodenames because then nodename does not match to hostname. This makes huge issues if we are using external cloudprovider plugin and when bootstrapping it.
issue in kops https://github.com/kubernetes/kops/issues/6441

@dims could you review this. I tried to search possibility to pass that k8s cluster name as start flag to application. However, it seems that its not possible (easily?). I went through all external CCM providers and none of them are passing optional flags.

I think we will just replace . -> - in kops. Then linux hostnames works and also openstack api works like previously

@zetaab I think this makes sense, but should be done in the model.
https://github.com/kubernetes/kops/blob/master/pkg/model/openstackmodel/servergroup.go#L84
This is non-passive and will break find, but we are still alpha and I think your concern here is correct.


Revert "Truncate like we mean it"

Reverts Clever/s3-to-redshift#92, until we decide if "Truncate" is the right move here

verbal LGTM from Evan


fix: check pipeline

What/Why/How?
Reference
Testing
Screenshots (optional)
Check yourself

[ ] Code is linted
[ ] Tested with redoc/reference-docs/workflows
[ ] All new/updated code is covered with tests

Security

[ ] Security impact of change has been considered
[ ] Code follows company security practices and guidelines

Not relevant


Stand In Line, Type Error bug

Stand In Line code throwing the Type Error, as show below.
####My Code
function nextInLine(arr, item) {
  // Your code here
 arr = arr.push(item);
 var firstElement = arr.shift();
  return firstElement;  // Change this line
}

var testArr = [1,2,3,4,5];
// Display Code
console.log("Before: " + JSON.stringify(testArr));
console.log(nextInLine(testArr, 6)); // Modify this line to test
console.log("After: " + JSON.stringify(testArr));

Screenshot

`

@DheerajVislavath Thank you for reporting this issue, but your code is not correct. Please take a look at your code carefully and double check your understanding of the methods you are using. There is something incorrect about them. The type error you're getting is a hint.
This is a standard message notifying you that this issue seems to be a request for help. Instead of asking for help here, please click the "help" button on the challenge on freeCodeCamp, which will take you to the help chatroom for that specific challenge. You can also view our full list of official chatrooms.
If you think I'm wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding!


JSON insufficient for the openapi document.

During the June 28th TSC meeting, we held an informal vote and agreed on JSON.
I was tasked with creating a base document from which we could create examples. After noting that all of the existing openAPI examples are in YAML, I checked out why:
These documents often use a "$ref: '#/path/to/object'" method of relating objects together. It is a feature unique to YAML. I think we'll need to do YAML for this document, although we can still use JSON for actual calls.

@dcroshere, are you sure that is unique to YAML? Unless I am reading the Open API document incorrectly, it looks like they provide an example of using $ref in JSON. https://swagger.io/docs/specification/using-ref

You are correct, this is my mistake.


Compute m_[uE,vN] & prof_[U,V] in profiles independent of pkg/ecco

What changes does this PR introduce?
feature: allows pkg/profiles to be compiled and run and produced mooring prof_[U,V] outputs without needing pkg/ecco.
What is the current behaviour?
At the moment, pkg/profiles works independently only for prof_[T,S] (and may be other tracers (?)).  When having mooring arrays with prof_[U,V], no model equivalent outputs are calculated for these two quantities unless pkg/ecco is compiled.
What is the new behaviour
In this modification, I put ifndef ALLOW_ECCO block inside 3 files within pkg/profiles, such that if pkg/ecco is not compiled, then global variables m_[uE,vN] are still defined, calculated, and prof_[U,V] can be filled in within pkg/profiles.
When pkg/ecco is defined, then the old (current) behavior takes place as before, with m_[uE,vN] being defined and calculated within pkg/ecco.
Does this PR introduce a breaking change?
(What changes might users need to make in their application due to this PR?)
I do not anticipate any breaking changes.  I suspect I might be the first user to try to use pkg/profiles without pkg/ecco and thus realizing I did not get prof_[U,V] unless I compile with pkg/ecco.
Other information:
While making this mod, I have also noticed that prof_etan also requires pkg/ecco for computation.  Potentally this could also be changed such that it can pkg/profiles is completely independent of pkg/ecco.

@antnguyen13 thanks for this, couple of questions

why is #ifndef ALLOW_ECCO needed. Thats not clear to me?

profiles_inloop.F_new looks like a file that got pushed by mistake?

@gaelforget could you take a look at this - thanks. Chris

prof_[U,V] in pkg/profiles need m_[uE,vN] .  m_[uE,vN] (the eastward and northward components of the model uvel and vvel are defined only in pkg/ecco/ecco.h and calculated in pkg/ecco/ecco_phys.F .  So currently to access these variables to fill out something in pkg/profiles we would also need to compile pkg/ecco .  Ideally I would have preferred that these two global variables m_[uE,vN] are defined outside of any package so we can just access them.  However, I searched the code and the only packages that need them are pkg/ecco and pkg/profiles.  So, to summarize:
a) if compile pkg/profiles & pkg/ecco, m_[uE,vN] are available
b) if compile only pkg/ecco , m_[uE,vN] are available
c) if compile only pkg/profiles, m_[uE,vN] are NOT available.
I'd like to fix (c) , and avoid double define and double calculating in case of (a) , hence the #ifndef ALLOW_ECCO , i.e., only in the case of (c) that we define and calculate the variables within pkg/profiles.

Ah, must be a mistake, sorry, this is my first time ever checking in something on git!  And I do not see a copy of profiles_inloop.F_new on my local machine, so I'm a bit confused.. Could you suggest how to remove that file if locally you don't see it? I had thought I finished all my edits and removed all extra files before doing git add . and git commit .

try git rm  profiles_inloop.F_new

@jklymak Thanks, but I don't have the file on my local machine, that's why I'm confused..
[atnguyen@ profiles]$ git rm profiles_inloop.F_new
fatal: pathspec 'pkg/profiles/profiles_inloop.F_new' did not match any files

Backup your local branch, and then in the branch do git reset --hard origin/separate_profiles_ecco.  That'll get your branch to be exactly whats on GitHub.  Then git rm and git commit and git push.  There is probably also a way to remove the file directly using git rm, but it seems you've somehow changed locally so maybe safer to start with whats on GitHub as described above.

@jklymak Thanks! I got through almost everything, except during the commit/push, when it first i updated the wrong branch, then accidentally created a new branch (very new to git and still very confused about how to point to the right branch when pushing...)
@christophernhill Could you please check if the extra file profiles_inloop.F_new is removed?  These are the steps I used:
[atnguyen@ pkg]$ git remote add upstream https://github.com/MITgcm/MITgcm.git
fatal: remote upstream already exists.
[atnguyen@nansen pkg]$ git fetch upstream
[atnguyen@nansen pkg]$ git reset --hard origin/separate_profiles_ecco
HEAD is now at da0e076 Compute m_[uE,vN] & prof_[U,V] in profiles independent of pkg/ecco
[atnguyen@nansen profiles]$ git rm profiles_inloop.F_new
rm 'pkg/profiles/profiles_inloop.F_new'
[atnguyen@nansen profiles]$ git status
On branch salt_plume_bugfix
Changes to be committed:
(use "git reset HEAD ..." to unstage)

deleted:    profiles_inloop.F_new

[atnguyen@nansen profiles]$ git commit -m "remove not needed file"
[salt_plume_bugfix 50fc386] remove not needed file
1 file changed, 131 deletions(-)
delete mode 100644 pkg/profiles/profiles_inloop.F_new
[atnguyen@nansen profiles]$ git push -u origin separate_profiles_ecco
Branch separate_profiles_ecco set up to track remote branch separate_profiles_ecco from origin.
Everything up-to-date
[atnguyen@nansen profiles]$ git status
On branch salt_plume_bugfix
nothing to commit, working directory clean
[atnguyen@nansen profiles]$ git push -u origin origin/separate_profiles_ecco
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/antnguyen13/MITgcm.git

[new branch]      origin/separate_profiles_ecco -> origin/separate_profiles_ecco
[atnguyen@nansen profiles]$ git checkout separate_profiles_ecco
Switched to branch 'separate_profiles_ecco'
[atnguyen@nansen profiles]$ git push
warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
Everything up-to-date
[atnguyen@nansen profiles]$ git status

On branch separate_profiles_ecco
nothing to commit, working directory clean
(now I think i have an extra branch origin/separate_profile_ecco ? )

Just put tripple quotes around the whole thing!
Yeah, not sure what you did there, but I just do git push origin branchname.

@jklymak  Could you check the commands I typed above again (now with edited tripple backquotes)? I did do git commit after removing.  I think I was just confused which branch I was on and whether I was pushing to the right branch (or that it created new branches).  I think I now have 2 branches: separate_profiles_ecco and origin/separate_profiles_ecco . Let me check via the browser now.

@antnguyen13
Re: 1. prof_[U,V] in pkg/profiles need m_[uE,vN] . m_[uE,vN] (the eastward and northward components of the model uvel and vvel) are defined only in pkg/ecco/ecco.h and calculated in pkg/ecco/ecco_phys.F  etc....
I'll get together with Gael on this. If possible, it would be nice not to have it in two different places depending on ifndef double negative, which can be confusing. Not sure if it is possible though!

@antnguyen13 the origin/ at the start of the branch name means that it is the version of that branch in your GitHub repository (i.e. in your fork of MITgcm, see @jrscott's lovely figure 5.1 here). It's not a duplicate.
I'm not sure why you're having such trouble removing the file, The instructions from @jklymak should have worked.

My preference, instead of duplicating code from pkg/ecco to pkg/profiles, would be that you add a test in pkg/profiles that issues a warning (a stop would probably be excessive) when variables defined in pkg/ecco are needed in pkg/profiles but pkg/ecco has not been compiled. The test conditions should be easy to formulate once data.profiles and the *.nc inputs have been scanned (i.e., after profiles_init_fixed; ideally in a new function called profiles_check). User can then decide to compile pkg/ecco or otherwise. BTW I dont think that the memory footprint of compiling pkg/ecco on top of pkg/profiles is significant.
On a related note, the only gridded fields that are currently being defined in pkg/profiles are prof_etan_mean, prof_theta_mean, and prof_salt_mean -- feel free to remove these while you are it. These are actually never used and only prof_etan_mean, which was once used, even gets assigned ... in pkg/ecco by copying the old "psmean" variable . Additional comments about that: using m_eta rather than psmean, if needed, would be better and can be done without prof_etan_mean; replicating pkg/ecco's time-averaging capabilities in pkg/profiles would not be a great idea either in my opinion.

Hang on, I think I've worked it out - you were on the salt_plume_bugfix branch when you did the reset and removed the file. You need to be on the separate_profiles_ecco branch. Before you execute the commands Jody suggested, execute git checkout separate_profiles_ecco

@gaelforget @christophernhill
I think it would be nice to not have pkg/profiles needing pkg/ecco simply for 2 lines of code that access something readily available in the model (and not something specific to pkg/ecco):  the model's U and V (rotated to East and North, using commonly used subroutine ROTATE_UV2EN_RL) .
Would it be possible to just name the variable different from m_[uE,vN] and have pkg/profiles always just do this calculation without looking to pkg/ecco?  That is to remove my modification of ifndef ALLOW_ECCO, and simply fill in a new set of variables = rotated velocity inside pkg/profiles?
As you mentioned, it's annoying to have "duplicating" code .  But because this is such a basic calculation that I think regardless how m_[uE,vN] might be modified in ecco_phys.F , for pkg/profiles it's always the same: simply the rotated velocities.

@edoddridge
I think i finally figured that part out after I pushed and it said "now onsalt_plume_bugfix branch.  I did re-checkout separate_profiles_ecco and did re-push the new code in.  I hope everything is in order now and that the extra file is removed?

I hope everything is in order now and that the extra file is removed?

Look under the "Files Changed" tab above.

@jklymak oh no, i still see it, ack! ok, i'll sort this out within today. Thanks. I wasn't sure what you meant by "Files Changed" yesterday but now see it in my browser.

@antnguyen13 I find this page useful, and mostly follow it to understand git:  https://matthew-brett.github.io/pydagogue/gitwash/development_workflow.html#some-other-things-you-might-want-to-do

@antnguyen13
Re: I think it would be nice to not have pkg/profiles needing pkg/ecco simply for 2 lines of code....
Agreed. Not sure what is good way to do this. Jeff has offered to help figure that out with you and Gael. It would be nice to avoid having a gradual accretion of duplicate stuff because ecco, autodiff, prof etc.. are treading on each others toes -- maybe that is not possible, but it would be a good goal.

@antnguyen13: since this thread has grown so extensive already, I feel it may be worth asking: why is not compiling pkg/ecco/ important to you? Would this save you a large memory footprint even if data.ecco were empty? Something else?
@christophernhill, regarding "would be nice to avoid having a gradual accretion of duplicate stuff": yes that is my basic concern; replicating the m_eta computation and array in pkg/profiles/ would likely be next; and so on and so forth.
@christophernhill, regarding "ecco, autodiff, prof etc.. are treading on each others toes": I feel that ecco dealing with gridded data sets and profiles dealing with ungridded data sets makes sense as a general principle. The addition of ecco_phys.F was meant to provide a location for quantities like m_eta, m_UE, m_VN to be computed and stored within ecco/ (I did not see another obvious location at the time). pkg/profiles/ would then subsample gridded fields from pkg/ecco/ like it already did for gridded fields from model/inc/ and now also does for pkg/ptracers/. In contrast, having pkg/ecco inherit gridded fields computed in pkg/profiles/ would have made no sense to me. Merging ecco/ and profiles/ would have been one way to avoid code duplication but gridded and ungridded data sets often involve different issues, methods, etc. so I am still not in favor of that approach. Another approach would consist in moving m_UE, m_VN, m_eta, etc. (computations and arrays) to model/ whenever they start being used in several packages -- if making profiles/ independent from ecco/ is important (?) then maybe this is the best way to proceed. Would be curious to know what @jm-c thinks about this.
@christophernhill, regarding "ecco, autodiff, prof etc.. are treading on each others toes": the situation may be worse than you realize. ctrl/ and various cryosphere related packages have their own gridded cost function codes and arrays -- maybe we should leave that alone for now, but all of this duplication would be worth looking into as some point. Things also remain pretty messy wrt ocbs/ controls and costs if I recall correctly -- let's leave that can of worms alone too. Not totally sure why you listed autodiff/ here but there probably was a good reason and cost/ probably should also be mentioned. If I were to summarize I would say that things have come a long way since the good old days when pkg/ecco/ contained a copy of the_main_loop, and I did put quite a bit of time removing the duplicates and disentangling some of this stuff, but a fair amount of work remains needed. @jrscott would do a great service to this community if he were to take on some of the remaining issues. I can provide some guidance, but again I would be curious to know what @jm-c would advise.
Sorry the text above got so long -- hopefully I spent enough time on it to avoid adding confusion...

Hmmm - it sounds like there isn’t an easy way to do this more tidily as
things currently stands. Maybe logging the issues for things that might be
needed to make profs usable outside of Ecco-autodiff-curl-cost (assuming
that is desirable) is best that can be done for now and then doing ifndef
thing for now?
It sounds like any approach except the ifndef Ecco scheme is going to
involve some effort.
On Tue, Mar 27, 2018 at 13:58 Gael Forget<EMAIL_ADDRESS>wrote:

@antnguyen13 https://github.com/antnguyen13: since this thread has
grown so extensive already, I feel it may be worth asking: why is not
compiling pkg/ecco/ important to you? Would this save you a large memory
footprint even if data.ecco were empty? Something else?
@christophernhill https://github.com/christophernhill, regarding "would
be nice to avoid having a gradual accretion of duplicate stuff": yes that
is my basic concern; replicating the m_eta computation and array in
pkg/profiles/ would likely be next; and so on and so forth.
@christophernhill https://github.com/christophernhill, regarding "ecco,
autodiff, prof etc.. are treading on each others toes": I feel that ecco
dealing with gridded data sets and profiles dealing with ungridded data
sets makes sense as a general principle. The addition of ecco_phys.F was
meant to provide a location for quantities like m_eta, m_UE, m_VN to be
computed and stored within ecco/ (I did not see another obvious location at
the time). pkg/profiles/ would then subsample gridded fields from pkg/ecco/
like it already did for gridded fields from model/inc/ and now also does
for pkg/ptracers/. In contrast, having pkg/ecco inherit gridded fields
computed in pkg/profiles/ would have made no sense to me. Merging ecco/ and
profiles/ would have been one way to avoid code duplication but gridded and
ungridded data sets often involve different issues, methods, etc. so I am
still not in favor of that approach. Another approach would consist in
moving m_UE, m_VN, m_eta, etc. (computations and arrays) to model/ whenever
they start being used in several packages -- if making profiles/
independent from ecco/ is important (?) then maybe this is the best way to
proceed. Would be curious to know what @jm-c https://github.com/jm-c
thinks about this.
@christophernhill https://github.com/christophernhill, regarding "ecco,
autodiff, prof etc.. are treading on each others toes": the situation may
be worse than you realize. ctrl/ and various cryosphere related packages
have their own gridded cost function codes and arrays -- maybe we should
leave that alone for now, but all of this duplication would be worth
looking into as some point. Things also remain pretty messy wrt ocbs/
controls and costs if I recall correctly -- let's leave that can of worms
alone too. Not totally sure why you listed autodiff/ here but there
probably was a good reason and cost/ probably should also be mentioned. If
I were to summarize I would say that things have come a long way since the
good old days when pkg/ecco/ contained a copy of the_main_loop, and I did
put quite a bit of time removing the duplicates and disentangling some of
this stuff, but a fair amount of work remains needed. @jrscott
https://github.com/jrscott would do a great service to this community
if he were to take on some of the remaining issues. I can provide some
guidance, but again I would be curious to know what @jm-c
https://github.com/jm-c would advise.
Sorry the text above got so long -- hopefully I spent enough time on it to
avoid adding confusion...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MITgcm/MITgcm/pull/71#issuecomment-376617935, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADXx4M3LEHHmIGaVdS7lVo4JdagbX7Mfks5tin2ngaJpZM4S5l7L
.

I took a look at pkg/profiles and changes from this PR:

appart from this '''profiles_inloop.F_new''', the rest seems reasonable;
I also understand that one may want to use pkg/profiles without pkg/ecco,
but I have no idea about what this means in term of cost/ctrl (and adjoint).
@antnguyen13 does this work nicely in both forward and adjoint mode ?

for a coding point of view:
if the array to be sampled was passed as argument of S/R PROFILES_INTERP (instead
of having all arrays included within profiles_interp.F) it would certainly
help for this type of modification. But currently it's not the case
so this modification has to involve saving m_UE and m_VN in a common block
with the same name as in '''ecco.h'''.

On Tue, Mar 27, 2018 at 11:28:32AM -0700, christophernhill wrote:

Hmmm - it sounds like there isn???t an easy way to do this more tidily as
things currently stands. Maybe logging the issues for things that might be
needed to make profs usable outside of Ecco-autodiff-curl-cost (assuming
that is desirable) is best that can be done for now and then doing ifndef
thing for now?
It sounds like any approach except the ifndef Ecco scheme is going to
involve some effort.
On Tue, Mar 27, 2018 at 13:58 Gael Forget<EMAIL_ADDRESS>wrote:

@antnguyen13 https://github.com/antnguyen13: since this thread has
grown so extensive already, I feel it may be worth asking: why is not
compiling pkg/ecco/ important to you? Would this save you a large memory
footprint even if data.ecco were empty? Something else?
@christophernhill https://github.com/christophernhill, regarding "would
be nice to avoid having a gradual accretion of duplicate stuff": yes that
is my basic concern; replicating the m_eta computation and array in
pkg/profiles/ would likely be next; and so on and so forth.
@christophernhill https://github.com/christophernhill, regarding "ecco,
autodiff, prof etc.. are treading on each others toes": I feel that ecco
dealing with gridded data sets and profiles dealing with ungridded data
sets makes sense as a general principle. The addition of ecco_phys.F was
meant to provide a location for quantities like m_eta, m_UE, m_VN to be
computed and stored within ecco/ (I did not see another obvious location at
the time). pkg/profiles/ would then subsample gridded fields from pkg/ecco/
like it already did for gridded fields from model/inc/ and now also does
for pkg/ptracers/. In contrast, having pkg/ecco inherit gridded fields
computed in pkg/profiles/ would have made no sense to me. Merging ecco/ and
profiles/ would have been one way to avoid code duplication but gridded and
ungridded data sets often involve different issues, methods, etc. so I am
still not in favor of that approach. Another approach would consist in
moving m_UE, m_VN, m_eta, etc. (computations and arrays) to model/ whenever
they start being used in several packages -- if making profiles/
independent from ecco/ is important (?) then maybe this is the best way to
proceed. Would be curious to know what @jm-c https://github.com/jm-c
thinks about this.
@christophernhill https://github.com/christophernhill, regarding "ecco,
autodiff, prof etc.. are treading on each others toes": the situation may
be worse than you realize. ctrl/ and various cryosphere related packages
have their own gridded cost function codes and arrays -- maybe we should
leave that alone for now, but all of this duplication would be worth
looking into as some point. Things also remain pretty messy wrt ocbs/
controls and costs if I recall correctly -- let's leave that can of worms
alone too. Not totally sure why you listed autodiff/ here but there
probably was a good reason and cost/ probably should also be mentioned. If
I were to summarize I would say that things have come a long way since the
good old days when pkg/ecco/ contained a copy of the_main_loop, and I did
put quite a bit of time removing the duplicates and disentangling some of
this stuff, but a fair amount of work remains needed. @jrscott
https://github.com/jrscott would do a great service to this community
if he were to take on some of the remaining issues. I can provide some
guidance, but again I would be curious to know what @jm-c
https://github.com/jm-c would advise.
Sorry the text above got so long -- hopefully I spent enough time on it to
avoid adding confusion...
???
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MITgcm/MITgcm/pull/71#issuecomment-376617935, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADXx4M3LEHHmIGaVdS7lVo4JdagbX7Mfks5tin2ngaJpZM4S5l7L
.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/MITgcm/MITgcm/pull/71#issuecomment-376627809

@antnguyen13 I did
git clone https://github.com/antnguyen13/MITgcm antnguyen13-MITgcm
cd antnguyen13-MITgcm
git checkout separate_profiles_ecco
cd pkg/profiles/
git rm profiles_inloop.F_new
git commit
git push

to get rid of zoombie profiles_inloop.F_new in PR (it will still hang around in intermediate commit but thats OK).
The file may still be lurking in other branches you have and/or in local copies that haven't
been updated. I think that will do for now - lets hope it doesn't come back from the dead....

In fact, pkg/profiles/ has long been tested without any of the state estimation packages in global_with_exf (in forward mode when pkg/profiles/ can be used as a diagnostic tool) and it seems to behave as expected in that configuration. @antnguyen13's issue rather is that variables which live in pkg/ecco/ are not available to pkg/profiles/ when pkg/ecco/ is not compiled (my guess is that this currently results in a bunch of 0s being outputed without any error or warning).
With this being said, I just double checked: pkg/ecco/ does have a sizable memory footprint based on what the ECCO_OPTIONS.h and ecco.h defaults. So here is what I would propose: if agreed that, once the memory footprint of pkg/ecco/ has been reduced, the newly duplicated code will be removed and replaced with a warning that pkg/ecco should be compiled (or a stop) then just proceed with the PR and let's be done with this for now.

Made some notes in issue #79 and merging.


Select all fields on an object for a SOQL Query

Is your feature request related to a problem? Please describe.
I need to backup a set of records before performing mass update or delete and want to capture a csv of all the fields on it...
Presently I need to switch to a different tool to get the query or manually select each field one by one
Describe the solution you'd like
Add a "button" or even better a "Picklist" under "field suggestions" to select all available fields (with different flavors below).
Describe alternatives you've considered
Possible options
1 - (Simple and common) Loop through all of the fields and make a comma separated list.
[Just this would be a big improvement and I think the data is already available]
2 - (Better) Generate a list of all fields the running user has access to, checking for FLS visibility first
[It is relatively common for deprecated fields to be hidden via FLS, even from admin but they still physically exist]
3 - (Reach) - Add a list of "editable" fields
[Since formula fields only present a calculated value but do not store a value themselves,  they cannot written to and therefore has is nothing to "roll back" if an update was performed mistakenly & need to load the data back.
Some objects have MANY of these fields and the update will fail trying to write to a read-only field]
Additional context
Yes, FIELDS(ALL) works if there is less than 200 records but it is very common to need to update more than that...
Also IMO the logic is too simplistic for some use cases (e.g. ignores FLS and editable)
Other tools have something simular to this (workbench, data loader, XL-Connector)

Hi @BL-isidle,
It is already possible, I added a new section in the documentation


Pass raw AWS Lambda event via the WSGI environ dictionary

I've been happily using awsgi until encountering an issue when using API Gateway custom authorizers. The authorizer context, which allows your authorizer to pass custom data to the application (e.g. user ID, group membership, permissions, etc.), exists as a dictionary value in the Lambda event. It lives in event['requestContext']['authorizer'], but this value is not passed by awsgi to the application.
Since AWS could at any time add other bits of useful metadata to the Lambda event, would it make sense for awsgi to just pass the AWS Lambda event to the application via the WSGI environ dictionary?

Fixed by #22
Thanks for the report @jordal


bump version to 1.4.0

closing as there is more to do before #67 is completed

ah! Cool I thought I missed the release. I still have time to do it :)

ha! I'm in no hurry, I just was looking at this last night and got ahead of myself.


Trying to update Powershell with winget fails

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
Whenever I attempt to update powershell 7 using winget winget upgrade --Id Microsoft.Powershell this fails with the error: "A newer version was found, but the install technology is different from the current version installed. Please uninstall the package and install the newer version".
Expected behavior
Expected behavior is still update powershell to the latest version using winget.

Actual behavior
Updating powershell fails with an error. When viewing the logs, it appears that the local version installed is a .exe while the winget installer is a wix.

Error details
`winget upgrade --Id Microsoft.PowerShell
A newer version was found, but the install technology is different from the current version installed. Please uninstall the package and install the newer version.`

Environment data
Name                           Value
----                           -----
PSVersion                      7.2.5
PSEdition                      Core
GitCommitId                    7.2.5
OS                             Microsoft Windows 10.0.25174
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Visuals
WinGet-2022-08-15-22-29-43.277.log

I think this is an issue that should have been raised on the Winget Packages repo and not here as the PowerShell team do not own the install process via winget & as such I am closing this issue.

This does indeed appear to be a Powershell issue according to the logs (which i also just replicated)
Powershell version <IP_ADDRESS> reports to be installed as a EXE instead of a MSI/MSIX installer
2022-08-16 19:40:00.933 [CLI ] Starting installer selection.
2022-08-16 19:40:00.933 [CLI ] Installer [X64,wix,Machine,] not applicable: Installed package type 'exe' is not compatible with installer type wix
2022-08-16 19:40:00.933 [CLI ] Installer [X86,wix,Machine,] not applicable: Installed package type 'exe' is not compatible with installer type wix
2022-08-16 19:40:00.933 [CLI ] Installer [Arm,msix,Machine,] not applicable: Installed package type 'exe' is not compatible with installer type msix
2022-08-16 19:40:00.933 [CLI ] Installer [Arm,msix,Machine,] not applicable: Machine is not compatible with Arm
2022-08-16 19:40:00.933 [CLI ] Installer [Arm64,msix,Machine,] not applicable: Installed package type 'exe' is not compatible with installer type msix
2022-08-16 19:40:00.933 [CLI ] Installer [Arm64,msix,Machine,] not applicable: Machine is not compatible with Arm64
2022-08-16 19:40:00.933 [CLI ] Installer [X86,msix,Machine,] not applicable: Installed package type 'exe' is not compatible with installer type msix
2022-08-16 19:40:00.933 [CLI ] Installer [X64,msix,Machine,] not applicable: Installed package type 'exe' is not compatible with installer type msix

Please don't stick your head into the sand before checking the easy to read logs next time :)
IF you are going to say "We've changed how the installer works", how would we know?


Lumina: unregistered desktop

Output of desktop-file-validate command:
lumina-info.desktop: error: value "Lumina" for key "OnlyShowIn" in group "Desktop Entry" contains an unregistered value "Lumina"; values extending the format should start with "X-"
The pcbsd uses a patched desktop-file-utils, or this is a bug?

The "desktop-file-validate" utility you refer to probably is not aware of the Lumina desktop (this was also an issue for a while with users of "xdg-open" and other cross-DE utilities).
However, I did just find a capitalization issue with the lumina-info.desktop file, where is set "OnlyShowIn=Lumina", but the XDG_CURRENT_DESKTOP value is set to "LUMINA". I just fixed that in the source code a moment ago.
Link to the standards governing the use of the this file:
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html

The desktop-file-validate tool uses an internal list to recognize desktops:
http://cgit.freedesktop.org/xdg/desktop-file-utils/tree/src/validate.c#n365
The „Lumina” not listed here, so the validation tool doesn't accept it.

Yep , sounds like that utility needs an update by it's developers then.... :-)
You might want to let them know about it so that it gets corrected sooner rather than later...


Support task metadata

This feature would be quite useful for myself and I am wondering if folks are still open to supporting it. I don't even think it is particularly necessary to display the metadata field in inspect view, it would be useful even just for programmatically loading metadata about an eval run.

Interestingly we have a metadata field in the EvalSpec (which is what this is drawing from) but no way to populate it! I wonder if should add a metadata field to Task and forward it here? (@dragonstyle LMK what you think)

Originally posted by @aisi-inspect in https://github.com/UKGovernmentBEIS/inspect_ai/issues/50#issuecomment-2175918773

Resolved with https://github.com/UKGovernmentBEIS/inspect_ai/pull/656


AIML40 bug 2

I found another problem in AIML 40 demo2, when I use clothing_automl.xlsx it to dataset , I found preview show error like this ，characters are garbled。  I use UTF-8 ..........

@lokinfey Change format to Tabular

@lokinfey please confirm when changing this to tabular the setup works? I will then close this issue

The instructions confirm the need for the dataset to be uploaded in Tabular format - therefore I am closing this issue. Thank you for sharing