[Incremental] Catch conversion failure in Fingerprint

When creating a Fingerprint from a string, if the string is not valid hex, information is lost, creating the potential for miscompilation. However, I believe this situation only happens in some tests, for example,  Driver/Dependencies/mutual-interface-hash-fine.swift. This change checks for that failure, but it cannot be merged as-is because some tests will (rightly) fail. Before the advent of Fingerprint the swift-dependency-tool would write out the whole string, and thus the tests worked correctly.
To see the failure, try converting the .swift files from before this PR in Driver/Dependencies/Inputs/mutual-interface-hash-fine from yaml to binary and back.

We should just convert the tests - it's not hard to teach Slava's tool to do this.
Fingerprints created by the frontend will otherwise round-trip losslessly, so you are correct that only the tests are wonky here.

I see two issues: one meriting a fix and the other, an understandable oversight meriting discussion:
The definite problem is that there was no check in the fromString: input. That code could not deal with a non-hex number, but it did not check. You did put in an assertion which is great, but it turned out that that assertion was in the wrong place to check the input. I'll be refining the PR to fix that.
What merits discussion is that Fingerprint chooses limit the quantity of information to 128 bits, instead of an unlimited string. I understand how the present state of the compiler would inspire that limitation. But that limitation is inconsistent with the present state of the tests. I expect that a fixed, hard limit on the size of a fingerprint is good for compiler performance, but might there be a way to get the best of both worlds?

We should just convert the tests - it's not hard to teach Slava's tool to do this.
Fingerprints created by the frontend will otherwise round-trip losslessly, so you are correct that only the tests are wonky here.

I see two issues: one meriting a fix and the other, an understandable oversight meriting discussion:
The definite problem is that there was no check in the fromString: input. That code could not deal with a non-hex number, but it did not check. You did put in an assertion which is great, but it turned out that that assertion was in the wrong place to check the input. I'll be refining the PR to fix that.
What merits discussion is that Fingerprint chooses limit the quantity of information to 128 bits, instead of an unlimited string. I understand how the present state of the compiler would inspire that limitation. But that limitation is inconsistent with the present state of the tests. I expect that a fixed, hard limit on the size of a fingerprint is good for compiler performance, but might there be a way to get the best of both worlds?

What merits discussion is that Fingerprint chooses limit the quantity of information to 128 bits

Increasing the number of bits in a hash does not correlate at all with an increase in desirable properties.  For example, SHA-1 is a 256-bit hash, but it is deeply insecure and weaker than (the ironically named for this discussion) SHA-256, and less collision resistant than SipHash.

What merits discussion is that Fingerprint chooses limit the quantity of information to 128 bits

Increasing the number of bits in a hash does not correlate at all with an increase in desirable properties.  For example, SHA-1 is a 256-bit hash, but it is deeply insecure and weaker than (the ironically named for this discussion) SHA-256, and less collision resistant than SipHash.

What merits discussion is that Fingerprint chooses limit the quantity of information to 128 bits

Increasing the number of bits in a hash does not correlate at all with an increase in desirable properties. For example, SHA-1 is a 256-bit hash, but it is deeply insecure and weaker than (the ironically named for this discussion) SHA-256, and less collision resistant than SipHash.

While there exist larger fingerprints with worse performance--a fair point!--that does not rule out the potential need for larger fingerprints in order to get better performance. From an information theoretic standpoint, a fingerprint with more bits can potentially fulfill its purpose better. By placing a fixed, hard limit on the size of a fingerprint, the existing code will make it harder to expand the fingerprint in the future, should we deem it necessary to do so.
That necessity cannot be ruled out because we don't have much data for our code-base regarding the efficacy of the fingerprints, that is, how often a fingerprint fails to catch a mutation in the code. I have heard that other projects have some experience here, but have not investigated. Thus, it seems conceivable that we might enlarge fingerprints someday. The Fingerprint abstraction will help do that if/when we do.
I am OK with leaving length fixed for now; however, we'll have to fix the tests in a manner which will make them slightly harder to debug in the future.

What merits discussion is that Fingerprint chooses limit the quantity of information to 128 bits

Increasing the number of bits in a hash does not correlate at all with an increase in desirable properties. For example, SHA-1 is a 256-bit hash, but it is deeply insecure and weaker than (the ironically named for this discussion) SHA-256, and less collision resistant than SipHash.

While there exist larger fingerprints with worse performance--a fair point!--that does not rule out the potential need for larger fingerprints in order to get better performance. From an information theoretic standpoint, a fingerprint with more bits can potentially fulfill its purpose better. By placing a fixed, hard limit on the size of a fingerprint, the existing code will make it harder to expand the fingerprint in the future, should we deem it necessary to do so.
That necessity cannot be ruled out because we don't have much data for our code-base regarding the efficacy of the fingerprints, that is, how often a fingerprint fails to catch a mutation in the code. I have heard that other projects have some experience here, but have not investigated. Thus, it seems conceivable that we might enlarge fingerprints someday. The Fingerprint abstraction will help do that if/when we do.
I am OK with leaving length fixed for now; however, we'll have to fix the tests in a manner which will make them slightly harder to debug in the future.

By placing a fixed, hard limit on the size of a fingerprint, the existing code will make it harder to expand the fingerprint in the future, should we deem it necessary to do so.

I don't understand this objection. We have the ability to change the version and format of swiftdeps at any time. If a larger bitwidth is needed, we have the headroom to make such a change.

By placing a fixed, hard limit on the size of a fingerprint, the existing code will make it harder to expand the fingerprint in the future, should we deem it necessary to do so.

I don't understand this objection. We have the ability to change the version and format of swiftdeps at any time. If a larger bitwidth is needed, we have the headroom to make such a change.

By placing a fixed, hard limit on the size of a fingerprint, the existing code will make it harder to expand the fingerprint in the future, should we deem it necessary to do so.

I don't understand this objection. We have the ability to change the version and format of swiftdeps at any time. If e.g. a larger bitwidth is needed, we have the headroom to make such a change.

Yes we do, although it would be harder than when the fingerprint was a string.
I objected because I didn't understand the relevance of:

Increasing the number of bits in a hash does not correlate at all with an increase in desirable properties. For example, SHA-1 is a 256-bit hash, but it is deeply insecure and weaker than (the ironically named for this discussion) SHA-256, and less collision resistant than SipHash.

The fact that a poorer yet larger hash exists struck me as irrelevant to the merits of modifying the code to accommodate varying-length fingerprints today.
I also failed to understand the "does not correlate at all" statement, given my understanding of Shannon information theory.
Anyway, I'll look into fixing up the tests and adding those fixes to this PR.

By placing a fixed, hard limit on the size of a fingerprint, the existing code will make it harder to expand the fingerprint in the future, should we deem it necessary to do so.

I don't understand this objection. We have the ability to change the version and format of swiftdeps at any time. If e.g. a larger bitwidth is needed, we have the headroom to make such a change.

Yes we do, although it would be harder than when the fingerprint was a string.
I objected because I didn't understand the relevance of:

Increasing the number of bits in a hash does not correlate at all with an increase in desirable properties. For example, SHA-1 is a 256-bit hash, but it is deeply insecure and weaker than (the ironically named for this discussion) SHA-256, and less collision resistant than SipHash.

The fact that a poorer yet larger hash exists struck me as irrelevant to the merits of modifying the code to accommodate varying-length fingerprints today.
I also failed to understand the "does not correlate at all" statement, given my understanding of Shannon information theory.
Anyway, I'll look into fixing up the tests and adding those fixes to this PR.

Information theory is simply one aspect. You're considering the data produced by the hash, instead of the hash algorithm itself and its result. If you have such a variable-length algorithm in mind, I invite you to propose it and implement it and we'll give it a shootout with the compiler performance suite.

Information theory is simply one aspect. You're considering the data produced by the hash, instead of the hash algorithm itself and its result. If you have such a variable-length algorithm in mind, I invite you to propose it and implement it and we'll give it a shootout with the compiler performance suite.

Information theory is simply one aspect. You're considering the data format of the hash, instead of the hash algorithm itself and its result. If you have such a variable-length algorithm in mind, I invite you to propose it and implement it and we'll give it a shootout with the compiler performance suite.
Note that a variable-length format is not, in itself, a good thing. One could imagine a terrible hash function on variable-length outputs where the combiner simply appends a 0 or 1 to a bitstring for each quantum of data. You'd collide quite frequently, but you'd have all the entropy you could cram into the thing at your disposal.

Absolutely right! But doesn't information theory imply that although no fingerprint will be perfect, a longer fingerprint has the potential to be better than a shorter one, as long as the fingerprint is still shorter than the code its hashing.
Given that you've chosen an excellent hash, if someday it seems to be not quite good enough, might it not be the case that we need to enlarge it?

Information theory is simply one aspect. You're considering the data format of the hash, instead of the hash algorithm itself and its result. If you have such a variable-length algorithm in mind, I invite you to propose it and implement it and we'll give it a shootout with the compiler performance suite.
Note that a variable-length format is not, in itself, a good thing. One could imagine a terrible hash function on variable-length outputs where the combiner simply appends a 0 or 1 to a bitstring for each quantum of data. You'd collide quite frequently, but you'd have all the entropy you could cram into the thing at your disposal.

Absolutely right! But doesn't information theory imply that although no fingerprint will be perfect, a longer fingerprint has the potential to be better than a shorter one, as long as the fingerprint is still shorter than the code its hashing.
Given that you've chosen an excellent hash, if someday it seems to be not quite good enough, might it not be the case that we need to enlarge it?

@swift-ci please smoke test

@swift-ci please smoke test

Fingerprint::fromString now always checks for information loss, returning an optional. I believe this check is worthwhile because:

The data being checked are read in from a file, either in the driver or when testing. It's good to check for file corruption, and
Given all the other work in reading the file, I don't think we'll see a noticeable performance regression in the driver.

Fingerprint::fromString now always checks for information loss, returning an optional. I believe this check is worthwhile because:

The data being checked are read in from a file, either in the driver or when testing. It's good to check for file corruption, and
Given all the other work in reading the file, I don't think we'll see a noticeable performance regression in the driver.

@swift-ci test

@swift-ci test

Thank you, @CodaFi

Thank you, @CodaFi

Build failed
Swift Test Linux Platform
Git Sha - 67028b9f4f76e85e4a29a039398b52746c1c9cda

Build failed
Swift Test Linux Platform
Git Sha - 67028b9f4f76e85e4a29a039398b52746c1c9cda

Build failed
Swift Test OS X Platform
Git Sha - 67028b9f4f76e85e4a29a039398b52746c1c9cda

Build failed
Swift Test OS X Platform
Git Sha - 67028b9f4f76e85e4a29a039398b52746c1c9cda

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test


Owner user is a bit over-capable

Schemaverse requires (there are several references inside pl/pgsql code) that the "owner" user be called 'schemaverse', and that it be a superuser.
I'd somewhat like for neither to be required.

round_control() runs COPY to dump out data to a file, and that mandates SUPERUSER.  This is likely not the right way to do this; a psql script could request \COPY with more pedestrian permissions.    It may suffice to just do USER trigger disabling.

I'm not against these changes at all. It was done for two reasons originally 1) laziness, and 2) larger attack vector for the Defcon tournaments.


Pulsar Sink Connector Consume Rate

Is your enhancement request related to a problem? Please describe.
I have some JDBC sinks that I recently reconfigured to have a longer timeout and batch size. This helped since the topic had a steady publish rate of about 100 msg/s, so these settings prevent spamming inserts to the database.
In some scenarios, I'd want to start these sinks on data from a day or two ago, and let it catch up to live data. Even with a batch size of 100,000, and timeout of 1 minute, the sink consumes messages very fast from the topic. It would receive 100,000 messages in much less than 1 minute, and it would still spam inserts to the database. I don't want to increase the batch size too large, because I suspect there will still be issues with waiting on the database to finish inserting, and more large batches being ready to go so soon.
Describe the solution you'd like
An option for sink connectors, similar to --rate of the pulsar-client CLI. This would let the user specify a throughput rate for the sink consumer. This can be used to set the consumption rate only slightly higher than the expected live data rate, so the sink can still catch up but not spam inserts as often.
I suppose this works best when there is a steady, expected level of throughput on the topic. I'm not sure if this behaviour can be made more dynamic in any way.

@Alxander64 Pulsar supports limit the publish message rate and consume message rate at the broker side, you can use pulsar-admin set-dispatch-rate to limit the consumption rate. Is this work for this issue?

@Alxander64 Pulsar supports limit the publish message rate and consume message rate at the broker side, you can use pulsar-admin set-dispatch-rate to limit the consumption rate. Is this work for this issue?

I learned about that just recently, but I believe it doesn't quite fit what I was aiming for. I was hoping there could be some similar setting at the topic-level, or even for individual subscriptions, because I believe that setting is applied to an entire namespace.

I learned about that just recently, but I believe it doesn't quite fit what I was aiming for. I was hoping there could be some similar setting at the topic-level, or even for individual subscriptions, because I believe that setting is applied to an entire namespace.

@Alxander64 The topic level policy is supported a 2.7.0 but not able for individual subscriptions.

@Alxander64 The topic level policy is supported a 2.7.0 but not able for individual subscriptions.

Interesting, is there any plan to support this for individual subscriptions, or is there something holding it back?

I can work on it.


bicycleinit.sh assumes that it is run from within git repo with correct remote

$ ./bicycleinit.sh
fatal: not a git repository (or any of the parent directories): .git
Failed to fetch updates. Check your network or Git configuration.

This has been clarified in the README file.


Migrate possible JS from EJS to server-side

2ce1cc30b0a3fe348ae80e2b05b06278015deab0
7649f0a940d020d679d0b1dfcf7a4b3357d8b125
Migrated several JS code blocks from EJS files to server side


Add "JXL" text to the file header for future easy identification of extension less files and/or data recovery

Is your feature request related to a problem? Please describe.
Nope
Describe the solution you'd like
Add "JXL" text to the file header for future identification of extension less files and/or data recovery
Describe alternatives you've considered
NA
Additional context

It's a bit late in the game to change the bitstream specification :)
If you use the container-based jxl format, you will see ascii "JXL" and "jxl" show up a few times in the initial bytes.
For the 'naked codestream' we kept things as minimal as possible, and even 3 bytes for "JXL" were considered too much. Instead we use the 2 bytes 0xFF0A which uses the FFxx marker syntax as it is used in several JPEG standards (and the combination 0xFF0A is uniquely reserved for "start of jxl codestream").

I hope @jonsneyers helps. Closing this as won't fix for the time being.


Remove now-deprecated "rename-dependency" cargo feature

This feature was stablized in cargo 1.31.

Thanks!


Update management plane event grid

Testing out Management Plane Restructuring.

@Azure/azure-sdk-eng


Failed to read environment variables

I run cap production deploy and got this error:
$HOME/.rbenv/bin/rbenv exec bundle exec rails webpacker:clobber
(Backtrace restricted to imported tasks)
cap aborted!
Errno::ENOENT: No such file or directory - ( export RBENV_ROOT="$HOME/.rbenv" RBENV_VERSION="2.5.5" RAILS_ENV="production" RBENV_ROOT="$HOME/.rbenv" RBENV_VERSION="2.5.5" RAILS_ENV="production" ; $HOME/.rbenv/bin/rbenv exec bundle exec rails webpacker:clobber )

Tasks: TOP => webpacker:precompile
(See full trace by running task with --trace)
The deploy has failed with an error: No such file or directory - ( export RBENV_ROOT="$HOME/.rbenv" RBENV_VERSION="2.5.5" RAILS_ENV="production" RBENV_ROOT="$HOME/.rbenv" RBENV_VERSION="2.5.5" RAILS_ENV="production" ; $HOME/.rbenv/bin/rbenv exec bundle exec rails webpacker:clobber )

This is my deploy.rb file:
lock "~> 3.11.0"

set :application, "myapp"
set :repo_url, "git@github.com:githubusername/myapp.git"

# Deploy to the user's home directory
set :deploy_to, "/home/deploy/#{fetch :application}"

append :linked_dirs, 'log', 'tmp/pids', 'tmp/cache', 'tmp/sockets', 'vendor/bundle', '.bundle', 'public/system', 'public/uploads'

# Only keep the last 5 releases to save disk space
set :keep_releases, 5

set :default_env, {
	RBENV_ROOT: "$HOME/.rbenv",
	RBENV_VERSION: "2.5.5" ,
	RAILS_ENV: "production"
}

before "deploy:assets:precompile", "deploy:yarn_install"

namespace :deploy do
  desc 'Run rake yarn:install'
  task :yarn_install do
    on roles(:web) do
      within release_path do
        execute("cd #{release_path} && yarn install")
      end
    end
  end
end

namespace :env do
  	desc 'Print enviroment variables'
  	task :env do
	  on roles(:all) do
	    execute "env"
	  end
	end
end

after 'deploy:updated', 'webpacker:precompile'

I also have a file in server /home/deploy/myapp/.rbenv and /home/deploy/myapp/.rbenv-vars that contain:
RAILS_MASTER_KEY=ohai
SECRET_KEY_BASE=1234567890

STRIPE_PUBLIC_KEY=x
STRIPE_PRIVATE_KEY=y

RBENV_ROOT=.rbenv
RBENV_VERSION=2.5.5
RAILS_ENV=production

What is the solution?

Sorry, we do not provide support with deployments with Capistrano here. The error is likely in your setup, but I don't see where.
FWIW, where you have RBENV_ROOT=.rbenv, the path should be an absolute one, not relative. (Although that alone might not fix your issue.)


Speaker tab is buggy

As of now, there isn't enough information about the speaker in speaker detail activity.
Also the logos are all jumbled up.
I will add screenshots in a bit.

@mariobehling this looks good?

Good progress. I need to try it out to see. Generally, could you limit the specific app color, here red, to some areas only and keep areas with a lot of text with a white background and black ink, please? This will make it easier to change colors in future as well, as we do not have to test too much if things stay readable if we change colors.

@mariobehling That red color can be easily changed with a customized color needed by the user.
This was implemented in #511 , but we need to change the front-end to use this feature.

As mentioned for areas with lots of text, please implement white background and dark/black ink, e.g. here:

Maybe keep "Speaker Name" in red and below white. It all depends.
But, we need to make things easily readable, please.

@mariobehling
Ok, sure.

@the-dagger @mariobehling We can use Pallete to change the color according to the the vibrant and the muted colors. This will make it readable for all the colors of images possible. http://willowtreeapps.com/blog/palette-the-new-api-for-android/

@manan tried that few minutes ago, but the action bar is still primary colored and hence this want going with the flow.

@the-dagger You can change that too for this activity 😉

Ah, ok.
I'll do it then. 👍
Thanks.

👍

@mananwason @mariobehling THis looks good?
The colors will be automatically fetched from speaker's image.

Looks good @the-dagger but please change the text color as well.

Please keep the name and picture with the app background color and below that white background and black ink.

Too many different colors start to be confusing. People might think, they belong to the colors of tracks and we do not know how well this works with all different kinds of colors. I do not want to explain to people what means what. A simple app that works is sufficient.


udp: support udp proxy to use original_dst_cluster

Title: support udp proxy to use original_dst_cluster
Description:
Looking to forward UDP traffic that has been redirected via iptables to use the original_dst_cluster, identical to how TCP is supported via the original_dst filter
Attempted the following config but looks like UDP only supports a single listener filter, so seems like we need to extend the udp_proxy listener similarly what was done with use_original_src_ip [pr]
error adding listener '<IP_ADDRESS>:10005': Only 1 UDP listener filter per listener supported
admin:
  access_log_path: admin_access.log
  address:
    socket_address:
      address: <IP_ADDRESS>
      protocol: TCP
      port_value: 9901

static_resources:
  listeners:
    - name: original_dst_cluster_listener
      address:
        socket_address:
          protocol: UDP
          address: <IP_ADDRESS>
          port_value: 10005
      listener_filters:
      - name: envoy.filters.listener.original_dst
        typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.listener.original_dst.v3.OriginalDst"
      - name: envoy.filters.udp_listener.udp_proxy
        typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.udp.udp_proxy.v3.UdpProxyConfig"
            stat_prefix: udp_egress
            cluster: original_destination_cluster
  clusters:
  - name: original_dst_cluster
    connect_timeout: 5s
    lb_policy: CLUSTER_PROVIDED
    type: ORIGINAL_DST
    dns_lookup_family: V4_ONLY

It looks like support for multiple UDP filters was added here: https://github.com/envoyproxy/envoy/pull/18573
What version are you using?

@skiptomyliu Hi, did you get the udp proxy working with original_dst filter?
I noticed that @zhxie has added multiple udp filter support.  but my run on envoy v1.32.0 generated the following error.
[2024-11-08 12:26:21.560][63623][critical][main] [source/server/server.cc:412] error initializing config '  configs/test3.yaml': Didn't find a registered implementation for 'envoy.filters.listener.original_dst' with type URL: 'envoy.extensions.filters.listener.original_dst.v3.OriginalDst'
[2024-11-08 12:26:21.560][63623][info][main] [source/server/server.cc:1050] exiting
Didn't find a registered implementation for 'envoy.filters.listener.original_dst' with type URL: 'envoy.extensions.filters.listener.original_dst.v3.OriginalDst'
jianyong@E-5CG4171GZW:~/gitlab/envoy$


Feature Request - Swarm-API-Backend - Authorization: Bearer

Hello mcmonkey4eva!
I have deployed another Swarm-API-Backend in OVH's Public Cloud, to be able to use the app securely, I would need to use the authentication.
see: https://help.ovhcloud.com/csm/fr-public-cloud-ai-deploy-tokens?id=kb_article_view&sysparm_article=KB0047992
Would you be able to implement authentication methods to Swarm-API-Backend ?
Thank you!

Added as a backend setting


testing : attach method fails if the data passed is an array

if passed an array of files through attach method, the validation fails :/

Please ask on the forums. Also, in future, this information was totally insufficient to do anything with.


SocketIO 2.0

Hi @marcosscriven,
I work on Loop, and we've just updated the backend to use SocketIO 2.0.
I've just cloned the repo and confirmed it works after just changing the version in package.json to 2.2.0, but making a pull request isn't going to be possible quickly from my end, so hoping you can fix it!
Thanks!

Thanks @paulmdavies for the notification - I know how it is getting the red tape done to contribute externally, however, trivial.
I updated both the node and web client, seems to work fine thanks.

@paulmdavies great when company developers come out of the woodwork!
Could I add another repo to your radar? https://github.com/pavoni/pyloopenergy/issues/30
Eventually guessed what the issue was, but could have saved a little time if I'd seen your helpful  heads up on the version change.

Hi @paulmdavies - do you still work at Loop?
I got the email your gas readings service is shutting down, so I asked for the API code to read from this device. However, someone called Gerry has refused.
I wonder if you could help find a way to not just brick this device please? I’m not expedient Loop to run a service or divulge its IP. Merely allow us to continue to use the device locally.

Hi Marcos - sorry for not seeing this sooner.
The device has no API - it merely sends data to the Loop backend in a custom message format. There's no possibility to query the data from the device locally.

Hi Marcos - sorry for not seeing this sooner.
The device has no API - it merely sends data to the Loop backend in a custom message format. There's no possibility to query the data from the device locally.


Tiny typo

I can't do neutronics, but I can help fixing typos 🤓

Thanks for the fix @RemDelaporteMathurin it is rebuilding now and should be deployed online in a few mins


[Linux Build Actions] Do not preserve directory tree when packing tar

Basically it won't include the "export/release/linux/bin" folders with it anymore.

Can you do this for mac too pls

Done, will just make a new PR for this since I've renamed the branch


[bgfx] Update to v1.118.8415-411

[x] Changes comply with the maintainer guide
[x] SHA512s are updated for each updated download
[x] The "supports" clause reflects platforms that may be fixed by this new version
[x] Any fixed CI baseline entries are removed from that file.
[x] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

Fixed the submodule versions


Improve how exception looks like for dnxcore

PCL collects stack as exception.StackTrace string. We may want to improve this in Core.

Hi, I have the following questions:

In what aspects do you want the exeption to improve?
Is there the issues, which can help me?

Thank you, I await your response...

Hello,
Any specifics on how can this be improved?

@gzepeda this was fixed by https://github.com/Microsoft/ApplicationInsights-dotnet/pull/521 Thanks for asking!


Inference speed m2m_100

Hello,
I'm experimenting with the m2m_100 model (4 gpus checkpoint) and observed that on my testing machine, the translation of sentences of about 128 tokens take about 2 minutes. I'm talking about pure inference time and decoding, without taking into account the time spent loading the model and preparing the input.
I was wondering if this timing is what one would expect or if there is something I can do to speed up the process... although I doubt it.
Also, is there a way to translate sentences longer than 256 tokens? I understand that max_positions is fixed and the model has been trained with that number, so changing it at inference time could disrupt the behavior, however I just want to know if this is something feasible or not. This second question is related to #2875
Thank you

Hello @SaricVr. My inference time is around 2 minutes per 128 sentences on an 8 core intel processor, which is about 1 second per sentence translation.
The easiest solution is to distill knowledge into a smaller, faster architecture. For instance, I'm currently building a mobile friendly version of the M2M model by applying knowledge distillation to train a smaller architecture (e.g. fewer transformer layers, smaller layer width). The inference time will improve by doing this (at the expense of accuracy). I've already tried torchscript & packages such as torch.utils.mobile_optimizer, but received inadequate results there.
I'm also exploring the mobileBERT architecture.

On the natural language inference tasks of GLUE, MobileBERT achieves a GLUEscore o 77.7 (0.6 lower than BERT_BASE), and 62 ms latency on a Pixel 4 phone.

Another, more involved, solution is to port the M2M model to a framework optimized for inference latency (e.g. MarianNMT). The model size may still need to be further reduced, however.

Hello @SaricVr. My inference time is around 2 minutes per 128 sentences on an 8 core intel processor, which is about 1 second per sentence translation.
The easiest solution is to distill knowledge into a smaller, faster architecture. For instance, I'm currently building a mobile friendly version of the M2M model by applying knowledge distillation to train a smaller architecture (e.g. fewer transformer layers, smaller layer width). The inference time will improve by doing this (at the expense of accuracy). I've already tried torchscript & packages such as torch.utils.mobile_optimizer, but received inadequate results there.
I'm also exploring the mobileBERT architecture.

On the natural language inference tasks of GLUE, MobileBERT achieves a GLUEscore o 77.7 (0.6 lower than BERT_BASE), and 62 ms latency on a Pixel 4 phone.

Another, more involved, solution is to port the M2M model to a framework optimized for inference latency (e.g. MarianNMT). The model size may still need to be further reduced, however.

Hello @SaricVr. My inference time is around 2 minutes per 128 sentences on an 8 core intel processor, which is about 1 second per sentence translation.
The easiest solution is to distill knowledge into a smaller, faster architecture.
For instance, I'm currently building a mobile friendly version of the M2M model by applying knowledge distillation to train a smaller architecture (fewer transformer layers, smaller layer width). This will improve latency (at the expense of accuracy).
Note: I've tried torchscript & packages such as torch.utils.mobile_optimizer, but received inadequate results there.
I'm also exploring the mobileBERT architecture.

On the natural language inference tasks of GLUE, MobileBERT achieves a GLUEscore o 77.7 (0.6 lower than BERT_BASE), and 62 ms latency on a Pixel 4 phone.

A more involved solution is to port the M2M model into a framework optimized for inference latency (e.g. MarianNMT, which is a framework used by many huggingface transformers). I suspect the model size might still need to be reduced, though.

Hello @SaricVr. My inference time is around 2 minutes per 128 sentences on an 8 core intel processor, which is about 1 second per sentence translation.
The easiest solution is to distill knowledge into a smaller, faster architecture.
For instance, I'm currently building a mobile friendly version of the M2M model by applying knowledge distillation to train a smaller architecture (fewer transformer layers, smaller layer width). This will improve latency (at the expense of accuracy).
Note: I've tried torchscript & packages such as torch.utils.mobile_optimizer, but received inadequate results there.
I'm also exploring the mobileBERT architecture.

On the natural language inference tasks of GLUE, MobileBERT achieves a GLUEscore o 77.7 (0.6 lower than BERT_BASE), and 62 ms latency on a Pixel 4 phone.

A more involved solution is to port the M2M model into a framework optimized for inference latency (e.g. MarianNMT, which is a framework used by many huggingface transformers). I suspect the model size might still need to be reduced, though.

unfortunately, the inference speed for large models is indeed very slow. We are very interested in making this faster, with alternative architectures and compression as Jorg mentions above. thanks for your interest!

unfortunately, the inference speed for large models is indeed very slow. We are very interested in making this faster, with alternative architectures and compression as Jorg mentions above. thanks for your interest!

Ok, understood. Thank you for the answers and for the great pointers!

Ok, understood. Thank you for the answers and for the great pointers!

are you referring to the 12B checkpoint?

Hello @SaricVr. My inference time is around 2 minutes per 128 sentences on an 8 core intel processor, which is about 1 second per sentence translation.
The easiest solution is to distill knowledge into a smaller, faster architecture.
For instance, I'm currently building a mobile friendly version of the M2M model by applying knowledge distillation to train a smaller architecture (fewer transformer layers, smaller layer width). This will improve latency (at the expense of accuracy). Note: I've tried torchscript & packages such as torch.utils.mobile_optimizer, but received inadequate results there.
I'm also exploring the mobileBERT architecture.

On the natural language inference tasks of GLUE, MobileBERT achieves a GLUEscore o 77.7 (0.6 lower than BERT_BASE), and 62 ms latency on a Pixel 4 phone.

A more involved solution is to port the M2M model into a framework optimized for inference latency (e.g. MarianNMT, which is a framework used by many huggingface transformers). I suspect the model size might still need to be reduced, though.

are you referring to the 12B ckpt?

Hello @SaricVr. My inference time is around 2 minutes per 128 sentences on an 8 core intel processor, which is about 1 second per sentence translation.
The easiest solution is to distill knowledge into a smaller, faster architecture.
For instance, I'm currently building a mobile friendly version of the M2M model by applying knowledge distillation to train a smaller architecture (fewer transformer layers, smaller layer width). This will improve latency (at the expense of accuracy). Note: I've tried torchscript & packages such as torch.utils.mobile_optimizer, but received inadequate results there.
I'm also exploring the mobileBERT architecture.

On the natural language inference tasks of GLUE, MobileBERT achieves a GLUEscore o 77.7 (0.6 lower than BERT_BASE), and 62 ms latency on a Pixel 4 phone.

A more involved solution is to port the M2M model into a framework optimized for inference latency (e.g. MarianNMT, which is a framework used by many huggingface transformers). I suspect the model size might still need to be reduced, though.
@Jorghi12  Hello, I want to ask if the knowledge distillation of m2m100 has been realized? How to choose teacher model and student model

To give a sense of how slow the inference is, I compared M2M100 418M with AWS. Keep in mind that translation via AWS involves, in addition to inference, uploading and downloading data. M2M was noticeably slower than AWS. How could this be?

Hello @SaricVr. My inference time is around 2 minutes per 128 sentences on an 8 core intel processor, which is about 1 second per sentence translation.
The easiest solution is to distill knowledge into a smaller, faster architecture.
For instance, I'm currently building a mobile friendly version of the M2M model by applying knowledge distillation to train a smaller architecture (fewer transformer layers, smaller layer width). This will improve latency (at the expense of accuracy). Note: I've tried torchscript & packages such as torch.utils.mobile_optimizer, but received inadequate results there.
I'm also exploring the mobileBERT architecture.

On the natural language inference tasks of GLUE, MobileBERT achieves a GLUEscore o 77.7 (0.6 lower than BERT_BASE), and 62 ms latency on a Pixel 4 phone.

A more involved solution is to port the M2M model into a framework optimized for inference latency (e.g. MarianNMT, which is a framework used by many huggingface transformers). I suspect the model size might still need to be reduced, though.

Depending on, among other things, the hardware and the model, "1 second per sentence translation" isn't that bad. See my post. That said, AWS is surprisingly faster at, often times, less than 0.1 second.


disallow changing the scale from fixed to global

https://github.com/rancher/rancher/issues/6812

TF is unrelated.


Add the ability to log interrupted periods.

For example, only 16 minutes out of 25 have passed, when the counter is reset, those 16 minutes are logged.
Unfinished pomodoro are marked differently so that they can be counted

Hi! I understand that logging requirements can vary, so I am considering implementing a more generic approach, such as a log template. What do you think?

Hi. Yeah, that sounds great.

@Fertion I've just released an update, and I believe this template script wil cover the case you mentioned. Modify it as necessary.
Please ensure that the Templater plugin is installed, as this script relies on it.
<%*
if (log.mode == "WORK") {
  if (!log.finished) {
    tR = `🟡 Focused ${log.duration} / ${log.session} minutes`;
  } else {
    tR = `🍅 Focused ${log.duration} minutes`;
  }
} else {
  tR = `☕ Took a break from ${log.begin.format("HH:mm")} to ${log.end.format(
    "HH:mm"
  )}`;
}
%>

Here are some references that might be helpful:
Readme - Custom log template
Templater - Documentation

Just what I need, thanks.
This works if you press button 1, but does not work if you press button 2 with the timer running.

That was intentional actually.
I plan to disable the mode switching while the timer is running to avoid any mix-ups and keep the timer from getting reset by mistake.


[Feature]

Description
Issue: Implement Financial Calculator Feature
Description
We aim to add a financial calculator to our CalciDiverse app. This feature will allow users to perform key financial calculations, including:

Loan Payment Calculator: Calculate monthly payments based on loan amount, interest rate, and term.
Future Value Calculator: Estimate the future value of investments with given interest rates and compounding periods.
Present Value Calculator: Determine the present worth of future sums.
Mortgage Payment Calculator: Compute monthly mortgage payments, including principal and interest.

Requirements

Implement calculations using JavaScript.
Design a responsive HTML interface for user input and output.
Ensure input validation and error handling.

Tasks

Develop the UI for input and output.
Write JavaScript functions for calculations.
Integrate calculations with the UI.
Test for responsiveness and accuracy.

Screenshots
No response
Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[X] I am a GSSOC'24 contributor.
[ ] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[ ] I am a SWOC'24 contributor.

Code of Conduct

[X] I agree to follow this project's "Code of Conduct".

@Varsani2520  please assign me this issue under GSSOC'24

@Rakesh9100 please assign me this issue under GSSOC'24

Go ahead @priyashuu


Training Launcher (Front End)

This is the training launcher page.  before a volunteer can work the phones, they need to take the training to get up to speed.
This task is for the UI only of the launcher.

[ ] it should have re-usable mid sections for more modules as needed.

[ ] it will also have a section for custom notes (only will appear if there are any notes in organization settings)

https://projects.invisionapp.com/d/main#/console/14746784/338201794/preview

Approved.  nice work


feat: add index.d.ts

Checklist

[x] npm test passes
[x] tests and/or benchmarks are included
[ ] documentation is changed or added
[ ] commit message follows commit guidelines

Description of change

Add index.d.ts.

Codecov Report

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

@@          Coverage Diff          @@
##           master    #10   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           2      2
  Lines           8      8
=====================================
  Hits            8      8

Impacted Files
Coverage Δ

app.js
100% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

1.1.0


Change mkdir conf for config to match volume

Creates config directory instead of conf to match the volume, which was changed in #392

@omBratteng Applied, thanks


Inclusion of desktop and metadata files for the GUI application

This PR is a contribution which adds the desktop and AppStream metadata files for XEphem and its integration with the source code.
AppStream metadata provides information about the application in the software centers of some Linux distributions (for example, in GNOME software included in Ubuntu), showing for the end-user a specific description and screenshots of the application, with the opportunity to translate this information into different languages. Linux distributions such as Debian and Fedora suggest in their packaging practices to include *.desktop and *.metainfo files for GUI applications.
The attached screenshot shows the presentation of XEphem in the GNOME software of my Ubuntu 18.04.

Hi @brandon-rhodes!
Thank you very much for responding to my PR request for XEphem.
In following, I will extend on your doubts mentioned in the previous comment.

"...GNU make. So maneuvers like := won't work, I don't think, and maybe not things like $(MAKE) either, though I'm not sure."
I understand the reason for keeping the GUI/xephem/Makefile file unchanged to ensure compatibility of code in the compilation process on different platforms. In fact, I also agree with you on this point.

"I love the typo fixes! If they were their own PR, I'd merge immediately."
Precisely for this, I sent a new PR which contains only these corrections. This PR present also contains them, but they are merged with other aspects.

"I don't know at all what to think about the desktopfiles/ directory. I've never used a project with a directory of that name - is it standard?"
This is a directory dedicated to hosting files such as icons, desktop and metadata files. Various projects integrate a directory for this type of files and its name is appropriate to the needs and style of the project; so, I don't believe there is a standard for his name.
However, here some examples in Stellarium, Celestia, VLC, Vokoscreen.
I decided to use the name desktopfiles/ in this PR, since in multi-platform projects like GIMP and DjView4 is also used.

"if it's metadata, ... It's a shame it's XML and not JSON."
At this point, if it is a standard for files AppStream metadata in order to display the meta-information of the projects, through the software centers present in different Linux distributions. Additionally, the packaging guidelines for distributions as Debian and Fedora encourage developers to use this format.

"You list yourself as the copyright holder of the new xephem.metainfo.xml file."
At this point, I have put the copyright note for the xephem.metainfo.xml file as a validation requirement. That is, about good practices for the preparation of this type of document. Of course, I do not want to ignore the work of other collaborators in this type of document; on the contrary, if I have unknown him, I apologize by don’t have in mind his contributions or authorship from him. If necessary, I would have no problem correcting or removing this line from this document.

New PRs
According to the above, for me it is more appropriate to send a new PR (other!) in which it exclusively contains the inclusion of the desktop files and metadata for the GUI application, and thus, close this PR to avoid confusion in the aspects already mentioned.

I'll be awaiting your comments. Success in the project!!


[ionic-push] Notification status API response for multiple tokens

Hi, This is regarding Push notification APIs. The issue that I am facing is that when I make a single call to notification create API for multiple device-tokens and then make another API call to retrieve status of this notification then I do not get status/error per token. Sometimes I get status for few of the given tokens and sometimes for only one of them. This seems random to me.
I am adding the actual cURL calls and received responses for reference.
Call to create notification to 7 device-tokens-
curl -X POST -H "Authorization: Bearer <my_app_token>" -H "Content-Type: application/json" -d '{
    "tokens": ["cA6UtzTzO-U:APA91bHH7pyeGryf0990zZlMWszh2VorSNjOXs3f8SHyBmddBBGINFkmn7bTF-SoQMCwhG1nwymrpN1s6oXpfm4rIkFEarRHqGYoEHCGJbsNiYLWi8g5Bqbzu_QDVgN9V2GV2frDsUiG", "c0XgHOJtGDQ:APA91bG63seri8XH7cE6YV8Zqhty-vSZkLz_AG9CLS-TJMWg6dLHxi3FGHnJSZGeRSsqQNOYNBf-_i_XsSmyPnoQw9iAGQa3eH7Nsw4bAAarRfDNuBWQUx7gA6LZ7-gIlk5vfuGbR8vh", "fXQbWvRGBro:APA91bH36m9Ms_NvJ__ll3IL8NigqY4oAy0A365W5PWlTopQdrbfLnCN6FUn2eeKFH6PMIhXH-3zEo3H3VGAfvl3YjZUSLXOcqnd3tlbeUSc0nhDVVumlOOUzV_Qt_plmPIcbOadcBqg", "9176590cb28243457931fd60e43898981595a4e980f79f782f265acc05006579", "46ec8bceacfed1ed1e1d09cbede87a034248837f120f8686268495d31614c95d", "c72f7da6407c607b6f27d740ab820afe4ba195ae18a65b0b3a07f08c36eac403", "3722f8141e4457f22e9efc3aa46a9dff957dd1ca8b8ea701070e389f13c29462"],
    "profile": "<my_security_profile>",
    "notification": {
        "title": "test_title",
        "message": "test_message"
    }
}' "https://api.ionic.io/push/notifications"

Response from this-
{
  "meta": {
    "version": "2.0.0-beta.0",
    "request_id": "66396e22-77ab-40f8-c077-e29651c67212",
    "status": 201
  },
  "data": {
    "created": "2017-01-16T18:15:33.398727+00:00",
    "status": "open",
    "config": {
      "tokens": [
        "cA6UtzTzO-U:APA91bHH7pyeGryf0990zZlMWszh2VorSNjOXs3f8SHyBmddBBGINFkmn7bTF-SoQMCwhG1nwymrpN1s6oXpfm4rIkFEarRHqGYoEHCGJbsNiYLWi8g5Bqbzu_QDVgN9V2GV2frDsUiG",
        "c0XgHOJtGDQ:APA91bG63seri8XH7cE6YV8Zqhty-vSZkLz_AG9CLS-TJMWg6dLHxi3FGHnJSZGeRSsqQNOYNBf-_i_XsSmyPnoQw9iAGQa3eH7Nsw4bAAarRfDNuBWQUx7gA6LZ7-gIlk5vfuGbR8vh",
        "fXQbWvRGBro:APA91bH36m9Ms_NvJ__ll3IL8NigqY4oAy0A365W5PWlTopQdrbfLnCN6FUn2eeKFH6PMIhXH-3zEo3H3VGAfvl3YjZUSLXOcqnd3tlbeUSc0nhDVVumlOOUzV_Qt_plmPIcbOadcBqg",
        "9176590cb28243457931fd60e43898981595a4e980f79f782f265acc05006579",
        "46ec8bceacfed1ed1e1d09cbede87a034248837f120f8686268495d31614c95d",
        "c72f7da6407c607b6f27d740ab820afe4ba195ae18a65b0b3a07f08c36eac403",
        "3722f8141e4457f22e9efc3aa46a9dff957dd1ca8b8ea701070e389f13c29462"
      ],
      "profile": "<my_security_profile>",
      "notification": {
        "message": "test_message",
        "title": "test_title"
      }
    },
    "uuid": "dadb57af-fac1-4c59-a2f8-c6ff5a5f0159",
    "app_id": "<my_app_id>",
    "state": "enqueued"
  }
}

Then using the uuid, call to retrieve status-
curl -X GET -H "Authorization: Bearer <my_app_token>" -H "Content-Type: application/json" "https://api.ionic.io/push/notifications/dadb57af-fac1-4c59-a2f8-c6ff5a5f0159/messages"

Response from this-
{
  "meta": {
    "version": "2.0.0-beta.0",
    "request_id": "f3150626-491b-4887-c8ae-291e4e97e14c",
    "status": 200
  },
  "data": [
    {
      "created": "2017-01-16T18:15:33.624836+00:00",
      "user_id": null,
      "error": null,
      "uuid": "0d6198d6-425e-42be-ba3c-74fe4f0482c0",
      "notification": "dadb57af-fac1-4c59-a2f8-c6ff5a5f0159",
      "token": {
        "created": "2017-01-16T14:45:54.122496+00:00",
        "type": "android",
        "app_id": "<my_app_id>",
        "invalidated": null,
        "valid": true,
        "token": "c0XgHOJtGDQ:APA91bG63seri8XH7cE6YV8Zqhty-vSZkLz_AG9CLS-TJMWg6dLHxi3FGHnJSZGeRSsqQNOYNBf-_i_XsSmyPnoQw9iAGQa3eH7Nsw4bAAarRfDNuBWQUx7gA6LZ7-gIlk5vfuGbR8vh",
        "id": "32e0cb0258958a3f2ccdf66bcd2dc53e"
      },
      "status": "sent"
    },
    {
      "created": "2017-01-16T18:15:33.621845+00:00",
      "user_id": null,
      "error": null,
      "uuid": "a7363546-cea2-4bd9-af21-5ee1534e5c4f",
      "notification": "dadb57af-fac1-4c59-a2f8-c6ff5a5f0159",
      "token": {
        "created": "2016-10-31T18:04:15.289611+00:00",
        "type": "ios",
        "app_id": "<my_app_id>",
        "invalidated": null,
        "valid": true,
        "token": "46ec8bceacfed1ed1e1d09cbede87a034248837f120f8686268495d31614c95d",
        "id": "d58d6fbedcad1dcd1bbeb664966052b0"
      },
      "status": "sent"
    },
    {
      "created": "2017-01-16T18:15:33.618752+00:00",
      "user_id": null,
      "error": null,
      "uuid": "e55d96df-ec20-4af3-a0a3-f22774ecd385",
      "notification": "dadb57af-fac1-4c59-a2f8-c6ff5a5f0159",
      "token": {
        "created": "2016-12-27T14:31:23.609266+00:00",
        "type": "android",
        "app_id": "<my_app_id>",
        "invalidated": null,
        "valid": true,
        "token": "fXQbWvRGBro:APA91bH36m9Ms_NvJ__ll3IL8NigqY4oAy0A365W5PWlTopQdrbfLnCN6FUn2eeKFH6PMIhXH-3zEo3H3VGAfvl3YjZUSLXOcqnd3tlbeUSc0nhDVVumlOOUzV_Qt_plmPIcbOadcBqg",
        "id": "6a3088915dfa16c9d5aaef3227a31220"
      },
      "status": "sent"
    }
  ]
}

It can be noticed that I got status for only 3 of the 7 tokens. In a previous exact call, I got status for 4 of the 7.
Status/error per token is crucial to my requirement and should be consistent. Please look into it and/or provide information if I am missing anything here.

Any update for this?

Any update for this?

Messages are created as the notification is parsed, and will not be created for invalid tokens or targets with no associated tokens.  As mentioned in the other issue, you can use the tokens API to determine the validity of individual tokens, but if a message is not created for a notification, it means that the token was marked invalid.


Add request for single project and redux thunk to get project and put into state

Current dependencies on/for this PR:

main

PR #1851

PR #1852

PR #1853   👈

This stack of pull requests is managed by Graphite.

App.tsx requests all projects today.
This pattern of bulk requesting data and depending on that to view specific data by id, is used across the board. We could change that pattern if needed.. for now the project by id should already exist because of App.tsx call.
Not sure if the batches list page requests the data again.
Thoughts?

Oh right... I forgot about that. I generally prefer to get the data in the view, this guarantees that if the data has changed at some point (let's say outside of the projects area... if that is even possible) it will be accurate by the time you get to the view. I suppose in this case, the project entity wouldn't be modified elsewhere so I can remove it if you want

App.tsx requests all projects today.
This pattern of bulk requesting data and depending on that to view specific data by id, is used across the board. We could change that pattern if needed.. for now the project by id should already exist because of App.tsx call.
Not sure if the batches list page requests the data again.
Thoughts?

Oh right... I forgot about that. I generally prefer to get the data in the view, this guarantees that if the data has changed at some point (let's say outside of the projects area... if that is even possible) it will be accurate by the time you get to the view. I suppose in this case, the project entity wouldn't be modified elsewhere so I can remove it if you want

No need to remove it. Since the request by id updates the same state in redux (projects list), data will be consistent across project view and projects list view. This is a cleaner optimal design for sure. We currently fetch all data, edit single views, refetch all data.. to keep things consistent in redux. A per object approach is certainly a better path.

If you'd like, up to you. Or leave it for future requests.

Cool, I have to do the edit and delete project requests next so I will do it in that PR


Hf/add player velosity to projectiles

This is related to #400

Make sure to test if aiming is even more difficult now (if that is even possible).
Adding the player velocity will make the projectiles not land where the player was aiming if he was moving while shooting.

This does not solve the #400, still extinguishes the candle if you shoot and strafe to the right

Now solves #400
Player can shot their own candle if it's on the floor but not if it's in their hand.
Also fixed a bug related to the movement in debug when the framerate is low


Add workflow to upload Artifact Bundle

Add action to upload artifact bundle

It's difficult to test this so I'll merge this without approval.


Inline fields don't work if they're used with bullets

Perhaps tangential to #158 :
first: this is a mindblowing extension and I can't thank you enough for building it— it's helping me surface things from my old knowledge vaults I'd given up on.
Issue— I got into the habit of using bullets when creating metadata fields when using Roam, and still like the idea of nested tags/ having inline blocks (over a YAML header). However, dataview doesn't identify key value pairs when used in bullets (whether nested or not).  Is there a workaround for this or should we never use bullets when using inline fields?
So a query like the following one

Which works when the key— Week is not bulleted

will fail as soon as bullet are used

Would love support for this. I know you did say that you'd be adding it but couldn't find an entry in the readme checklist.

Bumping this!


Delete items which are removed from a feed

Trying to fix this spam problem on blog.openstreetmap.org: https://github.com/gravitystorm/blogs.osm.org/issues/17 I've come up with this logic which I believe will solve it.
I've added a test. I have now also tested this logic end-to-end within a full pluto set-up, and it seems to work as expected. I've only done that by hacking the gem internals. I didn't figure out how to build this into a gem properly. The multi-gem set-up with hoe is confusing to me at the moment.
Also you may prefer to make this behaviour optional, as a thing users can switch on for a particular feed (so a config option for the ini file entries, rather like filters). I took a look at doing this, but for similar reasons passing the option through multiple gems seemed tricky.
Having said that, I could make a case that the "delete removed" behaviour is actually desirable as reasonable default. For most blog feeds most of the time it will make no difference (find nothing was removed), but presumably if a source blogger ever wants to delete an entry they published by accident they'll run into the same problem we're seeing with deleting spam diary entries.

Sorry for the late reply. I was on vacation (offline) until today. You have of course my full support. Thanks for using pluto for  the open street map planet.   As a quick review I'm happy to merge and you're welcome to join as a committer if interested (just let me know and I send you an invitation via github) - the only addition would be a something like a feature / command line flag (e.g. --delete) that lets you toggle the (new) delete functionality since not everybody might want to use it. I will try to add it in the next days (and push out a new gem).

feature / command line flag (e.g. --delete) that lets you toggle the (new) delete functionality

Yes, that could be a good idea, although as I a say, I don't think it should be a problem running with this over any blog source.  I think ideally it would be a per feed option within the .ini file config.

Thanks for your patience.  Since you're basically the only user as far as I can tell I'm with you. Let's keep it simple - I will just add some comments (for some possible future work).  I will try to push out a new gem later this week.

Well to be clear, I'm one OpenStreetMap enthusiast interested in fixing the spam problem, but I'm sure the OpenStreetMap sysadmins (people like @tomhughes )  would appreciate your vigilance in ensuring I don't commit any crazy code to pluto :-)
They may also feel more comfortable with the ability to configure this new logic in the .ini file, to apply only to the OpenStreetMap diaries (Although I maintain that this is not strictly necessary the code won't cause any adverse effects for other sources)
In fact I'm currently demoing this working here:
https://harrywood.dev.openstreetmap.org/blogs.osm.org/build
compare with
https://blogs.openstreetmap.org
And in the logfile here:
https://harrywood.dev.openstreetmap.org/blogs.osm.org/buildscript.log
We can see it doing a "DELETE" only on spam entries in the osm diaries.
What d'you think @tomhughes ? If @geraldb packages this up as a new pluto gem, would you be comfortable rolling with it? Or d'you think we should ask gerald to make it an .ini file option? (I did have a go at doing this, but couldn't work out how to do it across the different gems)

No worries - if anything breaks we can change / fix / improve the code (and push out a new gem). Thanks again for the detailed report and testing.

@harry-wood FYI: Your delete removed feed items change is now "gemified", that is, you can use the lastest gem, that is, pluto-models v1.5.1 https://rubygems.org/gems/pluto-models.

now "gemified"

Thanks!
I didn't realise, but @tomh has done the bundle update   to put this change live on https://blogs.openstreetmap.org   In fact he did that a few minutes after you said that. I think he was keen to zap that spam! :-)

Thank you. Great to see the zap spam machinery live. Have a great weekend. Cheers.


CB-10445: Documentation includes broken github links

Fixing broken links.
@dblotsky @riknoll @nikhilkh @rakatyal Can you please review and merge this PR?

LGTM. @rakatyal I remember we integrated a gulp command in docs build to find broken links - it might be a good idea to run it and fix all broken links. Also, we need it to be part of docs build CI.

Suggestion: use reference-style links.

@nikhilkh we have a JIRA for it, but it's lower priority.

@dblotsky that would be nice, but we don't really do that in the rest of the docs. Might be worth a separate JIRA task.

@dblotsky Changed the links to reference style links

@riknoll I've created a JIRA for the styling.

LGTM.


Give full list of dependencies in README

In section https://github.com/Marxlp/pyFlightAnalysis#run-from-source , rather than the somewhat imprecise list of dependencies, would be great if you could provide something people can copy-paste like:
pip install pyqtgraph pyOpenGL pyulog numpy matplotlib

If using Python3, then also install PyQt as shown
pip install PyQt5

Note If using Python 2, instead install PyQt4 manually ....

Yes, I have updated the README file. But it still need your review to avoid syntax error.

Yes, I have updated the README file. But it still need your review to avoid syntax error.

The changes are not rendering. I have created #6 which fixes this and improves the English a little.
This can be closed if #6 is merged.

Fine.


XmlParserException: ">" expected at 1:16

It can't be parsed.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<title>405 Method Not Allowed</title>

Method Not Allowed

The requested method PUT is not allowed for the URL /myURL.

from S3 error
sorry. myURL is secret.
called by this
xml.XmlDocument.parse(response.body);

Note that your input is not valid XML, several online validators (https://www.w3schools.com/xml/xml_validator.asp, https://www.xmlvalidation.com/, https://www.liquid-technologies.com/online-xml-validator) agree with the library.
If this is HTML, you probably want to use a HTML parser instead?

Thank you for replying!
Amazon S3  reply such HTML...
Does your module check XML or HTML?
because, I want to check HTML or XML before parsing.

No, the input is expected to be valid XML. Typically XML documents start with <?xml ..., but that is not a requirement.


Projects instead of milestones

Implement Git Projects instead of Git Milestones for a few of the milestones that don't make too much sense. These projects can then have milestones in them, but can exist for a long time.
Milestones are goals that should be reached with due dates, projects are long term goals and sometimes even tickets that are too far in the future or not feasible yet.
Some long-living projects could include

Route viewer
Route editor
Hold editor

Some not yet feasible projects could include

3D display with WebGL

Some ever-living git projects could include...

Bug reports

Will not do, may implement later.


Auto close after selecting file

Would it be possible to automatically close rnvimr after selecting a file?

h rnvimr
g:rnvimr_pick_enable
    Default: 0

    Enable ranger to be hidden after picking a file.
    It will automatically attach file in next |:RnvimrToggle|.


[R-package]  Error in data$update_params(params = params) :    [LightGBM] [Fatal] Cannot change max_bin after constructed Dataset handle.

Description

When trying to create a model I get this error:
Error in data$update_params(params = params) :
  [LightGBM] [Fatal] Cannot change max_bin after constructed Dataset handle.

Reproducible example

I run the script from Repit
devtools::install_github("rstudio/reticulate")
devtools::install_github("rstudio/tensorflow")
devtools::install_github("rstudio/keras")

library(reticulate)
library(keras)
library(tensorflow)
conda_create("myenv")
use_condaenv("myenv")
install_keras(method="conda", envname="myenv")
install_tensorflow(version = "nightly", method = "conda", envname="myenv")
use_condaenv("myenv")

install.packages("lightgbm", repos = "https://cran.r-project.org")
library(lightgbm)
library(Retip)

#>Starts parallel computing
prep.wizard()

# import excel file for training and testing data
RP2 <- readxl::read_excel("Plasma_positive.xlsx", sheet = "lib_2", col_types = c("text",
                                                                              "text", "text", "numeric"))
# import excel file for external validation set
RP_ext <- readxl::read_excel("Plasma_positive.xlsx", sheet = "ext", col_types = c("text",
                                                                                "text", "text", "numeric"))
#> or use HILIC database included in Retip
HILIC <- HILIC
#> Clean dataset from NA and low variance value
db_rt <- proc.data(descs)
preProc <- cesc(db_rt) #Build a model to use for center and scale a dataframe
db_rt <- predict(preProc,db_rt) # use the above created model for center and scale dataframe

#> Split in training and testing using caret::createDataPartition
set.seed(101)
inTraining <- caret::createDataPartition(db_rt$XLogP, p = .8, list = FALSE)
training <- db_rt[ inTraining,]
testing  <- db_rt[-inTraining,]

When running this line, I receive the error above:
lightgbm <- fit.lightgbm(training,testing)
However, if I remove the max_bin = 50 inside the functionlightgbm::lgb.cv (that inside the function fit.lightgbm) or change it to max_bin = 255, then there is no errro.
Environment info
> sessionInfo()
R version 4.0.3 (2020-10-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19041)

LightGBM version or commit hash:
version 3.1.1
Command(s) you used to install LightGBM
install.packages("lightgbm", repos = "https://cran.r-project.org")
library(lightgbm)

Additional Comments

Many Thanks!

Thanks for using {lightgbm}!
Where does the function fit.lightgbm() come from? There is no such functiom in {lightgbm}. Right now, your example code does not seem to contain any {lightgbm} code.

[LightGBM] [Fatal] Cannot change max_bin after constructed Dataset handle.
This problem usually occurs when:
First, a Dataset is created, and used for training once.
Then if the user uses the same Dataset to train for the second time, and specify a different max_bin value from the first training, the error will be reported.
This is because, before Dataset is used for training, the feature values will be discretized into at most max_bin bins. And currently, we don't support discretize the Dataset for twice with different max_bin values.
To avoid this, just recreate the Dataset each time before your training.

@jameslamb - Sorry for being unclear.
The fit.lightgbm() comes from the  Repit (This is were all the code come from).
This how fit.lightgbm() looks like:
> fit.lightgbm
function (training, testing)
{
  train <- as.matrix(training)
  test <- as.matrix(testing)
  coltrain <- ncol(train)
  coltest <- ncol(test)
  dtrain <- lightgbm::lgb.Dataset(train[, 2:coltrain], label = train[,  1])
  lightgbm::lgb.Dataset.construct(dtrain)
  dtest <- lightgbm::lgb.Dataset.create.valid(dtrain, test[,2:coltest], label = test[, 1])
  valids <- list(test = dtest)
  params <- list(objective = "regression", metric = "rmse")
  modelcv <- lightgbm::lgb.cv(params, dtrain, nrounds = 5000,
                              nfold = 10, valids, verbose = 1, early_stopping_rounds = 1000,
                              record = TRUE, eval_freq = 1L, stratified = TRUE, max_depth = 4,
                              max_leaf = 20, max_bin = 50)
  best.iter <- modelcv$best_iter
  params <- list(objective = "regression_l2", metric = "rmse")
  model <- lightgbm::lgb.train(params, dtrain, nrounds = best.iter,
                               valids, verbose = 0, early_stopping_rounds = 1000, record = TRUE,
                               eval_freq = 1L, max_depth = 4, max_leaf = 20, max_bin = 50)
  print(paste0("End training"))
  return(model)
}

If I change the max_bin = 50 in the modelcv   to max_bin = 255 or remove it at all the function  lightgbm::lgb.cv does work.
Otherwise, there is the error mentioned.

@shiyu1994 -  Thank you for your time

Then if the user uses the same Dataset to train for the second time, and specify a different max_bin value from the first training, the error will be reported.

I do not think this is the case, since the  fit.lightgbm function looks like that:
> fit.lightgbm
function (training, testing)
{
  train <- as.matrix(training)
  test <- as.matrix(testing)
  coltrain <- ncol(train)
  coltest <- ncol(test)
  dtrain <- lightgbm::lgb.Dataset(train[, 2:coltrain], label = train[,  1])
  lightgbm::lgb.Dataset.construct(dtrain)
  dtest <- lightgbm::lgb.Dataset.create.valid(dtrain, test[,2:coltest], label = test[, 1])
  valids <- list(test = dtest)
  params <- list(objective = "regression", metric = "rmse")
  modelcv <- lightgbm::lgb.cv(params, dtrain, nrounds = 5000,
                              nfold = 10, valids, verbose = 1, early_stopping_rounds = 1000,
                              record = TRUE, eval_freq = 1L, stratified = TRUE, max_depth = 4,
                              max_leaf = 20, max_bin = 50)
  best.iter <- modelcv$best_iter
  params <- list(objective = "regression_l2", metric = "rmse")
  model <- lightgbm::lgb.train(params, dtrain, nrounds = best.iter,
                               valids, verbose = 0, early_stopping_rounds = 1000, record = TRUE,
                               eval_freq = 1L, max_depth = 4, max_leaf = 20, max_bin = 50)
  print(paste0("End training"))
  return(model)
}

And the max_bin=50 is constant if I understand it correctly.

I see, that was the context we needed. Thank you  I think that if you pass max_bin as  parameter to lgb.Dataset(), instead of lgb.train() and lgb.cv(), your code will run successfully. @shiyu1994 's explanation above explains why. Let us know if you have additional questions.

@jameslamb and @shiyu1994  Thank you for the clear explanations.
Following @jameslamb's last comment now it works.
Many Thanks!!


Improve unknown function error for operators

Summary of the changes / Why this improves CrateDB
Format the unknown operator in operator style, not function style.
Example:
unknown function: bool = ANY(integer)
Checklist

[ ] Added an entry in CHANGES.txt for user facing changes
[ ] Updated documentation & sql_features table for user facing changes
[x] Touched code is covered by tests
[x] CLA is signed
[ ] This does not contain breaking changes, or if it does:

It is released within a major release
It is recorded in CHANGES.txt
It was marked as deprecated in an earlier release if possible
You've thought about the consequences and other components are adapted
(E.g. AdminUI)

For example, instead of unknown function: (text = ANY(text)) we could have Unknown function: ('George' = ANY (name)), no overload found matching types: (text, text). (If we could include some of the candidates that would be even better)

Yep good point, pushed a fixup to use this style.


Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/2125/
Test FAILed.

@puppetlabs-jenkins retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/2144/
Test PASSed.

:+1:

our base acceptance does run against 15.04, so this should be tested in the Jenkins results
:+1:


Turbolinks duplicated requests

Hello!
I'm playing around with Stimulus and i encountered a pretty bad blocker - each time i leave and get back to a page which uses stimulus controller, all the controller code gets duplicated. One reload = one replica.
My controller periodically fetches stats and going to a different page and getting back on stats page 10 times makes the request duplicated 10 times - that's pretty bad.
You can see it here: https://mastodon-tags-explorer.hcxp.co/stats
Click on the Instances link and then again at Stats - you'll see that request to /stats.json is triggered two times per 10 seconds while it should be triggered once. Source code of this app is here: https://github.com/mbajur/mastodon-tags-explorer
Thanks in advance for any clues!

That's correct. Your controller starts a timer on connect(), but doesn't stop it on disconnect() so it continues running. See https://stimulusjs.org/handbook/working-with-external-resources#releasing-tracked-resources.


Make shard allocation give preference to current location

In this implementation, it gives infinite preference to the current location.
This works well in most if not all recent migrations that I am aware of,
but will work poorly in the special case of simply adding a new node,
without removing any nodes or increasing the number of copies. In this case
all shards will stay where they are and no shards will end up on the new nodes.
I think this is still a huge practical improvement over the former algorithm.
In the future if this becomes a concern, I think a potential solution is basically
to do this first, and then go through a secondary rebalancing step,
where the preference for current location is loosened and shards are moved from
fuller nodes to emptier nodes until an acceptable uniformity is reached.

but will work poorly in the special case of simply adding a new node,

From what I know, this is the only expected migration expected to take place in the next few months (perhaps on ICDS if expanding the cluster). Are there any migrations that you expect to occur that would benefit from this?

Oh, is that so? I'm planning on moving shards from couch[0-2]-production to
couch[3-10]-production (in multiple steps so there are pivot shards). For
that I want it to keep the same allocation for all existing commcarehq
(main DB) shards, and also keep locations of shards added over the multiple
steps without churn.
Sounds like you're saying that sometime soon we plan to add nodes on icds
have all existing shards get evenly rebalanced across the old and new
nodes. Is that right?
On Tue, Feb 5, 2019, 5:16 PM Jonathan Emord<EMAIL_ADDRESS>wrote:

but will work poorly in the special case of simply adding a new node,
From what I know, this is the only expected migration expected to take
place in the next few months (perhaps on ICDS if expanding the cluster).
Are there any migrations that you expect to occur that would benefit from
this?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dimagi/couchdb-cluster-admin/pull/24#issuecomment-460825576,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIX_PUcG-NSHE3Rb30XrMzkWKWIMiFfks5vKgKggaJpZM4ajtqO
.

@snopoke I think the changes I'm making here are still worthwhile. I'm going to add something that makes the behavior reasonable in the situation where you're adding an empty node and want shards redistributed to it.
About your specific issue with the user db, I think if you find something like that happening, you can now (with the changes I made in a recent PR) handle that by calling out the user db separately; then the allocation for the rest of the shards won't take it into account. If you have nodes couch0 through couch5, you could do:
target_allocation:
  - couch0,couch1,couch2,couch3,couch4,couch5:3:commcarehq__users
  - couch0,couch1,couch2,couch3,couch4,couch5:3

The second one will notice commcarehq__users was already mentioned and exclude it that piece of the allocation.

OK I used this for a series of migrations to move shards off couch[0-3], and it went great. (As you can see I had to make corrections to a couple logical errors in the algorithm.) I'm happy with this and will merge pending your review @snopoke


raftstore: enable observing cmds for all regions

Signed-off-by: 5kbpers<EMAIL_ADDRESS>
What problem does this PR solve?
Problem Summary:
Separate from #9435
After introducing follower stale read, all commands executed by all leaders need to be observed to advance resolved ts.
What is changed and how it works?
What's Changed:
This PR temporarily enable to observe commands for all regions.
There will be a mechanism to disable observing for follower peers after we complete merging all codes related to resolved ts.
Check List
Tests

Unit test
Integration test

Release note

N/A

/LGTM

Please address the comments above, thanks!


[Log Search UI] Make the app header aligned with the design

What changes were proposed in this pull request?
Just small css changes in order to meet the design of the Log Search
How was this patch tested?
Manunal tests and unit tests and also comparing with the design spec.
Please review Ambari Contributing Guide before opening a pull request.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/3101/
Test PASSed.


Add TestIndexResourcesManager and CleanupAllTestResourcesListener

Problem
Our current integration test setup is a bit difficult to reason about and debug. When adding new integration tests, it can be hard to understand the mechanics of how the current IndexManager creates and manages Index resources. We also end up with a lot of lingering index resources as indexes created via createIndexIfNotExistsDataPlane aren't generally cleaned up as a part of the tests they're used in.
Ultimately, I think we should move away from createIndexIfNotExistsDataPlane and findIndexWithDimensionAndType entirely and implement a way for indexes to be explicitly shared across tests by name.
Solution

Add new TestIndexResourcesManager singleton to handle creating, sharing, and cleaning up index resources across an integration test run.
Add new CleanupAllTestResourcesListener which implements Junit's TestExecutionListener allowing us to run the singleton cleanup at the end of the entire test run.
Update /integration/controlPlane/* tests to use the new pattern.

My goal here was to have a centralized TestIndexResourcesManager class that is used across all our integration tests. This class should handle global setup and teardown before and after all test classes run. Essentially, I wanted this class to act as a generator and manager for external resources.
I wanted to also have the TestIndexResourcesManager only create the required resources as needed. Instead of trying to create and seed multiple indexes before any tests run, I'm trying to do this only at the time a test that's included in the run requests the resource.
The strategy I've used here is to leverage the Junit Platform Launcher TestExecutionListener interface: https://junit.org/junit5/docs/5.0.3/api/org/junit/platform/launcher/TestExecutionListener.html
We can create a new class CleanupAllTestResourcesListener that implements TestExceutionListener and overrides testPlanExecutionFinished. We then need to register this listener which I've done by adding the /META-INF/services/org.junit.platform.launcher.TestExecutionListener file to the integration module. Check the code comments for a bit more info about where I figured out how to do this.
In this PR I've only updated the tests under /integration/controlPlane to leverage this new pattern, and it would be very similar for updating the data plane operations. Basically, we would go through and replace usages of findIndexWithDimensionAndType, createNewIndex, and createIndexIfNotExistsDataPlane with calls to getPodIndex() from the singleton.
I tried a few different methods of doing "global setup and teardown" in Junit and found it quite difficult. It was a lot easier to trigger code before and after each test class rather than the entirety of the run.
Other approaches tried:

I tried implementing a Junit extension and using the @ExtendWith() annotation across all tests: https://junit.org/junit5/docs/current/user-guide/#extensions. This worked for running code before and after each class but not the suite as a whole.
I tried having a base class BaseTest that was extended by each test class, and had its own @BeforeAll and @AfterAll. Again, this triggers every test class and not at the test run level.
Using "test suites", or organizing our tests at a higher level than discrete classes. This ultimately felt very cumbersome, and I couldn't find straightforward ways of running a suite directly with gradle, or handling running tests individually outside the suite context without losing the setup and teardown.

Type of Change

[X] Infrastructure change (CI configs, etc)

Test Plan
Run integration tests locally and in CI. Make sure control plane tests pass as expected with this new architecture.

implement a way for indexes to be explicitly shared across tests by name.
Yes!


Option to Disable Auto-Closing on Overlay Click for Dialog/Drawer Components

Hello
I'm writing to report an issue related to the overlay feature integrated within the Dialog and Drawer components of the shadcn UI.
Issue Description:
Currently, when the overlay (the dimmed area outside of the Dialog or Drawer) is clicked by the users, the Dialog or Drawer components automatically close. However, for our application, we require functionality where clicking on the overlay does not close these components.
Expected Behavior:
We need the Dialog and Drawer components to remain open even when the overlay is clicked. This behavior is essential for our use case as we want to keep the main content visible and interactive without dismissing it unintentionally by an overlay click.
it is not work :
<DialogContent
className="sm:max-w-[425px]"
onPointerDownOutside={(e) => {
e.preventDefault();
}}
Request:
Could you please develop and integrate the option to disable the auto-closing feature when the overlay is clicked? The ability to toggle this behavior on and off as needed would be greatly appreciated.
Thank you for your attention to this matter. We look forward to a resolution that will enhance the flexibility of these UI components.

@otthry
Here is the update
<DialogContent
	className='sm:max-w-[425px]'
	onEscapeKeyDown={(e) => e.preventDefault()}
	onPointerDown={(e) => e.preventDefault()}
	onInteractOutside={(e) => e.preventDefault()}
>
	...
</DialogContent>

Preventing on pointer down will cause input becoming unclickable, a minimal solution would be:
<DialogContent onInteractOutside={(e) => e.preventDefault()}>
...

I don't want to disable this on all my Dialogs, so I took @Hasankanso 's answer and created a prop:
interface DialogContentProps
  extends React.ComponentPropsWithoutRef<typeof DialogPrimitive.Content> {
  disableOutsideClick?: boolean;
}

const DialogContent = React.forwardRef<
  React.ElementRef<typeof DialogPrimitive.Content>,
  DialogContentProps
>(({ className, children, disableOutsideClick, ...props }, ref) => (

...

    <DialogPrimitive.Content
      onInteractOutside={
        disableOutsideClick
          ? (e) => e.preventDefault()
          : props.onInteractOutside
      }

And in the Dialog that I want to disable outside click:
<DialogContent disableOutsideClick>


How do I change font color for a particular block of text?

There is no easy way to do this with Markdown in Jekyll unless you want to write inline CSS or use HTML.
I suggest you search around Jekyll's help forums as this isn't something the theme can help with and is more of a Markdown/Jekyll issue.
Closing for this reason.


Add tz_world elixir library to lookup library list

Updates the library list in the README.md to include the Elixir language tz_world library.

I went ahead and manually added this in 92ee8cf707344f646ce104f0ae86e3de327f043c.


alert newline interpreted differently

Hello,
I couldn't find an open ticket for this.
When creating an alert, the alertmanager will interpret a \n as a newline
Prometheus itself interprets a html
 in the alerts section.
In the e-mail sent out none of the two are interpreted. I believe this should be consistent.
Here is the complete line I used, only the names are changed.
ALERT mycontainer_PRD_availability
  IF count(time() - container_last_seen{environment="production",image=~"^mycontainer.*"} < 300)
  ANNOTATIONS {
    summary = "Production container is down",
    description = "No production container running in the last 5 minutes.
 \n Documentation: https://wiki.mywebsite.com/index.php/mycontainer",
  }

If anyone has better ideas of how to send documentation and related information like charts in the alerts, let me know.
Also, if anyone has additional documentation on how to use labels in the alerts, that would help too.

This seems like Prometheus just fails to escape the HTML then in its UI.
Using HTML is a hint that you are probably going beyond the scope of alert annotations. In this case, you want documentation do be its own annotation. Any nicer representation for humans should happen in Alertmanager's notifications.
ALERT mycontainer_PRD_availability
  IF count(time() - container_last_seen{environment="production",image=~"^mycontainer.*"} < 300)
  ANNOTATIONS {
    summary = "Production container is down",
    description = "No production container running in the last 5 minutes.",
    documentation = "https://wiki.mywebsite.com/index.php/mycontainer",
  }

Hello @fabxc
Thanks for the info, I was unaware that we where allowed to add our own annotations. It looks much cleaner with the documentation as a separate annotation.
Where could I have found this in the documentation? I looked into this page

This is meant to be expressed by the syntax specification, which says that
the annotations block may contain any , not just two specific
ones.
Further down:
The ANNOTATIONS clause specifies another set of labels that are not
identifying for an alert instance. They are used to store longer additional
information such as alert descriptions or runbook links. The annotation
values can be templated.
Do you have suggestions on how to make the intent clearer?
On Tue, Aug 9, 2016 at 11:44 AM EvertMDC<EMAIL_ADDRESS>wrote:

Hello @fabxc https://github.com/fabxc
Thanks for the info, I was unaware that we where allowed to add our own
annotations. It looks much cleaner with the documentation as a separate
annotation.
Where could I have found this in the documentation? I looked into this
page https://prometheus.io/docs/alerting/rules/#defining-alerting-rules
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prometheus/alertmanager/issues/452#issuecomment-238505027,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEuA8grXV_A7KFxkZWVstCKJexoEztAMks5qeEwAgaJpZM4Jfzbd
.

Hello @fabxc
I think it's rather my English that's not advanced enough. I've read it from a different perspective and was thinking the additional information was a fixed set of keys and that I couldn't find those keys.
Thanks for explaining.

Not very cool to see this. i followed prometheus rules format google search first link to be there - perhaps i'm not the only one :)