MB-16104: v2 prime api for new fields

Jira ticket
Summary
This follows the instructions in this ADR and implements the changes to support a singular new API end point prime/v2/move-task-orders/{moveTaskOrderID}. I followed these three example PRs that were linked in the ADR:

For yaml changes
For handler changes
For service changes

If you are trying to get a sense of what making these changes was like, please take a look at the individual commits.
In general folks should try to understand what the impact of these changes are on the existing tests. In this scenario it meant that all of the existing tests that called move_task_order_fetcher would now be calling the new v2 service instead of the existing v1 service.
My thoughts on this process
Yaml changes
Making these changes was quite cumbersome. For a larger entity like move_task_order we need a lot of the existing definitions. This meant a lot of manual copy pasting. This also made it difficult to keep the changes in line with main since the original prime.yaml was actively being modified. I am planning on moving all of the existing definitions into their own files so that they can be used across yaml files. This will cut down on the duplicated code and make it easier to maintain. It is still potentially difficult to understand what the net changes are between v1 and v2 by just looking at the code.
Handler changes
This was fairly straight-forward yet cumbersome. Adding the model to payload functions for such a large entity meant we were primarily copying functions over with minor modifications.
Service changes
This was the most smooth portion of the changes. We had a service for the v1 API and a service for the v2 API. If you diff the two files you can see what the differences are between the two. We could potentially make some enhancements on how we are setting these flags and add some additional logic to make the behavior more consistent between when API calls are being made and when tests are being run. Right now the flag that we are using is nil when we are running tests. (There are some comments about this [1 | 2].)
Tests
The tests are in many ways just duplication of existing tests with minor edits. It's important to call out that the approach that we are taking here make it so that the default behavior utilizes the newer service. This means all existing tests will point to the new v2 service.
Verification Steps for the Reviewer

Verify the new API is working correctly
Verify the old API is still working as expected
Verify the new prime_v2.yaml file and corresponding docs
Verify the existing prime.yaml file and corresponding docs

Setup to Run the Code

Instructions for starting storybook
Instructions for starting the MilMove application
Instructions for running tests

How to test

Compare and contrast the responses between the v1 and v2 API where :moveTaskOrderID is a path variable
a. In postman make a get call to the v1 API https://primelocal:9443/prime/v1/move-task-orders/:moveTaskOrderID
b. In postman make a get call to the v2 API https://primelocal:9443/prime/v2/move-task-orders/:moveTaskOrderID
You should see they are identical except in the v2 version the fields methodOfPayment, naics, packingAndShippingInstructions,  and supplyAndServicesCostEstimate are populated within the orders object and the contractNumber is populated within the top level object.

You can also compare the v1 API response on this branch with main to ensure that the v1 branch has not changed.

To test the docs locally you can close the backend server since it runs on port 8080 and then run openapi preview-docs swagger/prime_v2.yaml. You can then visit localhost:8080 and you should be able compare and contrast the v1 API docs with the v2 docs. Ensure that the new fields exist on the v2 doc.

If you want to ensure that the v1 API hasn't changed you can ensure that the prime.yaml in the swagger folder hasn't been modified.

Messages

:book:
:link: MB-16104

  Generated by :no_entry_sign: dangerJS against a11e0faabbce8aa8e7b59856c5abf9acb10b05a5

IMHO, it is a feature to copy all of the yaml object definitions for v2. Otherwise, when you have to make a change to those files, you have to work pretty hard to figure out which versions are affected and which APIs are affected.
IMHO, the prime API should not be using the same object definitions as our other APIs, as we cannot change the prime object definitions, but we can change the ones for our internal APIs.

@ahobson Thanks for sharing this feedback! Fwiw, I felt this way initially. Implementing these changes made me change my mind. It felt like we were potentially front-loading work without clear concrete wins.
Can you help me better understand:

Otherwise, when you have to make a change to those files, you have to work pretty hard to figure out which versions are affected and which APIs are affected.

Would you be able to provide some toy example(s) to demonstrate what you mean? I'm happy to chat if that feels like a more efficient medium.
Take this with a grain of salt since I'm not sure I am completely following: I think you can tell which API version files are affected by looking at the generated swagger files when you make those changes. From my current vantage point, it seems like both approaches have the same difficulty in determining which API's are affected.

IMHO, the prime API should not be using the same object definitions as our other APIs, as we cannot change the prime object definitions without doing a version bump, but we can change the ones for our internal APIs.

This is true. I think we can still ensure that the object definitions are not changing by ensuring that the generated prime yaml file doesn't change. If that is the case, I don't see the advantage of preemptively creating new version of things like PaymentServiceItemStatus (which is just an enum of statuses) and Error when these are things that are unlikely to change and similar across APIs.
That said, there are definitely some downsides to this approach. For example, if you make a change to an object that is only found within another object like address, you'll have to create new v2 definitions of all of the parent objects until you reach the root.

@ronaktruss I think we'll need to add prime2 manually to our spectral linter list in our .pre-commit-config.yaml  https://github.com/transcom/mymove/blob/4098258c65e383e3540732dc2a23ee66c3f3bf9d/.pre-commit-config.yaml#L182

I don't think it's a blocker but our cmd/prime-api-client is only capable of calling the existing v1 endpoints I think.  Maybe we can document that in the usage notes somewhere so the limitation is obvious.
The other thing I wanted to ask was about the audit log event name.  It seems to default to the operationID of the endpoint.  I wonder if we need a convention to distinguish between events that originate in v1 from v2 https://github.com/transcom/mymove/blob/d2064d4d9fa9f223731beb089420b36035533c87/pkg/audit/context.go#L11.  Seems like it will be more important for mutations.

I don't think it's a blocker but our cmd/prime-api-client is only capable of calling the existing v1 endpoints I think. Maybe we can document that in the usage notes somewhere so the limitation is obvious.

@duncan-truss Yeah that's a good call out. There is some overlap between leveraging postman to call prime/support apis, the prime api client, and the prime simulator. I don't think the boundaries between these are very clear and we'll likely need alignment on what we are actually planning on supporting long term. If you think otherwise feel free to let me know.
I don't have much context on the audit logs. Let me try and do some digging.

@ronaktruss Should the prime simulator be updated to call v2 of getMoveTaskOrder?  I know we only have one swagger client setup and would need to add one for v2 if we want to have both availaible. https://github.com/transcom/mymove/blob/1fc9901379cc8ec5921f090e7b0e662ec45cd06e/src/services/primeApi.js#L8-L17

@duncan-truss Right now the prime simulator wasn't updated to be able to support this new API call. This was intentional for a couple of reasons:

It's unclear to me how we are supporting v2 APIs if they are not being adopted immediately. In the case we introduce a v2 API but the prime is still using a v1 API, would we want to update the prime simulator to just default to the new version? I think the answer depends on the specifics of the scenario.
To limit the scope of the this initial PR. Because the answer to the question above feels a bit muddy it didn't seem like it was a necessary inclusion at the time.

That said, we could still add the capability of accessing the v2 APIs without changing the existing behaviors. I was planning on doing this in a separate PR after getting a bit more clarity on how this PR would land. If you think that should be included in this PR feel free to let me know. I can be easily swayed on this.

The other thing I wanted to ask was about the audit log event name. It seems to default to the operationID of the endpoint. I wonder if we need a convention to distinguish between events that originate in v1 from v2. Seems like it will be more important for mutations.

Also I spoke to @mmayo-truss about this and it seems unlikely that we will want to distinguish between a v1 and v2 event. (I think he might be writing a response that will likely have more specifics.) From the UI perspective the user likely doesn't care between the distinction between the two. There might be some edge cases where entities are being significantly modified but those will likely be paired with their own set of template changes.

I don't think it's a blocker but our cmd/prime-api-client is only capable of calling the existing v1 endpoints I think. Maybe we can document that in the usage notes somewhere so the limitation is obvious.
The other thing I wanted to ask was about the audit log event name. It seems to default to the operationID of the endpoint. I wonder if we need a convention to distinguish between events that originate in v1 from v2. Seems like it will be more important for mutations.
https://github.com/transcom/mymove/blob/d2064d4d9fa9f223731beb089420b36035533c87/pkg/audit/context.go#L11

@duncan-truss The event name is used in conjunction with the action type and the table name to select the appropriate template to display in the for a row in audit history table UI. If a unique combination of those three are not found a default template would be utilized. This is the template registration function. And this is an example template for an update to MTO Service Item.
If we differentiated v1 and v2 event names here, we would need to have separate templates in the audit history table for each. Or modify the template lookup mechanism to account for the multiple versions of the event name.
I think defaulting to using the same event name makes sense. If, in the process of versioning an endpoint, the need to differentiate the templates for the audit history table UI arises, we could differentiate the one endpoint and create the necessary audit history event templates.

@duncan-truss  Are you seeing any warnings outside oas2-unused-definition? I think it's expected that there should be 5 warnings atm.

@duncan-truss Are you seeing any warnings outside oas2-unused-definition? I think it's expected that there should be 5 warnings atm.

Those were the only ones I saw locally and I think that count matched what was in CI too.


chore: upgrade libp2p to 0.44.0

Why is this change needed?
Upgrades libp2p one minor version up (Release Notes | Migration Guide)
Breaking Change in Autodial + Connection Manager Behavior
When a libpp2 node dials a peer , it gets 1) added to the PeerStore as a Peer 2) added to the PeerStore's AddressBook as a multi addr and 3) added to the ConnectionManager as an open connection. There is a ConnectionManager and an Autodial system used to reconnect to known peers if we get disconnected. Autodial ensures that if we have a peer, but do not have enough connections to it, we will reconnect at some cadence and ensure that it is in our addressbook.
There is a semi-documented behavioral change with Autodial in 0.44.0. In 0.43.x, Autodial would trigger on a timer which was set to 10s. In v0.44.0, Autodial has a timer but is also automatically triggered by DefaultConnectionManager on a peer:disconnect event.
We have a method called removePeerFromAddressBook used in a couple of places in hubble.ts (location 1 | location 2). This method hangsup on the peer and and removes it from the address book.

In 0.43.x, calling this method would disconnect the peer until AutoDial runs again (~0-10s) at which point it will reconnect.
In 0.44.x, calling this method would disconnect the peer and Autodial runs again immediately reconnecting it in a few milliseconds.

This raises a problem and a question:

Problem - there are two tests that disconnect peers and asserts that the connection remains disconnected a few hundred ms later. These now fail.

Question - is removePeerFromAddressBook meant to cause a reconnection to the peer after 10s? Or is this a bug in our implementation?

There are a few paths forward:

Patch libp2p to not auto-dial on disconnect. This would probably return us to close to previous behavior, but may cause further problems when upgrading.

Modify our tests to remove the peer from the peer store. This would prevent autodial from reconnecting and making the tests pass. But if production code depends on this behavior, it would run into an issue.

Modify tests and removePeerFromAddressBook to remove the peer from the peer store when removePeerFromAddressBook is called. This is the most thorough, but may have downstream implications.

Merge Checklist
Choose all relevant options below by adding an x now or at any time before submitting for review

[ ] PR title adheres to the conventional commits standard
[ ] PR has a changeset
[ ] PR has been tagged with a change label(s) (i.e. documentation, feature, bugfix, or chore)
[ ] PR includes documentation if necessary.

PR-Codex overview
This PR updates dependencies and refactors connection logic in the GossipNode and ConnectionFilter classes.
Detailed summary

Updated @chainsafe/libp2p-gossipsub to version 6.2.0
Updated @libp2p/interface-connection to version 4.0.0
Added @libp2p/interface-connection-gater
Updated @libp2p/mplex to version 7.1.6

The following files were skipped due to too many changes: yarn.lock

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

The intention behind removePeerFromAddressBook is to kick the peer from the network. We use this in two places:

To prevent connecting to "invalid" peers (not in allow list, below min version etc)
To prevent connecting to peers that don't have a reachable rpc port

So, I think the the fact that autodial would override this is the bug and I don't think we were aware of that when it was implemented. We should remove from the peerStore if that will fix it.


[244] Add the confirm personal details component

Adds the personal detail confirmation component.

Missing some view previews and specs for the personal details component


use table column alignments when available

Bug/issue #, if applicable: rdar://100337272
Summary
This PR takes a new alignments property from Render JSON and adds new styles to table cells to control their text alignments.
Dependencies
https://github.com/apple/swift-docc/pull/389
Testing
See the testing instructions from the linked Swift-DocC PR.
Checklist
Make sure you check off the following items. If they cannot be completed, provide a reason.

[x] Added tests
[x] Ran npm test, and it succeeded
[ n/a ] Updated documentation if necessary

@swift-ci Please test

@swift-ci Please test


New Dataset for Existing Task

New dataset description: Human/Rat Liver Microsomal Stability (HLM_RLM)
Describe the problem
We believe that the HLM_RLM datasets would be beneficially added under the ADME task. The HLM_RLM datasets predict the metabolic stability of compounds in Human and Rat Liver Microsomes, which is crucial for early-stage drug development. The datasets include 6,013 compounds for human liver microsomes and 5,590 for rat liver microsomes. Compounds are classified as stable or unstable based on their half-life. We have sanitized and organized the datasets, derived from a published paper(DOI: 10.1021/acs.chemrestox.2c00207), into a format with three columns: ID, X, and Y.
Describe the solution you’d like
from tdc.single_pred import ADME
data = ADME(name = ‘hlm’)
data = ADME(name = ‘rlm’)

@haneul-park please make sure tests pass. also, looks like you have a merge conflict. also, can you provide remaining information for this license(s) as per dataset descriptions on the website.
Please fill out a template following the format shown here. Looks like you have most already so should not be difficult.

Last, make sure to follow the instructions here
https://github.com/mims-harvard/TDC/blob/main/CONTRIBUTE.md#1-new-dataset-for-existing-task
is this data in harvard dataverse already?

Thank you for your feedback. I have resolved the issues and filled in the missing information. Additionally, I have attached a zip file here containing ‘data processing scripts’ and ‘text description’.

Merge conflict: Resolved
Fill out a template: Completed (‘text description’)
Remaining information for the license: Added in ‘text description’
Follow the instructions for contribution: Done
Pytest: Updated the forked TDC into the newest version. Since there was a similar error on the main branch recently, this update may resolve the error you are seeing here. )
Is this data in Harvard Dataverse already?: Yes, I have already uploaded the datasets to Harvard Dataverse.

Please let me know if anything further needs to be added or changed.
HLM_RLM.zip

Hi @haneul-park , thanks for the contribution!


Tutorial notebooks

What do we want to demonstrate in notebooks? (Please edit/update this issue description as appropriate.)

[x] General introduction notebook (Vincent)
[x] Efficient sampling (Vincent)
[x] GPflux features: monitoring, tensorboard, saving (Vincent)
[x] GPflux with neural net layers (Vincent)
[ ] Convolutional DGP (Artem?)
[ ] Latent Variable model (CDE paper) with extension to Importance Weighting? (Hugh?)

Hey there! Sorry to interrupt. For some reason, it seems like I do not have the authorization to view the tutorial/documentation. I wonder if that is expected? Thank you so much!

Hi @tingyuansen, thanks for bringing this to our attention. The documentation and tutorial links should all have been updated by now. Definitely let us know if you spot more broken ones.

Thank you!

On "GPflux with neural net layers", please discuss usage patterns and usage constraints when building hybrid models.
For example, can one put a GPLayer in the middle of a neural net model, preceded and followed by Keras layers? The existing code example (only one) has a GPLayer as the last layer but preceded by a linear Dense layer:
tf.keras.layers.Dense(1, activation="linear"),
gp_layer,
Is the linear Dense layer with output dimension 1 required?

Hi,
Thanks for releasing this exciting package.
Would you be able to add a classification task example to the tutorial?
thanks
Hashem

Hi, Thanks for releasing this exciting package. Would you be able to add a classification task example to the tutorial? thanks Hashem

I would really appreciate if an example of a classification would be provided. Especially for a multivariate data and multiclass problem. I tried to come up with a gpflux code to do that. I failed. The error outputs are extremely unhelpful. Thus, an example would be highly appreciated.


C/C++ header files randomly go missing, then reappear

On Build 15042, while compiling in parallel using the MinGW version of GCC with make -j 8, header files are randomly unavailable to the compiler (pre-processor?). Sometimes, the compiler finds them in the wrong path then, upon trying to use them, cannot open them; and sometimes, they simply don't open from their correct place.
In previous Windows Insider builds up to and including 15019, my compilation ran perfectly. After this, another issue prevented me from using the Linux subsystem.
Here is an example of the output:
make[2]: stat: /mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/include/boost/config/stdlib/libcpp.hpp: Invalid argument
make[2]: *** No rule to make target '/mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/include/boost/config/stdlib/libcpp.hpp', needed by 'samples/cpp/CMakeFiles/tutorial_non_linear_svms.dir/tutorial_code/ml/non_linear_svms/non_linear_svms.cpp.obj'. Stop.
CMakeFiles/Makefile2:3772: recipe for target 'samples/cpp/CMakeFiles/tutorial_non_linear_svms.dir/all' failed
make[1]: *** [samples/cpp/CMakeFiles/tutorial_non_linear_svms.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

You'll notice that the pre-processor prints "Invalid argument" (rather than something like "file not found", and that the error seems to be a return from a call to stat(). The file referred to, above, most certainly exists at the path where it is named, and can be opened and edited by other programs e.g. vim.
Other large builds that fail include cross-compiling Qt 5.8 (similar problem) and, also, FFmpeg likewise failed. When I build with make -j 1, failures still occur occasionally. Re-starting the compilation makes the problem go away temporarily, until another header file goes missing further down the Makefile.
If you'd like me to help with strace outputs, in case this is a new bug, I'll try: but the failures are random so I can't guarantee they'll be repeatable. They also occur usually after the build has been running for some minutes.
The rest of the system, in use as an editing machine for Avid Media Composer, is working just fine.

Thank you for asking. I start a new console using the "Bash on Ubuntu on Windows" shortcut; then, within that window, compiled my own x86_64-w64-mingw32-gcc (and all other tools), and it is that gcc that fails to find the header one moment; then finds it the next.
The filesystem this is running on is a mounted NTFS system, as the pathnames may make clear.
Since Bash on Ubuntu on Windows came in, my large parallel compile cycles have all worked perfectly, until the build that followed 15019.
It's just failed again: but at a different point in the compilation. If I run this again, the compilation will pass this point, then fail somewhere else. It's that "invalid argument" that gets to me. And, in this particular case, the file isn't even where the error print-out says it is. In fact, it's in the top directory of the include tree. I can't work out why gcc is finding it in the wrong place; then, of course, unable to open it for pre-processing.
In file included from /mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/include/minwindef.h:163:0,
                 from /mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/include/windef.h:8,
                 from /mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/include/windows.h:69,
                 from /mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/include/winsock2.h:23,
                 from libavformat/os_support.h:112,
                 from libavformat/internal.h:28,
                 from libavformat/rawdec.c:24:
/mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/include/winnt.h:628:21: fatal error: /mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/x86_64-w64-mingw32/include/bs2b/guiddef.h: Invalid argument
 #include <guiddef.h>
                     ^
compilation terminated.
common.mak:60: recipe for target 'libavformat/rawdec.o' failed
make: *** [libavformat/rawdec.o] Error 1
make: *** Waiting for unfinished jobs....
Build failure. Please see error messages above.
john@JW-AVID-2016:/mnt/e/Users/john/Documents/MultimediaTools-mingw-w64$

Yep. It's compiled the previous file, where there was an error, perfectly. But then it went hunting down the glib-2.0 include path. That's not even a path I give to the compiler. Still returns "invalid argument" not "file not found". Odd.

/mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/bin/x86_64-w64-mingw32-gcc -I. -I./ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DOPJ_STATIC -DZLIB_CONST -DHAVE_AV_CONFIG_H -std=c11 -fomit-frame-pointer -pthread -I/mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/x86_64-w64-mingw32/include -Iinclude/ -mms-bitfiIn file included from /mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/include/winsock2.h:23:0,
                 from libavformat/os_support.h:112,
                 from libavformat/internal.h:28,
                 from libavformat/redspark.c:26:
/mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/include/windows.h:102:22: fatal error: /mnt/e/Users/john/Documents/MultimediaTools-mingw-w64/sandbox/mingw-w64-x86_64/x86_64-w64-mingw32/lib/glib-2.0/include/winspool.h: Invalid argument
 #include <winspool.h>

Hm...  I'm not sure what is going on.  I haven't hit this issue in probably 10 or 20 wall-clock-hours of compiling stuff in DrvFs on build 15042 so far.  But I'm not using mingw (clever setup, by the way!); I'm using Ubuntu's stock gcc.  Also, I have hit some slightly different weirdness as documented in #1729 .
Maybe there's a timing hole of some sort in WSL's logic for setting up new process environments?  Just a guess.
(I'm not a WSL dev myself; I was kinda hoping that one would drop in with some thoughts :-) )

It's very odd. Happens only at times of greatest stress: big suites e g. FFmpeg, DJV viewer, Qt 5.8. Most of the rest of the compilation progresses smoothly. I have never seen this trouble before in months of compiling this huge suite almost daily. And because the failure comes at semi-automatic random moments, I'm at a loss to diagnose it. Maybe it's time for a strace.

Come to think of it, I have had other occasional fails with "invalid argument". These cases have been where the argument appears to be a directory, not a file (then quickly reappears as a file) — which is nonsense for a C or C++ header file and, hence, quite reasonably causes the compiler to barf saying "invalid" rather than "missing".

Hm...  I wonder if this might be an IO race condition?
My test machine has a very fast disk (NVM SSD) and a less-fast CPU (dual-core mobile i7).  @Warblefly , do you have a slower disk and/or faster CPU?  Just a thought.

Yes. i7 at 4.5GHz with hyperthreading but traditional HDD 6Gbit/s SATA connection onto data drive which would be accessed through DrvFs. System boots off SDD (which would be through VolFs were I to move files location to /home/john rather than /mnt/e...) though the SDD is also on a 6GBit/s interface.

Hi @Warblefly,
Could you share repro steps for this problem, so we can try to diagnose what is happening? Make sure to include how you set up your build environment to build and use the MinGW gcc.
Thanks,
Sven

Certainly. I'm just going to run an overnight build attempt of my suite on Insider Preview 15046, which arrived today (been at a trade show today). Will write more in the morning (UK time), and send links to source code and a strace, if the problem persists.

I am very sorry to report that, on Insider Preview 15046, my entire build proceeds without error. No files go missing or change their types; nothing fails, even under stressful multi-process compilation. Of course, that's actually very good news! Something has been fixed, either in WSL or in Windows itself.
My repo: https://github.com/Warblefly/MultimediaTools-mingw-w64#readme

@Warblefly - Closing it out since the issue is resolved for you now. If I misread your post and the issue is not resolved, please let us know and we will reopen the issue. Thanks for using WSL and the feedback!

For the first time in a long time, this error has reappeared. Here's the output from ls -l — you'll see that 'build' (created a few minutes earlier) has stuck around in an unfortunate state. This is on Windows Insider Build 15063, and no third-party antivirus.
ls: cannot access 'build': No such file or directory
total 78688
drwxrwxrwx 0 root root  4096 Mar 24 10:31 3rdparty
drwxrwxrwx 0 root root  4096 Mar 24 10:31 apps
d????????? ? ?    ?        ?            ? build
drwxrwxrwx 0 root root  4096 Mar 24 10:31 cmake
-rwxrwxrwx 1 root root 51021 Mar 24 10:31 CMakeLists.txt
-rwxrwxrwx 1 root root 51002 Mar 24 10:31 CMakeLists.txt.orig
-rwxrwxrwx 1 root root   191 Mar 24 10:31 CONTRIBUTING.md
drwxrwxrwx 0 root root  4096 Mar 24 10:31 data
drwxrwxrwx 0 root root  4096 Mar 24 10:31 doc
drwxrwxrwx 0 root root  4096 Mar 24 10:31 include
-rwxrwxrwx 1 root root   509 Mar 24 10:31 index.rst
-rwxrwxrwx 1 root root  1772 Mar 24 10:31 LICENSE
-rwxrwxrwx 1 root root  1025 Mar 24 11:02 lsout.txt
drwxrwxrwx 0 root root  4096 Mar 24 10:31 modules
-rwxrwxrwx 1 root root   437 Mar 24 10:31 opencv-boost-thread.patch
-rwxrwxrwx 1 root root     0 Mar 24 10:31 opencv-boost-thread.patch.done
drwxrwxrwx 0 root root  4096 Mar 24 10:31 platforms
-rwxrwxrwx 1 root root   566 Mar 24 10:31 README.md
drwxrwxrwx 0 root root  4096 Mar 24 10:31 samples

This just started happening for me in build 16299_rs3_release, using the stock compiler GCC 5.4.0.

If you are on 16299 then you're seeing #2448, which is different (confusingly) to this one reported back in February here. Try out the work-around in that issue or try Insider 17035 or later.

Workaround fixes the build issue, but causes the entire desktop to lock up after compiling ~40 files at -j8. Looks like I'll need to wait for the official Fall Creators update patch, since I can't really run an Insider release at work.
In the meantime, it looks like manually re-running make -j1 multiple times will eventually build everything, it just takes 10-15x as long.

If you are holding out, consider compiling your stuff on LxFs (/home). It is in general a better experience, even discounting the present bug.


Fix Deployment file name cleaning

Not all browsers append the "C:\fakepath" and, for those who appended
if going back and forth, filename was getting cut by 12 chars every time

Nice catch @ammendonca !


Remove print-statement in _render_single_graph

Currently a print-statement is executed when rendering a graph

Is it possible to remove it and perhaps return the file_path instead?

To inform the user where the image was saved makes totally sense if you use it as a console-application.
But in my use case I would like to use clingraph as a library and create graphs along a toolchain. So to either inform the user of my application under which name the file was saved or do something else with the file afterwards, i would need to build the path manually.
Returning the path was just an idea. If it doesn't fit in the overall concept it's ok for me :-)

Ok, I understand what you mean now. I think it makes sense to return the path and only print when using the console functionality, let me see if I can include that in the next version.

Done! I hope this helps :) Thank you for the feedback.


[Frontend] Increase MAX_JSON_REQUEST_SIZE_BYTES_KEY

This patch increases the MAX_JSON_REQUEST_SIZE_BYTES_KEY from 20mb to
128Mb. This is the maximum size of json sent as part of a stitch
request. The stitch request for 1tb blob is 64mb. Setting it to 128mb
allows 2tb stitch requests.
Tested on localhost mac by uploading a 64mb stitch request.

Codecov Report

Merging #2127 (e37ba4f) into master (cd61057) will decrease coverage by 3.91%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #2127      +/-   ##
============================================
- Coverage     73.82%   69.90%   -3.92%
+ Complexity    10094     9599     -495
============================================
  Files           722      722
  Lines         54873    54881       +8
  Branches       6788     6790       +2
============================================
- Hits          40509    38364    -2145
- Misses        12215    14391    +2176
+ Partials       2149     2126      -23

Impacted Files
Coverage Δ

...n/java/com/github/ambry/config/FrontendConfig.java
100.00% <100.00%> (ø)

...java/com/github/ambry/notification/UpdateType.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...thub/ambry/notification/BlobReplicaSourceType.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../cloud/LeaderStandbyHelixVcrStateModelFactory.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...om/github/ambry/named/MySqlNamedBlobDbFactory.java
0.00% <0.00%> (-94.74%)
:arrow_down:

...ry/accountstats/AccountStatsMySqlStoreFactory.java
0.00% <0.00%> (-93.34%)
:arrow_down:

...y/network/http2/Http2ClientStreamStatsHandler.java
0.00% <0.00%> (-90.48%)
:arrow_down:

...ava/com/github/ambry/network/http2/Http2Utils.java
0.00% <0.00%> (-90.00%)
:arrow_down:

.../github/ambry/account/mysql/MySqlAccountStore.java
0.00% <0.00%> (-87.50%)
:arrow_down:

...mbry/network/http2/Http2ClientResponseHandler.java
0.00% <0.00%> (-87.50%)
:arrow_down:

... and 115 more

Continue to review full report at Codecov.

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


Align stac api swagger spec with static catalog

Once the static catalog is set we should revisit the swagger / openapi 2.0 document to make sure that the responses from it mirror it exactly, so a client could treat them as the same.

There's probably more to do here at the 'catalog' level, but they are roughly aligned now, especially at the 'item' level.


Try to fix tests by not installing Bokeh dependencies

Trying  to fix #25

Why not just add bokeh to req-travis-conda.txt with a pinned version?

(And then just merge the two requirements file with cat, to clarify)

Because we still install all dependencies from requirements.txt from Blocks after that, see this line. I guess we should somehow installed a pinned version of Bokeh and insist that no packages are updated, but somehow --no-update-dependencies does not work for me in #27

Well, strictly we don't even need to install that requirements.txt (everything should be installed already with req-travis-conda.txt). That said, I don't understand the problem? If you create a file req-travis-conda.txt with the contents bokeh==0.10 and then do this in .travis.yml:
- curl https://raw.githubusercontent.com/mila-udem/blocks/master/req-travis-conda.txt >> req-travis-conda.txt
- conda install -q --yes python=$TRAVIS_PYTHON_VERSION --file req-travis-conda.txt

The added bonus is that you can be sure that dependencies aren't duplicated between blocks-extras and Blocks.

Looks like you did exactly that the same time I pressed the comment button :p I would use a separate file because it's consistent with the other repos (and scales more easily to possible future dependencies), but otherwise I think this solution should work.

I agree that a separate file makes sense. But I fail to understand why we install Blocks with requirements.txt on Travis, even though we have a special file req-travis-pip.txt for that.

I guess the idea is that -r requirements.txt should not do anything. If it does it means that we are either missing dependencies in req-travis-*.txt, or the dependencies have gotten out of sync. If there are syntax errors in requirements.txt those would show up as well.

In this case we should install them without -q, so that we at least saw that something is done by visual inspection of the log.
Feel free to merge this PR.

Agreed, the installation of blocks itself should really be done without -q.


Update linux-recovery-cannot-start-file-system-errors.md

@JarrettRenshaw : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Production Release ETA & Funding

I saw there is still a bit to do till 1.0: https://github.com/orgs/FOSSBilling/projects/2
But if I understand it correctly, with FOSSBilling we could give clients the ability to book their own domains and have them right away in HestiaCP, without any work from our side. They could also cancel their domain or get an auth code to move. They could be billed automatic via a payment provider like Mollie or Stripe.
If that is correct, FOSSBilling would enable us to serve more customers with less work, and as such we would be very willing to provide some funding.
So how could we support the development, and what results can we expect?

Hello Janek,
Truthfully speaking the roadmap isn’t being reliably updated and it likely isn’t a very good representation of what is left until FOSSBilling we consider production ready. As we are working on the software and improving things, we are often uncovering new issues and things that need to be improved.
Yes, the intention of FOSSBilling is to automate most actions hosting providers will need to perform such as billing, account creation, domain registration, and more.
Right now the biggest way to help support development of FOSSBilling is actually here on GitHub through code contributions. We are also accepting donations through GitHub Sponsors and Open Collective, however outside of the donation tiers listed they should be made with zero expectations in terms of accelerated development. If you are looking to pay for accelerated development or priority for features, that would need to be discussed with us (the Steering Committee) in a private discussion rather than a public forum such as GitHub.
Two different options for having a private discussion like that would be through our<EMAIL_ADDRESS>email address, or you can join the discord server and we can the create a private channel with you.

Hey, the repo still features the in-development disclaimer, but the website makes it seem like FOSSBilling could be started to be used productively?
We are not quite satisfied with InvoiceNinja and right now have a last chance to switch before going all-in on it.

Hello,
Can you please share what on the website gives that idea?
FOSSBilling is still considered to be pre-production software and this is intentionally reflected in the version number, repository README.md, and the website. If there's some place that suggests otherwise, we'd probably want to review the wording on that page.
With that being said, there has been quite a bit of progress since you last posted here.
The roadmap is fully flushed out with what we consider to be the TODOs before 1.0.0 (first official production-ready release), and there has been quite a few releases with new features, enhancements, bug fixes, and strengthened security.
The software itself should be pretty stable at this point with the biggest reason for it not being considered production ready being missing or incomplete features.

On the Downloads page it clear state:
Before downloading, please keep in mind:

FOSSBilling is currently considered pre-production software
You should have a strong technical knowledge
Due to the pre-production nature of FOSSBilling, you should always read the release notes before updating
We recommend understanding PHP and software development so you may aid in FOSSBilling development as well as resolve issues for yourself if needed
FOSSBilling currently does not function correctly when placed under a sub-folder, so use a sub-domain instead

We have patched a few issues with the invoice numbering increment after the payment. So the main objection for running in EU has been solved..

Thanks for the heads up @jaapmarcus! German law compliance is an important part.
Yes we have technical background and are open to collaborate on development.
Subdomain installation is no problem.
Considering the overlap in developers, I am surprised there are no installation instructions for HestiaCP ;)

Can you please share what on the website gives that idea?

Go on the start page > "Getting Started" > "Install with Docker"
Everything to go is there, none of these pages has a disclaimer. I did not even reach the download page before your hint.

Considering the overlap in developers, I am surprised there are no installation instructions for HestiaCP ;)

I am the only developer who is active on both Hestia and Fossbilling...
But unzip folder + follow the instructions. I don't think it needs a guide...

Considering the overlap in developers, I am surprised there are no installation instructions for HestiaCP ;)

Hey @xeruf 👋🏻, documentation about installing on shared hosting should mostly apply to HestiaCP. We might cover it in the future, but it's hard to write documentation for every specific software and harder to keep them updated.
If you meant to search for a documentation page about configuring HestiaCP to work with FOSSBilling and providing hosting via it, there already is a documentation page for that.
Our documentation needs more love. We usually don't have much activity from external contributors in that area, and that's all we developers can do in limited circumstances

Everything to go is there, none of these pages has a disclaimer. I did not even reach the download page before your hint.

You're right on this.

Yes we have technical background and are open to collaborate on development.

We would really appreciate any kind of help. Our roadmap is public. Feel free to go through the issues and contribute to the project. We can also get in touch in our Discord server.

German law compliance is an important part.

Regarding German law compliance, it's an important aspect for us as we aim to target the European market. I have just created a new project board tracking compliance tasks with European Union regulations, which you can find here. Please feel free to create new issues related to the specifics of compliance, and we'll have them added to the project board.
We look forward to your contributions and collaboration. Your technical background and insights will be highly valuable to our project and hopefully yours.

Considering the overlap in developers, I am surprised there are no installation instructions for HestiaCP ;)

Hey @xeruf 👋🏻, documentation about installing on shared hosting should mostly apply to HestiaCP. We might cover it in the future, but it's hard to write documentation for every specific software and harder to keep them updated.

When it is stable enough I will create Quick install app. So it will be a lot easier...

We have patched a few issues with the invoice numbering increment after the payment. So the main objection for running in EU has been solved..

To be clear: the invoice numbering has not yet been changed in a release. This change currently is only seen in preview builds


Pull request for Issue #26

Fixes #26

@all-contributors please add @dNhunter3107 for doc, tool

ty for this 🙏

Welcome @comoser


externals not work

i do a plugin, use exteranls exclude react：
externals: {
react: 'React'
},
when i use this plugin，tell me the react is undefined，i use this plugin like this:
import React from 'react';
window.React = React;
import {FullModal} from '../dist/cmui.min';

You don't need externals for react, just import React from 'react' and use it :)

Yup, please re-open at Stack Overflow as that works better for support.


Updated dependency and added Python 3 compatibility.

Updated the pysignals code to v1.9.8 from Django, and fixed str<-->bytes compatibility issues between Python 2 and 3.
My test (I left it out of the template test class; it assumes there's a WeMo switch on the network):
#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""
test_ouimeaux
----------------------------------

Tests for `ouimeaux` module.
"""

import unittest

from ouimeaux.environment import Environment
import time

class TestOuimeaux(unittest.TestCase):

    def setUp(self):
        pass

    def test_switch(self):

        # Set up environment and find devices
        env = Environment()
        env.start()
        env.discover(5)

        # Make sure switches were found (Note: This is specific to my testing environment)
        if len(env.list_switches()) <= 0:
            raise ValueError("There should have been a switch detected.")

        # Toggle each switch to ensure proper connection
        for switch_name in env.list_switches():
            switch = env.get_switch(switch_name)
            switch.toggle()
            time.sleep(1)
            switch.toggle()

    def tearDown(self):
        pass

if __name__ == '__main__':
    unittest.main()

Thanks to the submitter of #107 for helping speed the process up.

Will test this this evening.

Tested on Python 3.5 and 2.7, LGTM


Support for -X GET -d (for Elasticsearch, etc.)

Elasticsearch requires data to be sent along with GET requests for many operations.
$ curl -XGET /cars/transactions/_search?search_type=count -d '
{
    "aggs" : {
        "colors" : {
            "terms" : {
              "field" : "color"
            }
        }
    }
}'

This is a Chrome limitation - you can't add a body to GET requests. We're looking at ways to work around this though.

@naterkane From the Elasticseach documentation

Both HTTP GET and HTTP POST can be used to execute search with body. Since not all clients support GET with body, POST is allowed as well.

http://www.elastic.co/guide/en/elasticsearch/reference/1.x/search-request-body.html
I've been using sense a while and this seems to be a recommendation when trying to hit Elasticsearch with chrome: https://github.com/bleskes/sense. The official support for this extension was moved to Marvel, but you could use the extension loading it with Developer Mode.

Chrome app platform restriction - cannot include a body with GET requests

Maybe this shouldn't have been built within the Chrome sandbox so it could have utilized curl or something similar shrugs


Add Korean translations

Add Korean translations
add main_ko
translate from main_zh

Make sure to run selfdrive/ui/update_translations.py --release, looks like there's a couple differences

Make sure to run selfdrive/ui/update_translations.py --release, looks like there's a couple differences. You can delete that vanished string and move the translation to the new one.
Actually I'm not sure why I can't remove the vanished string manually, but just run update_translations, use linguist to copy the translation to the new string, save, then close and update the QM file. That should work

    <source>Get turn-by-turn directions displayed and more with a comma``` ```
    <source>Get turn-by-turn directions displayed and more with a comma

@crwusiz does my last commit look good?

Good..!!

You're missing NO PANDA, Dongle ID, and Serial. Or are those fine in English?

You're missing NO PANDA, Dongle ID, and Serial. Or are those fine in English?

I thought it looked better in English.

Thanks for the PR!


API and website documentation and minor cleanups for AppRequest/AppNotify

[x] Debugger document improvements
[x] Minor debug print improvements for debugger AppRequest/AppNotify
[x] Add 'duk' example for AppRequest, provide a custom "CommandLine" AppRequest
[x] Add 'duk' example for AppNotify, provide custom "DebuggerHandleFile" when running files
[x] Add debugger error code metadata into the debugger build (not used yet)
[ ] Add API document for duk_debugger_attach_custom()
[ ] Add note to duk_debugger_attach() to API document
[ ] Discuss Duktape 2.x deprecation of one or the other (most likely duk_debugger_attach_custom() staying and renamed to something else)
[ ] Add one paragraph summary of the feature to website Debugger section
[x] Releases entry for AppRequest/AppNotify

@fatcerberus The minor code changes in https://github.com/svaarala/duktape/commit/284a29959c8abd9e27624676bfe86f905b3b5c19 are essentially:

Debug log (DUK_DPRINT) when application calls duk_debugger_notify(). This matches a DUK_DPRINT level debug log for attach/detach, and also for received AppRequest.
Return after DUK_ERROR_API(); the code is not consistent w.r.t. this however. It generates better code (and less warnings) when "noreturn" is not available.
NULL the request_cb in detach1(), regardless of detach reason. This should have no practical effect, but it's best to NULL on detach.
NULL the request_cb along with I/O callbacks on transport errors. This should have no practical effect, but the best state to be in after an I/O error is that we only have the detached callback non-NULLed.
More strongly worded debug log when the AppRequest nrets doesn't look sane: when asserts are disabled it's not necessarily safe to continue (even with the if-condition) so this documents the issue in code and debug logs.

As for the debugger documentation, proposed changes in https://github.com/svaarala/duktape/commit/aac9ef58c9539490f4005264f7b976164997b8c1:

Feature AppRequest/AppNotify more prominently in the intro blurp, moving it up a bit
Clarify in AppNotify how an application error is created (the previous wording was e.g. for "target" which is a bit ambiguous), also make the example error message clearly application specific
Reword the example callback request example a little bit; add a small note that JSON/JX conversion should avoid errors (might not be apparent, e.g. for looped objects), not sure if it's improved or not
Add an explicit nvalues check for the callback request example to highlight it's critical to check (it was present in the other section but not here), also fix handling when argument 0 is not a string (the example used duk_get_string() which might return NULL and then strcmp()'d it)
Emphasize in the callback explanation section that nvalues may have any value, including zero, so there isn't necessarily even a string command name there, otherwise it'd be easy to write incorrect code

There are also unrelated changes and cleanups in the commits:

Some more notes on TCP transport
Future work note on error codes

Here's the "duk" example for AppRequest and AppNotify: https://github.com/svaarala/duktape/commit/d0fb89c96e107fb9afd1d12e1e44028a809fe4bd.
It'd be nice to illustrate how the AJS heap info could be dumped but it'd need to access AjsHeap internals so I'll probably delete that example; the CommandLine AppRequest is pretty good I think, it's more or less realistic and has no portability impact like some other examples like getting current time or something.

I like the CommandLine example, it might be useful for the debugger to see the target's command line arguments.

There's an issue that just caught me up that is probably impossible to fix, but should be noted in the documentation: Integers pushed to the value stack for requests and notifys will be encoded as "number" (i.e. IEEE double) dvalues.  This came as quite a surprise at first but when I thought about it it made sense why that would be the case.

It would be fine to send them as plain integers when there's no loss of precision. This is what debugger.rst says:
Plain integers are guaranteed for e.g. command numbers:

When not sending a duk_tval value, integer number values must always be encoded as plain integers (not the IEEE double encoding).

duk_tval may use either:

When parsing a duk_tval value, both plain integers and IEEE double values must be accepted.  The plain integers map uniquely to IEEE doubles so there's no loss of information.  Note that a negative zero must be represented as an IEEE double to preserve the sign.

I haven't done that yet but it'd be quite easy to change. It might break some debug clients in a minor way if they played fast and loose with the types though, but shouldn't be difficult to fix either.

For now I just made a minor change to dvalue_as_int() in the SSJ dvalue code that casts the float to an int for number dvalues.  Like I said, it's not really surprising once I thought about it, since by spec all numbers in Ecmascript are floating point.
But that's true that it shouldn't be too hard to fix, since you already have double->int downgrade code in the form of fastint support. :)

I'll add that downgrade code in a separate branch just in case. I have a hunch the change may reveal some incorrect debug client assumptions so it's good to have a bit more advance warning.

Ok, so this is what it looks like when request_cb returns a broken nrets with asserts enabled:
[D] duk_debugger.c:1481 (duk__debug_handle_apprequest): calling into AppRequest request_cb with nvalues=1, old_top=7, top=8
[D] duk_debugger.c:1484 (duk__debug_handle_apprequest): returned from AppRequest request_cb; nvalues=1 -> nrets=5, old_top=7, top=11
PANIC 54: assertion failed: duk_get_top(ctx) >= old_top + nrets (duk_debugger.c:1486) (segfaulting on purpose)
Segmentation fault

and without asserts:
[D] duk_debugger.c:1481 (duk__debug_handle_apprequest): calling into AppRequest request_cb with nvalues=1, old_top=7, top=8
[D] duk_debugger.c:1484 (duk__debug_handle_apprequest): returned from AppRequest request_cb; nvalues=1 -> nrets=5, old_top=7, top=11
[D] duk_debugger.c:1492 (duk__debug_handle_apprequest): AppRequest callback doesn't match value stack configuration, top=11 < old_top=7 + nrets=5; this might mean it's unsafe to continue!

I like that it's explicitly noted in the debug log that it might be unsafe to continue.

@svaarala By the way, thanks for the quick response on the AppRequest pull, because of that and the very functional heap walking I was able to release the second beta of minisphere 3.0 with a vastly improved debugger. :-)

@fatcerberus Ok, so I'm done with this pull; the relevant changes which you may want to check are:

Minor changes to the AppRequest implementation: https://github.com/svaarala/duktape/commit/ea8866562a1f830ebc600a0bcaf75ab1054776bb. One thing I don't like there is the naming of duk__debug_null_most_callbacks() but I couldn't come up with a short alternative for "NULL everything but detached callback".
API docs: https://github.com/svaarala/duktape/commit/1b155525b6cc5d8f4a0779e292f3b7cb94a73ec4
Minimal API testcases (what's possible without attaching): https://github.com/svaarala/duktape/commit/b49053d3b6721c7597c7754267c361f17a00822d
Website updates: https://github.com/svaarala/duktape/commit/c236fa0eed4e72c020949340a4e71dd55de395b7

No issues with the diffs, I'll test the branch a bit later.

Everything seems to be working properly still:
D:\src\spectacles-i>ssj specs-bs.spk
SSJ 3.0a3 minisphere CLI debugger (x64)
A powerful JavaScript debugger for minisphere
(c) 2016 Fat Cerberus

starting D:/src/spectacles-i/specs-bs.spk... OK.
connecting to <IP_ADDRESS>:1208... OK.
verifying... OK.
    inferior: minisphere 3.0a3
    duktape v1.4.0-167-gc2ecdc4

querying target... OK.
    game title: Spectacles: Bruce's Story
    author: Fat Cerberus
    source: D:/src/spectacles-i/

=> # 0: eval() at scripts/main.js:6
6: const DBG_DISABLE_TEXTBOXES = false;

scripts/main.js:6 eval()
(ssj) c
t: Spectacles: Bruce's Story [miniRT]
t: Sphere v2.0 (minisphere 3.0a3)
t:
t: Initializing Specs Engine test harness
t: Loading testcases from 'brucesStory.js'
t: Added battle test 'rsb1'
t: Added battle test 'rsb2'
t: Loading testcases from 'lastLucidan.js'
t: Added battle test 'temple'
t: Added battle test 'scott'
t: Initializing new game session >>diff lv: 2
t: Created party manager
t: Created new PC Scott >>lvl: 50
t: PC Scott learned skill Sword Slash
t: PC Scott learned skill Quickstrike
t: PC Scott learned skill Charge Slash
t: PC Scott learned skill Flare
t: PC Scott learned skill Chill
t: PC Scott learned skill Lightning
t: PC Scott learned skill Quake
t: PC Scott learned skill Hellfire
t: PC Scott learned skill Windchill
t: PC Scott learned skill Electrocute
t: PC Scott learned skill Upheaval
t: PC Scott learned skill Necromancy
t: PC Scott learned skill Crackdown
t: Added PC Scott to party
t: Initializing time-of-day manager
FATAL UNCAUGHT - Error: scott was eaten by maggie
    at: scripts/maps/Testville.js:72
=> # 0: [anon] at scripts/maps/Testville.js:72
72:                     throw new Error(food + " was eaten by " + muncher);

scripts/maps/Testville.js:72 [anon]
(ssj) v
var muncher = "maggie"
var food = "scott"
var maggieX = 847
var maggieY = 783
var pose = "south"
var foodX = 847
var foodY = 796
var name = "scott"

scripts/maps/Testville.js:72 [anon]
(ssj) bt
=> # 0: [anon] at scripts/maps/Testville.js:72
   # 1: MapEngine() at undefined:0
   # 2: game() at scripts/main.js:53

scripts/maps/Testville.js:72 [anon]
(ssj) c
SSJ session has been detached.

The bit on startup where it says "querying target"?  That was all done with AppRequests.  If someone were to connect to the game using another debug client things would still work. Also I hope your debug client would be able to connect to another target, notice there's no game title, but be otherwise functional :)

In theory SSJ could connect to any Duktape target (assuming a V1 protocol), although it probably wouldn't be able to locate source code since the target wouldn't respond to the "source path" request.  I personally find symbolic debuggers useless without the original source. ;)

You know what else is awesome?  Now that I have AppRequests at my disposal, I no longer need Duktape to be able to track source code - I can just query minisphere for the source.  Truly this is one of the best additions to Duktape ever. :)

That'd be worth mentioning in the documentation too I think, reading sources from the target.


if domain and insecure specified then set for prev

What happened:
I was doing some local development and I specified both a cookie domain x and cookie insecure on in my Caddyfile. In this case, insecure was added to the default config, but the cookie writing logic checked the domain entry.
That logic is in another repo, go-authcrunch.
What I expected:
no Secure; HttpOnly; strings in cookies if the authentication block sayscookie insecure on.
What the PR contains:
updateAuthPortalCookieConfig now checks to see if domains exist.  If so, insecure is added to those keys. If it is the  config writer's intent, they can have some domains use secure cookies by specifying them after the cookie insecure on line. The config test now includes cookie insecure on. No changes were needed to go-authcrunch because the struct lines up with the Caddyfile.

If I were the package maintainer, I would not accept this PR. Instead, I would remove per-domain Insecure field, and just use  CookieConfig.Insecure in go-authcrunch. This would simplify the code and follow the principle of least surprise. (I think that people assume a line in a config block applies to the whole block.)
However, that change would be more disruptive,  so I have instead included this minimal change which I think follows the maintainer's intent.

@DevinMcCode , thank you for the contribution 👍 it makes sense. Will merge by the end of the weekend (will be releasing ui changes).


Fix generated link anchors

Near the bottom of page http://www.fosshub.com/JabRef.html, there is a line

Found this software useful? Please consider a donation to the author. "Button Donate"

This links to http://www.jabref.org/#donations, which leads to the top of the page and not to the donation section.
The link should be http://www.jabref.org/#sections50-donations

This is because we fixed #29 and thus the anchors are generated differently. I know that Cool URIs don't change, but I hadn't the time to dive into the topic.
We have to investigate the Jekyll generation further.

For the record: same thing here: http://jabref.sourceforge.net/contact.php

What is the issue with http://jabref.sourceforge.net/contact.php? It redirects to http://www.jabref.org/#help, which is displayed as programmed in the template.

I fixed this issue at a9847adbc3c6730bc56, so I would vote to close this one.

Cannot find it anymore... Sorry...


GraphQL Query failure when mappings exist for relationship fields

When there exists mapping for relationship fields in a M:N relationship, GraphQL query fails
Config File - Mapping declaration
Entity : Book
"mappings": {
        "id": "identifier"
  },

Authors relationship
"authors": {
          "cardinality": "many",
          "target.entity": "Author",
          "source.fields": [
            "identifier"
          ],
          "target.fields": [
            "id"
          ],
          "linking.object": "book_author_link",
          "linking.source.fields": [
            "book_id"
          ],
          "linking.target.fields": [
            "author_id"
          ]
        }

Query
{
  books {
    items {
      identifier
      title
      authors {
        items {
          id
          name
          birthdate
        }
      }
    }
  }
}

Issue https://github.com/Azure/data-api-builder/issues/2166 covers this bug for all relationship types, so this one will be closed as duplicate.


[Update] Updating the adaptive-loading demos to use the new package of hooks

A new task high up in priority is a PR that updates the adaptive-loading demos to use the new package of hooks from npm (where possible)

@addyosmani
I think battery hook is missing from react-adaptive-hooks. Is it on purpose?

Yeah, we dropped it as Battery Status API is likely going away. I think we can continue using a custom hook in this repo for it during the time being.


fix(config): force Wake Up as supported for Aeon Labs Minimote

fixes: #1536

@kpine did you have a chance to verify if this works?

@kpine did you have a chance to verify if this works?

Sorry, not yet. Need to figure out how to get the file into zwavejs2mqtt docker image and reload it, haven't had a chance yet.

Sorry, not yet. Need to figure out how to get the file into zwavejs2mqtt docker image and reload it, haven't had a chance yet.

@zwave-js-bot pack this

@zwave-js-bot pack this

@kpine you can either build a custom image with this branch - or if you prefer the Node.js way, install zwave-js using the command the bot is going to post in a minute.

@kpine you can either build a custom image with this branch - or if you prefer the Node.js way, install zwave-js using the command the bot is going to post in a minute.

Great, I'll give it a try today.

Great, I'll give it a try today.

I think it looks good. I ended up just downloading the file into the container, replacing it in the two locations I found the existing file, and restarted the container. Then I excluded the node, restarted zwavejs2mqtt (not necessary), then added the node. I checked the cache and the wake up class was set. I restarted zwavejs2mqtt and in the UI the node kept all its information, never went dead, and has stayed Asleep. Interview considered it asleep instead of dead. Attached is the inclusion/restart log for completion. Thanks!
zwavejs_1.log

I think it looks good. I ended up just downloading the file into the container, replacing it in the two locations I found the existing file, and restarted the container. Then I excluded the node, restarted zwavejs2mqtt (not necessary), then added the node. I checked the cache and the wake up class was set. I restarted zwavejs2mqtt and in the UI the node kept all its information, never went dead, and has stayed Asleep. Interview considered it asleep instead of dead. Attached is the inclusion/restart log for completion. Thanks!
zwavejs_1.log

While you're at it, could you also check https://github.com/zwave-js/node-zwave-js/pull/1544 as an alternative broader solution?

While you're at it, could you also check https://github.com/zwave-js/node-zwave-js/pull/1544 as an alternative broader solution?

Sure, I can do that.

Sure, I can do that.

Following the discussion in https://github.com/zwave-js/node-zwave-js/discussions/1537, I'm going to modify #1544 in a way that it won't help you without this PR.

Following the discussion in https://github.com/zwave-js/node-zwave-js/discussions/1537, I'm going to modify #1544 in a way that it won't help you without this PR.

So how would I test both of these? Build an image with the other PR and copy this file into it? Or can you rebase this on the other PR?

So how would I test both of these? Build an image with the other PR and copy this file into it? Or can you rebase this on the other PR?

I meant there's no need - thanks anyways.

I meant there's no need - thanks anyways.


Refactor unit tests for controller folder

using table driven testing

/cc kashifest

/cc xenwar

/cc fmuyassarov


Is Custom Styles Overriding Still Available?

I wanted to override some default provided css styles (mainly the accent color like --vp-c-brand-X), but end up failing after these tries:

Using a index.scss file at /docs/.vuepress/styles/index.scss as mentioned here (this document contains broken links).
Using a palette.scss file at /docs/.vuepress/styles/palette.scss.
Using a palette.styl file at /docs/.vuepress/styles/palette.styl as in VuePress 1.
Using something similar to a custom.css file used in a regular Vue (Vite) app.

I wonder if the ability to introduce custom styles globally still available, and if there's a document I can refer to.

I am sorry for the errors and omissions in this section of the document. I have now updated the document, and you can refer to the new document for a custom style.

I am sorry for the errors and omissions in this section of the document. I have now updated the document, and you can refer to the new document for a custom style.

Thanks for the quick response! The new document solves the problem.


Access extras on SpannedIter

There's the Extras item on the lexer, but there's no way to access that once you converted it to a SpannedIter via Spanned.
Would it be possible to add that to the SpannedIter as well?

Implemented by #231, but we don't know when it's going to be merged.

Very similar to #231, it's just missing the method to access this field.


ttf2woff2.js Array Buffer Allocation Failed

I am running node.js 9 on a vanilla CentOS 7 box. I am simply issuing the enduro create project command and I get the following Unhandled rejection RangeError:  Array Buffer Allocation Failed error about the ttf2woff2.js module.

@BackPacker777 did you manage to overcome it?

?No, sorry.
~HB

From: Guy Korland<EMAIL_ADDRESS>Sent: Monday, November 20, 2017 3:06 PM
To: Gottwik/Enduro
Cc: Howard E. Bates; Mention
Subject: Re: [Gottwik/Enduro] ttf2woff2.js Array Buffer Allocation Failed (#171)
@BackPacker777https://github.com/backpacker777 did you manage to overcome it?

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Gottwik/Enduro/issues/171#issuecomment-345814550, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGaGbju_2PqT6xyyE6dLtDlL3zozUhK7ks5s4dutgaJpZM4QTlCj.
--
This email was Malware checked by UTM 9. http://www.sophos.com

Bump


[Request] Add protonvpn

PackageIdentifier: protonvpn
PackageVersion: 1.20.4
PackageLocale: en-US
Publisher: Protonvpn
PackageName: protonvpn
License: open source
ShortDescription: vpn service provider
Installers:
Architecture: x64
InstallerType: exe
InstallerUrl: https://github.com/ProtonVPN/win-app/releases/download/1.20.4/ProtonVPN_win_v1.20.4.exe
ManifestType: singleton
ManifestVersion: 1.0.0

Duplicate of #4678


The -o option does not put in a space and so fails to work (v 3.4.1)

Describe the bug
When using the -o there is not a space put in the command that is run (you can put in a manual space as a work around for the moment)
e.g.
cconstab@tarial ~ % sshnp -f @cconstab -t @kryz_9850 -d xmtpi -h @rv_am -s id_ed25519.pub -o "-L 9000:<IP_ADDRESS>:80"
ssh -p 50687 pi@localhost -o StrictHostKeyChecking=accept-new -o IdentitiesOnly=yes -i /Users/cconstab/.ssh/id_ed25519-L 9000:<IP_ADDRESS>:80

Notice the '/Users/cconstab/.ssh/id_ed25519-L 9000:<IP_ADDRESS>:80 ` lack of space !
Steps to reproduce

First run the command
Then I see the error
And then manually put in the required space and things work

Expected behavior
No need for the space in the '-o' option
Screenshots
No response
Smartphones

sshnp 3.4.1

Were you using an atApplication when the bug was found?
No response
Additional context
No response

I'll put up a PR to release a v3.4.2 with this fix...
I believe the behaviour of this option is broken on trunk due to my misunderstanding of the feature

Actually, I won't create a PR because we don't want to merge this to trunk since it has already changed drastically... I will create a pre-release which can be approved and released as latest

Doing a multibuild to add to the PR before we promote:
https://github.com/atsign-foundation/sshnoports/actions/runs/5998264887

The other part of this issue is fixing the behaviour on trunk, which I will add to a PR


RTL support for layout

if i set collectionflowlayout to this library, my collectionview ignores the semantics set by me. e.g i wanted RTL but when i set it let it again go the semantic property and always shows Left to right.
Any idea how to fix it ?

Any luck on solving this issue ?!

Unfortunately, that's not supported by this library.
Mentioned in the limitations section


Replace deprecated API call

Since neovim v0.10 the API call vim.lsp.get_active_clients was deprecated and replaced by the function call vim.lsp.get_clients.
This seems to be already known since there was a comment in the code about it and I assume this was done to be compatible with older neovim version, but for me it now bubbles up as a warning each time I start neovim.

Thank you for the change.
Could you also change the requirement section accordingly in the README while you're at it? 😅

Thanks for the fast response. I updated the requirements in the README accordingly.

Great, thanks so much!


Add option to manually start Schedules

Pull request: (https://github.com/Sentaroh/SMBSync2/pull/180)
Hi,
I had this patch since a few months but with inline code to parse the schedules
I finally found some time to look at the intent and clean it to use the existing timer intent code
This patch enables to start Schedules manually as I really needed that option I was used to in FolderSync and FreeFileSync
When we have a Schedule setup to run many tasks in a specified order, this can be annoying to always manually select the specified tasks when we do not want them to be set on Auto
This patch makes it possible to manually start either All Enabled Schedules or only Some Selected Schedules
Not implemented in the patch / To do:

msg entries not added in xml layout: only english in-code (to not conflict with previous pull requests). The final getString from resources code is written but commented
I did not add a dedicated intent ACTION label in the manifest, but reused the existing SCHEDULER_INTENT_TIMER_EXPIRED
I let you decide if you prefer a dedicated intent action
I let you decide and enhance if needed the icon I quickly did for my use

Note: I am holding on any further push requests until you are done. I know you are maintaining many repos and that it is an amazing work and a lot of time
Thank you for all your work and best regards

Thank you.
Why don't you do the following?

Sync button at the top of the screen shows only Task tab.
Display the Sync button on the schedule item

If you agree, I will implement it myself.
Best regards.

Hi,
Yes, it is a nice idea as you propose with sync button on the right of each schedule. It also makes teh GUI consistent between SyncTAB and ScheduleTAB
However, it would be great, like in SyncTab, to also have these 2 features I added in my pull request:

top sync button to start All Enabled Schedules
when in check mode, top sync button starts teh selected schedules

This makes it also consistent and same behavior as the SyncTab + it is really nice to start all enabled Schedules in one click + selected schedules
It would be great if you implement it as the GUI parts take me a lot of time.
Best regards

Hi,

Top Sync button is under consideration because it needs to be made other ICON to have the same meaning as Task tab.
Queue is possible, but it will be ignored if the same task exists.

Push for Preview.

Hi,
Change ICON.

Best regards.

In your previous version there was a bug I can no more reproduce on this new version:
Randomly, on app restart, the sync button was gone:

Sometimes, on scroll, it would appear and disappear on different lines
I cannot reproduce it on the version with new icons, but I report it so that you can look at the bug if you did not fix it properly because you did not notice it (I did not have time yet to look at the code details)
Best regards

The new layout works properly on my quick tests, thank you for the implementation
I have two things:

the new icons do not match well in color and aspect with your app: dark blue tone, 3D button effects and lightning effect that are all 3 absent in remaining app layouts. Maybe a more sober button to match the look of your app ?

In your previous version there was a bug I can no more reproduce on this new version:
Randomly, on app restart, the sync button was gone:

Sometimes, on scroll, it would appear and disappear on different lines
I cannot reproduce it on the version with new icons, but I report it so that you can look at the bug if you did not fix it properly because you did not notice it (I did not have time yet to look at the code details)
Best regards

edited with my feedback :-)
best regards

Thank you.
New ICON.

The lack of ICON is a bug in the first version, which has been resolved in the new version.
Best regards.

Thank you, looks really better for me
I will compile asap and lest you know if any issues once done, or I close the issue
Best regards


fix: timer task is time out or enqueue queue_, should run task immediately

Summary by CodeRabbit

Improvements

Enhanced thread execution control in the background processes for better performance and responsiveness.

PR Reviewer Guide 🔍

 ⏱ Estimated effort to review [1-5]
3

 🧪 Relevant tests
No

 🔒 Security concerns
No

 ⚡ Key issues to review

Possible Bug: The logic to reset rsignal_wait to true after waiting might lead to unexpected behavior or race conditions. It's important to ensure that the condition !queue_.empty() || !time_queue_.empty() || should_stop() is still valid after the lock is released and before it's acquired again.

Performance Concern: The use of rsignal_.wait_for with a dynamic wait time based on exec_time - unow could lead to performance issues if not handled correctly, especially in a high-load scenario. This needs careful review to ensure it does not introduce latency or inefficiency.

加上这个逻辑之后，线程还是优先执行到期的timertask吧？
感觉这两个应该拆开，在一个线程中执行不太好。
另外，现在pika中应该是没有用到timer_task。

sry, I think your pr maybe unuseful.  I guess that u maybe wanna do task immediately after waiting for timer task.  Because it costs much time for waiting. But your pr dont improve this problem.  It is similar to this pr #2648.
不好意思，我认为你的 pr 作用不大，我认为你也许是想在等待完 timer task 后立刻执行 task，因为等待需要花费很长时间。但是你的 pr 并不能改善这个问题，这个 pr 的思路与 #2648 接近。

sry, I think your pr maybe unuseful. I guess that u maybe wanna do task immediately after waiting for timer task. Because it costs much time for waiting. When jumping into wait function, if task is not empty, the wait function will be out immediately and if task is empty, the wait function will be waiting. So i think there is no bug in logic.
不好意思，我认为你的 pr 作用不大，我认为你也许是想在等待完 timer task 后立刻执行 task，因为等待需要花费很长时间。当进入 wait 函数的时候，如果 task 为空，wait 函数会直接返回，如果不为空，就继续等。所以我认为这里没有逻辑 bug。


Add timezone to container as rocker doesn't appear to set it.

An attempt was made to get the timezone into the container, but it doesn't appear to be working.

done


Dev rogue10

Codecov Report

Merging #30 into dev will increase coverage by 0.23%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##             dev      #30      +/-   ##
=========================================
+ Coverage   22.8%   23.03%   +0.23%
=========================================
  Files        386      369      -17
  Lines       9355     9258      -97
  Branches     828      824       -4
=========================================
  Hits        2133     2133
+ Misses      7163     7066      -97
  Partials      59       59

Impacted Files
Coverage Δ

Vstack.Externals/WebHelp/JsonWebClient.cs
0% <ø> (ø)
:arrow_up:

...Api/Web/Controllers/ElasticEntityDtoController2.cs
0% <ø> (ø)
:arrow_up:

Vstack.Api/Web/Controllers/RestfulController.cs
0% <0%> (ø)
:arrow_up:

...ernals/ShipEngine/Model/ShipEngineAccountSource.cs
0% <0%> (ø)

...ervices.Elastic/Converters/BaseElasticConverter.cs
0% <0%> (ø)
:arrow_up:

...pEngine/UnderscorePropertyNamesContractResolver.cs
0% <0%> (ø)

...ack.Externals/ShipEngine/Model/ShipEngineApiKey.cs
0% <0%> (ø)

...ck.Externals/ShipEngine/Model/ShipEngineAccount.cs
0% <0%> (ø)

Vstack.Externals/ShipEngine/Client.cs
0% <0%> (ø)

Vstack.Services/Converters/BaseConverter.cs
0% <0%> (ø)
:arrow_up:

... and 30 more

Continue to review full report at Codecov.

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


Add prusa printables button

Proposed Changes

Add button for prusa printables

Screenshot (If Applicable)
Checklist

[x] Tested locally
[ ] Ran yarn ci to test my code
[x] Did not add any unnecessary changes
[x] All my changes appear after other changes in each file
[x] Included a screenshot (if adding a new button)
[x] 🚀

Thank you!


[3.x] [HTML5] Fix wheel/touch callback modifying event after parse.

This is a requirement when input accumulation is enabled, as the events gets automatically put in a queue (without duplication) since #42220.
master version: #52720

Thanks!


Added MGE outputs for benchmarking dataset

MGE outputs run using the 'standard' MGE snakemake pipeline run with varying (r and s) parameter combinations. See config*.yaml for info.

🤖 - Hi! This is an automated message from the barcode validation robot. I'm going to validate the FASTA files in your request. This takes less than two minutes per sequence (about two hours per plate). Subscribe to this thread to get updates. You can safely close this tab.

Hi @SchistoDan - ignore the stack trace for now: the functionality for folding YAML and CSV into the output isn't there yet. Just leave this PR here, the example files are useful so I'll pick this up to get it to work.

Hi @rvosa, thanks for the heads up. Would it be useful for me to create a new PR with just the consensus sequence multi-fasta so barcode_validator can get on with validating? Similarly, I can leave the YAML and CSV files out of the remaining PRs I'm going to do (today or tomorrow) to validate the MGE pipeline variants, and seeing as you have now have examples. Happy to still include them if useful.

🤖 - Hi! This is an automated message from the barcode validation robot. I'm going to validate the FASTA files in your request. This takes less than two minutes per sequence (about two hours per plate). Subscribe to this thread to get updates. You can safely close this tab.


Implement first level test suites

I have divide this front-end test into three level: three-level. And now, I'm implement the first-level test suites.... 😀

Add jest test config in package.json
Add skipLibCheck in tsconfig.json for jest test skip libCheck.
Add jest test ignore config testConfigs/empty-module.js
Add all components snapshot test
Extract some common data logic in utils/ , src/components/tests/utils/
Extract some common types in src/types/index.js
Add test-needed data such as src/components/tests/utils/tuture.yml

Travis-CI locate build error is so difficult = =

I'd better add a config file called webpack.test.config.js for test env init.


bpf: xdp: use bpf_xdp_get_buff_len() when available

This helper was introduced in kernel 5.18 with
0165cc817075 ("bpf: introduce bpf_xdp_get_buff_len helper").

/test

/test

/ci-verifier

/test

I suppose this yet another step towards non-linear XDP packets :shrug: .

/test

/test

/test


lunr.Index.invertedIndex grows exponentially in size after each query

I'm using lunr 2.1.0 with the following plugin:
    function tokenPositionPlugin(builder) {
        let position = 0
        var pipelineFunction = function (token) {
            position += 1
            token.metadata['pos'] = position
            return token
        }
        lunr.Pipeline.registerFunction(pipelineFunction, 'tokenPositionMetadata')
        builder.pipeline.before(lunr.stemmer, pipelineFunction)
        builder.metadataWhitelist.push('pos')
    }

I'm using this positional data to implement phrase search. All is well and fine, except that lunr.Index.intertedIndex[term][field]['pos'] grows in size after each query (by a factor of four in my testing, but that might be query dependent; I'm not sure).
This appears to be because MatchData.combine is mutating the InvertedIndex metadata, rather than a copy. The solution that seems to be working for me is to take a shallow copy of the InvertedIndex[term][field] object during lunr.Index.query(), as seen in https://github.com/i80and/lunr.js/commit/41c7db350c269b3df64543321df04307720fc617.

That doesn't sound good! I'll have a look at re-creating this and then providing a patch.
Also, as an aside, pipeline functions are called with three arguments, one of which is the index of the token within the document/field being searched, e.g. you can just do the following in your pipeline function:
var pipelineFunction = function (token, pos) {
  token.metadata['pos'] = pos
  return token
}

This is documented, but it looks like JSDoc doesn't like how.

I can put together a minimal proof if you have trouble reproducing this issue.
And thanks for the advice! :D I really do love this library; I've been using it for a number of projects over the past couple of years, and it's always delivered.

If you wouldn't mind trying to put together a reproduction, I tried to re-create it here but not getting the behaviour you mention.
I can see where in the code this would be possible, I just can't trigger it at the moment.

It looks like it only triggers when using multiple identical terms in a query. I'm using this for fuzzy-searching as you described here: https://github.com/olivernn/lunr.js/issues/276#issuecomment-308205156
https://github.com/i80and/lunr-bug-reproduction
16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536

<--- Last few GCs --->

[43859:0x102801000]    36699 ms: Mark-sweep 1391.7 (1532.2) -> 1391.7 (1532.2) MB, 340.9 / 0.0 ms  allocation failure GC in old space requested
[43859:0x102801000]    37042 ms: Mark-sweep 1391.7 (1532.2) -> 1391.7 (1488.7) MB, 342.2 / 0.0 ms  last resort
[43859:0x102801000]    37363 ms: Mark-sweep 1391.7 (1488.7) -> 1391.7 (1477.2) MB, 321.5 / 0.0 ms  last resort

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x9bb715a9891 <JS Object>
    0: builtin exit frame: concat(this=0x9121f6720a1 <JS Array[712704]>,0x9121f6720a1 <JS Array[712704]>)

    1: combine [/Users/andrew/Documents/lunr-bug-repro/node_modules/lunr/lunr.js:~2319] [pc=0x254525acdf8d](this=0x1ef10c469561 <JS Object>,otherMatchData=0x9121f672619 <JS Object>)
    2: query [/Users/andrew/Documents/lunr-bug-repro/node_modules/lunr/lunr.js:1859] [pc=0x254525abd0e2](this...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/local/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/usr/local/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/bin/node]
 4: v8::internal::Factory::NewUninitializedFixedArray(int) [/usr/local/bin/node]
 5: v8::internal::Factory::NewJSArrayStorage(v8::internal::Handle<v8::internal::JSArray>, int, int, v8::internal::ArrayStorageAllocationMode) [/usr/local/bin/node]
 6: v8::internal::Factory::NewJSArray(v8::internal::ElementsKind, int, int, v8::internal::ArrayStorageAllocationMode, v8::internal::PretenureFlag) [/usr/local/bin/node]
 7: v8::internal::ElementsAccessor::Concat(v8::internal::Isolate*, v8::internal::Arguments*, unsigned int, unsigned int) [/usr/local/bin/node]
 8: v8::internal::(anonymous namespace)::Fast_ArrayConcat(v8::internal::Isolate*, v8::internal::BuiltinArguments*) [/usr/local/bin/node]
 9: v8::internal::Builtin_Impl_ArrayConcat(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/usr/local/bin/node]
10: 0x25452570415d
Abort trap: 6

Ah right, got it now. Thanks for putting together the reproduction, it'll be a big help in coming up with a better way combining the matched metadata.

Ok, I think there is a reasonably simple fix for this. The metadata held in the inverted index is always an array, this makes cloning the data, to prevent mutation, more straightforward.
While I'm here though I want to take a closer look into the lunr.MatchData object, I have the feeling it can be tidied up a bit.

I've just released a fix for this issue in version 2.1.2, let me know if it solves the issues you were seeing.

It does fix the issue!
However, I do have a concern. Take this for what it is, and obviously feel free to just consider this acceptable loss, but v2.1.2 comes with a hefty performance drop due to the deep copies. Specifically, I get the following performance numbers for a simple test of 1,000 queries:

Version
Seconds

https://github.com/olivernn/lunr.js#v2.1.2
19.1s

https://github.com/i80and/lunr.js/tree/fix-mutation
14.1s

However, I can't come up with a test case where one yields different results from the other. This should be expected: MatchData.combine() never mutates an array. It only ever mutates the metadata object. This means that a shallow copy of the metadata object should be OK unless I'm missing something.

Sigh, yeah, I had a feeling there would be a bit of a hit in performance. I think in general there is some time to be saved around the whole metadata and match data stuff.
The problem with using Object.assign is purely one of compatibility, Lunr currently works anywhere that supports ES5. For later releases (3.x) that might be relaxed, but at the moment I think its still a reasonable baseline.
I'm going to close this issue, but I am taking a look at lunr.MatchData with an eye on making some performance improvements.


[SPARK-44828][BUILD] Upgrade ORC to 1.9.1

What changes were proposed in this pull request?
This PR aims to upgrade ORC to 1.9.1 for Apache Spark 3.5.0.
Why are the changes needed?
To bring the following bug fix.

ORC-1462 Bump aircompressor to 0.25 to fix JDK-8081450

Here is the full release note for more bug fixes.

https://orc.apache.org/news/2023/08/16/ORC-1.9.1/

Does this PR introduce any user-facing change?
No.
How was this patch tested?
Pass the CIs.

ORC-1462 looks like a correctness issue, does it really affects ORC and Spark?

Irrelevant test failures. Thanks @dongjoon-hyun. Merged to master and 3.5

Thank you, @pan3793 and @yaooqinn .
According to Java community and Aircompressor community, java.util.zip.GZIPOutputStream can be affected in case of the concatenated GZip.

https://bugs.openjdk.org/browse/JDK-8081450
https://github.com/airlift/aircompressor/pull/171

For ORC file format, it will fail during accessing the file because ORC file magic code is at the end of the file.


Weed mount not showing changes happening on another node

Describe the bug
I am trying to use seaweedfs as a distributed filesystem. Essentially the seaweedfs mounted folder should more or less be the same on all hosts. Change a file on one server, the changes should be visible on the other server in a a few seconds.
In my testing setup it seems like file creation and deletion sync properly but changes to a file don't. The master server sees changes but the other mounts don't see the changes.
System Setup

List the command line to start "weed master", "weed volume", "weed filer", "weed s3", "weed mount".

Create the master, filer, and volume server as specified in wiki: https://github.com/chrislusf/seaweedfs/wiki/Directories-and-Files
weed server -filer=true

Create a mount in server1:
mkdir -p /mnt/seaweed
weed mount -filer=localhost:8888 -dir=/mnt/seaweed/ -filer.path=/

Create a mount in server2:
mkdir -p /mnt/seaweed
weed mount -filer=server1ip:8888 -dir=/mnt/seaweed/ -filer.path=/

Create a file on server1:
echo "testing" > /mnt/seaweed/testing.txt

Edit file on server2:
nano /mnt/seaweed/testing.txt
insert changes

See differences in files on both servers:
server2:
# cat testing.txt
testing

testing2

server1:
# cat testing.txt
testing

But if I dig around in the actual master server the changes do appear to be there.
curl http://server1:8080/5,3f6f9515ff

testing

testing2

OS version

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:        18.04
Codename:       bionic

output of weed version

root@server1:~# weed version
version 30GB 2.42 84312e6 linux amd64

if using filer, show the content of filer.toml

[leveldb2]
# local on disk, mostly for simple single-machine setup, fairly scalable
# faster than previous leveldb, recommended.
enabled = true
dir = "./filerldb2"                                     # directory to store level db files

Expected behavior
The files should be synced eventually. Even if I wait a few minutes, the files never seem to sync up. The only thing that syncs them is unmount and then remounting. Or deleting and creating a new file.
It seems like seaweedfs should support this, but let me know if I misunderstood something.

I can not reproduce this.

Is there any more info I can give you that might be useful?
Perhaps this is a kernel issue caching files too heavily? I noticed there were some other issues referencing similar things.

You can use https://github.com/chrislusf/seaweedfs/blob/master/docker/Makefile#L24 as an example to create reproducible docker setup.

This didn't work in local-mount-compose.yml either unfortunately.
Setting it up and then doing
docker exec -it seaweedfs_mount_1_1 sh
docker exec -it seaweedfs_mount_2_1 sh

Added vim to both containers and then created a test.txt file on mount_1 and editted it on mount_2:

I had to make a minor change to get it to run on my Mac though:
diff --git a/docker/compose/local-mount-compose.yml b/docker/compose/local-mount-compose.yml
index b1c579cd..8c432905 100644
--- a/docker/compose/local-mount-compose.yml
+++ b/docker/compose/local-mount-compose.yml
@@ -38,7 +38,7 @@ services:
   mount_2:
     image: chrislusf/seaweedfs:local
     privileged: true
-    entrypoint: '/bin/sh -c "mkdir -p t2 && mkdir -p cache/t2 && weed -v=4  mount -filer=filer:8888 -cacheDir=./cache/t2 -dir=./t2 -filer.path=/c1 -volumeServerAcess=publicUrl"'
+    entrypoint: '/bin/sh -c "mkdir -p t2 && mkdir -p cache/t2 && weed -v=4  mount -filer=filer:8888 -cacheDir=./cache/t2 -dir=./t2 -filer.path=/c1"'
     depends_on:
       - master
       - volume

Added a fix. Please help to verify the fix.

Hi there, unfortunately I don't think that worked. Same setup with docker-compose:
Created the file in t1 first, then editted it in t2, then viewed it in t1 again.

I rolled back a few versions to 2.34 (9672f9e) and it worked in the local docker setup. I'll have to try out the actual server setup but I imagine you'll figure out the real issue soon! Let me know if I can help verify any other fixes.

I think I was able to fix this by downgrading to 9672f9e but I need to test further. Happy to test any other fixes you put up though.

can not reproduce. Please check the version.

This still didn't work for me on Docker. I ran make clean on in the repo root directory as well as in the docker folder. I also deleted all containers, and images.
I'll test with one of the binaries that are built on dev now.

Okay perhaps the Docker image is caching something? This works properly with https://github.com/chrislusf/seaweedfs/releases/download/dev/weed-2021-05-01-05-52-linux-amd64.tar.gz running on actual hardware. Thanks for the quick fix!


Aimbot is dead

Just simply,doesn't work.

This is my cute little config:
https://hastebin.com/ibuxixanem.json

        "KillTimeout" : {
           "Enabled" : true,
           "Value" : 1
        },

Nothing else to say, except that you don't read anything there.


Removed unnessary devDependencies as they are defined in bitcore-build

ACK

Changes Unknown when pulling a2e0cb5abc61e2d4c7e17d9815966f0987929bfe on braydonf:update/devDependencies into ** on bitpay:master**.


Transfer logCollect tarballs to CERN EOS

Fixes #5719 and takes over Seangchan's PR #6294 .
Tested with 2 workflows (one at FNAL and another at Pisa) and everything worked fine.
Credits to Seangchan for doing 99% of the code changes :-)

Beginning pylint and unit tests.
See https://cmssdt.cern.ch/jenkins/job/DMWM-PR-test/721/ for details

Alan,  it is all your effort. we don't count effort by number of lines code wrote but who solve the problem. :smile: Thanks a lot for fixing the problem.

Summary of pylint changes for pull request 6300:

Score for src/python/WMCore/WMSpec/Steps/Executors/LogCollect.py decreased from 9.92 to 9.86
Warnings for src/python/WMCore/WMSpec/Steps/Executors/LogCollect.py increased from 1 to 2

src/python/WMCore/WMSpec/Steps/Executors/LogCollect.py got worse in pylint. Report follows:

Line 50 in LogCollect.execute R0914 Too many local variables (35/30)
Line 184 in LogCollect.execute W0703 Catching too general exception Exception
Line 224 in LogCollect.execute W0703 Catching too general exception Exception
Line 50 in LogCollect.execute R0912 Too many branches (21/12)
Line 50 in LogCollect.execute R0915 Too many statements (117/100)
plus 35 comments on code style

Unit test changes for pull request 6300:

WMCore_t.WorkQueue_t.WorkQueue_t.WorkQueueTest:testConflicts changed from success to failure

Previously working unit tests have failed!

@amaltaro this succeeded in its checks an hour ago. :-)

How come? It silently succeeded then, because what I see here is "Previously working unit tests have failed!" and a big red button saying "All checks have failed"  :(

Well, "All checks" means that Jenkins failed. We have no other checks. And it failed because of the unit test failure. And maybe the pylint score decrease.

So Jenkins ran successfully, it just doesn't like what it found. Ergo a big red X.

Ok, I pushed this patch in to all the production agents.
@ticoann feel free to merge it, it does not impact in cmsweb services.


Add actionbar to Preference Screens

Please search to check for an existing issue (including closed issues, for which the fix may not have yet been released) before opening a new issue: https://github.com/k9mail/k-9/issues?q=is%3Aissue
Expected behavior
When we go in the parameter, what ever the correction or change that we made in the setup, we should be able thereafter to go back to the previous screens until we reach our emails.
Actual behavior
For example, imagine that we select account parameters. From that screen, we have general parameters, emails reading, files, storage and so on.  But we dont have the arrow on the left up conner in order to go back the previous screen.
To exit from this screen i have to restart my cell.  When I select your software, I am back in the email screen.
is it possible to correct this problem
Steps to reproduce

Environment
K-9 Mail version:
Android version:
Account type (IMAP, POP3, WebDAV/Exchange):

In most cases the phone's back button should do what you want. But it should be consistent with other screens anyway..
I don't know how this will work in the Material Design. I'll leave it open for now.

  It should be consistent with the previous screen. So we should have a back arrow on the left corner to go back to the previous screen.
And yes, I found the back button on my phone and it works.
Regards,
Alain LePage
---------- Message d origine ----------
De : Philip<EMAIL_ADDRESS>Daté : 4 avril 2017 à 03:59
In most cases the phone's back button should do what you want. But it should be consistent with other screens anyway..
I don't know how this will work in the Material Design. I'll leave it open for now.
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.


Missing Vue License

Vue version
Any
Link to minimal reproduction
/
Steps to reproduce
Checkout CDN code<EMAIL_ADDRESS>What is expected?
There should be information about the license of the code in js file, imo.
What is actually happening?
There's no license information in the CDN code nor in the bundle which is generated by vite for example.
Unless I'm completely mistaken it should be included like the license says
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

Pinia for example has at least this
https://github.com/vuejs/pinia/blob/v2/rollup.config.mjs#L44
which results in the following to appear after building
/*!
 * pinia v2.1.7
 * (c) 2023 Eduardo San Martin Morote
 * @license MIT
 */

System Info
/

Any additional comments?
sorry if this isnt perhaps the right replace to mention this.

The license inclusion requirement only applies to users using the software, not the copyright owner distributing it. Technically the license is already distributed as part of the npm package (e.g. https://unpkg.com/browse/vue@3.4.7/LICENSE), but I guess we can include a small banner in individual files as well.

Even if we include the banner in dist files, bundlers are not guaranteed to preserve them. This is not something we can enforce so like you said, this is probably not the place to discuss that.

Even worse in the bundlers case I'd say. From what I can tell vite/rollup at least preserves any comments starting with @license, like the pinia banner.


Change VSCode Extension configuration to use the mirrord config file

Currently configuration is done through the UI and is pretty non-standard and has to be updated every time we add a new configuration value (it's pretty out of date already). We should have it use the mirrord config file instead, and if possible and simple, also provide some UI for it - perhaps through the extension settings window of VS Code.

i think, if conifg file is found, we can just warn the user that we are using the config file otherwise we spawn the UI. besides that on the implementation level I think we'd have to use a json/toml/yaml parser and set the env accordingly..

we don't need to set any env; you provide the layer the config path and it uses it instead of any other env.

we don't need to set any env; you provide the layer the config path and it uses it instead of any other env.