checkpoints/new_tunedvae

Thank you for sharing nice code and research!!!
I just would like to know more detail.
When I checked diffste.ckpt, It seem to use tunned vae 'vae': {'normalizer': 0.21966682713, 'pretrained_model_path': 'checkpoints/new_tunedvae'} not original vae from stable diffusion.
Could you share tunned vae??
Actually When I trained it from scratch with training data, Accuacy was much worse than diffste.ckpt.
Could you share some hint??I should use tunned vae???
Config file in diffste.ckpt :
{'source': 'raw', 'target': 'trainers.CharInpaintModelWrapper', 'pretrained_model_path': 'runwayml/stable-diffusion-inpainting', 'loss_type': 'MaskMSELoss', 'loss_alpha': 5, 'base_learning_rate': 5e-05, 'precision': 16, 'weight_decay': 0.0, 'adam_epsilon': 1e-08, 'freeze_char_embedder': False, 'optimize_vae': False, 'vae': {'normalizer': 0.21966682713, 'pretrained_model_path': 'checkpoints/new_tunedvae'}, 'tokenizer': {'model_max_length': 20}, 'char_tokenizer': {'pretrained_path': 'checkpoints/chartokenizer', 'pad_token': ' ', 'unk_token': ' ', 'model_max_length': 20}, 'char_embedder': {'vocab_size': 95, 'embedding_dim': 32, 'max_length': 20, 'padding_idx': 0, 'attention_head_dim': 2}, 'unet': {'attention_head_dim': {'text': 8, 'char': 2}, 'cross_attention_dim': {'text': 768, 'char': 32}}, 'noise_scheduler': 'diffusers.DDIMScheduler', 'ckpt_dir': 'logs/chardiffusion/2023-02-17T21-17-30_alldata/checkpoints'}

Thank you for your interest in our work.
The tuned VAE is actually included in the released checkpoint. You can access it using model.vae and save its weights using model.vae.save_pretrained("save_path").
If training from the original VAE doesn't yield satisfactory results, I think it's definitely worthwhile to fine-tune the VAE on your data.

Thank you for kindly explanation.
But I should load diffste ckpt model first with CharInpaintTrainer Class to model.vae.save_pretrained("save_path").
=> model = CharInpaintTrainer(config=config)
When I load CharInpaintTrainer Class, vae is loaded from runwayml/stable-diffusion-inpainting because there is no fintunned vae like below code.
print("There is no vae from finetunned.  So loaded original vae from runwayml/stable-diffusion-inpainting")
So original vae was saved with model.vae.save_pretrained("save_path").
class CharInpaintTrainer(pl.LightningModule):
def init(self, config):
super().init()
self.save_hyperparameters()
self.config = config
    FIXED_COMMIT_ID = FIXED_COMMIT_IDS.get(
        config.pretrained_model_path, None)
    pretrained_model_path = config.pretrained_model_path
    if self.config.vae is not None and self.config.vae.get(
        "pretrained_model_path", False
    ):
        print("Initialize vae from finetuned...")
        if os.path.exists(self.config.vae.get("pretrained_model_path")):
            self.vae = AutoencoderKL.from_pretrained(
                self.config.vae.get("pretrained_model_path"),
            )
        else:
            print("There is no vae from finetunned. So loaded original vae from runwayml/stable-diffusion-inpainting")
            self.vae = AutoencoderKL.from_pretrained(
                pretrained_model_path,
                subfolder="vae",
                revision=FIXED_COMMIT_ID,
            )
        self.NORMALIZER = self.config.vae.get("normalizer", 0.18215)
    else:
        print("Initialize vae from pretrained...")
        self.vae = AutoencoderKL.from_pretrained(
            pretrained_model_path,
            subfolder="vae",
            revision=FIXED_COMMIT_ID,
        )
        self.NORMALIZER = 0.18215  # original normalizer

This is correct. When you run CharInpaintTrainer.load_from_checkpoint(ckpt_path), a new CharInpaintTrainer object is created with randomly initialized weights, then the real model weights from ckpt_path will be replaced into the new model. I hope it helps.


Zone:_partTouchedZone(part) is not used

I was looking through the code for partExited and partEntered and I found that Zone:_partTouchedZone(part) was not used. Is the feature still a work in progress?

It's used for line 272:
https://i.imgur.com/opfLKx4.png
We've designed it this way to make it scalable for player events once .CanTouch goes live (and proves to be effective).


fix: should not dial bind addr directly

When server returns an any ip (<IP_ADDRESS> or [::]), we should use conventional ip to replace the any ip given (<IP_ADDRESS> or [::]). This behaviour adapts to most situations.
See v2fly/v2ray-core#523

Problem happens when socks5 proxy works on remote servers and different implementation will given different bind addr.
For most situations it is issues of servers. However, clients should behave normally in one case that returned bind addr is an ANYIP (<IP_ADDRESS> or [::]), which indicate that we should use a conventional remote address to connect.
RFC does not illustrate the mechanism of bind addr; it is based on experience.

First of all, thanks for your PR, and I read the rfc again.

RFC does not illustrate the mechanism of bind addr;

rfc1928, part 6:
In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR
fields indicate the port number/address where the client MUST send
UDP request messages to be relayed.

RFC has clarified BND.PORT and BND.ADDR.
So, I think we should not assume some non-standard behavior,

if a server does not support UDP, it MUST tell client through METHOD
if a server supports UDP, it MUST send a reply which described in rfc1928 to client

I support your point of not being clear about the part of rfc1928, but this issue BND.PORT and BND.ADDR, it is clear.
So if a server is not implemented correctly, we should submit an issue to it.
Thank you again.

First of all, thanks for your PR, and I read the rfc again.

RFC does not illustrate the mechanism of bind addr;

rfc1928, part 6:
In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR
fields indicate the port number/address where the client MUST send
UDP request messages to be relayed.

RFC has clarified BND.PORT and BND.ADDR.
So, I think we should not assume some non-standard behavior,

if a server does not support UDP, it MUST tell client through METHOD
if a server supports UDP, it MUST send a reply which described in rfc1928 to client

I support your point of not being clear about the part of rfc1928, but this issue BND.PORT and BND.ADDR, it is clear.
So if a server is not implemented correctly, we should submit an issue to it.
Thank you again.

The problem is that in some NAT situation, the server may can not confirm a solid outer IP. Thus, the server may expect the client to connect the address the same as TCP's.

The problem is that in some NAT situation, the server may can not confirm a solid outer IP. Thus, the server may expect the client to connect the address the same as TCP's.

There are many situations about UDP server address(IP:PORT) to process UDP request:

Same UDP IP with TCP IP and same UDP PORT with TCP PORT
Same UDP IP with TCP IP and random UDP PORT(port-range)
Different UDP IP(usually another independent machine) with TCP IP and random UDP PORT(port-range)

So MAY is not better, because MAY is a guess, not a guarantee. I think this is why RFC let server tell client its UDP IP:PORT
For guarantee, the only the server know what it will do, what it want to do, this mean we should let human config its server, here is a example project about UDP case:
https://github.com/coturn/coturn/blob/8dc5bbcb3b7f2ef561293df8b920cb21b0eaf081/examples/etc/turnserver.conf#L108

There are many situations about UDP server address(IP:PORT) to process UDP request:

Same UDP IP with TCP IP and same UDP PORT with TCP PORT
Same UDP IP with TCP IP and random UDP PORT(port-range)
Different UDP IP(usually another independent machine) with TCP IP and random UDP PORT(port-range)

So MAY is not better, because MAY is a guess, not a guarantee. I think this is why RFC let server tell client its UDP IP:PORT
For guarantee, the only the server know what it will do, what it want to do, this mean we should let human config its server, here is a example project about UDP case:
https://github.com/coturn/coturn/blob/8dc5bbcb3b7f2ef561293df8b920cb21b0eaf081/examples/etc/turnserver.conf#L108

RFC has clarified BND.PORT and BND.ADDR.

In reality, the use case of SOCKS5 as a means of communication between censorship circumvention tools can make it difficult to determine the actual BND.ADDR and/or BND.PORT. For example, the SOCKS5 server may be behind a NAT with a dynamic IP address.

So if a server is not implemented correctly, we should submit an issue to it.

That would mean we have to change the behavior of UdpAssociate response on all these SOCKS5 servers:

V2Ray before v2fly/v2ray-core#523: Returns the configured client IP, or <IP_ADDRESS> if unconfigured.
V2Ray after v2fly/v2ray-core#523: Returns the configured client IP. If unconfigured, returns loopback IP for local clients, or listening address for non-local clients.
Trojan-Go, shadowsocks-rust, shadowsocks-windows return the listening address.
Clash returns the local address of the connection that sent the UdpAssociate command.

You can't possibly change them all. "Fixing" the behavior would also make it more difficult to configure the SOCKS5 server. Standard compliance is important. But it's even more important to make sure the protocol actually works well under the desired use cases.
The Internet Area Working Group also acknowledged the widespread use of SOCKS5 among censorship circumvention tools in the SOCKS6 draft. So my opinion is that we should be flexible in this case and accept the widespread use of :: and <IP_ADDRESS> as the BND.ADDR.

RFC has clarified BND.PORT and BND.ADDR.

In reality, the use case of SOCKS5 as a means of communication between censorship circumvention tools can make it difficult to determine the actual BND.ADDR and/or BND.PORT. For example, the SOCKS5 server may be behind a NAT with a dynamic IP address.

So if a server is not implemented correctly, we should submit an issue to it.

That would mean we have to change the behavior of UdpAssociate response on all these SOCKS5 servers:

V2Ray before v2fly/v2ray-core#523: Returns the configured client IP, or <IP_ADDRESS> if unconfigured.
V2Ray after v2fly/v2ray-core#523: Returns the configured client IP. If unconfigured, returns loopback IP for local clients, or listening address for non-local clients.
Trojan-Go, shadowsocks-rust, shadowsocks-windows return the listening address.
Clash returns the local address of the connection that sent the UdpAssociate command.

You can't possibly change them all. "Fixing" the behavior would also make it more difficult to configure the SOCKS5 server. Standard compliance is important. But it's even more important to make sure the protocol actually works well under the desired use cases.
The Internet Area Working Group also acknowledged the widespread use of SOCKS5 among censorship circumvention tools in the SOCKS6 draft. So my opinion is that we should be flexible in this case and accept the widespread use of :: and <IP_ADDRESS> as the BND.ADDR.

There are many situations about UDP server address(IP:PORT) to process UDP request:

NAT server exactly know the port but may not know the IP address, so if it reply <IP_ADDRESS> with the port specified the client will know the thing.

There are many situations about UDP server address(IP:PORT) to process UDP request:

NAT server exactly know the port but may not know the IP address, so if it reply <IP_ADDRESS> with the port specified the client will know the thing.

Because this is not a standard, so I added a hijack func HijackServerUDPAddr into  Client

Because this is not a standard, so I added a hijack func HijackServerUDPAddr into  Client


Fixes spelling

Description
Fixes spelling in comment. Left over from #14144
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[x] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

@ChaiBapchya here's the fix. Sorry about that.

Looks like a random crash, restart the test to see if it is reproducible

@perdasilva Thanks for your contribution!
@mxnet-label-bot add [pr-awaiting-review]


Fix install init container

For issued #65
Need to test first

need to stop running in restricted scc...going to start over


time.Duration should implement encoding.TextMarshaler

time.Time implements all of the marshaler and unmarshaler interfaces, but time.Duration implements none of these.
I came across a case today where it would have been very convenient if time.Duration had already implemented encoding.TextMarshaler and encoding.TextUnmarshaler.
Would you accept a contribution that added implementations for these interfaces?

Would you accept a contribution that added implementations for these interfaces?
Not until Go2.

Duplicate of #10275.

Closing as duplicate.


NodeJS Wrapper error native function rs2_pipeline_start

Required Info

Camera Model
{ D415 }

Firmware Version
(<IP_ADDRESS>)

Operating System & Version
{Linux (Ubuntu 20.04.3 LTS)

Kernel Version (Linux Only)
(5.4.0-90-generic)

Platform
PC

SDK Version
{ 2.50 }

Language
{nodejs }

Segment
{Robot }

Issue Description
I built the RealSense library with the NodeJS wrapper. NodeJS is currently on version v10.24.1. I'm able to run the NodeJS examples like nodejs-capture.js in librealsense/wrappers/nodejs/examples. RealSense-Viewer works perfectly as well. However when I try to use the library in my node-red project (Code below), I receive the following error:
[realsense-node:dc353c6914411109] Error: Unrecoverable! error native function rs2_pipeline_start: set_xu(...). xioctl(UVCIOC_CTRL_QUERY) failed Last Error: Inappropriate ioctl for device

My code:
// initialize the features
const rs2 = require('node-librealsense');
const pipeline = new rs2.Pipeline(); //main work pipeline of realsense camera
pipeline.start(); //start camera

Any suggestions what could be wrong?

Hi @phixxx5  Do you experience the same error if you try the full starter script at the link below, please?
https://github.com/IntelRealSense/librealsense/tree/master/wrappers/nodejs/scripts/npm_dist#nodejs-api-for-intel-realsense-depth-cameras

With the starter script I do not experience the error.

The lines of your node-red code are the same as the initial lines of the starter script (aside from the absent const colorizer = new rs2.Colorizer(); line), which suggests to me that one of the missing lines may be triggering your error.
A way to test this theory would be to remove lines from the starter script and run it until it replicates the error in node-red.  Removing the final line rs2.cleanup(); would be a good place to begin.

Hi @phixxx5  Do you require further assistance with this case, please?  Thanks!

Hi,
I was able to solve the problem. The librealsense wrapper that I built from source was not imported but instead the one from here was imported (https://www.npmjs.com/package/node-librealsense). I copied the folder with the nodejs wrapper to my node-red project and then imported it through const rs2 = require('./lib/node-librealsense/index.js');
Thanks for your help :)

You're very wecome, @phixxx5  - thanks for sharing your solution with the RealSense community!

Case closed due to solution achieved and no further comments received.


Flash serve on Object Detection task

Discussed in https://github.com/PyTorchLightning/lightning-flash/discussions/1277

Originally posted by IncubatorShokuhou April  7, 2022
Is there an exampe on serving an object detection model in lightning-flash?

I would also be interested in this... Currently I'm using an awful hack where I write images (received as bas64) to disk and then read them using ObjectDetectionData.from_files https://github.com/Greenroom-Robotics/nuclio_lighting_flash/blob/main/nuclio_lighting_flash/flash_model_handler.py#L27
In addition to the model.serve it would be nice to have something like ObjectDetectionData.from_image which accepted pil images.


New Ingress controller issues

[x] Split feature is broken(need to verify)
[x] The QPS chart is not smooth. (Not critical. Issue understood, fix is on the way)
[ ] Engine metrics can be confusing between the runs because now the engine ids are the same across runs. [won't do as this is the same as before]

Tenant reports that the first issue could not be reproduced in the fixed version. So will mark it as closed.


Can we add compression configuration for functionColumnPairs to StartreeIndexConfigs?

I notice right now the Startree builder will not use any compression for metric columns. There is also no way to configure it, while in non-startree, you can do so via noDictionaryConfig field in the table config.
I would like the ability to configure this for startree because when a functionColumnPairs has a output type of bytes, such as when you use distinctcountrawhll, the size is big.  For example, my test segment goes from 77 mb -> 3.3 GB if I add a startree, and it's because the bytes field output of that functionColumnPair is not compressed. In this case, I want the compression but right now there is no way to configure it

Hey I'm interested in this too. Did anyone look into this? It would be a game changer for us.

@priyen Have you started working on this? @t0mpere is volunteering to work on this

we haven't prioritized work on this. Internally, we've changed this to always lz4 compress any byte columns. @t0mpere, feel free to take!

I'll prioritise this with my team. Probably picking it up in the upcoming weeks.


Failed to build gem native extension

When i try to install nokogiri, this error occur and remain this messages..
What can i do to solve this error?

ERROR:  Error installing nokogiri:
ERROR: Failed to build gem native extension.
current directory: /Users/seojonghyeon/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/nokogiri-<IP_ADDRESS>/ext/nokogiri

/Users/seojonghyeon/.rbenv/versions/2.3.1/bin/ruby -r ./siteconf20161108-21048-24v7fv.rb extconf.rb
checking if the C compiler accepts ... *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.
Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/Users/seojonghyeon/.rbenv/versions/2.3.1/bin/$(RUBY_BASE_NAME)
--help
--clean
/Users/seojonghyeon/.rbenv/versions/2.3.1/lib/ruby/2.3.0/mkmf.rb:456:in try_do': The compiler failed to generate an executable file. (RuntimeError) You have to install development tools first. 	from /Users/seojonghyeon/.rbenv/versions/2.3.1/lib/ruby/2.3.0/mkmf.rb:571:in block in try_compile'
from /Users/seojonghyeon/.rbenv/versions/2.3.1/lib/ruby/2.3.0/mkmf.rb:522:in with_werror' 	from /Users/seojonghyeon/.rbenv/versions/2.3.1/lib/ruby/2.3.0/mkmf.rb:571:in try_compile'
from extconf.rb:139:in nokogiri_try_compile' 	from extconf.rb:163:in block in add_cflags'
from /Users/seojonghyeon/.rbenv/versions/2.3.1/lib/ruby/2.3.0/mkmf.rb:629:in with_cflags' 	from extconf.rb:162:in add_cflags'
from extconf.rb:415:in `'
To see why this extension failed to compile, please check the mkmf.log which can be found here:
/Users/seojonghyeon/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/extensions/x86_64-darwin-15/2.3.0-static/nokogiri-<IP_ADDRESS>/mkmf.log
extconf failed, exit code 1
Gem files will remain installed in /Users/seojonghyeon/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/nokogiri-<IP_ADDRESS> for inspection.
Results logged to /Users/seojonghyeon/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/extensions/x86_64-darwin-15/2.3.0-static/nokogiri-<IP_ADDRESS>/gem_make.out

When you can created this issue, there was an issue template in the text box that you ignored and deleted, but which would have helped you either diagnose the issue yourself or else prompted you for enough information that someone could help you.
Closing. If you open a new issue, please follow the template instructions.


Difficulty Encountered While Fine-Tuning Model on Breakfast Dataset and Questions About Folder Structure

Thank you for developing such an inspiring model. However, while attempting the Video Understanding task on the breakfast dataset, I encountered a specific issue.
I adjusted the PREFIX and DATA_PATH in exp/breakfast/videomamba_middle_mask/run_f32x224.sh to match my local breakfast dataset file paths (downloaded from here) and executed bash ./exp/breakfast/videomamba_middle_mask/run_f32x224.sh. Unfortunately, it resulted in the following error:
srun: error: invalid partition specified: video5
srun: error: Unable to allocate resources: Invalid partition name specified

I suspect there might be an issue with the file or directory format. Could you please provide more details regarding the video data, particularly for the breakfast dataset, and clarify the location for placing the weight files? Your assistance would be greatly appreciated!

Hi! Our scripts use srun to start the training.  I have this piece of code, and I simply followed the instructions in the GitHub documentation to change PREFIX and DATA_PATH to my own data path because I wasn't sure how to proceed. Here it is:
PREFIX='/home/simslab-n/Downloads/BreakfastII_15fps_qvga_sync'
DATA_PATH='/home/simslab-n/Downloads/BreakfastII_15fps_qvga_sync'

Thanks again for your assistance.

The PREFIX is used to set your data path, like what you did. The DATA_PATH is used to set your annotation path, and I have uploaded it here.

Hi there,
Thank you so much for the assistance you provided earlier. I've been trying for the past few days and indeed managed to resolve the previous issue. However, I've run into some difficulties again during execution, and here's the error code:
optimizer settings: {'lr': 3.125e-06, 'weight_decay': 0.0, 'eps': 1e-08, 'betas': [0.9, 0.999]}
Use bf16: True
Use step level LR scheduler!
Set warmup steps = 3945
Set warmup steps = 0
Max WD = 0.1000000, Min WD = 0.1000000
criterion = SoftTargetCrossEntropy()
Auto resume checkpoint:
Start training for 10 epochs
Traceback (most recent call last):
  File "/home/simslab-n/Desktop/VideoMamba/videomamba/video_sm/run_class_finetuning.py", line 713, in <module>
    main(opts, ds_init)
  File "/home/simslab-n/Desktop/VideoMamba/videomamba/video_sm/run_class_finetuning.py", line 630, in main
    train_stats = train_one_epoch(
  File "/home/simslab-n/Desktop/VideoMamba/videomamba/video_sm/engines/engine_for_finetuning.py", line 82, in train_one_epoch
    loss_list = [torch.zeros_like(loss) for _ in range(dist.get_world_size())]
  File "/home/simslab-n/miniconda3/envs/Mamba/lib/python3.10/site-packages/torch/distributed/distributed_c10d.py", line 1555, in get_world_size
    return _get_group_size(group)
  File "/home/simslab-n/miniconda3/envs/Mamba/lib/python3.10/site-packages/torch/distributed/distributed_c10d.py", line 836, in _get_group_size
    default_pg = _get_default_group()
  File "/home/simslab-n/miniconda3/envs/Mamba/lib/python3.10/site-packages/torch/distributed/distributed_c10d.py", line 977, in _get_default_group
    raise ValueError(
ValueError: Default process group has not been initialized, please make sure to call init_process_group.

I have tried to train videomamba on single GPU,I attempted to add the line torch.distributed.init_process_group('nccl',init_method='file:///my_file',world_size=1,rank=0) before the line model = torch.nn.parallel.DistributedDataParallel(model, device_ids=[args.gpu], find_unused_parameters=True)( in run_class_finetuning.py line 562). But it seems like it didn't have any effect.  Your continued assistance would be greatly appreciated!

I've managed to solve the issue by adding the following code!
import torch.distributed as dist
dist.init_process_group(backend='nccl', init_method='tcp://localhost:23456', rank=0, world_size=1)

@franklio Hi,I also use one GPU for trainning, and i meet the same question, can you tell me this code should add to which file?plz

@franklio Hi,I also use one GPU for trainning, and i meet the same question, can you tell me this code should add to which file?plz

He mentions "run_class_finetuning.py" above

Hi! Our scripts use srun to start the training.  I managed to run successfully after removing 'srun' as you suggested, but only one card is operating. How can I get all four cards to run?

@CamelStorm Please follow these steps.


Add ability to specify exit code to quit watching

I am building a hot reloading solution using cargo-watch. I would like to have the ability to cleanly exit the whole setup. For this I would like to configure cargo-watch such that it stops running when the command returns a specific exit code. I imagine the API could be like:
cargo watch -s "some command" --exit-on 13

If some comand returns exit code 13 cargo watch will itself stop.

I'd accept a PR that implemented that.

Closing in favour of upstream issue: watchexec/watchexec#132.


0xff with type "uint8_t" being decompiled as "-1"

Compile the following source code with "-g" in gcc:
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <inttypes.h>

//test_uint8_ff
int test(uint8_t input){
	if (input < 0xff)
		{printf("input is less than 0xff\n");
			return 1;
		}
		printf("input is equal to 0xff\n");
			return 2;
}

int main(void) {
	uint8_t local = 0;
	scanf("%" SCNu8, &local);
	test(local);
}

And decompile the generated binary, ghidra will give us code like:
//test_uint8_neg_1
int test(uint8_t input){
	if (input == -1)
		{printf("input is equal to 0xff\n");
			return 2;
		}
		printf("input is less than 0xff\n");
			return 1;
}

I understand that "-1" and "0xff" are treated the same in uint8_t. But, if we compile both of the above two functions and run, they do not perform the same :
friends@friends-OptiPlex-5070:~/muqi/trash$ ./test_uint8_neg_1
-1
input is less than 0xff
friends@friends-OptiPlex-5070:~/muqi/trash$ ./test_uint8_neg_1
255
input is less than 0xff
friends@friends-OptiPlex-5070:~/muqi/trash$ ./test_uint8_neg_1
254
input is less than 0xff

friends@friends-OptiPlex-5070:~/muqi/trash$ ./test_uint8_ff
-1
input is equal to 0xff
friends@friends-OptiPlex-5070:~/muqi/trash$ ./test_uint8_ff
255
input is equal to 0xff
friends@friends-OptiPlex-5070:~/muqi/trash$ ./test_uint8_ff
254
input is less than 0xff

From readablity, 0xff being translated to -1 also confuses me.
Anyhow, If we want to fix this, some change could be made in PrintC::pushConstant .

You should check your data type manager and see what the uint8_t type boils down to.  (tip: turn on the "Preview Window" from the drop down triangle menu in the upper-right corner of the DTM, and then you could just type "uint8_t" in the filter field to narrow the tree down.  You only want to look at the entries that are under your program name, and ignore the ones under generic_clib_xyz or windows_vs_123, etc)
Ideally, it should resolve to an unsigned character type, but you should make sure of that first.

Thanks! I think the uint8_t is resolved to unsigned char type, I clicked the "Show Base data type" and it then points to "uchar" in ELF folder  -> my binary /program name folder -> Data Types

So that was the limit of my suggestions.  FYI, when I compile:
#include <stdio.h>
#include <stdint.h>

int test(uint8_t val) {
	printf("testing: %d\n", val);
	if ( val < 0xff ) {
		printf("lt 0xff\n");
		return 1;
	}
	printf(" == 0xff\n");
	return 2;
}
int main() { blah blah }

and put it into ghidra I get:
int test(uint8_t val)

{
  int iVar1;

  printf("testing: %d\n",(ulong)val);
  if (val == 0xff) {
    puts(" == 0xff");
    iVar1 = 2;
  }
  else {
    puts("lt 0xff");
    iVar1 = 1;
  }
  return iVar1;
}

Ha, I used an old version of ghidra~ Thanks for you time and sorry for the bother. Yes, you are right, it is correct now! After checking the result before and after  commit 1391e83ce9f63faf7fafc0d17b875d77729d5716, I am pretty sure this issue has been fixed~


Add a diagnostics tool to help collect logs on Windows.

The tool allows one to collect a series of logs and save them to a zip
file. When supplied with a Signed Url, the tool can upload the logs to a
GCS Bucket. The tool currently supports Windows only.

/gocheck

/gocheck

/gocheck

/gocheck


Notify admins when a user's GitHub company or organization changes

Continuing #756 but with GitHub...
I'm exploring another way to keep businesses honest and pay the required hiring fee. One idea is to track developers on ~LinkedIn~ GitHub and see if their job status changes.
Documented in the linked issue above, the GitHub API can fetch a lot of information for free. I'm most interested in "company" and "organizations". These most correlate to a developer getting a new job.
A PR addressing this issue should:

[ ] Send an email to admins once per day of any GitHub changes for developers

This is left intentionally vague as there are a ton of ways to do this. I imagine a rough outline would be running a daily background job to fetch the relevant information, comparing it to existing records, and sending an email with the changes.
I asked about how folks handle this on Twitter and got a variety of responses. The most viable (in my opinion) is working with ActiveModel::Dirty in some way. That means we can rely on the framework to do the "diff" and not calculate it manually.
I'm open to ideas and questions!

I looked that API documentation and it appears that the endpoint mentioned in the linked issue only returns information for the user that is currently authenticated with the API. This endpoint returns publicly available organization memberships for a user, but this would not cover private information about organizations. Another possibility would be to use [this endpoint](https://docs.github.com/en/rest/orgs/orgs?apiVersion=2022-11-28#get-an-organization] which provides a URL to list public members of that organization.
I guess the major sticking point is how big of an issue relying on publicly available information about organization memberships would be. If @joemasilotti feels that it is worthwhile to move forward on this, I would be willing to work on it.

Great point! I think that company plus public organization info is better than nothing right now. But let's test that assumption.
Want to throw together a throw-away PR that tallies how many folks have their company and/or an organization listed on GitHub? I can run it against production and share info here.
Based on that we can decide to move forward with a real PR that persists data, notifies admins, is tested, etc.

Sure, I can do that. Would you like me to work with actual user data? I could probably get by with a list of GitHub usernames

Actually, nevermind. I will just come up with something that will use test data locally.

Exactly. Then I can pull your code to my machine and run it against a local version of production data.

Verified by #783, over 40% of developers linking to their GitHub profile have either organization or company filled in.
Let's move forward with this PR!
I also noticed that the API has an hourly rate limit of 5000. So we should be good (for a while) in not hitting that.

I'm thinking of adding a github_company attribute/column to the User model and creating a GithubOrganization model with an association to user. I would then add a callback to the new model that would send an email to admin(s) when a new org gets added, with the exception of when the table gets populated for the first time. I would then add a rake task that would actually hit the API and could be run as a cron job. Does that sound good?

That sounds great with one change - let's move all of the new data to its own model. Even if that means we have a list/set/jsonb column for the organizations.

@joemasilotti  I have made some progress, but if someone is really eager to work on this I would be willing to hand it off.

OK, cool. I'm going to open it back up and see if they pick it up. Thanks!


Implementation with example in Angular 4

Here I get base64 data and i am converting it into blob and passing it to viewer.html .....
can anyone help me how to implment in angular2/4 and pass data to viewer.js or html
import { Component, Input, Output } from '@angular/core';
import { Router, ActivatedRoute, Params } from '@angular/router';
import * as pdfjsLib from 'assets/js/build/pdf.js'
import * as pdfjsLibWorkers from 'assets/js/build/pdf.worker.js'
import * as viewer from 'assets/js/web/viewer.js'
@Component({
template: <script src="assets/js/build/pdf.js"></script>     <script src="assets/js/web/viewer.js"></script>
})
export class PrintPolicyComponent  {
 this.printPolicyService.printSearchResult(JSON.stringify(json)).subscribe(printpolicyResults => {
            if (printpolicyResults) {
          var pdfData = atob(printpolicyResults.toString());
                    var url = URL.createObjectURL(blob);

                    var viewerUrl = 'assets/js/web/viewer.html?file=' +url;
            }
 })

}

The issue tracker is only for filing bugs in PDF.js. We cannot provide support for custom Angular (or other library) implementations; please use e.g., StackOverflow or related websites for such questions. We can only recommend to use the viewer components (https://github.com/mozilla/pdf.js/tree/master/examples/components) to build a custom viewer. Otherwise, we have more examples (https://github.com/mozilla/pdf.js/blob/master/examples/learning/helloworld64.html) that show how to load a PDF file from e.g., a base64 encoded blob.


crh marker is not always in place

ensure position s-o-s "knows" correct center before adding the crh marker

Pull Request Test Coverage Report for Build<PHONE_NUMBER>7
Details

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.68%

Totals

Change from base Build<PHONE_NUMBER>0:
0.0%

Covered Lines:
13496

Relevant Lines:
13497

💛  - Coveralls


Error in emulator when opening the second display

I got this error:
E/flutter ( 4259): #0      StandardMethodCodec.decodeEnvelope (package:flutter/src/services/message_codecs.dart:607:7)
E/flutter ( 4259): #1      MethodChannel._invokeMethod (package:flutter/src/services/platform_channel.dart:177:18)
E/flutter ( 4259): <asynchronous suspension>

when running on an android emulator. I tested multiple emulator devices, but they all gave the same error.
To Reproduce
Steps to reproduce the behavior:

Run Pixel C api 30 android emulator
Add a second display.
Launch the example app
Click "Get Displays"
Put the ID for the second display into the textbox
Click show presentation
Look at the console

Expected behavior
The second display should show something.
Smartphone:

Device: Pixel C
OS: Android api 30

I am getting the exact same Exception:
I/ContentValues( 2962): Channel: method: showPresentation | arguments: {"displayId": 2,"routerName": "presentation"}
I/ContentValues( 2962): Channel: method: showPresentation | displayId: 2 | routerName: presentation
E/flutter ( 2962): [ERROR:flutter/lib/ui/ui_dart_state.cc(209)] Unhandled Exception: PlatformException(showPresentation, Unable to add window android.view.ViewRootImpl$W@379a897 -- the specified display can not be found, null, null)
E/flutter ( 2962): #0      StandardMethodCodec.decodeEnvelope (package:flutter/src/services/message_codecs.dart:607:7)
E/flutter ( 2962): #1      MethodChannel._invokeMethod (package:flutter/src/services/platform_channel.dart:177:18)
E/flutter ( 2962): <asynchronous suspension>

So far, when I use the emulator is not working, but when I use an actual Android device and Chromecast as my secondary display it works. Same for iOS, in case of iPad I can use an HDMI cable or AppleTV. On iPhone I tested AppleTV and it works, I was not able to test cable, because I do not have a lighting to HDMI adapter.
So far that is what I am trying to do, and this does not represent an issue for me anymore.

Oh that is good to know. I do think it also needs to work on an emulator, and the issue does also seem to be android specific. Thanks for testing.

@fbernaly How do you set up the Chromecast as a secondary display? I'd like to help debug this

@kerberjg : It has been more than 2 years, I stopped working on that project, I am sorry but I dont remeber where I left the code or what I did for that.


Add persistent bulk download per user per batch

Modify workflow input to include batch id
Propagate batch id from workflow HTML UI
Gather outputs in single directory on server
Expose download/export option for end user  (or gather to single workspace?)

Aim to export: OpenDS, OpenDS flat as csv, PROV / run metadata (e.g. tool versions, config options)

If a collection of openDSs is to be exported, this could be packaged as an RO-Crate. For the interested this would add metadata but for those not - it is still a zip file

The switch to collections allows a user to easily download all submitted samples/specimens from their History(ies). There is some additional functionality we may want.


rust CI: explore if it's possible to free more disk space

We use the action free-disk-space to remove stuff from the free runners that we don't use.
The action doesn't seem maintained anymore. E.g. there are the following PRs where the maintained didn't reply:

https://github.com/jlumbroso/free-disk-space/pull/26
https://github.com/jlumbroso/free-disk-space/pull/24

Task: evaluate those PRs and if they are worth it, fork the github action and maintain it under rust-lang org
We could also check if more packages we don't use could be removed

I would not fork it and maintain inside of the rust-lang org, as we are already stretched too thin to maintain it and make it work for other people outside of Rust. I'd rather recreate the script inside of our src/ci/scripts directory and invoke it there.

maintain it and make it work for other people outside of Rust

I wouldn't do this. Although it would be nice to have external contributors that remove more stuff that GitHub might add to the runners.
The reason why we might want to have it as an action instead of a script, is that other rust projects (rust analyzer, miri, etc.) might want to use it at some point.

If at some point other repos start needing it we can extract the script out of rust-lang/rust, but IMO maintaining it as an in-tree script makes it easier to test it and tweak it.

I agree, let's start with an in-tree script then 👍
I'm putting the good first issue label if anyone wants to own this.

Hey! Could this be assigned to me please?

Done!


Issue 798

This PR aims to find and fix inconsistencies in the documentation for the PFMERGE command as mentioned in the issue #798
The objectives of this PR can be simplified in the points below

[x] Run the command and its examples in a local instance of DiceDB and make sure they work as per requirements
[x] Compare the command with Redis's counterpart and make sure that the results are the same
[x] In the official documentation, format the headings with the correct title as specified in the issue
[x] Remove the Conclusion heading if it exists
[ ] Appropriate use of headers
[x] Convert Parameters and Return Value to a markdown table format to ensure consistency

end goal - documentation should match the format followed by SET and be consistent with how the code works

HI @Kannav02 Thanks a lot for the changes, can you please add an error example as well if possible?

sure i will update the PR title, also just to follow up ,
you've told in the issue to use Examples as the heading to display the examples for the CLI usage
but in the SET documentation, Example Usage is being utilised
should I still go ahead and make the change to Examples
thank you!

@AshwinKul28 ,I think the PR should be good for review now
Thank you!


The Websocket cannot connect

Hello,
I am testing the code in the demo
client = Client(api_key, api_secret)
def process_message(msg):
　　print(msg)
bm = BinanceSocketManager(client)
conn_key = bm.start_trade_socket('BNBBTC', process_message)
bm.start()
and what i am getting is, error:
{'e': 'error', 'm': 'Max reconnect retries reached'}
I can normally open the page "www.binance.com/trade.html?symbol=BNB_BTC" on Google Chrome.So I think the network is normal.
Am I doing something wrong?
Please help me fix it. Thanks in advance

There are no problems with the code:
`from binance.client import Client
from binance.websockets import BinanceSocketManager
client = Client('', '')
def process_message(msg):
print(msg)
bm = BinanceSocketManager(client)
conn_key = bm.start_trade_socket('BNBBTC', process_message)
bm.start()
`
Have you created api_key, api_secret for the application on binance.com?

@theGalex  yes, I have created and used them.

I think you are banned. Please check this code after 24 hr

Thanks for your answers. When I run the program on a virtual personal server in Los Angeles, the error does not appear.The error may be due to the Great Firewall.

@Tuixote
Hi, I have the same problem on my local machine. Works fine on EC2 server.
How did you manage to solve this on your local machine?
Thanks!

@mingrui
I did not solve the problem when program  worked on the local machine. I choose to run it on vps.

Hello.
I have the same problem too.
Is anybody find a solution?
Is there any region restriction?
I've used VPN but it is not working.

I also met this problem, and I'm not sure what the real reason is. I tried the similar code in my own laptop and a Linode VPS. After long period of time, it returns:
message type: error
{'e': 'error', 'm': 'Max reconnect retries reached'}

I have the exact same problem currently. Two days before it still worked on this machine. Tried different API keys but does not change anything. Are there any rules on when one gets banned??

I have the exact same problem currently. Two days before it still worked on this machine. Tried different API keys but does not change anything. Are there any rules on when one gets banned??

Yes, every action you do on binance costs a weight. look here: https://github.com/binance-exchange/binance-official-api-docs/blob/master/user-data-stream.md
To create a listenKey costs 1 weight. The more you are out of range of a default user behaviour, the higher is your risk to get banned for a timeframe of 2 min to 3 days.
This is described here: https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#limits

Each route has a weight which determines for the number of requests each endpoint counts for. Heavier endpoints and endpoints that do operations on multiple symbols will have a heavier weight.
IP bans are tracked and scale in duration for repeat offenders, from 2 minutes to 3 days.


Adding option for preemptible google cloud instance

As discussed in https://github.com/snakemake/snakemake/issues/457#issuecomment-671116746, this pull request will add support for using preemptible as a resource option in a Google Life Sciences workflow (and I suppose it would be ignored otherwise).
I added one of the steps to be preemptible so we can test it during snakemake testing, here.
I also checked the instance running to ensure that setting it to true indeed resulted in this instance type:

The default will be False, as I assume most users wouldn't expect this.
Signed-off-by: vsoch<EMAIL_ADDRESS>

@johanneskoester I've added those additional resources to the main resources documentation! If it's not organized as you had in mind, please feel free to suggest -> commit (or of course just instruct me how to make changes). I didn't group preemptible with standard resources because it's only added for GLS, but if it's added for other cloud executors we could move it up there.

@johanneskoester what about pushing a dev image before we run tests on push to master and then we can use it for the google cloud executors? That way we can be sure if a previous bug was fixed. We could even delete the image tag right after the run.

Perhaps the docs should also caution that the preemptible option should be run with a --restart-times value?
Or maybe setting preemptible to true should automatically set --restart-times to a reasonable value for that job?

@aryam7 I don't see an option exposed in the Google Lifesciences API for restart times - could you point me to what you have in mind? https://cloud.google.com/life-sciences/docs/reference/rest/v2beta/projects.locations.pipelines/run#VirtualMachine

ah! I was referring to Snakemake's --restart-times
Preemptible instances can be terminated by Google Cloud at any time for any reason, but they incur much lower costs. I think it would only make sense for someone to use preemptible instances if they could have Snakemake retry terminated jobs.

Mhm, can we see from life science API whether a preemptible job failed because of google killing it (because of the peemptible flag) or because of other issues? In that case, the preemption cause should lead to infinite repeats of that job.

You can monitor the metadata of an instance to see if it was preempted
curl "http://metadata.google.internal/computeMetadata/v1/instance/preempted?wait_for_change=true" -H "Metadata-Flavor: Google"
see here

Thanks I’ll check this out!

If the job is preempted, it should return an exit code of 14.
One way to implement @kdbinder's approach could be to allow the preemptible resource to be a callable with the number of attempts as a parameter, like Snakemake already does for the mem_mb resource.

okay so we have a few options! Given that the life science worker can communicate being preemted with exit code 14, here are the options:
1. Preemptible as boolean with default retry.
If the user speifies preemptible=True this would be akin to using preemptible instances with some default number of retries, but only given that the exit code is 14. @johanneskoester you suggested infinite, but I'm weary of this because if a VM has a maximum time of 24 hours (and the user doesn't know this) it will essentially go on forever. We could have infinite retries but spit out warning messages about the maximum time, or have preemptible retry to some default value (e.g., 10?). This seems like the simplest option because the user can just request preemptible and not think about it.
2. Preemptible as integer to indicate retry
We could instead require the user to specify the number of retries off the bat, e.g., preemptible=10 and this would again only be in the case that the exit code is 14. But then what would happen if the user set both preemptible and restart times? The scheduler handles restarts and this would get messy or confusing.
3. Preemptible as boolean with restart times
I think the cleanest implementation would be to keep preemptible as a boolean, and:

case 1: if the user doesn't specify restart-times, we set it to a reasonable default (e.g., 10) for the step
case 2: if the user specifies --restart-times we use that with pre-emptible just as we would any other step.

The third solution above would not have any confusion between using restart times and preemptible. And if would sort of change into the first solution if the user doesn't specify a number of restarts. I think what we would want to make sure is possible is specifying the restart-times in the job resources:
    rule:
        input:    ...
        output:   ...
        resources:
            preemptible=True, restart-times=10
        shell:
            "..."

which actually makes me fall back to the other suggestion, we could simplify like this:
    rule:
        input:    ...
        output:   ...
        resources:
            preemptible=10
        shell:
            "..."

So in summary, why not allow the user to use a boolean or an integer? if an integer is provided, we set that to be the job's restart times. If not, we use a reasonable default. Thoughts?

Thanks for laying out the options, @vsoch!
I'm not really a fan of allowing the preemptible resource to be set equal to an integer. If somebody wants that behavior, they can just set it to a callable with the number of attempts, right? This is what I originally envisioned doing when I submitted this feature request.
I don't have strong feelings about a default number of retries as long as it can be overridden by the strategy in the callable, especially if the default is initially set to infinity.

I don't really have strong feelings either - even if we set it to be unlimited that would work given enough clear messages to the user about how it's working. I'll leave this decision up to @johanneskoester.

Thanks for this inspiring discussion. A different perspective: is preemptible something that should be in the workflow at all? It is not platform independent. What about this instead:

Allowing preemption for all rules, with 10 repeats: snakemake --preemptible default=10
Overwriting specific preemption for particular riöes: snakemake --preemptible default=10 map_reads=3 call_variants=0
No preemption by default, but for a particular rule: snakemake --preemptible default=0 map_reads=10

@johanneskoester this part:

A different perspective: is preemptible something that should be in the workflow at all? It is not platform independent. What about this instead:

Namely "it is not platform independent" tells me that the answer to https://github.com/snakemake/snakemake/issues/573 might in fact be that (in the case that cores is platform independent, because with drmaa we don't define any?) the workflow file should not be referencing this variable for that exact reason.
What do others think about having the preemptible args? I can refactor to fit this idea.

tl;dr

It is not platform independent.

I find this argument to be really convincing. I didn't realize that resources definitions were supposed to be defined independently from the execution environment. In that case, I think I favor the idea of having preemptible args.
The implications
But let's just make sure we're making the implications of this decision explicit.

By moving the preemptible option into the arguments, you imply that the preemptibility of each rule should not be decided by the developer of the Snakefile. It should be solely the user's decision.
Moreover, since all other resource definitions must be platform independent, any option which is specific to a particular cluster environment must be solely the user's decision. The developer should have no say because Snakefiles should be platform independent.

I am inclined to agree with the implications above. And I now have a newfound respect for the design decisions that went into Snakemake!
A potential counter-argument
Is there any value in the developer making decisions about preemptibility before the user? I can think of at least one situation.
For the sake of the argument, let's say preemptibility has an adverse impact on long-running rules; so rules that take a long time to execute are more likely to be preempted during their lifetime than ones that execute quickly. (I have no idea whether this is true, but it seems plausible.) Thus, the developer decides to only add preemptibility to steps in the Snakefile that take a short amount of time.
Note: that the user may later decide to override these decisions via Snakemake's --resources parameter. So it's not a matter of whether the developer gets to make the choice or the user. The user always gets to make the ultimate choice.
There are undoubtedly other situations that I haven't thought of. For example, what if the developer wanted to set preemptibility for a rule based on its wildcards?
In addition, you can probably expand this counter-argument to any resource definition (as I did for implication # 2).
Also, are you planning on adding arguments to Snakemake whenever this sort of things happens in the future?
A solution to the potential counter-argument
If you want the best of both worlds, you could allow resource definitions passed via --resources to be rule-specific. For example,
snakemake --resources preemptible=1

could become
snakemake --resources map_reads.preemptible=3

But then, of course, you compromise on the somewhat noble goal of ensuring that Snakefiles are utterly platform independent.
Thanks for reading till the end! I kinda got away with myself there, but this is all interesting stuff.

@aryam7 indeed the design is very well thought out! To your point here:

Is there any value in the developer making decisions about preemptibility before the user? I can think of at least one situation.
For the sake of the argument, let's say preemptibility has an adverse impact on long-running rules; so rules that take a long time to execute are more likely to be preempted during their lifetime than ones that execute quickly. (I have no idea whether this is true, but it seems plausible.) Thus, the developer decides to only add preemptibility to steps in the Snakefile that take a short amount of time.
Note: that the user may later decide to override these decisions via Snakemake's --resources parameter. So it's not a matter of whether the developer gets to make the choice or the user. The user always gets to make the ultimate choice.

I would argue that there is another level of representation that a developer still could embed the needed logic. If we consider the unit of packaging to be one up from the Snakefile, and to include an executor environment (e.g., some specific provider that does/does not support preemptible instances) the developer would provide the "correct" command for the user, and/or you could imagine it being built into a container with the entrypoint having it. In other words, the snakefile should be agnostic to this setting because it's more properly defined one level up.
This is a cool idea:
snakemake --resources map_reads.preemptible=3

but my intuition says that if a user wants a preemptible instance for one rule, likely they want it for most! So this would create a very busy command:
snakemake --resources map_reads.preemptible=3 --resources rule_2.preemptible=3 --resources call_variants.preemptible=0

when we could have just done
snakemake --preemptible-rules map_reads=3 rule_2=3 call_variants=0

And I suspect if we allow passing via a resources argument on the command line, it could be confusing for users why they can't specify it via the resource in a Snakefile.

@vsoch sounds good! Yes, embedding logic one level above Snakemake certainly works. That's a really good point.
Yeah. When I gave that example for passing rule-specific resources via the --resources parameter, it was under the assumption that the developer would be allowed to specify the resources in the Snakefile.
So to be clear, I was not endorsing that option. I was just trying to highlight it as a (sort-of) compromise between the two competing design philosophies. Like, a more flexible option: the developer specifies their recommended resources for each rule and the user overrides whatever they want to.
And I agree that the shorter syntax seems nicer.
Thanks for considering my ideas, at all!

Ah understood! And of course @aryam7, I think it’s really important that we have this discussion, and consider one another’s ideas. Hearing your thoughts is very important to me.

okay, PR has been updated to what we discussed!

Thanks for evaluating the implications. I think the developer might in such case rather define a job as short running. And we could allow to infer preemption for short running jobs via the command line. For this to work properly, we should define runtime_minutes (or another reasonable name: this is to be discussed, walltime? seconds, minutes?) as a new standard resource in the docs (under rules->resources), and add an option --preemption-default-max-runtime MINUTES that allows to only set the default for rules with a runtime that not exceeds the defined value.

@johanneskoester which comment are you responding to? I'd like to clarify what you are thinking before moving forward.

runtime_minutes would be a resource specification independent of pre-emptibility. It's not the minutes allowed to run, but the number of minutes that the user expects the step to take? How would they know? It seems appropriate for a wrapper but maybe not a random Snakefile.
If runtime_minutes is defined but preemption is not, it essentially does nothing
If runtime_minutes is defined and --preemption-default-max-runtime MINUTES is defined (for the default) - we skip over jobs that are greater than the limit, the rest are made pre-emptible.
If runtime_minutes is defined and --preemption-default-max-runtime MINUTES is not, the first again does nothing.
If --preemption-default-max-runtime MINUTES is defined without runtime_minutes, we can't do anything either.

I think there could confusion if runtime_minutes is an estimated ETA or the allowable minutes. And for the other points we would need to put a lot of warnings so the user is aware of one setting without the other. I'm also concerned a user might think it would indicate pre-emption "but only run for this many/max number of minutes."

Oh, and --preemption-default-max-runtime MINUTES would have a default value of 24 hours (1440 minutes) since that's the max for any preemptimble instance I think.

@johanneskoester which comment are you responding to? I'd like to clarify what you are thinking before moving forward.
* runtime_minutes would be a resource specification independent of pre-emptibility. It's not the minutes allowed to run, but the number of minutes that the user expects the step to take? How would they know? It seems appropriate for a wrapper but maybe not a random Snakefile.

* If runtime_minutes is defined but preemption is not, it essentially does nothing

* If runtime_minutes is defined and --preemption-default-max-runtime MINUTES is defined (for the default) - we skip over jobs that are greater than the limit, the rest are made pre-emptible.

* If runtime_minutes is defined and --preemption-default-max-runtime MINUTES is not, the first again does nothing.

* If --preemption-default-max-runtime MINUTES is defined without runtime_minutes, we can't do anything either.

I think there could confusion if runtime_minutes is an estimated ETA or the allowable minutes. And for the other points we would need to put a lot of warnings so the user is aware of one setting without the other. I'm also concerned a user might think it would indicate pre-emption "but only run for this many/max number of minutes."

Agreed, it can indeed be confused easily. runtime_minutes would still be of use without preemption, e.g. for cluster systems where the queue is selected based on runtime. And yes, it is meant as an ETA, hence probably not the best name. In any case, nothing that would need to be decided in the PR.

So, one final thing @vsoch: I think this PR is still missing a test case. Can you add one?

Can do! I had added a pre-emptible instance to be used for the pack step of the Google Life Sciences test - what other tests did you have in mind?

Can do! I had added a pre-emptible instance to be used for the pack step of the Google Life Sciences test - what other tests did you have in mind?

That's enough. I did not see that, thank you!

thank you so much for implementing this, @vsoch!

My pleasure @aryam7!


Modify Withdraw Address Modal

Scope
Work Done

Allow to connect with Keplr
The current withdrawal address display is the connected Keplr/Keysafe account
Title with “New Withdrawal Address”
styling
The button label changed to Confirm

Steps to Test
Modify Withdraw Address Action button clicking
Screenshots

Please correct spelling of Withdraw
Correct header should be
New Withdrawal Address


Could you add Istio ambient to your report?

Describe the bug
Love your report, but a req - can you also add ambient there? see: https://istio.io/latest/blog/2024/ambient-reaches-beta/
Steps to reproduce
No response
Expected behavior
No response
Evidence
NA
Environment
NA

Hi @linsun! Thanks for your engagement, and I'm pleased that you liked the Test Report.
We are happy to take onboard your request. I've discussed it with the team and we will run a part two of this service mesh comparison, where we will compare Istio Sidecar to Istio Ambient. I'm excited to see how Istio Ambient performs.

Thank you @oleksandr-livewyer! It is very cool to have a neutral party running performance and do it in the open. We appreciate it. We have other feedbacks - will continue to send it via github issues?

@linsun Thanks for your appreciation. We are happy to contribute to this and have already started working on it. We are planning to run some preparatory actions today and hopefully run tests next week. In terms of feedback, feel free to provide other bits using GitHub Issues.

Hi @oleksandr-livewyer Thanks so much!  Feel free to let me know if you have any questions related to Istio or ambient.
Regarding other feedback, please correct me if I am wrong here as I'm learning in this space as well:

When looking at your performance tests, I think you are testing HTTP for Linkerd and Istio, but for Cilium based on your template, you are not doing any L7 processing (other than at the ingress gateway).  Basically, the requests among the bookinfo sample app is HTTP for Linkerd and Istio, while it is TCP for Cilium. Is it possible to test HTTP for all meshes, and/or TCP for all meshes for consistency?

FIPS compliant. My understanding is Cilium doesn't currently support FIPS, because wireguard isn't FIPS compliant. If you google "wireguard FIPS compliant", you'd find a lot of search returns such as https://www.reddit.com/r/WireGuard/comments/yx4ipy/is_there_an_intention_to_get_wireguard_fips/.

mTLS, only Linkerd and Istiod support mTLS. Cilium, not yet, see https://github.com/cilium/cilium/issues/25216#issuecomment-1607159389.

Cilium CPU measurement doesn't seem to account for the datapath being in kernel? AFAIK, that is not attributed to any of the Cilium daemonsets.

Many thanks for your great work!

Hi @linsun ! Thank you for bringing up many valid points.
Our main goal was to provide a comparison between the three products, deploying them according to their product's official documentation while balancing that with environment and deployment consistency wherever possible. An additional benefit of this comparison was to further our engineering team's understanding of these three products, to better provide knowledge and guidance to our customers.
We will likely run another round of tests later this year, and we will take into account your and others' feedback to provide better insights.
Diving into details I can say:

Thanks for noting this. We followed the Cilium documentation, so we will review our setup and correct it if needed before the next round of tests.
I agree. It seems that Wireguard is not FIPS compliant. However, I bring you back to the point of our study. We did not intend to compare FIPS-compliant versions of products; we used the basic builds from the official documentation. Regarding Cilium's FIPS compliance, they provide multiple statements that they are FIPS compliant.
Cilium
Cilium
Isovalent
I agree. Cilium has its own implementation of mTLS, called mTLS-based mutual authentication. I believe it solves the same issues as common mTLS. To mitigate this, we will add some notes to the test report to make this clearer to readers.
That's a fair point. We didn't include this commentary in our test report, so I'll make sure to add this.

Hi @linsun! I believe I've addressed your request to add Istio Ambient to our comparison in PR#7.


TOH design

This is used to fix #50
See iquizoo/iquizoo.github.io#23 for preview.

Closing. Merged using git flow.


Need better way of handling visiting the website from unsupported platform

About 30% of our users are browsing the site on mobile devices; another 6% or so are using a browser we do not support.  When visiting our site, after the home page, the first action taken by about 35% of these users was to attempt to install uProxy by visiting either http://uproxy.org/mobile.html or http://uproxy.org/chrome-install.html.  We should do a better job of handling these users.
Current Flow
User sees site as normal, clicking on the install link if the user is on a mobile device will show a page containing the text "uProxy is not yet available on mobile devices.".  Clicking on  the install link from another browser (e.g. Safari, Opera) will show the normal Chrome install page.
Ideas

Show something better on the mobile page than "uProxy is not yet available on mobile devices"
Do not display the install links to the user, or grey them out and give the users an on-page notification that their browser is not supported

@gwpenn @lucyhe @zahoriea

@zahoriea how do you want to handle this?

Hi @jpevarnek, attached are proposed mocks and (screenshots of how we're handling these currently for reference)
Current:

Proposed:

For the proposed flow, I would like the uproxy.org homepage to stay the same (e.g. not greying out the install button) no matter what device or browser the user is on. However, when the user clicks on 'Install' from the homepage, the install page should replace any of the install buttons with a "your browser/device is not supported" message with instructions on how they can proceed in the light-blue boxes.
@gwpenn @lucyhe would love your thoughts as well!

@zahoriea okay, so, couple small changes I ended up making in the implementation, let me know if any are any problems.
For the heading font, I switched to using Quicksand the way we have with the rest of the headings on the page.
For the link, I switched to doing the same colour as the rest of the text but with dotted underlines to have consistency with the rest of the text.
I removed the "BACK TO UPROXY HOME" link since we were still on the home page in most cases.
I also removed the install links at the top of the page in the case where the user does not have a supported browser.
I tried to match the dimensions you had for the error (I measured it as 480px across with margins of 50px and 80px for top/bottom and left/right).
Let me know if anything needs to be changed.
This is currently viewable at https://jpevarnek-dot-uproxysite.appspot.com/, screenshot is also attached.

Hey there,
I'm actually advocating that we keep the "Install" button the same on the homepage (no color changes, swapping out for this box, etc.) and that ONCE the user has clicked on the Install button, they will see this on the Install page.
The reason why I'm advocating for this approach as better UX is that we should only be showing users this messaging once the user has indicated that they wan't to install uProxy.

Ah, okay, I interpreted that as replacing the button while staying on
the same page. I would actually advocate that we do it the way I
implemented it, I think it is a much better experience for the user to
keep them on the same page when something goes wrong instead of
sending them to another page.
I do think that removing the install link from the top of the page is
also a reasonable decision: I don't think having it in the header when
there are also multiple other buttons visible is actually adding much,
and I don't think the experience for that (you would have to navigate
to a completely new page) would be optimal.
Anyways, feel free to play around with that demo page.
On Thu, 10 Sep 2015 12:49 Izzie Zahorian<EMAIL_ADDRESS>wrote:

Hey there,
I'm actually advocating that we keep the "Install" button the same on the homepage (no color changes, swapping out for this box, etc.) and that ONCE the user has clicked on the Install button, they will see this on the Install page.
The reason why I'm advocating for this approach as better UX is that we should only be showing users this messaging once the user has indicated that they wan't to install uProxy.
—
Reply to this email directly or view it on GitHub.

@zahoriea okay, changes made.  The "visit this page from..." text seems a bit strange now, however, since visiting the page from those browsers will end up just showing the same error.  I'm guessing we don't want to change the text of mobile.html and unsupported.html when the user has Chrome/Firefox installed but I have no idea what we do want to do.

Thank you!! @gwpenn, any thoughts on language or how to handle here? It would be amazing to have the install page still be http://uproxy.org/install but show this error, rather than swapping out a separate page... however not sure how complicated that would be to build.

Ah, okay, we can do that.
We previously had separate pages for the different platforms, I'll set it
up so that they all just redirect to /install.
For Firefox, we still want to have the link go directly to the webstore,
correct?
On Thu, Sep 17, 2015 at 11:07 AM, Izzie Zahorian<EMAIL_ADDRESS>wrote:

Thank you!! @gwpenn https://github.com/gwpenn, any thoughts on language
or how to handle here? It would be amazing to have the install page still
be http://uproxy.org/install but show this error, rather than swapping
out a separate page... however not sure how complicated that would be to
build.
—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/1460#issuecomment-141169241.

Sounds good to me!

I think we actually fixed this in a previous update, @gwpenn

Yep. The site currently reflects Izzie's proposals. Thanks for flagging.


Jest testing broken - what have I done!?

Getting almost all the Jest tests fail with the following error.
TypeError: e.map(...).filter(...).flat is not a function

What have I done to my setup to bork it all up? (Have not changed anything except pull in the latest master)

Interesting... ".flat" IS indeed a function that Jest should understand. Did you update anything else?  I don't really know off the top of my head.

That's what I thought!?
I will try a full npm rebuild. Nothing done since pre Laracon when it
worked; and it obv works for you...
D
On Wed, 31 Jul 2019, 19:42 Caleb Porzio<EMAIL_ADDRESS>wrote:

Interesting... ".flat" IS indeed a function that Jest should understand.
Did you update anything else? I don't really know off the top of my head.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/calebporzio/livewire/issues/94?email_source=notifications&email_token=AAGDPCUAFYYHLQMVXVS64ITQCHMITA5CNFSM4IIIEGBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3IFZRY#issuecomment-516971719,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGDPCUYOQLGINRAZRMSZOLQCHMITANCNFSM4IIIEGBA
.

NPM Version was set to v10. Had to upgrade to v12 to get it working.


This repository is empty.

Is there a reason that there is no source in this repository? Where can I find it?

I am still in the process of migrating from the old project site on Fedora Hosted.

@npmccallum  Ah thanks. Would it be possible to leave this issue open & close it when you are done (so I'll get a notification)?

No, because I'm still working out the kinks on issue transfers. So I'll be deleting this project and recreating it until I get the details correct. Sorry!


DbRef CS0029	cannot implicitly convert type “System.Collections.Generic.List” to “AdvancedFilterConditionConfig"

var mapper = BsonMapper.Global;
mapper.Entity()
.DbRef(x => x.Conditons, "Conditons");
CS0029	cannot implicitly convert type “System.Collections.Generic.List” to “AdvancedFilterConditionConfig"

im Do follow the example of the Project Main Page
 // "Produts" and "Customer" are from other collections (not embedded document)
mapper.Entity<Order>()
    .DbRef(x => x.Customer, "customers")   // 1 to 1/0 reference
    .DbRef(x => x.Products, "products")    // 1 to Many reference

its my fault,my code is wrong.


Increment sequence for universe in E1.31 packets

Incrementing sequence number is required by E1.31 spec and is expected by some receivers, such as SACNView. This update tracks sequence number in the DMXSource instance, meaning this logic assumes there's a single DMXSource instance transmitting packets for a particular universe at a time. If this is not the case, the sequence will not have expected values and receivers may ignore packets.
May add support for multiple DMXSources with same universes sharing sequence numbers in the future, but not needed for my use case for now.

Looks like this was always there in the framing layer - and just wasn't exposed to the packet construct.
Thanks for adding - glad someone is getting some use from this project.


DeleteOnClose flag

Hi Liryna,
I have some issue with regards to the DeleteOnClose flag. This was apparently fixed at driver level here: https://github.com/dokan-dev/dokany/issues/18
My app though still fails to delete files that were opened with "Delete On Close" flag.
This is the procmon log for Excel 2010 on a normal NTFS drive, when opening 4.xlsx the temporay file ~$4.xlsx will be openend. It will be closed and deleted when Excel is closed.

10:25:04,6877324	EXCEL.EXE	8820	CreateFile	C:\test~$4.xlsx	 SUCCESS	Desired Access: Generic Read/Write, Delete, Disposition: Create, Options: Synchronous IO Non-Alert, Non-Directory File, Delete On Close, Open No Recall, Attributes: H, ShareMode: Read, AllocationSize: 0, OpenResult: Created
10:25:04,6880769	EXCEL.EXE	8820	CreateFile	C:\test~$4.xlsx	 SUCCESS	Desired Access: Write Attributes, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
10:25:04,6881516	EXCEL.EXE	8820	SetBasicInformationFile	C:\test~$4.xlsx	SUCCESS	CreationTime: 01.01.1601 02:00:00, LastAccessTime: 01.01.1601 02:00:00, LastWriteTime: 01.01.1601 02:00:00, ChangeTime: 01.01.1601 02:00:00, FileAttributes: HNNCI
10:25:04,6881965	EXCEL.EXE	8820	CloseFile	C:\test~$4.xlsx 	SUCCESS
10:25:04,6882500	EXCEL.EXE	8820	WriteFile	C:\test~$4.xlsx	 SUCCESS Offset: 0, Length: 55, Priority: Normal
10:25:04,6883144	EXCEL.EXE	8820	WriteFile	C:\test~$4.xlsx	 SUCCESS	Offset: 55, Length: 110, Priority: Normal
10:25:04,6883339	EXCEL.EXE	8820	FlushBuffersFile	C:\test~$4.xlsx	 SUCCESS
10:25:04,6883696	EXCEL.EXE	8820	WriteFile	C:\test~$4.xlsx 	SUCCESS	Offset: 0, Length: 4.096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal
10:25:29,0750834	EXCEL.EXE	8820	CloseFile	C:\test~$4.xlsx	 SUCCESS

I have noticed that in ZwCreateFileProxy if the fileOptions.DeleteOnClose is set,  rawFileInfo.DeleteOnClose is still false.
Cleanup and Close for the file in my app's drive are never called with DeleteOnClose=true which I would expect should happen.
The DokanNet mirror still does it correctly though. I see this in the log when Excel is closed:

06/13/2016 11:21:04 - [Mirror] CreateFile('\test~$4.xlsx', {, DeleteOnClose=False, False, False, False, #948, False, False}, [ReadAttributes, Synchronize], [ReadWrite, Delete], [Open], [None], [0]) -> ObjectNameNotFound
06/13/2016 11:21:04 - [Mirror] CloseFile('\test~$4.xlsx', {, DeleteOnClose=False, False, False, False, #6772, False, False}) -> Success

The code in Cleanup "if (info.DeleteOnClose)" is never executed, the mirror FileStream for "~$4.xlsx" is apparently only deleted on Close because it was created with relayed FileOptions.
Shouldn't the DeleteOnClose flag be set on Close/Cleanup by DokanNet in these cases?

Hi @js69 ,
On my side Delete On Close is correctly set otherwise the C# Mirror would never been able to remove files.
Having the flag in Close is useless because in Windows logic, the file has to be delete in the Cleanup.
Have you been able to make a simple test that delete a file ? To see if this only happen with Excel or in every cases ?
Be aware to https://github.com/dokan-dev/dokany/issues/249, is it is the same behaviour that you face, it is probably an issue directly in Dokan and not in the C#.

The C# mirror does not handle the DeleteOnClose case itself at all - that is done by Windows for the FileStream you create. The same is probably true for the C mirror sample.
The Cleanup never receives a DeleteOnClose=true flag from any Office application, as far as I can tell.
This might be fixable in the driver if it were to remember the FILE_DELETE_ON_CLOSE flag set on Create. In any case, Cleanup needs to have that flag sent to allow it to handle the case correctly.

What you describe is already made https://github.com/dokan-dev/dokany/commit/770d2a76a97f7cf86002660d44c9aaeba8f474f0#diff-f8956c408fab8dbdc1c6ccfbd0a1035cR108
We save the FILE_DELETE_ON_CLOSE and set it in the Cleanup.
In the C# Mirror logs that you gave, DeleteOnClose is not set during CreateFile.
I see in your logs that there is two CreateFile and one with DeleteOnClose but are you sure that there is no DeleteOnClose flag set ?
DeleteOnClose directly come from dokan.dll and the flag is set here https://github.com/dokan-dev/dokany/blob/7c53ac77393e1430ad228b2e514f1f4a5d7fd247/dokan/dokan.c#L543
BUT there is probably something with Office 2010 and the magic of Windows that we do not handle.
I only think that if you see the request CreateFile with the flag delete, it have to be also set in Cleanup.

I don't see in the Dokan driver cleanup.c anything that handles the Delete On Close flag.
Shouldn't there be something similar like what was added in create.c?
if (irpSp->Parameters.Create.Options & FILE_DELETE_ON_CLOSE) {
  fcb->Flags |= DOKAN_DELETE_ON_CLOSE;

In the kernel side, we only have the information during the Create. Therefore, we save the flag in fcb->Flags https://github.com/dokan-dev/dokany/commit/770d2a76a97f7cf86002660d44c9aaeba8f474f0#diff-86caa6b16e4044982075fe5d5bc59915R514
and we set it back in Cleanup event https://github.com/dokan-dev/dokany/commit/770d2a76a97f7cf86002660d44c9aaeba8f474f0#diff-f8956c408fab8dbdc1c6ccfbd0a1035cR108

OK, getting back to the issue:
info.DeleteOnClose is never true in in the C' mirror Cleanup when opening and closing a file in Excel 2010 or Excel 2016. Could you please trace if that flag is really correctly set in the driver code's Cleanup?

@js69 , I will take a look this weekend !
Just to be sure, does the behaviour also happen with Excel 2016 with C mirror ?

Hi @js69 ,
From my observation (office 2016), the flag is correctly set during the CreateFile BUT during the Cleanup, the flag is not set.
The C and C# mirror succeed to delete the temporary file because they open the flag with DeleteOnClose during the CreateFile.
I agree that Cleanup should send the DeleteOnClose flag but I have no idea why does the fcb->Flags; does not have the correctly value set from CreateFile.
Also the Context is seems to be correctly set so it is strang that flag is not correctly restored.
@marinkobabic Do you have any idea why this would happen in some cases (only have been to reproduce with office) ?
[DokanFS] ==> DokanCreate
[DokanFS]   ProcessId 3864
[DokanFS]   FileName:\liryna\Desktop\~$hey.xlsx
[DokanFS]    IdType = VCB
[DokanFS]   IrpSp->Flags = 0
[DokanFS]   Allocate FCB
[DokanFS]   FILE_DELETE_ON_CLOSE is set so remember for delete in cleanup
[DokanFS] FLAGS VALUE = 16

It's clear to me what happens:

CreateFile "myfile" + DELETE_ON_CLOSE
CreateFile "myfile + OPEN_EXISTING
CloseFile "myfile"
CloseFile "myfile

If the order is like above, the CleanUp will not set the flag DeleteOnClose. Here the code causing the problem
https://github.com/dokan-dev/dokany/blob/master/sys/create.c#L591-L597
It's the https://github.com/dokan-dev/dokany/blob/master/sys/create.c#L596 which removes the flag during the second create. To fix this bug, the else line should be removed.
So but now you will get the flag during both CleanUp which may be wrong (example above 3,4). So after this line here https://github.com/dokan-dev/dokany/blob/master/sys/cleanup.c#L106 we need to check if the fcb->FileCount > 1 and if the flag DOKAN_DELETE_ON_CLOSE is set. If this is true, the flag should be removed from eventContext->FileFlags.
Hope you agree :smile:

:tada: Yeah @marinkobabic , it is exactly what is happening! that's sounds like a good fix :smiley:
But is it not possible to have a personnalized flag for each request ? because with your fix, it is always the last cleanup that get the delete on close.

@Liryna
This makes also sense. Only if there is no handle on the file, the file should be removed.
Thanks
Marinko
Von: Liryna<EMAIL_ADDRESS>Gesendet: Montag, 20. Juni 2016 12:57
An: dokan-dev/dokan-dotnet<EMAIL_ADDRESS>Cc: Babic Marinko<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Betreff: Re: [dokan-dev/dokan-dotnet] DeleteOnClose flag (#83)
🎉 Yeah @marinkobabic https://github.com/marinkobabic  , it is exactly what is happening! that's sounds like a good fix 😃
But is it not possible to have a personnalized flag for each request ? because with your fix, it is always the last cleanup that get the delete on close.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/dokan-dev/dokan-dotnet/issues/83#issuecomment-227111546 , or mute the thread https://github.com/notifications/unsubscribe/ADHSOMl-U1CJLnCQ6c35LhM84PrFv3v9ks5qNnHmgaJpZM4I0J_L .  https://github.com/notifications/beacon/ADHSOPNykrd2ul33ROCvwlVPhOTnMdCYks5qNnHmgaJpZM4I0J_L.gif

When the information is on CCB then it should be a personalized information. The question is when does windows delete the file?
CreateFile
CreateFile + DELETE_ON_CLOSE
CloseFile above
Wait 30 Seconds
CloseFile using the handle of the first create.
If the file is closed after the wait, the the fix is fine. If the file is removed before the wait, then we should put the flag on CCB.

I made some test in current status of dokan:
(1) CreateFile
(2) CreateFile + DELETE_ON_CLOSE
(2) CloseFile - Delete flag // DeleteFile ERROR_ACCESS_DENIED
(1) CloseFile - Delete flag

(1) CreateFile + DELETE_ON_CLOSE
(2) CreateFile
(2) CloseFile - No Delete flag
(1) CloseFile - No Delete flag

With this commit:https://github.com/dokan-dev/dokany/commit/f57b054b8d967573ef78e7f1164dfe994f1a9c43
(1) CreateFile
(2) CreateFile + DELETE_ON_CLOSE
(2) CloseFile - Delete flag // DeleteFile ERROR_ACCESS_DENIED
(1) CloseFile

(1) CreateFile + DELETE_ON_CLOSE
(2) CreateFile
(2) CloseFile
(1) CloseFile - Delete flag

So your idea @marinkobabic to put on CCB since to be the good one ! :+1:
Before adding it to master branch, I just would like to know if https://github.com/dokan-dev/dokany/blob/master/sys/create.c#L596 is really needed and what is the purpose of it ? (it seems like the flag on fcb is used for DeletePending)

Hi Liryna
The line makes no sense, so you can remove it. Good job!
Thanks
Marinko
Von Samsung Mobile gesendet

Ok great !
Thank you for you expertise @marinkobabic  :smiley: and @js69 for your report ! It was hard to see :)
Fixed on master with https://github.com/dokan-dev/dokany/commit/59d08ffca07f69c40d9d46e5a687816cb72d0a49


The default keyring directory does not seem unique enough

I'm looking at the instructions for creating a keyring and we have:
$ mkdir -p ~/tf_data_path/
$ echo 'Spectrumscale!' >> ~/tf_data_path/keyring

Then looking at where this default is consumed...
$ cd resources/
$ git grep keyring
common/ansible_vault/ansible_vault.tf:    default = "~/tf_data_path/keyring"
common/ansible_vault/ansible_vault.tf:    description = "Ansible vault keyring file path."
$

My thought here is that tf_data_path is not unique for someone to remember what that directory is.
If the user clones down this repo and follows the steps, it's scattering data around their home directory. At a later time, if they forgot what this is for...  they just see a directory tf_data_path.. it has no meaning, maybe they would just delete it.  🤷♂
Suggest:

If we want to leave in the users home directory, should we do something more unique, also tf expand to terraform
mkdir ~/cloud-install-terraform-data/keyring
...

Move this directory to be under ibm-spectrum-scale-cloud-install repo..
cd ibm-spectrum-scale-cloud-install
mkdir terraform-data
echo 'Spectrumscale!' >> terraform-data/keyring

and add entry into .gitignore: terraform-data* so those files are not picked up as part of the repo files.

@sasikeda  I am able to take this issue if we agree on one of those paths above.


Update introduction.md

Editing VSAN to vSAN for consistency throughout the document.

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

What about this change? Will it be merged?

Looks good. Thanks @sbkuehn


Fixed invalid visual shader outputs (TRANSMISSION, ALPHA_SCISSOR)

(They are renamed to BACKLIGHT and ALPHA_SCISSOR_THRESHOLD respectively) + fixed typo in one place

Thanks!


Review/debug import scripts in Pmag GUI

Go through all of the import scripts in Pmag GUI from start to finish.  There will be bugs.

@ltauxe, I am running through all of the import types in Pmag GUI and fixing bugs.  I'm wondering, what do you want me to do when everything works, but what is coming out looks a bit weird, i.e. the MIT example:

I plotted that data up in another plotting program. It is a really weak low-coercivity poorly behaved sample. The weirdness is in the data not the code.

Thanks, good to know!


Fix versions discrepencies

Versions appear in multiple places:

git tag
Cargo.toml
StructOpt's --version

While StructOpt takes its value from Cargo.toml, it can be different from the latest git tag.
Ideally, the git tag should be the ground truth and others should derive from it. I'm not sure what's the best way to handle this.

Commits 095d7f5, e9db0e5 and 6cc8ab5b84b93850231f19dd99e1162ad4990867 fixes this. Clsoing.

CI fails: https://travis-ci.org/nbigaouette/pycors/jobs/507598369


Add at the speed of paul by kingsammelot

Song Name
at the speed of paul
Artist Name
dimrain47
Source
Direct file download
Youtube Link
view
Direct File Link
https://drive.google.com/file/d/1U5li6uw4CvZFd_aymqDcPy_kZ8NdhZEc/view
Song ID
467339
Start Offset [ms]
0
Extra
Created from Auto Nong.
Created for level: 64763376

reject
Must be a link to a proper CDN, Not Google Drive, Dropbox or MediaFile. Or a YT video


Expose containerViewTapGesture

I have a use case for disabling the recognizer that a user can't close the drawer until the user select a content from the drawer. Would this PR be acceptable?

@ikesyo OK!Thanks always 😄

Thanks too!


feat(dropdown) Add invalid and invalidText inputs

Closes #785

Could you ammend your commit to be feat(dropdown) Add invalid and invalidText inputs ... I was super confused until I looked at the code 😅

@Donisius any reason you closed this?

@cal-smith My mistake, didnt realize I did.


Added release job

Signed-off-by<EMAIL_ADDRESS><EMAIL_ADDRESS>

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages (more info).
[ ] Added or updated documentation.
[ ] Tests for new functionality and regression tests for bug fixes.
[ ] Screenshots or videos attached (for UI changes).
[x] All your commits have a Signed-off-by line in the message (more info).

lgtm


Vuese documentation doest consider description or watch, it only take prop, methods and events

Describe the bug
Vuese documentation doest consider description or watch, it only take prop, methods and events
Expected behavior
It should take component description, component group and watch and computed
Screenshots

Environmental information:
"vuese": "^1.4.7",

Yeah pretty useless to use this, if you have a component lets say that dosent have any methods, props, events vuese will not create any markdown at all...

@jmoidunny
can u update version  to 2.x from ^1.4.7 . And 2.x is fully compatible with 1.x
1.description
Paste the following code on this page, you can see the corresponding description
<template>

</template>

2. 「watch」and 「computed」
The default analysis result does not have watch and computed
For a component that is exposed to other user to import it, watch and computed are not necessary, props are the most important

Here you can know the default analysis result ： https://vuese.org/parser/#parserresult
And If you really need watch and computed options , you can actually add your own personalization ParserOptions

look here: https://vuese.org/parser/#parseroptions

Yeah pretty useless to use this, if you have a component lets say that dosent have any methods, props, events vuese will not create any markdown at all...

Hi  @Quasarman, Generally, No tool can fully meet our needs, but we can optimize it together

Hello @screetBloom,
I don't really know why I wrote this mean comment at that time (maybe I was frustrated).....I am sorry about that. Actually after reading the documentation it basically already states what can be done in order to generate documentation for components that dont have any props. methods, events, whatsoever. After considering all of this it works like a charm! Thank you!
Kinnd regards.


add microdnf update

https://github.com/open-cluster-management/backlog/issues/11537
Signed-off-by: Song Song Li<EMAIL_ADDRESS>

💯 /lgtm

/lgtm

/test test-e2e


Can't run examples

I just tried to clone the repository and run the examples, and I'm getting a webpack error. Traceback is in a gist here. Can you take a look?

No, even after I npm install in the root of the repository, I get the same error. Are you able to reproduce that?

Think I found the problem: the main module of the project's package.json is lib/index.js which is built from the TypeScript source. After a fresh clone and install, the compiled JS file doesn't exist.
Run npm run-script build at the root and that should (I swear this time) fix it.

Yes! That works. However, I had to inspect the dev.server.js file to figure out that I needed to visit port 3001 to actually view the examples. It seems like this workflow needs some more documentation. What's the best place to put that documentation?

How does this work again? I'm running into the same issue. To run the demos I need to:

run npm install in the repo root
run npm run-script build in the repo root
run npm start in /examples

Is this correct?

I got it to work through some fiddling, deleting, installing...etc.
So, the process should be?

run npm install in the repo root
run npm run-script build in the repo root
run npm install in /examples
run npm start in /examples

Yes, that looks right

I got it to work through some fiddling, deleting, installing...etc.
So, the process should be?

run npm install in the repo root
run npm run-script build in the repo root
run npm install in /examples
run npm start in /examples

i got an error:
ERROR in /.../react-mapbox-gl/example/src/demos/htmlCluster.tsx
./src/demos/htmlCluster.tsx
[tsl] ERROR in /.../react-mapbox-gl/example/src/demos/htmlCluster.tsx(80,7)
TS2322: Type 'React.CSSProperties' is not assignable to type 'import("/.../react-mapbox-gl/node_modules/@types/react/index").CSSProperties'.
Types of property 'outlineStyle' are incompatible.
Type 'string | undefined' is not assignable to type '"hidden" | "none" | "inherit" | "-moz-initial" | "initial" | "revert" | "unset" | "dashed" | "dotted" | "double" | "groove" | "inset" | "outset" | "ridge" | "solid" | "auto" | undefined'.
Type 'string' is not assignable to type '"hidden" | "none" | "inherit" | "-moz-initial" | "initial" | "revert" | "unset" | "dashed" | "dotted" | "double" | "groove" | "inset" | "outset" | "ridge" | "solid" | "auto" | undefined'.
ERROR in /.../react-mapbox-gl/example/src/demos/htmlCluster.tsx
./src/demos/htmlCluster.tsx
[tsl] ERROR in /.../react-mapbox-gl/example/src/demos/htmlCluster.tsx(131,15)
TS2322: Type 'React.CSSProperties' is not assignable to type 'import("/.../react-mapbox-gl/node_modules/@types/react/index").CSSProperties'.


x/tools/go/ssa/ssautil: deprecate AllFunctions

I would like to deprecate the AllFunctions helper function, because it's a poorly specified mess (my bad).
As its doc comment says:
// I think we should deprecate AllFunctions function in favor of two
// clearly defined ones:
//
//  1. The first would efficiently compute CHA reachability from a set
//     of main packages, making it suitable for a whole-program
//     analysis context with InstantiateGenerics, in conjunction with
//     Program.Build.
//
//  2. The second would return only the set of functions corresponding
//     to source Func{Decl,Lit} syntax, like SrcFunctions in
//     go/analysis/passes/buildssa; this is suitable for
//     package-at-a-time (or handful of packages) context.
//     ssa.Package could easily expose it as a field.

Before we can consider doing that (which will require a proposal), we should stop using it ourselves in x/tools and x/vuln. Its existing uses are:
// These test could use a simpler ad hoc algorithm, or an efficient CHA:
go/ssa/stdlib_test.go
go/ssa/builder_test.go

// both CHA and static do essentially the same reachability fixed point
// iteration and could do (the good bits of) AllFunctions themselves:
go/callgraph/cha/cha.go -- AllFunctions is not even correct here! see #66429
go/callgraph/static/static.go

--

// VTA uses AllFunctions to produce a set of entry points.
// I suspect it is both a massive overapproximation and yet still not always correct (see #66251)
// What exactly does vta.CallGraph need?
cmd/callgraph/main.go
go/callgraph/vta/vta_test.go
go/callgraph/vta/graph_test.go
go/callgraph/callgraph_test.go
x/vuln/internal/vulncheck/utils.go

// just for debugging; could easily be deleted.
go/callgraph/vta/helpers_test.go

I will tackle the first half. @zpavlinovic perhaps you could look at the VTA-related ones? What we need at this stage is just crisp descriptions of the exact requirements of each of these algorithms.

Related Issues and Documentation

proposal: x/tools/go/ssa/ssautil: Reachable: conservative approximation to reachable functions, runtime types #69291

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Regarding VTA:

the _test files need some set of functions for the test programs. We currently use ssautil.AllFunctions but we could in principle write a simple helper that collects functions for the test programs. These programs are rather simple. Also, we could use #69291.
CL/611216 removes the use of ssautil.AllFunctions for some unnecessary pruning in vulncheck. However, we will have to reintroduce the use of this function soon for a different purpose, i.e., when we try to take advantage of some improvements in VTA. The set of functions passed to VTA will be a forward slice of roots computed using the (copy of) golang.org/x/tools/go/callgraph/internal/chautil.LazyCallees. This function in turn expects a set of program functions. We have to use ssautil.AllFunctions for the time being and deprecate it when #69291 is done.

With my https://go.dev/cl/609281 stack (the last CL needs some thought), there are no remaining uses of AllFunctions in x/tools. (Not even tests of it, alarmingly.)
I notice that AllFunctions returns uninstantiated generics whereas the new chautil.Reachable does not, and for this reason it's probably not safe for us ever to make AllFunctions a wrapper around Reachable; we'll just have to leave it there with a doc explaining what it does and why there are better solutions for most tasks, and what they are.

@adonovan Reading through the current source code, I don't believe the second part of AllFunctions doc comment is available yet.
I was hoping for something like this:
// Func returns the package-level function of the specified name,
// or nil if not found.
func (p *Package) Funcs() ([]*Function) {
	var funcs []*ssa.Function
	for _, f := range p.Members {
	  if f, ok = f.(*Function); ok {
	    funcs = append(funcs, f)
	  }
	}
	return funcs
}

This would be very convenient for some linters to have, so they don't need to waste time calling SrcFunctions in go/analysis/passes/buildssa.


Add fcntl.h include, required for some linux platforms

Amazon Linux, at least, and probably others, requires the fcntl.h include to use the various constants in statx.

@swift-ci test


Sum v1.2 minor update + cache busting fix

Description
v1.2 update:

graphics update
version update in scripts files and pom.xml

cache busting for static assets:

using no-cache header, it will re-validate the static files served every time.

Testing for cache busting:

clear previous cache. Previous cache are still cached in browser, so clear it for the last time ever.
run classifai
open developer console and check the network, refresh and try to see the status 304 is there or not. (304 means validation performed, cached assets and the server one are the same. No update required)

close classifai
Make some changes in the static assets file. I'll suggest changing this file, to get
all the response at the first page https://github.com/CertifaiAI/classifai/blob/main/classifai-core/src/main/resources/webroot/assets/i18n/landing-page-en.json. Don't forget to save the changed file in order to reflect changes
open classifai(using ./startclasifai.sh) and see changes made without clearing cache

Fixes # (issue)
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Tested on?

[ ] Windows
[x] Linux Ubuntu
[ ] Centos
[ ] Mac
[ ] Others  (State here -> xxx )

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged

@devenyantis merge upon approval, and delete current branch too. thanks.