Anwar11234 commited on
Commit
952a040
1 Parent(s): 403c9e5

first commit

Browse files
.env ADDED
@@ -0,0 +1 @@
 
 
1
+ GROQ_API_KEY=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
Dockerfile ADDED
@@ -0,0 +1,14 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # Use the official Python 3.10.9 image
2
+ FROM python:3.10.9
3
+
4
+ # Copy the current directory contents into the container at .
5
+ COPY . .
6
+
7
+ # Set the working directory to /
8
+ WORKDIR /
9
+
10
+ # Install requirements.txt
11
+ RUN pip install --no-cache-dir -r /requirements.txt
12
+
13
+ # Start the FastAPI app on port 7860, the default port expected by Spaces
14
+ CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "7860"]
__pycache__/examples.cpython-39.pyc ADDED
Binary file (18.6 kB). View file
 
__pycache__/main.cpython-39.pyc ADDED
Binary file (2.15 kB). View file
 
__pycache__/system_message.cpython-39.pyc ADDED
Binary file (3.3 kB). View file
 
examples.py ADDED
@@ -0,0 +1,419 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ examples = [
2
+ {"input": "Explain the concept of recursion",
3
+ "output": """Recursion is a programming technique where a function calls itself directly or indirectly in order to solve a problem. The recursive function solves a small part of the problem and then calls itself to solve the smaller remaining problem. This continues until the function reaches a base case, which is a condition that stops the recursion.
4
+
5
+ To illustrate this concept, I will create a flowchart showing how recursion works with an example of calculating the factorial of a number. A flowchart is suitable here as it helps visualize the step-by-step process of recursion.
6
+
7
+ Example: Calculating Factorial
8
+ Factorial of n (n!) is the product of all positive integers up to n.
9
+ Recursive Definition:
10
+ Base Case: fact(1) = 1
11
+ Recursive Case: fact(n)=n*fact(n-1)
12
+
13
+ Flowchart:
14
+ ```mermaid
15
+ graph TD
16
+ A["Main Program"] --> B["fact(4)"]
17
+ B --> C["fact(3)"]
18
+ C --> D["fact(2)"]
19
+ D --> E["fact(1)"]
20
+ E -- base case: \n return 1 --> D
21
+ D -- return 2 * 1 = 2 --> C
22
+ C -- return 3 * 2 = 6 --> B
23
+ B -- return 4 * 6 = 24 --> A
24
+ ```
25
+
26
+ This diagram illustrates the recursive calculation of the factorial of 4. Here's a step-by-step explanation:
27
+ 1. Main Program starts the calculation and calls fact(4).
28
+ 2. fact(4) calls fact(3).
29
+ 3. fact(3) calls fact(2).
30
+ 4. fact(2) calls fact(1).
31
+ 5. fact(1) hits the base case and returns 1.
32
+ 6. The result of fact(1) is used by fact(2) to return 2.
33
+ 7. The result of fact(2) is used by fact(3) to return 6.
34
+ 8. The result of fact(3) is used by fact(4) to return 24."""},
35
+
36
+ {"input": "explain the binary search algorithm.",
37
+ "output": """
38
+ Binary search is an efficient algorithm for finding an item from a sorted list of items. It works by repeatedly dividing in half the portion of the list that could contain the item, until you've narrowed down the possible locations to just one.
39
+ To visualize the algorithm's steps, a flowchart is most suitable.
40
+ ```mermaid
41
+ graph TD
42
+ A["Start"] --> B["Initialize low = 0, high = n-1"]
43
+ B --> C["Calculate mid = (low + high) / 2"]
44
+ C --> D["Compare target with arr[mid]"]
45
+ D --> E["Target found at mid"]
46
+ D --> F["Target < arr[mid]"]
47
+ D --> G["Target > arr[mid]"]
48
+ F --> H["Update high = mid - 1"]
49
+ G --> I["Update low = mid + 1"]
50
+ H --> C
51
+ I --> C
52
+ E --> J["End"]
53
+ C --> K["low > high"]
54
+ K --> L["Target not found"]
55
+ L --> J
56
+ ```
57
+
58
+ Here's a step-by-step explanation of the binary search algorithm:
59
+
60
+ 1. Initialize `low` to 0 and `high` to `n-1`, where `n` is the length of the array.
61
+ 2. Calculate the middle index `mid` using the formula `(low + high) / 2`.
62
+ 3. Compare the target value with the value at `arr[mid]`.
63
+ 4. If the target value is found at `arr[mid]`, return the index `mid`.
64
+ 5. If the target value is less than `arr[mid]`, update `high` to `mid - 1`.
65
+ 6. If the target value is greater than `arr[mid]`, update `low` to `mid + 1`.
66
+ 7. Repeat steps 2-6 until `low` is greater than `high`.
67
+ 8. If `low` is greater than `high`, the target value is not found in the array.
68
+
69
+ The binary search algorithm has a time complexity of O(log n), making it very efficient for large lists.
70
+ """},
71
+
72
+ {"input": "What are the main principles of Object-Oriented Programming (OOP)?", "output": """
73
+ Object-Oriented Programming (OOP) is a programming paradigm based on the concept of objects. These objects contain data and methods that manipulate that data. To explain the main principles of OOP, I will create a mind map, which is suitable for organizing concepts hierarchically.
74
+
75
+ Mind Map:
76
+ ```mermaid
77
+ mindmap
78
+ root(("Object-Oriented Programming (OOP)"))
79
+ Encapsulation
80
+ Data Hiding
81
+ Access Modifiers
82
+ Private
83
+ Public
84
+ Protected
85
+ Abstraction
86
+ Simplification
87
+ Essential Features
88
+ Interface
89
+ Inheritance
90
+ Reusability
91
+ Base Class
92
+ Derived Class
93
+ Overriding
94
+ Polymorphism
95
+ Method Overloading
96
+ Method Overriding
97
+ Runtime Polymorphism
98
+ Compile-time Polymorphism
99
+ Classes and Objects
100
+ Class Definition
101
+ Object Instantiation
102
+ Attributes
103
+ Methods
104
+ Additional Principles
105
+ Composition
106
+ Aggregation
107
+ Association
108
+
109
+ ```
110
+ This mind map provides a structured overview of the main principles and components of Object-Oriented Programming (OOP).
111
+ 1. Encapsulation
112
+ - Data Hiding: Encapsulation involves hiding the internal state of objects and restricting access to it.
113
+ - Access Modifiers: Controls access levels to the attributes and methods of a class.
114
+ -- Private: Accessible only within the class.
115
+ -- Public: Accessible from any other code.
116
+ -- Protected: Accessible within the class and its subclasses.
117
+ 2. Abstraction
118
+ - Simplification: Focuses on the essential qualities of an object rather than the specific characteristics.
119
+ - Essential Features: Provides only the necessary details and hides the complexity.
120
+ - Interface: Defines a contract for what a class can do without specifying how it does it.
121
+ 3. Inheritance
122
+ - Reusability: Allows a new class to inherit properties and behaviors from an existing class.
123
+ - Base Class: The class whose properties are inherited.
124
+ - Derived Class: The class that inherits properties from the base class.
125
+ - Overriding: Allows a subclass to provide a specific implementation of a method already defined in its superclass.
126
+ 4. Polymorphism
127
+ - Method Overloading: Allows multiple methods with the same name but different parameters within the same class.
128
+ - Method Overriding: Allows a subclass to provide a specific implementation of a method defined in its superclass.
129
+ - Runtime Polymorphism: Method overriding achieved during runtime.
130
+ - Compile-time Polymorphism: Method overloading achieved during compile-time.
131
+ 5. Classes and Objects
132
+ - Class Definition: A blueprint for creating objects (a particular data structure).
133
+ - Object Instantiation: The creation of a real instance (object) from a class.
134
+ - Attributes: Characteristics or properties of a class.
135
+ - Methods: Functions or behaviors defined within a class.
136
+ 6. Additional Principles
137
+ - Composition: A way to combine simple objects or data types into more complex ones.
138
+ - Aggregation: A specialized form of composition where the child can exist independently of the parent.
139
+ - Association: A relationship between two objects.
140
+ """},
141
+
142
+ {"input": "what're middlewares in terms of backend development?" ,
143
+ "output": """In backend development, a middleware is a software component that mediates between two or more applications, services, or systems. It acts as an intermediary layer that enables communication, data exchange, and functionality between these entities.
144
+
145
+ To illustrate the concept of middleware, a sequence diagram is most suitable. It shows the flow of requests and responses between components.
146
+
147
+ Sequence Diagram:
148
+ ```mermaid
149
+ sequenceDiagram
150
+ participant Client as "Client App"
151
+ participant Middleware as "Middleware"
152
+ participant Server as "Backend Server"
153
+
154
+ Client->>Middleware: Request
155
+ Middleware->>Middleware: Process request
156
+ Middleware->>Server: Forward request
157
+ Server->>Middleware: Response
158
+ Middleware->>Middleware: Process response
159
+ Middleware->>Client: Forward response
160
+ ```
161
+ In this sequence diagram, the middleware acts as an intermediary between the client application and the backend server. It receives requests from the client, processes them, and then forwards them to the server. The server responds to the middleware, which then processes the response and forwards it to the client.
162
+
163
+ Middlewares can perform various tasks, such as:
164
+
165
+ 1. Authentication and authorization
166
+ 2. Request and response logging
167
+ 3. Error handling and debugging
168
+ 4. Data encryption and decryption
169
+ 5. Rate limiting and throttling
170
+ 6. Caching and content delivery
171
+ 7. API gateway and routing
172
+ 8. Message queuing and workflow management"""},
173
+ {"input": "Explain the client server architecture using a sequence diagram",
174
+ "output": """
175
+ Here is a sequence diagram explaining the client-server architecture:
176
+ ```mermaid
177
+ sequenceDiagram
178
+ participant Client as "Client"
179
+ participant Server as "Server"
180
+
181
+ note over Client: "Client initiates request"
182
+ Client->>Server: Request (e.g. HTTP GET)
183
+ Server->>Server: Process request
184
+ Server->>Database: Query database (if necessary)
185
+ Database->>Server: Return data (if necessary)
186
+ Server->>Client: Response (e.g. HTML page)
187
+ note over Client: "Client receives response"
188
+
189
+ alt Error handling
190
+ Server->>Client: Error response (e.g. 404 Not Found)
191
+ end
192
+ ```
193
+ Here's a step-by-step explanation of the sequence diagram:
194
+
195
+ 1. The client initiates a request to the server, such as an HTTP GET request.
196
+ 2. The server receives the request and processes it.
197
+ 3. The server sends a response back to the client, such as an HTML page.
198
+ 4. The client receives the response and displays it to the user.
199
+
200
+ In the error handling scenario:
201
+
202
+ 1. The server encounters an error while processing the request.
203
+ 2. The server sends an error response back to the client, such as a 404 Not Found error.
204
+ 3. The client receives the error response and displays an error message to the user.
205
+
206
+ This sequence diagram illustrates the basic client-server architecture, where the client initiates a request, the server processes it, and the server sends a response back to the client.
207
+ """}
208
+ ,
209
+ {"input": "Create a class diagram for a simple e-commerce system with classes for User, Product, Order, and Payment", "output": """
210
+ To model the relationships and structure of a simple e-commerce system, a class diagram is most appropriate. It allows us to visualize the classes, their attributes, methods, and relationships.
211
+ Class Diagram:
212
+ ```mermaid
213
+ classDiagram
214
+ class User {
215
+ +int userId
216
+ +String name
217
+ +String email
218
+ +String password
219
+ +login()
220
+ +logout()
221
+ }
222
+ class Product {
223
+ +int productId
224
+ +String name
225
+ +String description
226
+ +float price
227
+ +int stock
228
+ +addProduct()
229
+ +removeProduct()
230
+ }
231
+ class Order {
232
+ +int orderId
233
+ +Date orderDate
234
+ +addProduct(Product product)
235
+ +removeProduct(Product product)
236
+ +calculateTotal()
237
+ }
238
+ class Payment {
239
+ +int paymentId
240
+ +float amount
241
+ +Date paymentDate
242
+ +processPayment()
243
+ }
244
+
245
+ User "1" --> "0..*" Order : places
246
+ Order "1" --> "1" Payment : has
247
+ Order "1" --> "0..*" Product : contains
248
+ Product "0..*" --> "1" Order : ordered in
249
+ ```
250
+ This class diagram depicts a simplified model for an e-commerce system. Let's break down each component:
251
+
252
+ 1. User Class:
253
+ - Attributes: userId, name, email, password
254
+ - Methods: login(), logout()
255
+ - Relationship: A User can place 0 to * Orders (1 to * relationship).
256
+ 2. Product Class:
257
+ - Attributes: productId, name, description, price, stock
258
+ - Methods: addProduct(), removeProduct()
259
+ - Relationship: A Product can be contained in 0 to * Orders (0..* to 1 relationship).
260
+
261
+ 3. Order Class:
262
+
263
+ - Attributes: orderId, orderDate
264
+ - Methods: addProduct(Product product), removeProduct(Product product), calculateTotal()
265
+ - Relationship: An Order has exactly 1 Payment (1 to 1 relationship) and can contain 0 to * Products (1 to 0..* relationship).
266
+
267
+ 4. Payment Class:
268
+ - Attributes: paymentId, amount, paymentDate
269
+ - Methods: processPayment()
270
+ - Relationship: A Payment is associated with exactly 1 Order (1 to 1 relationship).
271
+ """},
272
+
273
+ {"input": "Explain the behavior of a traffic light system.",
274
+ "output": """
275
+ To model the behavior and state transitions of a traffic light system, a state diagram is most suitable. It helps visualize the different states and the transitions between them.
276
+
277
+ State Diagram:
278
+ ```mermaid
279
+ stateDiagram-v2
280
+ [*] --> Red
281
+ Red --> Green : Timer expires
282
+ Green --> Yellow : Timer expires
283
+ Yellow --> Red : Timer expires
284
+ ```
285
+ """},
286
+ {"input": "Plan a software development project.",
287
+ "output":"""
288
+ To plan a software development project, a Gantt chart is most appropriate. It provides a visual timeline of tasks, their durations, and dependencies, helping in project management.
289
+ Gant Chart:
290
+ ```mermaid
291
+ gantt
292
+ title Software Development Project Plan
293
+ dateFormat YYYY-MM-DD
294
+ section Planning
295
+ Requirement Analysis :a1, 2024-07-01, 10d
296
+ Feasibility Study :a2, after a1, 7d
297
+ Project Planning :a3, after a2, 5d
298
+ section Design
299
+ System Design :b1, 2024-07-20, 15d
300
+ Architecture Design :b2, after b1, 10d
301
+ Database Design :b3, after b1, 10d
302
+ section Development
303
+ Frontend Development :c1, 2024-08-10, 20d
304
+ Backend Development :c2, after c1, 25d
305
+ API Development :c3, after c1, 15d
306
+ section Testing
307
+ Unit Testing :d1, 2024-09-10, 10d
308
+ Integration Testing :d2, after d1, 10d
309
+ System Testing :d3, after d2, 10d
310
+ section Deployment
311
+ Deployment Preparation :e1, 2024-09-30, 5d
312
+ Final Deployment :e2, after e1, 2d
313
+ ```
314
+ This Gantt chart outlines a software development project plan, with tasks divided into five sections: Planning, Design, Development, Testing, and Deployment. Each section contains tasks with specified start dates and durations. Dependencies between tasks are also indicated, meaning that some tasks can only start after others are completed. Here's a breakdown:
315
+
316
+ 1. Planning
317
+ - Requirement Analysis: Starts on 2024-07-01 and lasts for 10 days.
318
+ - Feasibility Study: Starts after Requirement Analysis and lasts for 7 days.
319
+ - Project Planning: Starts after Feasibility Study and lasts for 5 days.
320
+
321
+ 2. Design
322
+ - System Design: Starts on 2024-07-20 and lasts for 15 days.
323
+ - Architecture Design: Starts after System Design and lasts for 10 days.
324
+ - Database Design: Starts after System Design and lasts for 10 days.
325
+
326
+ 3. Development
327
+ - Frontend Development: Starts on 2024-08-10 and lasts for 20 days.
328
+ - Backend Development: Starts after Frontend Development and lasts for 25 days.
329
+ - API Development: Starts after Frontend Development and lasts for 15 days.
330
+
331
+ 4. Testing
332
+ - Unit Testing: Starts on 2024-09-10 and lasts for 10 days.
333
+ - Integration Testing: Starts after Unit Testing and lasts for 10 days.
334
+ - System Testing: Starts after Integration Testing and lasts for 10 days.
335
+
336
+ 5. Deployment
337
+ - Deployment Preparation: Starts on 2024-09-30 and lasts for 5 days.
338
+ - Final Deployment: Starts after Deployment Preparation and lasts for 2 days.
339
+ """},
340
+
341
+ {"input": "Model a library system",
342
+ "output": """
343
+ To model a library system, an Entity-Relationship (ER) diagram is most appropriate. It helps visualize the entities, their attributes, and relationships.
344
+
345
+ ```mermaid
346
+ erDiagram
347
+ BOOK {
348
+ int BookID PK
349
+ string Title
350
+ string Author
351
+ string ISBN
352
+ string Publisher
353
+ int YearPublished
354
+ string Genre
355
+ int CopiesAvailable
356
+ }
357
+
358
+ MEMBER {
359
+ int MemberID PK
360
+ string FirstName
361
+ string LastName
362
+ string Address
363
+ string PhoneNumber
364
+ string Email
365
+ date MembershipDate
366
+ }
367
+
368
+ LOAN {
369
+ int LoanID PK
370
+ int BookID FK
371
+ int MemberID FK
372
+ date LoanDate
373
+ date DueDate
374
+ date ReturnDate
375
+ }
376
+
377
+ BOOK ||--o{ LOAN : has
378
+ MEMBER ||--o{ LOAN : borrows
379
+ ```
380
+ Entities and Attributes:
381
+ 1. Book
382
+ - BookID (Primary Key)
383
+ - Title
384
+ - Author
385
+ - ISBN
386
+ - Publisher
387
+ - YearPublished
388
+ - Genre
389
+ - CopiesAvailable
390
+
391
+ 2. Member
392
+ - MemberID (Primary Key)
393
+ - FirstName
394
+ - LastName
395
+ - Address
396
+ - PhoneNumber
397
+ - Email
398
+ - MembershipDate
399
+
400
+ 3. Loan
401
+ - LoanID (Primary Key)
402
+ - BookID (Foreign Key)
403
+ - MemberID (Foreign Key)
404
+ - LoanDate
405
+ - DueDate
406
+ - ReturnDate
407
+
408
+ Relationships:
409
+ 1. Book - Loan
410
+ - One Book can be associated with many Loans.
411
+ - One Loan is associated with one Book.
412
+ - Relationship: "Book" 1..* - 0..1 "Loan"
413
+
414
+ 2. Member - Loan
415
+ - One Member can have many Loans.
416
+ - One Loan is associated with one Member.
417
+ - Relationship: "Member" 1..* - 0..1 "Loan"
418
+ """}
419
+ ]
main.py ADDED
@@ -0,0 +1,82 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ import os
2
+ from fastapi import FastAPI, HTTPException
3
+ from pydantic import BaseModel
4
+ from dotenv import load_dotenv
5
+ from langchain_core.prompts import ChatPromptTemplate, FewShotChatMessagePromptTemplate
6
+ from langchain_groq import ChatGroq
7
+ from langchain_core.output_parsers import StrOutputParser
8
+ from examples import examples
9
+ from system_message import sys_msg
10
+
11
+ # Load environment variables from .env file
12
+ load_dotenv()
13
+
14
+ # Get the Groq API key from environment variables
15
+ GROQ_API_KEY = os.getenv("GROQ_API_KEY")
16
+
17
+ if not GROQ_API_KEY:
18
+ raise ValueError("GROQ_API_KEY environment variable not set")
19
+
20
+ # FastAPI app initialization
21
+ app = FastAPI()
22
+
23
+ # Define the input data model
24
+ class PromptRequest(BaseModel):
25
+ input: str
26
+ model: str = "llama" # Default model is LLaMA
27
+
28
+ def get_final_prompt():
29
+ example_prompt = ChatPromptTemplate.from_messages(
30
+ [
31
+ ("human", "{input}"),
32
+ ("ai", "{output}")
33
+ ]
34
+ )
35
+
36
+ few_shot_prompt = FewShotChatMessagePromptTemplate(
37
+ example_prompt=example_prompt,
38
+ examples=examples
39
+ )
40
+
41
+ # Final prompt template
42
+ final_prompt = ChatPromptTemplate.from_messages(
43
+ [
44
+ ("system", sys_msg),
45
+ few_shot_prompt,
46
+ ("human", "{input}")
47
+ ]
48
+ )
49
+
50
+ return final_prompt
51
+
52
+ def get_model_response(model , input_text):
53
+ models = {
54
+ "mixtral": "mixtral-8x7b-32768",
55
+ "llama": "llama3-70b-8192"
56
+ }
57
+
58
+ final_prompt = get_final_prompt()
59
+ chat = ChatGroq(groq_api_key=GROQ_API_KEY, model_name=models[model], temperature=0.0)
60
+ output_parser = StrOutputParser()
61
+ chain = final_prompt | chat | output_parser
62
+ return chain.invoke({"input": input_text})
63
+
64
+ def format_response(response: str) -> str:
65
+ # Replace '\n\n' with two new lines to keep paragraph breaks
66
+ formatted_response = response.replace('\\n\\n', '\n\n')
67
+
68
+ # Replace '\\n' with a single new line to maintain line breaks
69
+ formatted_response = formatted_response.replace('\\n', '\n')
70
+
71
+ return formatted_response
72
+
73
+ @app.post("/generate-response/")
74
+ async def generate_response(request: PromptRequest):
75
+ input_text = request.input
76
+ model_choice = request.model.lower()
77
+
78
+ response = get_model_response(model_choice , input_text)
79
+ return {"response": format_response(response)}
80
+
81
+ # To run the FastAPI app, use:
82
+ # uvicorn main:app --reload
system_message.py ADDED
@@ -0,0 +1,36 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ sys_msg = """
2
+
3
+ You are an expert in generating Mermaid diagrams from natural language descriptions. Mermaid is a Markdown-inspired tool that allows users to create diagrams and visualizations using a simple syntax.
4
+ The user will ask you to explain some concept and your task is to explain concepts with the help of visualization, you can generate diagrams only if you were specifically asked to do that, but if you weren't asked to just generate a diagram and were asked to explain something then do your best to use visualization to make the explanation a lot more clear. For each input, ensure the output is a correctly formatted Mermaid diagram code that accurately represents the described structure, even if the user does not explicitly request a diagram.
5
+
6
+ Follow these guidelines for generating the correct types of diagrams:
7
+ 1. Flowcharts are suitable for: Algorithm visualization, process flows ,conditional logic, and control structures (if-else, loops).
8
+ 2. Sequence Diagrams are suitable for: Interaction between objects or components, communication protocols, method calls in OOP, and client-server interactions.
9
+ 3. Class Diagrams are suitable for: Object-Oriented Programming (OOP) concepts, class structures, inheritance and relationships, and system architecture.
10
+ 4. State Diagrams are suitable for: State machines, lifecycle of objects, protocol states, and workflow states
11
+ 5. Entity-Relationship Diagrams (ERD) are suitable for: Database schema design, relationships between data entities, and data modeling.
12
+ 6. Gantt Charts are suitable for: Project management, task scheduling, and timeline of events.
13
+ 7. Mind Maps are suitable for: Brainstorming ideas, roadmaps, concept mapping, and hierarchical information.
14
+
15
+ When generating diagrams using the Mermaid diagramming language, ensure to follow these guidelines to avoid common syntax errors:
16
+ 1. In flowcharts, if any node label contains parentheses or brackets or unicode characters, then make sure to enclose that label in double quotation marks. For example: D[replace arr[i] with arr[i+1]] will cause a syntax error while D["replace arr[i] with arr[i+1]"] won't, Also E[fact(3)] will cause a syntax error while E["fact(3)"] won't.
17
+
18
+ 2. In flowcharts, to add text above arrows follow one of these formats:
19
+ - A-->|text|B (correct)
20
+ - A-- text -->B (correct)
21
+ any other format will cause a syntax error, for example this is incorrect and will cause syntax error:
22
+ - A --> text>B. (incorrect)
23
+ - A -->|text|> B (incorrect)
24
+
25
+ 3. Never add notes or alts when creating sequence diagrams,additional comments or alternative scenarios are not supported directly. DON'T ADD NOTES TO SEQUENCE DIAGRAMS.
26
+
27
+ When responding, follow this format:
28
+
29
+ [Explanation in simple terms]
30
+
31
+ [Mermaid diagram type]:
32
+ [Your generated Mermaid code]
33
+ [Brief explanation of the Mermaid diagram]
34
+
35
+ Be precise and maintain the syntax of Mermaid diagrams and make sure you follow the given guidlines. If any information is unclear or incomplete, make reasonable assumptions to complete the diagram.
36
+ """
test.py ADDED
@@ -0,0 +1,16 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ import requests
2
+
3
+ # Define the URL of the API endpoint
4
+ url = "http://127.0.0.1:8000/generate-response/"
5
+
6
+ # Define the payload
7
+ payload = {
8
+ "input": "give me a roadmap for frontend development using a mindmap.",
9
+ "model": "llama" # Change to "mixtral" to test the Mixtral model
10
+ }
11
+
12
+ # Send a POST request to the API
13
+ response = requests.post(url, json=payload)
14
+
15
+ # Print the response from the API
16
+ print(response.json())