Azure Account Center links to retired page at https://account.windowsazure.com/subscriptions

The "View usage - other subscriptions" section, has a link for the Azure Account Center link to https://account.windowsazure.com/subscriptions
But the linked page refers customers to the Azure portal-

Account management has moved to Azure portal
This portal has been retired. We have migrated all the functionality including managing payment methods, downloading invoices, usage & costs and viewing your subscriptions to the Azure portal.
Azure portal offers a richer unified experience for cost management & billing and resource management.

I suggest that we update this doc with a similar link directly to Azure Cost Management blade.
Also the View usage - Enterprise Agreement subscriptions section has a link to an EA portal at https://ea.azure.com, but I'm not able to confirm if that site is still valid.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 0137a710-b369-d41a-4bf1-8b2c92abd04e
Version Independent ID: 18d89d67-fcee-bd46-98eb-6db35fcf35d1
Content: Report Azure Stack Hub usage data to Azure - Azure Stack Hub
Content Source: azure-stack/operator/azure-stack-usage-reporting.md
Service: azure-stack
Sub-service: azure-stack-hub
GitHub Login: @sethmanheim
Microsoft Alias: sethm

@alexsmithMSFT Thank you for catching that -- I updated to the link to point to the Azure Cost Management blade. Will be live after 3 PM PT today.

@alexsmithMSFT
It looks like your issue is resolved since you closed this thread.
If there are further questions regarding this matter, please tag me in a comment. I will reopen it and we will gladly continue the discussion.


Step 2.1 in the Differential Pivot Build is a duplicate of Step 2.2.2 in the Body Assembly

Given the reorganization of the Body Build, it makes sense to eliminate it from the Differential Pivot Build.

This was noted in #148 and subsequently fixed in 4590fbd.


Update Developer Guide

Coverage remained the same at 92.691% when pulling 16f6df7d942e0fc43a0b38096e3060cc10e27ddf on Lenaldnwj:DG_component into 28a6374a12a1dbc6e2a225d79ecdb705e9334264 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.691% when pulling e90aefef7949271fc33d1ee0f2ddae4013d343e7 on Lenaldnwj:DG_component into 28a6374a12a1dbc6e2a225d79ecdb705e9334264 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.691% when pulling faafb52e5d010975b2e75ab44d48e99082c4fa7b on Lenaldnwj:DG_component into 28a6374a12a1dbc6e2a225d79ecdb705e9334264 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.691% when pulling faafb52e5d010975b2e75ab44d48e99082c4fa7b on Lenaldnwj:DG_component into 28a6374a12a1dbc6e2a225d79ecdb705e9334264 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.691% when pulling 180d52c5c513075420b158f9866cd560fbb2fd9f on Lenaldnwj:DG_component into 28a6374a12a1dbc6e2a225d79ecdb705e9334264 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.691% when pulling 5db3651903c7faa42db72996ded37d311b738eac on Lenaldnwj:DG_component into 28a6374a12a1dbc6e2a225d79ecdb705e9334264 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.691% when pulling d66aa8849dbcfbb3ad5a16cd960c102a2b8d7c38 on Lenaldnwj:DG_component into 28a6374a12a1dbc6e2a225d79ecdb705e9334264 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.691% when pulling 11c07c1fe92799d9c3dc978161873e672aacd637 on Lenaldnwj:DG_component into 0288d1140b191baf3e494e8c7cf0172c93fde189 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.691% when pulling 11c07c1fe92799d9c3dc978161873e672aacd637 on Lenaldnwj:DG_component into 0288d1140b191baf3e494e8c7cf0172c93fde189 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.723% when pulling 87a8e5d73a628ffb8efea0f09be739bc95009fbf on Lenaldnwj:DG_component into 970e0b07dffddca01afcf47bd2d6ed8e5e37e007 on CS2103AUG2017-T16-B2:master.

Coverage remained the same at 92.723% when pulling 87a8e5d73a628ffb8efea0f09be739bc95009fbf on Lenaldnwj:DG_component into 970e0b07dffddca01afcf47bd2d6ed8e5e37e007 on CS2103AUG2017-T16-B2:master.


[WIP] Updates to Xcode 8 / Swift 3

[x] Get project compiling
[x] Get unit tests compiling
[x] Get unit tests to pass
[x] Fix this test
[ ] Test on device

          3 Warnings

  :warning:
  PR is classed as Work in Progress

  :warning:
  Needs testing on a Phone if change is non-trivial

  :warning:
  Detected some Swift building time outliers

Time | Class | Function |
| --- | ----- | ----- |40.9ms | Mutex.swift | func lock(closure: () -> Void)

  Generated by :no_entry_sign: danger

So the big issue now is that we were testing on iOS 9.3 but Circle only has 9.0 or 10.0. I'm looking into how hard it would be to move back to 9.0, but it's looking like 10.0 might be just a s much work (and a step forward, not back).

Yeah, so there's work left to do if we're going to compile against iOS 10, which we'll need to do eventually. But most things look good. I'll talk to the rest of the team about their plans around this.

I’m thinking that it might make sense to run CI against the oldest version we support, as it’s likely that we’d normally dev on iOS 10. Does that make sense to you?

Makes sense to me!
Deploying from Xcode 8 on CI means there still might be some iOS 10 issues, I haven't thoroughly tested yet.

Looks like it'll be easier to just install the simulator from the command line.

https://goo.gl/JBljdR

Note: the Pods dir will need work on a merge, a bunch of stuff has happened in there since this PR was started

OK, I think that's everything.

[WIP], an unchecked TODO, and merged. Living the danger life 🤘


Problems extracting DOM to submit

This is no bug report or something. I have a problem with the regions object.
Im trying to instead of using an ajax request to send FormData(), to apply the form as hidden input fields before making a submit of the page. My sites flow is to not use ajax for most things, but instead submit the page with data. This is for e.g. tracking, SEO, security (by checking that its not the wrong user doing the request) and so on and so on.
When trying to log out what's in the regions object i can't really get any usefull values/data from there.
Please understand that JS is not my language by birth :)
If i understand it right, the data saved by the ajax call is the clean variant of the HTML? right? Not with all the css classes that ContentTools uses to make its magic.
Like images should not be saved as <div styel="background jada jada../>  but as img-tag and such. I have tried now for more than a day to extract something useful to send to my backend, but nothing yet. Please help me out here :)
Thanks a lot in advance!

Hi @FuXual can you send me an example of your JS that's being used to gather the html to submit to your server. Also have you tried implementing this code from the tutorial? - http://getcontenttools.com/tutorials/saving-strategies#sending-save-requests-to-the-server-with-ajax

Thank you for your answer Anthony! And thank you very much for this great application! Yes, i have read it, but I instead solved it by making my own DOM parser and converter.
This is because that my project im building is a bit different in many ways, and im just using ContentTools as an engine (in some way). Im bypassing most of the functionality and triggers events very differently etc.
I then utilize htmlLawed like functionality (written by me) in the backend to parse it again for other reasons (mostly security reasons). I also have my own version control software in the backend (which is the main project)
Thanks again alot for this piece of software :)


Data loss when worker crashed

Alluxio Version:
2.6.0
Describe the bug
In our test cluster, we used Flink to consume Kafka data and write it to Alluxio. There are three workers, the number of replication is 2, UFS is HDFS, writeType is cache_through. After we stopped two of the workers and waited for Kafka lag to recover, we began to compare the data directly written into HDFS by product cluster, and found that the data was about 5/1000 less. We tested it multiple times, and the results were all biased.
We suspect there is something wrong with BlockOutStream#updateCurrentChunk(), which is not handling any exceptions.
  private void updateCurrentChunk(boolean lastChunk) throws IOException {
    // Early return for the most common case.
    (...)
    if (mCurrentChunk.writableBytes() == 0 || lastChunk) {
      try {
        if (mCurrentChunk.readableBytes() > 0) {
          for (DataWriter dataWriter : mDataWriters) {
            mCurrentChunk.retain();
            dataWriter.writeChunk(mCurrentChunk.duplicate());
          }
        } else {
          Preconditions.checkState(lastChunk);
        }
      } finally {
        // If the packet has bytes to read, we increment its refcount explicitly for every packet
        // writer. So we need to release here. If the packet has no bytes to read, then it has
        // to be the last packet. It needs to be released as well.
        mCurrentChunk.release();
        mCurrentChunk = null;
      }
    }
  (...)
  }

We added log.
  private void updateCurrentChunk(boolean lastChunk) throws IOException {
    (...)
    if (mCurrentChunk.writableBytes() == 0 || lastChunk) {
      try {
        if (mCurrentChunk.readableBytes() > 0) {
          for (DataWriter dataWriter : mDataWriters) {
              mCurrentChunk.retain();
              dataWriter.writeChunk(mCurrentChunk.duplicate());
          }
        } else {
          Preconditions.checkState(lastChunk);
        }
      } catch (Throwable t) {
        throw new IOException("UpdateCurrentChunk failed!", t);
      } finally {
        // If the packet has bytes to read, we increment its refcount explicitly for every packet
        // writer. So we need to release here. If the packet has no bytes to read, then it has
        // to be the last packet. It needs to be released as well.
        mCurrentChunk.release();
        mCurrentChunk = null;
      }
    }
   (...)
  }

Log as follows.
21/08/23 18:55:51 ERROR stream.BlockOutStream: UpdateCurrentChunk failed!
java.lang.IllegalStateException: DataWriter is closed while writing chunks.
	at alluxio.shaded.client.com.google.common.base.Preconditions.checkState(Preconditions.java:508)
	at alluxio.client.block.stream.LocalFileDataWriter.writeChunk(LocalFileDataWriter.java:129)
	at alluxio.client.block.stream.BlockOutStream.updateCurrentChunk(BlockOutStream.java:263)
	at alluxio.client.block.stream.BlockOutStream.write(BlockOutStream.java:142)
	at alluxio.client.file.AlluxioFileOutStream.writeInternal(AlluxioFileOutStream.java:254)
	at alluxio.client.file.AlluxioFileOutStream.write(AlluxioFileOutStream.java:217)
	at org.apache.hadoop.fs.FSDataOutputStream$PositionCache.write(FSDataOutputStream.java:57)
	at java.io.DataOutputStream.write(DataOutputStream.java:107)
	at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:96)
	at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:68)
	at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:129)
	at org.apache.hadoop.fs.shell.CommandWithDestination$TargetFileSystem.writeStreamToFile(CommandWithDestination.java:485)
	at org.apache.hadoop.fs.shell.CommandWithDestination.copyStreamToTarget(CommandWithDestination.java:407)
	at org.apache.hadoop.fs.shell.CommandWithDestination.copyFileToTarget(CommandWithDestination.java:342)
	at org.apache.hadoop.fs.shell.CommandWithDestination.processPath(CommandWithDestination.java:277)
	at org.apache.hadoop.fs.shell.CommandWithDestination.processPath(CommandWithDestination.java:262)
	at org.apache.hadoop.fs.shell.Command.processPathInternal(Command.java:367)
	at org.apache.hadoop.fs.shell.Command.processPaths(Command.java:331)
	at org.apache.hadoop.fs.shell.Command.processPathArgument(Command.java:304)
	at org.apache.hadoop.fs.shell.CommandWithDestination.processPathArgument(CommandWithDestination.java:257)
	at org.apache.hadoop.fs.shell.Command.processArgument(Command.java:286)
	at org.apache.hadoop.fs.shell.Command.processArguments(Command.java:270)
	at org.apache.hadoop.fs.shell.CommandWithDestination.processArguments(CommandWithDestination.java:228)
	at org.apache.hadoop.fs.shell.CopyCommands$Put.processArguments(CopyCommands.java:295)
	at org.apache.hadoop.fs.shell.FsCommand.processRawArguments(FsCommand.java:120)
	at org.apache.hadoop.fs.shell.Command.run(Command.java:177)
	at org.apache.hadoop.fs.FsShell.run(FsShell.java:328)
	at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76)
	at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:90)
	at org.apache.hadoop.fs.FsShell.main(FsShell.java:391)

Hi @yuzhu @maobaolong , have you met similar problems? Please help to confirm whether there is a bug here. Thanks a lot.

Hi @tomscut thanks for the report!
We'd like to further understand the log you added and see. In your log for updateCurrentChunk() could you print more information in that log message? For example I recommend printing the lastChunk argument, the mLength and mAddress from the BlockOutStream object. Also the mDataWriters from the BlockOutStream class has information about the DataWriter objects. In your stacktrace it seems to be LocalFileDataWriter and LocalFileDataWriter has additional information about where the write is from, like CreateLocalBlockRequest and the LocalFileBlockWriter. If you could print those information and share with us, we can then identify how the DataWriter is closed unexpectedly.

Also do you observe any pattern between the log message and the data loss? Does one exception correspond to one data loss?

@tomscut  can you help provide more information to help jiacheng debug this issue?

Hi @apc999 @jiacheliu3 , sorry for the late reply. I will post a detailed log ASAP.

Hi @jiacheliu3 , we can reproduce the question like this:
1 Add catch to updateCurrentChunk() and print relevant information we need.
2 Create a large file and upload it to Alluxio using the command line alluxio fs copyFromLocal ./10g-file.
3 Shut down a worker during file uploading. Then we can see the error message.

jiacheng is on vacation, I will take a closer look. thanks @tomscut

jiacheng is on vacation, I will take a closer look. thanks @tomscut

Thank you for your attention to this issue.

@apc999 @jiacheliu3， do you have any update on this issue?

@tomscut Thx for adding the information.
I'm confused why retry will resolve this issue. At least I'm not yet convinced before I can see what the DataWriter is. Without that information I think it's hard to reason how this issue can be fixed. Is it possible to add the logging as I suggested?
Also for the stacktrace you pasted, if the exception is not caught here, it will propagate to higher levels. Looks to me the exception is caught somewhere else. IllegalStateException is a RuntimeException and will propagate to your shell's log.
However, your stacktrace is from a shell command instead of Kafka stream? How are things connected?


[AI] Bug Fixing Pass

after the recent merge, AI has probably lots of bugs, so a full bug testing session nis required

obvious bug fixing done


fix: Raid issues

Fix team number

What do you want to test ?

I think set_team_number is never called by the test, it is not covered


Po import 20180925

looks like this is revealing some longstanding issues, etc
id: GO:0046844
name: micropyle formation
namespace: biological_process
def: "Establishment of the micropyle, a single cone-shaped specialization of the chorion that allows sperm entry into the egg prior to fertilization."  We should look at this together on an editors' call.

Yes. But his is actually good because it is identifying longstanding issues that are uncovered by importing external ontologies.

I think it would be a good exercise to go through the error report, loading into Protege, identifying unsatisfiable classes and looking at the explanation panel. This is a nice teaching example.

Looks like there is some confusion with respect to spore-bearing structures and some conflation of anatomy terms and logical definitions with respect to sporangium development and spore-bearing structure development. This is waaaaay out of my field of expertise, but seems like we need a parent sporangium to encompass many taxa that can bear spores (there is one in the PO and one in the FAO and according to GO there is also an oomycete one). This leads me to believe that the GO logical defs are way too specific. I'm tempted just to remove the logical defs for spore-bearing structure development and sporangium development because there is no good anatomy term that makes the def necessary and sufficient for all taxa. The micropyle one is easy. We just pointed to the plant structure instead of the GO CC. @tberardini any advice on the sporangium terms?

And do you know the difference between a spore-bearing structure and a sporangium? The defs are very close to being the same.

I'm tempted just to remove the logical defs for spore-bearing structure development and sporangium development because there is no good anatomy term that makes the def necessary and sufficient for all taxa.

Yes to this.

And do you know the difference between a spore-bearing structure and a sporangium? The defs are very close to being the same.

I'd need to do some background reading to be sure.  Removing the logical defs seems the cleanest and fastest way to resolve the import clashes at this point in time.

Works for me. We can merge later if we think that is best.


Build error

The following command fails to build:  go get -u -v github.com/cloudflare/ebpf_exporter/...
github.com/cloudflare/ebpf_exporter (download)
github.com/cloudflare/ebpf_exporter/vendor/github.com/iovisor/gobpf/bcc
github.com/cloudflare/ebpf_exporter/vendor/github.com/iovisor/gobpf/bcc
go/src/github.com/cloudflare/ebpf_exporter/vendor/github.com/iovisor/gobpf/bcc/module.go:261:33: not enough arguments in call to _C2func_bpf_attach_uprobe
have (_Ctype_int, uint32, *_Ctype_char, *_Ctype_char, _Ctype_ulong, _Ctype_int)
want (_Ctype_int, uint32, *_Ctype_char, *_Ctype_char, _Ctype_ulong, _Ctype_int, _Ctype_uint)
After forcing an additional param '0' at the end of the function allows the build to go through: "go/src/github.com/cloudflare/ebpf_exporter/vendor/github.com/iovisor/gobpf/bcc/module.go:261:33"
res, err := C.bpf_attach_uprobe(C.int(fd), attachType, evNameCS, binaryPathCS, (C.uint64_t)(addr), (C.pid_t)(pid), 0)
I am unable to use uprobes, could this be the reason?
Thanks.

BCC doesn't have a stable API, which means that it breaks from time to time. It seems that you're using BCC 0.17.0 or newer, while epbf_exporter expects 0.16.0. The following commit from gonbpf is needed (same as your change):

https://github.com/iovisor/gobpf/commit/dcacba608f5153b453bfbe30a2a915e8e867d468

This has nothing to do with ebpf_exporter, it's API between gobpf and bcc.

You can sue this in the meantime: https://github.com/cloudflare/ebpf_exporter/pull/96


⚠ CIOOS Pacific ERDDAP dataset ECCC_MSC_BUOYS has degraded performance

In cdae2df, CIOOS Pacific ERDDAP dataset ECCC_MSC_BUOYS (https://data.cioospacific.ca/erddap/tabledap/ECCC_MSC_BUOYS.htmlTable?wmo_synop_id&time>now-3hours&distinct()) experienced degraded performance:

HTTP code: 503
Response time: 15935 ms

Resolved: CIOOS Pacific ERDDAP dataset ECCC_MSC_BUOYS performance has improved in 9a9e941 after 8 minutes.


Ultimatum Tag

Hi there dermow, could you possibly update with an Ultimatum tag now that it's back in the game?

Implemented :)


Support/stud233

Increase test coverage by testing rabbitmq stuff

Can you also test the school delivery layer? There are some new lines added in code that aren’t covered in tests!

ok bb


Wrong HTTP Method type in documentation

curl localhost:5000 is GET request, but in doc it says POST request

Proposed changes

Unreleased project version (optional)

Related issues (optional)

Thank you @zhengjxu


nvm install lts panic

What happened?
nvm install lts returns ''panic: runtime error: index out of range[0] with length 0"
nvm list  returns "no installations recognized"
What did you expect to happen?
First command, to install the latest version of node
Second command, to list node versions
Version
1.1.11 or newer (Default)
Which version of Windows?
Windows 11+
Which locale?
English (Default)
Which shell are you running NVM4W in?
PowerShell
User Permissions?
Administrative Privileges, Elevated
Is Developer Mode enabled?
No (Default)
Relevant log/console output
PS C:\WINDOWS\system32> nvm debug
Running NVM for Windows with administrator privileges.

Administrator: Windows PowerShell
NVM4W Version:      1.1.11
NVM4W Path:         C:\Users\Kevin\AppData\Roaming\nvm\nvm.exe
NVM4W Settings:     C:\Users\Kevin\AppData\Roaming\nvm\settings.txt
NVM_HOME:           C:\Users\Kevin\AppData\Roaming\nvm
NVM_SYMLINK:        C:\Program Files\nodejs
Node Installations: C:\Users\Kevin\AppData\Roaming\nvm

Active Node.js Version: none
(run "nvm use <version>" to activate a version)

No problems detected.

Find help at https://github.com/coreybutler/nvm-windows/wiki/Common-Issues
PS C:\WINDOWS\system32> nvm list

No installations recognized.
PS C:\WINDOWS\system32> nvm install lts
panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
main.getLTS(...)
        C:/Users/corey/OneDrive/Documents/workspace/libraries/oss/coreybutler/nvm-windows/src/nvm.go:1141
main.getVersion({0xa0140b0, 0x3}, {0x10b6b0d, 0x2}, {0x0, 0x0, 0x0})
        C:/Users/corey/OneDrive/Documents/workspace/libraries/oss/coreybutler/nvm-windows/src/nvm.go:225 +0x73d
main.install({0xa0140b0, 0x3}, {0x10b6b0d, 0x2})
        C:/Users/corey/OneDrive/Documents/workspace/libraries/oss/coreybutler/nvm-windows/src/nvm.go:290 +0x255
main.main()
        C:/Users/corey/OneDrive/Documents/workspace/libraries/oss/coreybutler/nvm-windows/src/nvm.go:94 +0xaf7
PS C:\WINDOWS\system32>

Debug Output
PS C:\WINDOWS\system32> nvm debug
Running NVM for Windows with administrator privileges.

Administrator: Windows PowerShell
NVM4W Version:      1.1.11
NVM4W Path:         C:\Users\Kevin\AppData\Roaming\nvm\nvm.exe
NVM4W Settings:     C:\Users\Kevin\AppData\Roaming\nvm\settings.txt
NVM_HOME:           C:\Users\Kevin\AppData\Roaming\nvm
NVM_SYMLINK:        C:\Program Files\nodejs
Node Installations: C:\Users\Kevin\AppData\Roaming\nvm

Active Node.js Version: none
(run "nvm use <version>" to activate a version)

No problems detected.

Find help at https://github.com/coreybutler/nvm-windows/wiki/Common-Issues

Anything else?
OS Name	Microsoft Windows 11 Pro Insider Preview
Version	10.0.23585 Build 23585

The remote JSON file providing the list of versions is only partially returning, so NVM4W is getting an incomplete response from the Node servers (i.e. invalid JSON). I'm adding special error handling for this so users will know what is going on... but the fix is basically to wait for the server to return a proper response. I will release this as v1.1.12 sometime today. In the meantime, I encourage users to wait a few minutes and retry. Alternatively, download the specific version (20.9.0 as of this writing). This bypasses the version lookup process for the lts alias.
This behavior is happening sporadically at the moment. Some changes are happening in the Node GitHub repo, so it is likely just a matter of time before the web server caches are updated.


chore(io-engine-client): migrating io engine client to v1 grpc code

This PR migrates io-engine-client operation to v1 grpc API.
We are supporting both v0, v1 calls.


[WIP] Refactor start_clone method and break up powershell functions

This addresses an issue where an invalid provisioning attempt could fail. Instead of a helpful error message, users are getting an obscure JSON parsing error.
What is essentially happening is that the call to New-SCVirtualMachine inside the build_ps_script is failing, with the result that the method returns an empty string because there's no error checking. When JSON then tries to parse an empty string, it bombs.
This PR splits the powershell functions into two separate calls, and we check the results of the first one before moving onto the second.

@djberg96 still having the refresh issue :disappointed:

@jteehan @skateman This should be good to go. You can copy these files over, restart your app and then put it in debug mode to get full output.


Remove unused imports

Codecov Report

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

@@            Coverage Diff            @@
##             master    #1054   +/-   ##
=========================================
  Coverage     67.37%   67.37%
  Complexity      774      774
=========================================
  Files           176      176
  Lines          3234     3234
  Branches        368      368
=========================================
  Hits           2179     2179
  Misses          898      898
  Partials        157      157


'byte' does not name a type

Veryfing code using this library in Particle Build fails with this error:
Spark-Websockets/Spark-Websockets.h:72:3: error: 'byte' does not name a type
   byte _opCode

Trying to compile the example app inside of the web ide and this error happens

looks like this fix needs to be updated (reimported) on the webIDE

Hello, try it. I've reimported ,but not tested. Haven't time for this, and doesn't using webide


help! need some test results: will take you two minutes

:star2: Attention all you watchers! If you have Windows 10, Linux or MacOS, I need your help for a couple of minutes

css line height differs per platform in Firefox, and can thus be used to determine your os.  For example, I use Georgia as my default serif and locked doc fonts to 0 .. and I'm shown up as 19px (and everyone thinks I'm on Linux)
I've built a work-in-progress PoC, but need some more data. I'm just going off the original info supplied by hackerone - source, so I'm not even looking at san serif or monospace, or other fonts families, or styles (but I may do, this is interesting).
The other thing I have found is that something happened with the release of FF62, and all the measurements changed. Maybe it's something to do with stylo, IDK, and it doesn't matter - because I can 100% reliably detect your FF version based on internally how FF handles various JS features (you can't change these using prefs: if JS is allowed to run, I can detect your version in FF60 up)

I need test results to confirm ESR60 and FF64/65
:exclamation: Make sure you allow document fonts for this test

[SETTING] General>Language and Appearance>Fonts & Colors>Advanced>Allow pages to choose...

:exclamation: and don't zoom the page: do the test at 100%
So here is my little test page: https://thorin-oakenpants.github.io/testing/ and this is the bit of info I need from you guys ad gals

:small_orange_diamond: ESR60

OS
expecting
confirmed result

Windows7
19.2 or 20
20

Windows10
19.2 or 20

MacOS
19.5167
19.6833 (in a dodgy VM)

Linux
19
19 (debian) 17 (debian 32bit)

Android

:small_orange_diamond: FF64/65 preferably (or at least 62 or higher)

OS
results

Windows7
18

Windows10
18, 19 (scaling=200%)

MacOS
19.2, (19.6833 in a dodgy VM)

Linux
19 (arch) 17 (debian)

Android
19.5

Note: the test has two css line heights. One I specify to use the Times New Roman font: just paste both results. I am not sure what the default serif font is on other platforms, and if hackerone's test used the default font or specified one
...

thanks everyone ... I think I have enough info


Everytime I try to chart the song and reload the audio it shows a blank state :|

Describe your bug here.
I feel like this has been said before, but as the title says, i'm having issues charting some songs,and yes i have changed both the tracks to Voices.ogg and Inst.ogg. But either way, it still won't seem to work everytime i reload the song, and everytime i do it will show a blank state saying: Uncaught Error:Error loading sound from file: mods/Testing lol/songs//cory/Voices.ogg. Does anyone know how to fix this?
Command Prompt/Terminal logs (if existing)
No response
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
no

Ig it's a Psych issue itself or you are definitely did something wrong

I can't play the song "Test" for the secret. It is just the song I used with the notes, But still, The Song works well, Not the .JSON file tho. I don't think It's in the mod (O.7.3v btw). tell me how I do it? I wanna have the secret badge: "Play The Secret Test Song on hard with No Misses." and all that. Pls


Add support for expressions in add_entries processor

Is your feature request related to a problem? Please describe.
Add Entries processor should support adding entries based on expressions, especially expressions with functions
For example,
    processor:
        - add_entries:
           entries:
            - key: "requestLength"
            - value: "length(/request)"

or
   processor:
        - add_entries:
           entries:
            - key: "newKey"
            - value: "getMetadata('newKey')"

or
    processor:
        - add_entries:
           entries:
            - key: "newLength"
            - value: "length(/request) + getMetadata('padding_length')"

Describe the solution you'd like
Need to support dataprepper expressions as values. They may be supported under existing value: config option  or add new config option like value_expression: which takes an expression, evaluates it and stores the result as value for the given key
 processor:
        - add_entries:
           entries:
            - key: "newLength"
            - value_expression: "length(/request) + getMetadata('padding_length')"

Describe alternatives you've considered (Optional)
Alternative way is to have a special character as the first character in the value to indicate that what's following is an expression. For example
 processor:
        - add_entries:
           entries:
            - key: "newLength"
            - value: "@(length(/request) + getMetadata('padding_length'))"

Additional context
Add any other context or screenshots about the feature request here.

Initially, arithmetic operators are not supported in arithmetic expressions


Update Design System for steps/conviction/compensation_payment_receipt

Story: https://mojdigital.teamwork.com/#/tasks/21707831

Much cleaner now 😄 without those duplicated locales


Adding receiving_hei_id parameter to request parameters and making it required

Hi,
It is definitely clear that the receiving hei_id is the owner of the listener CNR called by sending HEI.
However, this is clear only if the receiving hei has and uses its EWP implementation modules under its own domain name.
And in other cases and implementations as below, the receiving hei id becomes undetectable and we think it deserves its own parameter as required parameter in the URL.
Please check the scenarios below:
CASE 1 (no problem)
Sending HEI ID: A =>aa.edu
Receiving HEI ID: B => bb.edu
Receiving HEI has EWP API URLs under bb.edu
=> Receiving HEI ID is clear and not needed as the CNR is sent directly to an address responsible only for a single HEI.
CASE 2 (problem detecting the receiving HEI)
Sending HEI ID: A =>aa.edu
Receiving HEI ID: B => bb.edu
Receiving HEI is using an EWP provider/gateway: (domain: ewp-provider-gateway.xyz) and its EWP API URLs are under ewp-provider-gateway.xyz such as ewp-provider-gateway.xyz/omobility-cnr-listener
This provider/gateway is also responsible for some other HEIs (such as cc.edu, ff.edu, gg.edu etc)
=> In this case, the gateway/provider (ewp-provider-gateway.xyz) knows the sending hei id but cannot detect or know the receiving HEI ID and thus cannot deliver the CNR information package to the receiving HEI.
The problem here is where and to whom gateway shall deliver this CNR? bb.edu, cc.edu, ff.edu, ...?
Our suggestion is to add a receiving_hei_id parameter to request parameters and making it required.
In our opinion, this will solve such gateway delivery issues and the receiving hei ambiguities in this API as it will clearly state/define the receiving institution.
Just to make it more clear, here is a sample case from real life:
I am as A sending a cargo package to my friend B.
B is living in a single house and the house number is 17.
UPS delivers easily this cargo to number 17 as this house is a single building/house and it is owned only by B.
Secondly, I am sending a cargo package to my friend C.
C is living in a building which has 20 flats/apartments.
UPS goes to the building for delivery but does not know definitely to whom (name?, flat/floor/apartment number?) it shoud deliver this cargo in the building.
Please let us know if we are missing anything in the API specs and docs or if there is anything not clear in my message or if details needed.
Thanks for your interest and time.
Best,

This is not the first time such suggestion is done, see https://github.com/erasmus-without-paper/ewp-specs-api-imobilities/issues/2. Generally we agree and would be happy to add such change, the only problem is backward compatibility.
If  some more developers would support the idea, in particular developers, who are already in production with their solutions, we would make a change.
@georgschermann, @pleys and the others, whould do you think?

Hi,
We would like to bring this issue to the front again.
Just as a quick summary:
We would like not only this but all of the CNRs to have both receiving and sending HEI ID parameters as required.
And maybe setting an effective date for new API versions would be motivating as well as deprecating old APIs after a while with a pre-announced effective date.

From version v5.1.0 of the https://github.com/erasmus-without-paper/ewp-specs-api-discovery no extra parameters to identify sender/receiver are needed as "A unique key is enough to identify the sender/caller, and a unique service URL (API) to identify the recipient/callee".


Better logging in E2E tests.

This PR improves logging in GH actions. Now, The besides the test status (FAILED, SKIPPED) also reason is given e.g. Can't connect to the device... or Pipeline crashed etc.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 33.20%. Comparing base (37a2d92) to head (8c20ec0).
Report is 6 commits behind head on main.

:white_check_mark: All tests successful. No failed tests found.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #133      +/-   ##
==========================================
- Coverage   33.40%   33.20%   -0.21%
==========================================
  Files          68       68
  Lines        3739     3765      +26
==========================================
+ Hits         1249     1250       +1
- Misses       2490     2515      +25

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Over the network install doesn't work. It fails in pc but says it was succefull in 3ds.

Seconded. Just had SocketPunch fail while the 3ds said that the install had succeeded. Tried this with a small file and a 1.6 GB file

This release is supposed to work:
https://gbatemp.net/threads/release-socketpunch-fbi-network-cia-installer-for-android-pc.412174/page-16#post-6254075

Old utilities and older versions of sockfile are not supported.


Add open() method signature to FloorDatabase class.

This is handy once the generated classes reside in a different package, then _$AppDatabase becomes unreachable. So the abstract AppDatabase class would have the signature of open() while the generated code adds the @override annotation so to keep the linter happy.

Hi @noordawod, what's your use case for this? It should be the same as opening the database by using the database builder.

@vitusortner
Tried explaining my usecase in the previous comment, so I'll try again.
I architectured my app in such a way that the data model lives in its own module. The data model contains Floor and all its generated code. In this way, however, _$AppDatabase is basically inaccessible. I could add a signature for open() in the abstract AppDatabase class annotated with @Database, but there should be an @override annotation there too.
The reason this is good is that I could just reference FloorDatabase instead of AppDatabase in method/function signatures, like so:
Future<void> ensureDatabaseOpen(covariant FloorDatabase db) {
  return db.open(...);
}

There's no need to specifically request that the passed parameter is a specific database class (like AppDatabase). It makes more sense when creating multiple schemas, for example.
Lastly, I could argue that a class that has a close() method should also have an open() counterpart.

What do you say @vitusortner?

What do you say @vitusortner?

Refactored my use case, no need for this anymore.


Tick rendering in Firefox

The tick that is added using the class show-tick doesn't render nicely in Firefox (checked in FF 72 on Windows 10)
bootstrap-select v1.13.12
jQuery v3.4.1
Bootstrap v4.4.1
To reproduce the problem, open https://plnkr.co/edit/RHA12B5OFfxR2jqg5EEQ?p=preview in Firefox and select an option from the dropdown. The displayed tick is split into three parts by small lines.
This could be remedied by adding the following CSS to the stylesheet.
.bootstrap-select .bs-ok-default::after { transform-style: preserve-3d; }

This seems to be fixed in Firefox 75 on Windows 10, but I'll be happy to take another look if you're still having problems.

I can still reproduce it on my copy of Firefox 75 on Windows 10. Could it
be dependent on screen resolution? Either way my suggested fix resolves the
issue.
[image: image.png]
On Wed, 22 Apr 2020 at 18:24, Casey Holzer<EMAIL_ADDRESS>wrote:

This seems to be fixed in Firefox 75 on Windows 10, but I'll be happy to
take another look if you're still having problems.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/snapappointments/bootstrap-select/issues/2381#issuecomment-617918373,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOKZWHXYKBKM5CIRKCK4JALRN4R5HANCNFSM4KJWASJA
.

Looks like there were some issues with the image you tried to include.

Sorry, I just replied inline to the email and it obviously doesn't like images being supplied in that way. Hopefully this will work!

Thanks! I see what you're talking about (although I'm still unable to reproduce it on my computer). What resolution is your screen? Do you have a retina or 4K display?

It's nothing special - just a fairly standard 27" Benq GW2760, running at
1920x1080
On Fri, 24 Apr 2020 at 20:20, Casey Holzer<EMAIL_ADDRESS>wrote:

Thanks! I see what you're talking about (although I'm still unable to
reproduce it on my computer). What resolution is your screen? Do you have a
retina or 4K display?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/snapappointments/bootstrap-select/issues/2381#issuecomment-619196734,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOKZWHUX3NJOXCJCKCNQY23ROHRANANCNFSM4KJWASJA
.

I was able to recreate this with a different screen.

Released in v1.13.16!


[Misc] Code cleanliness

Looks great, most of the files has been built using a tab indentation of 4 while Github appears to use 8 by default. It looks much better now.

Accepted, thanks for your contribution. :+1:


Windows Support [$30]

hey @quarnster,
I'm going to take on the task of the windows port.
I should have it done fairly soon.
I have discovered linking errors with mingw64 and go lang and a patch should be pushed in to the mingw64-crt soon to resolve the last linking error of pygo and other c binded depends.

---
There is a **[$30 open bounty](https://www.bountysource.com/issues/1439455-windows-support?utm_campaign=plugin&utm_content=tracker%2F282001&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F282001&utm_medium=issues&utm_source=github).

Can this thread be reset into new issue with status update?

@techtonik No need to close :)
I will try updating the packages we have for go and do a few patches on them to see where we stand on this now

Okay so it seems that currently we are still at the same stage where part of the go language itself does not work properly on windows.
I am exploring 2 different possible solutions to this.
Both will require a bit of time to test.
I'll be back in about a week with an update

Week is passed. This issue needs to be reticketed with short summary - for it is impossible to take action on it given all the limitation of real life and free time.

martell, which part of the go language fails to work properly on windows? Also I think you mean the go implementation rather than the language itself?

Hi! What news about porting on windows? Do you have any progress?

I don't entirely know what the problems used to be, but Lime-QML builds and runs fine for me in Windows. Here's my instructions: https://github.com/ricochet1k/lime-qml/wiki/Building-on-Windows-using-MSYS2

The year is 2017, the month is June, i.e. 1250 days passed since issue was created.
Err… Hello? Could we try some pre-compiled Windows binary at last, please?

have discovered linking errors with mingw64 and go lang and a patch
should be pushed in to the mingw64-crt soon to resolve the last linking
error of pygo and other c binded depends

unsub me from this

Here..


[FLOC-2628] Don't use /tmp

The error in http://build.clusterhq.com/builders/flocker-centos-7/builds/5503/steps/trial/logs/stdio seems to be caused by /tmp running out of space. Don't use it and create a temporary path within trial's temp on the regular filesystem.

The theory about /tmp sounds right and I agree that we shouldn't be using /tmp in our tests, but I wasn't able to reproduce the error when running a container with a volume backed by a full tmpfs in our vagrant dev environment.
Here's what I did
[vagrant@localhost ~]$ sudo mount -t tmpfs -osize=1M tmpfs /foo
[vagrant@localhost ~]$ dd if=/dev/zero of=/foo/bar
dd: writing to ‘/foo/bar’: No space left on device
2049+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.00227618 s, 461 MB/s
[vagrant@localhost ~]$ df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root  8.5G  2.2G  6.4G  26% /
devtmpfs                 236M     0  236M   0% /dev
tmpfs                    245M     0  245M   0% /dev/shm
tmpfs                    245M  8.3M  237M   4% /run
tmpfs                    245M     0  245M   0% /sys/fs/cgroup
/dev/sda1                497M  152M  346M  31% /boot
none                     469G   84G  386G  18% /vagrant
tmpfs                    1.0M  1.0M     0 100% /foo

[vagrant@localhost ~]$ sudo docker run --env 'CUSTOM_ENV_A="a value" CUSTOM_ENV_B="another value"' --volume /foo:/var/lib/data openshift/busybox-http-app
Serving /usr/mock/source/ on port 8080...
^C

[vagrant@localhost ~]$ ls -l /foo/
total 1024
-rw-rw-r-- 1 vagrant vagrant 1048576 Jul 10 13:45 bar
[vagrant@localhost ~]$ df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root  8.5G  2.2G  6.4G  26% /
devtmpfs                 236M     0  236M   0% /dev
tmpfs                    245M     0  245M   0% /dev/shm
tmpfs                    245M  8.3M  237M   4% /run
tmpfs                    245M     0  245M   0% /sys/fs/cgroup
/dev/sda1                497M  152M  346M  31% /boot
none                     469G   84G  386G  18% /vagrant
tmpfs                    1.0M  1.0M     0 100% /foo

[vagrant@localhost ~]$ echo moo | sudo tee /foo/baz
moo
tee: /foo/baz: No space left on device

I also searched the test.log file accompanying that failed build and couldn't find any sign of an out of space error.
BUT
I can recreate that error with a simple busybox container.
[vagrant@localhost ~]$ sudo docker run --env 'CUSTOM_ENV_A="a value" CUSTOM_ENV_B="another value"' --volume /foo:/var/lib/data busybox 'echo x > /var/lib/data/richard'
exec: "echo x > /var/lib/data/richard": stat echo x > /var/lib/data/richard: no such file or directory
FATA[0000] Error response from daemon: Cannot start container 320d0c6fa583c10a3c8d927dc4eacbf7830675b277165f0b28c6ec0b24cde767: [8] System error: exec: "echo x > /var/lib/data/richard": stat echo x > /var/lib/data/richard: no such file or directory

And the error appears in docker logs.
Jul 10 13:56:27 localhost.localdomain docker[906]: Cannot start container 320d0c6fa583c10a3c8d927dc4eacbf7830675b277165f0b28c6ec0b24cde767: [8] System error: exec: "echo x > /var/lib/data/richard": stat echo x > /var/lib/data/richard: no such file or directory
Jul 10 13:56:27 localhost.localdomain docker[906]: time="2015-07-10T13:56:27Z" level=info msg="-job start(320d0c6fa583c10a3c8d927dc4eacbf7830675b277165f0b28c6ec0b24cde767) = ERR (1)"
Jul 10 13:56:27 localhost.localdomain docker[906]: time="2015-07-10T13:56:27Z" level=error msg="Handler for POST /containers/{name:.*}/start returned error: Cannot start container 320d0c6fa583c10a3c8d927dc4eacbf7830675b277165f0b28c6ec0b24cde767: [8] System error: exec: \"echo x > /var/lib/data/richard\": stat echo x > /var/lib/data/richard: no such file or directory"
Jul 10 13:56:27 localhost.localdomain docker[906]: time="2015-07-10T13:56:27Z" level=error msg="HTTP Error: statusCode=404 Cannot start container 320d0c6fa583c10a3c8d927dc4eacbf7830675b277165f0b28c6ec0b24cde767: [8] System error: exec: \"echo x > /var/lib/data/richard\": stat echo x > /var/lib/data/richard: no such file or directory"

The error isn't quite the same but perhaps that's because I'm using a different version of Docker.

So...I'm not 100% convinced that this will fix the flaky test but it might!
So let's merge it when you've got the rackspace + ubuntu-14.04 acceptance tests to pass.

So...I'm not 100% convinced that this will fix the flaky test but it might!
So let's merge it when you've got the rackspace + ubuntu-14.04 acceptance tests to pass.

I don't think this is the right conclusion to draw.  We should merge changes that do fix problems, not changes that might fix problems.

I can recreate that error with a simple busybox container.

I think that error is happening there because you override the command (if there is one) inside the busybox container when it runs with the echo x > /var/lib/data/richard command and it ends up trying to execute that before it's done the mount binding of /foo on host to /var/lib/data in the container, so in other words, /var/lib/data doesn't exist yet at that point.

hence why one succeeds and one fails...
(flocker4)dave@dave-ThinkPad-X230:~/flocker$ sudo docker run -t -i --env 'CUSTOM_ENV_A="a value" CUSTOM_ENV_B="another value"' --volume /tmp:/var/lib/data openshift/busybox-http-app '/bin/sh'
/ # echo x > /var/lib/data/dave1
/ # cat /var/lib/data/dave1
x
/ # (flocker4)dave@dave-ThinkPad-X230:~/flocker$ sudo docker run -t -i --env 'CUSTOM_ENV_A="a value" CUSTOM_ENV_B="another value"' --volume /tmp:/var/lib/ openshift/busybox-http-app 'echo x > /var/lib/data/dave1'
exec: "echo x > /var/lib/data/dave1": stat echo x > /var/lib/data/dave1: no such file or directory
Error response from daemon: Cannot start container 444acbbec363fe360761522a9d4e4708eaab7a9e498375cd43b2a48ecbb500d5: [8] System error: exec: "echo x > /var/lib/data/dave1": stat echo x > /var/lib/data/dave1: no such file or directory

so it's not a reproduction of exactly what's happening when the affected test fails, I still suspect that's some tmpfs related behaviour as a result of mounting from /tmp on the host - that is, if /tmp on that build slave is using tmpfs, I guess it might not be. But I struggle to see any other likely explanation here.

Also @exarkun I think the fact that /tmp is unpredictable depending on the set-up of the host, e.g. is it volatile memory, is it a regular directory under a single-partition system (as is typically the case on Ubuntu), this is probably a good reason to not use it in our tests anyway.

Also @exarkun I think the fact that /tmp is unpredictable depending on the set-up of the host, e.g. is it volatile memory, is it a regular directory under a single-partition system (as is typically the case on Ubuntu), this is probably a good reason to not use it in our tests anyway.

That's fine.  I'm not sure why we were using it in the first place here.  The change is reasonable - it just doesn't fix FLOC-2628.

So we are definitely seeing something odd here, where the bind mount has not completed before the non-default command is run
(flocker4)dave@dave-ThinkPad-X230:~/flocker$ sudo docker run -t -i --env 'CUSTOM_ENV_A="a value" CUSTOM_ENV_B="another value"' --volume /tmp:/var/lib/data openshift/busybox-http-app 'echo x > /var/lib/data/dave1'
exec: "echo x > /var/lib/data/dave1": stat echo x > /var/lib/data/dave1: no such file or directory
Error response from daemon: Cannot start container 816a41e36200955e39d267daec3091ae0bafa8264f268f9971a6a769420a72ae: [8] System error: exec: "echo x > /var/lib/data/dave1": stat echo x > /var/lib/data/dave1: no such file or directory
(flocker4)dave@dave-ThinkPad-X230:~/flocker$ docker run -t -i --env 'CUSTOM_ENV_A="a value" CUSTOM_ENV_B="another value"' --volume /tmp:/var/lib/data openshift/busybox-http-app 'echo x > /var/lib/data/dave1'
exec: "echo x > /var/lib/data/dave1": stat echo x > /var/lib/data/dave1: no such file or directory
Error response from daemon: Cannot start container 88235cde62510f50edf8d2acfe8f9b52929fa68aa50463678b4c9d75fcf692b8: [8] System error: exec: "echo x > /var/lib/data/dave1": stat echo x > /var/lib/data/dave1: no such file or directory
(flocker4)dave@dave-ThinkPad-X230:~/flocker$ docker -v
Docker version 1.7.0, build 0baf609
(flocker4)dave@dave-ThinkPad-X230:~/flocker$

If I build an image in the form of
FROM openshift/busybox-http-app
CMD echo x > /var/lib/data/dave1

It can run fine with docker run --env 'CUSTOM_ENV_A="a value" CUSTOM_ENV_B="another value"' --volume /tmp:/var/lib/data gebler/data1 where gebler/data1 is the image built from that Dockerfile.

The error there is "I looked for an executable named echo x > /var/lib/data/dave1 to execute and I couldn't find it."
You want to run /bin/sh -c "..." as the command.

You want to run /bin/sh -c "..." as the command.

Sneaky - you don't have to do that in a Dockerfile CMD when you specify the whole command as a single string, it runs it through shell automatically.

That's fine. I'm not sure why we were using it in the first place here. The change is reasonable - it just doesn't fix FLOC-2628.

Ok. I created https://clusterhq.atlassian.net/browse/FLOC-2636 and #1765


Add benchmarks for evaluating performance

This PR adds a system for running benchmarks, built with the same structure as the rendering tests.
Use npm run benchmarks.
Benchmarks are simple scripts in the /rendering/benchmark/<name>/ directory where a map is created and animated. These scripts are then run using Puppeteer.
The benchmark server exposes an endIteration() function which should be called when the animations are done. Also the benchmark script must define a startIteration() function on its window object, which will be called when a new iteration must be started.
The result of the benchmark is currently two values : average frame time and max frame time. An HTML report can be generated using --report option.
Please note: to achieve this, a new map event was added: prerender.
Currently only one benchmark is defined which consists of a map with a vector tile layer and a zoom in/zoom out animation. The tiles used in the benchmark are stored on the disk.
Example output:
$npm run benchmarks

><EMAIL_ADDRESS>benchmarks
> node rendering/benchmark.js --iterations 20 --log-level info

benchmark server listening http://<IP_ADDRESS>:3000/
wait until bundle finished: /benchmarks/vectortile-animation/main.js
   258 modules
Compiled successfully.
./benchmarks/vectortile-animation/main.js - benchmark finished
Maximum frame time: 118.2ms
Average frame time: 15.1ms

The benchmarks results are not saved as an artefact in circleci, for example:
https://314-4723248-gh.circle-artifacts.com/0/benchmarks/vectortile-animation/benchmark.json

To compare the benchmark results we could:

save the benchmark results from the master branch (in circleci, using save_cache ?)
on every build, compare with master

@fredj I thought that maybe the circleci config could have a conditional step which would be something like git checkout -- src/ && npm run benchmarks --json-report report-master.json, only run when not on the master branch. And then upload both report.json and report-master.json as artifacts.
Eventually we may implement a very simple service to upload benchmark results and output a nice graph somehow...

@tschaub I've tried rebasing this branch locally on master (after the merge of the composite branch) and the benchmarks failed at around 25 iterations, most likely because of a memory leak. You can see it happening by launching the benchmarks with --headless false.
I'll try to research this more if I have time for this, but this was just to let you know.
Here is the complete log with --log-level debug:
iteration 1 ended - average 7.6ms / max 120.3ms
iteration 2 ended - average 7.0ms / max 110.2ms
iteration 3 ended - average 7.2ms / max 110.7ms
iteration 4 ended - average 11.4ms / max 339.3ms
iteration 5 ended - average 7.4ms / max 102.9ms
iteration 6 ended - average 7.9ms / max 127.0ms
iteration 7 ended - average 7.8ms / max 115.4ms
iteration 8 ended - average 8.7ms / max 119.6ms
iteration 9 ended - average 24.1ms / max 603.7ms
iteration 10 ended - average 8.9ms / max 145.4ms
iteration 11 ended - average 9.8ms / max 95.0ms
iteration 12 ended - average 10.3ms / max 115.6ms
iteration 13 ended - average 15.7ms / max 132.2ms
iteration 14 ended - average 24.4ms / max 216.2ms
iteration 15 ended - average 12.8ms / max 179.0ms
iteration 16 ended - average 21.2ms / max 166.8ms
iteration 17 ended - average 23.4ms / max 230.6ms
iteration 18 ended - average 84.9ms / max 304.3ms
iteration 19 ended - average 22.9ms / max 246.6ms
iteration 20 ended - average 168.5ms / max 489.9ms
iteration 21 ended - average 19.7ms / max 241.1ms
iteration 22 ended - average 570.7ms / max 1493.6ms
iteration 23 ended - average 22.1ms / max 218.5ms
iteration 24 ended - average 344.4ms / max 1706.6ms
page crash Error: Page crashed!
    at Page._onTargetCrashed (/home/oguyot/dev/openlayers/node_modules/puppeteer/lib/Page.js:176:24)
    at CDPSession.Page.client.on.event (/home/oguyot/dev/openlayers/node_modules/puppeteer/lib/Page.js:138:56)
    at emitOne (events.js:115:13)
    at CDPSession.emit (events.js:210:7)
    at CDPSession._onMessage (/home/oguyot/dev/openlayers/node_modules/puppeteer/lib/Connection.js:216:12)
    at Connection._onMessage (/home/oguyot/dev/openlayers/node_modules/puppeteer/lib/Connection.js:99:19)
    at WebSocketTransport._ws.addEventListener.event (/home/oguyot/dev/openlayers/node_modules/puppeteer/lib/WebSocketTransport.js:41:24)
    at WebSocket.onMessage (/home/oguyot/dev/openlayers/node_modules/puppeteer/node_modules/ws/lib/event-target.js:120:16)
    at emitOne (events.js:115:13)
    at WebSocket.emit (events.js:210:7)

Any progress/news on this issue?
I'm trying to debug some performance issues with big datasets on a vector source (geojson) and stumbled over this issue.

Eventually we started looking into running benchmarks using an third party application, namely: https://github.com/jahow/ol-benchmarks
Although this is still WIP (hence why this issue is still open).


branch-3.0 Pick 6 commits

Proposed changes
pick #39982 #41292 #40576 #41555 #41589 #41592

run buildall

run buildall

run buildall


updated issue with the popup content

This PR closes #1262 with modification of popup content about signup and signin , previously it looks something like this

The text content is getting overflowed because of some issue with the styling, it is not given enough width and it is getting overflowed, the full content is not visible.
After modifying the code it looks something like this , the contents are clearly visible, no overflow, everything looks perfect

@pa1narendra
Please see the conflicts . Resolve the conflicts . Ensure you pull all the latest changes before pushing your feature/bug fixes to the main branch. After resolving the conflicts, please open a new PR for review.
Thank you!

@PriyaGhosal , I opened a new PR resolving all the conflicts and fixed the issue with the popup content as well as the scroll to the top button/icon please take a look at it and let me know if there are any issues and this PR is moved to #1315


fix(data/dungeons): remove duplicate 'of' from aspect descriptions

The descriptions for the aspects obtained from dungeons had a duplicate 'of' i.e. 'Aspect of of Berserk Ripping'.
This removes the duplicate.

Will add this fix to my generation pipeline as well.


chore(deps): update testcontainers-scala-postgresql, ... to 0.41.2

About this PR
📦 Updates

com.dimafeng:testcontainers-scala-postgresql
com.dimafeng:testcontainers-scala-scalatest

from 0.41.0 to 0.41.2
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.dimafeng" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.dimafeng" }
}]

labels: test-library-update, early-semver-minor, semver-spec-patch, commit-count:1

Superseded by #291.


A comment thread is not shown

Not sure whether it's an issue of Remark42 or some bug related to how it was installed. Please help if you can.
I was notified about a new comment via telegram, I opened the link and replied to the comment. Link to the comment: https://konstantin.ist/july-2019/?fbclid=IwAR1sX0aHpIlty0ae_1r105auzMPgGZBlioOupetoOx6Posbm64Kt2euE6Bg#remark42__comment-e1699883-dcb5-46fd-ba0d-e2e63eff49e1
However, if you open the URL of this blog post itself, this comment is not shown: https://konstantin.ist/july-2019/
The comments to the other blog posts work just fine though.

Hm, I see no comments either ways. There is no errors there, remark's api returns empty list. Though I see comments for previous post. Can you elaborate a bit, what should I see there? Maybe screenshot?

Thank you for the response.
Here is what I see if I click on the first link

I see the first, but not the second. To me, it looks like the issue with URL mismatch as a comment created for URL  https://konstantin.ist/july-2019/?fbclid=IwAR1sX0aHpIlty0ae_1r105auzMPgGZBlioOupetoOx6Posbm64Kt2euE6Bg but a second link (https://konstantin.ist/july-2019/) is a short form of this, without query param

Thank you @umputun.
I am not a developer, so although I seem to understand what you meant, I can hardly imagine how to:
a) amend this particular comment so that it shows below the post
b) prevent this from happening again. Seems like the lady who commented the post found the link on facebook, hence the query parameter in URL.
Would appreciate if you advised on this.

How do you see comments? I'm have nothing. https://remark.konstantin.ist/api/v1/find?site=konstantin.ist&url=https://konstantin.ist/july-2019/&sort=-active&format=tree returns
{"comments":[],"info":{"url":"","count":0,"first_time":"0001-01-01T00:00:00Z","last_time":"0001-01-01T00:00:00Z"}}

How do you see comments? I have nothing.

Hey @Reeywhaar, not sure whether your question was addressed to me, but seems like @umputun  has already found out where the problem lies (see above).
Any chance to get fix suggestions?

@Reeywhaar - your url param is wrong. You need the full thing, with fbclid part, like it is in the first link.
@kostimoshenko - Remark42 (backend) links comment to posts by url passed in. The frontend uses the link of the active window to figure what is the post URL. In this particular case query params seem to play no role in identifying the post, but I can imagine opposite cases. @Reeywhaar - I don't see any generic solution for this issue and the only suggestion I have is to add UI conf/param enforcing use of "naked url", i.e. trimming all query params.
Note: back in days I used disqus I run into a similar issue a couple of times. Their solution was different but confusing - admin UI allowed to change the "matching link"

@kostimoshenko - as a quick fix suggestion I could recommend striping url params on your side. I'm not sure what blog engine you use and how pages generated, but most likely you run some reverse proxy (nginx or smth like this) in front and you can add a redirect from {url}/?params to {url}. It will not fix the current comment but will prevent such issues from happening again

Unfortunately, there is no built-in editor or API to change the link in the store. We may add such API and UI support someday, but as of now, your best bet is to export remark42 data, edit the link and import.
You can also try to use some external "boltdb ui/editor" and change the link directly. The post you are looking for in the bucket "posts" and you will need to change both bucket key and edit the value as well.
Probably, you would like to stop remark42 and copy your *.db file before you do any of this.

@umputun, first method worked just fine, thank you for the suggestion.
And I would also like to separately thank you for a wonderful commenting system. It's really good as it is now, but seems like with all the efforts you keep putting in it, it is definitely destined to become even better


VR issues

VR is not well supported, many bugs.
We are unable to test atm

We played a bit in VR (both client and host) and we could not find any VR-related issues, everything worked very well.
Only thing that we found is the player name marker on the map, it is 3D, hovering above the map:
https://github.com/user-attachments/assets/30bfe3ec-d02c-40c9-8442-a4775e927732
But this is very minor.
Feel free to reply here if you need any more tests done in VR.


Unable to resolve "./native.mjs"

Current Behavior
Unable to resolve "./native.mjs" from<EMAIL_ADDRESS>›

I've double checked that mjs is in my sourceExts (I use expo sdk 50)
config.resolver.sourceExts [
  'ts',  'tsx',  'mjs',
  'js',  'jsx',  'json',
  'cjs', 'scss', 'sass',
  'css', 'glsl', 'wgsl',
  'sql'
]

Expected Behavior
The native.mjs file should be in the @tamagui/helpers package's dist/esm folder
Tamagui Version
1.89.2

Platform (Web, iOS, Android)
expo sdk 50.0.5

Reproduction
https://www.npmjs.com/package/@tamagui/helpers?activeTab=code

See screenshot of npm files in `dist/esm` missing `native.mjs`.

System Info
> npx envinfo --system --npmPackages --binaries --browsers

  System:
    OS: macOS 14.1.2
    CPU: (8) arm64 Apple M1 Pro
    Memory: 80.13 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.19.0 - /nix/store/6x8nm7kgdj2v79mwkjrqaj12rwwdzn50-nodejs-18.19.0/bin/node
    Yarn: 4.0.2 - /nix/store/9ibfxlr2wa5sf2aks79zl10rq9c4c78s-yarn-1.22.21/bin/yarn
    npm: 10.2.3 - /nix/store/6x8nm7kgdj2v79mwkjrqaj12rwwdzn50-nodejs-18.19.0/bin/npm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 121.0.6167.139
    Safari: 17.1.2
    Safari Technology Preview: 17.4
  npmPackages:
    expo-constants: 15.4.3 => 15.4.3
    expo-router: 3.4.2 => 3.4.2

This should be fixed I renamed the file. Naming a file native is dangerous due to react native platform suffix.


Fix nested list parsing

Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.
Fixes
If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce to agents-aea?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist
Put an x in the boxes that apply.

[ ] I have read the CONTRIBUTING doc
[ ] I am making a pull request against the develop branch (left side). Also you should start your branch off our develop.
[ ] Lint and unit tests pass locally with my changes and CI passes too
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked that code coverage does not decrease.
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in downstream modules

You can test this change using following script
import json

from aea.helpers.env_vars import apply_env_variables, generate_env_vars_recursively

vars = {
    "dust_threshold":<PHONE_NUMBER>0000,
    "conditional_tokens_address": "0xCeAfDD6bc0bEF976fdCd1112955828E00543c0Ce",
    "slippage": 0.01,
    "stratagies_kwargs": [
        ["bet_kelly_fraction", 0.25],
        ["floor_balance",<PHONE_NUMBER>00000000],
        [
            "bet_amount_per_threshold",
            {
                "0.0": 0,
                "0.1": 0,
                "0.2": 0,
                "0.3": 0,
                "0.4": 0,
                "0.5": 0,
                "0.6":<PHONE_NUMBER>0000000,
                "0.7":<PHONE_NUMBER>0000000,
                "0.8":<PHONE_NUMBER>00000000,
                "0.9":<PHONE_NUMBER>000000000,
                "1.0":<PHONE_NUMBER>0000000000,
            },
        ],
    ],
    "file_hash_to_strategies_json": [
        [
            "bafybeifr5cr2pbvhiwpqyqmuh7cfztaph2vzblxan7fclxawndipnehv3i",
            ["bet_amount_per_threshold"],
        ],
        [
            "bafybeigqgurbw3rsr7ick4pk46iz2zusdbnriac3hteopdj2gm5bpisew4",
            ["kelly_criterion"],
        ],
    ],
    "configs": [
        {"foo": "bar"},
        {"hello": "world"},
    ],
    "numbers": [1, 3, 4],
}

generated = generate_env_vars_recursively(
    data=vars,
    export_path=["skills", "trader_abci", "models", "params", "args"],
)

check = {
    "dust_threshold": "${int:null}",
    "conditional_tokens_address": "${str:null}",
    "slippage": "${float:null}",
    "stratagies_kwargs": "${list:[]}",
    "file_hash_to_strategies_json": "${list:[]}",
    "configs": [{"foo": "${str:null}"}, {"hello": "default"}],
    "numbers": "${list:[]}",
}

check = apply_env_variables(
    data=check,
    env_variables=generated,
    path=["skills", "trader_abci", "models", "params", "args"],
)

print(
    json.dumps(
        check,
        indent=4,
    )
)

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (e3b608a) 90.21% compared to head (326a54a) 90.22%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #700   +/-   ##
=======================================
  Coverage   90.21%   90.22%
=======================================
  Files         371      371
  Lines       29795    29812   +17
=======================================
+ Hits        26881    26897   +16
- Misses       2914     2915    +1

Flag
Coverage Δ

unittests
90.22% <100.00%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


VitBert_MLM

Created the MLM model for ViTBERT following flaxbertMLM

@NilakshanKunananthaseelan Thanks for working on this.
I would expect you to add your changes to modeling_vit_bert.py and please remove the notebook.


Ability to extend existing selectors

It would be great if we had the ability to also extend existing selectors (similar to how you can in Sass):
My use case for this is when you can't always restructure your code to have everything extending an initial @define, like when you want to extend a class from a library:
@import 'suitcss-utils'; // contains .u-cf...

.SomeClass {
  color: red;
}
.List--plain {
  @extend .u-cf;
  @extend .SomeClass;
}

I just read the README, and it seems this is intentional :)
However, I'll leave this open if you have any specific thoughts on my use case.

I will leave this open because it's a possibility worth considering. Your use-case makes sense, of course, as an argument in favor of adding this functionality.
Open to pull requests; and at some point I'll try to sit down myself and work on it.

Sounds good.

A hurdle: If we build in the functionality to extend regular selectors, this is no longer postcss-simple-extend: it's not simple anymore. Would it make sense to rename the plugin? If so --- what's a good name, since postcss-extend is already taken?

Good point.
You could use NPM's shiny new scopes: http://blog.npmjs.org/post/116936804365/solving-npms-hard-problem-naming-packages
Or, just brainstorming:
postcss-at-extend
postcss-extend-rule

Just a note: the more I'm getting into PostCSS the more I'm wanting a full-featured @extend.
I agree it's use is not without caveats, but those can really be managed with responsible use.
So, I'm excited to hear you're open to it. If I get some time, I may try to dig in.

I think there is still a step that could be take to make postcss-simple-extend cover my use-case, without getting into the complexities mentioned here in a full-featured extend.
For example, "simple" could refer to the fact that you're limited to extending simple selectors, e.g.
.foo {
  display: block;
}

.foo a {
  color: red;
}

.bar {
  @extend .foo;
  background: blue;
}

Would expand to:
.foo,
.bar {
  display: block;
}

.foo a,
.bar a {
  color: red;
}

.bar {
    background: blue;
}

However, this would be disallowed. Sass allows you to do this, but it seems like way more trouble than it's worth:
.bar {
  @extend .foo a;
  background: blue;
}

Media query example
Since Media query rules cannont be combined, this either needs to be disallowed, or ideally duplicated only once per media scope:
.foo {
  content: 'foo';
}

@media (min-width: 500px){
  .bar {
    @extend .foo;
  }
  .baz {
    @extend .foo;
  }
}

Expands to:
.foo {
  content: 'foo';
}

@media (min-width: 500px){
  .bar,
  .baz {
    content: 'foo';
  }
}

I think those are still some not-insignificant complications. Not as complicated as Sass's extend, you're right, but pretty significant nonetheless. I'm open to a PR, but might no get to myself for a little while.

Good article here by Philip Walton - http://philipwalton.com/articles/extending-styles/
Feel like that's a really nice use case for a full featured extend

Thanks @simonsmith.  I just don't have the time to build it right now; and until it's built the simple-extend is serving my needs. If anybody else wants to get started on that full extend, I'll be happy to pitch in at some point.

After looking at https://tech.bellycard.com/blog/sass-mixins-vs-extends-the-data/ I'm wondering if extending selectors from libraries is in fact the only reason to use extends ...

@davidtheclark interesting!
Whether or not the extend extends selectors or merely duplicated properties like a mixin, I still think an example like this is valid:
.PromoButton {
  @extend .Button;
  @extend .Header-item;
  /* Optional additional styles... */
}

Using mixins would require you to go back, make the .Button properties a mixin, and apply it to .Button and .PromoButton. To me, thats a big enough inconvenience.
We have a fork that should be ready for testing soon with extendable classes.

Yeah, I've been thinking about it more and do think that the fact that there's not filesize difference means that extending real selectors still has a couple of uses while maybe placeholder selectors are unimportant --- the very stuff this plugin currently does :)
I just read http://www.smashingmagazine.com/2015/05/04/extending-in-sass-without-mess/ and it explains a lot of finer points about how selectors are extended in Sass -- if you're intereseted.

@davidtheclark Yeah some of the Sass stuff outline in that article is bonkers to me.
We're starting out by saying something is only extendable when there is an exact selector match.
So the craziest you can get, would be (not that I would ever suggest doing this):
.foo .bar {
  color: red;
}

.baz {
  @extend .foo .bar;
}

Cool.
I'm wondering: Would your patch address https://github.com/davidtheclark/postcss-simple-extend/issues/2?
Also, @timkelty: If you're interested in working on a more complete @extend plugin, the @postcss/owners are open to it, especially if it approaches the spec draft closely enough that @MoOx might integrate it with cssnext. Something to think about.

Forget to reference: https://github.com/postcss/postcss/issues/321

@davidtheclark our patch doesn't address #2.
We had it working if it was just jumping up one level of recursion, but beyond that it wouldn't work, so for now we're disabling any recursion.

@davidtheclark As much as I love completely turning around what Tim said (just two days later) it looks like we're going to be able to address #2 (and by extention flip CSS on it's head with the ability to recursively extend things that haven't even been declared yet in some cases)
.bravo {
  @extend .charlie;
  color: blue;
  background: purple;
}
.charlie {
  @extend .delta;
  color: red;
  background: orange;
}
.delta {
  color: green;
  background: gray;
}
.echo {
  color: blue;
  background: purple;
}
.foxtrot {
  @extend .echo;
  color: red;
  background: orange;
}
.gulf {
  @extend .foxtrot;
  color: green;
  background: gray;
}
----------------Processing:----------------
.bravo {
  color: blue;
  background: purple;
}
.bravo, .charlie {
  color: red;
  background: orange;
}
.bravo, .charlie, .delta {
  color: green;
  background: gray;
}
.echo, .gulf, .foxtrot {
  color: blue;
  background: purple;
}
.gulf, .foxtrot {
  color: red;
  background: orange;
}
.gulf {
  color: green;
  background: gray;
}

Hooray!

Very cool

Users who want these kinds of powers can now use https://github.com/travco/postcss-extend


Problem building with Umbraco 13

It would appear that the dependency on Contentment causes a build failure in Umbraco 13. (I triead installing Contentment on it's own and get the same issues)

seems it was a nuget cache problem. I cleared my local cache and then reinstalled and all now working


Ruff fails with memory allocation of X bytes failed

Hi guys,
for some time now, ruff has been failing with error "memory allocation of<PHONE_NUMBER>139656813 bytes failed" if I run it for a specific file with option --force-exclude. Without it, is works fine, but includes excluded files for which it runs. It is working fine when checking the whole project, but I also use it among file watchers in Pycharm where it fails. I am using a custom config with some file exclusions, so in order to avoid ruff reports for excluded files, I need --force-exclude option. However, the file watcher has not been working properly for me, not from start, but for some time now, could be weeks or months. It only happens in one of my bigger projects, so it does not seem broken, maybe only demanding somehow. It does not bother me much, because it is so fast I can run it for the whole project instantly. :-)
Python: 3.8
Ruff: 0.0.292
Do you have any idea what could be causing this? Thanks

Hi! Is this with the ruff check command? Could you include an example full invocation of the command? Glad you've found a workaround in the meantime.
The stack trace from a debug build (e.g. clone the repository, cargo build, and use ./target/debug/ruff with RUST_BACKTRACE=1) would be useful too.

Hi, yeah, it is the check command, the full invocation looks like this:
<path-to-ruff> --config <path-to-toml> --force-exclude --quiet <path-to-file>

I noticed that yesterday too. It can happen if the caches are incompatible. I'm surprised you run into this because the ruff version is part of the cache key: Different ruff versions should never use the same cache. At least, that's how it's supposed to work.
Do I understand it correctly that you use a pre-built ruff version (you're not building ruff yourself)?

Executing ruff clean helps as well. Now I can use cache again, against the same file, and it works. After the cache was built again, the file watcher still works for me. I am not sure how would the cache become corrupted on my side, I can come back if I notice it again, ideally with more info about what I did that could cause it. I always install new version using pip, I do not build it myself. Thanks for the help. Feel free to close the issue.

Thanks @harpener. Clad to hear that it helped. Yes, please come back if you run into the problem again. I'll keep this issue open for now to see if other users run into this problem as well.

I also ran into this problem and ruff clean fixed it.
I was not switching between Ruff versions (all stables on ruff 0.1.2) but was running Ruff over and over. At some seemingly-random point I ran ruff and got the error:
poetry run ruff . --fix
memory allocation of<PHONE_NUMBER>924727087 bytes failed
memory allocation of<PHONE_NUMBER>863120500 bytes failed
make: *** [ruff] Abort trap: 6

Thank you for reporting -- we'll investigate.

I suspect that we read an incompatible cache for whatever reason, which makes bincode incorrectly interpret some byte sequence as the array length, resulting in it allocating a insanely large array

I had same problem with bincode 1.3.3, when I changed cache format(from storing BtreeMap<String, Item> to Vec)
This was "fixed" in 1.3.1 release - https://github.com/bincode-org/bincode/pull/336, but I can still reproduce problem with 1.3.3 version.
Maybe this is already fixed with 2.0.0 version, but not tested it yet

New bincode issue - https://github.com/bincode-org/bincode/issues/676

So it is not really a bug in bincode, but by default it not limit allocation size, which may be really big in some situations(broken cache, changed save structure)
To fix problem, limits needs to be set - https://docs.rs/bincode/latest/bincode/config/trait.Options.html#method.with_limit and probably invalid cache files should be also deleted

Thanks.
I prefer identifying the root cause of this rather than hidding it with the size limit. Ruff shouldn't load incompstible caches, nor is it ever growing.

Thins I tried without success so far:

Run multiple instances of ruff at the same time, sporadically resetting the git cache (in the hope that they race on writing the cache)

I managed to capture a backtrace of the crash:
  21:        0x101b34604 - __rg_oom
                               at /rustc/a2f5f9691b6ce64c1703feaf9363710dfd7a56cf/library/std/src/alloc.rs:364:1
  22:        0x101bad1fc - alloc::alloc::handle_alloc_error::rt_error::h0b49241c647bd0ac
                               at /rustc/a2f5f9691b6ce64c1703feaf9363710dfd7a56cf/library/alloc/src/alloc.rs:383:13
  23:        0x101bad1fc - alloc::alloc::handle_alloc_error::h947fa5de62136ddf
                               at /rustc/a2f5f9691b6ce64c1703feaf9363710dfd7a56cf/library/alloc/src/alloc.rs:389:9
  24:        0x101a0e138 - alloc::raw_vec::handle_reserve::h68784d82265b35cc
                               at /rustc/a2f5f9691b6ce64c1703feaf9363710dfd7a56cf/library/alloc/src/raw_vec.rs:506:43
  25:        0x101ba9290 - alloc::raw_vec::RawVec<T,A>::reserve::do_reserve_and_handle::ha49ecf137cbb24a1
                               at /rustc/a2f5f9691b6ce64c1703feaf9363710dfd7a56cf/library/alloc/src/raw_vec.rs:289:13
  26:        0x101a0d504 - alloc::raw_vec::RawVec<T,A>::reserve::h99d157706d8f6389
                               at /rustc/a2f5f9691b6ce64c1703feaf9363710dfd7a56cf/library/alloc/src/raw_vec.rs:293:13
  27:        0x101a0d504 - alloc::vec::Vec<T,A>::reserve::h05ba621538aba417
                               at /rustc/a2f5f9691b6ce64c1703feaf9363710dfd7a56cf/library/alloc/src/vec/mod.rs:909:18
  28:        0x101a0a638 - alloc::vec::Vec<T,A>::extend_with::hc577c989726a2c72
                               at /rustc/a2f5f9691b6ce64c1703feaf9363710dfd7a56cf/library/alloc/src/vec/mod.rs:2534:9
  29:        0x101a0a96c - alloc::vec::Vec<T,A>::resize::hb21e03d42d0f7c1f
                               at /rustc/a2f5f9691b6ce64c1703feaf9363710dfd7a56cf/library/alloc/src/vec/mod.rs:2416:13
  30:        0x10073cc50 - bincode::de::read::IoReader<R>::fill_buffer::h1774c5c2f9bc7e8c
                               at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bincode-1.3.3/src/de/read.rs:144:9
  31:        0x10073cfa0 - <bincode::de::read::IoReader<R> as bincode::de::read::BincodeRead>::get_byte_buffer::h951d5d50670d2b39
                               at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bincode-1.3.3/src/de/read.rs:171:9
  32:        0x1006d8e00 - bincode::de::Deserializer<R,O>::read_vec::h17ca3b9d50b73b72
                               at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bincode-1.3.3/src/de/mod.rs:96:9
  33:        0x1006d8934 - bincode::de::Deserializer<R,O>::read_string::h51e7017758544173
                               at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bincode-1.3.3/src/de/mod.rs:100:19
  34:        0x1006da704 - <&mut bincode::de::Deserializer<R,O> as serde::de::Deserializer>::deserialize_string::hb3aa252b3728b54d
                               at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bincode-1.3.3/src/de/mod.rs:244:30
  35:        0x1006e9680 - serde::de::impls::<impl serde::de::Deserialize for alloc::string::String>::deserialize::hd78077d08aa2c9f6
                               at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.188/src/de/impls.rs:582:9
  36:        0x100682c8c - <core::marker::PhantomData<T> as serde::de::DeserializeSeed>::deserialize::h770e7118bcfe1463
                               at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.188/src/de/mod.rs:794:9
  37:        0x1006d6abc - <<&mut bincode::de::Deserializer<R,O> as serde::de::Deserializer>::deserialize_tuple::Access<R,O> as serde::de::SeqAccess>::next_element_seed::h7645625915be4900
                               at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bincode-1.3.3/src/de/mod.rs:314:25
  38:        0x1006d86ec - serde::de::SeqAccess::next_element::h93005d487dcc0a49
                               at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.188/src/de/mod.rs:1726:9
  39:        0x1006983f4 - <ruff_python_ast::imports::_::<impl serde::de::Deserialize for ruff_python_ast::imports::ModuleImport>::deserialize::__Visitor as serde::de::Visitor>::visit_seq::h8b7ad517c7ecda6b
                               at ~/ruff/crates/ruff_python_ast/src/imports.rs:123:49

Full trace here: https://gist.github.com/mrcljx/c0aa363ba32b16709d4d87a7c82278ae  -RUST_BACKTRACE=1 did not work OOTB, because Rust doesn't panic on OOM, it just aborts, so I had to build a debug build with Rust nightly and use set_alloc_error_hook:
diff --git a/crates/ruff_cli/src/bin/ruff.rs b/crates/ruff_cli/src/bin/ruff.rs
index 81830ca25..8cdfb5f43 100644
--- a/crates/ruff_cli/src/bin/ruff.rs
+++ b/crates/ruff_cli/src/bin/ruff.rs
@@ -1,3 +1,4 @@
+#![feature(alloc_error_hook)]
 use std::process::ExitCode;

 use clap::{Parser, Subcommand};
@@ -6,6 +7,13 @@ use colored::Colorize;
 use ruff_cli::args::{Args, Command};
 use ruff_cli::{run, ExitStatus};

+
+use std::alloc::{Layout, set_alloc_error_hook};
+
+fn custom_alloc_error_hook(layout: Layout) {
+   panic!("memory allocation of {} bytes failed", layout.size());
+}
+
 #[cfg(target_os = "windows")]
 #[global_allocator]
 static GLOBAL: mimalloc::MiMalloc = mimalloc::MiMalloc;
@@ -23,6 +31,7 @@ static GLOBAL: mimalloc::MiMalloc = mimalloc::MiMalloc;
 static GLOBAL: tikv_jemallocator::Jemalloc = tikv_jemallocator::Jemalloc;

 pub fn main() -> ExitCode {
+    set_alloc_error_hook(custom_alloc_error_hook);
     let args = wild::args_os();
     let mut args =
         argfile::expand_args_from(args, argfile::parse_fromfile, argfile::PREFIX).unwrap();

@mrcljx oh nice, thanks for capturing the stacktrace. Unfortunately, I'm still surprised why it tries to load a version-incompatible cache. Or is it that we have a incompatible Serialize and Deserialize implementation somewhere where serializing and deserializing again fails?
Anyone running into this issue and working on an open source project. Could you share the GitHub commit and upload your .ruff-cache directory. It would be a tremendous help fixing this issue.

I have the same issue, here's what my cache looks like:
ls -ltrh .ruff_cache/
total 8
-rw-r--r--     1 xxx  staff    43B Mar  6  2023 CACHEDIR.TAG
drwxr-xr-x  1136 xxx  staff    36K Nov  7 14:30 content
drwxr-xr-x    48 xxx  staff   1.5K Nov  8 10:29 0.1.4
drwxr-xr-x    54 xxx  staff   1.7K Dec  1 11:51 0.1.6

I looked at file size, there's nothing out of the ordinary, the biggest file is 1.1mb and the total size is 10mb.
--no-cache fixes it.

I have the same issue, here's what my cache looks like:
ls -ltrh .ruff_cache/
total 8
-rw-r--r--     1 xxx  staff    43B Mar  6  2023 CACHEDIR.TAG
drwxr-xr-x  1136 xxx  staff    36K Nov  7 14:30 content
drwxr-xr-x    48 xxx  staff   1.5K Nov  8 10:29 0.1.4
drwxr-xr-x    54 xxx  staff   1.7K Dec  1 11:51 0.1.6

I looked at file size, there's nothing out of the ordinary, the biggest file is 1.1mb and the total size is 10mb.
--no-cache fixes it.

Is this happening in an open source project or a project where you would feel comfortable sharing the given repository state and cache directory content? It would help us analyse the issue.

Is this happening in an open source project or a project where you would feel comfortable sharing the given repository state and cache directory content? It would help us analyse the issue.

Sadly I'm not comfortable sharing this information.
One thing that comes to mind is I have ruff running from 2 different virtual envs on the same repo:

one runs from my dev environment, whenever I save file (that's the one that crashes)
one runs from my pre-commit hook. It's potentially a different version of ruff, and python

maybe it could explain why the cache goes into a bad state.

I started getting this issue with Ruff running as a File Watcher sorting imports in PyCharm
The Output:
/Users/User/Library/Caches/pypoetry/virtualenvs/app-TUB9piUY-py3.10/bin/python -m ruff check --select I --fix app.py
memory allocation of<PHONE_NUMBER>279723890 bytes failed

$ ls -ltrh .ruff_cache/
total 8
-rw-r--r--     1 xxx  staff    43B May  1  2023 CACHEDIR.TAG
drwxr-xr-x  4227 xxx  staff   132K Oct 31 14:56 content
drwxr-xr-x    14 xxx  staff   448B Nov 30 12:48 0.1.6
drwxr-xr-x    14 xxx  staff   448B Dec  7 13:06 0.1.7

$ ruff --version
ruff 0.1.7

Code is not open source, so can't share unfortunately. ruff clean fixed it.

Our team is working with a fairly large repo and we're getting the same issue.
Again, running ruff clean fixes the issue.

I am also running into this issue, but in my case ruff clean does not solve it.

Interesting. The ruff clean command should be equivalent to what you ran as it basically removes the entire .ruff_cache directory. Did you have anything else apart from the 5 entries you've provided in the .ruff_cache directory i.e., cache directory from any other Ruff version?

this is the entire output at the moment:
❯ ls /Users/mattia.baldari/project/.ruff_cache/
0.1.13       0.1.14       CACHEDIR.TAG

I had encountered same error.
ls
0.1.13       CACHEDIR.TAG
ruff 0.1.13
python 3.10.13
My command,
/opt/homebrew/bin/ruff --config ~/ruff.toml --fix  /path/to/repo/a-file.py

ruff clean not working
rm -rf 0.1.13 not working
--no-cache worked

@rumbarum would you be able to share the repro file and the state of your cache directory so that we could try to reproduce locally?

@MichaReiser
Would you explain me what is and how to get repro file ?
And would you let me know how to get state of cache directory?

@rumbarum What would be useful for us is to have a project with a cache directory state that allows us to reproduce the error. What we need for this is:

A link to the project or zip with the source (if publicly available, we can talk about different communication channels if you feel comfortable sharing the source to a closed source project)
A zip with the content of the .ruff_cache directory

@MichaReiser
Currently, .ruff_cache is empty and no error.
I will ruff without --no-cache and gather caching. When error happen again I will touch you.

@MichaReiser
Error Happen again, and my repo is property of company. So it is not sharable.
But I can describe more detail,
Command on terminal works fine both on pycharm term or iterm2 without --no-cache.
This error happen only with pycharm File-watcher. This is my Pycharm setting.

# on Filewatcher
/opt/homebrew/bin/ruff format --config ~/ruff.toml /Users/rumbarum/sig/slash-server/services/fastapi/app/views.py
memory allocation of<PHONE_NUMBER>061442862 bytes failed

Process finished with exit code 134 (interrupted by signal 6:SIGABRT)

# on terminal
/opt/homebrew/bin/ruff format --config ~/ruff.toml /Users/rumbarum/sig/slash-server/services/fastapi/app/views.py
1 file reformatted

Thanks @rumbarum I suspect that we run into some sort of concurrency issue that corrupts the cache. I'll play a bit with file watchers to see if I can corrupt my local cache.

@MichaReiser
FYI, my ruff config
#  ~/ruff.toml
line-length = 100
exclude = ["*/__init__.py"]

[lint]
# F=pyflakes
# I=Isort
select = ["F", "I"]

#F541 f-string without any placeholders
#F841 local variable '...' is assigned to but never used
#F403 from {name} import * used; unable to detect undefined names
#F401 '...' imported but unused --> Makefile (make ruff)에서만, 사용 강제합니다.
# ㄴ 작업 하면서 미리 import 하는 경우도 있기 때문에
ignore = ["F541", "F841", "F401", "F403"]
fixable = ["ALL"]

[isort]
relative-imports-order = "closest-to-furthest"

[format]
quote-style = "double"
indent-style = "space"
line-ending = "auto"

# pyproject.toml
[tool.poetry.dependencies]
python = "^3.10"
fastapi = "0.103.2"
uvicorn = {extras = ["standard"], version = "^0.25.0"}
python-multipart = "^0.0.6"
sqlalchemy = {version = "1.4.49", extras = ["asyncio"]}
asyncpg = "0.28.0"
requests = "2.28.1"
email-validator = "1.3.0"
pyjwt = "2.4.0"
google-api-python-client = "2.58.0"
google-auth-oauthlib = "0.5.2"
google-auth = "2.11.0"
google-auth-httplib2 = "0.1.0"
slack-bolt = "1.14.3"
aiohttp = "^3.9.1"
boto3 = "1.26.1"
redis = {extras = ["hiredis"], version = "^5.0.1"}
python-dateutil = "^2.8.2"
cryptography = "41.0.7"
mailchimp-transactional = {git = "https://github.com/mailchimp/mailchimp-transactional-python.git", rev = "master"}
alembic = "^1.13.1"
arrow = "^1.3.0"
orjson = "^3.9.10"
nest-asyncio = "^1.5.8"
dependency-injector = "^4.41.0"
click = "^8.1.7"
gunicorn = "^21.2.0"
sqlalchemy-utils = "^0.41.1"

[tool.poetry.group.develop.dependencies]
black = "^23.12.1"
isort = "^5.13.2"
pytest = "7.4.3"
pytest-asyncio = "0.21.1"
httpx = "^0.26.0"
mypy = "^1.8.0"
ruff = "^0.1.11"

[tool.ruff]
line-length = 100
exclude = [".venv", "./services/fastapi/migrations", "*/__init__.py"]

[tool.ruff.lint]
# F=pyflakes
# I=Isort
select = ["F", "I"]

#F541 f-string without any placeholders
#F841 local variable '...' is assigned to but never used
#F403 from {name} import * used; unable to detect undefined names
#F401 '...' imported but unused --> Makefile (make ruff)에서만, 사용 강제합니다.
# ㄴ 작업 하면서 미리 import 하는 경우도 있기 때문에
ignore = ["F541", "F841", "F401", "F403"]
fixable = ["ALL"]

[tool.ruff.lint.isort]
relative-imports-order = "closest-to-furthest"

[tool.ruff.format]
quote-style = "double"
indent-style = "space"
line-ending = "native"
exclude = [".venv", "./services/fastapi/migrations"]

[tool.pytest.ini_options]
testpaths = [
    "services/fastapi/tests",
]

[tool.commitizen]
name = "cz_conventional_commits"
tag_format = "v$version"
version_scheme = "semver"
version_provider = "poetry"
use_shortcuts = true

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

Ruff 0.1.3
Poetry (version 1.7.1),
PyCharm 2023.3.2 (Professional Edition)
M1 (14.1.2)
And If any code is not included in cache file (I only see paths), I will share current .ruff_cache through email. Let me know please.

I currently have this error, so I am reporting here in the hope it is useful.
❯ ruff check
memory allocation of<PHONE_NUMBER>483511827 bytes failed
Aborted (core dumped)

Running with --no-cache works fine.
I tried copying (cp -R) the project directory to see if I could reopen it in a new devcontainer and reproduce the error. In the new environment it worked fine, but it was using the version 0.2.1, whereas my existing environment was using 0.1.14. Updating my existing environment to 0.2.1 fixes the issue and rolling back to 0.1.14 breaks it again. Rolling back the new environment to 0.1.14 does not cause the issue. I also tried made another copy of the project and reopened in devcontainer with ruff pinned to 0.1.14, but this did not cause the problem either.
The project is open source. I have made a branch from the checkout I currently see the issue in, including a zipped cache from the existing environment (sad) and the new environment (happy) in the root of the repo.
Given I can't even reproduce the error by copying the entire failing project directory I am not sure if checking out the project will help, but maybe the cache will be useful. I will leave the broken checkout untouched in case there are any other diagnostics that could be done with it.

Thanks @GDYendell . that's amazing. I tried to reproduce locally with ruff build from the v0.1.14 tag but failed to reproduce. I believe the reason is that our cache uses the project root as cache key.  I think that should allow me to "force" ruff to use your cache data. If that doesn't work, then I probably have to look at the bincode files manually...

One possibility is that the persist method fails after writing some bytes. The file will be picked up during the next read. https://github.com/astral-sh/ruff/blob/b3dc5654731aa6a152b43a992c020c59bc416ce3/crates/ruff/src/cache.rs#L168-L176
We could try to delete the file when writing failed but there's still a risk that the process dies in the middle

The absolute path to the broken checkout is /scratch/development/pvi.

I created a small script that deserializes the cache and prints the current offset. This can be useful to investigate where the file is corrupt.
The problematic cache file is<PHONE_NUMBER>753128385. The deserialization works fine up to the ModuleImport at offset 8144:
        module import entry 16@8144
[crates/ruff/tests/cache_issue.rs:199] self.read_len() = 21
          module: pvi.device.TextFormat
          range: 287..297

The next entry import entry (index 17) starts at offset 8181 but the length is only one byte instead of 8 (I can tell because what starts after is the name typing.pvi.device.TextRead)
@8144: 15 00 00 00 00 00 00 00 (length of name)
@8152: 70 76 69 2E 64 65 76 69 63 65 2E 54 65 78 74 46 6F 72 6D 61 74 (import name: pvi.device.TextFormat)
@8173: 1F 01 00 00 (range start)
@8177: 29 01 00 00 (range end)
@8181: 13 74 79 70 69 6E 67 2E 70 76 69 2E 64 65 76 69 63 65 2E 54 65 78 74 52 65 61 64 (next module entry
@8181: typing.pvi.device.TextRead

I suspect that we run into some form of race and the file only gets written partially. This is possible because we use a BufWriter that chunks the write calls. However, POSIX gives no guarantees that multiple write calls from the same process are atomic. It only guarantees that a single write call is atomic (to some extent).
I think a first good starting point to fix this is to write the cache to a temporary file and then rename it when writing was successful. This doesn't just help with potential races but also protects about corrupted cache files in case the ruff process dies in the middle of writing the cache (for whatever reason).

Thank you all for your help and reproductions... Your reproductions and error reports allowed me to reproduce the bug locally and I now have a fix ready for review.


Add dfVFS requirements

(Test failures are unrelated to this change, and will be fixed elsewhere so merging this as is)


acme-fixperms fails if /var/lib/acme is a symlink

Describe the bug
Like some other NixOS users, I clear my root filesystem on boot. To prevent my certificates being removed, I symlink /var/lib/acme to a safe location. This makes acme-fixperms.service fail (and I'm not sure how to fix this).
systemd[1]: Starting Fix owner and group of all ACME certificates...
systemd[4786]: acme-fixperms.service: Failed to set up special execution directory in /var/lib: Not a directory
systemd[4786]: acme-fixperms.service: Failed at step STATE_DIRECTORY spawning /nix/store/rq5rsxw7zkhhdylvxc8g8j4d8zmm14vz-acme-fixperms: Not a directory
systemd[1]: acme-fixperms.service: Main process exited, code=exited, status=238/STATE_DIRECTORY
systemd[1]: acme-fixperms.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Fix owner and group of all ACME certificates.

To Reproduce
Steps to reproduce the behavior:

Make /var/lib/acme a symlink.
Start acme-fixperms
Watch it fail

Expected behavior
It should not fail.
Notify maintainers
@NixOS/acme
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.10.45, NixOS, 21.11.20210628.4f3bc6a (Porcupine)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4pre20210601_5985b8b`
 - nixpkgs: `/etc/channels/nixpkgs`

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:
 - acme

That holds for any systemd service. StateDirectory must not be a symlink. Can you use a bind mount instead?

I'll give that a try, thanks. I guess it is true that this would be a problem for any systemd service, but acme-fixperms is the only one actually having problems on any of my systems.

Sounds like you followed https://grahamc.com/blog/erase-your-darlings. I was using the symlink approach as well, but it stopped working in NixOS 20.09 already, so now I just have /var/lib/acme on an extra ZFS dataset.

I switch my setup to use bindmounts instead of symlinks and everything seems to work well. Thanks!