Spaces:
Sleeping
Sleeping
Anwar11234
commited on
Commit
•
952a040
1
Parent(s):
403c9e5
first commit
Browse files- .env +1 -0
- Dockerfile +14 -0
- __pycache__/examples.cpython-39.pyc +0 -0
- __pycache__/main.cpython-39.pyc +0 -0
- __pycache__/system_message.cpython-39.pyc +0 -0
- examples.py +419 -0
- main.py +82 -0
- system_message.py +36 -0
- test.py +16 -0
.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())
|