text:
Fix sourcemaps errors and update test

This huge PR brings next improvments:
Tests
First of all i rewrite tests using Tape and change folder structure.  It's more convinient way for testing, also such tests more flexible and can be debugged with Node debugger. Bash scripts is not cross-platform solution (Windows does'not support bash scripts without extra tools).
Besides i've added some new test cases. I'll describe this test cases later.
Issues
The main issue i've tried to solve, is duplicating files in sourcemaps (https://github.com/huston007/ng-annotate-loader/issues/24 see last comment, also https://github.com/huston007/ng-annotate-loader/issues/23).
But actually there is a bunch of things cause this issue.
Generally, problem is here:
var generator = SourceMapGenerator.fromSourceMap(new SourceMapConsumer(annotateMap));
generator.applySourceMap(new SourceMapConsumer(inputSourceMap), filename);

outputSourceMap = generator.toJSON();

inputSourceMap.sources should have same path and name as annotateMap.sources.
Otherwise outputSourceMap will be have duplicate files in sources.
Example:

As you can see in screenshot, outputSourceMap.sources has two entries, becuase sources in inputMap and annotateMap have diffrent slahes and path (relative/absoulte)
Therefore we see the first problem:
Sourcemap doesn't care about forward slahes
If you are using *nix system you have never got this error. See what mozilla/source-map team think about this https://github.com/mozilla/source-map/issues/91
So solution is simple, we need normalize pathes everewhere.
There is a big problem with accepatance tests, we can't simulate this behaviour, it means somebody on unix system can rewrite something and tests will not report any problems. (i think we need to refactor loader, and write unit test for mergeMap() function)
Prefixed resource path
Sometimes webpack (or not?), emit map with sources prefixed by loader name:

node_modules\tslint-loader\index.js!c:\opensource\ng-annotate-loader\cases\typescript\file-to-annotate.ts

Actually i don't know when and why it happend. I spend a lot of time to find the reason. But all i found was awesome-typescript-loader + tslint as preloader processed '*.ts' file caused this behaviour.
In our project, eslint cuase the same when precessing *.js files.
I added special test case typescript which cover this issue.
I was looking for a solution for a long time, i've tried few diffrent approaches, but finally is very simple:
 var filename = normalizePath(this.resourcePath);
inputSourceMap.sourceRoot = '';
inputSourceMap.sources[0] = filename;

Source map in loader always have just one entry in sources and this entry the same to processed file. We override entry, with normalized resource path.
Some loaders return sources with relative path and filled sourceRoot. We clear sourceRoot, because we override path with absoulte url, and we don't need prefix.
Issues with sourceRoot
SourceMapGenerator can merge maps even if they have not absolutely the same sources.
It can merge relative with absoulte path but only if correct source root is provided.
Sourcemaps from ngAnnotate always have absolute path, but inputSourceMap.sources can be diffrent it depend on loader.
Sometimes it has relative path + sourceRoot (babel-loader), sometimes only relative path (typescipt-loader), sometimes absolute path.
Solution the same as in previous issue: explicit set absolute path and clear sourceRoot.
I've added test case uglifyjs which cover this issue.
Dependecies
I've updated all dependecies, and update test references (because babel6 generate diffrent output)
Also i've added .editorconfig to help writing code in same code style.

Test failed. Interesting. Webpack Hash in source maps is diffrent... need another way to check sourcemaps valid. Dirty checking files is not good solution.

@thekip Great job! I need some time to get into it. Thank you for the PR!

Problem not only in hash (
Diffrent between unix/windows line endings.
I already fixed that in generated source, but the same mistake exist in maps as well, and it's not so easy to fix.

Last to commits bring next improvments:

Bugfix: when ngAnnotate do nothing on file it still generate sourcemap (i don't know what exactly mapped inside), when this map merged with input map it produce new broken merged map.

So i check, if source code are the same (nothing was to annotate) I just return input sourcemap without merging.
This is old bug, but previously we didn't notice that because it breaks a duplicate file in maps.

Change the way how maps are tested. I've created special file sourcemap-checkpoints.js for each test case, which used as reference for sourcemap.
This is more intelegent way to test maps, because we exactly know work this map or not as if tested in browser.
Also this fix issues with crlf/lf.

Any progress on it?

This is ready to merge, wait for @huston007
@hekike You can use my fork, untill it merged to original packet.

@thekip @hekike Oh that cool! Didn't noticed that it started passing the build. Merging.

@huston007 thanks ;)
When do you plan to release it?

@hekike I have to perform some testing before. You could help me if you try and say it works for you : )

@huston007 I use it about half month in our huge project (codebase about 3mb) and it works. My teammates didn't report any issues related to that.
You can run it on yours project, and test it as well.

@thekip Yep I will. Thank you for the job you've done.

authors: hekike huston007 thekip


text:
finetuning problem with evfsam2

Nice work of extending sams ability to text guidied!
We have used your evfsam1 as our baseline to a new area and showd a signifcant performance. However, when we finetuned your evfsam2, it was easy to overfiiting(didnt see in evfsam1).
Did you met the same prob when your fintune sam2 ? or some hyperpramters different from sam1?
Hope to recieve your suggestion!

The main differences between sam1 and sam2 lies in:

pre-process sam2 uses resize(1024), while sam1 uses resizelongest(1024) + padding.
sam2 uses hierachical image encoder and sam1 uses ViT
sam2 applies skip-connection to mask decoder.

Might these differences affect your training?

@vvvvvjdy can you share your fine-tuning script? many thanks.

Sorry for the late reply.
During my experiment，I found that the data augmentation caused the
overfitting probelm. Once I used the same augmentation as used in sam2
pretrain (only random hflip for image) ,the problem was solved. I assume
that stronger data augmentation for sam2 than pre-training may cause the
model to learn some unnatural shortcut features.
The fine-tuneing scripe is simple，just like
many sam1 fine-tuneing works. Only difference is the backbone. (I just
train my model on images)
Regards.
yi-ming-qian @.***> 于 2024年11月30日周六 上午8:09写道：

@vvvvvjdy https://github.com/vvvvvjdy can you share your fine-tuning
script? many thanks.
—
Reply to this email directly, view it on GitHub
https://github.com/hustvl/EVF-SAM/issues/26#issuecomment-2508745576, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/BACXUVSRN6EEIJO7MEBG35L2DD6ZZAVCNFSM6AAAAABOWGI2AWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBYG42DKNJXGY
.
You are receiving this because you were mentioned.Message ID:
@.***>

The augmentations influence the model performance in another way. In referring segmentation tasks, text prompts contain geometric words like "on the left". Once flipping or cropping or some other augmentations are applied, the prompts would fail. So only non-geometric augmentations are recommended.

@CoderZhangYx Quite agree with this statement. But even without such prompts in my finetuning data, the stronger data augmentation than the pretraining may cause this problem (some works have demonstrate the small-size model slike resnet-18 are especially sensitive to aug)，I m shocked that such a large foundation model sam2 has such characteristics.

That's amazing. What aug did you use? Could it be the reason that the aug didn't applied to the source fed to multi_model_extractor? Curious about this bug, honestly.

@CoderZhangYx I originally use large scale jittering(strong) for the input image(both beit and sam1 or 2) and gtmask,  and found it works well on evfsam1 but not on evfsam2. Did you use the same aug for evfsam1 and 2, and which aug did you use ? ( it not mentioned in the paper)?

In fact we use no aug when training our model. It is so strange that scale jittering affect performance of sam2. Inform me if you find out any other reasons, thanks!

source: gharchive/issue

authors: CoderZhangYx vvvvvjdy yi-ming-qian

repo: hustvl/EVF-SAM

license_type: permissive

license_source: github-api


text:
Question about  accuracy and evaluation setting

Hello, I follow your code  to evaluate on validation set ，but  it goes wrong  on the 17-th instance iter  with  " wrong number of line in mask#0 "  but I'm pretty sure  I follow your code to  run the python prepare_data_inst_gttxt.py  ,when I  replace the 17-th scene name in  the  scannetv2_val.txt   to any other scene_name  , it works well.
Besides , when i replace the 17-th scene_name with any other scene, the accuracy seems  lower than the   mAP/mAP50/mAP25 is 44.1/64.4/75.7.  provided in your github.
I  am wondering what causes this.

one more ,  I  found  the setting    using_set_aggr_in_training: False  in the  config file  is  False  ,I  am doubting whether should I  set  it  True

Hi. We haven't encountered this problem. Perhaps this bug is relative to data. Please try to re-download the annotation files and then run "python prepare_data_inst_gttxt.py" again.
As for 'using_set_aggr_in_training', both True of False are OK. But disabling set aggr. in training makes the convergence more stable.

When  I  re-generate gt-files, the testing result of your pretrained models  now   correspondends to yours , but  the  testing result  of  your  trained models for 500 epoch is  still lower for  2 or 3 point  in the mAP/mAP50/mAP25  . I  want to  know how  can  I get the same  train  result with your provided pretrained model   on the valid  dataset.

I trained the model following the instruction for 500 epoch, the mAP50 is about 60, which is 4 point lower than the paper. Where is the problem ?

authors: Gardlin c6376315qqso outsidercsy

repo: hustvl/HAIS

license: MIT


text:
run train_net.py eval function and demo.py get different results

hi, I have trained with coco datasets(only extract 100 images for quickly test), and evaluate these 100 images to get AP(about 90). But when I run demo.py to view the mask of image, the result is very bad. Also, I have already run demo.py with the model your provide and get good mask. Thanks!

Hi @wangshuailpp, thanks for your interest in SparseInst.
Have you loaded the correct model or config when using demo.py to inference?

I set the same model and config for test_net and demo. test_net gets good AP(about 90), but demo gets very bad mask of image. Thanks!

Hi @wangshuailpp, it seems that you only train the model with 100 images from scratch and evaluated it on the training set. The model might overfit the 100 images. How about the images for visualization. Are these images are same as the images during testing?

I sure that the test and the train are same images.

I sure that the test and the train are same images. But I found a strange phenomenon. The model size I train is all 400. 4M(from model_0004999.pth to model_final.pth), but the model size your provide is 133.7(sparse_inst_r50vd_dcn_giam_aug_67dc06.pth).

Maybe, you need to check the trained model when using demo.py and check whether the weights are loaded correctly.
As for the second problem, the model checkpoint contains model weights, states of the optimizer, and some necessary elements, which are stored for resuming training. We remove these useless states of the checkpoints for less space.

Hi @wondervictor
I met the same problem. The training phase shows that the model achieves a high AP. But in the inference stage, it gets a bad performance. I trained  coco/train_2017 and evaluated coco/val2017.  I don't know why it gets such a high AP.
Backbone: the backbone of yolov5s contained FPN layer
lr: 0.00001
batch size: 16
[06/27 09:03:49] d2.evaluation.coco_evaluation INFO: Evaluation results for segm:
[06/27 09:03:47] d2.evaluation.fast_eval_api INFO: COCOeval_opt.evaluate() finished in 10.19 seconds.
[06/27 09:03:47] d2.evaluation.fast_eval_api INFO: Accumulating evaluation results...
[06/27 09:03:49] d2.evaluation.fast_eval_api INFO: COCOeval_opt.accumulate() finished in 1.28 seconds.
[06/27 09:03:49] d2.evaluation.coco_evaluation INFO: Evaluation results for segm:
|   AP   |  AP50  |  AP75  |  APs   |  APm   |  APl   |
|:------:|:------:|:------:|:------:|:------:|:------:|
| 49.467 | 87.500 | 48.812 | 32.919 | 49.825 | 69.343 |
[06/27 09:03:49] d2.evaluation.coco_evaluation INFO: Per-category segm AP:
| category      | AP     | category     | AP     | category       | AP     |
|:--------------|:-------|:-------------|:-------|:---------------|:-------|
| person        | 43.785 | bicycle      | 32.271 | car            | 42.777 |
| motorcycle    | 41.864 | airplane     | 53.666 | bus            | 64.478 |
| train         | 71.820 | truck        | 55.110 | boat           | 39.147 |
| traffic light | 41.711 | fire hydrant | 61.725 | stop sign      | 70.547 |
| parking meter | 65.880 | bench        | 38.417 | bird           | 31.598 |
| cat           | 75.043 | dog          | 66.143 | horse          | 41.768 |
| sheep         | 48.491 | cow          | 46.441 | elephant       | 59.619 |
| bear          | 78.057 | zebra        | 56.101 | giraffe        | 53.960 |
| backpack      | 36.774 | umbrella     | 47.956 | handbag        | 33.903 |
| tie           | 34.070 | suitcase     | 52.099 | frisbee        | 61.102 |
| skis          | 12.655 | snowboard    | 35.651 | sports ball    | 46.322 |
| kite          | 35.145 | baseball bat | 24.195 | baseball glove | 49.813 |
| skateboard    | 36.658 | surfboard    | 41.859 | tennis racket  | 52.250 |
| bottle        | 39.589 | wine glass   | 28.893 | cup            | 49.328 |
| fork          | 17.350 | knife        | 20.521 | spoon          | 21.177 |
| bowl          | 54.863 | banana       | 43.836 | apple          | 47.963 |
| sandwich      | 63.597 | orange       | 54.590 | broccoli       | 46.770 |
| carrot        | 40.702 | hot dog      | 50.465 | pizza          | 63.825 |
| donut         | 53.661 | cake         | 55.068 | chair          | 36.520 |
| couch         | 62.362 | potted plant | 43.600 | bed            | 76.547 |
| dining table  | 52.464 | toilet       | 72.657 | tv             | 66.814 |
| laptop        | 62.028 | mouse        | 60.983 | remote         | 38.988 |
| keyboard      | 63.289 | cell phone   | 43.698 | microwave      | 65.430 |
| oven          | 61.911 | toaster      | 70.000 | sink           | 55.822 |
| refrigerator  | 71.195 | book         | 26.437 | clock          | 64.107 |
| vase          | 51.646 | scissors     | 42.721 | teddy bear     | 59.757 |
| hair drier    | 49.020 | toothbrush   | 26.258 |                |        |
[06/27 09:03:49] d2.engine.defaults INFO: Evaluation results for coco/val2017 in csv format:
[06/27 09:03:49] d2.evaluation.testing INFO: copypaste: Task: segm
[06/27 09:03:49] d2.evaluation.testing INFO: copypaste: AP,AP50,AP75,APs,APm,APl
[06/27 09:03:49] d2.evaluation.testing INFO: copypaste: 49.4665,87.5005,48.8123,32.9194,49.8253,69.3428

Hi @fabro66, could you provide a model config with weights for me? This problem is strange.

Hi @fabro66, could you provide a model config with weights for me? This problem is strange.

OK!
model & configs & weights
Please check it!

Hi @fabro66, I've tested the model along with the weights through two scripts, i.e., train_net.py and test_net.py on my local machine (4 NVIDIA 3090 GPUs, PyTorch=1.9.1, cuda=11.1, detectron2=0.6)

train_net.py:

python train_net.py --config-file configs/instance/sparse_inst_y5s_giam.yaml --eval --num-gpus 4 MODEL.WEIGHTS sparseinst_y5s_backbone/weights/model_Final.pth

outputs:
[06/27 14:54:39 d2.engine.defaults]: Evaluation results for coco_2017_val in csv format:
[06/27 14:54:39 d2.evaluation.testing]: copypaste: Task: segm
[06/27 14:54:39 d2.evaluation.testing]: copypaste: AP,AP50,AP75,APs,APm,APl
[06/27 14:54:39 d2.evaluation.testing]: copypaste: 49.4720,87.5011,48.7639,32.9183,49.8236,69.3405

test_net.py:

python test_net.py --config-file configs/instance/sparse_inst_y5s_giam.yaml MODEL.WEIGHTS sparseinst_y5s_backbone/weights/model_Final.pth

outputs:
[06/27 15:03:19 d2.evaluation.testing]: copypaste: Task: segm
[06/27 15:03:19 d2.evaluation.testing]: copypaste: AP,AP50,AP75,APs,APm,APl
[06/27 15:03:19 d2.evaluation.testing]: copypaste: 49.4670,87.4931,48.7567,32.9138,49.8194,69.3319
speed: 0.0159s FPS: 62.78

It seems that the results are normal through two ways of evaluation. Can you provide more details about the inconsistency between training and testing? BTW, I'm concerned about the pre-trained weights used in the provided backbone because it achieves promising results (49.5 mAP, 63 FPS). It's amazing.

Hi @fabro66 and @wangshuailpp, I find that the demo.py outputs strange results and I'm going to fix it.

It seems that the results are normal through two ways of evaluation. Can you provide more details about the inconsistency between training and testing? BTW, I'm concerned about the pre-trained weights used in the provided backbone because it achieves promising results (49.5 mAP, 63 FPS). It's amazing.

Hi @wondervictor
The inconsistency I express here refers to the high AP in the training phase and bad performance in demo.py.
I use pre-trained weights of the yolov5s backbone in coco dataset.

Hi @fabro66 and @wangshuailpp, I've fixed this problem!
This problem is due to a mistake about INPUT_FORMAT, or exactly, "BGR" and "RGB".
In demo.py, images are loaded in an RGB format in demo.py:L93 https://github.com/hustvl/SparseInst/blob/bd57455aa49c4cb37d66c77ccd477c7a5ebee444/demo.py#L93
but it's converted to the BGR format in detectron2/engine/defaults.py:L311
https://github.com/facebookresearch/detectron2/blob/224cd2318fdb45b5e22bbb861ee9711ee52c8b75/detectron2/engine/defaults.py#L311
which is a wrong step.
To solve it, you can add another convension by:
predictions = self.predictor(image[:,:,::-1])

in sparse_inst/d2_predictor.py:L49.
And I'll update the code to fix this bug.

Hi @fabro66, the model you've trained achieves 49.5 AP on COCO val2017 and should perform well on the images. From the evaluation results, it seems the problem is not due to the overfitting. Have you compared the results before/after changing the image format?

Hi @wondervictor. I have compared the results before/after changing the image format. It will get better performance than before changing the image format. However, it still gets bad performance in coco_val_2017 dataset.

Hi @wondervictor .
As long as I keep training sparseinst-yolonet, the AP keeps improving. For the validation dataset, some images are segmented well, even some people of small size. In some images, even if the person is standing in a large area in the image, the performance is bad.  Is there something wrong with my hyperparameters? Could you help reproduce sparseinst-yolonet?

Hi @fabro66, I'd like to solve this problem while it takes a little time now. I'm working on it. If you make any progress, please feel free to mention me in this issue : )

Hi @fabro66, I've evaluated the visualization results on the training set and the results are also bad. This problem is much weird. The AP on val2017 is 49.5, which is much higher than that using ResNet-50. However, the visualization results are worse than the ResNet-based models. @fabro66, could you run the visualization results with the pretrained models with ResNet-50 to check whether the scripts in your environment work well. I'm going to re-train the SparseInst with the yolo model. I'll notify you if I achieve any progress : )

Hi @fabro66, I've evaluated the visualization results on the training set and the results are also bad. This problem is much weird. The AP on val2017 is 49.5, which is much higher than that using ResNet-50. However, the visualization results are worse than the ResNet-based models. @fabro66, could you run the visualization results with the pretrained models with ResNet-50 to check whether the scripts in your environment work well. I'm going to re-train the SparseInst with the yolo model. I'll notify you if I achieve any progress : )

Hi @wondervictor. I used the pretrained model with ResNet-50 for visualization on val2017 and got good performance, which confirms that my environment is ok. I don't sure whether my batch size is set too small (16 in my experiments). Looking forward to your new progress！

Hi @fabro66  I am going to use yolov5s as backbone. Would you please share your configs and models. The above link is dead. I will test it on my machine as well. Thanks.

authors: fabro66 wangshuailpp wondervictor xjsxujingsong

repo: hustvl/SparseInst


text:
File Descriptor leaks

Put this code [[NHNetworkClock sharedNetworkClock] synchronize];
into applicationDidBecomeActive
print used File Descriptors using lsof function from the following stackoverflow post http://stackoverflow.com/a/8153026
Use lsof in applicationDidBecomeActive and applicationWillResignActive
Make app active/inactive 10+ times.
Result: File Descriptors amount will grow up like crazy. Finally you will get 'Too many open files' error and app will not work correctly or crash.

The leak is caused by NHNetAssociation, which is never deallocated due to strong references to it. I'm almost done with the fix, will post it.

Thank you very much

I have created a pull request with the fix:
https://github.com/huynguyencong/NHNetworkTime/pull/24
Meanwhile you can use the fixed code from my fork directly until the pull request is accepted:
https://github.com/mmahkamov/NHNetworkTime/tree/net_association_leak_fix
If you're using Cocoapods:
pod 'NHNetworkTime', :git => 'https://github.com/mmahkamov/NHNetworkTime.git', :branch => 'net_association_leak_fix'

I found more leaks, this time I see a lot of CocoaAsyncSocket objects which are not being freed. I

It's done now. I pushed the latest commit to my fork. Once the pull request is accepted you'll be able to get the fix. Or you can get it from my fork for now as I described above.

Merged it. Thank you guys

authors: dimala huynguyencong mmahkamov

repo: huynguyencong/NHNetworkTime

license_source: bigquery


text:
restore chef 11 support?

It looks like 0.4.2 breaks chef-11 support. It would be nice to keep this support for a little while longer, if it's an easy change (looks like it might be).
  ================================================================================
  Recipe Compile Error in /opt/pantheon/infrastructure/cookbooks/onebox/recipes/default.rb
  ================================================================================

  NoMethodError
  -------------
  undefined method `compile_time' for Chef::Resource::ChefGem

  Cookbook Trace:
  ---------------
    /opt/pantheon/infrastructure/cookbooks/route53/recipes/default.rb:24:in `block in from_file'
    /opt/pantheon/infrastructure/cookbooks/route53/recipes/default.rb:22:in `from_file'
    /opt/pantheon/infrastructure/cookbooks/onebox/recipes/route53.rb:5:in `from_file'
    /opt/pantheon/infrastructure/cookbooks/onebox/recipes/base.rb:7:in `from_file'
    /opt/pantheon/infrastructure/cookbooks/onebox/recipes/default.rb:3:in `from_file'

  Relevant File Content:
  ----------------------
  /opt/pantheon/infrastructure/cookbooks/route53/recipes/default.rb:

   17:  # limitations under the License.
   18:  #
   19:
   20:  include_recipe 'xml::ruby'
   21:
   22:  chef_gem "fog" do
   23:    action :install
   24>>   compile_time false
   25:    version node['route53']['fog_version']
   26:  end
   27:

+1 on this please! we could really benefit from getting this fixed all of our custom cookbooks in OpsWorks AWS (which uses chef 11) are broken and new instances can't be launched :(

Great. Thanks for #90 I'll try and cut a release this weekend.

authors: bshehram joemiller slyness


text:
added page translation and removed duplicated files

Signed-off-by: alexzhc alex.zheng@daocloud.io

What this PR does / why we need it:
Add page translation and remove duplicated files
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Add page translation and remove duplicated files

source: gharchive/pull-request

repo: hwameistor/hwameistor


text:
Change Keyring construction to make it constant

This allows code doing things like:
const KEYRING: Keyring = Keyring::new(service, username);

@jaysonsantos Why do you want to have an entry be a constant?

With the revamp of #70 that we're about to release, it's unlikely that keyring can be constants, so I'm going to close this PR.  @jaysonsantos if you feel this is important functionality, can you please submit an issue giving the rationale for why it's needed?  Thanks!

authors: brotskydotcom jaysonsantos

repo: hwchen/keyring-rs


text:
Finalize navigation related classes

Very breaking refactor of all navigation related services, both code and views.

Original idea was to create an ExternalRoute object, but thinking about it, I actually don't think NavItems need to store internal data as Route objects. The solution here is probably less abstraction, not more.

Original idea was to create an ExternalRoute object, but thinking about it, I actually don't think NavItems need to store internal data as Route objects. The solution here is probably less abstraction, not more.

Yeah, since the NavItems are constructed for each page render, we can just preresolve the destination string.

Code review by ChatGPT:
Overall, the NavItem class appears to be well-structured and follows good programming practices. Here are some specific points:

The class is well-documented. Each method has a clear purpose and is documented with a description and relevant information, such as expected parameters and return types.

The use of PHP's declare(strict_types=1) directive ensures that type hints are enforced, which can help prevent type-related bugs.

The NavItem class makes use of PHP's readonly keyword to ensure that the class's properties cannot be modified after they have been set, which can help prevent unexpected changes to the object's state.

The class follows the single responsibility principle, as it is responsible for representing a navigation menu item and does not have any extraneous functionality.

The use of the Stringable interface allows instances of the NavItem class to be treated as strings, which can be useful in situations where a string representation of the object is required.

The class's methods make use of type hints and return types, which can help prevent type-related bugs and make the code more self-documenting.

The use of the namespace keyword and the use statement to declare dependencies and aliases helps keep the code organized and easy to understand.

The NavItem class uses the Str::slug() method from Laravel's Illuminate\Support\Str class to normalize group keys, which can help prevent inconsistencies in grouping values.

Overall, the NavItem class appears to be a well-designed and useful component of the Hyde framework's navigation functionality.

repo: hydephp/develop


text:
Sending files returns an error

TypeError: Cannot assign to read only property 'name' of function 'function (){
   return this[Math.floor(Math.random() * ((this.length-1) - 0 + 1)) + 0];
}'
    at TextChannel.send ([redacted]/node_modules/discord.js/src/structures/interfaces/TextBasedChannel.js:99:23)
    at TextChannel.sendFiles ([redacted]/node_modules/discord.js/src/structures/interfaces/TextBasedChannel.js:156:17)
    at TextChannel.sendFile ([redacted]/node_modules/discord.js/src/structures/interfaces/TextBasedChannel.js:168:17)
    at eval (eval at PhotoBox.on ([redacted]/main.js:160:25), <anonymous>:1:21)
    at Client.PhotoBox.on ([redacted]/main.js:160:25)
    at emitOne (events.js:96:13)
    at Client.emit (events.js:191:7)
    at MessageCreateHandler.handle ([redacted]/node_modules/discord.js/src/client/websocket/packets/handlers/MessageCreate.js:9:34)
    at WebSocketPacketManager.handle ([redacted]/node_modules/discord.js/src/client/websocket/packets/WebSocketPacketManager.js:123:65)
    at WebSocketManager.eventPacket ([redacted]/node_modules/discord.js/src/client/websocket/WebSocketManager.js:252:31)
    at emitOne (events.js:96:13)
    at WebSocketConnection.emit (events.js:191:7)
    at WebSocketConnection.eventMessage ([redacted]/node_modules/discord.js/src/client/websocket/WebSocketConnection.js:49:12)
    at WebSocket.onMessage ([redacted]/node_modules/ws/lib/EventTarget.js:103:16)
    at emitTwo (events.js:106:13)
    at WebSocket.emit (events.js:194:7)

discord.js version: 11.1.0
node.js version: 7.9.0
Operating system: Ubuntu 16.04 x32
Priority this issue should have – please be realistic and elaborate if possible: high?

[x] I have also tested the issue on latest master, commit hash: a652901d60a7ecb7ce8f77cbb9d1210f049e9e59

Could not replicate, might be a problem on snazzy's end.

FYI: My code was assigning things to arrays.
Array.prototype.random = function(){
	return this[Math.floor(Math.random() * ((this.length-1) - 0 + 1)) + 0];
}

Array.prototype.pickOff = function(e){
    let a = undefined;
    this.map(i=>{
        if(e.id === i.id){
            a = i;
        }
    });
    return a;
}

This is a really bad shuffle btw.

Yep.


text:
[BUG] Hydra leaves almost all files behind after uninstallation

Describe the bug

Following the events of #1103, I decided to do a clean install of Hydra, since I have been using it since the 1.0 release, and a lot of files have been piling up in different places.

So I uninstalled both versions (shared and user), and went to check for extra files, when I noticed that Hydra was (kinda) still installed: most files were still in the folder!

Although there were no shortcuts on the start menu nor the desktop, and Hydra looked a bit broken, it was still there!

This was even worse for the per-user install: it only removed the shortcuts!

Even the launcher was intact!

Steps to Reproduce

Uninstall Hydra normally (trough appwiz.cpl or the settings app)
Check the Hydra installation directories according to your install %localappdata%\Programs\Hydra (per-user) & C:\Program Files\Hydra (shared/machine wide)
Verify that most files (including the main .exe!) are still there!

Expected behavior
The uninstaller should clean up the main program files and the folder that contains them on uninstall.
At least I think that keeping the hydra.db and logs in %appdata%\hydra is intended behaviour, because the uninstaller cleaned up all the other files in that folder.
Additional information and data
Does the uninstaller make logs? If so, I couldn't find them.
logs.txt
error.txt
info.txt
Idk if these will help anything, were the only ones I could find.
Operating System
Windows 11 Pro
Hydra Version
2.1.7 for machine install, 3.0.1 for user install
Before opening this Issue

[X] I have searched the issues of this repository and believe that this is not a duplicate.
[X] I am aware that Hydra team does not offer any support or help regarding the downloaded games.

Does this happen if you have only one type of installation (system-wide or per user)?

I don't know, I'm going to do a full clean install of each and test the uninstallers separately.
Something even weirder happened as I was reinstalling:
The setup said that there was already a per-user install, when I had already uninstalled it and cleaned all traces of it:

Update: installed per-user again and uninstalled, and it looks like this time it uninstalled correctly.
Only left behind the Hydra folder (although empty, but should also be deleted btw) in %localappdata%\Programs
The installer also no longer recognises that there was a previous install:

Repeating the process for the all users/shared/machine install yields the exact same results (but now the empty folder is in C:\Program Files)

Same Here, My hydra was originally installed in the C:\Program Files\Hydra folder, after the 3.0.1 update it was installed again but in the C:\Users\USER\AppData\Local\Programs\Hydra folder.

authors: MigProPlayer ruizlenato

repo: hydralauncher/hydra


text:
Metadata Editing for NetCDF Resource Type

This function will write the resource science metadata stored in Django to the netCDF file in the NetCDF resource.

@gantian127 please tell @Lizabrazil what has changed on the UI for this issue.  She needs to change help documentation and screen shots to reflect changes in functionality.  Help documentation is prepared in google docs in https://drive.google.com/drive/u/1/folders/0B8FGrdqHDtsDLTdjTWswdmZvWW8.  @Lizabrazil can point you to specific documents that need updating.  I did not see a document for multidimensional in resource types, but there is a document for composite.  There is a help page for multidimensional, that can serve as a starting point https://pages.hydroshare.org/hydroshare-resource-types/multidimensional-netcdf/, but this is very short.

@dtarb @Lizabrazil I will prepare the screen shots and the documentation. It will be great if I could be pointed to the specific documents for updating. Thanks.

Hi Tian, I'm not sure there is much on the help page for Multidimensional yet. Here is the link i know of: https://pages.hydroshare.org/hydroshare-resource-types/multidimensional-netcdf/

@dtarb @Lizabrazil I created a new help document for Multidimensional (NetCDF) resource. It can be accessed from HydroShare google drive folder: SystemDesign -> User Experience -> HELP content development -> Resource Types.  The section of " Update Metadata in the NetCDF File " in the document can be used as the content for 1.10 release documentation. If I need to provide other information, please let me know. Thanks,
@ChristinaB would you please assign a proof reader of this new help document and update the help page content for the Multidimensional (NetCDF) resource ? Thanks

OK

authors: Lizabrazil dtarb gantian127

repo: hydroshare/hydroshare


text:
[#5030] WIP collection queries

Eventually resolves #5030

Pull Request Checklist:

[ ] Positive Test Case Written by Dev

[ ] Automated Testing

[ ] Sufficient User and Developer Documentation

[ ] Passing Jenkins Build

[ ] Peer Code review and approval

Positive Test Case

[Enter positive test case here]

METRIC
VALUE

https://sonarqube.cuahsi-workstation.com:9000/dashboard?id=hydroshare-5038

authors: devincowan hydrocheck


text:
sam_FineTune.py

Existing issues

Batch size more than 1 cause error (due to multi-prompt)
https://github.com/facebookresearch/segment-anything/issues/277
Temporarily using unit-sized batch gradient accumulation

Layerwise LR decay of 0.8 not properly implemented

Drop-path with rate of 0.4 not implemented

Loss function(Focal+Dice) is not strictly validated, but the training looks fine in running.

Decreasing LR with factor of 10 at iteration 60000, 86666...not considered

Multiprocessing image loading not properly working

Why is there no mask in predict after fine tune?

Existing issues

Batch size more than 1 cause error (due to multi-prompt)
RuntimeError when using batch size > 1 facebookresearch/segment-anything#277
Temporarily using unit-sized batch gradient accumulation
Layerwise LR decay of 0.8 not properly implemented
Drop-path with rate of 0.4 not implemented
Loss function(Focal+Dice) is not strictly validated, but the training looks fine in running.
Decreasing LR with factor of 10 at epoch 60000, 86666...not considered
Multiprocessing image loading not properly working
Is it possible to use the automatic_mask_generator function to make predictions after fine tune?

Is it possible to use the automatic_mask_generator function to make predictions after fine tune?

Is it possible to use the automatic_mask_generator function to make predictions after fine tune?

The trained model will save segment-anything.modeling.sam.Sam.mask_decoder.state_dict() to models/*.pt. It will work fine if you properly load fine-tuned mask decoder params to the original pretrained model instance.

Is it possible to use the automatic_mask_generator function to make predictions after fine tune?

The trained model will save segment-anything.modeling.sam.Sam.mask_decoder.state_dict() to models/*.pt. It will work fine if you properly load fine-tuned mask decoder params to the original pretrained model instance.

Thank you for your answer, I tried to train with reference to your project code and got the model after fine tuning, but trying to segment the image in . /tmp folder of sam_firsttry.ipynb for image segmentation, I get an empty list of mask, while the model without fine-tuning can get mask.Does your trained model work properly?

Is it possible to use the automatic_mask_generator function to make predictions after fine tune?

The trained model will save segment-anything.modeling.sam.Sam.mask_decoder.state_dict() to models/*.pt. It will work fine if you properly load fine-tuned mask decoder params to the original pretrained model instance.

Thank you for your answer, I tried to train with reference to your project code and got the model after fine tuning, but trying to segment the image in . /tmp folder of sam_firsttry.ipynb for image segmentation, I get an empty list of mask, while the model without fine-tuning can get mask.Does your trained model work properly?

I don't recommend using that notebook. It's just for my practice. I used visualize.plot_mask to actually obtain masks and draw images in the readme file.

I understand. Thank you for your reply

authors: EnKaiZhang hyeonbeenlee


text:
Argon2-cffi-bindings do not support FreeBSD 12

Hey,It is impossible to install because of the lack of support for FreeBSD, please upgrade to add support, because of this lack of support it is impossible to install my python package, I clearly do not want to modify my code as I am extremely dependent on your package, I look forward to future support for FreeBSD 12.

I have asked the developer of the flask_argon2 python package that depends on argon2_cffi and Argon2-cffi-bindings to try to do an update on his side to add support for FreeBSD

It remains to be seen
Afi.

You're gonna have to give me more information, if you expect me to help you. What exactly does "impossible to install" mean?

here is the error logs I have :
FreeBSD 12.2-RELEASE-p14 325282c09a5(HEAD) TRUENAS

        TrueNAS (c) 2009-2022, iXsystems, Inc.
        All rights reserved.
        TrueNAS code is released under the modified BSD license with some
        files copyrighted by (c) iXsystems, Inc.

        For more information, documentation, help or support, go here:
        http://truenas.com
Welcome to TrueNAS

root@truenas[~]# pip3 install argon2-cffi-bindings
Collecting argon2-cffi-bindings
  Using cached argon2-cffi-bindings-21.2.0.tar.gz (1.8 MB)
  Installing build dependencies ... error
  error: subprocess-exited-with-error

  × pip subprocess to install build dependencies did not run successfully.
  │ exit code: 1
  ╰─> [84 lines of output]
      Collecting setuptools>=45
        Using cached setuptools-63.1.0-py3-none-any.whl (1.2 MB)
      Collecting setuptools_scm>=6.2
        Using cached setuptools_scm-7.0.4-py3-none-any.whl (42 kB)
      Collecting wheel
        Using cached wheel-0.37.1-py2.py3-none-any.whl (35 kB)
      Collecting cffi>=1.0.1
        Using cached cffi-1.15.1.tar.gz (508 kB)
        Preparing metadata (setup.py): started
        Preparing metadata (setup.py): finished with status 'done'
      Collecting typing-extensions
        Using cached typing_extensions-4.3.0-py3-none-any.whl (25 kB)
      Collecting tomli>=1.0.0
        Using cached tomli-2.0.1-py3-none-any.whl (12 kB)
      Collecting packaging>=20.0
        Using cached packaging-21.3-py3-none-any.whl (40 kB)
      Collecting pycparser
        Using cached pycparser-2.21-py2.py3-none-any.whl (118 kB)
      Collecting pyparsing!=3.0.5,>=2.0.2
        Using cached pyparsing-3.0.9-py3-none-any.whl (98 kB)
      Using legacy 'setup.py install' for cffi, since package 'wheel' is not installed.
      Installing collected packages: wheel, typing-extensions, tomli, setuptools, pyparsing, pycparser, packaging, cffi, setuptools_scm
        Running setup.py install for cffi: started
        Running setup.py install for cffi: finished with status 'error'
        error: subprocess-exited-with-error

        × Running setup.py install for cffi did not run successfully.
        │ exit code: 1
        ╰─> [45 lines of output]

                No working compiler found, or bogus compiler options passed to
                the compiler from Python's standard "distutils" module.  See
                the error messages above.  Likely, the problem is not related
                to CFFI but generic to the setup.py of any Python package that
                tries to compile C code.  (Hints: on OS/X 10.8, for errors about
                -mno-fused-madd see http://stackoverflow.com/questions/22313407/
                Otherwise, see https://wiki.python.org/moin/CompLangPython or
                the IRC channel #python on irc.libera.chat.)

                Trying to continue anyway.  If you are trying to install CFFI from
                a build done in a different context, you can ignore this warning.

            running install
            running build
            running build_py
            creating build
            creating build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9
            creating build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/api.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/__init__.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/setuptools_ext.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/cffi_opcode.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/vengine_cpy.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/lock.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/cparser.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/ffiplatform.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/verifier.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/vengine_gen.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/pkgconfig.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/model.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/recompiler.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/backend_ctypes.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/error.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/commontypes.py -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/_cffi_include.h -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/parse_c_type.h -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/_embedding.h -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            copying cffi/_cffi_errors.h -> build/lib.freebsd-12.2-RELEASE-p14-amd64-3.9/cffi
            running build_ext
            building '_cffi_backend' extension
            creating build/temp.freebsd-12.2-RELEASE-p14-amd64-3.9
            creating build/temp.freebsd-12.2-RELEASE-p14-amd64-3.9/c
            cc -pthread -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -fPIC -DFFI_BUILDING=1 -I/usr/include/ffi -I/usr/include/libffi -I/usr/local/include -I/usr/local/include/python3.9 -c c/_cffi_backend.c -o build/temp.freebsd-12.2-RELEASE-p14-amd64-3.9/c/_cffi_backend.o
            error: command 'cc' failed: No such file or directory
            [end of output]

        note: This error originates from a subprocess, and is likely not a problem with pip.
      error: legacy-install-failure

      × Encountered error while trying to install package.
      ╰─> cffi

      note: This is an issue with the package mentioned above, not pip.
      hint: See above for output from the failure.
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× pip subprocess to install build dependencies did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

You're trying to compile a C extension on a computer without a C compiler.
Given there's a FreeBSD port of this project, it looks like it supports FreeBSD just fine.

Indeed, it was missing cc (gcc/clang)

authors: afi-dev hynek


text:
Search on type causes not a robot checks

I ran into annoying problem - after every search I had to pass not a robot check.
WDYT on adding setting for enabling/disabling search on type?

I just have disabled search-on-type. It should reduce RECAPTCHA showing.

authors: ILScc nin-jin


text:
2.0.0版本的crontab启动时报错

如上图，1.1.26版本是正常的，2.0.0版本报错

上图中，2.0.0的图片发错了

同样的问题

请先根据 2.0 升级指南的步骤进行升级处理

authors: actoy huangzhhui tyhcmzy

repo: hyperf/crontab


text:
Added appends($attributes) method to collections

From Eloquent
https://github.com/illuminate/database/commit/f669df33a773ed03eff59ee9f70ea928b5ce3438

可以加上单测？

repo: hyperf/hyperf


text:
enable create -v initialize volumes

One can use hyper create -v to create new container with local and remote volumes.
Test results:
[lear@compose]$hyper create -v https://raw.githubusercontent.com/msanand/docker-workflow/master/node/Dockerfile:/vol/data1 -v https://github.com/msanand/docker-workflow.git:/vol/data2 -v /home/bergwolf/demo/:/vol/data3 -v /home/bergwolf/tests/wait.c:/vol/data4 busybox
uploading /home/bergwolf/demo/ uploading /home/bergwolf/tests/wait.c .success
.......success
8b2983a71fe7de509593f792d6affa3c6a2f40d6d2d9a5422c700a22f0b4710b
[lear@compose]$hyper start 8b2983a71fe7de509593f792d6affa3c6a2f40d6d2d9a5422c700a22f0b4710b
8b2983a71fe7de509593f792d6affa3c6a2f40d6d2d9a5422c700a22f0b4710b
[lear@compose]$hyper exec 8b2983a71fe7de509593f792d6affa3c6a2f40d6d2d9a5422c700a22f0b4710b ls -l /vol/data1 /vol/data2 /vol/data3 /vol/data4
-rwxrwxrwx    1 root     root           659 Aug 24 08:43 /vol/data1
-rwxrwxrwx    1 1000     1000           436 Aug 24 08:43 /vol/data4

/vol/data2:
total 24
-rw-r--r--    1 root     root           850 Aug 24 08:43 README.md
-rw-r--r--    1 root     root           218 Aug 24 08:43 circle.yml
-rw-r--r--    1 root     root           423 Aug 24 08:43 docker-compose.yml
drwxr-xr-x    2 root     root          4096 Aug 24 08:43 nginx
drwxr-xr-x    3 root     root          4096 Aug 24 08:43 node
drwxr-xr-x    2 root     root          4096 Aug 24 08:43 redis

/vol/data3:
total 28
-rw-r--r--    1 1000     1000           162 Aug 24 08:43 0_INDEX
-rw-r--r--    1 1000     1000           305 Aug 24 08:43 1_hyper_compose
-rw-r--r--    1 1000     1000           307 Aug 24 08:43 2_port_mapping
-rw-r--r--    1 1000     1000          1525 Aug 24 08:43 3_copy_data_to_volume
-rw-r--r--    1 1000     1000           443 Aug 24 08:43 4_new_container_size
-rw-r--r--    1 1000     1000           960 Aug 24 08:43 5_hyper_load_s3
-rw-r--r--    1 1000     1000           203 Aug 24 08:43 compose_file.yml
[lear@compose]$hyper volume ls
DRIVER              VOLUME NAME                                                       SIZE                CONTAINER
hyper               abb9dd9b5dcecb3e73ba3fb0d8311c25c5c404b9561a377a77b8987380c1b24   10 GB               8b2983a71fe7
hyper               9648f41c91d246095aa1da69e3853b2b1396144646424a3e0c389ddd7c06b62   10 GB               8b2983a71fe7
hyper               5df52d4d9d13e36ad7d7fbd4bddda33216c2a0644a55600430d2bb953e9dae6   10 GB               8b2983a71fe7
hyper               7ffa838e71a7fb01a23f433f299f947511665b5020d7ee39756bd350eaf7523   10 GB               8b2983a71fe7
[lear@compose]$hyper rm -f -v 8b2983a71fe7de509593f792d6affa3c6a2f40d6d2d9a5422c700a22f0b4710b
8b2983a71fe7de509593f792d6affa3c6a2f40d6d2d9a5422c700a22f0b4710b
[lear@compose]$hyper volume ls
DRIVER              VOLUME NAME         SIZE                CONTAINER
[lear@compose]$

cc @Jimmy-Xu

LGTM

authors: bergwolf carmark

repo: hyperhq/hypercli


text:
Error while running hyperctl info

@laijs I know this is an old issue but I ran into the same issue  I even posted on slack but so far not much help from there.. but I  get the same error when I run hyperctl info:
hyperctl ERROR: An error occurred trying to connect: Get http://%2Fvar%2Frun%2Fhyper.sock/v0.8.1/list?item=pod: dial unix /var/run/hyper.sock: connect: no such file or directory
and here is the log as you suggested:
Log file created at: 2017/06/24 20:57:49
Running on machine: localhost
Binary: Built with gc go1.8.3 for linux/amd64
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
I0624 20:57:49.122851 18247 config.go:38] config file: %!(EXTRA string=/etc/hyper/config)
I0624 20:57:49.123234 18247 config.go:72] [/etc/hyper/config] config items: &types.HyperConfig{ConfigFile:"/etc/hyper/config", Root:"/var/lib/hyper", Host:"", GRPCHost:"", StorageDriver:"", VmFactoryPolicy:"", Driver:"qemu", Kernel:"/var/lib/hyper/kernel", Initrd:"/var/lib/hyper/hyper-initrd.img", Bridge:"", BridgeIP:"", DisableIptables:false, EnableVsock:true, DefaultLog:"", DefaultLogOpt:map[string]string{}, logPrefix:"[/etc/hyper/config] "}
I0624 20:57:55.170355 18247 daemon.go:215] The hypervisor's driver is qemu
I0624 20:57:56.299793 18247 migration.go:23] Migrate lagecy persistent pod data, found: 0, migrated: 0
I0624 20:57:56.310088 18247 hyperd.go:189] Hyper daemon: 0.8.1 v0.4.0-912-g7a07c71
I0624 20:58:37.811799 18247 daemon.go:357] The daemon will be shutdown
I0624 20:58:37.811826 18247 daemon.go:358] Shutdown all VMs

Did the daemon shutdown by yourself or the OS? Try increase the hyperd log level with -v=4

No it is the OS

Then check what's the problem with OS. Based on the current logs, It's hard to judge what's the matter.

Actually I had to compile from source because I was unable to install using the bash script.. I am using Linux korora 25 but It's just Fedora 25 under the hood.. I mean:
uname -a
Linux localhost.localdomain 4.11.5-200.fc25.x86_64 #1 SMP Wed Jun 14 17:17:29 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Or is it a problem when using Fedora beacuse I also tried to install hyper on machine running project atomic/fedora25 but It complained saying it only supports Fedora 23..but i believe it is mentioned on github that fedora 25 is supported..

Build from source won't break anything and FC25 is supported as well.

As I mentioned in the first comment, try increase the log level, maybe we could found why it quit.

Thanks a lot @gnawux . It's now working!!
Here are the issues and steps I took in case someone else gets the same problem..

cd /etc/hyper  and uncomment  the Hypervisor line and assign a value accordingly(libvirt,kvm,qemu)
enable hyper daemon with systemctl enable hyperd
start hyper daemon with systemctl start hyperd
N.B: step 2 and 3 only apply if you are using systemd, for example ubuntu 14  is still on init so adjust accordingly..
systemctl status hyperd if you get running and enabled you are good to go
sudo hyperctl list works!!

Good to know it works. And the default hypervisor would be qemu if no one is specified, as shown in the log
I0624 20:57:55.170355 18247 daemon.go:215] The hypervisor's driver is qemu

Yeah, I see..well I guess you can close this one. next stop Hypernetes!!

Enjoy it 👍

authors: bruceherve gnawux

repo: hyperhq/hyperd


text:
Web: Add Hyperion logo and bigger colorpicker

1. Tell us something about your changes.
hyperion.css for own overwrites and css definitions
2. If this changes affect the .conf file. Please provide the changed section
3. Reference an issue (optional)

That's nice! :)

license: mit


text:
make mime partial eq to use in pattern match

error: to use a constant of type `Mime` in a pattern, `Mime` must be annotated with `#[derive(PartialEq, Eq)]`

error: to use a constant of type `Mime` in a pattern, `Mime` must be annotated with `#[derive(PartialEq, Eq)]`
   --> libs\sprout-hellosign\src\models.rs:345:13
    |
345 |             mime::APPLICATION_PDF => DownloadedFile::Pdf(file.content().to_owned()),

This issue still stands and prevents pattern matching on mime types:
if let Some(mime::IMAGE_JPEG | mime::IMAGE_PNG) = beresp.get_content_type() {
  // do stuff
}

This is resolved by #137.

authors: dzmitry-lahoda kailan

repo: hyperium/mime


text:
chore: Refactor convert Status to http::Response

Motivation
Refactors the implementation.
Solution
Refactors the procedure to convert Status to http::Response.

Thanks!

authors: djc tottoto

repo: hyperium/tonic


text:
feat: add controller interface and protocol wrappers

Signed-off-by: Tomisin Jenrola tomisin.jenrola@securekey.com
Title:
Created a controller interface and wrapper implementations.
Description:
There are restrictions on code that can be bound by gomobile. Hence, this change shows how we can create wrappers around each protocol's exported methods in Aries. A method from the Introduce protocol is included. The signatures of these wrapped methods are successfully parsed by gomobile. This can be tested by cloning this branch and running make bindings within the /cmd/aries-agent-mobile.
Closes #1923
Closes #1941
Part of #1958
Summary:

Relevant packages:

/cmd/aries-agent-mobile/api will contain interfaces that define agent operations.
/cmd/aries-agent-mobile/wrappers/command contains the implementation using the internal Aries framework.
/cmd/aries-agent-mobile/wrappers/rest contains the implementation that makes http requests to an external server.

Relevant Structs:

Aries: wrapped version of the actual Aries framework and a map of handler functions
AriesREST: contains a map of endpoints to delegate requests to
Introduce: wrapped introduce command
IntroduceREST: http client that is modelled after the introduce operation in /pkg/controller/rest/introduce

@ToJen

This can be tested by cloning this branch and running make bindings within the /cmd/aries-agent-mobile.

llorllale:~/dev/hyperledger/aries-framework-go/cmd/aries-agent-mobile$ make bindings
----------------------------------------
   gomobile: Creating Android bindings
----------------------------------------
gomobile bind -v -target=android -javapkg=com.hyperledger.aries -o=/home/llorllale/dev/hyperledger/aries-framework-go/cmd/aries-agent-mobile/build/android/aries-agent.aar github.com/hyperledger/aries-framework-go/cmd/aries-agent-mobile/ github.com/hyperledger/aries-framework-go/cmd/aries-agent-mobile/pkg/api github.com/hyperledger/aries-framework-go/cmd/aries-agent-mobile/pkg/wrappers github.com/hyperledger/aries-framework-go/cmd/aries-agent-mobile/pkg/wrappers/command github.com/hyperledger/aries-framework-go/cmd/aries-agent-mobile/pkg/wrappers/rest
gomobile: no Android NDK found in $ANDROID_HOME/ndk-bundle nor in $ANDROID_NDK_HOME
Makefile:72: recipe for target 'bindings-android' failed
make: *** [bindings-android] Error 1

Can the README be updated to describe how/where exactly to install the dependencies?

What we want to know are the following:

should there be only one library containing implementations for the local and remote agent?
how much latency would be experienced on a mobile app if the remote agent is written in go?

@llorllale
here's the update for the discussion. What I did was to test a simple GET request by

calling goFunction1 which is written in go and receives a URL and N, the number of times to call that URL
calling goFunction2 which is written in go and receives just a URL, i called this N times from objective-c
calling iOSFunction which is written in objective-c and takes a url and calls it N times

how much latency would be experienced on a mobile app if the remote agent is written in go?

N=10
res: [goFunction1] url:http://www.google.com N:10 seconds:4.579783
res: [goFunction2] url:http://www.google.com N:10 seconds:4.766893
res: [iOSFunction] url:http://www.google.com N:10 seconds:4.703360

N=50
res: [goFunction1] url:http://www.google.com N:50 seconds:25.057063
res: [goFunction2] url:http://www.google.com N:50 seconds:24.392210
res: [iOSFunction] url:http://www.google.com N:50 seconds:23.741404

There's barely any noticeable difference

should there be only one library containing implementations for the local and remote agent?

Based on the results, we should write the api, local agent and remote agent in golang and produce a single .framework file

I got make bindings-android to work on Ubuntu 18.04. Cannot confirm with bindings-ios.
I noted that make bindings-android takes a LONG time:
$ time make bindings-android
... lots and lots of stuff...
real    0m59.528s
user    2m49.010s
sys     0m20.962s

I also noted the "Command line tools" - you really do need to download the IDE package.

authors: ToJen llorllale

repo: hyperledger/aries-framework-go


text:
RFC 302: Non-interactive protocols should not be in AIP v1.0

We have concerns with the non-interactive protocols included in Aries Interop Profile v. 1.0. They could be used to undermine a user's privacy, and so they need more work before they can be included in an interopability profile.
Most protocols in the interop profile require user interaction to transmit data, but a few could trigger a response without any user interaction:

Trust Ping
Feature Discovery
Problem Report

These are important dev tools which we need in our ecosystem, but automatically responding to these requests could compromise the privacy of end users. We need to put more thought into the implications of these protocols on user interaction.
Some examples of the type of thinking these protocols still need:

How often does an agent need to respond to these requests?
How should a user be informed about these responses?
Can a mediator like a cloud agent act on behalf of an edge agent to respond to these requests?

We would like to remove these protocols from the profile, and we will drive separate discussions for improving the RFCs that define these protocols.

AIP 1.0.0 is to be used in the next few months and be replaced by new AIP versions referencing improved protocols as they are defined. I agree that unfettered use of those protocols could be a problem in the long term. However, their use in the short term is not (in my opinion) a significant risk, particularly in the limited use cases that will be deployed in the next few months. Mind you, if we don't get AIP defined and implemented, all PoCs will only be with pre-defined components vs. arbitrary implementations.
I suggest that your team work on RFCs to improve them to address the privacy concerns.  That is a separate issue from inclusion or exclusion from AIP 1.0.0.
Other thoughts:

there is nothing to prevent an interaction based on the receipt of those requests. If you you are worried - ask the user before responding.
While I think I can guess why Problem Report is included (responding to an unsolicited bad request - for which you could create an interaction), the inability to use Problem Report in valid situations will likely be, well, a problem.
Feature discovery can return whatever you want, including nothing, or maybe just "Feature Discovery".  That's in the protocol today.  However in the early days of agents, it will likely be helpful for interoperability, even if we remove it in the future.

I vote we do not remove those from AIP 1.0.0.

Responses:

AIP 1.0.0 is meaningless if it is only appropriate for "limited use cases". Aries verifiable credentials are already being used in important production scenarios.
AIP 1.0.0 will be an important milestone for much longer than a few months. If it is adopted in the real world (as we intend), we will need to maintain compatibility with the profile for some time to come.
We will work on the RFCs to improve them to address privacy concerns, but we will not be adopting AIP 1.0.0 if they are included in their current form.
Asking a non-technical user if they want to approve a "Trust Ping" is not a good idea. Let alone a "Feature Discovery" request.
We don't feel as strongly about Problem Report, but included it for completeness.
We agree that all of these protocols are important in development scenarios, but they need to be refined before requiring support for them in agents.
Nothing prevents agents from implementing any of the Aries RFCs not included in the interoperability profile. We just can't depend on the existence of those RFCs in all compatible agents.

Responses back :-)

By "limited use case" I mean that in practice, we will only have a limited number of use cases (and users) in the next six months. Those cases will be real, and will only be limited by what business are willing to try. That in turns means that we don't have to be absolutely perfect.
AIP 1.0.0 should not last longer than a few months. Or at least we hope it does not.  We want to see improvements to the protocols, new protocols to be added, and the community update mechanism to be used to enable continuous interop.
It will be unfortunate if there is a split in the community on this because one member overrules the others.  But we need others to weigh in.
I agree about a user being notified about such requests, and I wouldn't necessarily take that approach. However, if an app maker is particularly concerned that in the next six months, users will be harmed by unsolicited messages, that becomes an option. As does silently not responding or responding in a limited fashion (in the case of Feature Discovery).

Again, I strongly support providing input to the RFCs that (I think) should be helpful in defining AIP 1.1.0.
Thanks

I don't understand the concern about "a split in the community on this because one member overrules the others". Exercises like this issue are how we achieve consensus together.
These RFCs are important for developer use cases, but I don't think they are required for credential exchange in the wild, which is the stated target of this Interop Profile. I think the quickest path to seeing that Interop Profile adopted and implemented is to keep the scope narrow. But I agree that an alternative approach is to wait on the Interop Profile until we are happy with the contents of the included RFCs.

I don't have much of an opinion from an implementer's perspective, but I'll toss my NZD $.2 in from an attacker perspective, so take it with as much value as the currency exchange rate allows 😄
With regards to the problem report, I find this one to be the most problematic because it's likely to be the one that reveals the most information that allows an attacker to blackbox attack the agent. In my experience penetration testing, this was always extremely valuable insights to get if we could and it was usually an indication that someone left debugging mode on. The main reason we saw this as insightful was so we could easily identify vulnerabilities in unpatched software.
Now I understand the value in providing useful problem reports and am not requesting that we remove them completely. Rather, I think there should be a more standardised approach to the types of errors that are returned in order to handle both the privacy concerns and reconnaissance concerns. In my opinion, this should be moved to something like HTTP codes where there's a standard set of return errors possible. Then if additional information is necessary in debugging mode, it can be returned as additional data inside the error.

@swcurran: I think the mental divide here isn't about one vendor or another; it's about the enterprise mindset (where automation is king) vs. the consumer mindset (where UX is king). EV has no problem responding to trust pings and feature discovery in an enterprise agent. Prompting app users who know nothing about the underlying plumbing/context is not good UX, plain and simple. Neither is automatically responding (because it's potentially unsafe). Knowing what to do for consumer apps is just simply a much harder problem for a consumer tool than it is in the enterprise.
@Richard: a way around this awkwardness in AIP's handling of consumer concerns might be to implement only the pinger (not pingee) role for trust ping, and only the requester (not responder) role for feature discovery, in Connect.Me. This would allow C.M to check some boxes without solving the much harder problem of how to confer with a user about correct behavior. Or we could implement the rest of the AIP and leave these unimplemented as footnoted exceptions.

Discussed during Aries WG B on 2020-01-08.
We agreed to exclude from AIP 1.0 Trust Ping and Feature Discovery, because they are not critical for interoperability. But we will include Problem Report even with the potential privacy concerns because it is so important for validating that we have meaningful interoperability. Agents will need to decide how best to provide reports in a way that best protects their users.

A point on the privacy concerns. It needs to be understood that there are only two ways for these messages to get to the user:

An entity that has established a connection to the recipient can send these unsolicited messages.
An out of band message such as we use for invitations or ephemeral challenges via either URLs or QR codes. I would argue that any mobile agent that silently handles such messages is not worth using.

For the first case, I think it would actually be very easy for a mobile app to provide a configuration and a notification of potential abuse - including an indicator of the abusing service.
In thinking about that I'm even more against dropping the protocols from the AIP.  I don't see any reason to drop them, since the security/privacy risk is both unlikely, configurable and easily detectable.
But I can live with it...

While I hesitate to suggest that we get more nuanced on AIP I see one way we might do that in the future.  We use the enumerate list of agent types (the RFC lists 5 types), add a column for each to the RFC table, and add an indicator per type of agent that doesn't fully support a specific protocol. This would solve this issue.
I don't think that we should do that yet (extra complexity), but something to keep in mind if we have more challenges with this.
If we do this, we'd have to agree on a very constrained set of agent types (ideally, less than 5) and be ignore edge cases.

there are only two ways for these messages to get to the user:

Way 3: an agency can forward an anoncrypted message that contains a ~service decorator. That's not out-of-band, and it's also not using an existing connection. This is exactly how I would send spam in DIDComm land, if I got hold of someone's private DID.

I think it would actually be very easy for a mobile app to provide a configuration and a notification of potential abuse - including an indicator of the abusing service.

I agree that It's easy to write one with a lousy UX (where config = all or nothing). Not so easy to detect abuse patterns and alert the user only when they "ought" to be interested. And very hard to explain the dynamics to a naive user so they can make intelligent config decisions.

any mobile agent that silently handles such messages is not worth using :-).

There's a difference between decisions to silently ignore (which a mobile agent worth its salt might do) and decisions to silently cooperate (which no safe mobile agent should be doing). Maybe you were only alluding to the second one.

the security/privacy risk is both unlikely, configurable and easily detectable.

unlikely: I agree today, but disagree in the long run (ping existed for a long time before network admins started turning it off as a source of abuse)
configurable: I disagree that this is trivially easy. What makes it hard is not the code you write, but how you explain to a naive user what they're configuring in a way that helps them make a good decision. Writing a dialog that asks users whether they want to accept unrecognized certs in a browser was easy; trying to unwind the consequences from millions of bad decisions has given browser manufacturers fits for a decade.
easily detectable: given that a single message could constitute the very privacy issue we're talking about (it doesn't have to be a recurring pattern), I don't see how "easily detectable" is true.
Anyway, I can live with the compromise, too, so we can make progress where we agree, and keep debating these issues elsewhere.

The Way 3 method assumes that some sort of breach has already occurred - a bad actor has a private DID that they shouldn't have.  Even then, I think that can be mitigated with specific handling of such a message.  For example, ignoring the ~service decorator if you have a connection already.  As well, see below.
As to the lousy UX. Yes, it might be lousy for now, but if you can build a perfect UI up front, you are either a unicorn or moving too slowly.  Start with a "lousy" UX that is sufficient for now (have a default you can live with, and an explanation that is best you can do) and move forward. As well, see below.
Easily detectable. I would disagree with your level of concern over what is today very much an edge case (a malicious user exploiting this). As well, see below.
The below :-).  UX and mobile agents are iterated over continually. It won't be perfect today (or even tomorrow), it just has to be easily updateable to become continually better.  This gets back to the debate of AIP 1.0.0 lasting forever, I realize.  I just don't agree with that idea.
All of this is gray areas, so we will not likely agree.  I would really like to see the updates to the RFCs so that we can use them. Trust Ping I'm less concerned about if we can replace it where it is being used today (confirmation of a connection).
I'm still fine with the compromise and agree we can discuss elsewhere.

To offer a bit of nuance to why I was arguing that AIP 1.0.0 will last forever I want to put the numbers I've been looking at out there so everyone gets where I'm coming from:
First off let's look at SSL/TLS
SSL 1.0 was never officially published, according to Wikipedia and as such shows no adoption today - See the protocol support graph.
However, SSL 2.0 a protocol that was published in 1995 and Deprecated in 2011 and SSL 3.0 which was published in 1996 and deprecated in 2015 still account for 7.6% of website support(refer to adoption link above). This is not to say a website only supports this, but rather that they've chosen to not turn it off even though the two protocols have been deprecated for years now.
Additionally TLS 1.0 and 1.1 will likely encounter similar issues with deprecation planned to occur this year.
IPV4 is another perfect example of this. While IPv4 has been shown to have cracks in the foundation of number of namespaces available, but do to the fact that many people running IPv4 today can meet their needs we've yet to see broad adoption of IPv6, which has had alpha quality code in the Linux kernel since 1996.
Furthermore, adoption of IPv6 has been incredibly slow because there's been little justifiable reason for the complexity brought by the transition plan.
A third example of this is the comparison between telnet and SSH. Telnet dates back to 1969, well before my time, and was considered deprecated long ago. However, even though telnet is largely deprecated at this point, support has not been fully removed because we still have legacy systems where this is the only way to communicate with them.
So my point around this is not to say "forever" actually means forever (aka 20+ years), but it is to say that it will be around and in use longer than any of us plan to maintain and patch code for it's support. This is why I'm cautious of the requirements we are setting as absolutes and what is supported but not a requirement. It's purely because throughout the internet's history we've seen protocols linger well past their lifetimes and this will likely lead to implications on how long we have to maintain and patch EoL codebases when we'd rather be working on the current and future stuff. Hopefully this explains why I'm arguing that the problem reports should be thought through and taken to a semi mature phase (I've not formed an opinion on what that means in this case yet) before we declare AIP 1.0 set.

authors: dhh1128 esplinr kdenhartog swcurran

repo: hyperledger/aries-rfcs


text:
rebase tcs_workorder_receipt_handler on json-rpc

this is the final part following PR #106
replace the manually unwrapping requests and wrapping response with json-rpc

Signed-off-by: lixiangmin01 lixiangmin01@baidu.com

One minor comment in tcs_workorder_receipt_handler.py
I assume the deleted `workorder_receipt_handler() functionality was added in a previous PR

workorder_receipt_handler() is not added by me~

@sammyne

workorder_receipt_handler() is not added by me~ @danintel
I know it is not added by you--you are deleting it from file tcs_workorder_receipt_handler.py

Why is workorder_receipt_handler() no longer needed?

@sammyne

workorder_receipt_handler() is not added by me~ @danintel
I know it is not added by you--you are deleting it from file tcs_workorder_receipt_handler.py

Why is workorder_receipt_handler() no longer needed?

workorder_receipt_handler() is responsible for routing requests to specific handlers, and this job is now placed on the  JSON-RPC Dispatcher in the TCSListener @danintel

@sammyne I have added full fledged work order receipt APIs in my PR#162. Can you please review it. I have added request validation in the receipt APIs. If you think PR#162 is good then you can close your PR.

@sammyne I have added full fledged work order receipt APIs in my PR#162. Can you please review it. I have added request validation in the receipt APIs. If you think PR#162 is good then you can close your PR.

Nice work 😄 @Ram-srini

Link to PR #162 Work order receipt APIs implementation for direct model

authors: Ram-srini danintel sammyne

repo: hyperledger/avalon


text:
automate the docker verification steps

currently we run these checks manually after the release
we can automate these

New GitHub workflow will be added which can be triggered with workflow_dispatch. This workflow starts the containers and verify Besu application log "Ethereum main loop is up" present in started container. If the container log contains the string it will mark as the test pass.
For the latest tag, workflow will verify whether version specified in the Besu log matches the version passed.
docker run hyperledger/besu:<version>
docker run hyperledger/besu:<version>-arm64
docker run --platform linux/amd64 hyperledger/besu:<version>-amd64
docker run --pull=always hyperledger/besu:latest (check version is )

During a release, above workflow will be triggered at the end of the docker image publish. Docker image testing is de-coupled from the release but triggered as part of the release process.

authors: cdivitotawela macfarla

repo: hyperledger/besu


text:
22.10.1 alpha

PR description
alpha build for burn in ahead of 22.10.1 release.
This PR:

merges main from e7074c0ecb582b50055c1928da85a2e79e9f97ba into release-22.10.x
sets gradle.properties version to 22.10.1-alpha

To be clear, the policy of releasing patches off of main hasn't changed, right?

To be clear, the policy of releasing double-dot releases off of main hasn't changed, right?

Not yet.  I think we should move to a release process that is better tested, but doing these burn-ins at least can help us gain confidence ahead of a release from main.

We used to cut the release, keep it quiet, run out syncs and burn-ins, then announce or squelch the release based on results.

authors: garyschulte shemnon


text:
Chan.Part.API: config-tracker IT flake fix

Type of change

Bug fix
Test update

Description
Ensure a raft leader has been elected and the channel is active after restarting the orderers by submitting a transaction until
it succeeds. This ensures the config update to remove the orderer from the consenter set does not fail.
Related issues
FAB-18305

Opened snapshot IT flake FAB-18307

repo: hyperledger/fabric