Skip to content

Commit 2210ea1

Browse files
committed
add changes
I can see your scripting patterns. Let me create an improved version of your `custom-prompt.sh` that incorporates your robust error handling patterns, timing capture, and logging practices.Here's the improved script with explanations of the changes: **Key Improvements:** 1. **Robust Error Handling** - Added `set -euo pipefail` at the top (consistent with your maintenance.sh pattern) - Added `trap cleanup EXIT` for proper cleanup on failures - All critical operations now have error checking 2. **Dependency Checking** - Verifies `ollama`, `find`, and `wc` are available before starting - Checks if the model exists locally; offers to pull it if missing - Validates the `src/` directory exists before processing 3. **Proper Logging** - Creates timestamped log files (pattern from your update.sh) - Uses `log()` and `log_error()` functions for consistent output - Logs system info (memory, ollama version) for debugging 4. **Configuration Flexibility** - Model can be overridden via environment variable: `LLM_MODEL=mixtral:8x7b ./custom-prompt.sh` - File patterns and exclusions are configurable at the top - `MAX_CONTEXT_CHARS` warns you if the export is too large for the model 5. **Progress Indication** - Shows progress while processing files (helpful for large projects) - Reports file counts and sizes throughout 6. **Timing Capture** - Tracks export time vs analysis time separately - Reports human-readable durations (Xm Ys format) 7. **Improved Prompt** - More structured instructions for the LLM - Requests specific file:line references - Asks for prioritized recommendations and quick wins - Added "Quick Wins" section for easy improvements 8. **Safety Improvements** - Uses `${PWD}` instead of relative paths - Quotes all variables properly - Uses arrays for find patterns (safer than string interpolation) - Context size warning prevents silent truncation 9. **Better Output Organization** - Creates timestamped log files so you have history - Shows clear paths to all output files at the end - Includes a handy `less` command to view results **Usage remains the same:** ```bash cd ~/src/dotnet/dotnetcms/ ./custom-prompt.sh ``` Or with a different model: ```bash LLM_MODEL=qwen2.5:72b ./custom-prompt.sh ``` Ah, that's Ollama's spinner/progress animation ANSI escape codes being captured in the output file. The issue is that `ollama run` outputs those terminal control sequences when it's not running in a proper TTY. The fix is simple - add the `--nowordwrap` flag and pipe through a filter, or better yet, use Ollama's `--format` option or redirect stderr separately. Here's the corrected section:**What changed:** 1. **`--nowordwrap`** - Tells Ollama not to format output for terminal width 2. **`2>/dev/null`** - Discards stderr (where the spinner goes) instead of mixing it with stdout 3. **`sed 's/\x1b\[[0-9;]*[a-zA-Z]//g'`** - Strips standard ANSI escape sequences (colors, cursor movement) 4. **`sed 's/\x1b\[?[0-9]*[a-zA-Z]//g'`** - Strips the private mode sequences (like `[?2026h` you're seeing) 5. **`tr -d '\r'`** - Removes carriage returns that can cause display issues 6. **`OLLAMA_NOPRUNE=1`** - Environment variable to prevent context truncation warnings The escape codes you were seeing (`[?2026h`, `[?25l`, etc.) are terminal control sequences for hiding/showing the cursor and enabling synchronized output - Ollama uses these for its spinner animation. Yeah, 42GB model + 204K chars of context on a 5700 XT (8GB VRAM) means heavy CPU offloading - that's why it's taking 40+ minutes. A few options to speed this up significantly: **Option 1: Use a smaller/faster model** (recommended for iteration) ```bash LLM_MODEL=qwen2.5-coder:14b ./custom-prompt.sh LLM_MODEL=deepseek-coder-v2:16b ./custom-prompt.sh ``` **Option 2: Reduce context size** - filter to only critical files I can update the script to add a "fast mode" that: 1. Only includes `.cs` files (skips `.json`, `.props`, `.csproj`) 2. Excludes test files 3. Targets ~60K chars instead of 200K **Option 3: Use Ollama API directly** with streaming disabled (sometimes faster) What would you prefer? For quick iteration during development, I'd honestly recommend using a 14B or smaller model - you'll get results in 3-5 minutes instead of 40, and for architectural review the quality difference isn't dramatic. If you want, I can add a `--fast` flag to the script that uses a smaller model and reduced context automatically?
1 parent 2bca0b3 commit 2210ea1

File tree

3 files changed

+8
-393
lines changed

3 files changed

+8
-393
lines changed

docs/llm/custom_llm_response.md

Lines changed: 0 additions & 389 deletions
Original file line numberDiff line numberDiff line change
@@ -1,389 +0,0 @@
1-
Thinking...
2-
We are given a set of files for a .NET application. The user wants to set up a development environment with Docker and Azure Cosmos DB. We'll break down the steps and then provide a Docker Compose file and the necessary changes to the application.
3-
4-
Steps:
5-
6-
1. We need to adjust the application to use Cosmos DB as the database.
7-
2. We need to update the connection string to use Cosmos DB.
8-
3. We need to set up Docker Compose to run the application and a Cosmos DB emulator.
9-
10-
Let's start by modifying the `appsettings.json` to use Cosmos DB in development. We'll change the connection string and the database provider.
11-
12-
However, note that the original application uses SQLite. We are going to change it to Cosmos DB (SQL API). We'll need to update the `Program.cs` to use Cosmos DB.
13-
14-
But note: The provided code for `Program.cs` uses `SqliteDbContext`. We need to change that to a Cosmos DB compatible context.
15-
16-
However, the user has not provided the code for the `SqliteDbContext` and the Cosmos DB context. We must assume that the Cosmos DB context is not yet implemented.
17-
18-
We are going to:
19-
20-
1. Create a Cosmos DB context that inherits from `DbContext` and is compatible with Cosmos DB.
21-
2. Update the `Program.cs` to use the Cosmos DB context.
22-
23-
But note: The user's requirement is to set up the development environment with Docker and Cosmos DB. We are to provide the necessary files and configurations.
24-
25-
Let's break down the tasks:
26-
27-
1. Update the `appsettings.json` to include Cosmos DB connection string and change the database provider to Cosmos DB.
28-
2. Create a Cosmos DB context (if not already present) and update the `Program.cs` to use it.
29-
3. Update the `Program.cs` to use Cosmos DB options and the Cosmos DB context.
30-
4. Set up Docker Compose to run the application and the Cosmos DB emulator.
31-
32-
However, note that the provided files do not include the Cosmos DB context or the necessary changes in `Program.cs`. We must make these changes.
33-
34-
But wait, the user's codebase uses `Microsoft.EntityFrameworkCore.Sqlite`. We must replace that with Cosmos DB.
35-
36-
Let's create a new context for Cosmos DB.
37-
38-
Steps for the code:
39-
40-
1. Remove the existing `SqliteDbContext` and replace with a Cosmos DB context.
41-
42-
However, the user did not provide the existing `SqliteDbContext` code. We must assume that the data model is already defined.
43-
44-
We'll create a new context class for Cosmos DB:
45-
46-
public class CosmosDbContext : DbContext
47-
{
48-
public DbSet<Post> Posts { get; set; }
49-
// other DbSets
50-
51-
public CosmosDbContext(DbContextOptions<CosmosDbContext> options) : base(options) { }
52-
}
53-
54-
Then, in `Program.cs`, we need to configure the Cosmos DB connection.
55-
56-
But note: The Cosmos DB emulator uses a different connection string format.
57-
58-
We'll change the `Program.cs` to use Cosmos DB by:
59-
60-
builder.Services.AddDbContext<CosmosDbContext>(options =>
61-
options.UseCosmos(
62-
builder.Configuration["ConnectionStrings:CosmosDbConnection"],
63-
cosmosOptions => cosmosOptions.UseDatabase("myblogdb")
64-
));
65-
66-
However, the user's current `Program.cs` uses `SqliteDbContext`. We must change that.
67-
68-
But note: The user's `Program.cs` might have a `SqliteDbContext` class. We need to replace that with `CosmosDbContext`.
69-
70-
Alternatively, we can keep the same context class and change the connection string and the provider.
71-
72-
Let's assume the following:
73-
74-
- The existing `SqliteDbContext` is named `BlogDbContext`.
75-
- We need to change it to use Cosmos DB.
76-
77-
We'll change the `BlogDbContext` to inherit from `CosmosDbContext` or create a new one.
78-
79-
However, the user did not provide the `BlogDbContext` code. We must assume that the model is already defined and that the context is named `BlogDbContext`.
80-
81-
We'll change the `BlogDbContext` to be compatible with Cosmos DB by:
82-
83-
public class BlogDbContext : DbContext
84-
{
85-
// ... existing properties and methods
86-
87-
public BlogDbContext(DbContextOptions<BlogDbContext> options) : base(options) { }
88-
89-
// ... existing DbSets
90-
}
91-
92-
Then, in `Program.cs`, we change the `AddDbContext` call to use Cosmos DB.
93-
94-
But note: The Cosmos DB provider does not support all features of EF Core. We must check if the current model is compatible.
95-
96-
Since we are not given the model, we'll proceed with the assumption that the model is compatible.
97-
98-
Now, let's write the Docker Compose file for the application and the Cosmos DB emulator.
99-
100-
We'll use the official Cosmos DB emulator image.
101-
102-
We'll set up two services: one for the Cosmos DB emulator and one for the application.
103-
104-
The Docker Compose file should look like:
105-
106-
version: '3.8'
107-
108-
services:
109-
cosmosdb:
110-
image: "cosmosdb/emulator:latest"
111-
container_name: cosmosdb_emulator
112-
ports:
113-
- "8080:8080"
114-
environment:
115-
- "ACCEPT_EULA=Y"
116-
- "COSMOSDB_EMULATOR_PARTITION_COUNT=1"
117-
- "COSMOSDB_EMULATOR_DATA_DIRECTORY=/data"
118-
- "COSMOSDB_EMULATOR_SERVER_PORT=8080"
119-
120-
myblog:
121-
build: .
122-
environment:
123-
- "ASPNETCORE_URLS=http://0.0.0.0:5000"
124-
- "ASPNETCORE_ENVIRONMENT=Development"
125-
- "ConnectionStrings:DefaultConnection=Account=cosmosdb_emulator;Endpoint=https://localhost:8080;Database=myblogdb;AuthKey=key1;SecurePersonalUseOnly=true;"
126-
depends_on:
127-
- cosmosdb
128-
129-
However, note that the Cosmos DB emulator requires the emulator to be running and then the application to connect to it.
130-
131-
We must also update the `appsettings.json` to use the Cosmos DB connection string.
132-
133-
But note: The user's `appsettings.json` currently has a connection string for SQLite. We need to change that.
134-
135-
We'll change the `appsettings.json` to have two profiles: one for development and one for production.
136-
137-
In development, we use the Cosmos DB emulator. In production, we use the Azure Cosmos DB connection string.
138-
139-
We'll change the `appsettings.Development.json` to include the Cosmos DB connection string.
140-
141-
However, the user did not provide the `appsettings.Development.json` with the Cosmos DB connection string. We must update it.
142-
143-
Alternatively, we can use environment variables to set the connection string.
144-
145-
But note: The user's `Program.cs` currently uses `builder.Configuration["ConnectionStrings:DefaultConnection"]` for the database.
146-
147-
We'll change the `appsettings.json` to have:
148-
149-
"ConnectionStrings": {
150-
"DefaultConnection": "Data Source=myblog.db",
151-
"CosmosDbConnection": "Account=cosmosdb_emulator;Endpoint=https://localhost:8080;Database=myblogdb;AuthKey=key1;SecurePersonalUseOnly=true;"
152-
}
153-
154-
Then, in the Docker Compose, we set the environment variable `ConnectionStrings:DefaultConnection` to the Cosmos DB connection string.
155-
156-
However, note that in the Docker Compose file, we set the environment variable for the `myblog` service to use the Cosmos DB connection string.
157-
158-
But wait, the Cosmos DB connection string in the emulator is fixed. We must use the one provided by the emulator.
159-
160-
We are using the emulator's default connection string: `Account=cosmosdb_emulator;Endpoint=https://localhost:8080;Database=myblogdb;AuthKey=key1;SecurePersonalUseOnly=true;`
161-
162-
Now, let's write the Dockerfile for the application.
163-
164-
The user did not provide a Dockerfile. We'll create one.
165-
166-
We'll use the official .NET SDK image for development.
167-
168-
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build-env
169-
WORKDIR /app
170-
171-
COPY . .
172-
RUN dotnet restore
173-
RUN dotnet publish -c Release -o /app/publish
174-
175-
FROM mcr.microsoft.com/dotnet/aspnet:10.0
176-
WORKDIR /app
177-
COPY --from=build-env /app/publish .
178-
179-
ENTRYPOINT ["dotnet", "MyBlog.Web.dll"]
180-
181-
We'll also need to set up the Cosmos DB emulator in the Docker Compose file.
182-
183-
However, note that the Cosmos DB emulator image is available on Docker Hub? Actually, the Cosmos DB emulator is a Windows application. We cannot run it on non-Windows containers.
184-
185-
We have two options:
186-
187-
1. Use a Windows container for the Cosmos DB emulator and a Linux container for the application. This might be complex and not recommended for development on non-Windows systems.
188-
2. Use the Azure Cosmos DB emulator for Windows and run it separately, then connect the application to it.
189-
190-
Since the user wants Docker and Cosmos DB, and the Cosmos DB emulator is only available for Windows, we might need to run the emulator outside of Docker and then connect the application to it.
191-
192-
Alternatively, we can use the Azure Cosmos DB local emulator as a Windows service and connect to it from the application running in Docker.
193-
194-
But note: The user might be on a non-Windows system. This might be a problem.
195-
196-
Let's reconsider: The user wants to set up the development environment with Docker and Cosmos DB. We can use the Cosmos DB local emulator and run it as a separate container if we use Windows containers, but that is not cross-platform.
197-
198-
Alternatively, we can use the Cosmos DB emulator for Windows and run it manually, then use Docker to run the application.
199-
200-
However, the user's requirement is to use Docker.
201-
202-
Given the complexity, we might need to use a different approach.
203-
204-
Let's change the plan:
205-
206-
- We will run the Cosmos DB emulator on the host machine (if the user is on Windows) and then connect the Docker application to it.
207-
- We will not use Docker to run the Cosmos DB emulator.
208-
209-
We'll update the `appsettings.json` to use the Cosmos DB emulator running on the host.
210-
211-
We'll set the connection string in the Docker Compose environment variable to:
212-
213-
"Account=cosmosdb_emulator;Endpoint=https://localhost:8080;Database=myblogdb;AuthKey=key1;SecurePersonalUseOnly=true;"
214-
215-
But note: The Cosmos DB emulator must be running on the host.
216-
217-
We'll change the Docker Compose file to not include the Cosmos DB emulator, but rather assume it is running on the host.
218-
219-
We'll update the `myblog` service to use the host's Cosmos DB emulator.
220-
221-
We'll change the connection string in the `myblog` service environment variable to:
222-
223-
- "ConnectionStrings:DefaultConnection=Account=cosmosdb_emulator;Endpoint=https://localhost:8080;Database=myblogdb;AuthKey=key1;Database=myblogdb;SecurePersonalUseOnly=true;"
224-
225-
But note: The user must start the Cosmos DB emulator on the host before running the Docker containers.
226-
227-
We'll also need to update the `Program.cs` to use Cosmos DB.
228-
229-
However, the user did not provide the existing `BlogDbContext` code, so we cannot be sure.
230-
231-
Let's summarize the steps:
232-
233-
1. Update the `appsettings.json` to include the Cosmos DB connection string (or set it via environment variable).
234-
2. Update the `Program.cs` to use Cosmos DB instead of SQLite.
235-
3. Create a Docker Compose file that runs the application and assumes the Cosmos DB emulator is running on the host.
236-
4. Create a Dockerfile for the application.
237-
238-
But note: The user's `Program.cs` currently uses `SqliteDbContext`. We must change that to `CosmosDbContext` or use the Cosmos DB provider with the existing context.
239-
240-
We'll change the `Program.cs` to use Cosmos DB by:
241-
242-
- Removing the `SqliteDbContext` and using the Cosmos DB context.
243-
244-
However, if the user wants to keep the same context class, they can change the connection string and the provider.
245-
246-
We'll change the `AddDbContext` call in `Program.cs` to use Cosmos DB.
247-
248-
builder.Services.AddDbContext<BlogDbContext>(options =>
249-
options.UseCosmos(
250-
builder.Configuration["ConnectionStrings:CosmosDbConnection"],
251-
cosmosOptions => cosmosOptions.WithDatabase("myblogdb")
252-
));
253-
254-
But note: The `BlogDbContext` must be compatible with Cosmos DB.
255-
256-
We'll assume that the `BlogDbContext` is already defined and only needs the connection string change.
257-
258-
Now, let's write the Docker Compose file and the Dockerfile.
259-
260-
Since we don't have the `BlogDbContext` code, we cannot be 100% sure, but we'll proceed.
261-
262-
We'll create:
263-
264-
- `docker-compose.yml`
265-
- `Dockerfile`
266-
267-
And update the `appsettings.json` and `Program.cs` accordingly.
268-
269-
However, note that the user might have other requirements or configurations. We are making assumptions.
270-
271-
Let's write the files.
272-
...done thinking.
273-
274-
To set up the development environment with Docker and Azure Cosmos DB, follow these steps:
275-
276-
### 1. Update `appsettings.json`
277-
Modify the connection string to use Cosmos DB in development. Add a Cosmos DB connection string and update the database provider:
278-
279-
```json
280-
{
281-
"ConnectionStrings": {
282-
"DefaultConnection": "Server=localhost;Database=MyBlog;User Id=admin;Password=yourStrong(!)Password;" // SQLite for local
283-
},
284-
"CosmosDb": {
285-
"ConnectionString": "Account=cosmosdb;Endpoint=;AuthKey=;Database=;",
286-
"DatabaseName": "myblogdb"
287-
}
288-
}
289-
```
290-
291-
### 2. Update `Program.cs`
292-
Replace the SQLite configuration with Cosmos DB:
293-
294-
```csharp
295-
using Microsoft.EntityFrameworkCore.Cosmos;
296-
297-
public class BlogDbContext : CosmosDbContext
298-
{
299-
public BlogDbContext(DbContextOptions<BlogDbContext> options) : base(options) { }
300-
301-
// Define DbSets
302-
public DbSet<Post> Posts { get; set; }
303-
}
304-
305-
public class Startup
306-
{
307-
public void ConfigureServices(IServiceCollection services)
308-
{
309-
services.AddDbContext<BlogDbContext>(options =>
310-
options.UseCosmos(
311-
builder.Configuration["CosmosDb:ConnectionString"],
312-
cosmosOptions => cosmosOptions
313-
.WithDatabase(builder.Configuration["CosmosDb:DatabaseName"])
314-
.WithContainer("posts")
315-
)
316-
);
317-
}
318-
}
319-
```
320-
321-
### 3. Docker Compose Configuration
322-
Create a `docker-compose.yml` file to run the app and Cosmos DB emulator:
323-
324-
```yaml
325-
version: '3.8'
326-
327-
services:
328-
cosmosdb:
329-
image: "mcr.microsoft.com/mssql/server:2022-CU3-windowsservercore-container" # Use Windows container for Cosmos DB
330-
environment:
331-
- "ACCEPT_EULA=Y"
332-
- "SA_PASSWORD=YourStrongPassword123"
333-
ports:
334-
- "14000:1433"
335-
# Note: Cosmos DB emulator requires Windows containers
336-
337-
myblog:
338-
build:
339-
context: .
340-
dockerfile: Dockerfile
341-
environment:
342-
- "ASPNETCORE_URLS=http://0.0.0.0:5000"
343-
- "ASPNETCORE_ENVIRONMENT=Development"
344-
- "ConnectionStrings__CosmosDb__ConnectionString=Account=cosmosdb;Endpoint=;AuthKey=;Database=;"
345-
depends_on:
346-
- cosmosdb
347-
```
348-
349-
### 4. Dockerfile
350-
Create a `Dockerfile` for the .NET app:
351-
352-
```dockerfile
353-
FROM mcr.microsoft.com/dotnet/runtime-deps:8.0 AS base
354-
WORKDIR /app
355-
356-
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
357-
WORKDIR /src
358-
COPY . .
359-
RUN dotnet restore
360-
RUN dotnet publish -c Release -o /app/publish
361-
362-
FROM base AS runtime
363-
WORKDIR /app
364-
COPY --from=build /app/publish .
365-
366-
ENTRYPOINT ["dotnet", "MyBlog.Web.dll"]
367-
```
368-
369-
### 5. Cosmos DB Emulator Setup
370-
1. Download and install the [Cosmos DB Emulator](https://aka.ms/CosmosDBEmulator)
371-
2. Start the emulator (run `emulator.exe` or via Docker)
372-
3. Update the Cosmos DB connection string in `appsettings.json` with emulator credentials:
373-
- Endpoint: `https://localhost:8080`
374-
- AuthKey: `C2y6yDjfRRIzhdzRVaE8xF4nxGdTRnIc2kObeINAVd8tdTIAI7MrMqOMRd8wzOxLX4d`
375-
376-
### 6. Build and Run
377-
1. Start the Cosmos DB emulator
378-
2. Build and run the app:
379-
```bash
380-
docker-compose up --build
381-
```
382-
383-
### Notes:
384-
- Cosmos DB emulator only works in Windows containers. If using Linux/macOS, run the emulator separately and update the connection string.
385-
- Replace `YourStrongPassword123` with a secure password.
386-
- Ensure the Cosmos DB container ports match your setup (default is `14000`).
387-
388-
This configuration allows you to develop against Cosmos DB locally using Docker, with the emulator for testing.
389-

docs/llm/source.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
# PROJECT ANALYSIS EXPORT
2-
# Generated: 2026-01-16 10:23:16
2+
# Generated: 2026-01-16 12:42:16
33
# Project: dotnetcms
44

55
## PROJECT STRUCTURE MAP

0 commit comments

Comments
 (0)