[Bug]: process on ray occur "TypeError: 'str' object cannot be interpreted as an integer"

[laolv421]

[Bug]: process on ray occur "TypeError: 'str' object cannot be interpreted as an integer"

[laolv421]

@garyzhang99 It worked, thanks a lot.

[garyzhang99]

I was unable to reproduce this bug when running the command. Could you try running it again after executing pip install -v -e .[sci]?

[laolv421]

I was unable to reproduce this bug when running the command. Could you try running it again after executing pip install -v -e .[sci]?

This error occured again after I executed pip install -v -e .[sci].

• ray version=2.7.0
• python version=3.8.18
• data juicer =0.2.0

This error is weird, after I commented line 83, it will raise error from line 88.

[garyzhang99]

I was unable to reproduce this bug when running the command. Could you try running it again after executing pip install -v -e .[sci]?

This error occured again after I executed pip install -v -e .[sci].

• ray version=2.7.0
• python version=3.8.18
• data juicer =0.2.0

This error is weird, after I commented line 83, it will raise error from line 88.

When using Ray in a distributed setting, due to Ray's feature (Ray future), Ray does not compute directly at the corresponding line of code. Instead, the computation is performed when the result is called. After you commented out line 83, the computation that was originally performed at line 83 is executed at line 88, leading to an error at line 88, whereas the actual error should have occurred before line 83.

The error reporting mechanism of Ray makes it difficult to pinpoint the corresponding error. Could you try not using Ray first and run the corresponding code in a single-machine version to see if there are more complete error messages?

[laolv421]

I was unable to reproduce this bug when running the command. Could you try running it again after executing pip install -v -e .[sci]?

This error occured again after I executed pip install -v -e .[sci].

• ray version=2.7.0
• python version=3.8.18
• data juicer =0.2.0

This error is weird, after I commented line 83, it will raise error from line 88.

When using Ray in a distributed setting, due to Ray's feature (Ray future), Ray does not compute directly at the corresponding line of code. Instead, the computation is performed when the result is called. After you commented out line 83, the computation that was originally performed at line 83 is executed at line 88, leading to an error at line 88, whereas the actual error should have occurred before line 83.

The error reporting mechanism of Ray makes it difficult to pinpoint the corresponding error. Could you try not using Ray first and run the corresponding code in a single-machine version to see if there are more complete error messages?

Thanks for your advice. I have tested the code without Ray, and everything worked as expected, normally. I then double-checked the demo.yaml file, modified ray_address: 'ray://localhost:10001' to ray_address: 'auto' and ran the code. Everything worked normally except for two operators with models, namely, language_id_score_filter and perplexity_filter. When I commented out these two operators, it worked fine. I conducted unit tests on both operators, and they both worked. But on the local ray, they were unable to find the model.

# language_id_score_filter
  File "/home/lzj/project/open-source/data-juicer/data_juicer/ops/filter/language_id_score_filter.py", line 53, in compute_stats
    raise ValueError(err_msg)
ValueError: Model not loaded. Please retry later.
# perplexity_filter
  File "/home/lzj/project/open-source/data-juicer/data_juicer/ops/filter/perplexity_filter.py", line 71, in compute_stats
    logits += kenlm_model.score(line)
AttributeError: 'NoneType' object has no attribute 'score'

[garyzhang99]

Based solely on the provided description, we have not been able to reproduce the bug, nor can we pinpoint the specific issue. It appears it might be an environmental problem or an issue with the get_model and check_model functions. Could you provide more information?

Additionally, I would like to ask whether CUDA is enabled in your local environment and whether the corresponding Data-Juicer version is up to date.

[laolv421]

Based solely on the provided description, we have not been able to reproduce the bug, nor can we pinpoint the specific issue. It appears it might be an environmental problem or an issue with the get_model and check_model functions. Could you provide more information?

Additionally, I would like to ask whether CUDA is enabled in your local environment and whether the corresponding Data-Juicer version is up to date.

• torch.cuda.is_available() = True
• data-juicer = v0.2.0
  Here are the screenshots. I hope they are helpful for you.
  
  
  
  

[garyzhang99]

Based solely on the provided description, we have not been able to reproduce the bug, nor can we pinpoint the specific issue. It appears it might be an environmental problem or an issue with the get_model and check_model functions. Could you provide more information?
Additionally, I would like to ask whether CUDA is enabled in your local environment and whether the corresponding Data-Juicer version is up to date.

• torch.cuda.is_available() = True
• data-juicer = v0.2.0
  Here are the screenshots. I hope they are helpful for you.
  
  
  
  

It looks like the issue may be because you are using an older version of data-juicer, which previously did not have good support for CUDA in the Ray distributed version. You can try these two solutions separately：

• Pull the latest data-juicer code from the main branch on GitHub, then build from source (pip install -v -e .).
• Avoid using CUDA by setting the use_cuda related configurations to False in the code and modifying the CUDA environment variables accordingly.

It should be able to solve your problem.