To se mi líbí 0
Fork 0

Naposledy aktivní 1781220063

Z revidoval tento gist 1781220063. Přejít na revizi

Žádné změny

Z revidoval tento gist 1777611620. Přejít na revizi

1 file changed, 0 insertions, 0 deletions

Gemma4-DSL-Test.md přejmenováno na Gemma4-DSL-Code-Test.md

Soubor přejmenován beze změn

Z revidoval tento gist 1777611208. Přejít na revizi

1 file changed, 1 insertion, 1 deletion

Gemma4-DSL-Intro.md

@@ -53,7 +53,7 @@ graph TD
53 53 Val -- available --> CreateAcc[Create Account API]
54 54
55 55 CreateAcc -- timeout 5m --> Recovery[Recovery Page]
56 - CreateAcc -- success --> Fork[Fork: Profile Setup]
56 + CreateAcc -- ok --> Fork[Fork: Profile Setup]
57 57
58 58 subgraph Parallel_Profile_Setup
59 59 Fork --> User[Set Username]

Z revidoval tento gist 1777611123. Přejít na revizi

1 file changed, 1 insertion, 1 deletion

Gemma4-DSL-Intro.md

@@ -23,7 +23,7 @@ The process follows a linear path that branches for validation, pauses for async
23 23 #### C. The Provisioning Phase (Async/External)
24 24 * **External Integration:** `Auth.CreateAccount` triggers an external API call (`EXT:AuthService.CreateAccount`).
25 25 * **Async Handling:** The system enters a `WAIT` state, meaning it doesn't block the entire system but waits for a specific event (`Account_Created`).
26 - * **Timeout Safety:** There is a **TTL (Time to Live)** of 5 minutes. If the API doesn't respond, it triggers `Auth.Timeout_Handler` $\rightarrow$ `Page.Recovery`.
26 + * **Timeout Safety:** There is a **TTL (Time to Live)** of 5 minutes. If the API doesn't respond, it triggers `Auth.Timeout_Handler` > `Page.Recovery`.
27 27 * **State Update:** Upon success, it captures the `{uid}` and updates the global `$user_id`.
28 28
29 29 #### D. The Profile Setup (Parallelism/Fork-Join)

Z revidoval tento gist 1777611038. Přejít na revizi

1 file changed, 1 insertion, 1 deletion

Gemma4-DSL-Intro.md

@@ -5,7 +5,7 @@ Here is a detailed breakdown and analysis of the flow described in the snippet:
5 5 ### 1. High-Level Workflow Summary
6 6 The process follows a linear path that branches for validation, pauses for asynchronous API calls, splits into parallel tasks for profile completion, and finally converges on a dashboard.
7 7
8 - **The Journey:** `Welcome` $\rightarrow$ `Validation` $\rightarrow$ `Account Creation` $\rightarrow$ `Profile Setup (Parallel)` $\rightarrow$ `Dashboard`.
8 + **The Journey:** `Welcome` > `Validation` > `Account Creation` > `Profile Setup (Parallel)` > `Dashboard`.
9 9
10 10 ---
11 11

Z revidoval tento gist 1777610939. Přejít na revizi

1 file changed, 0 insertions, 0 deletions

DSL-Test.md přejmenováno na Gemma4-DSL-Test.md

Soubor přejmenován beze změn

Z revidoval tento gist 1777610912. Přejít na revizi

1 file changed, 53 insertions

DSL-Test.md(vytvořil soubor)

@@ -0,0 +1,53 @@
1 + ```python
2 + # ========================================================================
3 + # PROJECT: User Onboarding Flow
4 + # VERSION: 1.0.0
5 + # DESCRIPTION: Handles user registration, account creation,
6 + # parallel profile setup, and dashboard entry.
7 + # ========================================================================
8 + # --- GLOBAL STATE DEFINITIONS ---
9 + $user_id = null
10 + $onboarding_status = "not_started"
11 + $account_created = false
12 + # --- MODULE: PROFILE SETUP (The Parallel Block) ---
13 + # This module handles three tasks that can happen in any order.
14 + Module ProfileSetup {
15 + docs: "docs/profile_setup.md",
16 + # Start by splitting the flow into three parallel paths
17 + Profile.Start F-> [Profile.Username, Profile.Photo, Profile.Interests]
18 + # Individual Node Logic
19 + Profile.Username /input /save {name} -> Profile.Join
20 + Profile.Photo /upload /save {img} -> Profile.Join
21 + Profile.Interests /select /save {tags} -> Profile.Join
22 + # Synchronize: Wait for ALL three to finish before completing the module
23 + [Profile.Username, Profile.Photo, Profile.Interests] J-> Profile.Complete
24 + return {profile_complete: true}
25 + }
26 + # --- MAIN APPLICATION FLOW ---
27 + # 1. Welcome & Email Entry
28 + Welcome.Screen /start /show [doc: "docs/welcome.md"] {email} -> Auth.ValidateEmail
29 + # 2. Email Validation (Branching Logic)
30 + Auth.ValidateEmail /check /verify {email} ? [
31 + exists -> Welcome.Error {msg: "Email already taken"} -> Welcome.Screen,
32 + available -> Auth.CreateAccount
33 + ]
34 + # 3. Account Creation (External API & Async Wait)
35 + Auth.CreateAccount /execute /call [doc: "docs/account_creation.md"]
36 + EXT:AuthService.CreateAccount /post /register {$api_key} {email}
37 + -> WAIT (Account_Created)
38 + T [5m] -> Auth.Timeout_Handler # If API takes > 5 mins, fail
39 + -> $user_id = {uid}
40 + -> $account_created = true
41 + -> Call ProfileSetup
42 + # 4. Transition to Dashboard
43 + ProfileSetup.Complete -> Dashboard.Welcome /render /show {$user_id}
44 + -> $onboarding_status = "completed"
45 + -> Dashboard.Home
46 + # 5. Error Handling (The Dead Letter / Recovery)
47 + Auth.Timeout {
48 + # If the user abandons the process
49 + # Redirect to a "Resume Account" page
50 + Page.Recovery /redirect
51 + }
52 + # --- END OF GRAPH ---
53 + ```

Z revidoval tento gist 1777610844. Přejít na revizi

1 file changed, 80 insertions

Gemma4-DSL-Intro.md(vytvořil soubor)

@@ -0,0 +1,80 @@
1 + This code appears to be written in a **custom Domain Specific Language (DSL)** designed to define **state machines or workflow orchestrations**. It describes a high-level logic map for a User Onboarding process, blending elements of a flowchart, a configuration file, and a programming language.
2 +
3 + Here is a detailed breakdown and analysis of the flow described in the snippet:
4 +
5 + ### 1. High-Level Workflow Summary
6 + The process follows a linear path that branches for validation, pauses for asynchronous API calls, splits into parallel tasks for profile completion, and finally converges on a dashboard.
7 +
8 + **The Journey:** `Welcome` $\rightarrow$ `Validation` $\rightarrow$ `Account Creation` $\rightarrow$ `Profile Setup (Parallel)` $\rightarrow$ `Dashboard`.
9 +
10 + ---
11 +
12 + ### 2. Technical Logic Breakdown
13 +
14 + #### A. Global State & Initialization
15 + * **State Variables:** The system tracks `$user_id`, `$onboarding_status`, and `$account_created`. These act as flags to ensure the user cannot skip steps or to allow the system to resume from a specific point.
16 +
17 + #### B. The Authentication Phase (Sequential/Branching)
18 + * **Entry:** Starts at `Welcome.Screen`.
19 + * **Validation Logic:** The `Auth.ValidateEmail` node acts as a **Decision Gate**.
20 + * **Path A (Error):** If the email `exists`, the user is looped back to the welcome screen with an error message.
21 + * **Path B (Success):** If `available`, the flow proceeds to account creation.
22 +
23 + #### C. The Provisioning Phase (Async/External)
24 + * **External Integration:** `Auth.CreateAccount` triggers an external API call (`EXT:AuthService.CreateAccount`).
25 + * **Async Handling:** The system enters a `WAIT` state, meaning it doesn't block the entire system but waits for a specific event (`Account_Created`).
26 + * **Timeout Safety:** There is a **TTL (Time to Live)** of 5 minutes. If the API doesn't respond, it triggers `Auth.Timeout_Handler` $\rightarrow$ `Page.Recovery`.
27 + * **State Update:** Upon success, it captures the `{uid}` and updates the global `$user_id`.
28 +
29 + #### D. The Profile Setup (Parallelism/Fork-Join)
30 + This is the most complex part of the DSL. It uses a **Fork-Join pattern**:
31 + 1. **Fork (`F->`):** The flow splits into three concurrent paths:
32 + * `Profile.Username`
33 + * `Profile.Photo`
34 + * `Profile.Interests`
35 + 2. **Independent Execution:** These can be completed in **any order**. Each node performs a `/save` operation.
36 + 3. **Join (`J->`):** The system uses a synchronization barrier. It will not proceed to `Profile.Complete` until **all three** parallel paths have reported completion.
37 +
38 + #### E. Finalization (The Happy Path)
39 + * Once `ProfileSetup.Complete` is reached, the user is transitioned to `Dashboard.Welcome`.
40 + * The global status is updated to `$onboarding_status = "completed"`.
41 + * The flow ends at `Dashboard.Home`.
42 +
43 + ---
44 +
45 + ### 3. Visual Representation (Logic Map)
46 +
47 + ```mermaid
48 + graph TD
49 + Start((Start)) --> Welcome[Welcome Screen]
50 + Welcome --> Val{Validate Email}
51 +
52 + Val -- exists --> Welcome
53 + Val -- available --> CreateAcc[Create Account API]
54 +
55 + CreateAcc -- timeout 5m --> Recovery[Recovery Page]
56 + CreateAcc -- success --> Fork[Fork: Profile Setup]
57 +
58 + subgraph Parallel_Profile_Setup
59 + Fork --> User[Set Username]
60 + Fork --> Photo[Upload Photo]
61 + Fork --> Int[Select Interests]
62 +
63 + User --> Join
64 + Photo --> Join
65 + Int --> Join
66 + end
67 +
68 + Join[Join/Sync] --> DashWelcome[Dashboard Welcome]
69 + DashWelcome --> DashHome((Dashboard Home))
70 + ```
71 +
72 + ### 4. Key DSL Syntax Observations
73 + If you are implementing or extending this language, here are the key operators identified:
74 + * `/start`, `/show`, `/upload`, `/save`, `/execute`: **Action Operators** (define what the node does).
75 + * `->`: **Transition** (defines the next state).
76 + * `? [ ... ]`: **Conditional Branching**.
77 + * `F->` and `J->`: **Concurrency Control** (Fork and Join).
78 + * `EXT:`: **External Service Bridge**.
79 + * `T [time]`: **Timeout Constraint**.
80 + * `{var}`: **Data Injection/Extraction**.
Novější Starší

Vytvořeno pomocí Opengist ⋅ Load: 47ms⋅

Čeština