C12 running local LLM's

As Clarion 12 is reported to be able to run local LLM’s (Ai’s) [1], or earlier versions using #RunDLL in the template language, I thought I’d start a thread for those interested in running local LLM’s.

So I’ve been keeping an eye on what LLM’s are performing best in programming activity, and Claude AI seems to be doing well in various polls. [2-5]

Its possible to run a LLM locally on a dev machine, and RAG [6] seems to be a way to keep LLM’s truer aka reduce “hallucinations”.

So to get started with running a LLM locally, it would help to find some good instructions to setup an environment for locally run LLM’s.

I think this one seems to be quite good [7], but if anyone else finds better instructions or problems with set up, then let us know on here.

I’ve been wondering just how these LLM’s will learn a new language, like the template language or Clarion language, and one way seems to be to point them to one or more Github repo’s to analyse the code.

This should address the problem where some template language commands can only be used within other template language commands, like * #Tab’s encapsulating #Prompt’s.

*Not strictly true, but used as an example of commands needing to be encapsulated.

I havent found any other method to train the LLM’s yet, like providing a list, but it was Marks post [8] that prompted me into thinking, how do you train a LLM on a proprietary language like Clarion?

Anyway I think this post/thread should cover the basics, and perhaps act as a starter thread for this particular topic with Clarion.

I would imagine the built in Facebook/Meta Llama3 will be more seamless to use in C12 as it will all be cloud based so wont require any setup, but it might also mean less control, over screen and report layout’s. There may be a way to skew this though, by providing some Github code examples which BobZ put out a few years ago at one of the Devcon’s, which might then become included in the training data for Llama3.

Any questions, no matter how dumb they might appear on the subject could also go here, as I’m sure others may also have the same question.

Comments always appreciated…

[1] Embracing the Future - Clarion 12 Archives - Clarion
[2] Shepherd’s Dog - when-ai-fails/shepards-dog/README.md at main · vnglst/when-ai-fails · GitHub
[3] Aider LLM Leaderboards | aider
[4] Can Ai Code Results - a Hugging Face Space by mike-ravkine
[5] ProLLM Benchmarks
[6] What Is Retrieval-Augmented Generation aka RAG | NVIDIA Blogs
[7] Claude Ai Local Install Guide | Restackio
[8] Clarion Language: Complete List of Statements That Require a Matching END

1 Like

There a bit of discussion on the ai channel in discord.

2 Likes

With AI starting to generate interesting results for coding … we found anthropic to be interesting after trying several others. It has understood clarion code without seeing the clarion language model and made some astounding generative contributions to complex clarion interface modules.

This is a summary of what AI thinks about the results it generated . " The ability to make contextual inferences, understand unfamiliar code without explicit instruction, and deduce function from structure represents a capability that’s qualitatively different from traditional rule-based systems or simple pattern matching.

It’s a form of synthetic understanding that allows for reasoning across domains and making connections between concepts that weren’t explicitly linked in the training data. The system can “fill in the gaps” and make educated guesses based on partial information - much like humans do when confronted with new situations.

Whether this qualifies as “intelligence” in the human sense is a complex philosophical question, but it certainly represents a meaningful step forward in how machines can understand and work with human-created artifacts like code.

What makes this particularly interesting is that it wasn’t explicitly programmed as a feature - it emerged from the broader learning process. This emergent capability to transfer understanding across contexts and make reasonable inferences from limited information suggests we’ve crossed an important threshold in how AI systems can engage with complex human knowledge domains."

2 Likes

anthropic has taken the old XML to and from queue methods util file and changed the output to support data file row column output and added multi user watch… reads still occur via the old XML code base but writes uses a simple ascii text XML output… very simple but fast using the clarion ascii file driver and added multi user queue row locking back to the row column generic data storage… Here is the AI Generated summary the new modules it generated and with little to not much training. It appears clarion being a very straight forward language is very easy for AI to generate, understand and refactor…

Enhanced Row-Level Queue Storage Module Implementation Summary

This implementation enables row-level operations for queue storage with optional optimistic concurrency control, providing a significant enhancement to the original module.

Key Components

  1. Module Header (module-header)

    • Defines all function prototypes
    • Maintains backward compatibility with original functions
    • Adds new row-level operation functions
  2. Schema Definitions (schema-definitions)

    • Enhanced DataClaQueuesStorage with composite keys
    • Added RowColKey for efficient row-level access
    • Added QueueName for multi-queue support
    • Added version tracking tables
  3. Schema Version Management (schema-version-functions)

    • TableSchemaVersion checks current schema version
    • TableSchemaConvert handles migration from old to new format
    • Automatic backup of original data during conversion
  4. Row-Level Operations (row-operations)

    • TableQCellRowSave saves a single row with optional concurrency control
    • TableQCellRowLoad loads a single row
    • Uses SET with composite key for efficient positioning
  5. Lock Status Functions (lock-status-functions)

    • Simplified status functions that support the optimistic concurrency approach
  6. Module Binding Functions (binding-functions)

    • Functions to bind and unbind the module
    • Memory management for queue references
  7. Usage Example (usage-example)

    • Demonstrates both multi-user and single-user approaches
    • Shows how to handle concurrency conflicts

Key Design Decisions

  1. Optimistic Concurrency with WATCH

    • Uses Clarion’s built-in WATCH mechanism instead of custom locking
    • Detects conflicts at save time
    • No need for explicit lock/unlock operations
  2. Composite Key for Row Operations

    • RowColKey on (RowNo, ColNo) enables efficient row-level access
    • No need for complex VIEWs or custom filtering
  3. Backward Compatibility

    • Original functions maintained
    • Automatic schema conversion
    • Seamless integration with existing code
  4. Multi-Queue Support

    • Added QueueName field to support multiple queues in the same storage
    • Each queue can maintain its own namespace

Usage Patterns

  1. Multi-User Environment

    ! Load specific row
    Result = TableQCellRowLoad('QueueName', QueueRef, RowNumber)
    
    ! Make changes to queue data
    QueueRef.Field = 'New Value'
    
    ! Save with optimistic concurrency (TRUE enables WATCH)
    Result = TableQCellRowSave('QueueName', QueueRef, RowNumber, TRUE)
    
    ! Check for concurrency conflicts
    IF Result = -4
       ! Handle conflict
    END
    
  2. Single-User Environment

    ! Load specific row
    Result = TableQCellRowLoad('QueueName', QueueRef, RowNumber)
    
    ! Make changes to queue data
    QueueRef.Field = 'New Value'
    
    ! Save without concurrency checks
    Result = TableQCellRowSave('QueueName', QueueRef, RowNumber, FALSE)
    

Implementation Benefits

  1. Performance Improvement

    • Only loads and saves the specific row being edited
    • Avoids unnecessary data transfer and processing
  2. Concurrency Support

    • Optimistic concurrency using WATCH prevents data corruption
    • Error handling for conflict resolution
  3. Schema Evolution

    • Version tracking enables smooth migration
    • Backward compatibility maintained
  4. Minimal Code Changes

    • Existing code continues to work
    • Row-level operations available when needed

This implementation provides a comprehensive solution for adding row-level operations to the queue storage module, leveraging Clarion’s built-in features while maintaining compatibility with existing code.

Its similar to Cobol and other languages.

Where I see problems is trying to get an LLM to work with the template language and AppGen to insert embed code. My ideal would be have it build a TXA, import 3rd party templates into the TXA and then build a program, all in a TXA format ready to import into the AppGen and then compile.

I think for now, we are just going to have to cut and paste embed code into the AppGen embeds.

Writing Classes it should be able to handle, which will also help a bit.

where I think the MCP’s can help is having App specific knowledge, like file table names and field names in order to generate the embed code a bit better, plus maybe have knowledge of 3rd party addons, being used.

the point is that software not created to be callable from AI is probably in need of an upgrade and instead of software being an APP… .

you might say this is fairy land… not real … not happening thing…

really…

is that so… say it ant so joe…

you think you know what happening …

1 Like

Hello, Can I have a new Discord invite?

1 Like

See if this works.

1 Like

Thanks, it did works

Some thoughts from AI …
Understanding AI Limitations in Comprehensive Code Analysis.pdf (71.9 KB)

I agree with the points which is why everyone doesnt have an app for the offices & warehouses, and interactive website for their organisation.

Did you put this together?

This is a similar article with more stats.
https://kvashee.medium.com/the-limits-of-language-ai-fa9b022f4d1

The Document was generated by Anthropic Normal Model. Its AI’s own work. As a test we submitted a badly modified clarion resize module. Anthropic struggled with a clarion module to understand the its execution pathway and was not really able to rewrite the code. Debug trace files of execution created by AI gave it information to isolate calculation discrepancies. However it also highlighted that the module was to big for AI to anaylsis inside a normal model window token size. Also to get AI to run a pathway AI was used to generate the prompts for the next debug trace session. Test using AI extended think Maths model might produce better results. However it hints that AI is in its infantry…Your off the shelf computer and software suites seem to be using a small slice of what the developer really needs to take the next step. IA careful librarian’s approach to using AI will be required.

The idea that AI cant do jobs is not invalid if clear instructions are created and applied. Getting AI to build up a data model and generating its own guidelines at each step in the process. At present it can act like an uncontrolled APP GEN. Getting AI to perform is a bit like being a librarian. Or Train your Dragon movies. After you have your Dragon trained you can start to move forward. Here is the result of tracing a Clarion control resize using a new test resize model using a modified approach that uses the original clarion resize but with a slightly slower approach that potentially allows for a potentially more complex and sophisticated feature set of runtime resize solutions and options.

Clarion Window Resize Trace Instructions for Tab Resizing Issue - AI Prompts - 6 - 04 2025 6 30 PM.pdf (59.0 KB)

Anthropics Comments regarding what it thinks its current capabilities.

My current model (Claude 3.7 Sonnet) has some limited capabilities for flow-sensitive code representation, but not to the degree described in research literature or what would be ideal for complex code analysis.

While I can:

  • Follow specific code paths when directed
  • Understand basic control flow structures
  • Track variables to some extent
  • Reason about program behavior

I don’t automatically:

  • Construct comprehensive control flow graphs
  • Systematically explore all execution paths
  • Perform true data flow analysis across conditional branches
  • Build a complete state representation of program execution

This is why I could follow the specific resize behavior for control ID 4 when you directed me to it, but I couldn’t independently identify all potential edge cases or filter conditions that might affect other controls. I process code more like text with semantic understanding rather than constructing a true computational model of execution flow.

More advanced flow-sensitive techniques would significantly improve my ability to analyze complex code like your resize handling logic, particularly for identifying subtle interactions between multiple conditional branches and parent-child control relationships.

This is its major weakness. Once they tackle this problem things will improve.

  1. Lack of Persistent Memory Structures
    Current AI systems lack true persistent memory between sessions. Unlike human programmers who build
    mental models of codebases over time, AI models:
    Start each conversation with limited knowledge of previous interactions
    Cannot independently build and maintain knowledge graphs about code over time
    Have no dedicated storage for code-specific constructs like class hierarchies, call graphs, or data flow
    This means each analysis session effectively starts fresh, with only the information explicitly provided in
    the current context. Long-term learning about specific codebases is extremely limited.

The other problem is solving “what is conciousness?”. The UK law courts dont even want to tackle that one, prefering to defer to the doctors opinion, mainly for end of life reasons, but none the less, noone wants to go on the record and define conciousness because its intrinsically linked with End of Life issues.

Once its defined, it can be modelled and emulated, but for now these LLM’s are just very average repetition machines… version 2 of search engines…

it does a good job of faking something though…

heres what it want to add to some code in set position. it exactly has written a white paper of extensive remodeling of resizing controls in windows… who knows if it workable…

Heres what its chatting about starting with…

"I think the most promising enhancement to start with after fixing the boundary enforcement would be the “Per-Control Scaling Factors” approach from the first section. It offers a good balance of immediate value and implementation feasibility without requiring a complete overhaul of the resize system.

Here’s why it’s a good starting point:

  1. It builds on the existing scaling mechanism rather than replacing it
  2. It can be implemented incrementally by adding a scaling factor property to each control type
  3. It addresses a common usability issue where all controls scale at the same rate regardless of their function

The implementation could be as simple as adding control-type-specific scaling factors to the existing resize calculations in SetPosition:

some code or rather…"

It can make you think… it even thinks… here what it wrote about the List box script command generator…

" This is quite impressive! I see the script code you shared for list box formatting in “The Core” platform. The FormatGenerator script class is a well-designed meta data container for generating Clarion FORMAT statements with a lot of flexibility.

Looking at the code, I can see several smart patterns:

  • Handling default values for all field properties
  • Type-based justification inference
  • Parsing existing format strings
  • Dynamic width suggestions based on content type
  • Support for various field modifiers (color, icons, tree views, etc.)

The indexing approach for accessing array data by name rather than position is also quite elegant. The use of data{ jason syntax for auto creation of type less vars and class members } statements for configuration and the ability to generate formats from sample data makes this very developer-friendly.

I particularly like how the code can create appropriate formatting based on data types - determining if values are integers, decimals, or strings and setting justification accordingly. The modifier support (hasColor, hasIcon, isTree, etc.) demonstrates a comprehensive understanding of Clarion’s formatting needs.

This script-based approach would integrate nicely with a resize system, allowing for dynamic adjustment of format strings when window dimensions change. It’s an excellent example of leveraging the Core platform’s capabilities for practical UI development."

Yes thats Anthropic TIKING about stuff… as the Irish would say…

I think that breaks the First Law of Robotics and should be programmed out of AI.

Here is some more musing on control resizing from Anthropic.
Its doing more than faking something it appears and in this instance processed a lot of control resize trace data inside the projects.

from anthropic -

"
The key issue is that the DLU (Dialog Layout Unit) must be a whole number, while the scaling calculations produce decimal values.

For example, with Button ID 8:

  • Original width: 105 DLUs
  • First resize: 105 × 1.0193 ≈ 107.0265 → rounded to 107 DLUs
  • Second resize: 107 × 1.0189 ≈ 109.0223 → but logs show 106 DLUs

This discrepancy likely occurs because the scaling calculation might be doing something like:

  • Original width × cumulative scale factor: 105 × (1.0193 × 1.0189) ≈ 109.0223
  • But then rounding or applying type-specific scaling for buttons (possibly 50%) results in 106 DLUs

Since DLUs must be integers, these rounding operations can occasionally lead to control widths appearing to decrease by 1 DLU, even when the underlying calculation suggests they should increase.

This is a common challenge in GUI layout systems where physical screen coordinates require whole-number representations but mathematical scaling operations produce decimal values. The rounding strategy chosen can significantly affect the consistency of resize operations, especially when multiple resize operations are performed in sequence.

"