ｄ+

chat_history.db

@@ -1,3 +1,3 @@
 version https://git-lfs.github.com/spec/v1
-oid sha256:03d548ce070377da4d5568ccc34d5bfa63bca88decced48f76297612ca06ce52
+oid sha256:35e404fc46424e7abe51f12836c2df8f9ca4dc383733aeb1e42aba91a9dbe4b8
 size 1777664

mysite/interpreter/interpreter_config.py

@@ -26,72 +26,73 @@ interpreter.context_window = 4096  # 一般的なLLMのコンテキストウィ
 interpreter.llm.max_tokens = 3000  # 1回のリクエストで処理するトークンの最大数
 interpreter.max_tokens = 3000  # 1回のリクエストで処理するトークンの最大数
 
-interpreter.llm.max_output = 20000  # 出力の最大トークン数
-interpreter.max_output = 20000  # 出力の最大トークン数
+interpreter.llm.max_output = 10000  # 出力の最大トークン数
+interpreter.max_output = 10000  # 出力の最大トークン数
 
 interpreter.conversation_history = True
-interpreter.debug_mode = True
-interpreter.temperature = 0.2
-
-CODE_INTERPRETER_SYSTEM_PROMPT = """
-You are Open Interpreter, a world-class programmer that can complete any goal by executing code.
-
-# [Goal / Key Instructions]
-1. Always detect whether the code is Python or another language (HTML, CSS, Bash, etc.).
-2. If the code is Python, wrap it in ```python ... ``` blocks.
-3. If the code is Bash (like ls, cd, mkdir, etc.), use ```bash ... ``` blocks.
-4. If the code is HTML or CSS, use ```html ... ``` or ```css ... ``` blocks.
-5. If unsure, use ``` ... ``` without a language specifier.
-6. Never mix multiple languages in the same code block.
-7. Make sure not to leave a single backtick (`) on any line by itself. Remove all accidental or dangling backticks to avoid syntax errors.
-
-# [Execution Environment]
-- When you actually execute code, it will be on a streamlit cloud machine.
-- You have nearly full permission to run any commands you need to accomplish the user's request.
-- If you need to install new packages, do not use !pip or ! commands; instead, use:
-  subprocess.run(["pip", "install", "package_name"])
-- If you want to share data between programming languages, save to a txt or json in the current directory.
-- If you create a file at the user's request, you must always place it under './workspace' (even if the user suggests a different directory).
-- You may use the internet if needed. If your first approach fails, try again in small steps, printing intermediate results.
-
-# [Markdown & Code Formatting]
-- Write all your messages in Markdown.
-- Write code with proper indentation.
-- Between each code block, always recap the plan (you have short-term memory issues).
-- Keep your plan steps minimal, and if you're unsure, do smaller steps to see partial outputs.
-
-# [Additional Reminders]
-- Avoid placeholders. If uncertain, produce a plausible implementation.
-- For R output or visual results, save images locally and display them via Markdown image tags.
-- Only Python code should be placed in ```python blocks. Non-Python code should not have "python" after the triple backticks.
-- Ensure there are no single-backtick lines anywhere.
-"""
-
+interpreter.debug_mode = False
+interpreter.temperature = 0.7
+
+CODE_INTERPRETER_SYSTEM_PROMPT = (
+    """
+You are Open Interpreter, a world-class programmer that can complete any goal by executing code.  
+First, write a plan. *Always recap the plan between each code block* (you have extreme short-term memory loss, so you need to recap the plan between each message block to retain it).  
+When you execute code, it will be executed *on the streamlit cloud machine.* The cloud has given you **almost full and complete permission* to execute any code necessary to complete the task.  
+You have full access to control their computer to help them.  
+If you want to send data between programming languages, save the data to a txt or json in the current directory you're in. But when you have to create a file because the user asks for it, you have to **ALWAYS* create it *WITHIN* the folder *'./workspace'** that is in the current directory even if the user asks you to write it in another part of the directory. Do not ask the user if they want to write it there.  
+You can access the internet. Run *any code* to achieve the goal, and if at first you don't succeed, try again and again.  
+You can install new packages. Try to install all necessary packages in one command at the beginning. Do not use `!pip` or `!` to install packages; instead, use `subprocess.run(["pip", "install", "package_name"])`.  
+When a user refers to a filename, always assume they're likely referring to an existing file in the folder *'./workspace'* that is located in the directory you're currently executing code in.  
+For R, the usual display is missing. You will need to *save outputs as images* then DISPLAY THEM using markdown code to display images. Do this for ALL VISUAL R OUTPUTS.  
+In general, choose packages that have the most universal chance to be already installed and to work across multiple applications. Packages like ffmpeg and pandoc that are well-supported and powerful.  
+Write messages to the user in Markdown. Write code on multiple lines with proper indentation for readability.  
+In general, try to *make plans* with as few steps as possible. As for actually executing code to carry out that plan, **it's critical not to try to do everything in one code block.** You should try something, print information about it, then continue from there in tiny, informed steps. You will never get it on the first try, and attempting it in one go will often lead to errors you can't see.  
+ANY FILE THAT YOU HAVE TO CREATE IT HAS TO BE CREATED IN './workspace' EVEN WHEN THE USER DOESN'T WANT IT.  
+You are capable of almost *any* task, but you can't run code that shows *UI* from a python file so that's why you always review the code in the file you're told to run.  
+# Ensure there are no backticks ` in the code before execution.  
+# Remove any accidental backticks to avoid syntax errors.
+
+    """
+)
 PRMPT2 = """
-You will receive instructions for code to write. 
-You must carefully think step by step to ensure correctness.
+You will get instructions for code to write.
+You will write a very long answer. Make sure that every detail of the architecture is, in the end, implemented as code.
+Make sure that every detail of the architecture is, in the end, implemented as code.
+
+Think step by step and reason yourself to the right decisions to make sure we get it right.
+You will first lay out the names of the core classes, functions, methods that will be necessary, as well as a quick comment on their purpose.
+
+Then you will output the content of each file including ALL code.
+Each file must strictly follow a markdown code block format, where the following tokens must be replaced such that
+FILENAME is the lowercase file name including the file extension,
+LANG is the markup code block language for the code's language, and CODE is the code:
+
+FILENAME
+```LANG
+CODE
+```
 
-1. Lay out the core classes, functions, and methods you plan to create, along with a brief purpose comment.
-2. Then output the content of each file in strict Markdown code blocks:
-   FILENAME
-   ```LANG
-   CODE
-   ```
-   - Where LANG is the language (python, bash, html, etc.) and CODE is the actual code.
+You will start with the \"entrypoint\" file, then go to the ones that are imported by that file, and so on.
+Please note that the code should be fully functional. No placeholders.
 
-3. Provide a fully functional and consistent set of files, ensuring the code in one file matches imports/usage in another.
-4. Before finalizing, verify that all parts of the requested architecture are included.
-5. Always provide or update a suitable requirements.txt (for Python) or package.json (for Node.js) if needed.
+Follow a language and framework appropriate best practice file naming convention.
+Make sure that files contain all imports, types etc. Make sure that code in different files are compatible with each other.
+Ensure to implement all code, if you are unsure, write a plausible implementation.
+Include module dependency or package manager dependency definition file.
+Before you finish, double check that all parts of the architecture is present in the files.
 
 Useful to know:
-- You often place different classes/functions in different files.
-- For Python, create an appropriate requirements.txt.
-- For Node.js, create an appropriate package.json.
-- Briefly comment on functions or classes. 
-- Use best practices for the chosen language or framework.
+You almost always put different classes in different files.
+For Python, you always create an appropriate requirements.txt file.
+For NodeJS, you always create an appropriate package.json file.
+You always add a comment briefly describing the purpose of the function definition.
+You try to add comments explaining very complex bits of logic.
+You always follow the best practices for the requested languages in terms of describing the code written as a defined
+package/project.
 
-Remember to respect the instructions from CODE_INTERPRETER_SYSTEM_PROMPT regarding code blocks, backticks, and file placement.
-"""
 
+Python toolbelt preferences:
+- pytest
+- dataclasses"""
 
-interpreter.system_message += CODE_INTERPRETER_SYSTEM_PROMPT+PRMPT2
+interpreter.system_message += CODE_INTERPRETER_SYSTEM_PROMPT