correct error in online tutorial markup

From<EMAIL_ADDRESS>on February 10, 2012 16:08:54
The code for the first measure shows the same pitch (C3) being repeated in the left hand, but in the example the pitch jumps up an octave.
Original issue: http://code.google.com/p/music-encoding/issues/detail?id=50

From<EMAIL_ADDRESS>on February 22, 2012 00:23:19
It's fixed.
Status: Fixed
Cc<EMAIL_ADDRESS>


fix: update to eye v8.7.3

fix: update to eye v8.7.3

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

npm package (@latest dist-tag)
GitHub release
v10.7.2

Your semantic-release bot :package::rocket:


latest master branch build failure

[ 15%] Built target azure-core
[ 25%] Built target azure-storage-common
[ 30%] Built target azure-storage-files-shares
[ 38%] Built target azure-storage-blobs
[ 46%] Built target azure-storage-files-datalake
[ 50%] Built target azure-storage-sample
[ 52%] Built target gtest
[ 54%] Built target gmock
[ 56%] Built target gtest_main
[ 76%] Built target azure-storage-test
[ 86%] Built target azure-core-test
[ 88%] Built target azure_hang
[ 89%] Linking CXX executable azure_core_storage_issue_248
/usr/bin/ld: ../../libazure-core.a(curl.cpp.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/usr/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_storage_issue_248.dir/build.make:105: sdk/core/azure-core/test/e2e/azure_core_storage_issue_248] Error 1
make[1]: *** [CMakeFiles/Makefile2:597: sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_storage_issue_248.dir/all] Error 2
make: *** [Makefile:160: all] Error 2

We are unable to reproduce this failure.  If you have a repro, please provide details on the OS, targeted arch, and any build flags/options you are passing.

mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=ON
make -j

Ubuntu 20.04 LTS
gcc version 9.3.0
cmake version 3.18.0

I can also reproduce it on CentOS

seems it's caused by not linking to pthread.
can core sdk try to link to pthread like this
set(CMAKE_THREAD_PREFER_PTHREAD TRUE)
set(THREADS_PREFER_PTHREAD_FLAG TRUE)
find_package(Threads REQUIRED)
target_link_libraries(YOUR_TARGET Threads::Threads)

to reproduce on Ubuntu 20.04
apt-get update
apt-get install g++ cmake git libcurl4-openssl-dev libxml2-dev libssl-dev
git clone https://github.com/Azure/azure-sdk-for-cpp.git
cd azure-sdk-for-cpp/
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=ON
cmake --build .

error message:
Scanning dependencies of target azure_core_storage_issue_248
[ 89%] Building CXX object sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_storage_issue_248.dir/azure_core_storage_list_containers_sample.cpp.o
[ 90%] Linking CXX executable azure_core_storage_issue_248
/usr/bin/ld: ../../libazure-core.a(curl.cpp.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/usr/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_storage_issue_248.dir/build.make:86: sdk/core/azure-core/test/e2e/azure_core_storage_issue_248] Error 1
make[1]: *** [CMakeFiles/Makefile2:564: sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_storage_issue_248.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

I have the same problem when -DBUILD_TESING option is ON on Ubuntu 20.04. Command:
mkdir build && cd build && cmake -DBUILD_TESTING=ON .. && make -j12
Message:
[ 23%] Linking CXX executable azure_core_storage_issue_248
/usr/bin/ld: ../../libazure-core.a(curl.cpp.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/usr/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_storage_issue_248.dir/build.make:86: sdk/core/azure-core/test/e2e/azure_core_storage_issue_248] Error 1
make[1]: *** [CMakeFiles/Makefile2:565: sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_storage_issue_248.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 24%] Linking CXX executable azure_core_with_curl
[ 25%] Linking CXX executable azure_core_with_curl_stream
/usr/bin/ld: ../../libazure-core.a(curl.cpp.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/usr/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_with_curl.dir/build.make:86: sdk/core/azure-core/test/e2e/azure_core_with_curl] Error 1
make[1]: *** [CMakeFiles/Makefile2:646: sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_with_curl.dir/all] Error 2
/usr/bin/ld: ../../libazure-core.a(curl.cpp.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/usr/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_with_curl_stream.dir/build.make:86: sdk/core/azure-core/test/e2e/azure_core_with_curl_stream] Error 1
make[1]: *** [CMakeFiles/Makefile2:619: sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_with_curl_stream.dir/all] Error 2
[ 26%] Linking CXX static library libazure-identity.a
[ 27%] Linking CXX executable azure_core_storage_issue_249
[ 27%] Built target azure-identity
/usr/bin/ld: ../../libazure-core.a(curl.cpp.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/usr/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_storage_issue_249.dir/build.make:86: sdk/core/azure-core/test/e2e/azure_core_storage_issue_249] Error 1
make[1]: *** [CMakeFiles/Makefile2:592: sdk/core/azure-core/test/e2e/CMakeFiles/azure_core_storage_issue_249.dir/all] Error 2
[ 28%] Linking CXX static library ../../../lib/libgtestd.a
[ 28%] Built target gtest
make: *** [Makefile:141: all] Error 2

@RickWinter This is impacting our customers, can anybody from Core sdk take a look and fix it?

The solution by @Jinming-Hu seems to be working, I opened a PR #980 with the proposed code change.

fixed by #980


[bug]: patchmatch failed to load or compile on Arch

Is there an existing issue for this problem?

[X] I have searched the existing issues

Operating system
Linux
GPU vendor
Nvidia (CUDA)
GPU model
RTX 3060
GPU VRAM
12GB
Version number
4.0.4
Browser
Librewolf 124.0.1-1
Python dependencies
No response
What happened
After clear installation on Arch patchmatch doesn't work
Generate images with a browser-based interface
>> patchmatch.patch_match: ERROR - patchmatch failed to load or compile (/run/media/User/SSD/InvokeAI/.venv/lib/python3.11/site-packages/torch/lib/libgomp-a34b3233.so.1: version `GOMP_5.0' not found (required by /usr/lib/libvtkCommonCore.so.1)).
>> patchmatch.patch_match: INFO - Refer to https://invoke-ai.github.io/InvokeAI/installation/060_INSTALL_PATCHMATCH/ for installation instructions.
[2024-04-16 13:53:11,368]::[InvokeAI]::INFO --> Patchmatch not loaded (nonfatal)
[2024-04-16 13:53:13,161]::[InvokeAI]::INFO --> Using torch device: NVIDIA GeForce RTX 3060
[2024-04-16 13:53:13,475]::[InvokeAI]::INFO --> cuDNN version: 8902
[2024-04-16 13:53:13,562]::[uvicorn.error]::INFO --> Started server process [1099918]
[2024-04-16 13:53:13,562]::[uvicorn.error]::INFO --> Waiting for application startup.
[2024-04-16 13:53:13,562]::[InvokeAI]::INFO --> InvokeAI version 4.0.4
[2024-04-16 13:53:13,562]::[InvokeAI]::INFO --> Root directory = /run/media/digital_dominus/GAMES_SSD/InvokeAI
[2024-04-16 13:53:13,566]::[InvokeAI]::INFO --> Initializing database at /run/media/digital_dominus/GAMES_SSD/InvokeAI/databases/invokeai.db
[2024-04-16 13:53:14,287]::[uvicorn.error]::INFO --> Application startup complete.
[2024-04-16 13:53:14,288]::[uvicorn.error]::INFO --> Uvicorn running on http://<IP_ADDRESS>:9090 (Press CTRL+C to quit)

What you expected to happen
I expected that if you install invoke via invoke installer and follow instructions on wiki, everything would work.
How to reproduce the problem
Install Invoke on Arch-based distro i guess?
Additional context
I found some closed issues with mention of

version `GOMP_5.0' not found

But I haven't figured out why they are closed and how to get the patchmatch to work, if someone can explain to me how to fix this I would be very grateful.
Also, before I got the error about GOMP_5.0, I installed a few libraries needed for patchmatch
Discord username
No response

Okay, i found  that i can symlink system library as mentioned in this comment, but i think it would be good to add this on wiki if this error is more or less common on arch-based systems, or (if its possible) somehow fix installer.

It looks like there are a few different solutions in that thread. It probably makes sense to just link to that issue in the patchmatch docs, unless someone wants to parse through the various fixes and format them into a coherent article.

Simply rm ~/invokeai/.venv/lib/python3.10/site-packages/torch/lib/libgomp.so.
I also needed to pacman -S fmt vtk hdf5.

Simply rm ~/invokeai/.venv/lib/python3.10/site-packages/torch/lib/libgomp.so

It is better rename to libgomp.so-old, then
yay -S gomp or gomp-bin
sudo ln -s /usr/lib/libgomp.so libgomp.so

and libgomp errors is gone


Potential way to speed up Mongoose

The scenario:
When users connect to node, I go grab their account data from Mongo and bind it to the connection for the duration of their session.
The problem:
Each Mongoose instance incurs significant overhead in terms of memory consumption and event listeners.  Creating 200 documents in under a second consumed 11MB of RAM.
The theory:
Abstract the Mongoose Schema into a Foundation that is used in Mongoose Schemas and in a new concept, Document Instances.  The Document Instance is a native JS prototype that imitates the structure of a Mongoose Schema without incurring all of Mongoose's overhead.  Append the Schema structure to the Document Instance prototype so that new instances of the Document Instance properly match what is expected in Mongoose.  Append a save function that invokes Mongoose only during saves.
The execution:
https://gist.github.com/1328177
The result:
11MBs of RAM for 200 documents was reduced to 180KB of RAM for 200 Document Instances while preserving Mongoose saving functionality.
Postmortem:
By abstracting the Mongoose Schema into a Foundation, the structure of the document can be used in many other instance, not only for Document Instances, but also for code generation to make client-friendly versions of Mongoose Models that a browser can pull down and use.

most of the overhead in mongoose is incurred by applying defaults at instantiation, specifically for properties of type MongooseArray. i'd love for that to go away but i haven't found any good solutions yet.
what you're doing here removes a lot of the benefits of using mongoose eg utilizing its setters to create fine tuned atomic document updates. in the example above every document will use one large $set for the entire operation thereby creating a high risk of overwriting other changes to that document that occurred before you saved. if all you're doing is creating documents quickly then this might work for you but document updates come with increased risk.
mongoose 0.x worked like this and was one of the big motivations for the rewrite.
that said, I'm sure there is room for massive improvement somewhere.

Thanks for the response.  A question, then.  Does this intended behavior as it exists in Mongoose trigger the same $set problem?
var PersonDocument = mongoose.model('persons', PersonSchema);
var person = new PersonDocument({
   name: 'Bob',
   age: 17
});
person.save();

If so, why it is recommended on Mongoosejs.com documentation?
If not, how is it different than this:

function PersonInstance() {};
var personInstance = new PersonInstance();
personInstance.name = 'Bob';
personInstance.age = 17;

var PersonDocument = mongoose.model('persons', PersonSchema);
var person = new PersonDocument(personInstance);
person.save();

you are correct, your technique is fine for creating documents (if you don't need any setters / virtuals / defaults / etc) and the operation sent to mongo will be the save, just one big $set.

I see.  I'll dig around.. see if I can get something elegant enough to get resource usage down across all systems while still preserving Mongoose functionality.
Thanks for the back-and-forth.

thanks for digging in!


change(deps): Upgrade shared dependencies to match zcashd 5.5.0

Motivation
We want to use the same shared dependencies as the latest zcashd version 5.5.0.
Closes #6232
Specifications
These libraries already implement the consensus rules as specified.
Solution
Upgrade the following shared dependencies:

bellman
bls12_381
group
halo2
halo2_proofs
jubjub
orchard
redjubjub
zcash_address
zcash_note_encryption
zcash_primitives
zcash_proofs

Replace orchard::from_bytes_wide() with ff::from_uniform_bytes()
Review
This is an urgent change we want in the next release, so we continue building with Rust 1.69.
Reviewer Checklist

[ ] Will the PR name make sense to users?

[ ] Does it need extra CHANGELOG info? (new features, breaking changes, large changes)

[ ] Are the PR labels correct?
[ ] Does the code do what the ticket and PR says?

[ ] Does it change concurrent code, unsafe code, or consensus rules?

[ ] How do you know it works? Does it have tests?

Follow Up Work
Upgrade zcash_script:

#6535

Temporary network error building the lightwalletd docker image:

ERROR: failed to solve: failed to compute cache key: failed to copy: read tcp <IP_ADDRESS>:34684-><IP_ADDRESS>:443: read: connection timed out

https://github.com/ZcashFoundation/zebra/actions/runs/4728149718/jobs/8389421342#step:11:786

Failed due to #6506:
https://github.com/ZcashFoundation/zebra/actions/runs/4728149708/jobs/8389424668?pr=6536#step:14:3856


Can not find files when copy from AzureStorage-path written with backslash as separator .

Which version of the AzCopy was used?
10.10.0
Which platform are you using? (ex: Windows, Mac, Linux)
Windows Server 2019
What command did you run?
https://smddevtest.blob.core.windows.net/interfacedata/pattern02\Sub_Folder/* D:\10_DataTransfer\AzureStorage\Download\pattern01 --recursive=false --include-pattern sx_test02.txt*
Note: Please remove the SAS to avoid exposing your credentials. If you cannot remember the exact command, please retrieve it from the beginning of the log file.
What problem was encountered?
We could copy the files from AzureFolder using path with backslash "%5C" as folder separator in AzCopy V8 version.
But the 10.10.0's copy from AzureStorage function can not find files with same path.
How can we reproduce the problem in the simplest way?
Could you support backslash separator in copy function from AzureStorage.

Currently, Copy to AzureStorage function supports backslash separator in 10.10.0.

Have you found a mitigation/solution?
Now, we get back to use V8 version AzCopy.

Hi @nao830713, the current version of AzCopy does not supports "%5C" as backslash separator instead try using a regular backslash "/" for sub folders.


How to detect special characters?

Hi ,
Thanks for such a nice recognition model. I have used the pre trained model "TPS-ResNet-BiLSTM-Attn.pth" for text recognition. I need help with detecting special characters. For instance, in a word<EMAIL_ADDRESS>the special characters like '.' , '@', '-' are not detected in the output. i tried both Attn and CTC as prediction modes. Also i tried changing the argument character, i was getting below error
RuntimeError: Error(s) in loading state_dict for DataParallel:
size mismatch for module.Prediction.attention_cell.rnn.weight_ih: copying a param with shape torch.Size([1024, 294]) from checkpoint, the shape in current model is torch.Size([1024, 307]).

Hello,
TPS-ResNet-BiLSTM-Attn.pth is not trained with special characters.
Try to download and use TPS-ResNet-BiLSTM-Attn-case-sensitive.pth
This model is trained with special characters.
Best


Don't hold implicit reference to activity from loader

MyCourseListTabFragment creates an anonymous implementation of CoursesAsyncLoader, which will reference the fragment, which in turn references the ListView and adapter, and so both will survive, as well as the activity instance itself, even after the activity destroyed.
Fixed by moving the overridden method in the loader, since it is only used in this one place, thus we no longer need an anonymous implementation.

@@            master    #564   diff @@
======================================
  Files          469     469
  Stmts        21894   21891     -3
  Branches      3181    3181
  Methods          0       0
======================================
+ Hit           2936    2940     +4
+ Partial        378     377     -1
+ Missed       18580   18574     -6

Review entire Coverage Diff as of cde607c

Powered by Codecov. Updated on successful CI builds.

I don't think this is the cause of https://fabric.io/edx-inc/android/apps/org.edx.mobile/issues/56ab5ce8f5d3a7f76b6d6638 but it's the only glaring problem I could find.

@BenjiLee ? Quick review? All I did was inline a method :P

:+1:

https://github.com/edx/edx-app-android/pull/571


add needed imports

it is seemed to lack of a few imports

I found another problem around here.
If you run this HTTP tutorial on a machine which different from "http://package.elm-lang.org/", you get following error:
XMLHttpRequest cannot load http://package.elm-lang.org/packages/elm-lang/core/latest/README.md. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://<IP_ADDRESS>:8000' is therefore not allowed access.
I guess package.elm-lang.org doesn't send CORS headers.
To fix this, change url or setup CORS header to the package.elm-lang.org site.


error with some quadratic objective

diff_model fails while defining a problem having objective like this one - https://github.com/jump-dev/MathOptInterface.jl/blob/master/src/Test/contquadratic.jl#L31. Shows:
AssertionError: (size(objective_function.quadratic_terms))[1] == (nz * (nz + 1)) / 2

need to think of some way to extract Q assuming all other terms to be 0

Q is already defined as
Q = zeros(nz, nz)

i think removing the assertion should do


change from golide to dep

Before:
If we run find _vendor/ -type f | wc -l, the output is 1108.
After:
If you run find vendor/ -type f | wc -l and the output is 1783.
I am not sure is it worth to change it or we wait until dep is more stable.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Working on it.


Fixing a bug in _pagination_links

The params list didn't get forwarded to raw_pagination_links and thus the next, previous, ... options didn't work.
Second commit fixes a warnig with newer Elixir versions

Yeah damn. The params is supposed to be url parameters, but the second parameter of raw_pagination_links/2 are options.
That works I guess, but then I guess theres an issue of not being able to use Map.keys(@raw_defaults) as url parameters...

I'm not really sure what you are talking about. I looked twice but I can't find a pice of code containing Map.keys(@raw_defaults) in scrivener_html? Not even a call to 'Map.keys/1`

Ok, now I understand what you are talking about. Well, in this case we nee another parameter containing the options, right? And we need to remove them from pagination_links options list.

I added another commit removing @raw_default from the params for URL generation

Great! I think this works for the time being. Guess we'll have to wait and see if anyone has a problem with any intersection of url params and the options because that would cause a change to the API and a major version bump.


feat: add storage client extension generator

We could get bucket list from {SUPABASE_URL}/storage/v1/bucket, like this:
[
    {
        "id": "avatars",
        "name": "avatars",
        "owner": "",
        "public": false,
        "file_size_limit": null,
        "allowed_mime_types": null,
        "created_at": "2024-09-23T00:51:09.228Z",
        "updated_at": "2024-09-23T00:51:09.228Z"
    },
    {
        "id": "covers",
        "name": "covers",
        "owner": "",
        "public": false,
        "file_size_limit": null,
        "allowed_mime_types": null,
        "created_at": "2024-09-21T15:06:45.988Z",
        "updated_at": "2024-09-21T15:06:45.988Z"
    }
]

This branch will generate storage client code additional according to the json, like this:
// Supabase Storage Client Extension
extension SupadartStorageClient on SupabaseStorageClient {
  StorageFileApi get avatars => from('avatars');
  StorageFileApi get covers => from('covers');
}

Wow we can also do storage.. Thanks again!, will merge this in a bit!


Github

Adds a file github.js .

Export functions that fetches repository, organisation and user data respectively.
Handle Errors with fetching and post to Sentry
Make use of Conditional Requests.
Expose functionality to update ecosystem list (Pull content from github and update the collection list locally)

This is now done @koechkevin


How to create y in the data to predict edge edits?

Hello, I'm trying to predict the edge edits. The notebook examples show how to get a graph classification, which has one y label per data, and show how to get a node classification, which has the same number of y label as nodes. But I'm not sure for predicting edge edits, how can I create y?
Also not sure how to write the loss function? Since the predicted edits and ground-truth edits may have be different in sizes. E.g. ground-truth: there are 3 edits but I only predict there will be 2 edits. I'm thinking of padding them to the max size manually but I want to check if there is a built-in function that does that already.

Well not exactly about GED. In my case, one graph is given as the input (instead of two graphs in the link), the graph edits are known as ground-truth. The project is about given reactant molecules as a graph, trying to predict the edge edits (once we know the edge edit, we know the chemical bond change, and thus we know the product of the reaction. So I somehow need to provide these edge edits as y to feed the model.

Well not exactly about GED. In my case, one graph is given as the input (instead of two graphs in the link), the graph edits are known as ground-truth. The project is about given reactant molecules as a graph, trying to predict the edge edits (once we know the edge edit, we know the chemical bond change, and thus we know the product of the reaction. So I somehow need to provide these edge edits as y to feed the model.


Extension does not handle syntax highlighting and autocompletion in {% stylesheet %} tags properly

Code in {% stylesheet %} tags do not get highlighted or linted in the same way as {% style % } tags. CSS rules in Stylesheet tags are entirely greyed out without syntax highlighting.
This could be related to another issue encountered with this extension/theme-check in the CLI that I reported earlier here #1655 where theme-check was erroneously claiming stylesheet tags with hyphens were not closed.

Oh wow. {% style %} and {% stylesheet %} have both occupied the same slot in my brain for a long time.
That's going to be a bug in the syntax highlighting repo and the prettier-plugin as well.


[AutoPR] machinelearningservices/resource-manager

Created to accumulate context: machinelearningservices/resource-manager

Codecov Report

Merging #2663 into master will decrease coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master    #2663     +/-   ##
=========================================
- Coverage   55.88%   55.79%   -0.1%
=========================================
  Files        7161     7161
  Lines      150710   151195    +485
=========================================
+ Hits        84228    84360    +132
- Misses      66482    66835    +353

Impacted Files
Coverage Δ

...gmt/servermanager/operations/session_operations.py
20.58% <0%> (-4.42%)
:arrow_down:

...e/mgmt/servermanager/operations/node_operations.py
14.67% <0%> (-2.75%)
:arrow_down:

...servermanager/operations/power_shell_operations.py
13.78% <0%> (-2.37%)
:arrow_down:

...gmt/servermanager/operations/gateway_operations.py
41.68% <0%> (-0.56%)
:arrow_down:

...re/mgmt/servermanager/models/gateway_parameters.py
100% <0%> (ø)
:arrow_up:

...zure/mgmt/servermanager/models/gateway_resource.py
100% <0%> (ø)
:arrow_up:

...ager/azure/mgmt/servermanager/server_management.py
100% <0%> (ø)
:arrow_up:

...ermanager/azure/mgmt/servermanager/models/error.py
60% <0%> (+1.66%)
:arrow_up:

...ge/azure/mgmt/storage/storage_management_client.py
52.72% <0%> (+2.72%)
:arrow_up:

Continue to review full report at Codecov.

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

(message created by the CI based on PR content)


update mpiamrvac download

I think mpiamrcav has moved to github:
https://github.com/amrvac/amrvac
(maybe check with Rony)
updating this and also building on a more recent version might fix #230

The old version was from 2012, so updating will probably take a bit of effort.
But I agree it's a good idea to update to a more recent version.
v2.0 seems like it would be a good starting point. I'll make a branch for updating this.

work-in-progress in branch patch-update-amrvac.

ok, thanks..btw..it may take a while for this branch to be merged (if it runs out to require some effort), wouldn't the branch better live in your personal fork? I think we sought to clarify this in #166 and #225 (but then maybe not clear enough ;-) )

You’re right. I’ll move it to my fork.
The most important thing is that this should not be work done in master, as it very much breaks things ;).

ok...
for reference: http://amrvac.org/md_doc_faq.html#faq-new-version


Issue and series window do not update with new information

When a full series or issue call is made via current_item_changed, only a limited number of fields are updated.
Series updates image and desc.
Issues updates issue number, image and desc.
Also, issue only displays month. Year is over written by month looking at it.

The table itself is never updated, those rows are only created when the window is created. The full data is updated internally you just won't see it until you re-open the window.
The fields that you do see update are updated on every change even without the network call.
I'll push out a fix for the date issue in a bit.

Related, it causes a delay when loading the extra data so switching the cursor to "busy" should be done as well.
I'll try and do a PR for both.


Couldn't find a dataset script at cv_portrait_model/rb-meimei_labeled/rb-meimei_labeled.py or any data file in the same directory.

This share link expires in 72 hours. For free permanent hosting and GPU upgrades, run gradio deploy from Terminal to deploy to Spaces (https://huggingface.co/spaces)
显存足够
** Setting base model to SD1.5 **
--------uuid:  qw
----------work_dir:  /workspace/facechain/worker_data/qw/ly261666/cv_portrait_model/rb-meimei
2024-01-15 10:52:21,362 - modelscope - INFO - Use user-specified model revision: v1.0.0
/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/onnxruntime/capi/onnxruntime_inference_collection.py:65: UserWarning: Specified provider 'CUDAExecutionProvider' is not in available provider names.Available providers: 'CPUExecutionProvider'
warnings.warn(
2024-01-15 10:52:22,289 - modelscope - INFO - Use user-specified model revision: v1.0.0
2024-01-15 10:52:23,096 - modelscope - INFO - Use user-specified model revision: v1.0.0
2024-01-15 10:52:23,833 - modelscope - INFO - Use user-specified model revision: v1.0.0
2024-01-15 10:52:30,497 - modelscope - INFO - PyTorch version 2.1.2+cu118 Found.
2024-01-15 10:52:30,499 - modelscope - INFO - Loading ast index from /home/bill/.cache/modelscope/ast_indexer
2024-01-15 10:52:30,558 - modelscope - INFO - Loading done! Current index file version is 1.10.0, with md5 407d4f9c9ea2e6d66553d789ca5ec7f4 and a total number of 946 components indexed
/workspace/facechain/app.py:1275: GradioDeprecationWarning: The style method is deprecated. Please set these arguments in the constructor instead.
output_images = gr.Gallery(label='Output', show_label=False).style(columns=3, rows=2, height=600,
[['/workspace/facechain/resources/inpaint_template/1.jpg'], ['/workspace/facechain/resources/inpaint_template/2.jpg'], ['/workspace/facechain/resources/inpaint_template/3.jpg'], ['/workspace/facechain/resources/inpaint_template/4.jpg'], ['/workspace/facechain/resources/inpaint_template/5.jpg']]
/workspace/facechain/app.py:1378: GradioDeprecationWarning: The style method is deprecated. Please set these arguments in the constructor instead.
output_images = gr.Gallery(
[['resources/tryon_garment/garment1.png'], ['resources/tryon_garment/garment2.png'], ['resources/tryon_garment/garment3.png'], ['resources/tryon_garment/garment4.png']]
/workspace/facechain/app.py:1529: GradioDeprecationWarning: The style method is deprecated. Please set these arguments in the constructor instead.
output_images = gr.Gallery(
2024-01-15 10:52:36,647 - modelscope - INFO - Use user-specified model revision: v4.0
2024-01-15 10:52:38,714 - modelscope - INFO - Use user-specified model revision: v1.0.1
Process Process-1:
Traceback (most recent call last):
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/modelscope/utils/import_utils.py", line 450, in _get_module
requires(module_name_full, requirements)
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/modelscope/utils/import_utils.py", line 353, in requires
raise ImportError(''.join(failed))
ImportError:
modelscope.models.nlp.chatglm2.tokenization requires the SentencePiece library but it was not found in your environment. Checkout the instructions on the
installation page of its repo: https://github.com/google/sentencepiece#installation and follow the ones
that match your environment.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/multiprocessing/process.py", line 314, in _bootstrap
self.run()
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/multiprocessing/process.py", line 108, in run
self._target(*self._args, **self._kwargs)
File "/workspace/facechain/facechain/inference.py", line 25, in _data_process_fn_process
Blipv2()(input_img_dir)
File "/workspace/facechain/facechain/data_process/preprocessing.py", line 205, in init
self.skin_retouching = pipeline('skin-retouching-torch', model='damo/cv_unet_skin_retouching_torch', model_revision='v1.0.1')
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/modelscope/pipelines/builder.py", line 163, in pipeline
clear_llm_info(kwargs)
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/modelscope/pipelines/builder.py", line 227, in clear_llm_info
from .nlp.llm_pipeline import ModelTypeHelper
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/modelscope/pipelines/nlp/llm_pipeline.py", line 15, in
from modelscope.models.nlp import ChatGLM2Tokenizer, Llama2Tokenizer
File "", line 1075, in _handle_fromlist
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/modelscope/utils/import_utils.py", line 435, in getattr
value = getattr(module, name)
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/modelscope/utils/import_utils.py", line 434, in getattr
module = self._get_module(self._class_to_module[name])
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/modelscope/utils/import_utils.py", line 453, in _get_module
raise RuntimeError(
RuntimeError: Failed to import modelscope.models.nlp.chatglm2.tokenization because of the following error (look up to see its traceback):
modelscope.models.nlp.chatglm2.tokenization requires the SentencePiece library but it was not found in your environment. Checkout the instructions on the
installation page of its repo: https://github.com/google/sentencepiece#installation and follow the ones
that match your environment.
instance_data_dir /workspace/facechain/worker_data/qw/training_data/ly261666/cv_portrait_model/rb-meimei
** project dir: /workspace/facechain
** params: >base_model_path:ly261666/cv_portrait_model, >revision:v2.0, >sub_path:film/film, >output_img_dir:/workspace/facechain/worker_data/qw/training_data/ly261666/cv_portrait_model/rb-meimei, >work_dir:/workspace/facechain/worker_data/qw/ly261666/cv_portrait_model/rb-meimei, >lora_r:4, >lora_alpha:32
The following values were not passed to accelerate launch and had defaults used instead:
--num_processes was set to a value of 1
--num_machines was set to a value of 1
--mixed_precision was set to a value of 'no'
--dynamo_backend was set to a value of 'no'
To avoid this warning pass in values for each of the problematic parameters or run accelerate config.
2024-01-15 10:52:49,990 - modelscope - INFO - PyTorch version 2.1.2+cu118 Found.
2024-01-15 10:52:49,994 - modelscope - INFO - Loading ast index from /home/bill/.cache/modelscope/ast_indexer
2024-01-15 10:52:50,053 - modelscope - INFO - Loading done! Current index file version is 1.10.0, with md5 407d4f9c9ea2e6d66553d789ca5ec7f4 and a total number of 946 components indexed
/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/accelerate/accelerator.py:393: UserWarning: log_with=tensorboard was passed but no supported trackers are currently installed.
warnings.warn(f"log_with={log_with} was passed but no supported trackers are currently installed.")
01/15/2024 10:52:52 - INFO - main - Distributed environment: NO
Num processes: 1
Process index: 0
Local process index: 0
Device: cuda
Mixed precision type: no
2024-01-15 10:52:52,608 - modelscope - INFO - Use user-specified model revision: v2.0
{'dynamic_thresholding_ratio', 'clip_sample_range', 'thresholding', 'sample_max_value', 'rescale_betas_zero_snr', 'variance_type'} was not found in config. Values will be initialized to default values.
{'force_upcast'} was not found in config. Values will be initialized to default values.
{'dropout', 'reverse_transformer_layers_per_block', 'attention_type'} was not found in config. Values will be initialized to default values.
Traceback (most recent call last):
File "/workspace/facechain/facechain/train_text_to_image_lora.py", line 1222, in
main()
File "/workspace/facechain/facechain/train_text_to_image_lora.py", line 791, in main
dataset = load_dataset(
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/datasets/load.py", line 2523, in load_dataset
builder_instance = load_dataset_builder(
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/datasets/load.py", line 2195, in load_dataset_builder
dataset_module = dataset_module_factory(
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/datasets/load.py", line 1848, in dataset_module_factory
raise FileNotFoundError(
FileNotFoundError: Couldn't find a dataset script at /workspace/facechain/worker_data/qw/training_data/ly261666/cv_portrait_model/rb-meimei_labeled/rb-meimei_labeled.py or any data file in the same directory.
Traceback (most recent call last):
File "/home/bill/miniconda3/envs/facechain/bin/accelerate", line 8, in
sys.exit(main())
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/accelerate/commands/accelerate_cli.py", line 47, in main
args.func(args)
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/accelerate/commands/launch.py", line 1023, in launch_command
simple_launcher(args)
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/accelerate/commands/launch.py", line 643, in simple_launcher
raise subprocess.CalledProcessError(returncode=process.returncode, cmd=cmd)
subprocess.CalledProcessError: Command '['/home/bill/miniconda3/envs/facechain/bin/python3.10', '/workspace/facechain/facechain/train_text_to_image_lora.py', '--pretrained_model_name_or_path=ly261666/cv_portrait_model', '--revision=v2.0', '--sub_path=film/film', '--output_dataset_name=/workspace/facechain/worker_data/qw/training_data/ly261666/cv_portrait_model/rb-meimei', '--caption_column=text', '--resolution=512', '--random_flip', '--train_batch_size=1', '--num_train_epochs=200', '--checkpointing_steps=5000', '--learning_rate=1.5e-04', '--lr_scheduler=cosine', '--lr_warmup_steps=0', '--seed=42', '--output_dir=/workspace/facechain/worker_data/qw/ly261666/cv_portrait_model/rb-meimei', '--lora_r=4', '--lora_alpha=32', '--lora_text_encoder_r=32', '--lora_text_encoder_alpha=32', '--resume_from_checkpoint=fromfacecommon']' returned non-zero exit status 1.
Traceback (most recent call last):
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/gradio/queueing.py", line 407, in call_prediction
output = await route_utils.call_process_api(
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/gradio/route_utils.py", line 226, in call_process_api
output = await app.get_blocks().process_api(
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/gradio/blocks.py", line 1550, in process_api
result = await self.call_function(
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/gradio/blocks.py", line 1185, in call_function
prediction = await anyio.to_thread.run_sync(
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/anyio/to_thread.py", line 56, in run_sync
return await get_async_backend().run_sync_in_worker_thread(
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 2134, in run_sync_in_worker_thread
return await future
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 851, in run
result = context.run(func, *args)
File "/home/bill/miniconda3/envs/facechain/lib/python3.10/site-packages/gradio/utils.py", line 661, in wrapper
response = f(*args, **kwargs)
File "/workspace/facechain/app.py", line 803, in run
train_lora_fn(base_model_path=base_model_path,
File "/workspace/facechain/app.py", line 207, in train_lora_fn
raise gr.Error("训练失败 (Training failed)")
gradio.exceptions.Error: '训练失败 (Training failed)'
请问这个错误要怎么处理，有人碰到过吗？ conda 环境

Have you solved it yet? Can you give me some suggestions? thanks

please try out the newest train-free, 10s inference version facechain-fact.


Lua to Obj-C

Hello,
Is there a way Lua can send an Asynchronous message to obj-C/swift while executing a function that was invoked from obj-c/swift?

What do you mean by "async" here? Sending a message is always intiazed in a sync way. Then, it could get decoupled by moving it into a thread, and then it runs quasi-parallel, but it's still not async.
Async usually means that a response to a request comes back in an async matter, ie. you don't get it back right away when you make the call to the request, but would get a function called "out of line" of what it's currently doing.
This lib (and Lua in general) allows your app to make calls into Lua functions, and Lua can call functions that your app has provided to the Lua context.
But nothing of this is really async.


don't load property-specific artifacts in Node

Coverage increased (+0.01%) to 92.932% when pulling 0ff2e1d92e3d5b5b55089da494fff36cb26500ce on always-load-global into c35b5a627d4df4771f2e075a4c3f4445f9709e4f on master.


The display of Dai and USDx Token Card

The standard display should be,
"balance" "contract name" "(Symbol)"
Like

It seems broken on Dai and USDx token card,

dforce is the contract name (for both USDx and DF) but is missing the symbol once clicked on the card.
Contract name on the token card is overridden by the TokenScript for localization, however it is strange that a bracket is missing on the end (See https://github.com/AlphaWallet/alpha-wallet-ios/issues/1443)


Issue Title: "Add Cursor-Following Animation"

@Yash-Ainapure
Issue Description: The website currently lacks interactive design elements that enhance user experience. The website is looking good, adding cursor-animation makes it more beautiful, I propose adding a cursor-following animation to create dynamic interactions where design elements move along with the mouse cursor, providing a more engaging and visually appealing experience.
I’d like to work on adding this feature. Please assign this issue to me under hacktoberfest-accepted, gssoc-ext, level

@Yash-Ainapure Issue Description: The website currently lacks interactive design elements that enhance user experience. The website is looking good, adding cursor-animation makes it more beautiful, I propose adding a cursor-following animation to create dynamic interactions where design elements move along with the mouse cursor, providing a more engaging and visually appealing experience.
I’d like to work on adding this feature. Please assign this issue to me under hacktoberfest-accepted, gssoc-ext, level

Could you show me a demo /video of what do you want to do?

https://github.com/user-attachments/assets/011540af-ee50-4bcf-939e-fbb7b0892120
like this,

cursor6.mp4
@Yash-Ainapure like this,

Sorry the animations will affect the website performance , we want to create a minimilistic , performance  oriented webapp


should the binaries be placed within "build" directory?

Currently, the binaries are placed outside of the build directory, what is - in my opinion - counterintuitive (i.e., not the default bahaviouor CMake used in most (all) projects I've tried). It is also not possible to generate several builds not overwriting the binaries, e.g.:

build-O3
build-Ofast
build-debug
...

If a user wants to put the binaries in "vinecopulib/bin" this would still be possible by setting CMAKE_PREFIX_PATH and doing "make install"
What about placing the binaries within "build"?

Fine by me. The current path is a relic from the CMake skeleton project I used.

Yeah. I'd prefer having them in /build.

Done!


text shows up as code

On: https://docs.dapr.io/getting-started/configure-state-pubsub/
I see this:

I'm pretty sure the "Self-hosted slim mode" section should be normal text, not a code snippet. I tried to see why the md turned it into code but I couldn't figure it out, otherwise I would have submitted a PR.  I'm wondering if it's the presence of the back-tick text in there.

@msfussell @duglin it looks like this was resolved at some point and not linked to a PR... ok to close? https://docs.dapr.io/getting-started/tutorials/configure-state-pubsub/#step-3-apply-the-configuration

yup I'll close it. I assume that the original link https://docs.dapr.io/getting-started/configure-state-pubsub/ is supposed to return a 404 now, right?


[REPO] move and clarify enumerated endpoints to Lib3hProtocol (formerly JsonProtocol)

As a lib3h client, I can know the enumerated endpoints in the Lib3hProtocol (formerly JsonProtocol) so that I have knowledge of the protocol.

[x] Discuss path forward with HC Core team
[x] We have a method of knowing the alterations that have been made to JsonProtocol
[x] We need to maintain the n3h connection
[x] JsonProtocol is imported from core && all changes are tracked

Scoping:

Does not required completion CheckHealth, AdvancedQuery

The principle artifact of this work is here: https://hackmd.io/ZZ9wJFPHQxqIz4lOCkocTQ?view


Time correction for weather plugin

go easy on me for this one :sob:

Need to PR on the dev branch


Uncaught Type Error when opening the first time

Hey Tyler,
i found a bug. Opening the site the first time i cant click on any buttons, following error appears in the Dev-Tools (chrome 54 only):
Uncaught TypeError: Cannot read property 'replace' of undefined (main.min.js:8)
Dev-Tool finds a uncaught Syntax Error: Unexpected token on line 8, Column 106208. Coudn't find out what's the problem though.
Sometimes a Reload is enough, sometimes i need to Cache-Reload (STRG+F5).

Fixed, the issue was that I had the script tag at the top of the file. Because require.js is async, the page would load sometimes. Its a big performance no-no though, so moving the script tag to the bottom resolved it.


Allow for customizing CI tests based on environment and version

This is particularly important for infra roles. It may not be possible to create one test CR for a role that could be expected to pass on all of K8s upstream, OCP 3.0, and OCP 4.0. If the CI system is going to automate testing of multiple environment types, then we need the ability to create test CRs that are applicable to the specifics of the environment.

Adding clarity as discussed on our call..
This mostly affects infra roles, as often you cannot use the exact same methods/tools/sources to install the infra on k8s, OCP 3, and OCP4. This means that I cannot easily create a single test CR file that will pass on all CI systems. What I propose is to add logic to the CI script structure that allows for varying the test scripts and/or the CR files based on the configuration of the test system.

This can be done today easily as Jenkins makes a list of variables available to the tests as environment variables [1]. We can then access them and manipulate in the test scripts as needed. For an example, we can look at PR #94 which was doing something similar with the variable NODE_NAME. So in this case, we can use the variable JOB_NAME, as JOB_NAME contains either minikube or minishift which will help us understand the environment. I'll add this to documentation with the job_name description.
[1] http://porthos.perf.lab.eng.rdu2.redhat.com:8080/env-vars.html/
[2] https://github.com/cloud-bulldozer/ripsaw/pull/94/files

Closing this now, as this can be accomplished through the above mentioned manner.


[build] Speed up clang_format

This reduces clang-format duration to under 10s on my 128 core machine. Previously I stopped the process at 10 minutes. Major changes:
Eliminates 18,000 files
find ... \
    -and -not -path '*/cmake/build/*' \
    -and -not -path '*/huffman_geometries/*' \

Also, this now runs $CPU_COUNT number of parallel clang-format processes with a roughly equal number of files. Previously, this script was formatting one file at a time in separate processes (xargs -n 1).

can we keep huffman_geometries? (or at least have a recipe to fix them next time I change that code generator)

can we keep huffman_geometries? (or at least have a recipe to fix them next time I change that code generator)

@ctiller I added them back in. clang-format struggles with them, those 233 files double the run time on my system.


Uncaught ReferenceError: stopServer is not defined

[Enter steps to reproduce:]

...
...

Atom: 1.30.0 x64
Electron: 2.0.5
OS: Microsoft Windows 10 Home
Thrown From: atom-live-server-plus package 2.4.1
Stack Trace
Uncaught ReferenceError: stopServer is not defined
At C:\Users\InternetUser\.atom\packages\atom-live-server-plus\lib\atom-live-server.js:139

ReferenceError: stopServer is not defined
    at Object.startServer (/packages/atom-live-server-plus/lib/atom-live-server.js:139:7)
    at HTMLElement.atomLiveServerStartServer (/packages/atom-live-server-plus/lib/atom-live-server.js:66:50)
    at CommandRegistry.handleCommandEvent (~/AppData/Local/atom/app-1.30.0/resources/app/src/command-registry.js:384:49)
    at CommandRegistry.dispatch (~/AppData/Local/atom/app-1.30.0/resources/app/src/command-registry.js:273:23)
    at AtomEnvironment.dispatchApplicationMenuCommand (~/AppData/Local/atom/app-1.30.0/resources/app/src/atom-environment.js:1351:25)
    at EventEmitter.outerCallback (~/AppData/Local/atom/app-1.30.0/resources/app/src/application-delegate.js:339:53)
    at emitThree (events.js:136:13)
    at EventEmitter.emit (events.js:217:7)

Commands
     -0:37.5.0 atom-live-server:startServer (atom-workspace.workspace.scrollbars-visible-always.theme-one-dark-syntax.theme-one-dark-ui)

Non-Core Packages
atom-live-server 2.3.0
atom-live-server-plus 2.4.1
livestyle-atom 0.2.10
php-server 0.8.0

@akibrahim2001 Try uninstalling atom-live-server. atom-live-server-plus is supposed to replace atom-live-server, not supplement it. Also, could I get some steps to reproduce the exception? Did you just call :stopServer?

Try updating your package to v3.0.0. Closing this issue as I was unable to reproduce and was not responded to with more info.


bug: docs instructions do not mention critical step of "mike set-default"

Describe the bug
I tried make serve-docs.  It claimed to succeed, but when I directed my browser to http://localhost:8000/ it showed me a 404 response saying the following things in the web page.

Error response
Error code: 404
Message: File not found. Did you forget to run mike set-default? Alternately, you can navigate to <IP_ADDRESS>.in-addr.arpa:8000/[some-version] to see your docs.
Error code explanation: 404 - /.

Also, the shell running mike logged this:

<IP_ADDRESS> - - [21/Jul/2023 15:49:36] code 404, message File not found. Did you forget to run mike set-default? Alternately, you can navigate to <IP_ADDRESS>.in-addr.arpa:8000/[some-version] to see your docs

I tried guessing URLs that might work, such as http://localhost:8000/v0.4.0 , http://localhost:8000/release-0.4, and http://localhost:8000/main/; all rewarded me with a 404.
Steps To Reproduce
Do the above, in a context where the default has not been set.
BTW, I do not know where the setting of the default gets stashed.
Expected Behavior
The documented steps are sufficient.
Additional Context
No response

I can't reproduce this.  I will add it to the instruction set anyway - doesn't hurt to set it locally.
I do not know where 'mike' keeps this setting.  It is not in https://github.com/kubestellar/kubestellar/blob/gh-pages/versions.json

updated doc management doc.
https://docs.kubestellar.io/main/Contribution guidelines/operations/document-management/

which branch are you in when you run make serve-docs?
this is bizarre behavior.  You might look to reset your 'mike' environment - check the https://github.com/jimporter/mike site for some help.  If not, I would look for an issue that resembles your experience.
this may hold some hints - https://github.com/jimporter/mike/issues/106

This was with a fairly recent edition of main.


License missing

There is no copyright information in the git repository, neither license headers in the go files nor a separate license file. Please add license headers and a LICENSE file. Missing information means that no permission are granted.

@bdrung, completely agree with you. I will add MIT license to this package during a week. Thanks for mentioning this!

Any updates on this?

Hi @bdrung! Sorry for long delay (I have too much work to do) :(
I promise, I'll fix it before the end of this week. I will inform you additionally.

Any updates on this?

Hi @bdrung. I have implemented the requested update.


Use macros to precompile regexes

BugzID: 48704

Closing pull request, applying for job in a coffee shop.


Nuxt(Bun): Unable to start Nuxt with transformerDirectives

UnoCSS version
0.63.2
Describe the bug
Usage of the directive transformer results in  ERROR  Cannot start nuxt:  ResolveMessage {} that has no verbose information about issue, but stops Nuxt. Usage of transformer like VariantGroup has no such issue. Issue only appears while using Bun with their engine e.g. bun run --bun dev.
Reproduction
Initialize Nuxt repo and add @unocss/nuxt module, after that create a UnoCSS config that includes transformerDirectives() in transformers. Try to run it with bun run --bun dev.
https://codesandbox.io/p/devbox/wonderful-morning-c2s6dz
System Info
Firefox, Nuxt 3.13.2 (v4 features enabled), Windows, Bun 1.1.30
Validations

[X] Read the Contributing Guidelines.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Bun issues should be filed here: https://github.com/oven-sh/bun/issues as we can't really fix them here (except telling you not to use the runtime for now)

Probably it has to do something with this issue oven-sh/bun#13338


[simplebar-vue] fix: move vue-demi to dependencies

First I would like to apologise for breaking the 1.7.0 build :/
I've trusted unit testing and forgot to install it externally  to ensure it works in real life, or should have asked you to release it as beta.
https://github.com/Grsmto/simplebar/blob/3c5cb8d4f9848f80e64b0196c438bb5b2243c68f/packages/simplebar-vue/utils.js#L1-L6

vue-demi is not only used for testing but also to dynamically create the lifecyle names map for cross-compatiblity with vue 2 and 3
updated vue-demi to latest version, I was going crazy to make the tests work and thought that vue-demi had something to do with it but I has not.

@renatodeleao I just published a patch, if you can give it a try!

@Grsmto tried, from my tests it works on vue3 but not on vue2 even prefixing the build script with npm run use-vue:2.7 does not change the outcome.
It seems that I underestimated the task: my past experience with cross-compatible components I used solely render functions and didn't involve compiling SFC and that's where the problem is: the compiled output of SFC is a render function tailored for vue3 that does not work in vue2. There's scattered information around the web on how to do it right and these issues on vue-demi have listed the most workarounds but none is considered a de facto solution.

https://github.com/vueuse/vue-demi/pull/154
https://github.com/vueuse/vue-demi/issues/153

Since I've promised vue2 and vue3 support and now have to deliver, what I can do in the short-term to mitigate the failed release is basically re-writing the <template> as a plain render function with some conditionals for handling the differences between vue 2 and 3 signatures. I already managed to make it work for vue2.7 and vue3 https://github.com/renatodeleao/simplebar/commit/33146cab04df4166e502d3dd753a729128123437 , but I'm not sure If I'm going to make it for vue 2.6 which if becomes true tomorrow, means a breaking change version.
Once again, sry for the trouble, I had the best intentions when I suggested this feature didn't expect so many issues down the road!

@renatodeleao indeed I have tested only the vue 3 version but the vue 2 is not working. I will revert to the previous vue 2 support for now to avoid too many side effects from people upgrading to latest version.

@Grsmto You did well in reverting, thanks and sry!
The good news is that I have a — hopefully 🤞 — working version that is fully cross-compatible. Will push it sometime today!

Great stuff. Let's not do the same mistake and do a pre-release to test it this time! 😅


fix(search): increase styling and improve preview width

This is to address some inconsistency in the preview panel.
https://github.com/jackyzha0/quartz/assets/29749331/2b7940c9-819b-4c8f-af18-73b44b6c9c0b
also I increased the width of search for all devices that is not laptop.

is your css up to date? it should margin 0 auto the content

I'm going to close this, imo like the current width :)

Ah i have custom scss thats why.


feat: improve array formatting

It would be nice to format arrays enabling multiple values per line.
Current:
       #[test]
        fn test_u256_to_be_bytes_full() {
            let input: u256 = 0xf432156278901234deadbeefcafebabe0123456789abcdef0fedcba987654321;
            let res: Span<u8> = input.to_be_bytes();

            assert_eq!(
                res,
                [
                    0xf4,
                    0x32,
                    0x15,
                    0x62,
                    0x78,
                    0x90,
                    0x12,
                    0x34,
                    0xde,
                    0xad,
                    0xbe,
                    0xef,
                    0xca,
                    0xfe,
                    0xba,
                    0xbe,
                    0x01,
                    0x23,
                    0x45,
                    0x67,
                    0x89,
                    0xab,
                    0xcd,
                    0xef,
                    0x0f,
                    0xed,
                    0xcb,
                    0xa9,
                    0x87,
                    0x65,
                    0x43,
                    0x21
                ].span()
            );
        }

Desired:
        #[test]
        fn test_u256_to_be_bytes_full() {
            let input: u256 = 0xf432156278901234deadbeefcafebabe0123456789abcdef0fedcba987654321;
            let res: Span<u8> = input.to_be_bytes();

            assert_eq!(res, [
                0xf4, 0x32, 0x15, 0x62, 0x78, 0x90, 0x12, 0x34,
                0xde, 0xad, 0xbe, 0xef, 0xca, 0xfe, 0xba, 0xbe,
                0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef,
                0x0f, 0xed, 0xcb, 0xa9, 0x87, 0x65, 0x43, 0x21
            ].span());
        }

+1

I feel like your desired output as it is in not well defined, as each row in the array does not span the entire line. If we'll break each line once it reached the full length of the we'll have something like:
#[test]
fn test_u256_to_be_bytes_full() {
    let input: u256 = 0xf432156278901234deadbeefcafebabe0123456789abcdef0fedcba987654321;
    let res: Span<u8> = input.to_be_bytes();

    assert_eq!(
        res,
        [
            0xf4, 0x32, 0x15, 0x62, 0x78, 0x90, 0x12, 0x34, 0xde, 0xad, 0xbe, 0xef, 0xca, 0xfe,
            0xba, 0xbe, 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef, 0x0f, 0xed, 0xcb, 0xa9,
            0x87, 0x65, 0x43, 0x21
        ]
        .span()
    );
}

Which is probably what we'll end up doing.
Unrelated to this change, if you still wish to organise the array in a matrix like shape, you can make the formatter skip this statement using #[cairofmt::skip], however this means that the whole statement will have to be manually formatted.
#[test]
fn test_u256_to_be_bytes_full() {
    let input: u256 = 0xf432156278901234deadbeefcafebabe0123456789abcdef0fedcba987654321;
    let res: Span<u8> = input.to_be_bytes();

    #[cairofmt::skip]
    assert_eq!(
        res,
        [
            0xf4, 0x32, 0x15, 0x62, 0x78, 0x90, 0x12, 0x34,
            0xde, 0xad, 0xbe, 0xef, 0xca, 0xfe, 0xba, 0xbe,
            0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef,
            0x0f, 0xed, 0xcb, 0xa9, 0x87, 0x65, 0x43, 0x21
        ]
        .span()
    );
}


Adding blank condition and not_resources properties to avoid inaccurate drift

This PR is intended to address Issue #35 (and #37, which is likely a duplicate). The result has been tested successfully no longer indicating drift on subsequent runs.
No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

Hi, we are not accepting pull requests at this time. Thanks for notifying us of this issue.
We've included the workaround for Terraform issue https://github.com/hashicorp/terraform-provider-aws/issues/22595 in release v1.1.2


Add deep search in Request body

#322

PR will be updated.

Workability and performance have been tested with the attached OpenAPI definition file (size: ~5MB, number of methods: 900+)
openapi_v3.zip

Thank you for your PR !!!


Can't use an alias in Themes

I wanted to keep my theme files in Dropbox to easily back them up, and then place an alias in the Themes folder.
This then gives me the error
The file “Info.plist” couldn’t be opened

Have you tried creating a symbolic link for Themes folder instead of Finder alias?


Fix debugging handling

Looks good.
Some nit-picking about the messages : could you change it to say something affirmative, ie simply
"Devtools URL: " + url / port

done

updated the run.js printed log


No RPi5 config file for openocd?

I'm doing development work on a Pico using a RPi5 as the development machine. I'm also using the "Debug Probe" thing-y that you sell. Things are moving along OK, but I'm not doing anything very challenging at the moment.
However there does not appear to be a config file that applies to the RPi5 in the openocd folder. I draw this conclusion from the fact that each time I invoke openocd without the -c "adapter speed 5000" option in the command line, I get a warning in the output:
$ sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "program ina260_trial.elf verify reset exit"
Open On-Chip Debugger 0.12.0-g4d87f6d (2024-01-22-05:04)
...
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try to run the adapter at the low speed (100 kHz)
Warn : To remove this warnings and achieve reasonable communication speed with the target, set "adapter speed" or "jtag_rclk" in the init scripts.
...

Note the Warning suggests setting adapter speed "in the init scripts". I don't know what the heck they mean by "init scripts", but I could find nothing appropriate in any script in /pico/openocd for setting adapter speed. So, I tried grep-ing in pico/openocd:
$ grep -rni "adapter speed" | less

This produced a rather extensive list, mostly in the pico/openocd/tcl folder. After some searching, I found a few candidates:
tcl/board/pico-debug.cfg
tcl/interface/raspberrypi-swd.cfg
tcl/interface/raspberrypi-native.cfg
tcl/interface/raspberrypi-native.cfg
tcl/target/bcm2835.cfg
testing/test-bcm2835gpio-deprecated-commands.cfg
tcl/target/bcm2711.cfg

However, after inspecting each of these files, it seems that none of them are appropriate for the RPi5 and appear to be a logical place for setting adapter speed. Also, there is no cfg file for bcm2712.
If I've missed something, please let me know. If I haven't, I would surely appreciate a configuration file that sets adapter speed, and otherwise covers the RPi5 in openocd.

see #1611

@kilograham
Hey Graham - yeah, I'm aware of #1611 as I submitted that one also. However, #1611 was submitted for a different issue - an issue I've (at least temporarily) overcome by using the "Debug Probe". ... or am I missing something obvious?

I use a debug probe with pi5 every day. I'll check if I get this warning

I seem to have always been running openocd like this which avoids the issue...
openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000"

The realisable swclk depends on the hardware in question. It's explicitly a user choice to select a clock compatible with their hardware. 5MHz is a recommendation, but should not be a default.

Is 100 kHz a sensible default? That's what your get if you don't set it. I've heard reports of pico debugging being slow - I bet this is the reason

Here would be more appropriate? https://github.com/openocd-org/openocd

Our own openocd repo is still what https://github.com/raspberrypi/pico-setup/blob/master/pico_setup.sh#L135 points to, so does that need updating too? :man_shrugging:  (I'm still not 100% familiar with how SWD / OpenOCD / PicoProbe / GDB and their various upstream / downstream forks all connect together)

so does that need updating too?

I would guess, "yes"

I'm not averse to wrapping interface/cmsis-dap.cfg in interface/debugprobe.cfg and setting the speed there - it's a reasonable assumption that the JST connector + ribbon will be in use, which will easily do 5MHz.

The realisable swclk depends on the hardware in question. It's explicitly a user choice to select a clock compatible with their hardware. 5MHz is a recommendation, but should not be a default.

@P33M :
I mentioned in the first sentence of this issue that I was using the Debug Probe. I assume that settles the question re your comment re the "hardware in question"??
And if one were using a couple of GPIO from the RPi (instead of the Probe), could they not match the speed of the Debug Probe?

I'm going to "muddy the water" a bit with some information I discovered earlier today. If someone thinks this needs go in a separate issue, pls let me know & I'll move it.
In addition to the missing adapter speed setting, it has also bothered me that I'm required to use sudo to run openocd. This gets a bit complex, so I've separated into two (2) threads to hopefully make it less so.
1. To which config file should the adapter speed 5000 be added?
I assumed that all of the required files were installed under the /home/pi/pico folder. The command I use to run openocd is as follows:
$ sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "program ina260_trial.elf verify reset exit"

I assumed that the two files called out in this command were (somewhere) under /home/pi/pico.   I further assumed that rp2040.cfg was the most likely one to add the adapter speed.  I used locate to find rp2040.cfg. Turns out there are two copies of that file (at least on my system):
$ locate rp2040.cfg
/home/pi/pico/openocd/tcl/target/rp2040.cfg
/usr/local/share/openocd/scripts/target/rp2040.cfg

And so I edited the file /home/pi/pico/openocd/tcl/target/rp2040.cfg to add the single line: adapter speed 5000. When I tried running openocd again, it still defaulted to 100 kHz. And so then I tried the same edit in /usr/local/share/openocd/scripts/target/rp2040.cfg. It worked... this "did the trick".
I feel like I've made progress, but wonder the point of putting two copies of rp2040.cfg on the system, and then using the one in /usr/local/share which is owned by root?
2. Why is sudo required to run openocd?
As all the files in /usr/local/share/openocd are owned by root I thought this might have something to do with it... perhaps openocd wrote something to rp2040??? Anyway, I thought changing it was worth a try:
$ sudo chown pi:pi /usr/local/share/openocd/scripts/target/rp2040.cfg

But this made no difference. There are also duplicates of the cmsis-dap.cfg file used in the openocd command, and so I chownd that file also:
$ sudo chown pi:pi /usr/local/share/openocd/scripts/interface/cmsis-dap.cfg

openocd still errors out without sudo:
$ openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "program ina260_trial.elf verify reset exit"
Open On-Chip Debugger 0.12.0-g4d87f6d (2024-01-22-05:04)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Error: unable to find a matching CMSIS-DAP device
** OpenOCD init failed **
shutdown command invoked

At least the error message seems to pin the fault on CMSIS-DAP.
Any ideas what's going on here, and how to fix it so that sudo is not required?  Or is that even possible? I think I've run out of steam at present because I don't really understand what openocd does. Hoping someone who's more knowledgeable has a solution.

I feel like I've made progress, but wonder the point of putting two copies of rp2040.cfg on the system, and then using the one in /usr/local/share which is owned by root?

I assume you've used the pico_setup.sh script? The /home/pi/pico/openocd/tcl/target/rp2040.cfg file is created by the "git clone", and the /usr/local/share/openocd/scripts/target/rp2040.cfg file is created by the "make install". (This is the way that things are typically done on Linux when installing software from sourcecode, and isn't specific to openocd). If you're really concerned about there being "two copies of the file", you could delete the entire /home/pi/pico/openocd folder after the pico_setup.sh script has finished, if you want.

Any ideas what's going on here, and how to fix it so that sudo is not required?

I suspect that openocd needs root privileges to be able to talk to the hardware (i.e. the hardware that interface/cmsis-dap.cfg is specifying)? That's probably fixable with udev (e.g. something similar to https://github.com/raspberrypi/picotool/pull/50 ) but that's not something that I'm familiar with myself.

Any  ideas what's going on here, and how to fix it so that sudo is not required?

I suspect that openocd needs root privileges to be able to talk to the hardware (i.e. the hardware that interface/cmsisdap.cfg is specifying)? That's probably fixable with udev (e.g. something similar to aspberrypi/picotool#50 ) but that's not something that I'm familiar with myself.

Yes, it'll need root access to access the hardware it's talking to, and also yes, it should be fixable with udev but I've never bothered looking into what would be necessary to do that.

Regarding running openocd. Are you in the plugdev group? Are you in the dialout group? I don't seem to need to run sudo and I don't appear to have a udev rule.

I feel like I've made progress, but wonder the point of putting two copies of rp2040.cfg on the system, and then using the one in /usr/local/share which is owned by root?

I assume you've used the pico_setup.sh script? The /home/pi/pico/openocd/tcl/target/rp2040.cfg file is created by the "git clone", and the /usr/local/share/openocd/scripts/target/rp2040.cfg file is created by the "make install". (This is the way that things are typically done on Linux when installing software from sourcecode, and isn't specific to openocd). If you're really concerned about there being "two copies of the file", you could delete the entire /home/pi/pico/openocd folder after the pico_setup.sh script has finished, if you want.

You assume correctly; i.e. "Yes, I used pico_setup.sh to "install" the SDK.

Any ideas what's going on here, and how to fix it so that sudo is not required?

I suspect that openocd needs root privileges to be able to talk to the hardware (i.e. the hardware that interface/cmsis-dap.cfg is specifying)? That's probably fixable with udev (e.g. something similar to raspberrypi/picotool#50 ) but that's not something that I'm familiar with myself.

Someone ("breaker") has formulated a solution for the sudo issue - it can be found in this forum post...  (maybe you should hire this guy?).
My solution was a cop-out - I simply created an alias for the full command - including sudo and "adapter speed 5000".
And BTW:
I can understand why the sudo issue is complicated, but I fail to understand why the "adapter speed 5000" hasn't found an answer here (FWIW, I tried it in rpi2040.cfg without effect). I would think that among all of the domain-specific knowledge here, surely someone would know where to put this setting so that the SWD can upload the ELF file at a reasonable rate. One might get the impression that this is not the "A-team". So yes - by all means - let's close the issue.

Charming

Charming

Hope you find the edited version a bit less offensive. But really Mr Harper - do you honestly feel this is the way things get fixed and improved?

Perhaps you can suggest to this b team member what fixes to this problem can be put the pico-sdk?

Perhaps you could actually read the comments? Like this one from two weeks ago? The relevant part being:

And so then I tried the same edit in /usr/local/share/openocd/scripts/target/rp2040.cfg. It worked... this "did the trick". I feel like I've made progress, but wonder the point of putting two copies of rp2040.cfg on the system, and then using the one in /usr/local/share which is owned by root?

... and crickets.

but wonder the point of putting two copies of rp2040.cfg on the system

I already answered that:
The /home/pi/pico/openocd/tcl/target/rp2040.cfg file is created by the "git clone", and the /usr/local/share/openocd/scripts/target/rp2040.cfg file is created by the "make install".

... and crickets.

:cricket: :cricket_game:

@lurch
Ah - so that answers the question re why there are two files, but does it also answer the question "Why is the adapter speed config item is ignored in the file that's at /home/pi/pico/openocd/tcl/target/rp2040.cfg?"

Because when you run openocd at the command-line, that'll use the binary that exists in your $PATH (i.e. the one in /usr/local/bin/ rather than the one in /home/pi/pico/openocd/src/) and as you might expect, the systemwide-installed version of /usr/local/bin/openocd will look for the corresponding systemwide-installed config files in /usr/local/share/openocd/scripts/ .
I guess you also missed the part where I said:
If you're really concerned about there being "two copies of the file", you could delete the entire /home/pi/pico/openocd folder after the pico_setup.sh script has finished, if you want.

@lurch
Even when the command line specifies: sudo openocd -d0 ... -f target/rp2040.cfg ...? What did it do with thetarget` part?

What did it do with the target part?

cleverca22 already answered that here: https://github.com/raspberrypi/pico-sdk/issues/1611#issuecomment-1923467090

And I'm not really concerned about there being "two copies of the file" - I think you know that.

Sorry, perhaps I should have written "confused" rather than "concerned".

The command I used comes from the "Getting Started" Guide:

If you have problems with the PDF documentation, the correct place for reporting that is at https://github.com/raspberrypi/pico-feedback not the pico-sdk repo.

What did it do with the target part?

cleverca22 already answered that here: #1611 (comment)

And I'm not really concerned about there being "two copies of the file" - I think you know that.

Sorry, perhaps I should have written "confused" rather than "concerned".

The command I used comes from the "Getting Started" Guide:

If you have problems with the PDF documentation, the correct place for reporting that is at https://github.com/raspberrypi/pico-feedback not the pico-sdk repo.

Oh, how very smart...  But how do we know the problem is with the documentation? It could be - as has been shown here - that the location of the problem is very hard to pin down!


Add switch to not display success messages

Gitlab has its own jira integration that does a good job of displaying
all mentioned jira issues, in this case the message is uneccesary
however the messages on no jira being mentioned is still of value.

I just wanted to say thanks for the PR! 👏

I did not add a test case as this is the most ruby I have every really written that wasn't just config and that is a whole rabbit hole I sadly don't have time for at present sorry.


[🌟] Expose image compression method

Would it be possible to expose method which you are using for image compression (when quality option is provided)?
I have this app where user can upload all sort of documents. I'm using react-native-image-picker to allow him to capture or pick photo and react-native-document-picker to allow him to pick any kind of document. So the user can pick photos also through document-picker. Now if user picks a photo through document-pricker I would also like to compress it before upload. I can add another dependency just for this but is there a chance you could expose method of a image-picker so we can also manually use it for situations like these?

What u mean by image compression? Already there is an option to provide image quality which will compress the image.

Exposing it as a separate function is not possible right now.


Response of Firmware collection -APIs doesnt match between cache and live

The response of cache "firmware-1-0:firmware-component-list" and live is different "firmware-1-0:.
curl -X GET "http://xx:xx/core-model-1-4:network-control-domain=live/control-construct=513250005/firmware-1-0:firmware-collection/firmware-component-list=HUAWEI-PKG-MAIN" -H "accept: application/json" -H "user: User Name" -H "originator: Resolver" -H "x-correlator: 550e8400-e29b-11d4-a716-446655440000" -H "trace-indicator: 1.3.1" -H "customer-journey: Unknown value" -H "operation-key: Operation key not yet provided."

{
    "firmware-1-0:firmware-component-list": [

curl -X GET "http://xx:xx/core-model-1-4:network-control-domain=cache/control-construct=513250005/firmware-1-0:firmware-collection/firmware-component-list=HUAWEI-PKG-MAIN" -H "accept: application/json" -H "user: User Name" -H "originator: Resolver" -H "x-correlator: 550e8400-e29b-11d4-a716-446655440000" -H "trace-indicator: 1.3.1" -H "customer-journey: Unknown value" -H "operation-key: Operation key not yet provided."

{
  "firmware-1-0:HUAWEI-PKG-MAIN": [
    {
     ```

Tested with  latest tag [Test_v1.1.2]
Observing same response for firmware component list across cache and live . Hence closing the issue,
{
"firmware-1-0:firmware-component-list": [
{
curl -X GET "http://xxx:xxx/core-model-1-4:network-control-domain=cache/control-construct=513250004/firmware-1-0:firmware-collection/firmware-component-list=xxx" -H "accept: application/json" -H "user: User Name" -H "originator: Resolver" -H "x-correlator: 550e8400-e29b-11d4-a716-446655440000" -H "trace-indicator: 1.3.1" -H "customer-journey: Unknown value" -H "operation-key: Operation key not yet provided."

curl -X GET "http://<IP_ADDRESS>:3008/core-model-1-4:network-control-domain=live/control-construct=513250004/firmware-1-0:firmware-collection/firmware-component-list=HUAWEI-PKG-MAIN" -H "accept: application/json" -H "user: User Name" -H "originator: Resolver" -H "x-correlator: 550e8400-e29b-11d4-a716-446655440000" -H "trace-indicator: 1.3.1" -H "customer-journey: Unknown value" -H "operation-key: Operation key not yet provided."


Allow beta versions of Go

Very useful for testing Generics in v1.18beta1

Thanks for opening @stellirin!
@Chuxel Does this sound reasonable to you? I was able to verify it works (added PR's version of go-debian.sh to my .devcontainer/library-scripts, signified beta in Dockerfile; running go version output go version go1.18beta2 linux/amd64).

@bamurtaugh Yeah I think so.  This updates a utility script we tend to reuse in a number of different spots, so there's a slight risk of it getting undone by accident. We could instead add a "suffix" param to that particular function and use it from the go script. Then the go script would do what is here if "beta" is the value.
Thoughts @joshspicer? I know with features you're thinking about moving more towards utility functions.
e.g. this would add the suffix
# Figure out correct version of a three part version number is not passed
find_version_from_git_tags() {
    local variable_name=$1
    local requested_version=${!variable_name}
    if [ "${requested_version}" = "none" ]; then return; fi
    local repository=$2
    # Normally a "v" is used before the version number, but support alternate cases
    local prefix=${3:-"tags/v"}
    # Some repositories use "_" instead of "." for version number part separation, support that
    local separator=${4:-"."}
    # Some tools release versions that omit the last digit (e.g. go)
    local last_part_optional=${5:-"false"}
    # Some repositories may have tags that include a suffix (e.g. actions/node-versions)
    local version_suffix_regex=$6

    local escaped_separator=${separator//./\\.}
    local break_fix_digit_regex
    if [ "${last_part_optional}" = "true" ]; then
        break_fix_digit_regex="(${escaped_separator}[0-9]+)?"
    else
        break_fix_digit_regex="${escaped_separator}[0-9]+"
    fi
    local version_regex="[0-9]+${escaped_separator}[0-9]+${break_fix_digit_regex}${version_suffix_regex//./\\.}"
    # If we're passed a matching version number, just return it, otherwise look for a version
    if ! echo "${requested_version}" | grep -E "^${versionMatchRegex}$" > /dev/null 2>&1; then
        local version_list="$(git ls-remote --tags ${repository} | grep -oP "${prefix}\\K${version_regex}$" | tr -d ' ' | tr "${separator}" "." | sort -rV)"
        if [ "${requested_version}" = "latest" ] || [ "${requested_version}" = "current" ] || [ "${requested_version}" = "lts" ]; then
            declare -g ${variable_name}="$(echo "${version_list}" | head -n 1)"
        else
            set +e
            declare -g ${variable_name}="$(echo "${version_list}" | grep -E -m 1 "^${requested_version//./\\.}([\\.\\s]|${version_suffix_regex//./\\.}|$)")"
            set -e
        fi
        if [ -z "${!variable_name}" ] || ! echo "${version_list}" | grep "^${!variable_name//./\\.}$" > /dev/null 2>&1; then
            echo -e "Invalid ${variable_name} value: ${requested_version}\nValid values:\n${version_list}" >&2
            exit 1
        fi
    fi
    echo "Adjusted ${variable_name}=${!variable_name}"
}

Yea, I think making it more generic, to be used in other places, will be very useful in the future!


[BUG]

my antivirus detected a trojan after installing the launcher

you can literally see the entire hydra code here, and no one report any trojan in hydra code, so it's a false positive.


race-condition: ssh-login possible before system boot has completed

I'm running boot2docker as a VirtualBox VM to be used as a gitlab-runner (for securely building docker images, without built-in privilege escalation...).
For this to work, I need to install some additional files (bash, a local gitlab-runner) inside the VM.
Currently the only way (I know of) to install additional packages, is by running tce-load in the /var/lib/boot2docker/bootsync.sh script.
Unfortunately, this gives me a race-condition, as the GitLab-CI keeps trying to login via ssh while my VM boots - and as soon as it succeeds it wants to execute /bin/bash, which might not be there yet (depending on whether the /bootsync.sh has already been executed or not).
It would be great to be able to run a user-provided script before anybody (locally or remotely) is allowed to log into the system, possibly before any daemon is started.
This might also allow me to do something about #1330.

Your only option is to modify /etc/init.d/tc-config directly and copy it into a new build.
The boot system is not upstart or systemd.....
FROM boot2docker/boot2docker:latest

ADD files/etc/init.d/tc-config $ROOTFS/etc/init.d/

RUN /tmp/make_iso.sh

CMD ["cat", "boot2docker.iso"]

files/etc/init.d/tc-config is your modified version.

While I agree this sounds less than ideal (and likely something we should
try to fix if we can), I'd really recommend that you should probably be
looking at something like Debian, Ubuntu, Fedora, etc instead of
boot2docker for the project you're working on -- boot2docker is really only
still maintained to ensure that "docker-machine" users still have their
default environment available.

hmm, well fair enough.
(although, my need is really for a minimal VM that allows me to run docker containers and which boots fast...this awfully sounds like boot2docker and not at all like Debian/Fedora/...)

If you're willing to use systemd, my experience with Debian has been
that it boots really fast.  If you're wanting really minimal,
something based on Alpine Linux might be easier to use/maintain long
term.
If you just want something that has Docker out of the box, RancherOS
and CoreOS are both decent options (RancherOS having the benefit of
also being very lightweight).

Can you try this again on the new 18.09 ISO to verify that it's still an issue with the latest release? (which includes a pretty major rewrite of many of the boot processes / ISO creation)

Closing due to lack of reproducer.  If this is something we can reliably reproduce, it'd be a lot easier to work on a fix. :smile:


CMake and ext package upgrades

A variety of updates to ext package versions and CMake find modules:

Upgrade to CMake 3.12
Favor third-party CMake configs for finding packages
Adopt standard CMake <package>_ROOT variables for overriding package locations
Upgrade Half version to match VFX Reference Platform CY2020
Upgrade other packages to take advantage of upstream CMake upgrades and configs
Match find module variable namespace to target name, and target names to third-party CMake configs
Move ext find package calls to project root to guarantee imported targets are global

Signed-off-by: Michael Dolan<EMAIL_ADDRESS>

@michdolan Thanks for modernizing & improving the external library integration.
But, could you explain the rational of the first two bullets (i.e. Upgrade to CMake 3.12 &
Favor third-party CMake configs) ?

As for the rationale for preferring third-party CMake configs:
Most of our upstream dependencies provide CMake configs with their installs (in the new versions I proposed), which allows us to greatly reduce dependence on our CMake find modules for knowing where to find packages or how to check versions. Eventually, we can rely on the configs alone, and have no custom logic. The only thing stopping us from doing that right now is the handling of OCIO_INSTALL_EXT_PACKAGES, which complicates things a bit. We should also be shipping our own CMake config with OCIO for other projects to use for finding OCIO. We could eventually pull our package install logic out of the find modules, and rely on CMake configs when no install is needed.

This all looks good from my point of view. For a while now, I've had my projects using CMake 3.12 as a minimum for the same reasons, I export cmake config files, and am slowly retiring my own FindFoo.cmake modules as my dependencies reliably have their own exported config files.
I still have a couple places where I do automatic downloads, but enough people/sites have trouble with that to cause me to slowly remove them one by one, making my builds assume that all dependencies are present, but supplying scripts that download/build/install any of the dependencies that are not extremely common in all the distros. So I've come to think the best policy is to leave it up to the users to install the dependencies, but I give them tools to at least make it a single easy command when they need to do it.

This all looks good from my point of view. For a while now, I've had my projects using CMake 3.12 as a minimum for the same reasons, I export cmake config files, and am slowly retiring my own FindFoo.cmake modules as my dependencies reliably have their own exported config files.
I still have a couple places where I do automatic downloads, but enough people/sites have trouble with that to cause me to slowly remove them one by one, making my builds assume that all dependencies are present, but supplying scripts that download/build/install any of the dependencies that are not extremely common in all the distros. So I've come to think the best policy is to leave it up to the users to install the dependencies, but I give them tools to at least make it a single easy command when they need to do it.

By checking what is done in OpenImageIO, I agree that having a findXX from third-party libraries is extremely useful to simplify any cmake integration. By default, it could provide the version, and a standard way to search for the library. However, Windows platform support is still weak for the search part. So, the OCIO_INSTALL_EXT_PACKAGES is then essential for Windows platform support.
On the other hand, the automatic OpenColorIO library build is also mandatory (whatever is the platform) for most of our devs/users i.e. search for third-party libraries and if not found, download & compile, to guaranty a successful build without worrying about dependencies.
With the current work, the only missing piece is now the generated findOpenColorIO() and perhaps adjustments between findXX() vs. OCIO_INSTALL_EXT_PACKAGES.
Other aspects about using installed third-party libraries is the low control on the version, the dynamic vs. static library, and sometime the namespace. From the various integrations I did, I now always strongly recommend to generate & link with static libraries for all mandatory third-party dependencies, and hides private symbols (including third-party library ones). When integrating a library in a larger program (Maya, Flame, etc) there is a great chance that some third-party libraries be already used by the app or by another third-party dependency (out of your control) and that versions be different. The proposed approach avoids symbol conflicts at link time, weird crashes on client site at runtime.
So OCIO_INSTALL_EXT_PACKAGES is critical to 1) allow the bypass of installed third-party libraries, 2) build static libraries for dependencies and 3) optionally pass some extra compilation and/or link flags.

When looking at the CI builds, I notice that:

[Question] Could NOT find OpenImageIO (missing: OpenImageIO_DIR), should that be OpenImageIO_ROOT ?
[Minor] (found suitable version "3.7.7", minimum required is "2.7")  when detecting Python 3 the required version must be 3.x

When some third-party libraries are missing, the code could provide a additional one-line explanation on how to add the support:

Could NOT find GLEW (missing: GLEW_INCLUDE_DIRS GLEW_LIBRARIES)
or Could NOT find GLUT (missing: GLUT_glut_LIBRARY)
Keep the warning with an additional line explaining to use package_ROOT.

[Warning already present i.e. not from this PR]
On Windows platform, yaml-cpp and pystring have the following warning:
CMake Warning at share/cmake/modules/Findyaml-cpp.cmake:180 (message):
  Building STATIC libOpenColorIO using the in-built yaml-cpp.  yaml-cpp
  symbols are NOT included in the output binary!
Call Stack (most recent call first):
  share/cmake/modules/FindExtPackages.cmake:15 (find_package)
  CMakeLists.txt:216 (include)

The change could be part of another PR.

Hey, was just about to put in a PR around this. It may be isolated to my environment, however find_package(PythonInterp 2.7 QUIET) wasn't able to find my local Python3 interpreter or libraries. Swapping this with the now recommended (>=3.12)  find_package(Python COMPONENTS Interpreter)  however did work.
This would have to be updated in the python bindings CMakeLists.txt as well:
and find_package(Python COMPONENTS Interpreter  Development)
I'll make an updated PR to your branch.

@michdolan I have the same problem on macos with Python 2.7.16 & cmake 3.16.5.
@scoopxyz Your fix (in src/bindings/python/CMakeLists.txt) solves the problem on my machine.

I will address the remaining comments once I merge Sean's PR into my branch.

[Suggestions]

The search of the installed python is done several times, the code could centralize it, and enable/disable some builds i.e. docs, bindings, etc. For example, it could be moved in the root CMakeLists.txt, and if Python is not found, disable docs, Python bindings & Python unit tests with a warning message.
As the VFX Reference platform now requests Python 3, the code could check for version 3 (use of FindPython3 instead of FindPython) and if not found, fall back to Python 2 with a warning.

[Question] Could NOT find OpenImageIO (missing: OpenImageIO_DIR), should that be OpenImageIO_ROOT ?

CMake supports both. <package>_ROOT is searched first, and later <package>_DIR. I'm not sure why the CMake message calls out the later, but it's coming from find_package internals.

[Minor] (found suitable version "3.7.7", minimum required is "2.7") when detecting Python 3 the required version must be 3.x

I agree that 3.x is preferred, but technically 2.7 will still work too. If I bump the minimum we will be dropping support for Python 2 bindings.

[Warning already present i.e. not from this PR]
On Windows platform, yaml-cpp and pystring have the following warning:

These warnings are coming from our find modules. Are you suggestion to address the TODO comments about finding a way to merge in the static libs? On that point, do we want the yaml-cpp or pystring symbols to be exposed?
@hodoulp on a somewhat related point, should oiiohelpers depend on OpenGL and GLEW? OCIO CMake configuration will currently fail if OpenGL or GLEW are not found and OCIO_BUILD_APPS=ON, due to the REQUIRED find_package calls in it. It feels like this should not fail, since some apps could still be built.

@scoopxyz thanks for resolving the CLA issue. The DCO is now failing as it thinks you sign-off name should be your github handle. See: https://github.com/AcademySoftwareFoundation/OpenColorIO/pull/1016/checks?check_run_id=815283666

@hodoulp on a somewhat related point, should oiiohelpers depend on OpenGL and GLEW?

No, That's a false dependency. To be removed.


Monster book window

Button to optionally open additional checklist for monsters, as well as new window for graphical monster book.

Done in 413a85b but as separate program, rather than joined with Bookless tracker


Query and display info for Goals - My Care Planner

Patient/Caregiver App

If the barrier extension (FHIR-36691) is on the goal, it needs to be displayed.
If goal includes progress note, then display progress notes.
If goal addresses a condition, then display it
If goal includes a goal relationship extension to another goal, then it is displayed.

Add a link to "drill down" into a new view with details for one Goal.  This is too much information to display for all goals in the current goal list view.  Evaluate includes some of these additional elements for each goal in the goal listing.

Still need to add relationships and barriers.

Will resolve relationships and barriers connection with two stories on wireframing goal summary and goal detail pages #106 and #105