Missing Mupen64plus Standalone for Latest Arkos version (05/24/24)

This has been a problem for quite some time now but my ArkOS version does not come with the Mupen64plus Standalone which it says it has. Do you know how to install it?

What is your unit?

RG353VS
I notice it said you update mupe64plus standalone and you emulators and ports information has it listed.

Then it's already included.  You just need to install a supported n64 rom with the correct extension per the Emulators and Ports section then select standalone-gliden64, standalone-rice, or standalone-glide64mk2

okay then


Task 4: Add method to evaluate CalculatorBrain

Now that you allow variables to be entered as operands, add a method to evaluate the CalculatorBrain (i.e. calculate its result) by substituting values for those variables found in a supplied Dictionary ...
    func evaluate(using variables: Dictionary<String,Double>? = nil)
          -> (result: Double?, isPending: Bool, description: String)

Note that this takes an Optional Dictionary (with Strings as keys and Doubles as values) as its argument and that that argument defaults to nil if not supplied when this method is called. Also note that it returns a tuple (the first element of which is an Optional Double). This method is not mutating and you are not allowed to make it so. If a variable that has been set as an operand is not found in the Dictionary, assume its value is zero.

Commit 60d3383 solves this task.


🎉 New Design + Migrate to Next.js

Closing because another version with more improvements is in progress


update schinese - release notes 20240125/20240201 and some strings

Can you take a screenshot of what it looks like on your computer? I think mine is mixing multiple different system fonts on the blue buttons.

To get these notifications, rd_notification_debug_fake 1 on the beta branch.


Symfony 7

Thanks for the PR!

@oojacoboo any idea when this is going to be added to a new release? 🥇

@jerowork done.

@jerowork done.

Awesome! Thanks for the work 🙌


Enable workflow for csp-billing-adapter-google

Looks good in general, have a couple of questions.


[NFS] failed to pull image; failed to convert; operation not supported: unknown

Description
I m want to run my cluster over pxe and using for that nfs. i guess this is the problem, after reading this: https://github.com/containerd/containerd/issues/3762#issuecomment-922464270
but i dont know how to fix it.
I cant pull images. (i only test the kubernetes image)
I created first a ticket on Kubernetes for addition info.
https://github.com/kubernetes/kubeadm/issues/2608
Steps to reproduce the issue

Boot ubuntu from PXE server with fully NFS filesystem.
Try to pull an image with crictl pull k8s.gcr.io/kube-apiserver:v1.22.4

Describe the results you received and expected
I received: crictl pull k8s.gcr.io/kube-apiserver:v1.22.4 =
WARN[0000] image connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock]. As the default settings are now deprecated, you should set the endpoint instead.
ERRO[0002] connect endpoint 'unix:///var/run/dockershim.sock', make sure you are running as root and the endpoint has been started: context deadline exceeded
FATA[0016] pulling image: rpc error: code = Unknown desc = failed to pull and unpack image "k8s.gcr.io/kube-apiserver:v1.22.4": failed to extract layer sha256:73ac8c719e66cdb24825a3c9b3e3e23a069a7a8e0067864d221362bb77f9aba6: failed to convert whiteout file "usr/local/.wh..wh..opq": operation not supported: unknown

What version of containerd are you using?
containerd github.com/containerd/containerd 1.5.5-0ubuntu3
Any other relevant information
runc version 1.0.1-0ubuntu2
spec: 1.0.2-dev
go: go1.16.5
libseccomp: 2.5.1
crictl info
WARN[0000] runtime connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock]. As the default settings are now deprecated, you should set the endpoint instead.
ERRO[0002] connect endpoint 'unix:///var/run/dockershim.sock', make sure you are running as root and the endpoint has been started: context deadline exceeded
{
  "status": {
    "conditions": [
      {
        "type": "RuntimeReady",
        "status": true,
        "reason": "",
        "message": ""
      },
      {
        "type": "NetworkReady",
        "status": false,
        "reason": "NetworkPluginNotReady",
        "message": "Network plugin returns error: cni plugin not initialized"
      }
    ]
  },
  "cniconfig": {
    "PluginDirs": [
      "/opt/cni/bin"
    ],
    "PluginConfDir": "/etc/cni/net.d",
    "PluginMaxConfNum": 1,
    "Prefix": "eth",
    "Networks": [
      {
        "Config": {
          "Name": "cni-loopback",
          "CNIVersion": "0.3.1",
          "Plugins": [
            {
              "Network": {
                "type": "loopback",
                "ipam": {},
                "dns": {}
              },
              "Source": "{\"type\":\"loopback\"}"
            }
          ],
          "Source": "{\n\"cniVersion\": \"0.3.1\",\n\"name\": \"cni-loopback\",\n\"plugins\": [{\n  \"type\": \"loopback\"\n}]\n}"
        },
        "IFName": "lo"
      }
    ]
  },
  "config": {
    "containerd": {
      "snapshotter": "overlayfs",
      "defaultRuntimeName": "runc",
      "defaultRuntime": {
        "runtimeType": "",
        "runtimeEngine": "",
        "PodAnnotations": [],
        "ContainerAnnotations": [],
        "runtimeRoot": "",
        "options": {},
        "privileged_without_host_devices": false,
        "baseRuntimeSpec": ""
      },
      "untrustedWorkloadRuntime": {
        "runtimeType": "",
        "runtimeEngine": "",
        "PodAnnotations": [],
        "ContainerAnnotations": [],
        "runtimeRoot": "",
        "options": {},
        "privileged_without_host_devices": false,
        "baseRuntimeSpec": ""
      },
      "runtimes": {
        "runc": {
          "runtimeType": "io.containerd.runc.v2",
          "runtimeEngine": "",
          "PodAnnotations": [],
          "ContainerAnnotations": [],
          "runtimeRoot": "",
          "options": {
            "BinaryName": "",
            "CriuImagePath": "",
            "CriuPath": "",
            "CriuWorkPath": "",
            "IoGid": 0,
            "IoUid": 0,
            "NoNewKeyring": false,
            "NoPivotRoot": false,
            "Root": "",
            "ShimCgroup": "",
            "SystemdCgroup": false
          },
          "privileged_without_host_devices": false,
          "baseRuntimeSpec": ""
        }
      },
      "noPivot": false,
      "disableSnapshotAnnotations": true,
      "discardUnpackedLayers": false
    },
    "cni": {
      "binDir": "/opt/cni/bin",
      "confDir": "/etc/cni/net.d",
      "maxConfNum": 1,
      "confTemplate": ""
    },
    "registry": {
      "configPath": "",
      "mirrors": {},
      "configs": {},
      "auths": {},
      "headers": {
        "User-Agent": [
          "containerd/1.5.5-0ubuntu3"
        ]
      }
    },
    "imageDecryption": {
      "keyModel": "node"
    },
    "disableTCPService": true,
    "streamServerAddress": "<IP_ADDRESS>",
    "streamServerPort": "0",
    "streamIdleTimeout": "4h0m0s",
    "enableSelinux": false,
    "selinuxCategoryRange": 1024,
    "sandboxImage": "k8s.gcr.io/pause:3.5",
    "statsCollectPeriod": 10,
    "systemdCgroup": false,
    "enableTLSStreaming": false,
    "x509KeyPairStreaming": {
      "tlsCertFile": "",
      "tlsKeyFile": ""
    },
    "maxContainerLogSize": 16384,
    "disableCgroup": false,
    "disableApparmor": false,
    "restrictOOMScoreAdj": false,
    "maxConcurrentDownloads": 3,
    "disableProcMount": false,
    "unsetSeccompProfile": "",
    "tolerateMissingHugetlbController": true,
    "disableHugetlbController": true,
    "ignoreImageDefinedVolumes": false,
    "netnsMountsUnderStateDir": false,
    "containerdRootDir": "/var/lib/containerd",
    "containerdEndpoint": "/run/containerd/containerd.sock",
    "rootDir": "/var/lib/containerd/io.containerd.grpc.v1.cri",
    "stateDir": "/run/containerd/io.containerd.grpc.v1.cri"
  },
  "golang": "go1.17",
  "lastCNILoadStatus": "cni config load failed: no network config found in /etc/cni/net.d: cni plugin not initialized: failed to load cni config"

Show configuration if it is related to CRI plugin.
cat /etc/containerd/config.toml
disabled_plugins = []
imports = []
oom_score = 0
plugin_dir = ""
required_plugins = []
root = "/var/lib/containerd"
state = "/run/containerd"
version = 2
[cgroup]
path = ""
[debug]
address = ""
format = ""
gid = 0
level = ""
uid = 0
[grpc]
address = "/run/containerd/containerd.sock"
gid = 0
max_recv_message_size = 16777216
max_send_message_size = 16777216
tcp_address = ""
tcp_tls_cert = ""
tcp_tls_key = ""
uid = 0
[metrics]
address = ""
grpc_histogram = false
[plugins]
[plugins."io.containerd.gc.v1.scheduler"]
deletion_threshold = 0
mutation_threshold = 100
pause_threshold = 0.02
schedule_delay = "0s"
startup_delay = "100ms"
[plugins."io.containerd.grpc.v1.cri"]
disable_apparmor = false
disable_cgroup = false
disable_hugetlb_controller = true
disable_proc_mount = false
disable_tcp_service = true
enable_selinux = false
enable_tls_streaming = false
ignore_image_defined_volumes = false
max_concurrent_downloads = 3
max_container_log_line_size = 16384
netns_mounts_under_state_dir = false
restrict_oom_score_adj = false
sandbox_image = "k8s.gcr.io/pause:3.5"
selinux_category_range = 1024
stats_collect_period = 10
stream_idle_timeout = "4h0m0s"
stream_server_address = "<IP_ADDRESS>"
stream_server_port = "0"
systemd_cgroup = false
tolerate_missing_hugetlb_controller = true
unset_seccomp_profile = ""
[plugins."io.containerd.grpc.v1.cri".cni]
  bin_dir = "/opt/cni/bin"
  conf_dir = "/etc/cni/net.d"
  conf_template = ""
  max_conf_num = 1

[plugins."io.containerd.grpc.v1.cri".containerd]
  default_runtime_name = "runc"
  disable_snapshot_annotations = true
  discard_unpacked_layers = false
  no_pivot = false
  snapshotter = "overlayfs"

  [plugins."io.containerd.grpc.v1.cri".containerd.default_runtime]
    base_runtime_spec = ""
    container_annotations = []
    pod_annotations = []
    privileged_without_host_devices = false
    runtime_engine = ""
    runtime_root = ""
    runtime_type = ""

    [plugins."io.containerd.grpc.v1.cri".containerd.default_runtime.options]

  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]

    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
      base_runtime_spec = ""
      container_annotations = []
      pod_annotations = []
      privileged_without_host_devices = false
      runtime_engine = ""
      runtime_root = ""
      runtime_type = "io.containerd.runc.v2"

      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
        BinaryName = ""
        CriuImagePath = ""
        CriuPath = ""
        CriuWorkPath = ""
        IoGid = 0
        IoUid = 0
        NoNewKeyring = false
        NoPivotRoot = false
        Root = ""
        ShimCgroup = ""
        SystemdCgroup = false

  [plugins."io.containerd.grpc.v1.cri".containerd.untrusted_workload_runtime]
    base_runtime_spec = ""
    container_annotations = []
    pod_annotations = []
    privileged_without_host_devices = false
    runtime_engine = ""
    runtime_root = ""
    runtime_type = ""

    [plugins."io.containerd.grpc.v1.cri".containerd.untrusted_workload_runtime.options]

[plugins."io.containerd.grpc.v1.cri".image_decryption]
  key_model = "node"

[plugins."io.containerd.grpc.v1.cri".registry]
  config_path = ""

  [plugins."io.containerd.grpc.v1.cri".registry.auths]

  [plugins."io.containerd.grpc.v1.cri".registry.configs]

  [plugins."io.containerd.grpc.v1.cri".registry.headers]

  [plugins."io.containerd.grpc.v1.cri".registry.mirrors]

[plugins."io.containerd.grpc.v1.cri".x509_key_pair_streaming]
  tls_cert_file = ""
  tls_key_file = ""

[plugins."io.containerd.internal.v1.opt"]
path = "/opt/containerd"
[plugins."io.containerd.internal.v1.restart"]
interval = "10s"
[plugins."io.containerd.metadata.v1.bolt"]
content_sharing_policy = "shared"
[plugins."io.containerd.monitor.v1.cgroups"]
no_prometheus = false
[plugins."io.containerd.runtime.v1.linux"]
no_shim = false
runtime = "runc"
runtime_root = ""
shim = "containerd-shim"
shim_debug = false
[plugins."io.containerd.runtime.v2.task"]
platforms = ["linux/amd64"]
[plugins."io.containerd.service.v1.diff-service"]
default = ["walking"]
[plugins."io.containerd.snapshotter.v1.aufs"]
root_path = ""
[plugins."io.containerd.snapshotter.v1.btrfs"]
root_path = ""
[plugins."io.containerd.snapshotter.v1.devmapper"]
async_remove = false
base_image_size = ""
pool_name = ""
root_path = ""
[plugins."io.containerd.snapshotter.v1.native"]
root_path = ""
[plugins."io.containerd.snapshotter.v1.overlayfs"]
root_path = ""
[plugins."io.containerd.snapshotter.v1.zfs"]
root_path = ""
[proxy_plugins]
[stream_processors]
[stream_processors."io.containerd.ocicrypt.decoder.v1.tar"]
accepts = ["application/vnd.oci.image.layer.v1.tar+encrypted"]
args = ["--decryption-keys-path", "/etc/containerd/ocicrypt/keys"]
env = ["OCICRYPT_KEYPROVIDER_CONFIG=/etc/containerd/ocicrypt/ocicrypt_keyprovider.conf"]
path = "ctd-decoder"
returns = "application/vnd.oci.image.layer.v1.tar"
[stream_processors."io.containerd.ocicrypt.decoder.v1.tar.gzip"]
accepts = ["application/vnd.oci.image.layer.v1.tar+gzip+encrypted"]
args = ["--decryption-keys-path", "/etc/containerd/ocicrypt/keys"]
env = ["OCICRYPT_KEYPROVIDER_CONFIG=/etc/containerd/ocicrypt/ocicrypt_keyprovider.conf"]
path = "ctd-decoder"
returns = "application/vnd.oci.image.layer.v1.tar+gzip"
[timeouts]
"io.containerd.timeout.shim.cleanup" = "5s"
"io.containerd.timeout.shim.load" = "5s"
"io.containerd.timeout.shim.shutdown" = "3s"
"io.containerd.timeout.task.state" = "2s"
[ttrpc]
address = ""
gid = 0
uid = 0

fully NFS filesystem.

At least the following directories have to be non-NFS:

/var/lib/containerd
/run/containerd
/tmp

@AkihiroSuda thank you for the information but this is not really a solution for me ^^'
is there another way to ship arround that problem. i dont want to use a drive for every system.

now i not happy about the change to switch the container system from docker. hopfully it comes, or it comes a diffrent system.

There are my findings about this issue: https://github.com/kubernetes/kubeadm/issues/2608#issuecomment-1217900824
Basically, nfs/overlayfs/probably other filesystems cannot support contained runtime as they don't support some attributes required for containerd to operate.
I saw this 6273 ticket before, but an answer "don't do that, do that instead" didn't satisfy me and I needed to figure out the WHYs. I hope my findings will let someone else have peace of mind 😊 😌

I posted a link to my solution in the other thread.
truncate -s 10g /home/myuser/xfs.img
mkfs.xfs -m reflink=1 /home/myuser/xfs.img

which is about the same solution as you find for you. Thats why the tickets closed. The reason is also mentioned on the site. But maybe if you don't saw the link, here again https://www.redhat.com/sysadmin/rootless-podman-nfs

Didn't see the truncate solution of yours. Probably some other thread I haven't come across yet.
As for the link and explanation - I saw the link, but my case has nothing to do with podman, so I figured it doesn't apply to me.
Anyways, I'm glad you found your solution. I found mine. It seemed related to this ticket, as the error is the same, so I decided to share my insights with the internet. ;)


Support for Python 2.7

MesoPy doesn't support anything but Python 3. Should resolve this to maximize user accessibility.

travis shows good to go on 2.7 so closing this and marking support for 2.7 as good!


Removed SetInstanceId by making netId setter internal.

ok. did anyone test this in their projects?

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


Intellisense stops working after idle

Environment data

Language Server version: <IP_ADDRESS>
OS and version: macOS 10.15.1 (19B88)
Python version (& distribution if applicable, e.g. Anaconda): Python 3.6.55

Expected behaviour
Should be able to show function recommendations
Actual behaviour

I have to restart my VSCode in order for it to work, which is really an annoying thing to do.
Steps to reproduce:
[NOTE: Self-contained, minimal reproducing code samples are extremely helpful and will expedite addressing your issue]

Leave no activity on VSCode for at least 5-10 minutes
Try to write anything

Logs
Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)
XXX

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help; turn on source maps to make any tracebacks be useful by running Enable source map support for extension debugging)
XXX

I am having a similar issue on macOS 10.14, Python 3.7, MPLS version <IP_ADDRESS>. The Language Server seems to stop working randomly when I come back to a file I was editing a few minutes ago. When it does, there is no import auto-completion/Intellisense/type info on hover/etc.
This is a major issue for me : it has been the main reason I cannot definitively switch from Jedi to MPLS. Are there any updates/ideas on what the problem is ?
Last logs in the Output panel (as you can see, the last logs date from several minutes before the current time) :

No logs about MLPS in the Developer Tools' console.

Can you please set "python.analysis.logLevel": "Trace" to capture more output. Thanks

@MikhailArkhipov after further experiments, it seems that MLPS "crashing" actually happens to me when switching between workspaces in a Multi-Root Workspace environment. I opened #1962  regarding the issue, as it is probably actually different from this one.

I'm still having this issue, I literally need to reload my VSCode every time for it to work again, and now its getting worst, it doesn't even last 5 minutes before it stops working again.

Would it be possible to have a notification, when this the language-server stops working?


Moves mail layouts style tag at the right place

Out of curiosity was the old location causing any issues?

Technically, style tag have to be within the head tag... Strict mail client might not honor it within the body tag.

Fair enough, I'm just wondering if there any real world issues with it. Not opposed to merging, just wondering if there was a real world issue that prompted this because there wasn't anything in the PR description.

Nope @LukeTowers , I did not see any issue, I just worked on some mail layout and figured out it was misplaced.

According to https://www.campaignmonitor.com/css/style-element/style-in-body/ vs https://www.campaignmonitor.com/css/style-element/style-in-head; putting it in the head has slightly better support across some gmail clients, but loses support for yahoo mail on android. Works for me :)


WithProviderClassesFrom does not work with gradle.

Describe the bug
.withProviderClassesFrom("target/classes") is not working with Gradle. I get ERROR: No such provider when Keycloak starts. I have also tried with "build/classes" since the build is generating a build folder in project root, but that doesn't work either.
This is my setup for the container:
@Container
private static final KeycloakContainer keycloak = new KeycloakContainer("quay.io/keycloak/keycloak:22.0.1")
            .withRealmImportFile("/my-realm.json")
            .withProviderClassesFrom("target/classes")
            .withNetwork(network);

Version
3.0.0
Expected behavior
That the provider is found.
Actual behavior
The provider cannot be found.
How to Reproduce?
No response
Relevant log output
No response
Anything else?
No response

There's a current PR trying to fix this, please test with #112 and give some feedback if this solves your issue, thanks.

I tried it. Couldn't get it to work. I tried with "build/classes/java/main", "build/classes" and "target/classes".
I think I'm just going to go with Maven for this project as it seems to be working and it's a simple setup with few dependencies.
Thanks for the quick response though! As soon as there's a fix I'll be switching to Gradle again.

Removed the bug label, as it was not yet designed to work with Gradle. It's more of a kind of enhancement, like a new feature.

@sillen102 I don't have experience with Gradle, so I can't support something valueable here. Perhaps @objecttrouve can help here, as he provided #112 !?

@sillen102, it's possible to work around the issue by importing the extension via the withProviderLibsFrom-method instead of the withProviderClassesFrom-method.
It's just less convenient and requires you to create the jar or shaded jar before running the tests. This can be done in the build script by making the test task dependent on the jar or shadow task. Also, one should ensure that the build directory is always cleaned up first.

# build.gradle.kts
tasks.withType<Test> {
    dependsOn("jar")
}

# myTest
@Container
private val keycloak = KeycloakContainer(...)
.withProviderLibsFrom(listOf(File("build/libs/{modulename}.jar")))

this seem work fine 4 gradle

Closing this, as there are viable workarounds mentioned, also in #112


Preloading images

You said we can enable image preloading in the settings but I cant find it.

In the options window, under the "Interface > Image window" category:

Set it to 1 to preload the next and previous image. 0 (the default value) will disable preloading.


Add option to enable Google Profiler.

[Thanks @hbdeshmukh for the pointers on how to do this.]
This PR makes profiling pretty easy. Steps to take:

Install dependencies: Google Perftools must be installed already. This PR doesn't use the third_party perftools.
Build Quickstep with the ENABLE_GOOGLE_PROFILER flag turned on. You probably want to use Build Type RelWithDebInfo.
When running the CLI shell, pass the profiler_file_name flag to start profiling, and dump profile output to the file name specified. Note that the profiler only starts sampling from the second run of the query, so that it sees warm buffers/caches. Also, the profiler stops collecting samples after the last query run, before the teardown process begins. So we won't see munmap in the profile.
Alternatively, set the environment variable CPUPROFILE to turn on profiling for the entire run (including first run, preloading, foreman and worker setup, etc.).
Use google-pprof --dot profile.prof > profile.dot or something similar to get a usable output.

Tested with flag turned on and off, with RelWithDebInfo, with Clang on CloudLab machine. Dependencies were pre-installed using sudo apt-get install -y libgoogle-perftools-dev google-perftools.

LGTM. We can merge after the conflicts are resolved.

Thanks. I'll resolve and resubmit. I seem to have messed something up in my local branch.

OK, it should be ready now, I think.

LGTM.

Merged!

Thanks Zuyu!

On Jun 13, 2016, at 16:56, Zuyu ZHANG<EMAIL_ADDRESS>wrote:
Merged!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/apache/incubator-quickstep/pull/28#issuecomment-225720999, or mute the thread https://github.com/notifications/unsubscribe/ACZB66ieTRoH8yq2MvGgrIGkSMU7MFzNks5qLdIagaJpZM4Iz4mC.


Allow Symbols Zip to be Downloaded

Describe the solution you'd like
In HockeyApp you could download the symbols zip files that were uploaded for a given release. AppCenter should also allow this functionality.
Describe alternatives you've considered
Archiving the zips on another store, but this would introduce another storage solution to reference as part of our CI/CD process.
Additional context
With HockeyApp, we included our Sparkle appcast.xml files inside our symbols zip to make it easy for our deployment team to grab the appcast during release time. This was just a really convenient place to locate the xml as both the app binary and appcast xml was available in a single location.

Hey there! 👋 We are discussing when to pick up this work, but in the mean time, this is available through our APIs, which should hopefully unblock you! See here and here.

Hey @cainejette, thanks for the calls. Yeah, currently, our QA team is who grabs the zip manually, unarchives and pulls the appcast xml. But we could give them a simple script that grabs them.
I did test this out, and it looks like that API gives me every symbols file that has ever been uploaded... which is a bit unwieldy. I suppose if I include the symbols UUID in the release notes of each build, it'd be easy enough to grab that and run the script, true?
Anyway, yeah, having a non-dev way to download the symbols zip would still be awesome, so thanks for considering it!!

You can also query this API and find the upload ID to then query this API, maybe that would be easier?
But we absolutely hear you that a UI would streamline this for all users!

If you use the API today to upload symbols, we return the symbol upload ID you would use to query that second API directly. If you use the UI to upload symbols, you'd unfortunately need to call that first API to get the right symbol upload ID.

Yeah, we use the API to upload symbols, but it might be days/weeks later that the symbols need to be downloaded, so the upload ID wouldn't necessarily be readily available at that time. But again, I could query it when they are uploaded and store them off for future reference.

I saw this morning that I can now download symbols. Thanks!!
One minor request, would it be possible to include the build number in the download view? It was fairly tricky to match a symbols upload with the respective release.


Accessibility always disabled on Build 1855

Preparation

[X] I read the Troubleshooting Guide
[X] My question isn't answered in any other issues (even the closed ones)

Your question
I just upgrade my FGA from Build 14xx to 1855 because in 14xx, the refresh button area is on the "change skill" or something, usually it's not a problem if there's a support, that's why i never upgrade my FGA, in the past if it's accessibility problem i just restart my phone, now i can't even do anything, tried the solution on Troubleshooting Guide yield no result, restarting, force close, turn off accessiblity then turn it on again, nothing. is there a fix for this OR is there someone who have Build 14xx because it's not on the "Releases" tab" so i can downgrade, thank you

Have you tried reinstalling FGA?


install universe service reset by 10 minute, could change the time?

I am in china, so the net is slowlly.
and when install service from mesosphere, it could't downloaded all the file and install service.
because when 10 minutes after, the install service job will be reset by marthon.
so, how to change the 10 minutes to 20 or 30 minutes??
I can't find any other error from log, just find it reset job per 10 minutes.
Thanks!

@cmaloney or @jasongilanfarr Do we have any advice for @zerix?
@zerix in the future please file issue like this in our DC/OS Jira at https://dcosjira.atlassian.net/secure/Dashboard.jspa


Is it right to throttle the creation of compound files?

Description
Our current merge throttling implementation also covers the creation of the compound file when MergePolicy#useCompoundFile returns true. But I don't think it is right and I suspect that it was not done intentionally:

My understanding is that merge throttling does not generally try to throttle I/O, e.g. integrity checks are not throttled. It mostly uses written bytes as a best-effort proxy for the amount of CPU spent on merging, so that merges leave CPU for searches.
The page cache has protection against long sequential reads/writes from completely trashing the filesystem cache.

@mikemccand Do you know if this was intentional?

I wanted to see if any tests would fail if I would remove throttling when creating compound files, and none did, so I opened a PR. I'm still interested in thoughts regarding whether this was intentional or not.


Transfer workflow files

Including git history. I found this helpful in the process.

pyiron-workflow 0.post0.dev1 requires graphviz, which is not installed.

Which is a bit surprising since the requested graphviz 8.1.0 is clearly getting installed by conda. Maybe because the pypi python interface has a totally different version?
Also:
ModuleNotFoundError: No module named 'pyiron_contrib'

And of course, because I haven't added contrib to the dependencies. But since that is a hot mess I'm trying to escape here, let's just purge the executor in place of a pympipool version.

Pipcheck:
pyiron-workflow 0.post0.dev1 requires graphviz, which is not installed.
maggma 0.46.1 has requirement pyzmq==22.3.0, but you have pyzmq 25.1.1.

Unit tests:
ModuleNotFoundError: No module named 'graphviz'

Riiight, I sort of remember now that there's a difference between the raw graphviz and the python package. Sure enough, contrib had python-graphviz in its env file, and the versions for this guy match with the pypi package graphviz.
As for the maggma error.... This seems related to the mp-api nonsense troubling atomistics.

Pip check:
maggma 0.46.1 has requirement pyzmq==22.3.0, but you have pyzmq 25.1.1.

Notebooks:
5 from pyiron_atomistics import Project, _StructureFactory
...
40 from pyiron_atomistics.atomistics.structure.factories.materialsproject import (
...
File /usr/share/miniconda3/envs/my-env/lib/python3.11/site-packages/mp_api/client/core/utils.py:7
      4 from functools import cache
      5 from typing import Optional, get_args
----> 7 from maggma.utils import get_flat_models_from_model
      8 from monty.json import MSONable
      9 from pydantic import BaseModel

ImportError: cannot import name 'get_flat_models_from_model' from 'maggma.utils' (/usr/share/miniconda3/envs/my-env/lib/python3.11/site-packages/maggma/utils.py)

I get a lower bound pyzmq >=24.0.1 from both the conda-forge feedstock heads of both pympipool and maggma.
The chain to maggma is maggma < mp-api < pyiron_atomistics. Unfortunately, HEAD of the conda-forge feedstock for mp-api doesn't specify any bounds on maggma. Somehow, I'm getting this waaaaay out of date version of maggma (the latest at time of writing is 0.57.1). I have no idea why, but I'm quite sick of fighting materialsproject dependency bugs.

Well, purging pympipool did the trick and all the tests I expected to pass are (coverage is not working because I need to get set up with codacy, and black is failing).
I tried tracking down why pympipool would force a too-old version of maggma to get installed, but didn't get anywhere. Over on ironflow I ran into the same problem; I just cleared the caches there and am simply re-running -- if that works maybe I somehow wound up with a cache problem here in this new repo too??? If so, I'll revert the executor purge here and try again.

Nope, it wasn't the cache. I just pinned maggma over in ironflow, so let's see if that smokes out the offender.

Tests hang now for an hour. This is also a problem I encounter with pympipool when I run tests in pycharm on my macbook. Since my primary objective right now is just to get functioning workflow module moved over to this repository, I'm going to revert to using pyiron_contrib.executors.CloudpickleProcessPoolExecutor.

...
└─ python >=3.7,<3.8.0a0 , which can be installed.
Error: Process completed with exit code 1.

 That will be resolved separately soon, but for now just move on.
I'll repo-transfer the executor code and history over.


Don't show .to_bits in Display impl for Entity

Objective
#12469 changed the Debug impl for Entity, making sure it's actually accurate for debugging. To ensure that its can still be readily logged in error messages and inspectors, this PR added a more concise and human-friendly Display impl.
However, users found this form too verbose: the to_bits information was unhelpful and too long. Fixes #13980.
Solution

Don't include Entity::to_bits in the Display implementation for Entity. This information can readily be accessed and logged for users who need it.
Also clean up the implementation of Display for DebugName, introduced in https://github.com/bevyengine/bevy/pull/13760, to simply use the new Display impl (since this was the desired format there).

Testing
I've updated an existing test to verify the output of Entity::display.

@eidloi could I get your review here?

Exactly what I needed thanks!

Thanks y'all!


version in extension.json no longer allows version suffixes

I just upgraded to dfx 0.23.0 and received this error during the deploy process of Kybra 0.7.0rc0:
Error: Failed to load extension manifest
Caused by: failed to parse contents of /home/lastmjs/.cache/dfinity/versions/0.23.0/extensions/kybra/extension.json as json
Caused by: unexpected character 'r' after patch version number at line 3 column 25

It seems that in dfx 0.23.0, the ability to parse suffixes in the extension.json file for dfx extensions has been lost. This is unfortunate as Azle and Kybra both make extensive use of suffixes during release candidate deploys, and we currently keep the extension.json version completely in sync with the version of Azle or Kybra.

This was my mistake. PyPI will take a version like this: "0.0.0-rc.0" and on the website it seems to remove the hyphen and dot in the suffix to create a version like this: "0.0.0rc0", so I had gotten into the habit of just adopting that pattern in our own code. But if I use correct semver (assuming what PyPI is doing is not correct), then the process works just fine.


won't hash on gpu

I've tried both the v3 beta and the v2. Compiled from source on mac os x catalina. The cpus work fine, the gpu won't hash.
I've got a 2010 mac pro with a sapphire radeon pulse rx580 8GB on catalina.
I followed your instructions in the read me, and also here:
https://www.grin-forum.org/t/grin-v1-0-step-by-step-miner-guide-on-macos-english-version/1630
the miner usually starts with no error, device 0 shows for gpu, connects to the pool and receives work, but it won't hash, says inf.
Screenshots are here:
https://www.grin-forum.org/t/gpu-wont-hash-mac-os-catalina/6801

Did you compile the miner yourself? Instructions above are likely outdated.

I did compile the official grin miner on macos catalina with the instructions on git hub
I posted about it on the grin forum and the people who replied to the thread said it looked like I followed the insteructions
Probably doesn't matter, as I was only ever able to get the cpus to mine at .22gps even though the miner was reporting I was finding shares, never was able to get my gpu to work.
Some people said it may be the pool connection issue, since the grinmint website wasn't reporting the hash I was producing, and not really that the gpu wouldn't mine. So they advised me to contact pool support about the connection issue before spending more time on the gpu
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 6, 2020 4:03 PM, Quentin Le Sceller<EMAIL_ADDRESS>wrote:

Did you compile the miner yourself? Instructions above are likely outdated.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I'm the pool manager of Grinmint and by the look of it it looks like your GPU is mining at all so Grinmint will not show you anything.
Did you uncomment this line before compiling? https://github.com/mimblewimble/grin-miner/blob/master/Cargo.toml#L40

I actually re-compiled the binary numerous times with different options while I was trying to troubleshoot the issue, probably, unless that was in the read.me on github I did not compile without uncommenting that line.
I will try doing that, and see if it will work
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 6, 2020 4:09 PM, Quentin Le Sceller<EMAIL_ADDRESS>wrote:

I'm the pool manager of Grinmint and by the look of it it looks like your GPU is mining at all so Grinmint will not show you anything.
Did you uncomment this line before compiling? https://github.com/mimblewimble/grin-miner/blob/master/Cargo.toml#L40
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Without that line you will not compile any GPU mining plugin (so no GPU mining can be done).

umm, ok.
I just pulled the code off github (again) I can't find that line in any of the files.
I did compile the opencl plugins, and I can get the sevice to show up, but not labled as a gpu
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 6, 2020 4:15 PM, Quentin Le Sceller<EMAIL_ADDRESS>wrote:

Without that line you will not compile any GPU mining plugin (so no GPU mining can be done).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

You mean these pluging, correct?
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 6, 2020 4:22 PM, Kelli<EMAIL_ADDRESS>wrote:

umm, ok.
I just pulled the code off github (again) I can't find that line in any of the files.
I did compile the opencl plugins, and I can get the sevice to show up, but not labled as a gpu
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 6, 2020 4:15 PM, Quentin Le Sceller<EMAIL_ADDRESS>wrote:

Without that line you will not compile any GPU mining plugin (so no GPU mining can be done).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

It's in the main Cargo.toml

Sorry I just notice you were trying to mine with the OpenCL plugin. Give me some time to check a few things...

the only line in that file that's commented out are the cuda pluggins, I'm using opencl
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 6, 2020 4:31 PM, Quentin Le Sceller<EMAIL_ADDRESS>wrote:

It's in the main Cargo.toml
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I just recompiled from source with the instructions on github, noticed something interesting you may like to know
git clone
https://github.com/mimblewimble/grin-miner.git
cd
grin-miner
git submodule update --init
cargo build
cargo build --features opencl
./install_ocl_plugins.sh
Doing this builds the binary in ~/grin-miner/target/debug
but builds all the opencl stuff in ~/grin-miner/target/release
I've been cp'ing the opencl stuff from release folder to the debug folder to run the program with opencl, but I assume they're meant to end up in the same directory
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 6, 2020 4:33 PM, Kelli<EMAIL_ADDRESS>wrote:

the only line in that file that's commented out are the cuda pluggins, I'm using opencl
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 6, 2020 4:31 PM, Quentin Le Sceller<EMAIL_ADDRESS>wrote:

It's in the main Cargo.toml
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Can you compile with cargo build --features opencl --release ?

ok, I did that, still wind up with this:
(see attachments tried with both ocl-cuckaroo and cuckatoo plugins),
and no report of any activity on the grinmint dashboard
grin miner.toml
[[mining.miner_plugin_config]]
plugin_name = "cuckarood_cpu_compat_29"
[mining.miner_plugin_config.parameters]
nthreads = 8
[[mining.miner_plugin_config]]
plugin_name = "ocl_cuckaroo"
[mining.miner_plugin_config.parameters]
platform = 1
device = 0
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 6, 2020 4:48 PM, Quentin Le Sceller<EMAIL_ADDRESS>wrote:

Can you compile with cargo build --features opencl --release ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Any idea @hashmap ?

A mac developer who's also into mining looked at the grin miner and says:
"I had look at grin-miner and it seems the AMD side of things requires the drivers which aren't available for macOS so unfortunately unless there's another miner around which doesn't that's not going to work right now. The majority of algorithms have this issue which makes GPU mining on Mac more than a little tricky."

It's looks like macOS use a very old version of openCL. Closing, probably duplicate of #199


Add original license where applicable

It seems like you're copying a lot of code without including the original license text.
The MIT license states:
Copyright (c) <year> <copyright holders>
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

You're omitting the licenses from the individual source projects, which includes copyright attribution information, in violation of the stated terms of the license. I'm not sure about the other licenses, but at least with the MIT you're probably not adhering to the terms of the license.

Thanks for pointing this out -- I've tried to be as meticulous as possible about providing all the license information for each individual js file, but you're right that I (possibly mistakenly) thought it would be sufficient to have a direct link to the original projects and licenses all in one place rather than copying the license text itself (multiple times over, as most of the code uses a similar license like MIT).
I have no problem with going back and copying over all the license text just to be on the safe side. The practical question then arises of where the best place to put the licenses would be. I suppose they could be inserted into the source files as comments, though I've tried to avoid editing any of the code itself up to now. The other alternative might be to have a separate license file for each entry containing the original license. So e.g., entry.js would have a source file entry_src.js and a license file entry_license.txt. It might get a bit messy, but it's probably better than trying to cram the license text into the already huge markdown table. :smile:
If you have any preferences or suggestions about the best way to do this before I get started, I'd be glad to hear them!

@ebenpack This should be resolved now with commit 454d3af. I went ahead and added a file entry_license.txt for every entry -- hopefully I didn't miss any. As of 473b6b5 there is also an internal link back to each license file from the big table in js/README.md.
Thanks again for raising this issue. I'll close this now, but feel free to comment or open it up again if you have any feedback or notice anything I've missed. It goes without saying that a major goal of this project is to celebrate and acknowledge the work of authors who have had the foresight to open-license their js1k code, so getting the licensing aspect right is obviously very important.


'NSAttributedString' initializer is inaccessible

Thanks for creating and sharing this library -- I'm happy to not have to roll my own markdown formatting!
I'm a relative Swift n00b, so I'm not sure if this is an actual issue or if I'm doing something wrong...
I've pulled down Marker (v1.1.0) using CocoaPods and am trying to use the NSAttributedString initializer extension to create an attributed string like so:
            let contents = NSAttributedString(string: entry,
                                              textStyle: textStyle)

And the build fails with the following error:
'NSAttributedString' initializer is inaccessible due to 'internal' protection level
Adding 'public' to the initializer in NSAttributedString+Extensions.swift does the trick:
    public convenience init(string: String, textStyle: TextStyle) {

I wanted to confirm whether this is the correct fix, and if so to see if it can be rolled into the next release. Or, if the library is correct and I'm using it improperly, that'd be great to know as well.
Thanks,
Robert

Hey Robert, you should be able to use the public functions in Marker.swift for this purpose: https://github.com/prolificinteractive/Marker/blob/master/Marker/Marker/Marker.swift

Got it -- thanks for the pointer, and sorry for the noise!


Tolerate newer Angular versions

@kylecordes i'm gonna merge this, but for future PRs, please avoid changing the version number, that's handled automatically by the release process :)

Ooops - will avoid in the future!


[BACKLOG-11113] Fix step selection on the exit from DET

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f ui/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f ui/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  ui/src/org/pentaho/di/ui/spoon/trans/TransGraph.java

Still Broken Tests:
org.pentaho.di.ui.trans.steps.tableoutput.TableOutputDialogTest:
:red_circle: java.lang.ClassNotFoundException
java.lang.ClassNotFoundException: org.pentaho.di.ui.trans.steps.tableoutput.TableOutputDialogTest
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:264)

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.ui.spoon.trans.TransGraph

Branch Change:  + .10%
Complexity Change: -.00%:small_red_triangle_down:
Instruction Change:  + .04%
Line Change:  + .08%

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f ui/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f ui/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  ui/src/org/pentaho/di/ui/spoon/trans/TransGraph.java

Still Broken Tests:
org.pentaho.di.ui.trans.steps.tableoutput.TableOutputDialogTest:
:red_circle: java.lang.ClassNotFoundException
java.lang.ClassNotFoundException: org.pentaho.di.ui.trans.steps.tableoutput.TableOutputDialogTest
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:264)

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.ui.spoon.trans.TransGraph

Branch Change:  + .10%
Complexity Change: -.00%:small_red_triangle_down:
Instruction Change:  + .04%
Line Change:  + .08%


split out regridding-prerequisite variables in SHOW VARIABLE/TREE

Reported by andrew wittenberg on 20 Aug 2014 19:05 UTC
Background: I've been making great use of the fantastic new feature SHOW VARIABLE/TREE -- thank you so much for this!  As part of our diagnostic suite, I've now written some .jnl tools to analyze these trees, and then USE any datafiles needed to satisfy any file-variable prerequisites for a list of derived user-variables.  The idea is to have a user request a list of derived products, and Ferret then automatically figures out (from the variable definitions!) what files it needs to retrieve from tape, build descriptors for, etc., in order to provide those products.  Actually I've got this all working -- there's just one little gap, which this request is intended to address.
As part of SHOW VARIABLE/TREE, it'd be great if Ferret could split out any variable prerequisites that arise from regridding.  For example, contrast the following two cases:
 	NOAA/PMEL TMAP
 	FERRET v6.925
 	Linux 2.6.32-431.23.3.el6.x86_64 64-bit - 08/19/14
 	20-Aug-14 14:14

yes? let a = b+c; sho var/tree a
   A = B+C
     B ??                           <== UNKNOWN VARIABLE ******
     C ??                           <== UNKNOWN VARIABLE ******
yes? let a = b[sho var/tree a
   A = B[G=C](g=c];)
     B[  (unknown grid)

In the first case it's easy to parse through the output of SHOW VAR/TREE/OUTFILE, pick out the leftmost "word" on each line, to create the list of all prerequisite variables.  But in the second case, the "C" variable remains hidden inside the square brackets.  I wonder if this case could perhaps be changed to look like this:
yes? let a = b[g=c](G=C]); sho var/tree a
   A = B[    B ??                           <== UNKNOWN VARIABLE ******
     C ??                           <== UNKNOWN VARIABLE ******

In this case C isn't defined, so we can just call it an "unknown variable".
Now if the regridding target were defined, but not as a variable -- instead as a grid or axis -- then perhaps Ferret could display something like this:
yes? let a = temp[gz(depth)=zax@ave](G=C]
); sho var/tree a
   A = TEMP[GZ(DEPTH)=ZAX@AVE]
     TEMP = ...
     DEPTH = ...
     ZAX (axis)

Then I could just use sed to check the "second word" on each line, to filter out the grid & axis prerequisites.
These are just some ideas -- let me know what you think.
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/2195

Modified by steven.c.hankin on 8 Dec 2014 18:22 UTC

Comment by steven.c.hankin on 8 Dec 2014 18:47 UTC
Per Dec. 1, 2 emails with Andrew on this subject, a reasonable solution will be a tab-delimited output that has columns of varname, vartype, and description.  We also want to add a way (TBD) to  indicate the parent-child relationships.  The intended use of the parent-child information will need to guide how best to express it in the output.
I have a concern that we may be only partially satisfied with the results of this ticket.  Here's why.  The name used in a regridding operation may be a varname or a gridname (or in some cases axisname).  The identical regridding request may be expressed using a varname or a gridname.  This leads to several use cases where we will find of ambiguity or unreliability in the output that VTREE can generate. When the target name is NOT found we do not know if we are missing a variable, or a static grid definition. If a gridname IS found as a target, there may be implied dependencies that we have no way to report on.  For example that grid may have been defined through a SET DATA foobar; CAN DATA foobar, which means that the grid is in reality dependent upon dataset foobar.  VTREE has no way to know of this dependency.

Comment by steven.c.hankin on 23 Dec 2014 21:02 UTC
I believe there are two issues underlying this ticket:

when a regridding to an unidentifiable target name occurs, the code regards this as an error.  The associated variable then is not given a "normal" report.  For example this scenario

yes? let a = b+c
yes? let d = a[vtree d
   D = A[G=FOOBAR](g=foobar]
yes?)
     A[  (unknown grid)

where we see that the dependencies on b and c are inhibited by the unknown grid.
2. the target of a regrid is in some cases a variable dependency, too, but it is reported only implicitly as the contents of a "" attached to a variable name
Issue 1 I am hoping we can address pretty easily, simply by not regarding "unknown_grid" as an error  during VTREE.  (The risk is that we will be asking Ferret to plow ahead while carrying an unknown_grid corruption internally.  Need to be on the lookout for crash conditions ... possibly very subtle ones.)
The simplest approach to Issue 2 is just to report regridding dependencies as an opaque string of the form "[ This we can do for sure.  Addressing this in a fully satisfactory way, though, may be quite a lot of work:
i.  The regridding syntax can point to multiple dependencies as in "GX=xtarget,GY=ytarget,G=default"
ii. The target may be either grid or variable name.  If it is a variable, that variable may in turn depend upon other variables.
It isn't clear to me whether diving to the depth needed to fully address this issue will prove to have an attractive cost/benefit.  I'll be exploring ... and eager for comments on all of these thoughts.

Comment by andrew.wittenberg on 23 Dec 2014 23:47 UTC
Would it simplify things if we required the target of a regridding to be a simple variable name, in order for it to be traced?  I.e. [GX=varname,GY=gridname,GZ=axisname] would check whether varname,gridname,axisname were variables.  Since only "varname" is a variable, only it would be traced further.  But "gridname" is a grid and "axisname" is an axis, so they wouldn't be traced.
In other words, per its name, SHOW VARIABLE/TREE would trace only variable trees, not grid/axis trees.
This might be a good "80/20" compromise...

Comment by steven.c.hankin on 24 Dec 2014 00:30 UTC
I have a 1/2 done modification to code that will break out regridding as a separate line of the tree, eliminating the problem that an "unknown grid" error causes parts of the VTREE to be missed.  Lets look the resulting output over and decide where to go from there.
My spidey senses are uncomfortable that we may have 'gotchas' lurking in some of what we're discussing.  A regridding dependence is a different fish than a variable dependence.  The identity and character of the grid are "metadata" (for lack of a better word).  There is no dependency on the data values;  no need to be able to read or compute a variable in order to know its grid.  Does a dependency of this type deserve to be reported in the variable tree?  Or should we be looking at some other mechanism to reveal this information?  I suggest we wait until we have a look at the next iteration and then revisit these questions.
I won't be working much between now and Monday.  Wishing you a great Christmas!

Comment by steven.c.hankin on 31 Dec 2014 22:28 UTC
OK.  I have made changes and checked them into the trunk per the last entry.  Below are some sample outputs the new code to demonstrate the changes.  In brief, the deal is that VTREE now reports regridding dependencies on separate lines annotated as "grid from ...", but it does not at present chase down those dependencies.

The following datasets are set for all of the following
use coads_climatology
use levitus_climatology   ! default to d=2

I inserted "<<<<<<<<<<<" to point to what is significant
! case 1: target grid known,   regridded variable known
New behavior:
canc var/all
let myvar = temp           ! var to be regridded is known
let a = myvar[var/tree=all a
   in default dataset levitus_climatology
   A = MYVAR[G=SST[D=1](g=sst[d=1]]
sho)]
     MYVAR = TEMP
       grid from SST[            <<<<<<<<<<<<<<<
       TEMP

Ferret v6.9 behavior:
canc var/all
let myvar = temp           ! var to be regridded is known
let a = myvar[g=sst[d=1](d=coads_climatology])]
sho var/tree=all a
   in default dataset levitus_climatology
   A = MYVAR[    MYVAR = TEMP
       TEMP

! case 2: target grid unknown,   regridded variable known
New behavior:
canc var/all
let myvar = temp           ! var to be regridded is known
let a = myvar[g=mybad](G=SST[D=1]]
)
sho var/tree=all a         ! note new format to error conditions
   in default dataset levitus_climatology
   A = MYVAR[    MYVAR = TEMP                                                   <<<<<<<<<<<<<<<
       grid from MYBAD ??               <== UNKNOWN GRID ******     <<<<<<<<<<<<<<<
       TEMP                                                         <<<<<<<<<<<<<<<

Ferret v6.9 behavior:
canc var/all
let myvar = temp           ! var to be regridded is known
let a = myvar[g=mybad](G=MYBAD]
)
sho var/tree=all a         ! note new format to error conditions
   in default dataset levitus_climatology
   A = MYVAR[    MYVAR[G=MYBAD](G=MYBAD]
)   (unknown grid)               <<<<<<<<<< incomplete output!!

! case 3: target grid known,   regridded variable embedded into LAT defn
Note: this case illustrates that what a user variable is the target of a regrid, its definition is revealed down a single level in human-readable form (the verbatim text of the definition -- note "D=1" instead of "D=coads_climatology").  The underlying dependencies of that user variable are not revealed in machine readable form.  If we had been using /vtree=FILE on Case 3, the regrid dependency would not show at all, since the target is not a file variable.
Indeed, it is '''possible''' to make VTREE reveal the full dependency tree of the regrid target, though doing so may be a bit of a Pandora's box in the code.
New behavior:
canc var/all
let myvar = temp           ! var to be regridded is known
let target = sst[a = myvar[g=target](d=1]
let)
sho var/tree=all a
   in default dataset levitus_climatology
   A = MYVAR[    MYVAR = TEMP
       grid from TARGET = SST[D=1](G=TARGET]
)            <<<<<<<<<<<<<<<
       TEMP

Ferret v6.9 behavior:
canc var/all
let myvar = temp           ! var to be regridded is known
let target = sst[a = myvar[g=target](d=1]
let)
sho var/tree=all a
   in default dataset levitus_climatology
   A = MYVAR[    MYVAR = TEMP
       TEMP

! case 4: target grid known,   regridded variable unknown
New behavior:
canc var/all               ! myvar not defined
let a = myvar[g=sst[d=1](G=TARGET]
)]
sho var/tree=all a
   in default dataset levitus_climatology
   A = MYVAR[    MYVAR[G=SST[D=1](G=SST[D=1]]
)] ??                       <== UNKNOWN VARIABLE ******
       grid from SST[      <<<<<<<<<<<<<<<

Ferret v6.9 behavior:
canc var/all               ! myvar not defined
let a = myvar[g=sst[d=1](d=coads_climatology])]
sho var/tree=all a
   in default dataset levitus_climatology
   A = MYVAR[    MYVAR[G=SST[D=1](G=SST[D=1]]
)] ??                        <== UNKNOWN VARIABLE ******

! case 5: multiple target grid variables
Note that the VTREE output only reports in detail on the '''first''' regrid target variable.
New behavior:
canc var/all
let myvar = temp           ! var to be regridded is known
let a = myvar[var/tree=all a
   in default dataset levitus_climatology
   A = MYVAR[GX=SST[D=1](gx=sst[d=1],gy=salt]
sho),GY=SALT]
     MYVAR = TEMP
       grid from multi targets including SST[d=coads_climatology]     <<<<<<<<<<<<<<<
       TEMP

Ferret v6.9 behavior:
==> bug in Ferret V6.9.
It crashes on VTREE with multiple regrid targets  :-;

Comment by andrew.wittenberg on 5 Jan 2015 00:36 UTC
Thanks very much Steve.
In your case 1 (and the others too), the "grid from SST[is indented under "MYVAR", even though MYVAR itself simply has the grid of TEMP.  I'd suggest changing the indentation to:
sho var/tree=all a
   in default dataset levitus_climatology
   A = MYVAR[G=SST[D=1](d=coads_climatology]")]
     MYVAR = TEMP
       TEMP
     grid from SST[            <<<<<<<<<<<<<<<

and possibly also the wording to:
sho var/tree=all a
   in default dataset levitus_climatology
   A = MYVAR[G=SST[D=1](d=coads_climatology])]
     MYVAR = TEMP
       TEMP
     regridded to SST[            <<<<<<<<<<<<<<<

For case 5, it'd be helpful if Ferret could report all the (top-level) regrid targets, not just the first one.  (Is this doable, or does the code treat this as some sort of composition of regridding operations, using temporary intermediate variables?)  To that end, the above changes would read clearly as:
sho var/tree=all a
   in default dataset levitus_climatology
   A = MYVAR[GX=SST[D=1](d=coads_climatology]),GY=SALT]
     MYVAR = TEMP
       TEMP
     regridded to SST[    regridded to SALT

What happens in the trivial case when a variable is regridded to itself, e.g. SST[gx=SST](d=coads_climatology] )?  Seems like such a regridding dependency could be skipped entirely.
Now suppose we had:
let a = temp
let b = sst[c = a[gx=b,z=0](d=1]
let) + b[should that report?  Perhaps something like the following?

sho var/tree=all c
in default dataset levitus_climatology
C = A[GX=B,Z=0](gy=a,t=@ave]

How) + B[    A = TEMP
       TEMP
     B = SST[d=1](GY=A,T=@AVE]
)
       SST[    regridded to TEMP
     regridded to SST[d=coads_climatology](d=coads_climatology]
)

Or could the regridding dependencies be clipped in this case, since they're both already variables that appear in the tree?
Note also the curvilinear regridding, mentioned in my original report at the top.  How to handle this?

Comment by steven.c.hankin on 27 Jan 2015 01:48 UTC
I added code to report all (multiple) regrid targets, and suppresses duplicate reports.  Duplicate detection for missing grid errors is limited to case-blind string matches, so some duplicate unknown grid reports may slide through -- e.g. if the current dataset is D=1 this duplicated regridding reference will get reported twice by VTREE
myvar[gx=unknown,gy=unknown[d=1]]

Comment by andrew.wittenberg on 2 Feb 2015 18:10 UTC
A minor remaining issue with the reporting of regridding dependencies, for auxiliary-variable regridding.  Ought not ZAX also be reported below?
 	NOAA/PMEL TMAP
 	FERRET v6.933 (beta)
 	Linux 2.6.32-504.3.3.el6.x86_64 64-bit - 01/27/15
 	 2-Feb-15 13:07

yes? let a = temp[sho var/tree a
   A = TEMP[GZ(DEPTH)=ZAX](gz(depth)=zax];)
     TEMP[GZ(DEPTH)=ZAX] ??			<== UNKNOWN VARIABLE ******
       DEPTH   (unknown auxiliary variable)

Comment by steven.c.hankin on 24 Feb 2015 01:06 UTC
Have fixed this problem;  the target of the regridding is now reported as well as the auxiliary regridding variable.
Note that the solution falls short of 100% when error conditions are encountered. If an error occurs  identifying the auxiliary variable, then that error is reported, but the reporting of the main variable and the regrid target are suppressed.
This situation is to greater and lesser extent when happens throughout all code.  When an error has detected it leaves internal memory structures are in an abnormal state, and it is often unsafe to proceed.  A syntax error in a LET variable will similarly truncate some of the VTREE output.  It just seems more disappointing in this case, because VTREE is intended to report state.  Work-arounds are possible, but the violence that would be necessary in the code doesn't seem justified.


Support symlink

The non-standard FTP is command is SITE SYMLINK target source
Afero now supports it.

Done


Add a defi: OmniSwap - A one-click swap protocol for any token between any chain implemented by the OmniBTC team based on the wormhole/layerzero cross-chain interoperability protocol.

Thank you for making this list awesome! Please make sure that your addition follows the format [project_name](link) - Description. and other contribution requirements such as the Add project_name commit format.

https://github.com/OmniBTC/OmniSwap/tree/support-wormhole/aptos，
Here is the Aptos Move code we are implementing. Based on the wormhole interoperability protocol, realize the one-click swap function of tokens from any EVM chain (such as ETH, BSC, AAVAX, etc.) to the Aptos network.
After implementing Aptos, we immediately started to implement the Sui network.

https://github.com/MystenLabs/awesome-move/pull/22
Related to the previous PR.
OmniBTC contains three functions.
omniswap, omnibridge,
omnilending,
This PR refers to the first of three: omniswap

Closed by merging of #53.


How much RAM is required for ZooKeeper?

Is there a guide for memory usage of ZooKeeper for ClickHouse?
My system uses the ReplicatedMergeTree, creates 3000 parts for one day and stores it about one year.
I set 8GB memory for ZooKeeper. I don't know whether is it enough or not.
I hope your help.

ZK is in-memory database.
So lets check ZK database size
echo mntr | nc localhost 2181|grep zk_approximate_data_size
zk_approximate_data_size	68723698
~68MB
The same size as snapshot size
du -sh /var/lib/zookeeper/version-2/snapshot.4350f30c19
77M	/var/lib/zookeeper/version-2/snapshot.4350f30c19
So in my case ZK needs 77MB+~200MB JVM needs.
I would say 500MB is enough.
Check a MergeTree setting use_minimalistic_part_header_in_zookeeper. If enabled, Replicated tables will store compact part metadata in a single part znode. This can dramatically reduce ZooKeeper snapshot size (especially if the tables have a lot of columns). Note that after enabling this setting you will not be able to downgrade to a version that doesn't support it.

@den-crane
The use_minimalistic_checksums_in_zookeeper is enabled.
:) select * from system.merge_tree_settings

...
use_minimalistic_checksums_in_zookeeper                    │ 1            │       0 │
...

My ZooKeeper's zk_approximate_data_size is<PHONE_NUMBER>.
I will monitor how this value grows.
It's very helpful, thank you very much.


Two periods defined in schedule, only one period is working

I have the following periods defined:
{
   "Periods": [
      {
         "Begintime": "10:00",
         "Description": "period-1",
         "Endtime": "23:59",
         "Name": "period1",
         "Type": "period"
      }
   ]
}

{
   "Periods": [
      {
         "Begintime": "00:00",
         "Description": "period-2",
         "Endtime": "03:00",
         "Name": "period2",
         "Type": "period"
      }
   ]
}

and the schedule:
{
   "Schedules": [
      {
         "UseMaintenanceWindow": false,
         "StopNewInstances": true,
         "UseMetrics": false,
         "Timezone": "Asia/Manila",
         "Hibernate": false,
         "Enforced": false,
         "RetainRunning": false,
         "Description": "Test schedule, delete after use",
         "Periods": [
            "period1",
            "period2"
         ],
         "Name": "testing",
         "Type": "schedule"
      }
   ]
}

but when I simulate the usage, it gives me this:
{
   "Schedule": "testing",
   "Usage": {
      "2020-07-16": {
         "RunningPeriods": {
            "Period1": {
               "Begin": "07/16/20 03:00:00",
               "End": "07/16/20 23:59:00",
               "BillingHours": 21,
               "BillingSeconds": 75540
            }
         },
         "BillingSeconds": 75540,
         "BillingHours": 21
      },
      "2020-07-17": {
         "RunningPeriods": {
            "Period1": {
               "Begin": "07/17/20 03:00:00",
               "End": "07/17/20 23:59:00",
               "BillingHours": 21,
               "BillingSeconds": 75540
            }
         },
         "BillingSeconds": 75540,
         "BillingHours": 21
      },
      "2020-07-18": {
         "RunningPeriods": {
            "Period1": {
               "Begin": "07/18/20 03:00:00",
               "End": "07/18/20 23:59:00",
               "BillingHours": 21,
               "BillingSeconds": 75540
            }
         },
         "BillingSeconds": 75540,
         "BillingHours": 21
      },
      "2020-07-19": {
         "RunningPeriods": {
            "Period1": {
               "Begin": "07/19/20 03:00:00",
               "End": "07/19/20 23:59:00",
               "BillingHours": 21,
               "BillingSeconds": 75540
            }
         },
         "BillingSeconds": 75540,
         "BillingHours": 21
      },
      "2020-07-20": {
         "RunningPeriods": {
            "Period1": {
               "Begin": "07/20/20 03:00:00",
               "End": "07/20/20 23:59:00",
               "BillingHours": 21,
               "BillingSeconds": 75540
            }
         },
         "BillingSeconds": 75540,
         "BillingHours": 21
      }
   }
}

Only Period1 is recognized.

Hi @prandelicious , I apologize for this issue. Can you please confirm whether actual scheduling of instance is working as expected. Also I will add this to our future release backlog as a bug fix for 'scheduler-cli describe-schedule-usage' command.
Thanks,
Praveen

when scheduling these adjacent periods are merged to avoid a stop in between the two periods

We have added this to the backlog and it will be prioritized for a future release.


Fix BovWriter change in namespace

Codecov Report

Merging #8 (9f2caae) into master (ebcc230) will decrease coverage by 0.29%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master       #8      +/-   ##
==========================================
- Coverage   91.77%   91.47%   -0.30%
==========================================
  Files          37       37
  Lines        3428     2534     -894
==========================================
- Hits         3146     2318     -828
+ Misses        282      216      -66

Impacted Files
Coverage Δ

unit_test/tstParticleLevelSet.hpp
0.00% <0.00%> (ø)

src/Picasso_ParticleList.hpp
54.54% <0.00%> (-19.53%)
:arrow_down:

src/Picasso_ParticleCommunication.hpp
12.00% <0.00%> (-13.00%)
:arrow_down:

unit_test/tstLevelSetRedistance.hpp
87.09% <0.00%> (-12.91%)
:arrow_down:

src/Picasso_UniformMesh.hpp
69.38% <0.00%> (-10.62%)
:arrow_down:

unit_test/tstParticleInit.hpp
93.93% <0.00%> (-6.07%)
:arrow_down:

src/Picasso_InputParser.cpp
89.47% <0.00%> (-2.84%)
:arrow_down:

src/Picasso_AdaptiveMesh.hpp
83.60% <0.00%> (-2.11%)
:arrow_down:

src/Picasso_FacetGeometry.hpp
92.12% <0.00%> (-1.78%)
:arrow_down:

src/Picasso_FieldManager.hpp
97.22% <0.00%> (-0.61%)
:arrow_down:

... and 27 more

Continue to review full report at Codecov.

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


[1.10.2] [Bug] Fallen Knight render in wrong place

The video below shows an floating fallen knight, that is actually on the zombie horse, and only when the horse is killed does the fallen knight render in the right place, this does not happen to all mounted fallen knights just some.
ender zoo.zip

FWIW I have seen a similar case involving a player and a vanilla horse. It's very confusing to see a horse wander up and throw items at you while its rider stands on a hill nearby... 🤔

@miiichael now that you mention I remember that, happening to my sister, she was on her horse but I saw standing about block in air by her farm, and her horse was going around by it self, well it looked as if it was, maybe his is a vanilla issue, but @SleepyTrousers may be able to something about their fallen knight, it one have laugh not be able to see some one horse, but another to attached at the speed fallen knights and not been able to see them.

Also: https://www.reddit.com/r/Minecraft/comments/48i7hs/horse_bug_in_minecraft_19/

Would it be possible to fix their AI too? when riding a horse and they would need to go down a corner block, they spin all the day


ui: Fix quick view tooltip title on multiselect list views

Description

Fixed an issue, where the quick view tooltip title would not have been displayed properly on list views with a multiselect row.
This was because the html content of the first td of a row was used to render the title of the quick view tooltip, which would not work if the first columns content was a checkbox.
Now the td with class first will be used for this (this will be the second column if there is a multiselect column, otherwise it will remain the first column).
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Screenshots:
Before

After

How Has This Been Tested?
Deployed to local environment and tested functionality.

@shwstppr @anuragaw can you take a look? :)

Tested fine locally too

Based on PR Description and reading style in CSS LGTM.
Will do a quick test locally and get back if I find any issues.


How to know process tree status when the PR work is slow(=or heavy)

When the PR work is suddenly slow (or to heavy), We need to check process tree.

:octocat: cibot: Thank you for posting issue #416. The person in charge will reply soon.

https://github.com/nnsuite/TAOS-CI/pull/403 supports a process tree via web interface.

Proposal:


Query: GroupBy after Skip/Take produces incorrect results

        [ConditionalFact]
        public virtual void OrderBy_Skip_GroupBy()
        {
            AssertQuery<Order>(
                os => os.OrderBy(o => o.OrderDate).Skip(50).GroupBy(o => o.CustomerID).OrderBy(g => g.Key),
                assertOrder: true);
        }

Produces
  SELECT [o].[OrderID], [o].[CustomerID], [o].[EmployeeID], [o].[OrderDate]
  FROM [Orders] AS [o]
  ORDER BY [o].[CustomerID], [o].[OrderDate]
  OFFSET @__p_0 ROWS

Which is incorrect SQL and gives wrong results.

Assigned to 2.1.0 since this is required for group by.


Map debugging2

Popups should be a reasonable width and Single Location View bug is fixed and should show the proper location all the time.

Merging more recent branch instead


module 'diffusers.models' has no attribute 'autoencoders'

Describe the bug
When running deepspeed.init_inference for stablediffusion models there is an error (only in deepspeed >= 0.13)
if hasattr(diffusers.models.autoencoders.vae, "AutoencoderKL"):
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: module 'diffusers.models' has no attribute 'autoencoders'. Did you mean: 'AutoencoderKL'?

To Reproduce
Steps to reproduce the behavior:
I tried with a large variety of dependency versions, and they all seem affected. Here is one such example:
python = ">=3.10,<3.12"
distro-info = "1.0"
scikit-build = "^0.16.7"
pillow = "^10.2.0"
ninja = "^1.11.1"
diffusers = "^0.15.0"
triton = "^2.2.0"
transformers = "^4.37.2"
pynsq = "^0.9.1"
compel = "^2.0.2"
scipy = "^1.12.0"
torch = "^2.2.0"
xformers = "^0.0.24"
accelerate = "^0.26.1"
deepspeed = "^0.13.1"

Expected behavior
No error.
ds_report output
Please run ds_report to give us details about your setup.
Screenshots
If applicable, add screenshots to help explain your problem.
System info (please complete the following information):

OS: Linux Mint 21.2
GPU count and types: 1 Nvidia GeForce RTX 3070 NVIDIA-SMI 545.23.08              Driver Version: 545.23.08    CUDA Version: 12.3
(if applicable) 0.13.1
(if applicable)
3.11

Docker context
Not using docker.
Additional context
Add any other context about the problem here.

Hello @mikob,
This is due to the diffusers library changing the path to vae in diffusers version >=0.25.0. See this PR here.
What this means is that the latest versions of DeepSpeed support diffusers version >=0.25.0 as seen in the requirements.txt in the PR linked above.
Can you please try updating your diffusers library to the latest and running again?
Thanks,
Lev

Hi @lekurile yes tried your fix_sd_cli branch and it got me closer to working, along with another change it was working but then hit another roadblock in inference: https://github.com/microsoft/DeepSpeed/issues/5091

@mikob,
Glad you've made some progress. Since there's another issue opened now in #5091, shall we close this one?
Thanks,
Lev


Sort out the bindgen feature for rustc 1.40+

Possibly related to the updated borrowchecker (https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html), rustc 1.40 (current nightly) does not compile either fitsio-sys-bindgen or fitsio with the bindgen feature enabled.

This seems to have been a transient error with the version of rustc and bindgen that was in use.


siyuan: 3.0.11 -> 3.0.17

Description of changes
https://github.com/siyuan-note/siyuan/releases
This PR bumps the version of the siyuan package.
I also refactored how electron-builder is called, since it was broken by this update:
Previously I'd call npm run dist-linux which called electron-builder, however that meant that I had to patch the config file to only build the dir target and to use electron from nixpkgs.
Now, I call electron-builder manually, using --dir to override the target.
I also changed at which build step the kernel gets symlinked into the build environment.
Related PR: https://github.com/NixOS/nixpkgs/pull/313638

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Please rebase on master


Offline map download auto-resumption needs attention

It seems that if the network is disconnected or the internet is unavailable during an offline map download, the map download is stuck. The offline map download should resume once the internet connection is back. However, this does not seem to happen

The resumption seems to work well for a few minutes.
The resumption also works if you exit the app and come back since the download uses a foreground service that maintains the download progress notification on the notification bar.
When the internet is disconnected for around 11 minutes and resumed. It takes some minutes before the download progress bar starts showing progress.
From the logs the internet was disconnected at around 6:09 PM and errors were logged by Mapbox at:

6:09 pm
6:11 pm
6:12 pm
6:14 pm
6:18 pm

The wifi was turned on at 6:22 pm and the download did not start until 6:26 pm.
This shows that Mapbox retries resuming the download after 1 min, 2 mins, 4 mins, 8 mins and so on. The Mapbox OfflineManager however uses a broadcast receiver for android.net.conn.CONNECTIVITY_CHANGE which might not be utilised as expected from this observation

Offline map download resumption works OK when inside activities using the mapbox MapView. It seems that this is because the MapView activates the com.mapbox.mapboxsdk.net.ConnectivityReceiver and thus the
The Android MapboxSDK OfflineManager does not directly enable the com.mapbox.mapboxsdk.net.ConnectivityReceiver when offline region download resumes. It is only enabled when an offline region is being created and deactivated immediately after the region creation succeeds or fail. However, the OfflineManager and it's components use the com.mapbox.mapboxsdk.net.ConnectivityReceiver(which is a singleton) if it is activated.
The fix would be to activate the com.mapbox.mapboxsdk.net.ConnectivityReceiver before an OfflineRegion status is activated and deactivated after the OfflineRegion is done downloading, encounters a tile count limit exception or the MapboxOfflineDownloaderService is shutdown. Classes using the MapboxOfflineResourcesDownloader should deactivate the ConnectivityReceiver when they are destroyed to prevent a memory leak

Getting very many notification error messages when wifi is turned off when downloading map.
Samsung J5 physical phone.


build: integrate whiskers

Unsure if the changes seen in various color values are a bug in the original, or intentional deviation from the rest of the theme. This should be investigated before merge.

The output is not correct, but thanks for the help, I'll fix it here from now on. The original theme also wasn't totally correct so there's that.


Provide an API version constant for the types

The readme mentions:

The type declarations in @stripe/stripe-js for these objects in will always track the latest version of the Stripe API.

It'd be helpful if there was an exported constant providing that version, to ensure we don't hardcode the current version, having the types move to a new version, and unknowingly having a mismatch

Thanks for the question. This is an interesting idea. How would the use of a version export work within your codebase? I'm not sure I understand how you would like to use this information. If you hardcode an old version of the Stripe API and try to use a new version of the TypeScript definitions with incompatible types, then tsc will report an error, right?

Ah the issue is that our version of stripe-js is continually updated by Dependabot, but we have no way to know whether the API version has been updated at the same time. We'd like to ensure that the API version and the types are always in lockstep.
It seems that is most easily achieved by getting the API version from this library, alongside the types.
We then pass the API version to our backend when generating ephemeral keys, and we'd provide it into options.apiVersion to ensure the actual data matches the types too.
Also for general context, we use stripe-js in an Expo app, and the same single piece of code also uses stripe-react-native and exposes a single consistent interface (basically stripe.native.tsx & stripe.web.tsx). Not super relevant to this ask though

Not stale

What 😂
@fruchtose-stripe Could you please reopen? The bot ignored the bump

Sorry about that, I forgot to remove the stale label.

Does it work for you to import a constant type of the latest version? If so, you can do this:
import type {Stripe} from 'stripe';

type LatestApiVersion = Stripe.LatestApiVersion;

That sounds helpful, but the actual types are separate from the ones in this package. The key thing we need is the API version that was used to generate the types in this package

Not stale :\

@billinghamj sorry for getting back to you late. Our team is actively trying to find the best solution that works for you and also for our library.
We're trying to better understand what your use case is. I'm going to try to explain what I understand but feel free to correct me if I am wrong.
Context
On the backend you pass in an apiVersion to ensure that the data being returned from the library is in an expected shape. You also do the same on the frontend using options.apiVersion.
Problem
The problem that you are facing is this part:

The type declarations in @stripe/stripe-js for these objects in will always track the latest version of the Stripe API.

If you are passing in an apiVersion with stripe-js and Dependabot upgrades stripe.js automatically, stripe.js might use a new version of the API (with new types) but you will still be using the older version of the API (specified via options.apiVersion)
Please let me know if I've understood your problem correctly. I've provided some solutions below.
Solutions

Expose a constant from our library that expresses most recent version of the API that the types are defined on (your suggestion from this issue)
Always use the latest version of the API when using stripe-js. Is there a reason why you can't always use the most recent version of the stripe-api? (by not passing in a version via options)
Rely on SemVer. We try our best to maintain semantic versioning when publishing updates to this library. New versions of stripe.js that have a minor or patch version are not breaking changes, and should not break the types in anyway (only fix them or add new fields). If you use a specific version, you should be okay to use all future versions of stripe-js until a breaking change is released.

Let me know if any of these work for your use-case, if not we'd be happy to take another look at it :)

Not stale

Not stale


Add Nio to showcase

👋 Hello there! Welcome. Please follow the steps below to tell us about your contribution.

Please complete a Checklist
Fill in all sections of the template
Click "Create pull request"

Checklist
<-- Please fill the boxes with [x] before submitting a pull request -->

[x] I have read the How to Contribute.
[x] I have read the Showcase Requirements
[x] I have run yarn build after adding my changes without getting any errors.
[x] I have not committed any changes to yarn.lock (or have removed these changes).

Showcase addition
<-- Provide information for every bullet in the list below. The tags you select must match the tags in your changes to the showcase.js  -->

Title: Nio
Description: Track all assets in wallets and locked in Cardano DeFi smart contracts. Effortlessly monitor your assets and whale wallets
Website:   nioapp.io
Source:
Tags:

analytics
defi

@openVietAnh if you want to create a valid submission you'll need to choose at least one of the valid tags in the showcases.js file (there is no defi tag).

@openVietAnh if you want to create a valid submission you'll need to choose at least one of the valid tags in the showcases.js file (there is no defi tag).

Thanks a lot for the feedback, I have updated the tag to 'explorer'

@openVietAnh it doesn't fit with the current items having the explorer tag, which are all block explorers (as you can see when you hit the Block Explorer button in the Showcase): https://developers.cardano.org/showcase/?tags=explorer
@katomm I'm at a loss to for a definitive choice about this.  This tool resembles the wallet explorer on pool.pm which is listed in that category.  Would it be fair to include it with the other explorers, or is there a better choice?  (there seem only half-way matches: having some common ground with wallet, but without executing transactions, and analytics for specific but not general data structures)


[electron] fixed fat icons

see https://github.com/Microsoft/vscode/blob/master/src/main.js#L15

Thanks


Macro for "path to base of docs"?

AFAICT, there doesn't appear to be a macro that provides a relative path to the base directory of the documentation output.
Ie: In file someproject/docs_output/my_package/my_module/MyClass.html something like $(DDOX_BASE) would expand to ../../.
Ddox does this internally for the auto-generated navigation links, but it would be helpful to have this exposed to documentation authors.

I'm a little worried about making this a DDOX feature when Ddoc doesn't have it, as the goal is to have a fully compatible alternative. But any serious DDOX-only feature would potentially lead people to produce Ddoc-incompatible documentation comments. Do you have an example use case? Maybe there is an alternative solution? If not, we can of course add such a macro.

Do you have an example use case?

On dlang.org, we like to make URLs relative so that they work in the HTML files that are part of the dmd releases. We use a $(ROOT_DIR) macro that's set to .. on the Ddoc pages, but on the DDOX pages we need to set it to / (i.e. not relative) because of the nested directories. We could add the correct amount of ../s directly on the link instances, but that would break the Ddoc pages. A $(DDOX_BASE) macro would allow us to have both working at the same time.

It seems like the $(ROOT_DIR) macro is only used within the .dd files of dlang.org, but not within the embedded documentation on which DDOX is run. Is there any concrete example where this would be useful?

Regarding use-case:
Without ever requiring any configuration, the generated documentation could be copied as-is to any base path location, on any server, or viewed by any user locally, with or without ddox even installed let alone anyone ever needing to run ddox serve-html first.
Other options (all inferior):

Hardcoding /: Terrible option: Documentation can never be hosted within a subdirectory or viewed locally by end-users with file:///, and a server of some sort is always required. The inability to work from a subdirectory places restriction and burden on the server maintainer. It also gets in the way of easily offering hosted docs for prior releases (ex: example.com/docs/..., example.com/docs/v0.9/..., example.com/docs/v1.2/... ). On top of all that, this approach doesn't even offer any real benefit (aside from "'breaking' DDOC", which I address below).

Setting up a configurable relative-path $(ROOT_DIR): Broken by DDOX's nested directory structure. Even if that was changed (which I don't advocate since I like the nested structure), it would still have the same downfall as the next option:

Setting up a configurable absolute-path $(ROOT_DIR): Generated docs are neither relocatable, nor zero-configuration: Every time the docs are to be placed in a different location, or viewed locally by an end-user,  $(ROOT_DIR) would need to be re-configured and the docs must be rebuilt. All that for no real benefit (aside from "'breaking' DDOC", which I address below).

"Breaking" DDOC:
In short: So what?

DDOC is known to be insufficient, that's why things like DDOX exist in the first place. Otherwise, DDOX could have been nothing more than a set of macros and CSS files.

Making documentation comments work with multiple doc generating tools isn't a feature, it's an unjustified burden. It forces developers to be limited by a common subset of both the tool they chose AND the tools they chose against. And for what? Documentation doesn't need to be generatable with multiple doc generators. There's no benefit: As long as the one they're written for is available to contributors, that's all that's needed. DDOX being backwards-compatible with DDOC is nice, so users can upgrade to DDOX if they've been using the built-in, but after that, helping them do their work is more important than continually holding them back by a tool they've already ditched.

(Probably the most compelling reason) That ship's already sailed anyway: Linking across different parts of the documentation, in a way that works for both DDOC and DDOX is already impossible, at least in the general case. First, DDOX's automatic no-macro links don't happen in DDOC. And secondly, manual linking is broken by DDOC and DDOX using different directory structure. The only ways to fix this would involve making DDOX less of an improvement over DDOC, thus defeating the point of even having DDOX.

It seems like the $(ROOT_DIR) macro is only used within the .dd files of dlang.org, but not within the embedded documentation on which DDOX is run.

It's used through other macros. Examples:

DDLINK is defined in terms of ROOT_DIR. It's used in std.algorithm.iteration, for example.
The new REF macro is defined in terms of PHOBOS_PATH which builds on ROOT_DIR. REF is supposed to replace other macros like XREF.
Speaking of XREF, we would have liked to make it relative, but didn't because of DDOX. XREF is ubiquitous.

@aG0aep6G: Okay, thanks, I missed those. So REF and XREF can be implemented much simpler for DDOX, because it will do the cross references automatically. Just have it output the qualified name of the symbol in backticks. But DDLINK is indeed an issue. I was thinking about a solution that is local to the overridden ddox.layout.dt template, but that doesn't really work. I'll add $(DDOX_ROOT_DIR).


Built-in support for German words decompounder

name
about
title
labels
assignees

💭 Proposal
Better support for German words decompounder
[PROPOSAL]
proposal

What kind of business use case are you trying to solve? What are your requirements?
We would like to have an out-of-the-box solution for German words decompounder, where OpenSearch have some analyzer that we can simply use it, similar to the level of support that Japanese as a language has (with kuromoji analysis plugin).
What is the problem? What is preventing you from meeting the requirements?
Many German words are actually a combination of shorter words, for example Fallschirmspringerschule (Skydiving school) = Fallschirm (parachute) + spring (jump) + schule (school). To get good quality search results, we need a decompounder to "break" words into components, to search by each individual word.
Currently, there is some support for Germanic language decompounder in Lucene and OpenSearch (for example, documentation taken from Elasticsearch https://www.elastic.co/guide/en/elasticsearch/reference/7.9/analysis-hyp-decomp-tokenfilter.html and https://www.elastic.co/guide/en/elasticsearch/reference/7.9/analysis-dict-decomp-tokenfilter.html), however, we still need to find a good dictionary file to effectively use the token filters.
There are some effort to build such dictionary, for example, at https://github.com/uschindler/german-decompounder
Another effort to solve the same problem that we can find, is to write a prebuilt Trie into a plugin, for example, at https://github.com/jprante/elasticsearch-analysis-decompound
The problem attracts good level of interest, when searching on search engine. For example, in this SO post https://stackoverflow.com/questions/59595689/elasticsearch-handling-german-compound-words, both of the approaches above are mentioned.
I think a better language support for German will be beneficial for OpenSearch users. We will not need to reinvent the wheel or reconstruct/look for a dictionary (with questionable accuracy).
What are you proposing? What do you suggest we do to solve the problem or improve the existing situation?
I do not have any specific solution in mind.
What are your assumptions or prerequisites?
I assume that there is demand for such German decompounder token filter and users are not satisfied with existing solution (or not being able to install plugin onto OpenSearch)
What are remaining open questions?

search/index latency implication of different approaches
"quality" of the solution, i.e. will it work for most of the German words?

Hi team, is there any guidance/suggestion for this issue? Should I start working on some PR for this?

Hi team, is there any guidance/suggestion for this issue? Should I start working on some PR for this?

No need to ask for permission! Comment here if you're working on it so we don't duplicate work.

Hi @quangmaubach, are you still working on this?


Ecto.Changeset.merge do not merge types and do not raises when types are different

Elixir version
1.16.1
Database and Version
PostgreSQL: postgres:13-alpine
Ecto Versions
3.11.2
Database Adapter and Versions (postgrex, myxql, etc)
postgrex 0.17.4
Current behavior
During the Ecto.Changeset.merge/2 operation the type field of the changeset is not merged. Which result in a strange result when applying changes using schemaless changesets
data = %{}
changeset1 = Ecto.Changeset.cast({data, %{field1: :string}}, %{field1: "field 1"}, [:field1])
changeset2 = Ecto.Changeset.cast({data, %{field2: :string}}, %{field2: "field 2"}, [:field2])
Ecto.Changeset.merge(changeset1, changeset2) |> Map.get(:types)
# %{field2: :string}

Ecto.Changeset.merge(changeset1, changeset2) |> Ecto.Changeset.apply_changes()
# %{field2: "field 2"}

Is it the expected behaviour?
I see in the code the merging of types is performed via Kernel.||/2 and not a Map.merge/2 operation
  defp cast_merge(cs1, cs2) do
    ...
    new_types = cs1.types || cs2.types
    ...
  end

Expected behavior
I can see 2 types of behaviour that could be acceptable:

Merge the types for easiness to use merge with schema less changeset
Raise if the types are not equals (like when the data from the changesets are different)

I think merging the types is sensible, a pull request is welcome!


Minor readme adjustment

Wasn't runnable, fixed it

Thanks! Now that it’s registered, I should probably set it to a simple ]add. I’ll create the suggestion


Fix typo in jtx1rate.c, #2

Presume the little 'o' at beginning of line is a typo.  Compiles when removed.

Your fix has just been merged. Thank you for interest in the project and your contributions.

This typo was introduced in 4b0ad06b89df40c891b54c8280c0ec215482bf35.

Thanks :)