Post here some questions to your local LLM.

[Alain De Vos]

Eg , i currently do,

"
Act as a Senior Software Architect. Refactor the input F# file using these constraints:
1. ABSOLUTE CONSTRAINT: Do not modify mutable key-value types. And do not modify the operators on them. Keep them exactly as implemented.
2. Fix all structural anti-patterns, logical flaws, and unhandled edge cases.
3. Refactor for idiomatic F# and Async
4. Extract complex or nested logic blocks into distinct sub-functions.
5. Refactor for human readability, clean architecture, and low cognitive complexity.
6. Provide NO explanation, NO introduction, and NO markdown code block formatting.
7. Disable reasoning tokens. Return ONLY the raw text of the fixed F# file directly in the response body."

 

[MG]

But what's in the launcher script?

 

[DanielBowman]

This load of horse manure of report was emailed to me. Please [clankers might waste me for wasting tokens but then again they might make exemption for a nice guy] generate email answer where I tactfully inform them I needed to know this and this and this. Basically write it, so they can just copy it and email it back to me. Be precise and brief. [obligatory] Make no mistakes.

Coding might not be 100% solved. But corporate BS is light years beyond any human or some puny Turing test. Certainly in speed and also in style.
It saves me so much time, nerves and fingertips.

The other day I asked dummy Mistral to explain to me how electrical substations work - low level, protocols, protections comms and big picture. It generated me PDF which is basically summarized 100 textbooks in to few pages.
And I can directly question it and have follow up questions where I need.
Perfect.

For coding, I have better results the less guardrails I put in. I suspect a lot of them is already baked in anyway.
I have NASA coding rules in one .MD.
And since I am noob I ask it to be verbose.
Also I demand modular code...the UNIX way and every parameter changeable from arguments or config file.

But there will come time, when I just ask for ASM with zoom-able diagram to map specs on parts of code.

 

[Alain De Vos]

But what's in the launcher script?

Chocolate .
https://gitlab.com/alaindevos/scalatut/-/blob/master/llama/launch_sharp/Program.fs?ref_type=heads

Note, the model i use eats ctx-size tokens like crazy, as it spits out all its thinking , currently already 262k.

 

[Alain De Vos]

Coding might not be 100% solved. But corporate BS is light years beyond any human or some puny Turing test. Certainly in speed and also in style.
It saves me so much time, nerves and fingertips.

The other day I asked dummy Mistral to explain to me how electrical substations work - low level, protocols, protections comms and big picture. It generated me PDF which is basically summarized 100 textbooks in to few pages.
And I can directly question it and have follow up questions where I need.
Perfect.

For coding, I have better results the less guardrails I put in. I suspect a lot of them is already baked in anyway.
I have NASA coding rules in one .MD.
And since I am noob I ask it to be verbose.
Also I demand modular code...the UNIX way and every parameter changeable from arguments or config file.

But there will come time, when I just ask for ASM with zoom-able diagram to map specs on parts of code.

If you have interesting .MD's feel free to share them. Or its place in git(lab/hub) ?

 

[DanielBowman]

If you have interesting .MD's feel free to share them. Or its place in git(lab/hub) ?

Nothing fancy. I keep changing them or rather reducing them as models improve. If I need one, I let smarter model generate it. The less is better, especially with local models and small context.

# NASA Rules for Developing Safety-Critical Code

1. Restrict all code to very simple control flow constructs—do not use goto statements, setjmp or longjmp constructs, or direct or indirect recursion.
2. Give all loops a fixed upper bound. It must be trivially possible for a checking tool to prove statically that the loop cannot exceed a preset upper bound on the number of iterations. If a tool cannot prove the loop bound statically, the rule is considered violated.
3. Do not use dynamic memory allocation after initialization.
4. No function should be longer than what can be printed on a single sheet of paper in a standard format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function.
5. The code's assertions density should average to minimally two assertions per function. Assertions must be used to check for anomalous conditions that should never happen in real-life executions. Assertions must be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken such as returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule.
6. Declare all data objects at the smallest possible level of scope.
7. Each calling function must check the return value of nonvoid functions, and each called function must check the validity of all parameters provided by the caller.
8. The use of the preprocessor must be limited to the inclusion of header files and simple macros definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives must be kept to a minimum.
9. The use of pointers must be restricted. Specifically, no more than one level of dereference should be used. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.
10. All code must be compiled, from the first day of development, with all compiler warnings enabled at the most pedantic setting available. All code must compile without warnings. All code must also be checked daily with at least one, but preferably more than one, strong static source code analyzer and should pass all analyses with zero warnings
    
    

 

[Alain De Vos]

I like line 10. Will add it to my LLM which list.

 

[DanielBowman]

I like line 10. Will add it to my LLM which list.

That was taught to us at school, like lesson one. When professor reviewed our programs he made sure every time, that all compiler checks are ON.
I like number 4. But it might restrict clankers too much. No human eye will review that anyway.

 

[Alain De Vos]

With your input my latest version,

'Below_is_a_X_file'

<source_code>

# include <stdio.h>

</source_code>

'Act as a Senior Software Architect. Refactor the input X file using these constraints:
0. The version of the language used is X
0. The version of the build tool used is X
0. ABSOLUTE CONSTRAINT: Do not modify the TYPE of mutable key-value TYPES. 
   And do not modify the signature of the operators on them.
   E.g. do not introduce tuples as alternatives for key-value types.
0. All code must compile without errors and without warnings
0. All code must pass strong static source code analyzer and should pass all analyses with zero warnings
0. Fix all structural anti-patterns, logical flaws, and unhandled edge cases.
0. Refactor for idiomatic X and X
0. Cleanup the code 
0. Extract complex or nested logic blocks into distinct sub-functions.
0. No function should be longer than what can be printed on a single sheet of paper, typically this means no more than about 60 lines of code per function.
0. Refactor for human readability, clean architecture, and low cognitive complexity.
0. Provide NO explanation, NO introduction, and NO markdown code block formatting.
0. Disable reasoning tokens. Return ONLY the raw text of the fixed X file directly in the response body.'

 

[blackbird9]

What does number 8 "cleanup the code" make it do? it's a pretty general instruction. Does it give you different output every time?