arangoimport ignoring --translate in large tsv file

My Environment

ArangoDB Version:        3.5.3
Operating System:        Windows 10
Total RAM in your machine:        16Gb

Component, Query & Data
Affected feature:
arangoimport
Dataset:
available for download from http://www.catalogueoflife.org/DCA_Export/index.php
I downloaded complete data for plants (top level group=Plantae)
The main file is taxa.txt, a tsv file with 1.2M rows
I want the 1st column, taxonID, to be used as the document _key
Size of your Dataset on disk:
tsv file is 430MB
Steps to reproduce
import the file...
arangoimport --file "taxa.txt" --translate "taxonID=_key" --server.database species --collection col_taxa --create-collection --type tsv
Problem:
The import appears to work fine and in good time, however, the --translate option is ignored with no messages displayed. When I view the collection, taxonID is a normal attribute and _key is auto-generated. I tried renaming the header column to taxonid to avoid case issues and even _key, but neither worked.
IMPORTANT NOTE, it DID work as expected when I split out the first 300 rows into a separate file.
So, why does it not work on the larger file?
Expected result:
I expect taxonID to be used as the _key, or to display a meaningful warning/error message if it's not possible

I only tried this with the 3.7.3 Docker image, but I think I see the problem: taxa.txt has a byte order mark (BOM), which ArangoDB doesn't understand:
EF BB BF 74 61 78 6F 6E 49 44 ï»¿taxonID
It is interpreted as part of the first column name, which happens to be taxonID. The attribute ends up as \ufefftaxonID, and thus --translate doesn't match it.
Please remove the first three bytes from the source file. I would recommend a hex editor (e.g. HxD) but as this is text data it should also be okay to use Visual Studio Code for instance to re-save it without BOM. Then retry the import and let me know if it helped.

Ah yes, that's the issue. That's why it worked when I created a smaller separate file because it was saved with different encoding. FYI, I was using Notepad++ but I think HxD could be useful in future.
Many thanks for the help - much appreciated


Optional processor based on content-type header

Issue Description
What
I have implemented a SVGImageProcessor based on the discussion in this thread: https://github.com/onevcat/Kingfisher/issues/1225 . However I am fetching third party content I don't own, from various servers, and in some situations there is no file extension in the URL for me to be able to decide ahead of time when to apply the processor. I'm looking for something in the library that would allow me to read the response's content-type header to check if its svg and then add this processor if thats the case. This doesn't appear to be possible currently (unless i'm mistaken).
Is this functionality something you would consider adding? and in the short term do you have any guidance on how I could add it now, via subclassing, overrides, delegation etc. I don't know the library well and i'm struggling to find an easy place to add such logic

I seem to have a workaround, but I don't know what impact it will have on trying to retrieve / check if images are cached, as doing so requires passing in the processor identifier. Doing it this way, I have no way of knowing what the processor should be
Current solution:

Fork the library
Make various functions open instead of private, make structs public, add public init's etc
Create an ImageDownloader subclass
Override startDownloadTask(...
Check the network response, if the content-type header contains "svg", then find and swap the default image processor for an svg one

public class ContentTypeCheckingImageDownloader: ImageDownloader {

	public override func startDownloadTask(context: DownloadingContext, callback: SessionDataTask.TaskCallback) -> DownloadTask {

		...
		...
		...

			switch result {

				// Download finished. Now process the data to an image.
				case .success(let (data, response)):

					let processor = ImageDataProcessor(data: data, callbacks: callbacks, processingQueue: context.options.processingQueue)

					// If we are downloading an SVG, replace DefaultImageProcessor with SVGImgProcessor
					if let httpResponse = response as? HTTPURLResponse, let contentType = httpResponse.value(forHTTPHeaderField: "Content-Type"), contentType.contains("svg") {
						for (index, callback) in processor.callbacks.enumerated() {
							if callback.options.processor.identifier == DefaultImageProcessor.default.identifier {
								processor.callbacks[index].options.processor = SVGImgProcessor()
							}
						}
					}

		...
		...
		...
	}
}

I have the exact same requirement. I don't know what kind of image it is. My use case is an RSS Reader where the feed manages the images.
I also would have thought that appendProcessor would do the trick, by basically going through each processor (first the built in ones) and looking whether it can decode the image and then delegating to the appended ones; but it does not. It seems like when using appendProcessor it will only try very first processor.
setProcessor does not seem to work either because then I loose support for the built in formats that are supported.
And neither is there the possibility to get the content type from the signature public func process(item: ImageProcessItem, options: KingfisherParsedOptionsInfo) -> KFCrossPlatformImage? { from which I could then try to delegate to the built in processors (if they are public).
So how should we move forward?

Obviously, the best solution would be if Kingfisher were to support SVGs by default. There's quite some demand: https://github.com/onevcat/Kingfisher/issues/1225#issuecomment-1122412772

Any progress on this? Would you accept a PR with native support for SVG's?


PROPOSAL: Add --upgrade option to init enabling client to upgrade tiller if already installed

We're using helm in a continuous deployment pipeline, so the first step is to execute helm init to make sure tiller is installed in the cluster. Most of the time, tiller is already installed, so we get the expected warning about tiller already being installed, which is annoying but easy enough to ignore.
However, when we upgrade to new versions of helm, it would be useful if we at the same time could upgrade tiller. Currently we would need to detect the difference in version, then manually delete tiller, and then run helm init again.
It would be better if helm init could take an option --upgrade, which would make helm check the version of tiller, and upgrade to a matching version if it's not already up-to-date.

This makes sense to me.


SRE-2491 Set correct repo owner

Motivation: Set owner to an active team, to ensure the codebase gets proper maintenance

Semantic release: (Commit conventions)
No new version will be released.
If a release is expected, please fix commit messages to align with appropriate format :arrow_right: Commit conventions


Spruced up ch02.ipynb a bit by adding comments to most of the inputs

Thanks @lkissin2! What are the substantive changes here? It is hard to see from the diffs...

I added comments like
# bad idea to start a variable name with a number
or
 # good way to put a number in a variable name is to have it anywhere but the 0th character
I also wrote notes in chapters 3 and 4 with Markdown, but I haven't PR'd those yet. Is there a certain style guide I should be following?
Thanks!


[WIP] protection for splash:evaljs results

A PR to fix #343.

Current coverage is 85.73%

Merging #358 into master will decrease coverage by -0.07% as of 5ec7e9f

@@            master    #358   diff @@
======================================
  Files           39      39
  Stmts         4644    4647     +3
  Branches       627     628     +1
  Methods          0       0
======================================
- Hit           3985    3984     -1
- Partial        148     150     +2
- Missed         511     513     +2

Review entire Coverage Diff as of 5ec7e9f

Powered by Codecov. Updated on successful CI builds.


Cannot set property className of # which has only a getter

I was able to cause a bug using TypedSvg with Html.Attributes.
in particular, using Html.Attributes.class on a TypedSvg SVG's shape elements went badly.
here's what it looked like:

(additionally, it broke other functionality in my app.)
this code triggered it:
import Html.Attributes exposing (class)
import TypedSvg exposing (circle, path, svg)
import TypedSvg.Attributes exposing (cx, cy, d, fill, r, viewBox)

svg [ viewBox 0 0 24 24 ]
    [ circle [ cx (Px 12), cy (Px 12), r (Px 10), fill backgroundColor, class "primary" ] []
    , path
        [ d data
        , class "secondary"
        , fill foregroundColor
        ]
        []
    ]

removing the class attributes fixed the problem.
off the top of my head, I'm not sure what the solution should be for this bug. but I can see that TypedSvg.Attribute uses elm/virtual-dom attributes under the hood, which is probably why I'm able to throw incorrect attributes onto my SVGs here. so maybe there's a way to articulate within TypedSvg.Attribute which virtual DOM attributes can pass through and which ones need to be re-implemented or restricted in some way.

more context: based on some hints from Stack Overflow, I think HTML uses a className property under the hood, whereas SVG uses a proper class attribute. looks like a relic from the long and quirky evolution of JavaScript and the DOM.

Looking at the code, Html.Attribute.class uses:
https://github.com/elm/html/blob/1.0.0/src/Html/Attributes.elm#L162
stringProperty : String -> String -> Attribute msg
stringProperty key string =
  Elm.Kernel.VirtualDom.property key (Json.string string)

And TypedSvg.Attribute.class uses:
https://github.com/elm-community/typed-svg/blob/7.0.0/src/TypedSvg/Core.elm#L58
attribute : String -> String -> Attribute msg
attribute =
    VirtualDom.attribute

Both define Attribute as an alias onto VirtualDom.Attribute:
type alias Attribute msg = VirtualDom.Attribute msg

So long as TypedSvg is just a set of typed constructors built directly on top of VirtualDom, there isn't really a way to prevent this. TypedSvg would need some kind of intermediate representation to prevent you mixing in Html.Attribute stuff.
Its unfortunate this causes a runtime exception. The best way to fix this might be for VirtualDom to do better checking and ignore invalid attributes. This was also mentioned on the Elm discourse recently: https://discourse.elm-lang.org/t/valid-code-with-runtime-exception/8787
Workaround: User TypedSvg.Attribute.class and not Html.Attribute.class

The distinction between the two different ways of defining the class could also be mentioned in the docs and is something that might be worth adding to this package.


Growing feature of list/table shows wrong total number of records

OpenUI5 version: 1.32.7
Browser/version (+device/version): Chrome 46.0.2490.86 m (Desktop, Windows 7)
Any other tested browsers/devices(OK/FAIL): Firefox 41.0.2 (Desktop, Windows 7): Also fails
URL (minimal example if possible): http://output.jsbin.com/wegoma/1
What is the expected result?
The sap.m.table uses growing=true.
Only 20 records are fetched at one time. The number of already loaded records and the number of total records are displayed in the "More" item at the end of the table.
The total number of records should be constant.
What happens instead?
The indicated total number of records increases by the number of loaded records with every reload of further records.
When page is loaded (20 records initially loaded)

Another 20 records loaded by clicking on more:

Yes, this looks wrong... the count returned by northwind is always
"__count": "830"
So the wrong 870 etc. seems to be calculated inside UI5. It's in ODataListBinding.prototype.getLength(), where this.bLengthFinalis false and therefore this.iLength + iAdditionalLength is returned even though it should have been just iLength.
Possibly the bLengthFinal is wrong, but I can't say why. Opened internal ticket<PHONE_NUMBER> to investigate.
Thanks and regards
Andreas

Any info on when a fix can be expected?

Hi @Frank683 we are looking into this issue also with UX. The suggestion from the UX is not showing the total count since it is unknown. But can u tell me why you need InlineRepat. How about using Inline here? Does the count (may) changes with every request?

Hi @aborjinik I don't understand the suggestion to hide the total count. Why should it be unknown?
I'm using an OData model and the count is not unknown since $inlinecount is requested. Why did I choose InlineRepeat? Since counting doesn't put a real workload on the backend I chose to have the most up to date and accurate figures with every request.
Would it make a difference here with regards to this bug?

Hi Frank thanks for your quick reply. We were trying to understand your use case.
"InlineRepeat", which is meant for data that is known to be changed often (e.g. a blog or live ticker) So before you reach to the end of the list maybe there are new records have been inserted and growing should not stop in this case even though you reach the total count that was known.
Using Inline would make a difference since total count is requested only once while growing. But for sure this does not mean InlineCount should show the wrong total count values.

Ok, now I understand the difference between the two modes.
For my use case "Inline" is sufficient. I tested it and it works fine.
Nevertheless, I don't think that the total count should be removed in the "InlineRepeat" scenario.

Thanks for reporting this issue, we have now adapted the InlineRepeat mode to also show the correct length.

Fixed in https://github.com/SAP/openui5/commit/7761d0bb73273db3f4f221711f48c5d9056bb44d etc. in 1.28 and 1.34+

Header count in smartTable  showing double the threshold value when growing true.
total header count is 53 but showing 40


New Cricket game

Hi,
I was going to do a re-write of HandCricket to make it more of a longer game.
Its going to move from a beginner project to more of an intermediate level.
Do you want me to upload it as a new project or would you rather i develop it separately in my own repo?
Kind Regards
Peter

Can you make changes in the present file and make it more interactive and intermediate level?
File: https://github.com/Mrinank-Bhowmick/python-beginner-projects/blob/main/projects/HandCricket/main.py


Why Puppeteer v13 is missing from "versions.js" ?

Bug description
Hi,
I noticed that Puppeteer v13 is missing from https://github.com/puppeteer/puppeteer/blob/main/versions.js is this intentional? I checked that in v12 release that version.js contained Puppeteer v12.
Puppeteer version
13
Node.js version

npm version

What operating system are you seeing the problem on?
macOS
Relevant log output
No response

I think there were no Chromium rolls included in v13 and therefore it's not listed in versions.js.

Correct.


User notes

Allow either freeform text notes about a user, or maybe just keep it to allowing someone to "rename" a user.
Should this be synced to winchatty? Roaming setting? Local?

Added in 1fadecdb4055f256cca8a3e15e222fe6ce02635d

Added in 1fadecdb4055f256cca8a3e15e222fe6ce02635d


GH-705 Correctly size controls based on editor scale

Fixes #705

Applied to main (=2.1) and branch 2.0.


Add fallback of setting workgroup count to {1, 1, 1}.

When the dispatch has no compute ops, fallback to use a workgroup
count of {1, 1, 1}. The current configuration selection already picks
the CPUDefault pipeline. With this change this will compile
dispatches that dont have compute ops to use a default sequential
lowering.
Fixes #9749

out of curiosity, when would we have a dispatch with no ops? (I think this is probably useful for testing, but I'd be concerned if we are forming no-op dispatches)

hah just saw your comment on the other issue :)

out of curiosity, when would we have a dispatch with no ops? (I think this is probably useful for testing, but I'd be concerned if we are forming no-op dispatches)

Agreed. I am just fixing an error by adding a fallback (defense in depth as you would say). We need a pass to prune out such ops way ahead of time... (See https://github.com/iree-org/iree/issues/9749#issuecomment-1186052672)


opt enable parallel scan for local phase agg

Proposed changes
Issue Number: close #xxx

after we forbid some cases off agg candidate plans,
all local phase agg require DistributionSpecAny for child.
So, we could enable parallel scan for it
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Fix bugs in animationGroup code and use animationGroups in glTF loader

Fixes https://github.com/BabylonJS/Babylon.js/issues/3548
Addresses https://github.com/KhronosGroup/glTF/issues/1179

Is this fix published to a stable release of Babylon yet?  What version will it be in?  Thanks!

It is in our 3.2 preview release (available on npm or here in dist/preview release)


cli exec: let override existing environment values but print a warning

Would this PR allow us to override things like the $HOME environment variable in the kubernetes backend using the standard pipeline config?
This came up in #3123 so I thought it would be worth double checking.

no this is just for the local execution via cli tool

Thanks for the clarification. I'll open a separate issue about env override.


Add Select All / None Checkbox to User Class Picker

Fixes #2585

Nice. I guess it needs a rebuild?

@andrewbaldwin44  Thank you)


Background cut off on mobile

What happened?
baseof.html sets h-screen class on body. On my phone, this has the effect that the background is cut off and the background color changes:

I fixed it on my site by setting the body height to 100%:
body {
    height: 100% !important;
}

Theme version
v2.3.1
Hugo version
hugo v0.101.0+extended linux/amd64
What browsers are you seeing the problem on?
Firefox
Relevant Hugo log output
No response

Thanks for the report, @opncow. I've been trying to replicate this but haven't had any success. It looks like you're using an Android browser and I wonder if that is related. I don't have access to an Android device so it's difficult for me to test.
The fix you have proposed will not support the footer being at the bottom of the viewport on pages which have content that doesn't fill the whole screen.
This is the first report I've received about an issue like this and so I wonder if it's specific to a certain browser version?

Hi @jpanther, thanks for checking. You're right, it's browser-specific. I saw it on Fennec that I use as my only browser on my phone. It never behaved differently than the regular Firefox until now. To check it again, I now installed the regular Firefox and there I cannot reproduce the issue as well. Also Brave shows your page just fine.
Will remove the "fix" from my page again.
Thanks for the great template btw - it's really fun to work with!


Over-classification of wakefulness?

We are getting many (way too many?) epochs classified as wakefulness. We see frequent jumps from N3 or N2 to W, which doesn't seem right.
Have you previously encountered a problem of over-classification of wakefulness with yasa? If not, do you have any suggestion on were could we be having an error?
This is an example of our results for one night of sleep:

Hi @catalinasaini,
I have not seen this issue before, but my first guess is that it is related to the amplitude of your data and/or a noisy channel. Can you answer the following questions?

Which channel are you using?
What is the sampling frequency of your data?
Which PSG device does the data come from?
Have you visually checked the data before running the algo?
Is the data of "standard" amplitude (e.g. slow wavess are clearly visible and have >75 uV amplitude)? Some wearable PSG devices do not have the same amplitude as traditional PSG system, and thus won't work well with YASA.
Does the data come from a healthy individual or someone with sleep disorder?
What is the age of the individual?

Thanks,
Raphael

Hello again! We took time to inspect the data in detail and do some extra preprocessing.
• Which channel are you using? – This system only has one EEG channel that is located in the FPZ position.
• What is the sampling frequency of your data? - 256 Hz.
• Which PSG device does the data come from? – The device we use is the Sleep Profiler PSG2 device, a portable wearable device.
• Have you visually checked the data before running the algo? – Yes. It's noisy, but if we ignore the epochs that contain artifacts, the sleep scoring keeps predicting wakefulness most of the time.
When we do PSD we can notice multiple recordings have a peak of 20Hz which looks non-physiological. Unfortunately, we saw that we are not able to modify or filter the data before running the sleep staging classification from YASA. Is there a way in which we can do that? We hypothesize that it classifies a lot of epochs as wakefulness because of this peak that coincides with the beta frequency-range
• Is the data of "standard" amplitude (e.g. slow waves are clearly visible and have >75 uV amplitude)? -- Yes, after artifact removal.
• Does the data come from a healthy individual or someone with a sleep disorder? – Not all are healthy individuals, some are cancer survivors and some have sleep apnea. Note that we are seeing these overclassification in all of them.
• What is the age of the individual? -- We don’t have the exact age range, but they are all adults, not old.
Thanks,
Cata

Hi @catalinasaini,
You can remove the 20 Hz noise with a notch filter:
raw.notch_filter(20)
yasa.SleepStaging(...)

One thing to keep in mind is that YASA was trained using central electrodes (referenced to mastoids) from in-lab polysomnography, so I think that your data (Fpz, portable wearable device) may be too dissimilar from the training dataset of YASA. I would recommend using the U-Sleep algorithm, which may give better performance than YASA because it is based on deep learning.

Thank you for your help. We will try with the U-sleep algorithm and also try applying the filter at 20Hz.


Menu bar not working when fragmentation is running

An effect Kohulan encountered when tunneling MORTAR from a Linux server on a Mac. Investigate!

Is this really a MORTAR error or is it because the GUI is tunneled from the server to the desktop?

Most likely and hopefully the latter. But I need to look into this. Hence the "Investigate!" 😄

I have imported 1000 molecules and set the Scaffold Generator Fragmenter's "fragmentation type setting" to "all sub-scaffolds", so that the fragmentation takes a long time. I could not reproduce the problem reported here, everything worked as expected, I could access all functionalities of the application. So I'm going to close this issue.


onBeforeAction should run first, before waitOn is called

The expected behaviour for onBeforeAction is that it is run before a route is actioned, however, since 1.0.0, in the case where a waitOn function exists, the onBeforeAction function is not called until the waitOn function returns ready. In the classic case of checking for logged in status, this could be misleading and lead to content being wrongly published.

$ git clone https://github.com/oliverlloyd/waitOn_issue
Navigate to http://localhost:3000/login
Click link
In console, type: Posts.find()

In the demo given, although you are not logged in, a subscription has been created and you can access data. True, I can (and should) make sure that I don't publish content unless a user is logged in which would prevent this but I think that the default should be reversed here, if I'm not logged in it should not try to subscribe.

Just ran in to the same issue with my project. Going to use the onRun/onRerun workaround. Hopefully this will get sorted out.

@stephentcannon i like your solution to us Router.onRun(callback) and Router.onRerun(callback) .
but now that i am using it. now this is not working.
Router.configure({
   waitOn: function () {
      // this doesnt get called anymore?
      return Meteor.subscribe('recordSetThatYouNeedNoMatterWhat');
    }
});

If you don't want to add the check for the userId in every single method as @cmather suggested, you can just make a wrapper function and use it instead of Meteor.publish:
function publish(name, callback) {
	Meteor.publish(name, function() {
		if (!this.userId) {
			return this.ready();
		}

		var bound = _.bind(callback, this);
		return bound.apply(this, arguments);
	});
}

Just want to reiterate what @oliverlloyd said, waitOn (whether intentionally or otherwise) definitely must be ready before onBeforeAction will run. Perhaps even more confusing is that onAfterAction will run without ready() returning true.

I did some investigation into why waitOn appears to block onBeforeAction, and the explanation couldn't be much simpler.  waitOn triggers the loading plugin, which inserts Iron.Router.hooks.loading at the beginning of the action stack (route_controller_client.js:226).
Well, wouldn't you know it, Iron.Router.hooks.loading doesn't call this.next(), so the action stack is held up (and throws an annoying dispatch warning) while the onRun, onRerun, and onAfterAction hooks continue to run.
I think the most obvious solution here is that Iron.Router.hooks.loading should call this.next() in order to maintain proper ordering, but I also think we need to revisit what the design goal is for all of these various hooks.  Are we trying to prevent unnecessary processing (yes please!) -- if so, we should have more blocking, not less.  Maybe we should start such a discussion in a different thread?
I'm happy to contribute some of my time if it would be helpful.

@oliverlloyd damn can't find to send message or email on your github ;(
I'm totally agree with his opinion even I agree with @cmather 's idea as well.
BTW recently I updated my such a huge 0.9.6 Meteor Project to 1.1.3 and IronRouter was updated too.
I crashed this problem because I used to initial some conditions including 'wait on parameter for sub'.
On this pattern changed, actually my app was totally broken cause waitOn is called before onBeforeAction by the way, so I migrated almost all iron router life cycles to Blaze one.
I know @cmather 's pattern could be powerful, BUT, I'm for sure that every application need to be initial their data before do something, importantly, onRun is called only one time when the route called, and this is not called when hot code deployed or template re-rendered by any reasons.
This was perfect place to initial all data.
So my question is this. Which hook could I initial data only one time without making any annoying codes such as running only one time at the top of the waiting things??

@benmgreene i think you're on to something here


Remove @alexandraj777 from Feedstock maintainers

Removing myself, since I haven't been at SigOpt for a while 😄
I'm getting some automated emails to join the conda-forge organization - will removing myself from here stop the automated emails?
Thanks!

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Don't show messages global with path

With this change messages at the editor top will only be shown if they have no path.

No longer an up and down while writing something in an input and the message changes (was while the demo)
Should be a hint that a message from the backend has no path set
IMO those are no longer needed, because if they have a path they should be shown on the

accordion
widget (input, etc)

I also discussed this yesterday with pascal.
What do you think @weissreto?
Before:

After:

What do you mean with read only mode?
Do you mean when the project is packed (iar)?
I think it makes no difference because also in readonly mode the widget will be shown as they are with a message if they have one...
What we may can think about is, if we want do display the messages on the summary content if we implement those.

No, I mean if you open the inscription view and you are in the reader mode and not the edit mode. Then the errors should be visible somewhere. I think this is a task for Anais to think about where to display them in this mode.

Ah, when the accordions are closed?
Yes of course, as I said, I think they should be displayed somewhere in the summary part...
But currently, at least the accordion shows with the state if it has an error in it.


Automatic Wrangling Status Update after project making it life in the browser not working as expected

At least in 2 instances I can see projects that were exported to DCP for Release 26, and have already made it life to the Browser, but where the wrangling status has remained as "Submitted". As this is also linked to the DCP link showing in the Catalog, we are also missing that.
The projects where I've seen this are the following:
https://contribute.data.humancellatlas.org/projects/detail?uuid=f3825dfe-990a-431f-b971-9c26d39840db&tab=project
https://contribute.data.humancellatlas.org/projects/detail?uuid=c281ab63-7b7d-4bdf-b761-9b1baaa18f82&tab=project
Older project in the same situation:
https://contribute.data.humancellatlas.org/projects/detail?uuid=a1375150-dda4-4081-8318-c1593622da55&tab=project
Instances with projects in Submitted status (they are published in DCP already) but Graph invalid submissions:
https://contribute.data.humancellatlas.org/projects/detail?uuid=65858543-530d-48a6-a670-f972b34dfe10&tab=project
https://contribute.data.humancellatlas.org/projects/detail?uuid=34cba5e9-ecb1-4d81-bf08-48987cd63073&tab=project

The 1st two entries, are now resolved. It looks as if there is some sort of delay. Maybe worth adding a bug ticket to investigate at some point.

The last two are two datasets originally wrangled by Tiana Pereira (UCSC)

I am keeping this for the older project and the ones with graph invalid submissions. But I have created a Dev bug for the issue that originally made me open/create this ticket in the first place. I'll link here

https://app.zenhub.com/workspaces/dcp-ingest-product-development-5f71ca62a3cb47326bdc1b5c/issues/gh/ebi-ait/dcp-ingest-central/957

working on #1220 should address this issue as well


Ctrie Iterator

Adds Iterator, Size, and Clear operations to the Ctrie. Also adds a Map function to the persistent list.
@dustinhiatt-wf @alexandercampbell-wf @stevenosborne-wf @beaulyddon-wf @rosshendrickson-wf @tannermiller-wf

Think I found a decent compromise on the iterator nonsense @dustinhiatt-wf @alexandercampbell-wf. See last commit.

lol. The rule of Go.... when all else fails just add another channel.
+1

+1, but I can't say I really like introducing another channel.

I can merge this, but I have to agree with @alexandercampbell-wf, I'd much prefer to use a stateful iterator instead of leaving it up to the consumer to ensure memory isn't leaked.  Especially for people coming from other languages, the duty of having to create a channel and then cancel is a burden people probably aren't used to for a simple iteration.
@tylertreat, I'll merge as is if you want, but I'm just worried people will just forget to cancel or pass in nil and this thing will leak memory.  Up to you.

The stateful iterator will be surprisinglu nasty with this type of trie.


Completely zooming in and out causes font to slightly blur

This should probably be very low prio, it probably doesn't happen often.
It's also fixed by restarting visual code.
This is what it looks like default:

Now press ctrl++ x 9 times to completely zoom in
Now press ctrl+- x 9 times to completely zoom out
The font now seems blurred

This is on Windows 8.1

Great product btw, I really enjoy using it!

I am probably screwed, since I percieve the VS Code's font blurry even in the default state, aren't I? Will this be fixed? The font is just not enough sharp as it is.

@smuuf can you compare with 0.9.x release of VS code? I dont see blurriness on my Windows machine in code. Maybe you are still zoomed in?

Unfortunately I can't compare it with any older version. I installed it today and fiddled a bit with for a bit, until the font's bluriness became too much of a displeasure. (on Win 7)
The question that I really want to ask here is this:

This picture (the top one from the original post) - is this how the font should look like? Because it looks too blurry for me, too. Less than in the second one, but still.

@smuuf Are you looking at the image with 100% zoom in a separate tab, so that it's displayed with 1:1 pixel ratio?
https://cloud.githubusercontent.com/assets/4998498/11274683/3350697c-8eda-11e5-8797-806278ef6e93.png
If you're looking at it in this issue, keep in mind it's scaled down via CSS because its full width doesn't fit into the width of the conversation.

We pushed a major update to the UI framework to our insiders release and would appreciate feedback if this issue got resolved. You can give it a try from our insiders release today: http://code.visualstudio.com/Download#insiders
Happy for feedback!

Fixed (for the case when zooming with ctrl+= or ctrl+- or via window.zoomLevel) with 289370f2f335eeb2cd8b74cd8f20101d1ed3335a

@alexandrudima Does that mean window zoom level no longer needs to be restricted to 100% and higher (i.e., you can't zoom below 100% with Cmd+-)?

I think Cmd+- does not go below 100%, but window.zoomLevel: -1 worked for me when doing it from user settings.

I think Cmd+- does not go below 100%

I believe that was implemented because of the blurring issue (see comment by @bpasero):

We chose to not allow for zooming below 0 because some people end up in this state and wonder why the UI looks blurry.

Now that it's fixed, can't that restriction be lifted?
In other words, isn't forcing user to use window.zoomLevel instead of just Cmd+- to go below 100% no longer neccessary?

I am easy to change this so that you can also zoom out.

@joaomoreno You can verify by inspecting that we don't use translate3d on the dom nodes (easiest to spot is the editor scrollbar) when zoomed out or zoomed in.


Reimplement useRecognizers with useMemo

You can follow commit by commit to track changes

Use ES6 default values syntax in config.ts
Define DEFAULT_SWIPE_VELOCITY and DEFAULT_SWIPE_DISTANCE (magic numbers otherwise)
reimplement useRecognizers using useMemo: simpler code and less hooks involved

Thanks a million @thephoenixofthevoid, no one had looked into the code that deep I hope it isn't too ugly. I'm new to TypeScript and don't have any professional experience with React so there might be clumsy workarounds.
I've looked at your commits and they all look great, useRecognizer never felt right and I love the way you fixed it.
Is there any reason why you're using let vs const in config.ts? I know there's two sides on the matter, I don't have any strong opinion on it.

Just to be consistent among functions: in one function there is a need to change value, so it's impossible to use const in that case. Anyway they all turn into "var"s in the resulting code that will actually run.
I hadn't spent much time on that file yet, trying to avoid placing too many changes into a single PR. In the end, it's safer to use const everywhere, but some refactoring needs to be done to archive that.

No worries. Can I merge the PR or do you have more commits planned at this stage?

Yes. I will create a new PR for next changes.


Use latest Chronos docker container

please take a look at your earliest convenience @jsancio or @ConnorDoyle

Note, this also needs to be merged into EA2.

Hm, not sure why this is so slow running the build. Going to close and reopen.


Adverse Event Workflow

Matt will bundle recent Adverse Events into the prefetch. CQL will suggest contacting care team and ask the patient whether or not they have. A "Yes" will be saved by the app and this additional info will also be bundled into the prefetch in some form. The patient will then receive a different recommendation if they have already indicated they contacted the care team. Need to iron out several details on this.

AdverseEventWorkflow_proposal.pdf

AdverseEventWorkflow_proposal.pdf


Add SignatureError

Adds a SignatureError that is raised when the passed config and arguments do not match the signature of a captured function. It inherits from TypeError, so any check for this still works and is consistent with Python errors.
Also adds more advanced options for filter_traceback that allow SacredErrors to always (except for debugging) suppress sacred internal stacktrace, even if the Exception was raised from within sacred. This now applies to the new SignatureError that is raised from within sacred, but the point of interest is the calling function.

Coverage increased (+0.02%) to 83.622% when pulling 45808eab803bfa5f4822b6409ee55482f0dea938 on thequilo:improved-error-messages/signature-error into 94785b9592b16e8498212ad9cfa0e05d49a1819d on IDSIA:master.

I changed format_filtered_stacktrace according to your suggestions. Now, a ValueError is raised when a wrong argument is passed.

LGTM, thanks!


Read browserslist if available

As noted in #271.
The default targets is IE9 but my project targets IE11 and above and I would like to see all the var declarations disappear and only have let and const (which is supported by IE11).
I'm looking for a work-around but the ideal nuxt behaviour would be to read the browserslist just like PostCSS/Less etc does.

If I change nuxt.config.j as documented, it doesn't appear to have any effect.
module.exports = {
  build: {
    babel: {
        presets: ['env', {
          'targets': {
            'browsers': ["last 2 versions", "not IE < 11"]
          }
        }]
      }
  }
}

An error message still reveal:
~/assets/js/shared/utils22 in ./node_modules/babel-loader/lib?{"babelrc":false,"cacheDirectory":true,"presets":[["/Users/nappdev/projects/webvie
wer4/node_modules/babel-preset-vue-app/dist/index.common.js",{"targets":{"ie":9,"uglify":true}}]]}

I had build twice in my config object and the preset is suppose to look like this:
module.exports = {
  build: {
    babel: {
      presets: [['vue-app', {
        targets: {
          browsers: (console.log(projectPackage.browserslist), projectPackage.browserslist)
        }
      }]]
    }
  }
}

Many many thanks to @qm3ster for helping me out!


resin-yocto-scripts: Switch this submodule to balena-yocto-scripts

Changelog-entry: Switch from resin-yocto-scripts to balena-yocto-scripts
Signed-off-by: Florin Sarbu<EMAIL_ADDRESS>

@resin-jenkins test this please

@resin-jenkins test this please

@resin-jenkins test this please


Set limits on building Docker containers

So we don't actually overload machines by building containers that are way too large.

@yuvipanda at this point we implement ram/cpu limits, and we're working on network limits, yes? In this issue were you also referring to hard disk size of images? If not, I think we can close this

Nope, we don't set any limits for the build process yet. Only for the
running notebook processes, so this still needs to happen.
On Tue, Nov 28, 2017 at 3:06 PM, Chris Holdgraf<EMAIL_ADDRESS>wrote:

@yuvipanda https://github.com/yuvipanda at this point we implement
ram/cpu limits, and we're working on network limits, yes? In this issue
were you also referring to hard disk size of images? If not, I think we can
close this
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/binderhub/issues/3#issuecomment-347694552,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23kDMWNbI3R6WKa0ISGqJL9WnBVt2ks5s7JHygaJpZM4NS6bM
.

--
Yuvi Panda T
http://yuvi.in/blog


Installation in zsh fails

Expected Behaviour:

Adding the lines from the README.md under https://github.com/artempyanykh/shellmark#integration-with-shell to ~/.zshrc works

Observed behaviour:

For simplicity I ran the command in zsh:

if type shellmark &>/dev/null; then
    eval "$(shellmark --out posix plug)"
fi

zsh: parse error near `}'

This happens reproduceable also when the command is copied into ~/.zshrc and is then loaded via source ~/.zshrc.
System Information:
shellmark --version
shellmark 0.1.1
zsh --version
zsh 5.8.1 (x86_64-apple-darwin21.0)

Hi @hemeroc ! Thanks for giving shellmark a go. I tried to repro (both on Mac and Linux) but couldn't.
I'm curious, what output shellmark --out posix plug gives you?
Also, what's the output of type s?

Update: I could repro after I installed shellmark via cargo install shellmark rather than from source.

Hi @artempyanykh, thank you very much for the fast response.
Yes the new version fixed it! Thanks a lot ❤ keep up the great work!


Check the variables in the RelayPrioritizer

During the switch to HTTPS, (the current plan is that) we're going to switch to picking a first hop as usual with the RelayPrioritizer, but then want to pick an exit separately using the first hop's bandwidth as a factor. We will no longer be measuring one relay at a time, and we will be getting results two at a time.
We'll be getting results for relays that the relay prioritizer hasn't returned (yet). And it won't be able to update it's idea of relay priority until it has worked all the way through its current list of relays to return.
This means we might want to make it recalculate best priority more often.

I'm currently running with settings that essentially make it return 100 relays at a time.
It seems to take about 2 minutes to do its thing. I should check how often it has to calculate priority again when only returning 100 relays.

This is not the case anymore, every prioritizer loop returns around 300 relays, and we still consider one result at a time, since results are build without checking the fingerprint in the circuits.
Closed in favor of #29719 and #29720.This is not the case anymore, every prioritizer loop is


Is it possible to use all of the tsparticle options here?

I would love to create this gravity effect with custom shapes (https://codepen.io/matteobruni/pen/mdPmpxB) however, it doesnt seem this library allows me to set this option?
Am I able to use all the tsparticle options in this react component?
Thank you!

Hi @JPiao,
Those features are currently in beta and will be released soon


remove array extracting

This gets rid of 5 bytes in the bundle (I think). I'm not sure how expensive accessing [0] and [1] a few times is, compared to additional initialization to 0 and an if statement.
Note that previously if was executed all the time, and these accesses are happening only when the conditions are satisfied.

This gets rid of 5 bytes in the bundle (I think).

I run
yarn run build; zopfli --i2000 dist/hyperapp.js > dist/hyperapp.js.gz; size dist/hyperapp.js.gz

when golfing.

@lazarljubenovic

That makes it from 3605 to 3600, raw; and 1636 to 1625, gzipped. I used stat as size complains that "file format is not recognized" for the .js.gz file. :confused:
What do you think about this change, performance-wise?

@lazarljubenovic Not sure, (probably/hope there's no difference) but I'll definitely run the benchmarks for this one and see.

@lazarljubenovic Performance-wize there should be no difference as a gvn pass will simply create a temporary variable under the hood.
GVN: https://www.wikiwand.com/en/Global_value_numbering

Thanks @lazarljubenovic!


[1528] Fix intermittent asset failure in specs

Resolves #1528

Mock relative root in application helper specs

Looks great, just rebase onto the latest master and we can merge after a green build. Fantastic job!

should be good to go!

@esoterik merged!


chore: update node-wot packages to 0.8.1

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

3 of 6 (50.0%)  changed or added relevant lines in 1 file are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.7%) to 63.347%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

nodes/wot-scripting.js
3
6
50.0%

Files with Coverage Reduction
New Missed Lines
%

nodes/wot-discovery.js
4
65.03%

Totals

Change from base Build<PHONE_NUMBER>:
-0.7%

Covered Lines:
216

Relevant Lines:
319

💛  - Coveralls


Detailed ACL Feature missing (simple feature)

Hi
First, i would like to Thank the authors for their efforts for making this firmware.
the issue is this:
my Network IPs is: <IP_ADDRESS>/24
and when using the ESP8266 with your Firmware, it uses: <IP_ADDRESS>/24
What i tried to achieve is to prevent people who are accessing the internet through ESP8266 with ip <IP_ADDRESS>/24 to access any local device in my real network <IP_ADDRESS>/24
i just want them to be allowed to access the internet
so i though about it, i used your ACL documentation, i came up with these rules
acl from_sta TCP any any <IP_ADDRESS>/24 any deny
acl from_sta UDP any any <IP_ADDRESS>/24 any deny
acl from_sta IP any <IP_ADDRESS>/24 deny

it worked, but also internet is blocked with these rules! :(
but since accessing internet requires <IP_ADDRESS> (my main internet provider router)
after clearing rules with:
acl from_sta clear
i thought about modifying the rules to this:
acl from_sta TCP any any <IP_ADDRESS>/24 any deny
acl from_sta UDP any any <IP_ADDRESS>/24 any deny
acl from_sta IP any <IP_ADDRESS>/24 deny

so it should ignore the <IP_ADDRESS> and <IP_ADDRESS> IPs
but the problem is: after writing the above rules,
it still configures as <IP_ADDRESS>/24 not <IP_ADDRESS>/24
show acl
TCP any:any <IP_ADDRESS>/24:any deny (5 hits)
UDP any:any <IP_ADDRESS>/24:any deny (17 hits)
IP any <IP_ADDRESS>/24 deny (0 hits)

Any help would be appreciated
Thank you.

Try the following:
acl from_sta clear
acl from_sta UDP any any any 53 allow
acl from_sta IP any <IP_ADDRESS>/24 deny


Xnero: Watch thehotcontent.com

Xnero requests the watch of the watch_keyword thehotcontent\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

thehotcontent\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Ryan M in Charcoal HQ


Issue with Mist Privileged Helper Tool Still Prompting “Not Installed” After Installation

Hello everyone, I want to share a problem I encountered while using the Mist application, hoping to help friends who are also troubled by this.
After installing the Mist application, I installed the Mist Privileged Helper Tool as prompted. However, when I tried to use features that require administrator privileges, the system still prompted me with “Privileged Helper Tool not installed!”. This left me very confused because I had clearly installed the Helper Tool as required.
I  tried the following solutions, but none of them worked:
Completely close the Mist application and then reopen it.
Reinstall the Mist Privileged Helper Tool.
Check system settings to ensure that the Mist application has sufficient permissions.
Despite trying all possible solutions, the problem still persists. This leaves me feeling very frustrated and helpless.
If anyone has encountered a similar problem and found a solution, I hope you can share it in the comments below. Your help would be greatly appreciated.

Duplicate of https://github.com/ninxsoft/Mist/issues/69

Closing due to being a duplicate of #69, let's keep the conversation going there 👍


[SPARK-35696][PYTHON][DOCS][FOLLOW-UP] Fix underline for title in FAQ to remove warnings.

What changes were proposed in this pull request?
This PR follow-up for SPARK-35696 to fix incorrect underline in the documents to remove warnings.
Why are the changes needed?
We should build the docs without any incorrect documentation style
Does this PR introduce any user-facing change?
No
How was this patch tested?
Manually build docs and see the warning is removed

I manually tested.
Merged to master.


producing a ghost consumer at frequently start and stop consumers in one process

In production practice，There is a situation that is starting many diffent consumers and using web controls consumers restarting and stoping at the same time in one running process.
then I noticed a problem one day after stoping and starting consumers using web，There was a consumer who reconsume messages a few days ago.
What is the purpose of the change
fix issue below:
producing a ghost consumer at frequently start and stop consumers in the same process，who can not consume message，but can pull messages and submit the same consume offset.

Coverage increased (+0.09%) to 51.284% when pulling 06930390b4d8ac517a4365bb4b09ecb35588fff1 on lwclover:release-4.7.1 into 9f95a972e10e0681bc3f2d00e9957aa212e897b5 on apache:release-4.7.1.

Codecov Report

Merging #3040 (0693039) into release-4.7.1 (9f95a97) will decrease coverage by 0.24%.
The diff coverage is 100.00%.

@@                 Coverage Diff                 @@
##             release-4.7.1    #3040      +/-   ##
===================================================
- Coverage            45.69%   45.45%   -0.25%
+ Complexity            4271     4249      -22
===================================================
  Files                  546      546
  Lines                35860    35860
  Branches              4763     4763
===================================================
- Hits                 16388    16301      -87
- Misses               17429    17507      +78
- Partials              2043     2052       +9

Impacted Files
Coverage Δ

...rocketmq/client/impl/factory/MQClientInstance.java
47.41% <100.00%> (-0.60%)
:arrow_down:

...e/rocketmq/client/impl/consumer/RebalanceImpl.java
46.61% <0.00%> (-9.17%)
:arrow_down:

...org/apache/rocketmq/common/stats/StatsItemSet.java
41.79% <0.00%> (-8.96%)
:arrow_down:

...ketmq/client/impl/consumer/PullMessageService.java
71.11% <0.00%> (-8.89%)
:arrow_down:

...in/java/org/apache/rocketmq/test/util/MQAdmin.java
38.88% <0.00%> (-5.56%)
:arrow_down:

...ain/java/org/apache/rocketmq/test/util/MQWait.java
43.24% <0.00%> (-5.41%)
:arrow_down:

...ache/rocketmq/common/stats/MomentStatsItemSet.java
39.13% <0.00%> (-4.35%)
:arrow_down:

...ava/org/apache/rocketmq/test/util/VerifyUtils.java
46.26% <0.00%> (-2.99%)
:arrow_down:

...nt/impl/consumer/ConsumeMessageOrderlyService.java
42.59% <0.00%> (-2.89%)
:arrow_down:

...he/rocketmq/client/impl/consumer/ProcessQueue.java
60.00% <0.00%> (-2.80%)
:arrow_down:

... and 11 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 9f95a97...0693039. Read the comment docs.

Submit to develop branch. Please walk to pull request #3120

registerProducer & unregisterProducer possible requires  synchronization too, how about add for producer ? @lwclover

registerProducer & unregisterProducer possible requires synchronization too, how about add for producer ? @lwclover

OK.I will submit it when I have free time.


Laravel Dusk version 5

Laravel Dusk is now at v5, so when I try and install I get
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for laravel/dusk (locked at v5.0.0, required as ^5.0) -> satisfiable by laravel/dusk[v5.0.0].
    - beyondcode/dusk-dashboard 1.0.0 requires laravel/dusk ^4.0 -> satisfiable by laravel/dusk[4.0.x-dev].
    - beyondcode/dusk-dashboard 1.0.1 requires laravel/dusk ^4.0 -> satisfiable by laravel/dusk[4.0.x-dev].
    - beyondcode/dusk-dashboard 1.0.2 requires laravel/dusk ^4.0 -> satisfiable by laravel/dusk[4.0.x-dev].
    - beyondcode/dusk-dashboard 1.0.3 requires laravel/dusk ^4.0 -> satisfiable by laravel/dusk[4.0.x-dev].
    - Conclusion: don't install laravel/dusk 4.0.x-dev
    - Installation request for beyondcode/dusk-dashboard ^1.0 -> satisfiable by beyondcode/dusk-dashboard[1.0.0, 1.0.1, 1.0.2, 1.0.3].

i have same issue

same here

@mpociot can you check this.
i have same issue here.

Me too. Any chance this will get an update to support Dusk 5 @mpociot ?


Suggestion: add zoom in and zoom out overlay to map

this could be realized via "+" and  "-" symbols or some sort of magnifying glass at the left or right border of the map.

Hi,
Thanks. I'll consider adding it in the future.
Patrik

Hi,
I've added this feature with the latest commit. It will be part of the release (1.7)
P


Building package curl:x64-windows failed with: BUILD_FAILED

Package: curl:x64-windows
Vcpkg version: 2018.11.23-nohash
here is the errro I get when trying to install CUrl
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:56 (message):
Command failed: ninja;-v
Working Directory: C:/Program Files/vcpkg/buildtrees/curl/x64-windows-rel/vcpkg-parallel-configure
Error code: 1
See logs for more information:
C:\Program Files\vcpkg\buildtrees\curl\config-x64-windows-out.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_configure_cmake.cmake:273 (vcpkg_execute_required_process)
ports/curl/portfile.cmake:90 (vcpkg_configure_cmake)
scripts/ports.cmake:71 (include)
Error: Building package curl:x64-windows failed with: BUILD_FAILED

Error message in the logs say it cant find the CoreFoundation Framework
-- Found Perl: C:/Program Files/vcpkg/downloads/tools/perl/perl/bin/perl.exe (found version "5.24.1")
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE
-- Looking for getch in ws2_32;
-- Looking for getch in ws2_32; - found
-- Looking for getch in winmm;ws2_32
-- Looking for getch in winmm;ws2_32 - found
CMake Error at CMakeLists.txt:336 (message):
CoreFoundation framework not found
-- Configuring incomplete, errors occurred!
See also "C:/Program Files/vcpkg/buildtrees/curl/x64-windows-rel/CMakeFiles/CMakeOutput.log".
See also "C:/Program Files/vcpkg/buildtrees/curl/x64-windows-rel/CMakeFiles/CMakeError.log".
ninja: build stopped: subcommand failed.

Looing at the CMkaeErrorLog.txt it says it can find pthread.h
CheckIncludeFile.c(1): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory ninja: build stopped: subcommand failed.
I see that commit #4081 addressed this however even using the latest version I am still having this issue

Hi @EricPrits, does the issue still occur? I installed it successfully with Visual Studio 2017 and VCPKG latest source.
PS F:\test\vcpkg> .\vcpkg.exe install curl:x64-windows
The following packages are already installed:
curl[core,ssl,winssl]:x64-windows
Starting package 1/1: curl:x64-windows
Package curl:x64-windows is already installed
Elapsed time for package curl:x64-windows: 1.631 ms
Total elapsed time: 1.727 ms
The package curl is compatible with built-in CMake targets:
find_package(CURL REQUIRED)
target_link_libraries(main PRIVATE ${CURL_LIBRARIES})
target_include_directories(main PRIVATE ${CURL_INCLUDE_DIRS})

Yes the issue is now resolved, the cause was using the command:
vcpkg install curl[*]:x64-windows
When I specified the specific packages it worked

I am experiencing the same error here working on visual studio code, was your command something like this:
vcpkg install curl[core,non-http,schannel,ssl,sspi]:x64-windows

I am experiencing the same error here working on visual studio code, was your command something like this:
vcpkg install curl[core,non-http,schannel,ssl,sspi]:x64-windows

@baykac7 How do you know it is the same error? It is not the same curl and vcpkg, two years later. Better open a new issue.


Fallback to defaults in adstock|saturation_from_dict

Description

Related Issue

[x] Closes #950
[ ] Related to #

Checklist

[x] Checked that the pre-commit linting/style checks pass
[x] Included tests that prove the fix is effective or that the new feature works
[ ] Added necessary documentation (docstrings and/or example notebooks)
[ ] If you are a pro: each commit corresponds to a relevant logical change

Modules affected

[x] MMM
[ ] CLV

Type of change

[ ] New feature / enhancement
[ ] Bug fix
[ ] Documentation
[x] Maintenance
[ ] Other (please specify):

📚 Documentation preview 📚: https://pymc-marketing--955.org.readthedocs.build/en/955/

Hey, sorry that I had to open 3 separate PRs for the same functionality.
Working on a fork is not as flexible sometimes.
This PR should be good to review

Hey, sorry that I had to open 3 separate PRs for the same functionality. Working on a fork is not as flexible sometimes.
This PR should be good to review

All good! Thanks for taking the issue!

pre-commit.ci autofix

Thanks @PabloRoque !


Support for priority mempool chains

Summary
Starting with tm v0.34.20 we may see cosmos-sdk chains using priority enabled mempool. We need to make sure we support these chains.

Problem Definition
Here is my understanding about how prio mempool will be used from hermes pov.
Let’s say hermes submits 2 Tx-es, tx1 and tx2, with incrementing nonces, using broadcast_tx_sync. The application runs checkTx for each of them and returns an abci.ResponseCheckTx that includes a priority. The prio mempool then stores this and when it’s time to create a block it picks Tx-es in priority order.
In sdk chains, during checkTx, the priority is set by a TxFeeChecker and the default is defined in the auth module: https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/ante/validator_tx_fee.go.
In this case the priority is computed based on the Tx fee. Different apps/chains will have the ability to overwrite this handler.
But staying with the default behavior for now, it is possible  that tx2 will be included in a block before tx1, so deliverTx(tx2) will be executed first and will fail with account sequence mismatch.  tx1 will be successful.
If we try to use multiple wallets to go around the account sequence mismatch we will still see issues, e.g.:

tx2 may be rejected if tx1 includes a client update needed for msgs in tx2, or
the msgs in the tx-es are for ordered channels.

While we push for a solution in tendermint or SDK  (e.g. to not reorder Tx-es from same account or allow out of order execution during deliverTx), we should remove our assumption that Tx-es are executed in order,  figure out all the cases where we are exposed to this and how to handle them.
For the examples above, include update client in every tx (see also #2191), don’t send multiple Tx-es for ordered channels in same block (i.e. wait for tx1 hash to show up in a block before sending tx2), etc.

Acceptance Criteria
hermes works with prio mempool chains

[x] depends on #2455
[ ] update compatibility.rs to mark compat w/ sdk 0.46

https://github.com/informalsystems/ibc-rs/blob/5df35478607452baa8db004efb1d7aa38dfd8d89/relayer/src/chain/cosmos/compatibility.rs#L8-L23

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate milestone (priority) applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

An update on this:

I've released tendermint-rs v0.23.8-pre.1 to cater for the backported prioritized mempool released in Tendermint v0.34.20-rc0: https://github.com/informalsystems/tendermint-rs/releases/tag/v0.23.8-pre.1 (basically just adds 3 fields to the CheckTx result that are only relevant if the prioritized mempool is enabled). See https://github.com/informalsystems/tendermint-rs/issues/1148 for more details.

The Tendermint team's working on fixing a bug in the prioritized mempool at the moment: https://github.com/tendermint/tendermint/issues/8775
Once that's resolved, they'll cut another RC, do some more extensive testing with the SDK, and then finally cut a v0.34.20 release. Once that's out, the SDK team is keen to roll that out ASAP.

Notes from today's meeting:
Issues raised

There is a size overflow problem in cosmos/batch.rs: the batch is allowed to grow past the limit by the length of one message. Not related to prio mempool, but needs to be fixed just the same, as this causes the tx to fail due to fee miscalculation.

Moving the batching logic to the worker:

Max size checking also needs to be moved, in addition to the solution
in https://github.com/informalsystems/ibc-rs/issues/2191#issuecomment-1121015059
Need to do this with the full encoding of SignedTx (when batching for Cosmos chains), can't with just Vec<Any>.

Solutions proposed

Add method to the chain trait to evaluate tx size from the Vec<Any>. The worker will use this method in the batching logic.
The worker should be solely responsible for forming tx batches and inserting client updates.

Here is a summary from recent discussions:
Interaction with account sequence in Cosmos SDK

At the moment it is unclear how the prioritized mempool would interact with the nonce mechanism in Cosmos SDK.
For example:

Given tx1 and tx2 are in the mempool at the same time with account sequences N and N+1, with the current nonce being N.
If tx2 has higher priority than tx1, then tx2 will get processed first. But the transaction will fail because of nonce mismatch.
A possible fix is to allow for the use of any nonce greater than or equal to the current nonce.
But if tx2 is accepted, then tx1 would still fail with account sequence mismatch error.

As a result, it is never safe to have two transactions by the same sender in the mempool at any time.
A possible workaround is to require ABCI applications like Cosmos SDK to always give higher priority to transactions with lower account sequence.

But it is uncertain how this can work in a stateless manner, unless a fully application-specific mempool is implemented.

Sender-specific limitation on Tendermint

Tendermint v0.34.20 will allow only one transaction per sender in the mempool at any time.
The sender is determined by a Tendermint-specific sender field inside the transaction.
However, Cosmos SDK do not currently set the sender field to any value, i.e. the sender is always "".
Tendermint handles a special case of allowing unlimited transactions in the mempool when the sender value is "".
Therefore, there is currently no limit of how many transactions per wallet can be in the mempool at the same time.
However, it is unclear whether Cosmos SDK will set the sender field in the future.
It is also unclear if there is any other non-SDK ABCI applications that make use of the sender field.

Strategies for IBC Relayers

With the introduction of prioritized mempool, it does not seem to be safe for the relayer to submit more than one transactions in parallel to the mempool.

Having priority set in the wrong ordering will result in account sequence mismatch error for one or both transactions.
Even if both transactions are somehow accepted in different orders, tx2 would still fail if it depends on the UpdateClient message from tx1 to be committed first.
Parallel transactions will get outright rejected for non-SDK chains that make use of the sender field in Tendermint.

The best course of action in the short term is to submit one transaction at a time to the mempool, and only submit the next transaction when the current transaction is committed.

This can be done with minimal changes in the ibc-rs code base by modifying the batching algorithm inside send_messages_and_wait_commit to submit batch transactions one by one, instead of submitting them all at once and then waiting for the DeliverTX result.

This is not the most optimal strategy, but we can come out with a better strategy after we confirm that the simple strategy fixes the issue and merge the changes.

Testing Strategy

Tendermint v0.34.20 has been used in ibc-go v5.0.0-beta1. So we can test the relayer against the new behavior by running the integration test against the corresponding simd.
Cosmos.nix support for simd from ibc-go v5.0.0-beta1 has been merged in https://github.com/informalsystems/cosmos.nix/pull/90.
Integration with ibc-go v5.0.0-beta1 is being done in #2523. However there are other integration tests that are failing.

The failed tests are: test_clear_packet_recovery and test_supervisor.
The failures might or might not be related to prioritized mempool.
Further investigation is needed to triage the failures.

After the initial integration is done, we should also write more integration tests to test for the behavior of prioritized mempool. Some rough ideas:

Set the chain block time in test to 5s.
Try and send multiple transactions by manually setting the account sequences and then directly submitting them to the chain without going through ChainHandle.

This can be done by spawning multiple async tasks and calling simple_send_tx in parallel.

Attempt to manipulate tx2 to have higher priority than tx1. It is unclear how this can be done, but we can try a few strategies

Make tx2 contain more messages than tx1.
Set a higher fee in tx2.

Find ways to determine if tx2 is committed before tx1.

We can probably find this by querying the transaction history for a sender?

Determine if tx2 is committed before tx1, would the anticipated errors be raised?

Will we get account sequence mismatch errors?
Or will tx2 be rejected from the mempool?

Run the same integration test against earlier versions, e.g. Gaia v6, and see if the test produce different results.
Write test assertions based on the observed behavior, so that CI can detect if the behavior ever changes.

Priority Mempool Summary 2022-08-09
Here is a summary of recent discussions with the Tendermint and Cosmos SDK teams on this issue:

Priority Mempool has a per-node configuration
The default configuration is to have priority mempool disabled.
The effect of whether priority mempool is used depends on whether the configuration is enabled on the proposer validator node in each block.
If transactions are reordered by priority, the transaction with mismatching nonce will be rejected by Cosmos SDK.
Tendermint has a sender field that limits one transaction per sender in the mempool, but Cosmos SDK do not set the sender field.
Cosmos SDK sets all transaction priorities to 0 by default.
Priority mempool will be superceded by ABCI++

However similar issues will be present with applications using ABCI++.

It is not possible to peek into message content and disable priority for IBC messages.

Because priority can be overridden by applications on the transaction level.

There is currently no clear use cases on which chain would likely activate priority mempool.

It might be useful in future for features like oracles

Priority mempool is likely not needed by major chains like Cosmos Hub and Osmosis.

Short Term Recommendation

To keep the Hermes relayer working smoothly with Tendermint v0.34.20, it is highly recommended to disable priority mempool for all validator nodes for chains supporting IBC.

Since priority mempool is disabled by default, there may be no explicit action needed on this step.

This should not have any major impact, unless there is a compelling case for a chain to enable priority mempool.

If a chain wants to make use of priority mempool and also use Hermes for IBC relaying, note that IBC relaying may break in unexpected ways. The developers for such chain are strongly advised to contact the Hermes team to explore for alternative solutions.

Long Term Plans

Supporting priority mempool and ABCI++ will require major architecture overhaul for the Hermes relayer.
The best course of action is to use multiple wallets for parallel transactions being submitted to the chain.

Each wallet should have at most one transaction in the mempool at a time.
To support multiple wallets, data structures such as Any will need to be modified to allow the signer fields to be updated.
The ChainHandle trait will need to support the use of multiple wallets, as compared to using a globally configured wallet that cannot be changed.

To provide smooth experience for relayer operators, the relayer can create multiple burner wallets and use the fee grant feature to allow the burner wallets to spend fees from the main wallet.
On the analytics side, we will need to investigate ways associate the burner wallets with relayer operators.
Submitting parallel transactions using multiple wallets will require different strategies for submitting UpdateClient messages.

It is not possible to require an IBC transaction to depend on another IBC transaction containing the UpdateClient message submitted by a different wallet.
The UpdateClient message will have to either:

Be committed before the transactions that depend on it, which increases latency, or
Be included in all transactions that depend on ti, which increases cost.

This will likely require significant redesign of how the packet worker operates.

In the worst case, if we ever need to support priority mempool with the current relayer architecture, we can expose a configuration that make send_messages_and_wait_commit send batched messages in serial instead of in parallel.

This may cause significant performance degration, but it is better than having IBC relaying broken on chains that want to disregard our recommendation and enable priority mempool.

Update: It seems Umee and Cronos are two networks that confirmed they intend to enable priority mempool.

https://github.com/cosmos/chain-registry/blob/master/umee/chain.json
https://github.com/cosmos/chain-registry/tree/master/cronos

The cronos network has no entry on mintscan or IBC assets tagged in the chain-registry.
I had a look through the mintscan IBC data for Umee, the relevant part is the channel Umee <> Osmosis https://www.mintscan.io/umee/relayers/channel-0 which has high traffic & will likely be impacted.
After speaking with Robert Z. from Umee team, we decided on the following:

the Umee team will disable tx prioritzation for non-oracle-transactions, which is possible to do at the application level. Validators & node operators on Umee will enable prio mempool, which is important for oracle price feeds, and those transactions will have top priority; all other transactions will retain their default ordering (will not be prioritized by their fees).
once the Umee 0.46-based testnet enables IBC, they will give us access to a full node and a wallet and we'll conduct some basic tests to confirm IBC relaying with Hermes still works.

Apparently, the v1 mempool keeps FIFO behavior when the priorities are the same, so one short-term solution could be to make sure the relayer transactions end up with a static priority value, for example:

With a custom TxFeeChecker on app side, one can assign a static priority to the tx which includes IBC messages.
relayer carefully set gas prices so the resulting priority is static
a) with SDK default mechanism compute priority based on fee amount (I think it's more reasonable to based on gas price), one can set a constant fee amount to have a constant tx priority.
b) in ethermint and cronos, we applied EIP-1559 like feemarket to cosmos tx, where one can set the max_priority_price to a fixed value and set gas_price to maxint, the resulting priority would also be a fixed value, the effective gas price would be base_fee + max_priority_price.

include extension option ExtensionOptionDynamicFeeTx and set the max_priority_price to a constant value, set the gas_price to maxint, so it'll end up with a constant priority value.

@adizere @soareschen can this workaround be added to Hermes in the short term?

include extension option ExtensionOptionDynamicFeeTx and set the max_priority_price to a constant value, set the gas_price to maxint, so it'll end up with a constant priority value.

@adizere @soareschen can this workaround be added to Hermes in the short term?

opened an issue which includes a simple proposal.

Apparently, the v1 mempool keeps FIFO behavior when the priorities are the same, so one short-term solution could be to make sure the relayer transactions end up with a static priority value, for example:

With a custom TxFeeChecker on app side, one can assign a static priority to the tx which includes IBC messages.

Not sure how easy this is as the checker needs to decode the Tx and figure out the type of messages included. What should be the prio if there are also non IBC messages?

relayer carefully set gas prices so the resulting priority is static

the SDK default mechanism compute priority based on fee amount (I think it's more reasonable to based on gas price), one can set a constant fee amount to have a constant tx priority.

The problem is that this fee needs to be paid and should be enough to cover the actual Tx handling cost.  And this constant fee needs to cover the cost of every Tx, big or small, that the relayer submits. It will result in high fees for relayers.

Actually if the SDK compute priority based on gas price, then problem solved, because relayer already uses a static gas price which will translate to a static priority.

We should wait and see if SDK goes this way, I thought the idea is to give higher prio to higher fee Tx-es.

in ethermint and cronos, we applied EIP-1559 like feemarket to cosmos tx, where one can set the max_priority_price to a fixed value and set gas_price to maxint, the resulting priority would also be a fixed value, the effective gas price would be base_fee + max_priority_price. This will require some customization to the tx building in the relayer.

Could you please clarify? what is base_fee? And is base_fee + max_priority_price same as gas_price? Do you plan to use gas price to set the Tx the priority, as suggested in https://github.com/cosmos/cosmos-sdk/issues/12932?

Not sure how easy this is as the checker needs to decode the Tx and figure out the type of messages included.

I think it's pretty easy in the ante handlers where the TxFeeChecker is called, it can just do tx.GetMsgs().

What should be the prio if there are also non IBC messages?

I think we can single out the txs which contains only IBC messages, which I assume is the case for the relayers.

Not sure how easy this is as the checker needs to decode the Tx and figure out the type of messages included

It's pretty easy to do in TxFeeChecker, where it gets passed a sdk.Tx, it just needs to iterate the tx.GetMsgs().

What should be the prio if there are also non IBC messages?

We can single out the txs which only contains IBC messages, which I assume is the case with relayers.
For the other custom clients who also relay IBC messages, they'll need to be aware of the priority thing, and manage it with gas price.

The problem is that this fee needs to be paid and should be enough to cover the actual Tx handling cost. And this constant fee needs to cover the cost of every Tx, big or small, that the relayer submits. It will result in high fees for relayers.

There was discussions about should we set priority based on msg types or gas price/fee, there was no consensus on that, so the default implementation built in the SDK is only a minimal one.
Fortunately, it should be straightforward enough to customize the TxFeeChecker.
If it's important to prioritize the IBC message without requiring a higher fee, and it also doesn't introduce DoS vulnerability, one can do that with a custom TxFeeChecker.

We should wait and see if SDK goes this way, I thought the idea is to give higher prio to higher fee Tx-es.

Yeah, I think the default implementation in SDK is only like an MVP, the chains should think more about their own feemarket design, for example, the ethermint will use the ethereum-like design conveniently. But this brings us to the issue of a flexible way to build the tx in the clients.

Could you please clarify? what is base_fee? And is base_fee + max_priority_price same as gas_price? Do you plan to use gas price to set the Tx the priority, as suggested in https://github.com/cosmos/cosmos-sdk/issues/12932?

it follows the design of EIP-1559 of ethereum, the base-fee is an in-protocol gas price that is constantly adjusted based on the gas usage of the previous block.
And user supplies two fields, a) feeCap which is the maximum gas price to pay, b) prioFeeCap which is the maximum priority gas price to pay, the relationship between them is like this:
require(feeCap >= baseFee)
effectiveGasPrice = min(baseFee + prioFeeCap, feeCap)
priority = effectiveGasPrice - baseFee
effectiveFee = effectiveGasPrice * gas limit  # the actual fee to pay

When apply to cosmos-sdk tx, we reuse the existing fees / gas limit as the feeCap, and define an extension option for the user to input the prioFeeCap.
So if client want to have a constant priority, it can set prioFeeCap to a constant value, and feeCap to a maximum value, then the priority will always be prioFeeCap, and gas price to pay will be baseFee + prioFeeCap, which is adjusted based on block gas usage.

Thanks for the pointer and notes!

There was discussions about should we set priority based on msg types or gas price/fee, there was no consensus on that, so the default implementation built in the SDK is only a minimal one.
Fortunately, it should be straightforward enough to customize the TxFeeChecker.

So a solution involving the TxFeeChecker (*) is to require the default and ANY custom/ app specific implementations to result in relayer Tx-es having same priority. You propose doing this by computing the priority based on the "effective" gas price and not the gas limit or amount. This of course would work for the relayer and any actor trying to submit multiple Tx-es from same account.
But many operators also don't want to pay more than what they pay today (which is already quite a lot). This would mean allowing setting prioFeeCap to zero (i.e. no need for the extra hermes configuration) or something close to zero, with the understanding that IBC Tx-es will have low (can be zero) priority and therefore may be delayed.
Do you plan to enable priority mempool for ethermint? If yes, why (what are the usecases)? And have a custom impl of TxFeeCheckeralong the lines you describe above (ala EIP-1559)?
(*) I still feel we are trying a convoluted solution for a very basic SDK chain UX requirement, the ability to submit multiple Tx-es from same account, with incrementing nonces, to be included in the same block (i.e. never to be reordered regardless of the way priority is computed).

But many operators also don't want to pay more than what they pay today (which is already quite a lot). This would mean allowing setting prioFeeCap to zero (i.e. no need for the extra hermes configuration) or something close to zero, with the understanding that IBC Tx-es will have low (can be zero) priority and therefore may be delayed.

I think this is a different issue, possibly an orthogonal one, that the fee is too costly for relayer operators, I can see several options:

lower the gas fee requirement for all tx types
using ibc incentivization feature to move the cost to the end user
hardcode in the chain to make IBC messages enjoy higher priority without paying a higher fee, this has the risk that IBC messages become the lowest barrier for DoS attack.

Do you plan to enable priority mempool for ethermint? If yes, why (what are the usecases)? And have a custom impl of TxFeeCheckeralong the lines you describe above (ala EIP-1559)?

yeah, that's the plan, together with the EIP-1559.

what are the usecases

I think the main use case for prioritized mempool is when the chain is congested, the users who are willing to pay higher fee can get through faster.
And the use case for EIP-1559 is it maintain a base-fee which is adjusted according to block usage, so if the chain usage is low, the fee will drop automatically.

(*) I still feel we are trying a convoluted solution for a very basic SDK chain UX requirement, the ability to submit multiple Tx-es from same account, with incrementing nonces, to be included in the same block (i.e. never to be reordered regardless of the way priority is computed).

I've proposed a tiered-price-system, where client specify the priority(tier of service) explicitly, different tier has different gas price requirement, and within the same tier, it's FIFO.

We should wait and see if SDK goes this way, I thought the idea is to give higher prio to higher fee Tx-es.

https://github.com/cosmos/cosmos-sdk/pull/12953

#2543 is merged, but haven't fully resolved the workaround. This is because the relay_from_operational_data function is using the AsyncSender, which calls send_messages_and_wait_check_tx instead of send_messages_and_wait_commit. We would need to also modify the RelayPath to switch to use SyncSender if sequential_batch_tx is set to true.
I have also filed https://github.com/cosmos/cosmos-sdk/issues/13009 to ask for the possibility to introduce parallel nonces to Cosmos SDK. If that option is available, it would be much easier for us to support concurrent transactions.

We should wait and see if SDK goes this way, I thought the idea is to give higher prio to higher fee Tx-es.

cosmos/cosmos-sdk#12953

This PR is merged, may I know if it fixes the relayer issues with prioritized mempool now?

This PR is merged, may I know if it fixes the relayer issues with prioritized mempool now?

I think the prio mempool issue is fixed as a temporary workaround in #2543. We plan to extend that solution with an approach that is more resilient to errors or corner-cases (eg https://github.com/informalsystems/ibc-rs/issues/2565 and the comment above https://github.com/informalsystems/ibc-rs/issues/2350#issuecomment-1225534108).

This PR is merged, may I know if it fixes the relayer issues with prioritized mempool now?

I think the prio mempool issue is fixed as a temporary workaround in #2543. We plan to extend that solution with an approach that is more resilient to errors or corner-cases (eg https://github.com/informalsystems/ibc-rs/issues/2565 and the comment above https://github.com/informalsystems/ibc-rs/issues/2350#issuecomment-1225534108).

I thought the issue with prioritized mempool is relayer txs get reordered, so if it keep the FIFO behavior with relayer txs, it's work just like before? And in recent sdk with static gas price, the tx will have static priority, which will have get a FIFO treatment.


Add Unicoq

Since there is a request to add Mtac2, its dependency Unicoq should also be added to the platform.
Technically this is trivial (already done), but we need the agreement of the main authors of Unicoq.
@beta-ziliani, @mattam82: can you please comment here if you agree to adding Unicoq to the Coq platform under the coq platform charter (https://github.com/MSoegtropIMC/coq-platform/blob/master/charter.md) ?

Yes, of course

@MSoegtropIMC currently, Unicoq is restricted to OCaml < 4.08, which would restrict the platform a lot in terms of OCaml versions. See PR #23 by @Zimmi48 for additional discussion on this.

Sure, no problem.

@palmskog : Mtac2 and Unicoq have been part of the Windows installer since a while (8.10?) and my plan for the Coq platform 8.11.2 and 8.12.0 is to use OCaml 4.07.1. Do you see substantial issues with the 4.07.1 pick for the Coq platform? I would say must Coq users don't care much, but I understand that developers do care. But then it is easy to edit the Coq platform script for development purposes and switch to a later OCaml and remove Mtac2/Unicoq.
@mattam82, @beta-ziliani : do you see a substantial issue to update Unicoq to support a more recent version of OCaml for the Coq 8.13 release of the platform (in 6 months)?

There is a substantial issue (that needs to be solved by Coq developers in fact). Cf. the related discussion on Zulip (https://coq.zulipchat.com/#narrow/stream/250632-Coq-Platform.20devs.20.26.20users/topic/Platform.20OCaml.20versions).

I'm closing this one since unicoq is now part of the platform.


docs(README): clean up options so table doesn't horizontal scroll

I noticed on npmjs the table doesn't fit so you have to scroll horizontally. Fixing that up.
Also fixed a typo: the event option was mistakenly called ngOnDestroy.

Thanks 👍


'scrub' doesn't scrub

beets git version
beets version 1.3.16
plugins: convert, embedart, fetchart, info, lastgenre, replaygain, scrub

I import a FLAC file with a comment tag but scrub doesn't delete it.

Scrub is not supposed to delete the command tag. Perhaps you meant to use the zero plugin?

https://beets.readthedocs.org/en/v1.3.15/plugins/scrub.html

Scrub Plugin
The scrub plugin lets you remove extraneous metadata from files’ tags. If you’d prefer never to see crufty tags that come from other tools, the plugin can automatically remove all non-beets-tracked tags whenever a file’s metadata is written to disk by removing the tag entirely before writing new data.
...
Automatic Scrubbing
To automatically remove files’ tags before writing new ones, just enable the scrub plugin ...

By reading this I've understood that scrub would remove all tags before save the new ones.

With the zero plugin, it writes garbage to the comment field:
....
zero:
  fields: comments
  update_database: true

beet info -i comment ... doesn't show anything but:
$ mid3v2 -l Música/Avicii/Stories/01\ -\ Waiting\ for\ Love.mp3
IDv2 tag info for Música/Avicii/Stories/01 - Waiting for Love.mp3
COMM=iTunNORM=eng= 00002206 00002206 0000550E 0000550E 00000000 00000000 00008E88 00008E88 00000000 00000000
....

Ah, I understand how that could be unclear. The plugin removes everything beets doesn't support, but built-in beets fields (including comments) are preserved.
iTunNORM is an embodiment of the ReplayGain tag.

Just stumbled over this issue and have to cross-link to another comment for future reference, as it contains the explanation for a problem that I was losing some hair over:
@sampsyo said:

Are you referring to the iTunNORM field? That’s not considered a comment by beets; it’s an implementation of ReplayGain normalization. Unfortunately, eyed3 labels it as a “comment” for some reason.

This applies to eyeD3, evidently amaroK, too, and probably other players/tools as well…


Increase delay time

Hi, great plugin btw, but max 5 seconds is a bit short for some use case,
Like then I just search for something and look by, but don't want it to be increase the view-count.
Or many when I create a new note, it quickly add the view-count before I got my template be ready, so can it like increase to 1 minutes? even 5 minute for like document if I have read through it, then the view-count will be increase.

Hi @np6390. The delay is just for people that use the templater plugin to insert a template. If you are working on creating a template in a note and the view count is being inserted, that is a different situation. For that case, I would recommend making a templates folder and added it to the excludedPaths in the settings.

For reading a document, I could see it as annoying if you would like the view count only to be incremented when you finish, however that seems like a niche case for the general users of this plugin. For that case, I would recommend not using this plugin and just making a button that you can click to increment the view count.


⚠ Bofrost.be has degraded performance

In 96baf94, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 811 ms

Resolved: Bofrost.be performance has improved in c54a5e2.


:five: Update frontend-library version to 0.5.0

:rocket: deployment of nhsuk/connecting-to-services succeeded (http://connecting-to-services-pr-329.dev.beta.nhschoices.net)


Update Performance attribute interfaces

Modify to support performance of project REST API (Geti) keys
Related Issue: https://jira.devtools.intel.com/browse/CVS-118024
# Refer to new interface of client's web_ui/src/core/projects/dtos/project.interfaces.ts
export interface ScoreDTO {
    value: number;
    metric_type: string;
}

interface TaskPerformanceDTO {
    task_node_id: string;
    score: ScoreDTO | null;
    global_score?: ScoreDTO | null;
    local_score?: ScoreDTO | null;
}

export interface PerformanceDTO {
    score: number | null;
    global_score?: number | null;
    local_score?: number | null;
    task_performances: TaskPerformanceDTO[];
}

export interface ProjectDTO extends ProjectCommon {
    creation_time: string;
    id: string;
    name: string;
    datasets: DatasetDTO[];
    pipeline: {
        connections: ConnectionDTO[];
        tasks: TaskDTO[];
    };
    performance: PerformanceDTO;
    thumbnail: string;
    storage_info?: { size: number } | Record<string, never>;
}

Hi @ljcornel ,
I fixed this and checked locally that the inputs mentioned in the issue were passing fine, but now I see that the tests in the main branch also have issues.
There seem to be two issues,

There is an update to the model_api, but it is not currently reflected.

Need to change openvino.model_zoo.model_api -> openvino.model_zoo.model_api
Need to change input of OpenvinoAdapter (param change: model_path -> model)

However, even with the above fix, test throws an error because tests/data/dice/deployment.zip is out of date.

I asked kate, who added this, and she said that this needs to be manually updated with the deployment.zip, which we can get after running the training directly from the latest Geti.

So I realized that this had a bigger scope than I thought, so I stopped.
It seems to me that manually updating the deployment.zip in the tests folder is a very inefficient and time-consuming task. What do you think?

Hi @harimkang, thanks for the PR! Indeed, I have also noticed the problems with the tests, am working to fix them at the moment.
I agree with you that the test for the video reconstruction feature is not maintainable at the moment, updating the deployment data manually is not something we should be doing. I think I will skip this test for now until we find a better way to handle it.
Will let you know when the pipeline is working again, so that you can rebase your PR.

The CI is green again on main, @harimkang please rebase your PR to run the tests again.


updates about using sealed installers

Adding tabs describing install steps for 10.0.21

:x: Organization membership check failed
Members of the MicrosoftDocs organization should use the private repo. Please move your changes to https://github.com/MicrosoftDocs/Dynamics-365-Operations, and close this pull request.


feat: adopt to 4.2.0

[x] upgrade dependencies
[x] adopt typescript to babylon.js core 4.2.0

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

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Provide php-resque integration with an add on

All message dispatcher implementations, except the InMemoryMessageDispatcher, should be managed in separate repos.

already done


Gap with object_store

This issue is used to track opendal's gap with object_store.
Tasks
Planned

[x] https://github.com/datafuselabs/opendal/issues/353
[x] https://github.com/datafuselabs/opendal/issues/361
[ ] https://github.com/datafuselabs/opendal/issues/362
[ ] https://github.com/datafuselabs/opendal/issues/743

In Research

[x] Concurrent Request Limit
[x] Read multiple ranges support
[ ] copy_if_not_exists
[ ] rename_if_not_exists

@suyanhanx Do you want to take a look over move support?

I'm a little torn on how to implement it. Adding the move concept is simple, but it seems that there are very few backends that natively support move. We have to combine copy and delete at most cases.

We have to combine copy and delete at most cases.

Please don't confuse two different things.

Native support provided by backends.
Public API we exposed to users.

It's ok that very few backends support move.

After reviewing the list of backends that we currently support, I found that only a few of them support native move operations. While we can simulate the move operation, we cannot guarantee that it will be atomic or have the same behavior as a native move operation. Therefore, it makes more sense for us to not provide support for move operations on these backends to avoid any potential issues or inconsistencies.

There are two factors at play here.
First of all, The backend should only offer native support and avoid implementing fallbacks or workarounds. The capabilities of the backend will be documented at the beginning of its documentation.
I think both of us have agree with that.

Then, at Operator level. We don't know what's the underlying backend it is. The only thing we know is info.can_copy(). The decision we need to make is whether to return an Unsupported error or implement a fallback.
You concern is correct. We can't reach the same perf or atomic as native support does. However, users do have those features. They need to move data.
If we return an error, user will write code like:
match op.move(src, dst).await {
  Ok(_) => return Ok(()),
  Err(err) if err.kind() == ErrorKind::Unsupported => {
    op.copy(src, dst).await?;
    op.delete(dst).await?;
    return Ok(())
  }
  Err(err) => return Err(err)
}

Not providing this support forces users to repeat the same code for each task.

Not providing this support forces users to repeat the same code for each task.

At least users can wrap it themselves to handle this.

At least users can wrap it themselves to handle this.

Yes, they have the option to not use the rename function that we provide.

Most core feature has been implemented. Let's close this issue.


Prevent borgs from being able to be briefly toggled off.

About the PR
Borgs can no longer be briefly turned off via pressing E on them or via right-click verb.
Why / Balance
This should not be possible, and is annoying for the borg player as it resets the action order for modules and briefly slows them down & disables their AA.
Technical details
ItemToggleComponent has a new ManualToggle field which defaults to true, but is set to false, which prevents the item from being manually toggles or having a toggle verb.
Media
Not neccesary.
Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Changelog
:cl: BramvanZijp

fix: Fixed borgs being able to be briefly disabled by others.

resolves #31493


Added touchegg and dependencies

Hey, folks!
First commit here. Touchegg is a daemon that the user can run which recognizes touch surfaces, such as a touch screen, and gestures made on said touch surface to add those swiping motions all the kids love.

Travis passed, thanks and welcome.


create a top rented page

I can create a top rented page where the most rented products are displayed.
The items will be hardcoded for now as there is no backend to this project....

Please assign me this issue under level2 gssoc gssoc-ext hacktoberfest hacktoberfest-accepted...I'll be happy to work on it 💯
PS: I have thoroughly visited all prs and issues assigned and I saw that there is already a backend PR (#18),
when that is merged,
I can raise another issue for the same top rented page and implement it fully along with the necessary changes in the backend, like schema and logic for calculating top rated products.

@ShivanshPlays You can proceed with it. Please remember to -

Send a photo here of of the new design before raising a PR
Follow the proper file structure
Star the repo :)

All the best!

Okay I'll raise the PR by EOD

ANY ISSUE? @SaranshBangar

@ShivanshPlays I have written the issue in the review of your PR


No touch response to emoji icons on android chrome

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open the app in android chrome
Open any report
Click on emoji icon and observe there is no touch response (try steps 1-3 on android app and observe how it displays background color to icon on touch)
In emoji picker, select category icons and observe there is no touch response

Expected Result:
App should have touch response on icon click on android chrome as it does on android app and other platforms
Actual Result:
App does not have any touch response on click of icons on android chrome
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/43996225/231928597-817d1bce-0e92-48c5-b844-968dce7b0876.mp4
https://user-images.githubusercontent.com/43996225/231928607-1dac3f72-a687-4ba1-806d-126f38abc6b9.mp4
Expensify/Expensify Issue URL:
Issue reported by: @dhanashree-sawant
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1681401275526379
View all open jobs on GitHub

Triggered auto assignment to @garrettmknight (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

This is happening because we are using Pressable component instead of TouchableWithOpacity but since we are moving away from Touchables (tracking issue here: https://github.com/Expensify/App/issues/14589), we should wait until the migration is complete because after the migration, there will be a GenericPressableWrapper that should be used here.
So I think we can put this on hold until then. For further confirmation, we can ask Vit Horacek also as he created the tracking issue.

@garrettmknight Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

Thanks @esh-g! In that case, I think this is expected behavior rather than a bug. I'm going to close and if it comes back up after we move away from pressable, we can reopen!

Issue is reproduced in build <IP_ADDRESS>
https://github.com/Expensify/App/assets/93399543/4b8394e5-1e81-4f0c-9e34-cce8603a1854

This was reopened while I was OOO - will pick it up tomorrow.

Just tested and it looks like it's working now on 1.3.42-8 when I test in browserstack. @kbecciv Can you give it another try and close if it's working?

Hello @garrettmknight Yes, checking again

Works on build 1.3.42-26
https://github.com/Expensify/App/assets/93399543/76c481d3-7453-4304-af36-c313a203d05c