[Sugar-devel] Requesting the 2nd Feedback, made changes after getting the feedback.

[Chihurumnaya Ibiam]

Please use the reply-all next time to keep the conversation in the list.

300MB is a lot to bundle with an activity, when you say download once, you
make it seem like that's an advantage
when it's not.
You should use Sugar, it doesn't seem like you have because of the data
folder path you mentioned, I might
be wrong of course but it doesn't seem like you have.

The premise for checking issues like missing colons assumes the kids would
only want to check for a particular
language, which is why particularly handling such issues doesn't seem like
a great idea to me.
If you let the model handle such issues then that makes sense, not you
writing checks for those cases.

You've mentioned testing if kids will need data between sessions, do you
have kids to test this with?
I'd said what I said because if you need to save activity data, for
instance saving a game state makes sense,
then save the data, if you don't need to save data then don't save the data.

-- 

Ibiam Chihurumnaya
ibiamchihurumnaya at gmail.com




On Sat, Apr 5, 2025 at 11:01 AM Anurag Mishra <anuragmishra0521 at gmail.com>
wrote:

> Thank you, Ibaim, for your feedback on my plan to add a debugger to Pippy
> using a language model. This is what I was looking for(detailed feedback).
> I’ve thought about your comments and want to explain how we’ll do this(In
> GSoc time), keeping it simple and useful for kids learning to code in
> Sugar. The points are mentioned below -
>
>    1. Offline Model and Bundling
>    You asked if we’ll bundle the model with Pippy since it runs offline.
>    We’re planning to use a model like distilgpt2 that works without
>    internet, but it’s about 300MB, which might be too big to include in
>    Pippy’s file. Instead, we’ll download it once and save it in Pippy’s data
>    folder (like ~/SugarLabs/Pippy/data). This keeps Pippy small and works
>    offline after setup. If that’s still too large, we’ll find a smaller model
>    to include directly. We’ll test both ways to see what works best.
>    2. API Option and Measuring Delay
>    You asked how we’ll measure delay if the model is slow. If it takes
>    too long on older devices, we’ll use an online API (like xAI’s) when
>    internet is available. We’ll measure how many seconds it takes from
>    clicking “Debug” to showing the answer. If it’s more than 2 seconds, we’ll
>    try the API instead, but only if online. We’ll check this on real Sugar
>    hardware to get it right.
>    3. Finding Errors
>    You mentioned using exec() in a safe way or ast for checking code, and
>    asked if we’ll use exec() since Pippy already runs code. We’ll stick
>    with Pippy’s current way—running code in a separate process—because it’s
>    safe and matches the “Run!” button. We won’t use exec() yet to avoid
>    risks, but we’ll add ast to spot simple mistakes (like missing colons)
>    before running. This helps give kids better hints.
>    4. Helping Kids Learn
>    You pointed out the debugger should guide kids, not just fix things
>    for me. I agree! The language model will ask easy questions like “What does
>    this line do?” or “Did you mean to add something?” to help them think. For
>    example, if they forget a colon, it might say: “What’s this loop for? I see
>    a mistake—maybe it needs a colon?” We’ll keep it friendly and clear for
>    kids.
>    5. Common Mistakes
>    You asked if we’ll handle specific beginner errors. Yes, we’ll focus
>    on things like missing colons, wrong spacing, or using words not defined.
>    We’ll check these with ast or error messages and give simple tips,
>    like “Did you forget a colon?” or “Does everything line up?”
>    6. Words We Use
>    You said to keep terms simple but include real ones too. We’ll start
>    with easy words—like “mistake” instead of “error”—then add the real term
>    gently. For example: “There’s a mistake called a ‘SyntaxError’. What should
>    this do?” This teaches kids without confusing them.
>    7. Saving Answers
>    You asked if we’ll use sugar-datastore for storing answers. We’ll
>    first save common hints (like for missing colons) in memory while Pippy’s
>    open, so it’s fast. If it helps to keep them longer, like for school use,
>    we’ll save them in sugar-datastore between sessions. We’ll test if
>    kids need this.
>
> I'll be working hard to make this good for kids and Sugar. It’ll work
> offline, run fast, stay safe, and help kids learn by asking questions.
> Please let me know if I should change anything or focus on something
> specific next.
> Thanks again,
> Anurag
>
> On Fri, Apr 4, 2025 at 10:38 PM Chihurumnaya Ibiam <
> ibiamchihurumnaya at gmail.com> wrote:
>
>> I couldn't look at it properly at the time, that's why I sent that.
>>
>> I just noticed you used the Music Blocks logo, I'm wondering why.
>> If you want to use a Logo, at least use just the Sugar Labs logo as this
>> project isn't for Music Blocks.
>>
>> *"suitable for youth"*
>> We want the responses to be suitable for kids.
>>
>>
>> *Task: Install the Sugar desktop environment and fork the Pippy
>> repository from Sugar Labs’ GitHub.*
>> This is stating the obvious, which is why the project idea mentions it.
>>
>> You've also said the model you intend to use runs offline, does that mean
>> you intend to bundle it
>> with the activity?
>> You've mentioned integrating an API based approach if local performance
>> lags, how do you intend
>> to measure this lag?
>>
>> *Error Detection: Run the code through Python’s exec() in a sandboxed
>> environment, capturing errors via traceback. For static analysis, parse the
>> code with the ast module to identify potential issues (e.g., undefined
>> variables, infinite loops, or logic errors)*
>>
>> Pippy can execute code, do you intend to still use exec in a sandbox?
>>
>> *"Use the LLM to ask leading questions"*
>>
>> If I understand correctly, in the context this was used, this seems like
>> you're
>>
>> thinking about how you'd use the debugger, not how a child would use the
>> debugger,
>>
>> remember it's supposed to guide the child.
>>
>> *Handle common beginner errors:*
>>
>> The things you've listed in the above section seem like cases you intend
>> to particular
>>
>> implement in the debugger, is that the case?
>>
>> *Avoid technical terms (e.g., say “mix-up” instead of “exception”)*
>>
>> I agree about using simpler terms, but I don't think the necessary terms
>> should be avoided,
>>
>> I think they should be stated where they need to be stated, of course
>> something else can be
>>
>> used in its place, but they should be stated.
>>
>> *Cache frequent error responses (e.g., missing colons) in a local
>> dictionary to reduce LLM calls.*
>>
>> We usually use sugar-datastore to store data that's needed by an
>> activity, this data doesn't persist across activity
>>
>> instances except you want it to, is that what you're thinking about here?
>>
>>
>> Hope this helps!
>>
>> --
>>
>> Ibiam Chihurumnaya
>> ibiamchihurumnaya at gmail.com
>>
>>
>>
>>
>> On Thu, Apr 3, 2025 at 7:35 PM Anurag Mishra <anuragmishra0521 at gmail.com>
>> wrote:
>>
>>> Is that all the feedback you have for me? I’ve removed that section to
>>> keep the focus on my contributions rather than personal details.
>>>
>>> I appreciate your insights! Could you share any other areas where I can
>>> further improve?
>>> Regards
>>> Anurag Mishra
>>>
>>> On Thu, Apr 3, 2025, 9:09 PM Chihurumnaya Ibiam <
>>> ibiamchihurumnaya at gmail.com> wrote:
>>>
>>>> Programming Languages: JavaScript, TypeScript, C++, Python, C, Java Libraries/Frameworks:
>>>> React, Sass, BootStrap, TailwindCSS, Node.js, ExpressJs, Django,
>>>> NextJs, Rust
>>>>
>>>> Databases: MongoDB, PostgreSQL
>>>>
>>>> Tools/Platforms: Git, GitHub, Vercel, AWS, VS Code, Postman, Docker,
>>>> MATLAB
>>>>
>>>>
>>>> This section has little to do with the project, I don't see why it's
>>>> there tbh.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Ibiam Chihurumnaya
>>>> ibiamchihurumnaya at gmail.com
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Apr 2, 2025 at 7:31 PM Anurag Mishra <
>>>> anuragmishra0521 at gmail.com> wrote:
>>>>
>>>>> Dear Sugar Labs Community,
>>>>> Thank you for the opportunity to refine my Pippy Debugger proposal!
>>>>> Based on feedback about enhancing the UX and expanding the debugging scope,
>>>>> I’ve made some exciting updates. Here’s what’s changed:
>>>>> 1. Enhanced UX for the Debugger Panel
>>>>>
>>>>>    - Original: A basic side panel with LLM suggestions.
>>>>>    - Updated: The “Debug with Helper” button now opens a dynamic side
>>>>>    panel that:
>>>>>    - Highlights the error line (e.g., for i in range(3) missing a
>>>>>       colon).
>>>>>       - Shows a chat-style LLM tip (e.g., “Oops! Your for needs a :—can
>>>>>       you spot it?”).
>>>>>       - Offers interactive buttons: “Hint,” “Example,” and “Tell Me
>>>>>       More” for deeper guidance.
>>>>>       - Updates as the user revises code, styled in Sugar’s bright,
>>>>>       kid-friendly aesthetic.
>>>>>       - Why: This makes debugging engaging and intuitive, letting
>>>>>    kids explore at their pace. I’ve attached a mockup
>>>>>    (Pippy_Debugger_Mockup.png) to visualize it!
>>>>>
>>>>> 2. Broader Debugging Scope: Flow and Logic
>>>>>
>>>>>    - Original: Focused mainly on syntax errors.
>>>>>    - Updated: Now handles program flow and logic too:
>>>>>    - Uses ast to spot flow issues (e.g., infinite loops: “This while
>>>>>       never stops—how can we end it?”).
>>>>>       - Probes logic errors (e.g., “You wanted 10, but it prints
>>>>>       5—check range(5)!”).
>>>>>       - Combines code and output for context-aware tips.
>>>>>       - Why: Beginners struggle with more than syntax, so this
>>>>>    ensures well-rounded support.
>>>>>
>>>>> 3. Teaching Debugging Strategies
>>>>>
>>>>>    - Original: Gave hints but didn’t teach methods.
>>>>>    - Updated: The LLM now suggests techniques:
>>>>>    - “Try print(i) here to see what’s happening!”
>>>>>       - “Test just the loop—comment out the rest.”
>>>>>       - “What did you expect? Let’s check!”
>>>>>       - Progressive hints escalate from vague to specific.
>>>>>       - Why: This builds debugging skills, not just fixes, aligning
>>>>>    with Sugar’s educational goals.
>>>>>
>>>>> These updates make the debugger a true learning companion. I’d still
>>>>> love your thoughts on the panel’s usability, the flow/logic approach, and
>>>>> strategy guidance. Updated draft is attached/linked:
>>>>> https://docs.google.com/document/d/1kDaOTUjNIghWLVJUuLWUtLNLC9XB3hWYoDoOO_kWGV4/edit?tab=t.0#heading=h.7ajmtdnyhjmz.
>>>>> I’ll hop on #sugar IRC soon to chat more. Thanks again!
>>>>> Best,
>>>>> Anurag Mishra
>>>>> _______________________________________________
>>>>> Sugar-devel mailing list
>>>>> Sugar-devel at lists.sugarlabs.org
>>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20250407/b000027e/attachment-0001.htm>