Master 01

PR Summary
PR Overview
This PR is a chore :broom:
Change Details

Major Changes
Description

llmchain_with_history.py
This diff replaces the import of ChatOpenAI from langchain.chat_models with a function get_ChatOpenAI from server.utils. It also removes some unnecessary parameters from the instantiation of model and adds a new parameter temperature to the get_ChatOpenAI function call.

init.py
This diff adds imports for basic_config, kb_config, and prompt_config modules to the configs/__init__.py file. It also updates the VERSION variable to "v0.2.5" and adds a new TAG variable with the value ["desmond_test"].

copy_config_example.py
This diff adds a Python script that copies all files in the "configs" directory that have a ".example" extension and renames them to remove the extension. The script uses the "os" and "shutil" modules to accomplish this.

init_database.py
This diff adds new command line arguments to the argparse module in the init_database.py file. The new arguments are -r for recreating the vector store, -u for updating the vector store for files that exist in the database, and -i for updating the vector store for files that exist in the local folder but not in the database.

callbacks.py
This diff adds a new class CustomAsyncIteratorCallbackHandler which inherits from AsyncIteratorCallbackHandler. It also defines a new class Status with integer constants. The CustomAsyncIteratorCallbackHandler class has three new attributes: queue, done, and cur_tool. It also defines three new methods: on_tool_start, on_tool_end, and on_tool_error. The on_tool_start method initializes the cur_tool attribute with some values and puts it in the queue. The on_tool_end method updates the cur_tool attribute with some values and puts it in the queue. The on_tool_error method is not complete and is truncated in the diff.

custom_template.py
This diff adds two new classes, CustomPromptTemplate and CustomOutputParser, to the custom_template.py file. CustomPromptTemplate is a subclass of StringPromptTemplate and adds functionality to format intermediate steps and create a list of tools. CustomOutputParser is a subclass of AgentOutputParser and adds functionality to check if the agent should finish and parse out the action and action input.

google_search.py
This diff adds import statements for the os module and sets two environment variables for Google Custom Search Engine ID and API key. It also imports the GoogleSearchResults class from an external module and defines a new function google_search that uses this class to run a search query. No new line is added at the end of the file.

math.py
This diff adds imports for several modules and defines a new function calculate that takes a string parameter query, creates a ChatOpenAI model using get_ChatOpenAI function, creates a LLMMathChain object using the LLMMathChain.from_llm method, runs the query using the run method of llm_math object, and returns the result. It also defines a PromptTemplate object for generating prompts.

shell.py
This diff adds a new function shell to the file server/agent/shell.py. The function imports ShellTool from langchain.tools and uses it to run a shell command specified by the query parameter.

tools.py
This diff adds imports and creates a list of tools with their respective functions, names, and descriptions. It also creates a list of tool names.

translator.py
This diff adds a new function translate to the file server/agent/translator.py. The function takes a string parameter query and uses the get_ChatOpenAI function from server/utils.py to get a model for translation. It then uses the LLMChain class from langchain/chains.py to translate the query and returns the result. The PromptTemplate class from langchain/prompts.py is used to define the input variables and template for the translation prompt.

weather.py
This diff adds code for querying weather using the HeFeng weather API. It imports various modules and defines functions for getting city information and formatting weather data. It also includes some code for calculating time differences.

api.py
This diff contains changes in the file server/api.py. It adds a new function agent_chat to the chat module. It also renames the function list_llm_models to list_running_models and adds a new function list_config_models to the llm_api module. Finally, it removes the summary parameter from the stop function in the llm_api module.

init.py
This diff adds a new import statement for the module agent_chat in the file server/chat/__init__.py.

agent_chat.py
This diff adds imports and new function parameters to the agent_chat function in server/chat/agent_chat.py. It also defines a new async iterator function agent_chat_iterator.

chat.py
This diff contains changes in the import statements and function parameters of the file server/chat/chat.py. The import statements for model_config and chat_models have been changed to configs and chains respectively. The function get_ChatOpenAI has been added to the import statements from server.utils. The function create_database has been renamed to get_prompt_template and a new parameter prompt_name has been added to it. The parameter force has been removed from the function parameters.

knowledge_base_chat.py
This diff contains changes in the function knowledge_base_chat in the file server/chat/knowledge_base_chat.py. It adds parameters prompt_name and local_doc_url to the function, and removes imports of unused modules. It also changes the order of some parameters and modifies the range of the temperature parameter.

openai_chat.py
This diff adds imports for get_model_worker_config and fschat_openai_api_address from server.utils and uses them to set the api_key and api_base values for the openai module in the openai_chat function. It also removes the import for llm_model_dict and replaces it with a call to get_model_worker_config to retrieve the api_key value. Finally, it removes the log_verbose import and the print statements for openai.api_key and openai.api_base.

search_engine_chat.py
This diff contains changes in the function search_engine_chat in the file server/chat/search_engine_chat.py. It adds a new parameter prompt_name to the function with a default value of "knowledge_base_chat". It also changes the validation of the temperature parameter to be greater than or equal to 0.0.

utils.py
This diff removes the function wrap_done and its import of asyncio and typing.Awaitable. It also removes the try-except block that catches exceptions and sets an event.

base.py
This diff changes the import statement for SQLALCHEMY_DATABASE_URI in server/db/base.py from configs.model_config to just configs. It also removes an unused import for json.

kb_api.py
This diff contains a change in the import statement of EMBEDDING_MODEL, logger, and log_verbose from configs.model_config to configs. It also removes the import statement for Body from fastapi.

base.py
This diff contains changes in the file server/knowledge_base/kb_cache/base.py. The changes include importing modules from different locations, adding a new property key to the class, and modifying the acquire method to use the key property instead of the _key attribute. Additionally, there is a commented out line of code that was not removed.

faiss_cache.py
This diff contains changes in the ThreadSafeFaiss and KBFaissPool classes in the faiss_cache.py file. The changes include modifying the __repr__ method to use the key attribute instead of _key, modifying the save and clear methods to use the key attribute instead of _key, and adding a new vector_name parameter to the load_vector_store method in the KBFaissPool class.

kb_doc_api.py
This diff contains changes in the import statements and function parameters of the file kb_doc_api.py. The import statements have been updated to import from a different module. The parameters of the upload_docs function have been changed to use Form instead of Body. The docs parameter has been updated to require a JSON string.

base.py
This diff contains changes in the import statements of the file base.py. The imports from model_config are now imported from configs.

faiss_kb_service.py
This diff adds a new attribute vector_name to the FaissKBService class and uses it to modify the get_vs_path method to return a path based on the value of vector_name. It also modifies the load_vector_store method to include the vector_name parameter when calling kb_faiss_pool.load_vector_store.

milvus_kb_service.py
This diff changes the import statement for SCORE_THRESHOLD and kbs_config in milvus_kb_service.py and comments out the save_vector_store function.

pg_kb_service.py
This diff updates the import statement for kbs_config in pg_kb_service.py to import it from configs instead of configs.model_config.

migrate.py
This diff contains changes in the import statements of the file migrate.py. It also adds default values to some parameters in the folder2db function and removes the SupportedVSType import. Additionally, it disables the fill_info_only option in the mode parameter.

utils.py
This diff contains changes in the imports and function definitions of the file server/knowledge_base/utils.py. It imports configs instead of model_config and adds a new parameter llm_model to the function make_text_splitter(). It also modifies the function get_vs_path() to take a new parameter vector_name.

llm_api.py
This diff contains changes in the llm_api.py file. It renames the list_llm_models function to list_running_models and adds a new function list_config_models. It also replaces the httpx library with a custom get_httpx_client function for making HTTP requests. Finally, it updates the stop_llm_model function to use the new get_httpx_client function.

init.py
This diff adds two new worker classes, FangZhouWorker and QwenWorker, to the server/model_workers/__init__.py file.

baichuan.py
This diff adds import statements for various modules, defines a function to calculate MD5 hash, and adds a function to make a request to an API. It also defines a class BaiChuanWorker that inherits from ApiModelWorker and initializes with certain parameters.

base.py
This diff changes the import statement for LOG_PATH from model_config to basic_config in base.py. It also fixes a typo in the error message by changing "unknow" to "unknown".

fangzhou.py
This diff adds a new function request_volc_api which sends a request to a VolcEngine API and returns a response. It also adds a new class FangZhouWorker which inherits from ApiModelWorker and defines a new method __init__ with some new parameters.

minimax.py
This diff replaces the import of httpx with a call to get_httpx_client from server.utils in the minimax.py file. It also modifies the response variable to use the client object returned by get_httpx_client. The rest of the code remains the same.

qianfan.py
This diff adds a new import statement for get_httpx_client function from server.utils module. It also replaces the httpx.get function call with a client.get call inside the get_baidu_access_token function and replaces the httpx.stream function call with a client.stream call inside the request_qianfan_api function. These changes are made to use a shared httpx client instance for better performance. Additionally, it adds a new yield statement with an error message in the request_qianfan_api function if the access token is not obtained successfully.

qwen.py
This diff adds a new function request_qwen_api which sends messages to a Qwen API and returns the response. It also adds a new class QwenWorker which inherits from ApiModelWorker and initializes with some parameters.

xinghuo.py
This diff changes the port number of the worker address in the XingHuoWorker function from 20005 to 21003. It also updates the port number in the uvicorn.run function accordingly.

zhipu.py
This diff changes the worker address from port 20003 to port 21001 in the get_embeddings function of the zhipu.py file.

utils.py
This diff contains changes in the server/utils.py file. It adds a new function wrap_done which wraps an awaitable with an event to signal when it's done or an exception is raised. It also adds a new function get_ChatOpenAI which returns a ChatOpenAI object with specified parameters. The function uses get_model_worker_config to get the configuration for the specified model and creates a ChatOpenAI object with the specified parameters.

startup.py
This diff contains changes in the import statements of the file startup.py. The imports have been reorganized and grouped together. Additionally, the function create_model_worker_app has been modified to include a new parameter kwargs which contains fields such as host, port, model_names, controller_address, worker_address, online_api, worker_class, model_path, and device. The function has also been modified to remove some unnecessary imports and a workaround for program exit with Ctrl+c.

test_agent_function.py
This diff adds a new test function test_different_agent_function to the file tests/agent/test_agent_function.py. The function tests different agent functions such as weather, calculation, and translation. It imports various modules and creates instances of classes such as LLMChain, LLMSingleActionAgent, and AgentExecutor. The function uses pytest to run the tests and asserts that the text answer is not None.

test_kb_api.py
This diff changes the import statement for VECTOR_SEARCH_TOP_K from configs.model_config to configs. It also removes unused imports and adds an import for pprint.

test_kb_api_request.py
This diff changes the import statement for VECTOR_SEARCH_TOP_K in the test_kb_api_request.py file. It now imports it from configs instead of model_config.

test_llm_api.py
This diff removes the import of llm_model_dict and the function get_configured_models now returns a list of strings instead of a tuple. It also simplifies the logic for finding available new models in the test_change_model function.

test_stream_chat_api.py
This diff contains changes in the file test_stream_chat_api.py. It imports BING_SUBSCRIPTION_KEY from a different location and modifies the test_knowledge_chat and test_search_engine_chat functions to fix a typo and add an f-string respectively.

test_different_splitter.py
This diff changes the import statement in the file tests/custom_splitter/test_different_splitter.py. It replaces the import of a specific module (model_config) with a more general import of the configs package.

test_fangzhou.py
This diff adds an import statement for Path and sys modules, and appends the root path to the system path. It also imports request_volc_api function from server.model_workers.fangzhou module, and adds a test function test_qianfan with a parameterized mark. The test function sends a message to the request_volc_api function and prints the response. It also asserts that the response contains a message choice.

test_qianfan.py
This diff changes the test_qianfan function in the test_qianfan.py file. It modifies the @pytest.mark.parametrize decorator to only use the first two keys of the MODEL_VERSIONS dictionary. The function itself remains the same, printing a message with the version parameter.

test_qwen.py
This diff adds an import statement for Path and sys modules, and appends the root path to the system path. It also imports request_qwen_api function from server.model_workers.qwen module and adds a test function test_qwen that uses request_qwen_api to send a message and assert the response code is 200. The test function is parameterized with a version string.

test_migrate.py
This diff adds test functions test_recreate_vs and test_increament to the tests/test_migrate.py file. It also imports modules and defines variables for setting up a test knowledge base, copies test files to the knowledge base, and uses folder2db to migrate the knowledge base. The test functions assert that the migration was successful by checking the existence of files and documents in the knowledge base.

dialogue.py
This diff contains changes in the function get_messages_history in the file webui_pages/dialogue/dialogue.py. It adds a new parameter content_in_expander to control whether to return the content in the expander element or not. It also simplifies the message filtering process and removes unnecessary code.

knowledge_base.py
This diff contains changes in the imports of the file knowledge_base.py. It replaces the import of embedding_model_dict from model_config with the import of list_embed_models from server.utils. It also removes the import of get_file_path and LOADER_DICT from utils. Additionally, it removes the import of os and time. Finally, it adds an import of kbs_config, EMBEDDING_MODEL, DEFAULT_VS_TYPE, CHUNK_SIZE, OVERLAP_SIZE, and ZH_TITLE_ENHANCE from configs.

utils.py
This diff contains changes in the imports of the file webui_pages/utils.py. It removes the import of llm_model_dict from configs.model_config and adds imports for FSCHAT_MODEL_WORKERS and HTTPX_DEFAULT_TIMEOUT from configs. It also changes the function set_httpx_timeout() to set_httpx_config() and adds two new methods _client and _aclient to the ApiRequest class. Finally, it replaces the calls to httpx with calls to the newly added _client and _aclient methods.

Changes
Description

Change File List
Added files:

configs/basic_config.py.example
configs/kb_config.py.exmaple
configs/prompt_config.py.example
copy_config_example.py
docs/自定义Agent.md
img/official_account.png
img/qr_code_64.jpg
server/agent/callbacks.py
server/agent/custom_template.py
server/agent/google_search.py
server/agent/math.py
server/agent/shell.py
server/agent/tools.py
server/agent/translator.py
server/agent/weather.py
server/chat/agent_chat.py
server/model_workers/baichuan.py
server/model_workers/fangzhou.py
server/model_workers/qwen.py
tests/agent/test_agent_function.py
tests/online_api/test_fangzhou.py
tests/online_api/test_qwen.py
tests/test_migrate.py

Deleted files:

img/qr_code_61.jpg
img/qr_code_62.jpg

Modified files:

README.md
README_en.md
chains/llmchain_with_history.py
configs/init.py
configs/model_config.py.example
configs/server_config.py.example
docs/FAQ.md
init_database.py
requirements.txt
requirements_api.txt
requirements_webui.txt
server/api.py
server/chat/init.py
server/chat/chat.py
server/chat/knowledge_base_chat.py
server/chat/openai_chat.py
server/chat/search_engine_chat.py
server/chat/utils.py
server/db/base.py
server/knowledge_base/kb_api.py
server/knowledge_base/kb_cache/base.py
server/knowledge_base/kb_cache/faiss_cache.py
server/knowledge_base/kb_doc_api.py
server/knowledge_base/kb_service/base.py
server/knowledge_base/kb_service/faiss_kb_service.py
server/knowledge_base/kb_service/milvus_kb_service.py
server/knowledge_base/kb_service/pg_kb_service.py
server/knowledge_base/migrate.py
server/knowledge_base/utils.py
server/llm_api.py
server/model_workers/init.py
server/model_workers/base.py
server/model_workers/minimax.py
server/model_workers/qianfan.py
server/model_workers/xinghuo.py
server/model_workers/zhipu.py
server/utils.py
startup.py
tests/api/test_kb_api.py
tests/api/test_kb_api_request.py
tests/api/test_llm_api.py
tests/api/test_stream_chat_api.py
tests/custom_splitter/test_different_splitter.py
tests/online_api/test_qianfan.py
webui_pages/dialogue/dialogue.py
webui_pages/knowledge_base/knowledge_base.py
webui_pages/utils.py

Code Review (preview)
This feature is still under test. Suggestions are given by AI and might be incorrect.
chains/llmchain_with_history.py
Based on the code diff, it seems that the author has made some changes to the imports and the way the ChatOpenAI model is initialized. Instead of importing the ChatOpenAI model directly from the langchain module, the author is now importing it from the server.utils module. Additionally, the author is now passing the model_name and temperature parameters to the get_ChatOpenAI function instead of directly initializing the ChatOpenAI object.
Overall, these changes seem reasonable and should not cause any issues. However, it would be helpful if the author provided more context on why these changes were made and if there were any specific issues or bugs that were addressed.
One suggestion for the author would be to add some comments to the code to explain the purpose of the changes and any relevant information about the ChatOpenAI model and its usage. This would make it easier for future developers to understand the code and make any necessary modifications.
configs/init.py
The code change looks correct. However, it would be helpful if the author could provide some context on why they added the new imports and the new TAG variable. Additionally, it would be good to ensure that the new imports are being used correctly throughout the codebase.
copy_config_example.py
The code change looks correct and achieves the intended purpose of copying all files with the ".example" extension in the "configs" directory and renaming them to remove the extension.
One suggestion for the author would be to add some error handling in case the "configs" directory does not exist or if there are no files with the ".example" extension. This can prevent the script from crashing and provide a more user-friendly experience.
Another suggestion would be to add some comments to explain the purpose of the code and how it works, especially for future maintainers who may not be familiar with the code.
init_database.py
The code change looks correct. However, here are some suggestions for the author:

Add comments to the code to explain what each function does and how it is used.
Consider using a logging module instead of print statements for better debugging and error handling.
Use more descriptive variable names to improve code readability.
Consider adding error handling for cases where the specified knowledge base name does not exist.
Consider adding a confirmation prompt before executing the prune-db and prune-folder options to prevent accidental deletion of data.

server/agent/callbacks.py
The code change looks correct. Here are some suggestions for the author:

Consider adding type annotations to the self.cur_tool dictionary in the CustomAsyncIteratorCallbackHandler class. This will make the code more readable and easier to maintain.

Consider using asyncio.create_task instead of asyncio.ensure_future for better performance and readability.

Consider using async with self.queue instead of self.queue.put_nowait for better synchronization and error handling.

Consider using asyncio.Event.wait instead of asyncio.sleep for better performance and responsiveness.

Overall, the code change looks good and follows best practices for asynchronous programming in Python.
server/agent/custom_template.py
The code change looks correct. However, here are some suggestions for the author:

Add docstrings to the classes and methods to improve code readability and maintainability.
Use type hints for the variables and return types to improve code clarity and avoid potential bugs.
Consider using f-strings instead of string concatenation for better performance and readability.
Use more descriptive variable names instead of abbreviations like "ans".
Consider adding error handling for potential exceptions in the code.

server/agent/google_search.py
As an AI language model, I cannot determine whether the code change is correct or not without additional context. However, I can provide some suggestions to the author based on the code diff provided.

It is not recommended to hardcode sensitive information like API keys and IDs in the code. It would be better to store them in a separate configuration file or use environment variables.
It is good practice to include a newline at the end of the file to avoid any potential issues with certain tools or systems.
It would be helpful to include comments or documentation to explain the purpose and functionality of the code.

server/agent/math.py
Based on the code diff, it seems that the author has added a new function calculate that uses the LLMMathChain class from the langchain.chains module to solve math problems. The function takes a string query as input and returns the answer to the math problem.
One suggestion for the author is to add some error handling to the calculate function. For example, if the input query is not a valid math expression, the function should return an error message instead of crashing.
Another suggestion is to add some unit tests for the calculate function to ensure that it works correctly for different types of math problems.
Overall, the code change looks good, but adding error handling and unit tests would make the function more robust and reliable.
server/agent/shell.py
The code change looks correct. However, it would be helpful to add some comments to explain the purpose of the shell function and how it is used. Additionally, it would be good to add some error handling in case the ShellTool fails to run.
server/agent/tools.py
The code change looks correct. However, here are some suggestions for the author:

Instead of using multiple os.path.dirname calls, the author can use os.path.join to navigate to the desired directory.
It's a good practice to add comments to the code to explain what each function does.
The author can consider adding more tools to the list if needed in the future.

server/agent/translator.py
The code change looks good overall. Here are some suggestions for the author:

It's a good practice to add comments to the code to explain what each section of the code does. This can help other developers understand the code more easily.

It's also a good practice to add some error handling to the code. For example, if the query parameter is empty or None, the translate function should return an error message instead of trying to run the LLMChain.

The _PROMPT_TEMPLATE variable could be moved to a separate file or module to make it easier to maintain and update in the future.

The get_ChatOpenAI function is not defined in the code diff, so it's unclear what it does. The author should make sure that this function is defined and working correctly.

Finally, the author should consider adding some unit tests to the code to ensure that it works correctly in different scenarios.

server/agent/weather.py
Based on the code diff, it seems like the author is adding a new feature to query weather using the HeFeng weather API. Here are some suggestions for the author:

It's good to see that the author has added comments to explain the purpose of the code. However, some of the comments are in Chinese, which might make it difficult for non-Chinese speakers to understand. It's better to use English comments to make the code more accessible to a wider audience.

The author has imported several modules, but some of them are not used in the code. It's better to remove the unused imports to make the code cleaner.

The get_city_info function seems to be unused in the code. It's better to remove it to avoid confusion.

The format_weather_data function is doing a lot of work, including formatting the weather data and calculating the time difference between the forecast time and the current time. It's better to split this function into smaller functions to make it more modular and easier to test.

The get_weather function is returning formatted weather data. It's better to separate the formatting logic from the API call logic to make the code more modular and easier to test.

The split_query function is splitting the query string into location, adm, and time. It's better to add some error handling to this function to avoid unexpected behavior if the query string is not in the expected format.

The weather function is calling the split_query function to get the location, adm, and time from the query string. It's better to add some error handling to this function to avoid unexpected behavior if the query string is not in the expected format.

The weather function is returning a string if there is an error or if the API call fails. It's better to raise an exception instead of returning a string to make it easier to handle errors in the calling code.

The KEY variable is defined but not initialized. It's better to add a comment explaining that the user needs to fill in their HeFeng weather API key in this variable before running the code.

Overall, the code looks good, but there is room for improvement in terms of modularity, error handling, and documentation.
server/api.py
The code change looks correct. However, I would suggest adding some comments to the code to make it more readable and understandable for other developers who may work on the code in the future. Additionally, it would be helpful to add some documentation to the API endpoints to explain their purpose and expected input/output.
server/chat/init.py
The code change looks correct as it simply adds a new import statement for the agent_chat module. However, it's recommended to add a newline at the end of the file to follow PEP 8 guidelines. So, the code should be modified to add a newline at the end of the file after the new import statement.
server/chat/agent_chat.py
As an assistant code reviewer, here are my suggestions for the code diff:

It's good that you imported all the necessary modules and libraries at the beginning of the code.

It's better to add comments to explain the purpose of each function and variable.

In the agent_chat function, it's better to use a default value for the prompt_name parameter instead of using it as a function argument.

It's better to use more descriptive variable names instead of using abbreviations like LLM_MODEL and TEMPERATURE.

It's better to use type hints consistently throughout the code.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

It's better to use async with instead of asyncio.create_task to manage the lifecycle of the AgentExecutor object.

server/chat/chat.py
The code change looks correct. However, I would suggest adding some comments to explain the changes made and the reasoning behind them. Additionally, it would be helpful to update the import statements to reflect the changes made in the code. Finally, it would be good to ensure that the new code is properly tested before merging it into the main branch.
server/chat/knowledge_base_chat.py
Based on the code diff, it seems that the author has made some changes to the knowledge_base_chat function in server/chat/knowledge_base_chat.py. Here are my observations and suggestions:

The author has removed some imports related to the llm_model_dict and PROMPT_TEMPLATE. This suggests that these variables are no longer used in the function. It would be good to confirm this with the author and remove any unnecessary code.

The author has made some changes to the imports, specifically importing LLM_MODEL, VECTOR_SEARCH_TOP_K, SCORE_THRESHOLD, and TEMPERATURE from configs instead of configs.model_config. This is a good change as it simplifies the imports.

The author has changed the import for ChatOpenAI from langchain.chat_models to server.utils. It's not clear why this change was made, but it would be good to confirm with the author and make sure that the import is correct.

The author has changed the import for LLMChain from langchain to langchain.chains. This is a good change as it makes the import more specific.

The author has added a new parameter prompt_name to the function. This parameter is used to specify the name of the prompt template to use, which is defined in configs/prompt_config.py. This is a good addition as it allows for more flexibility in the prompts used by the function.

The author has changed the temperature parameter to have a lower bound of 0.0 instead of 0.1. This is a good change as it allows for more flexibility in the temperature used by the function.

The author has made some changes to the knowledge_base_chat_iterator function, specifically removing the kb parameter and using the get_ChatOpenAI function instead of creating a new ChatOpenAI object. It's not clear why these changes were made, but it would be good to confirm with the author and make sure that the changes are correct.

Overall, the changes made by the author seem reasonable and improve the function. However, it would be good to confirm some of the changes with the author and make sure that they are correct.
server/chat/openai_chat.py
Based on the code diff, it seems that the author has made changes to import statements and added a new import statement for server.utils. The author has also made changes to the openai_chat function to use get_model_worker_config function from server.utils to get the API key and API base URL for the model.
One suggestion for the author is to remove the print statements used for debugging purposes before committing the code. These statements can clutter the console output and should not be included in the final code.
Another suggestion is to add some error handling in case the get_model_worker_config function returns None or if the API key or API base URL is not found in the returned dictionary.
Overall, the code change seems correct and the author has made good use of the server.utils module to simplify the code.
server/chat/search_engine_chat.py
Based on the code diff, it seems that the author has made some changes to the search_engine_chat function and its related functions. Here are some suggestions for the author:

In the import statements, it is better to group the related imports together. For example, the imports related to model_config can be grouped together, and the imports related to server.utils can be grouped together.

In the search_engine_chat function, there is a new parameter prompt_name. However, it is not used in the function body. The author should either remove this parameter or use it in the function.

In the search_engine_chat_iterator function, the model object is created using the ChatOpenAI class. However, in the code diff, the get_ChatOpenAI function is used instead. It is not clear what this function does and whether it is a replacement for the ChatOpenAI class. The author should provide more information about this function and its purpose.

In the search_engine_chat_iterator function, the input_msg variable is created using the PROMPT_TEMPLATE constant. However, in the code diff, the get_prompt_template function is used instead. It is not clear what this function does and whether it is a replacement for the PROMPT_TEMPLATE constant. The author should provide more information about this function and its purpose.

In the search_engine_chat_iterator function, the chat_prompt variable is created using the ChatPromptTemplate class. However, it is not clear what this class does and whether it is necessary for the function. The author should provide more information about this class and its purpose.

In the search_engine_chat_iterator function, the task variable is created using the asyncio.create_task function. However, it is not clear what this task does and whether it is necessary for the function. The author should provide more information about this task and its purpose.

Overall, the code diff seems to introduce some new functions and parameters, but it is not clear how they fit into the existing codebase. The author should provide more information and documentation to help reviewers understand the changes.
server/chat/utils.py
Based on the code diff, it seems that the wrap_done function has been removed and the asyncio import is no longer needed. This change looks correct as the wrap_done function is not being used anywhere in the code and the asyncio import is not necessary for the remaining code in the file.
One suggestion for the author would be to remove the unused imports from the typing module as well. This can help to keep the code clean and easier to read.
server/db/base.py
As an AI language model, I cannot access the author's intention or the entire codebase. However, based on the code diff provided, it seems that the author has changed the import statement for SQLALCHEMY_DATABASE_URI from configs.model_config to just configs. This change seems reasonable as it could simplify the import statement and make it more readable.
One suggestion for the author would be to ensure that the SQLALCHEMY_DATABASE_URI variable is still defined and accessible in the new import statement. It would also be helpful to check if any other parts of the codebase rely on the old import statement and update them accordingly.
server/knowledge_base/kb_api.py
The code change looks correct as it simply changes the import statement for the EMBEDDING_MODEL, logger, and log_verbose variables from the model_config module to the configs module.
However, it would be good to check if the configs module actually contains these variables and if they are being used correctly in the code. Additionally, it would be helpful to ensure that the import statements for the other modules are still correct and that the code is still functioning as expected after this change.
server/knowledge_base/kb_cache/base.py
Based on the code diff, it seems that the changes made are correct. However, I have a few suggestions for the author:

It would be better to add comments explaining the purpose of the code changes, especially for the changes made in the load_embeddings function.

In the load_embeddings function, the model parameter is used to determine which type of embeddings to load. It might be a good idea to add some validation to ensure that only valid models are passed as arguments.

The query_instruction parameter in the HuggingFaceBgeEmbeddings constructor is set based on the language of the model. It might be better to have a separate function to handle this logic, especially if more languages are added in the future.

Overall, the code changes seem to be well-implemented and should improve the functionality of the kb_cache module.
server/knowledge_base/kb_cache/faiss_cache.py
The code change looks correct. However, I have a few suggestions for the author:

In the ThreadSafeFaiss class, the key attribute is being accessed directly in the __repr__ method. It might be better to use the self.key attribute instead of self._key to be consistent with the rest of the code.

In the ThreadSafeFaiss class, the save and clear methods are logging the same message with the self._key attribute. It might be better to define a constant for this message and use it in both methods to avoid duplication.

In the KBFaissPool class, the load_vector_store method is using a tuple (kb_name, vector_name) as the cache key instead of a string concatenation. This is a good practice to avoid issues with string concatenation and to make the code more readable.

In the KBFaissPool class, the load_vector_store method is using the get_vs_path function to get the path to the vector store. It might be better to define a constant for the vector store path and use it in both the load_vector_store and unload_vector_store methods to avoid duplication.

In the worker function, the range function is being used with the 1 as the start value. It might be better to use 0 as the start value to avoid off-by-one errors.

Overall, the code change looks good and the suggestions are minor improvements that can make the code more readable and maintainable.
server/knowledge_base/kb_doc_api.py
The code change looks correct. However, I have a few suggestions for the author:

In the upload_docs function, the docs parameter is described as "自定义的docs，需要转为json字符串" but the example provided is a Python dictionary. It might be better to provide an example that is a JSON string to avoid confusion.

In the update_docs function, the file_names parameter is described as "文件名称，支持多文件" but the example provided is a list of lists. It might be better to provide an example that is a list of strings to match the description.

In the recreate_vector_store function, the not_refresh_vs_cache parameter is described as "暂不保存向量库（用于FAISS）" but it might be helpful to provide more context on what this parameter does and why it is useful for FAISS.

Overall, the code change looks good and these suggestions are minor improvements that could make the code more clear and user-friendly.
server/knowledge_base/kb_service/base.py
Based on the code diff, it seems that the author has made a change to the import statements in the file server/knowledge_base/kb_service/base.py. Specifically, they have changed the import statement for the model_config module from "from configs.model_config" to "from configs".
This change seems correct as it simplifies the import statement and makes it more concise. However, it's important to ensure that this change doesn't break any other parts of the code that rely on the old import statement.
As a suggestion, the author could run the test suite to ensure that all tests pass after making this change. Additionally, they could review any other files that import from the model_config module to ensure that they are not affected by this change.
server/knowledge_base/kb_service/faiss_kb_service.py
Based on the code diff, it seems that the author has added a new variable vector_name to the FaissKBService class and used it in the get_vs_path method instead of hardcoding the string "vector_store". This is a good change as it makes the code more flexible and easier to maintain.
In addition, the author has also modified the load_vector_store method to pass the vector_name parameter to the kb_faiss_pool.load_vector_store method. This is also a good change as it ensures that the correct vector store is loaded.
However, I would suggest that the author add a default value for the vector_name parameter in the FaissKBService class constructor, so that it can be overridden if needed. For example:
class FaissKBService(KBService):
    def __init__(self, kb_name: str, embed_model: str, vector_name: str = "vector_store"):
        self.kb_name = kb_name
        self.embed_model = embed_model
        self.vector_name = vector_name
        self.vs_path = self.get_vs_path()
        self.kb_path = self.get_kb_path()

This way, if the vector_name parameter is not provided when creating a new FaissKBService object, it will default to "vector_store".
Overall, the code change looks good and the author has made some good improvements to the code.
server/knowledge_base/kb_service/milvus_kb_service.py
Based on the code diff, it seems that the author has made a change to import SCORE_THRESHOLD and kbs_config from configs instead of model_config. This change seems correct.
However, the author has commented out the save_vector_store method. It's unclear why this was done, so the author should provide a comment explaining the reason for this change. If this method is no longer needed, it should be removed entirely.
Overall, the code change seems correct, but the author should provide more context for the commented out method.
server/knowledge_base/kb_service/pg_kb_service.py
The code change looks correct as it only changes the import statement for the kbs_config variable. However, it would be better to specify the exact import from the configs module instead of importing the entire module. For example, from configs.kbs_config import kbs_config. This can help avoid potential naming conflicts and make the code more readable.
server/knowledge_base/migrate.py
Based on the code diff, it seems that the author has made the following changes:

Imported CHUNK_SIZE and OVERLAP_SIZE from configs module
Changed the function signature of folder2db to accept a list of kb_names instead of a single kb_name
Removed the SupportedVSType import from KBServiceFactory
Changed the default values of chunk_size and chunk_overlap to use the imported values from configs module
Removed the fill_info_only mode from folder2db
Removed the kb.create_kb() call from folder2db
Removed the kb.clear_vs() call from the recreate_vs mode of folder2db
Moved the files2vs function inside the folder2db function
Removed the kb.save_vector_store() call from the recreate_vs and update_in_db modes of folder2db
Removed the incomplete code block for the increament mode of folder2db

Overall, the changes seem reasonable and should not introduce any issues. However, here are some suggestions for the author:

It would be helpful to add comments or docstrings to explain the purpose of the changes and the function parameters.
The removed fill_info_only mode could be useful in some scenarios, so it might be worth keeping it or providing an alternative way to achieve the same functionality.
The incomplete code block for the increament mode should either be completed or removed to avoid confusion.
It might be worth considering using a logger instead of print statements for logging information and errors.

server/knowledge_base/utils.py
Based on the code diff, it seems that the changes made are mostly related to importing modules and updating function parameters. Here are some suggestions for the author:

It's good to see that the author is using relative imports instead of absolute imports. However, it's not clear why the EMBEDDING_MODEL parameter was moved from model_config.py to configs.py. It would be helpful to add a comment explaining this change.

The get_vs_path function now takes an additional parameter vector_name. It would be good to add a comment explaining what this parameter represents and why it was added.

The make_text_splitter function now takes an additional parameter llm_model. It would be good to add a comment explaining what this parameter represents and why it was added.

In the file2docs function, the author has added a try-except block to handle different input formats for the file parameter. However, it's not clear what kind of exceptions are being handled. It would be helpful to add specific exception types to the except block.

It's not clear why the zh_title_enhance parameter was moved from model_config.py to make_text_splitter function. It would be helpful to add a comment explaining this change.

The get_model_worker_config function is not defined in the code diff. It would be helpful to include this function or provide a reference to where it is defined.

Overall, the changes seem reasonable and should not cause any issues. However, it would be helpful to add more comments explaining the rationale behind the changes.
server/llm_api.py
The code change looks correct. However, I have a suggestion for the author. In the function list_config_models(), instead of returning list_llm_models(), which is a function, the author should call the list_llm_models() function and return its result. This will make the code more readable and easier to understand.
server/model_workers/init.py
Based on the code diff, it seems that the author has added two new worker classes, FangZhouWorker and QwenWorker, to the model_workers package.
The code change looks correct, but it would be helpful if the author could provide more information about these new worker classes, such as their purpose and how they fit into the overall system. Additionally, it would be good to ensure that the new classes follow the same coding conventions and style as the existing classes in the package.
server/model_workers/baichuan.py
The code change looks good overall. Here are some suggestions:

Remove duplicate import statements for json and sys.
Instead of using eval() to parse the response from the API, use json.loads() to safely parse the JSON response.
In the generate_stream_gate() method, consider adding error handling for cases where the API response is not successful (i.e. status code other than 200).
Consider adding more comments to explain the purpose of each method and variable.

server/model_workers/base.py
The code change looks correct. The only suggestion I have is to fix the typo in the error message. Instead of "unknow", it should be "unknown".
server/model_workers/fangzhou.py
The code change looks correct. However, here are some suggestions:

In the request_volc_api function, it would be better to use logging instead of print to log the MaasException error.

In the FangZhouWorker class, the generate_stream_gate method should have a return statement to return the generated stream gate.

In the FangZhouWorker class, the get_embeddings method is not implemented yet. It would be better to add a NotImplementedError exception to indicate that this method is not yet supported.

In the if __name__ == "__main__": block, it would be better to use a try-except block to catch any exceptions that may occur during the execution of the code.

In the if __name__ == "__main__": block, it would be better to use a configparser module to read the configuration file instead of hardcoding the values.

In the if __name__ == "__main__": block, it would be better to use a argparse module to parse the command-line arguments instead of hardcoding the values.

server/model_workers/minimax.py
The code change looks correct. However, here are some suggestions for the author:

It's good that you're using a context manager for the httpx client, but you should also use it for the response object to ensure that it's properly closed after use.

Consider adding some error handling for the httpx requests, such as catching exceptions and logging errors.

It's a good practice to use environment variables or configuration files for the server addresses instead of hardcoding them in the code.

Consider using a logger instead of print statements for debugging and logging purposes.

It's good to see that you're using type hints, but you could also add some docstrings to explain the purpose of the functions and parameters.

server/model_workers/qianfan.py
The code change looks correct. However, I have a few suggestions for the author:

It's a good practice to add a docstring to functions and classes explaining what they do and what parameters they take.

Instead of printing the error message in get_baidu_access_token function, it's better to raise an exception with the error message so that the caller can handle it appropriately.

In request_qianfan_api function, it's better to handle the exception and yield an error response instead of raising a runtime error.

It's a good practice to add a newline at the end of the file.

server/model_workers/qwen.py
Overall, the code change looks good. Here are some suggestions:

In the request_qwen_api function, there is a redundant version = version or config.get("version") line. Since version is already a parameter with a default value, this line can be removed.

In the request_qwen_api function, the text variable is not being used. It can be removed.

In the request_qwen_api function, the yield statement inside the if resp.status_code != HTTPStatus.OK block should be changed to a return statement, since there is no need to continue processing if the API did not respond correctly.

In the request_qwen_api function, the if resp["status_code"] == 200 block should be changed to if resp.status_code == HTTPStatus.OK, since resp is a Response object and not a dictionary.

In the QwenWorker class, the generate_stream_gate method should have a return type annotation of Generator[bytes, None, None].

In the QwenWorker class, the get_embeddings method should have a return type annotation of List[float].

In the QwenWorker class, the print statements in the get_embeddings method should be replaced with actual code to generate embeddings.

In the if __name__ == "__main__" block, the worker object should be passed to the app object using the set_worker method instead of directly assigning it to the worker attribute. This is because the worker attribute is not part of the public API of the app object.

In the if __name__ == "__main__" block, the MakeFastAPIOffline function should be called before setting the worker object, since the MakeFastAPIOffline function modifies the app object.

In the if __name__ == "__main__" block, the uvicorn.run function should be called with the host parameter set to "<IP_ADDRESS>", so that the server can be accessed from other machines on the network.

server/model_workers/xinghuo.py
Based on the code diff, it seems that the author changed the worker address from port 20005 to port 21003. This change seems correct as long as the new port is available and not being used by any other service.
One suggestion for the author is to add a comment explaining the reason for the port change. This can help future developers understand the reasoning behind the change and avoid confusion.
Another suggestion is to update any documentation or configuration files that reference the old port number to avoid any potential issues in the future.
server/model_workers/zhipu.py
The code change seems correct as it updates the worker address to a new port number. However, it would be helpful to add a comment explaining why the port number was changed. Additionally, it may be useful to update any relevant documentation or configuration files to reflect the new port number.
server/utils.py
Based on the code diff, it seems that the author has made some changes to the server/utils.py file. Here are some suggestions for the author:

It's good to see that the author has added some import statements for the required modules and packages. However, it's recommended to organize the imports in a better way, for example, by grouping them into standard library imports, third-party imports, and local imports.

The author has added a new function wrap_done which wraps an awaitable with an event to signal when it's done or an exception is raised. This function seems to be useful, but it's not clear where it's being used. It would be helpful if the author could provide some context or examples of how this function is being used.

The author has added a new function get_ChatOpenAI which returns a ChatOpenAI object. This function seems to be related to the langchain.chat_models module, but it's not clear what this module does or how it's being used. It would be helpful if the author could provide some documentation or examples of how this module is being used.

The author has made some changes to the BaseResponse and ListResponse classes. It's not clear what these changes are for, but it's recommended to provide some documentation or comments to explain the changes.

The author has added a new function torch_gc which clears the memory used by PyTorch. This function seems to be useful, but it's not clear where it's being used. It would be helpful if the author could provide some context or examples of how this function is being used.

The author has added a new function run_async which runs asynchronous code in a synchronous environment. This function seems to be useful, but it's not clear where it's being used. It would be helpful if the author could provide some context or examples of how this function is being used.

The author has made some changes to the iter_over_async function. It's not clear what these changes are for, but it's recommended to provide some documentation or comments to explain the changes.

The author has added a new function MakeFastAPIOffline which patches the FastAPI object that doesn't rely on CDN for the documentation page. This function seems to be useful, but it's not clear where it's being used. It would be helpful if the author could provide some context or examples of how this function is being used.

startup.py
Based on the code diff, it seems like the author has made some changes to the import statements and added some comments to the code. The changes to the import statements look correct and should not cause any issues.
However, there are some comments added to the code that are not very clear and may need some clarification. For example, the comment for the create_model_worker_app function mentions some kwargs fields, but it is not clear what these fields are or how they are used. The author should consider adding more detailed comments or documentation to explain these fields.
Additionally, there are some lines of code that have been removed, such as the init_heart_beat function override. It is not clear why these lines were removed, so the author should provide some explanation or justification for these changes.
Overall, the code changes look reasonable, but the author should provide more detailed comments and explanations for some of the changes.
tests/agent/test_agent_function.py
The code change looks correct. However, here are some suggestions:

Instead of appending the path to the system path, consider using relative imports to import the necessary modules.
It would be helpful to add comments to explain the purpose of each imported module and class.
Consider adding more test cases to cover a wider range of inputs and scenarios.

tests/api/test_kb_api.py
The code change looks correct as it is just changing the import statement for the VECTOR_SEARCH_TOP_K variable from configs.model_config to configs.
However, it would be good to check if this change affects any other parts of the codebase that may be using the VECTOR_SEARCH_TOP_K variable. Additionally, it may be helpful to add a comment explaining why the import statement was changed.
tests/api/test_kb_api_request.py
The code change seems correct as it is just changing the import statement for the VECTOR_SEARCH_TOP_K variable from configs.model_config to configs.
However, it would be better to use an absolute import instead of appending the root path to the system path. This can be done by changing the import statement for ApiRequest to from webui_pages.utils import ApiRequest.
Also, it would be good to add some comments explaining the purpose of the imported modules and variables.
tests/api/test_llm_api.py
The code change looks correct. However, I have a few suggestions for the author:

In the get_configured_models function, the llm_dict variable is no longer used. It can be removed to simplify the code.

In the test_change_model function, the availabel_new_models variable can be simplified by using set difference directly instead of checking if the first set is empty and then using the second set.

Here's the updated code with these suggestions implemented:
@@ -6,21 +6,19 @@
 root_path = Path(__file__).parent.parent.parent
 sys.path.append(str(root_path))
 from configs.server_config import FSCHAT_MODEL_WORKERS
-from configs.model_config import LLM_MODEL, llm_model_dict
+from configs.model_config import LLM_MODEL
 from server.utils import api_address, get_model_worker_config

 from pprint import pprint
 import random
+from typing import List

-def get_configured_models():
+def get_configured_models() -> List[str]:
     model_workers = list(FSCHAT_MODEL_WORKERS)
     if "default" in model_workers:
         model_workers.remove("default")
-
-    llm_dict = list(llm_model_dict)
-
-    return model_workers, llm_dict
+    return model_workers

 api_base_url = api_address()
@@ -56,12 +54,9 @@ def test_change_model(api="/llm_model/change"):
     running_models = get_running_models()
     assert len(running_models) > 0

-    model_workers, llm_dict = get_configured_models()
+    model_workers = get_configured_models()

-    availabel_new_models = set(model_workers) - set(running_models)
-    if len(availabel_new_models) == 0:
-        availabel_new_models = set(llm_dict) - set(running_models)
-    availabel_new_models = list(availabel_new_models)
+    availabel_new_models = list(set(model_workers) - set(running_models))
     assert len(availabel_new_models) > 0
     print(availabel_new_models)

tests/api/test_stream_chat_api.py
The code change looks correct. However, I would suggest adding some comments to explain the purpose of the tests and the changes made. Additionally, it might be helpful to add some assertions to ensure that the expected data is being returned from the API calls.
tests/custom_splitter/test_different_splitter.py
The code change looks correct as it is just changing the import statement to import the necessary variables from a different module. However, it would be better to specify which variables are being imported instead of importing everything from the module. This can help with code readability and avoid potential naming conflicts. For example, instead of from configs import *, it would be better to use from configs.model_config import CHUNK_SIZE, OVERLAP_SIZE.
tests/online_api/test_fangzhou.py
The code change looks correct. However, here are some suggestions for the author:

Instead of using sys.path.append, consider using a virtual environment or adding the project to the PYTHONPATH environment variable.
Consider using logging instead of print statements for debugging purposes.
It's good to have parameterized tests, but consider adding more test cases to cover different scenarios.
Consider adding more assertions to the test case to ensure that the expected behavior is met.

tests/online_api/test_qianfan.py
The code change looks correct. The test_qianfan function is now using a subset of the MODEL_VERSIONS keys instead of all of them. This can be useful for testing specific versions or for reducing the amount of time it takes to run the test suite.
One suggestion for the author would be to add a comment explaining why only the first two keys are being used. This can help other developers understand the reasoning behind the change and prevent confusion in the future.
tests/online_api/test_qwen.py
The code change looks correct. However, here are some suggestions for the author:

Instead of using print statements, consider using a logging library to log messages. This will make it easier to debug and maintain the code in the future.
It's a good practice to include a docstring for the test function explaining what it does and what it's testing.
Consider adding more test cases with different input messages to ensure the function works correctly in all scenarios.

tests/test_migrate.py
The code change looks good overall. Here are some suggestions:

Instead of using os.path.join, consider using Path objects throughout the code for better cross-platform compatibility.

Use assert statements with more descriptive error messages to make it easier to debug failures.

Consider adding docstrings to the test functions to explain what each test is checking.

In test_prune_folder, there are duplicate assertions for len(docs) == 0 for the same file. Remove one of them.

Consider adding some negative test cases to ensure that the functions behave correctly when given invalid input.

Instead of using pprint to print out the first document in a list, consider using print(docs[0].to_dict()) to print out the document metadata in a more readable format.

Consider using pytest instead of the built-in unittest module for more concise and readable test code.

webui_pages/dialogue/dialogue.py
There seems to be some incomplete code in the last line of the code diff. It looks like the author was in the middle of writing a line of code and didn't finish it.
As for suggestions, it would be helpful if the author added some comments to explain the purpose of the functions and variables in the code. Additionally, it might be useful to refactor the get_messages_history function to make it more readable and easier to understand.
webui_pages/knowledge_base/knowledge_base.py
Based on the code diff, it seems that the author has made some changes to the imports and added a new function list_embed_models() from the server.utils module.
The changes to the imports look good as they are now importing the required modules directly instead of importing them from a specific file. This makes the code more modular and easier to maintain.
The addition of the list_embed_models() function also seems like a good addition as it can help in listing all the available embedding models. However, it would be helpful if the author could add some comments or documentation to explain what this function does and how it can be used.
Overall, the code change looks good and the author has made some useful additions. It would be helpful if the author could add some comments or documentation to explain the changes and how they improve the code.
webui_pages/utils.py
Based on the code diff, it seems that the author has made changes to the imports and added some new variables and methods to the ApiRequest class.
One suggestion for the author is to add some comments to the new methods to explain their purpose and functionality. This will make it easier for other developers to understand the code and maintain it in the future.
Another suggestion is to remove the unused import llm_model_dict from the configs.model_config module to keep the code clean and organized.
Overall, the code changes seem correct and should not cause any issues.


tests: remove forced browser_version just to get tests running

WIP...just testing

Closing, as this one was just for debugging


Angular 4 support?

Hi Uday,
do you plan to support Angular 4 too? Dropzone seems to be amazing and I'd like to use this module in my project. I was wondering if you have anything worked out for Angular4...

It's coming up...

https://www.npmjs.com/package/angular-file-dropzone

Any news on this yet?

Sorry man. Too busy. :(

Respectfully,
Uday Hiwarale
Full Stack Developer
New Delhi, India
Ph. +91-9650913753
Website : http://thatisuday.com, http://gitmeet.com
On Fri, Aug 18, 2017 at 4:16 PM, Jonathan Smith<EMAIL_ADDRESS>wrote:

Any news on this yet?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/thatisuday/ng-dropzone/issues/17#issuecomment-323322207,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFcnzcWsMhxjlGtgmY10fu6DzfCaXm-Jks5sZWtrgaJpZM4NGY1Z
.

@iamjsmith @MchlFil Perhaps try this https://github.com/zefoy/ngx-dropzone-wrapper


Linux Launch Script Changes

Added:

OS Detection for Mac/Linux
Linux Launching

Boom. It's live!

Achievement Get: First OSS contribution ^^

:tada:


[lsp-server] 🐞 The language server throws "could not parse the TypeScript file" error for every TS file when documents field is used

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
The language server throws Could not parse the TypeScript file. SyntaxError: Unexpected token, expected "," errors when I use documents section in GraphQL config.
The Config:
projects:
  apps:
    schema: https://localhost:8080/graphql
    documents:
      - ./app/**/*.{ts,tsx}
      - '!(app/operations/generated/*)'
      - '!(app/operations/gqlApolloHooks.ts)'

The Other Config That I tested:
projects:
  apps:
    schema: https://localhost:8080/graphql
    documents:
      - ./app/**/*.{ts,tsx}
      - '!./app/operations/generated/*.{ts,tsx}'
      - '!./app/operations/gqlApolloHooks.ts'

And here is a trick config that works:
projects:
  apps:
    schema: https://localhost:8080/graphql
    include:
      - ./app/**/*.{ts,tsx}
    exclude:
      - './app/operations/generated/*.{ts,tsx}'
      - './app/operations/gqlApolloHooks.ts'

Expected Behavior
It should not throw TypeScript errors and just work.
Steps To Reproduce
No response
Environment

LSP Server Version: VSCode GraphQL v0.8.17
OS: macos

Anything else?
No response

Looks like my GraphQL schema did not load correctly, I switched back to using documents because fragments did not work with include.
The LSP is still throwing TypeScript errors but everything magically works now.
I'll keep this issue open as I still get the errors. I'll change the issue title.

I'm having the same error message in a monorepo setup with projects in the configuration. Every graphQL file throws the same "Could not parse the TypeScript file" error and after some time the GraphQL server crashes too often so it won't automatically restart

I'm seeing the same problem
Could not parse the TypeScript file at [path to .tsx] to extract the graphql tags:
SyntaxError: Unexpected token, expected "," (1:33)

i believed the fix for this is released as v0.8.19 for vscode-graphql, 2.11.5 for the LSP, let me know if that helps!

Nope still getting SyntaxError: Unexpected token, expected "," errors in the graphql language server output everytime I reload the VSCode.
The autocomplete works fine though.

I'm getting the same thing:
[Error - 11:22:11 PM] Could not parse the TypeScript file at file:///Users/jonno/Source/dorado/components/generic/CarrierAsyncSelect.tsx to extract the graphql tags:
[Error - 11:22:11 PM] SyntaxError: Unexpected token, expected "," (1:48)

ok, i think this is related to using graphql config to parse files again, which we reintroduced a few months ago. graphql config throws errors when a file is not perfectly parsable, whereas autocomplete and hover and other features use our fault tolerant parser. are any features besides validation not working because of these errors?

Same issue here with the following config:
// graphql.config.ts
import type { IGraphQLConfig } from 'graphql-config'

const schema = 'apps/api/src/schema/**/*.graphql'

export default {
  projects: {
    api: {
      schema,
    },
    web: {
      documents: 'apps/web/src/**/*.{ts,tsx}',
      schema,
    },
  },
} satisfies IGraphQLConfig

and the following output:
[Error - 02:54:29] Could not parse the TypeScript file at file:///some/file/path/etc.ts to extract the graphql tags:
[Error - 02:54:29] SyntaxError: Unexpected token, expected "," (1:28)

Still happening

most of these issues will be fixed in the next minor release soon! the errors do not point to the exact cause. documents config will be required and a warning will be logged if it isn't present
and then another major release will occur - this is another major rewrite which ensures that graphql-config includes and excludes are honored. this 2nd refactor actually just uses @graphql-tools/load to properly do everything with graphql config pointers, instead of manually unwrapping the pointers like we do now. we have been planning this with the guild for a long time! and so far it is much faster.

unfortunately the issue will continue happening until the 2nd stage rewrite, as it comes from graphql tools loadTypeDefs() via graphql config loadConfig(). it doesn't mean anything though because it falls back to another parser and keeps going
in the next release, where we overhaul logging levels, these errors will be buried because they are not relevant

I encountered a similar issue with the latest version (v0.11.0) where all my fragments are reported as "Unknown". Downgrading the extension to v0.9.3 fixes the issue.
However, both versions show the following errors for every TypeScript files in my repo:
[Error - 10:51:46 AM] Could not parse the TypeScript file at file:///xxx.tsx to extract the graphql tags:
[Error - 10:51:46 AM] SyntaxError: Unexpected token, expected "," (1:24)

Not sure why v0.9.3 works correctly and go to definition for fragments also works.

same issue

@luin these errors are unrelated. in the latest graphql config version it seems you must use arrays if you want full paths for documents, otherwise use globs for documents config

I encountered a similar issue with the latest version (v0.11.0) where all my fragments are reported as "Unknown". Downgrading the extension to v0.9.3 fixes the issue.
However, both versions show the following errors for every TypeScript files in my repo:
[Error - 10:51:46 AM] Could not parse the TypeScript file at file:///xxx.tsx to extract the graphql tags:
[Error - 10:51:46 AM] SyntaxError: Unexpected token, expected "," (1:24)

Not sure why v0.9.3 works correctly and go to definition for fragments also works.

Yes downgrading works for me as well. I am having this issue with all of my .vue files in my project.

@acao is there any update on this? It's still happening on the latest version.
Downgrading is the only way to resolve this.

@Tadimsky I suspect this is due to changes where we let graphql config do more of the parsing. Looking into it still!

Same issue on latest version only way is downgrading to v0.9.3

Getting the same errors, but with plain JavaScript files 😬, latest LSP v0.12.1 in VSCode

the confusing thing is that our new functional test suite confirms that this is not an issue :( so it will be hard to understand what edge cases might be causing this. note that this error is often a false negative, as the files that fail parsing via graphql-tools via graphql-config are still parsed with our custom embedded parser later, and may not be related to the source of the various functional issues people are reporting here in the thread, which may be related to other open tickets, and not this error.
I have a PR to move to graphql-tools completely and remove our custom parser, but then we have had trouble with parsing files containing incomplete operations or SDL statements, causing more issues with fragments and similar (a fragment or fragment spread will fail to work if the base type or operation leaf is invalid, etc)


Prevent overlinking against MPI libraries in ECMWF software and add support for different build types

Description
This PR only updates the submodule pointer for spack - needs updating after the corresponding spack PR https://github.com/NOAA-EMC/spack/pull/128 is merged.
Note that the submodule pointer update shows many more changes than just the 5 files that I changed - from previous PRs going in yesterday.
Dependencies

waiting on https://github.com/NOAA-EMC/spack/pull/128

Issues

fixes #231

Testing
Tested on Discover with Intel, on Orion with GNU, and on my local macOS with apple-clang+gfortran. Full CI tests passed for https://github.com/NOAA-EMC/spack-stack/pull/256/commits/49e700f15920893d63c57bf724a985ad0f62b31f.
I also installed all the packages with build type Debug and verified that CMAKE_BUILD_TYPE=Debug got passed to each of them. Then I verified that the modules are created with suffix -debug, as expected.
spack install --reuse --verbose ecmwf-atlas build_type=Debug ^fckit build_type=Debug ^ eckit build_type=Debug ^ fiat build_type=Debug ^ ectrans build_type=Debug 2>&1 | tee log.install.ecmwf-packages-debug

This can supersede #249

@kgerheiser This is ready to merge, CI tests passed for the last commit before reverting .gitmodules and updating spack. Happy to run them again if you think it makes sense.

The passing CI run looks good. Ok to merge.

The passing CI run looks good. Ok to merge.

Thanks can you approve please?


Do not upgrade linkerd by default

Rio by default run linkerd-install job to upgrade linkerd to match the version that ships along with Rio. We should be able to add a flag to control this behavior and not running upgrade-install-job be default.
This flag will be controlled by feature.options["upgrade"] = "true"

available to test on master.

Looks like it's working. To test:

rio install
kubectl get -n riosystemtest job.batch --> There should be a resource there like linkerd-install-xadfa. Keep note of its "AGE" and "NAME".
Restart rio controller (kill its pod should be enough)
Rerun step (2). Notice that this resource did not change.
rio -s edit configmap/rio-config --> update features to include:

"linkerd": {
  "enabled": true,
  "options": {
    "upgrade": "true"
  }
}

Run rio -s cat --key config configmap/rio-config | jq . to verify changes are present
Repeat steps (3) and (4). Now notice that the resource from step (2) does change.

Upgrading linkerd automatically with rio controller is now an "opt-in" feature.


Usable on Colab

A lot of people have resorted to using Colab for it memory power, it would be great to have a good working example without the conflicts maybe a Colab version..
Thanks for this, great work!

Hey, thanks for hitting me up about that, I live in my own little terminal land for the most part and tend to forget about such things. I will get to a working Colab example as soon as possible. I think the app should work fine in Colab though. What have you experienced? Can you maybe elaborate on what issues you had?

I rewrote the Colab example and it works as it should. Can you please verify @firmai ?

Lovely, thanks for that! Working on any new projects or just focusing on maintaining this one?

Hey @firmai, I'm currently working mainly on Scandinavian embeddings (benchmark and models) and a contextually sensitive topic modeling framework (turftopic) for which the papers and the Python package are already in progress + making topicwizard compatible with contextual models.


[Bug] ElasticSearch index not created when using existing SQL/Cassandra

What are you really trying to do?
Deploy Temporal with an existing Database.
Describe the bug
When an exiting DB is used, the suggested configuration is disabling the schema setup and update:
schema:
  setup:
    enabled: false
  update:
    enabled: false

However, this causes the the index creation job not to run either: https://github.com/temporalio/helm-charts/blob/master/templates/server-job.yaml#L347
There should likely be a separate flag controlling the ElasticSearch index creation.
Minimal Reproduction
Just run any of the "Install with your own MySQL/PostgreSQL/Cassandra" examples. All server services will be stuck in Init "waiting for elasticsearch index to become ready"
Additional context
There is this post on the community forum which might be related.

I stumbled upon this today while trying to configure temporal with an external PostgreSQL DB. I also found a workaround, but it isn't pretty.
We're deploying this through an ArgoCD application, and this is what it looks like:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
    name: temporal
    namespace: argocd
spec:
    syncPolicy:
        automated:
            selfHeal: true
            prune: true
    project: default
    destination:
        server: https://kubernetes.default.svc
        namespace: temporal
    source:
        path: charts/temporal
        repoURL: https://github.com/temporalio/helm-charts
        targetRevision: temporal-0.33.0
        helm:
            releaseName: temporal
            values: |-
                replicaCount: 1
                postgresql:
                  enabled: true
                prometheus:
                  enabled: true
                elasticsearch:
                  enabled: true
                grafana:
                  enabled: true
                cassandra:
                  enabled: false
                schema:
                  setup:
                    enabled: true
                  update:
                    enabled: true
                server:
                  config:
                    persistence:
                      default:
                        driver: sql
                        sql:
                          driver: postgres
                          host: temporal(...).eu-west-1.rds.amazonaws.com
                          port: 5432
                          user: postgresql
                          password: xxxx
                      visibility:
                        driver: sql
                        sql:
                          driver: postgres
                          host: temporal(...).eu-west-1.rds.amazonaws.com
                          port: 5432
                          user: postgresql
                          password: xxxx

All 4 temporal pods were stuck initializing. I only checked the worker pod which was was failing with:
waiting for elasticsearch index to become ready

This is due the es-index-setup job not being created.
I ended up cloning the repo, checking out the tag I was using above, putting the helm values on a file by themselves and templating the chart locally:
helm template temporal /home/daniel/repos/temporal-helm-charts/charts/temporal/ --values temporal-values.yml
And strangely enough this generated the yaml for the es-index-setup Job, which I then kubectl applied from my machine, which initialized temporal's elastic search instance, and now the pods are OK.
I ran out of time to troubleshoot why the helm chart has this strange behaviour, if it wasn't for this issue I would assume the problem was between my chair and keyboard, but IMO something's up that is worth fixing.
Also it is worth bearing in mind that many temporal users will use a GitOps tool (likely ArgoCD or FluxCD) to deploy this helm chart, so it is something worth validating.
Cheers

same issue is happening to me, have pods stuck on init state. I tried the workaround from @DanielCalvo but it not work on my case.

Do you happen to have any updates on this? Our team is also affected by this issue.

I seem to also have this issue upgrading from 0.36.0 to 0,37.0. It is my first upgrade.
Scott

I also had this issue; after a Kubernetes update I realized my Temporal deployment wasn't in a good state. I found that the temporal-history container was waiting on this same elasticsearch index setup. Following along the lines of above, in my temporal helm chart repo I set enabled: true in my values/values.postgresql.yaml (fixing the config OP pointed out), then I did:
helm template . --values values/values.postgresql.yaml > out.yml

Then you can search for temporal-es-index-setup in that output, stick that job into it's own job.yml file and do:
kubectl apply -f job.yml

I had to kick a few of the pods to restart the deployment but then everything was working as normal.

If you are using ArgoCD:

go into temporal ArgoCD app, remove resource "job" - "temporal-schema"
it will re-create job that takes care of es-index setup
watch progress of that job and look at any errors - in my case there was a problem connecting to Cassandra headless so I restarted pod for Cassandra

all working fine.

i ran into this and added
schema:
  update:
    enabled: true

to my chart. not sure if this is wrong though


[MOBILE][WHISPER] User gets group notifications if chat is open

And also if the message was sent by the user himself.
Because message.from is the group chat and not the actuall user id
(see message.controller line 152)

Seems to work on mobile after testing


Trow unreachable over IPv6

Describe the bug
When running a cluster with DualStack/IPv6 trow is not reachable as it only listens on <IP_ADDRESS> (all IPv4 interfaces).
This could be mitigated by letting Trow/Rocket listen by default on :: (actually all interfaces IPv4 and IPv6).
Another workaround would be to allow the helm chart to set the --host flag.
To Reproduce

Setup a cluster with IPv6 support
Setup an ingress controller with IPv6 support
Setup trow + ingress (or IPv6 service)

Expected behavior
Trow is reachable at the configured domain through the ingress/directly via IPv6
Trow Info

Install method: Helm
Helm Chart info:

apiVersion: v2
appVersion: 0.3.5
description: Helm chart for Trow registry
name: trow
type: application
version: 0.3.5

Kubernetes

Kubernetes distro/host: kubeadm on Arch
Kubernetes version: v1.25.5
Container Runtime: ContainerD

Note that Trow uses Rocket, which does not support listening to multiple addresses in a single instance. The workaround described here might work tho: https://github.com/SergioBenitez/Rocket/issues/1581.
Otherwise the solution is to have multiple instances of rocket running (like I did here).

Thanks @awoimbee !


tests for ReplaceSamHeader

(some disabled due to picard bug https://github.com/broadinstitute/picard/issues/284)

addresses #208

@cmnbroad please review

Code looks good - one comment on the tests. Back to @akiezun.


Implement playbackRate in the audio system

Please test

I tried to change the playbackRate of my sound with this code :
let cmpAudio: ƒ.ComponentAudio = new ƒ.ComponentAudio();
cmpAudio.loop = true;
cmpAudio.playbackRate = 2;
this.node.addComponent(cmpAudio);

But it doesn't change the speed of the sound and in didn't change the value in the console neither.
Project : https://easzyyyyy.github.io/prima/Projects/Karting/index.html

I found out, that the sound must be playing (being connected) when changing the playbackRate. In the MDN-Example, the slider is deactivated when the sound is stopped.
Have you tried the latest version of FUDGE? I see only a black screen with your example, so it's hard to test. But when I type
Script.karting.audio.playbackRate=2
in the console, the rate changes

It works perfectly, thank you.


Fix issue with NewFIFOSetInDir with Terminal true

Signed-off-by: Justin Terry (VM<EMAIL_ADDRESS>

@jhowardmsft - Since you use NewDirectIOFromFIFOSet from Docker can you please make sure that you dont assign stderr in the case of terminal?

@jterry75 As in https://github.com/moby/moby/blob/0a5c8c00f28a7eee72443a4a5266ff10793ccfb8/libcontainerd/remote/client_windows.go#L56-L58?

@jterry75 As in https://github.com/moby/moby/blob/0a5c8c00f28a7eee72443a4a5266ff10793ccfb8/libcontainerd/remote/client_windows.go#L56-L58?

Awesom thanks for confirmation. That code is correct.

Codecov Report

Merging #3054 into master will decrease coverage by 0.41%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #3054      +/-   ##
==========================================
- Coverage   43.87%   43.46%   -0.42%
==========================================
  Files         102      103       +1
  Lines       10903    11033     +130
==========================================
+ Hits         4784     4795      +11
- Misses       5384     5503     +119
  Partials      735      735

Flag
Coverage Δ

#linux
47.48% <ø> (ø)
:arrow_up:

#windows
40.28% <100%> (-0.81%)
:arrow_down:

Impacted Files
Coverage Δ

cio/io_windows.go
9.82% <100%> (ø)

cio/io.go
27.27% <0%> (-5.34%)
:arrow_down:

Continue to review full report at Codecov.

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

LGTM


Helm Dependencies and values.yaml completion and GoTo-Definition

Hey,
I was trying to use the LS in NeoVim but the completion based on dependencies (in the Helm Chart) do not work and also going to the definition. Going to the definition of a value in the dependency would be nice.
A minimal case can be:
helm create github-issue-chart
Then copy over this Chart.yaml
apiVersion: v2
name: test-deploy
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: "1.16.0"

dependencies:
  - name: nginx
    repository: "oci://registry-1.docker.io/bitnamicharts"
    version: "15.10.29"

I would expect this Helm LS to be able to suggest values for nginx.SOMETHING inside the values.yaml.  This does not work either after running helm dependency update and even after un-tar-ing the tarball (chart).
Here are the logs from :LspLog
[ERROR][2024-02-20 19:42:22] .../vim/lsp/rpc.lua:734	"rpc"	"/Users/zeljkobekcic/.local/share/nvim/mason/bin/helm_ls"	"stderr"	'{"level":"error","msg":"Error getting chart info for filefile:///private/tmp/test-deploy/values.yamlChart not found for file: file:///private/tmp/test-deploy/values.yaml. Using fallback","time":"2024-02-20T19:42:22+01:00"}\n{"level":"info","msg":"/private/tmp/test-deploy/values.yaml","time":"2024-02-20T19:42:22+01:00"}\n{"level":"info","msg":"helm lint: result for file file:///private/tmp/test-deploy/values.yaml : []","time":"2024-02-20T19:42:22+01:00"}\n{"level":"debug","msg":"Merged diagnostics[]","time":"2024-02-20T19:42:22+01:00"}\n{"level":"info","msg":"Workspace configuration: [{{true yaml-language-server 50 false {map[kubernetes:templates/**] true true}} {values.yaml values.lint.yaml values*.yaml} info}]","time":"2024-02-20T19:42:22+01:00"}\n'

I am also using the latest version of helm-ls.
Thank you in advance!

Hi thanks for the submission of the feature request,
currently there is no support at all for editing values.yaml files, so your nvim config is kind of wrong for even having helm-ls enabled for those files.

I realize that completion inside values files is not supported yet, however it would be really helpful if completion of values of dependency charts would work inside templates.
So same as the example above, it would be nice if {{ .Values.nginx. would show completion for the merged values of the nginx dependency chart.
It looks like from the design this is currently not supported? At least the Chart in https://github.com/mrjosh/helm-ls/blob/master/internal/charts/chart.go does not yet have any reference to the actual dependency chart structs, correct?
What would be the best way of adding this? I could also try to contribute here.
Thanks for your support!

Ah thanks for the hint, that makes sense. Then this could definitely be tackled in the refactoring with #77 .
Then I guess it makes sense to wait until #72 is completed. Thanks for the insights.

I realize that completion inside values files is not supported yet, however it would be really helpful if completion of values of dependency charts would work inside templates.
So same as the example above, it would be nice if {{ .Values.nginx. would show completion for the merged values of the nginx dependency chart.
It looks like from the design this is currently not supported? At least the Chart in https://github.com/mrjosh/helm-ls/blob/master/internal/charts/chart.go does not yet have any reference to the actual dependency chart structs, correct?
What would be the best way of adding this? I could also try to contribute here.
Thanks for your support!

Hi @msvechla, feel free to test https://github.com/mrjosh/helm-ls/pull/80, which should do what you suggested and provide some feedback.

@qvalentin just tried building the binary for that branch and I'm getting the following error:
Error getting chart info for filefile:///Users/xmath279/Documents/Projects/helm-ls/testdata/dependenciesExample/values.yamlChart not found for file: file:///Users/xmath279/Documents/Projects/helm-ls/testdata/dependenciesExample/values.yaml. Using fallback

This is from the example in the branch. I ran helm dependency build as well.


Better rstudio integration for extract_areas function

Hopefully from the rstudio team can help with this.

What issues are you encountering?

Really difficult to see and use the highlighter

The cursor appears to be the same across graphics devices and is defined quite deeply inside the R source. I'm not sure there's going to be away to get around this.

Will see if I can find the right rstudio dev maybe JJ Allaire?

The answer may be to create a Shiny app. plotOutput() offers a "brush" (drag) method for highlighting an area of a plot. That will probably work better than the current approach and possibly resolve platform-specific errors mentioned here.

Another approach is graphics events, apparently, but I think this will require cairoDevice to work on Mac.

Hey @abresler, I just added a little shiny widget thing as a hopefully better interface for when you're working within RStudio. Let me know if you have any reactions/suggestions.

You ROCK cannot wait to play with this!!
ᐧ

Alex Bresler
<EMAIL_ADDRESS>www.asbcllc.com
917-455-0239
 (cell)
@abresler http://twitter.com/abresler | LinkedIn
http://www.linkedin.com/in/abresler | My Musings http://asbcllc.com/blog
On Tue, Jun 7, 2016 at 8:48 AM, Thomas J. Leeper<EMAIL_ADDRESS>wrote:

Hey @abresler https://github.com/abresler, I just added a little shiny
widget thing as a hopefully better interface for when you're working within
RStudio. Let me know if you have any reactions/suggestions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/leeper/tabulizer/issues/8#issuecomment-224269787, or mute
the thread
https://github.com/notifications/unsubscribe/AAtM1MAxrGN-5WDo_dO1M_MpG0ojQk9mks5qJWibgaJpZM4IVyVx
.

I think I'm going to consider this closed, but I'll gladly reopen if any weird behavior emerges.


Remove service-cluster-ip-range flag from configs not using apiserver

This flag was needed before the "api-server" flag was introduced. Now it's only obligatory if the API server is enabled.

This change is

LGTM


Add null_literal node.

Fixes #140

Is this a copy of my PR? https://github.com/fwcd/tree-sitter-kotlin/pull/139

Wow, no, that's an extraordinary coincidence. I did a search for outstanding issues but not PRs so I didn't see this. I'm happy to close this one although I'd suggest you link yours to the bug I filed and you can simplify the grammar change slightly: there's no need to wrap a single node "null" in a seq call.

Is this a copy of my PR? https://github.com/fwcd/tree-sitter-kotlin/pull/139

Also I had to fix highlights.scm, make sure your tests fully pass. I think it was just a subtle message at the bottom of the test log.

Duplicate of #139


Response in IOS is very slow compare to android

Expected Behaviour
The text to speech should very fast in IOS but its not... But in Android its working smoothly with a fast response
Actual Behaviour
The response in both platform should be same
Reproduce Scenario (including but not limited to)
Steps to Reproduce
Platform and Version (eg. Android 5.0 or iOS 9.2.1)
Android: 8.0
IOS: 11.2
(Android) What device vendor (e.g. Samsung, HTC, Sony...)
MI A1
Cordova CLI version and cordova platform version
cordova --version : 8.0.0                                   # e.g. 6.0.0
cordova platform version android : 7.1.0                     # e.g. 4.1.1
cordova platform version ios : 4.5.4                     # e.g. 4.1.1

Plugin version
cordova plugin version | grep phonegap-plugin-speech-recognition: 0.3.0   # e.g. 1.5.3

Sample Push Data Payload
Sample Code that illustrates the problem
Logs taken while reproducing problem

Sorry about that, but it's as fast as it can be using Apple provided SDKs and we can't improve it, only Apple can, so consider reporting it in Apple's bug tracker.
Try enabling partial results, I think that should have faster response

Hii can you tell how to enable that partial results?

Read the Speech API https://w3c.github.io/speech-api/speechapi.html
It should be the part about interimResults


hello-rails-react

Description

To build React components as a part of your Rails JavaScript and serve it in a component, react_component, to be used in a regular ERB file.

General requirements

Make sure that there are no linter errors.
Make sure that you used correct Gitflow.
Make sure that you documented your work in a professional way.

Ruby requirements

Follow our list of best practices for Ruby.

Project requirements

Create a new Rails app called 'hello-rails-react'.
Initialize your project with Git.
Set up your project with web-packer the react-rails gems as describe in the previous lesson's tutorial.
Make sure that your project has a Post-gres database set up.
Create a table for storing your messages and create 5 different greetings.
Create an API endpoint that selects a random greeting from your table (you will need a controller with an action and Rails route).
Create a static view that will be the root of your app.
Create the App component with react-router and render it in your static view.
Create the Greeting component that will display a greeting. Set it up as a route in your App component.
Create a store, an action and a reducer that will connect to you API end-pont to get the random greeting.
Display the random greeting in your Greeting component.

Thanks for reviewing the PR.

Approved ✔
Hi @Abenezer-Tilahun
Congratulations on completing this project! 👏🏼 🎉
You have correctly implemented all of the requirements📃 correctly and without any errors⚠ or bugs🪲.
Cheers and good luck in your next milestones! 🍀
Feel free to leave any questions or comments in the PR thread(don't forget to tag me 😄) if something is not 100% clear.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


Edit: already implemented. Please close. Feature Request: associate APK and apks file types.

 Would you add the feature to let APK and APKS files be opened with this app, like Inure does?
Sadly I am not versed in Android development. AI seems to suggest that it has something to do with intents.
It suggests modifications must be made to the AndroidManifest.xml file.
I will try to implement it to the best of my ability and make a pull request with it as soon as I can, but I never worked with android apps until now.
https://www.perplexity.ai/search/how-to-Android-kEZ2_t.HSzes37ZefiEN0Q
https://chat.openai.com/share/cf1318d9-5aa8-4a49-bed9-a0ce2c39d0a7
Edit: the new release already implemented this.

You implemented it before I even made the request. I just did not install the latest update. Maybe implement an update notification?


ci: use install-extras for package check

Before submitting

[x] Was this discussed/agreed via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure to update the docs?
[x] Did you write any new necessary tests?

What does this PR do?
Follow-up based on https://github.com/Lightning-AI/utilities/pull/184
PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in GitHub issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

the problem seems with unrecognized extras:
WARNING: lightning-graphcore 0.1.0 does not provide the extra 'pytorch-lightning'