reprompt 0.1.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: 13fa55af8b7e2e77547d77b1df26c68d47b1814c6de4908289391cc0949c3449
+  data.tar.gz: '07548880dfcf028f0d915aa93650b8702b9461003782d338e7d0c83b87b006c6'
+SHA512:
+  metadata.gz: c2708cbec2de58e96fd3bbd3bc574750102d3ab48887972c8232c863fb1cfc58a1bc954c3bd946da6fe7a0933a3c485ca688f911567b211bd52cb428a48cc5f2
+  data.tar.gz: 436bce970274e743914da901726dff36d0df5d7a0035c3ab5168f457efd418f43973c46a28dff729e732969757b464af297594adb4e71323134defc396d6b17e

data/.rspec

@@ -0,0 +1,3 @@
+--format documentation
+--color
+--require spec_helper

data/.rubocop.yml

@@ -0,0 +1,13 @@
+AllCops:
+  TargetRubyVersion: 2.6
+
+Style/StringLiterals:
+  Enabled: true
+  EnforcedStyle: double_quotes
+
+Style/StringLiteralsInInterpolation:
+  Enabled: true
+  EnforcedStyle: double_quotes
+
+Layout/LineLength:
+  Max: 120

data/LICENSE.txt

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2024 Jim Jones
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

data/README.md

@@ -0,0 +1,217 @@
+# Reprompt
+
+Provides a pattern for iteratively prompting an LLM and asking follow up questions based on the response.
+
+## Installation
+
+Install the gem and add to the application's Gemfile by executing:
+
+    $ bundle add reprompt
+
+If bundler is not being used to manage dependencies, install the gem by executing:
+
+    $ gem install reprompt
+                          
+The only client adapter at the current moment is for Ollama.  So you'll have to run a model locally.
+
+Mistral is really good.
+
+```
+brew install ollama
+brew services start ollama
+ollama pull mistral
+```
+
+## Pattern
+
+Take a look in `reprompt/templates`.  Return a `true/false` for the `stop_condition` callback.
+Return a string (question, response, etc) for the `follow_up_on` callback.
+
+Here's the basic pattern.
+
+```ruby
+require_relative 'base'
+
+class TechnicalOutline < Base
+  def prompt(question)
+    @conversation = Conversation.new(client, max_responses) do
+      stop_condition do |depth, response|
+        response.include?("we are done") || depth >= max_responses
+      end
+
+      follow_up_on do |response|
+        # We'll have the Mistral LLM create our next follow up question
+        prompt "What is a good follow up question for #{response}?  Or are we done?"
+      end
+    end
+
+    conversation.start(question)
+  end
+end
+```
+       
+## Usage
+
+```ruby
+template = TechnicalOutline.new
+template.prompt("Outline the difference between a Ruby include vs prepend")
+```
+
+### The Resulting Article
+
+### Q: Outline the difference between a Ruby include vs prepend
+#### A:  In Ruby, `include` and `prepend` are two methods used to add functionality to a class or module. However, they serve different purposes:
+
+1. **Include:** The `include` method adds the methods (and constants, if any) of one module into another module or class. When you include a module into a class, all the methods defined in that module become available in the class. The instance methods are mixed-in and will be accessible on instances of the class. The class itself does not inherit from the included module.
+
+2. **Prepend:** The `prepend` method also adds the functionality of one module into another module or class, but it does so in a different way. When you prepend a module to a class, the methods defined in that module are added at the beginning (before all other instances and class methods) of the class's method chain. This can be useful when you want to modify or extend existing methods without overriding them completely.
+
+Here is an example to illustrate the difference between `include` and `prepend`. Let's assume we have two modules: `MyModule1` and `MyModule2`. Both modules define a method called `my_method`.
+
+```ruby
+module MyModule1
+  def my_method
+    puts "MyModule1: my_method"
+  end
+end
+
+module MyModule2
+  def my_method
+    puts "MyModule2: my_method"
+  end
+end
+```
+
+Now, let's see how we can use these modules with the `include` and `prepend` methods:
+
+**Using include:**
+
+```ruby
+class MyClass
+  include MyModule1
+  include MyModule2
+end
+
+MyClass.new.my_method # Output: "MyModule1: my_method" (because MyModule1 is included last)
+```
+
+In this example, `MyModule1` and `MyModule2` are included in the order they appear, so when you call `my_method` on an instance of `MyClass`, it will output "MyModule1: my_method". If we want to change the order, we would have to change the order in which the modules are included.
+
+**Using prepend:**
+
+```ruby
+class MyClass
+  prepend MyModule2
+  include MyModule1
+end
+
+MyClass.new.my_method # Output: "MyModule2: my_method" (because MyModule2 is prepended)
+```
+
+In this example, `MyModule2` is prepended to the class before including `MyModule1`. When you call `my_method` on an instance of `MyClass`, it will output "MyModule2: my_method" because `MyModule2` is added at the beginning of the method chain.
+### Q:  A possible follow-up question could be:
+
+Can you explain some use cases where it would be more appropriate to use `include` instead of `prepend`, and vice versa, when extending or modifying the functionality of a class or module in Ruby? Also, are there any limitations or drawbacks to using one method over the other, depending on the specific scenario?
+#### A:  Sure! The choice between `include` and `prepend` depends on your specific use case and the desired outcome. Here are some common scenarios where each method might be more appropriate:
+
+**Use Cases for Include:**
+
+1. When you want to add new methods or functionalities to an existing class or module, without modifying any of the existing methods. This is because `include` adds the methods at the end of the class's method chain.
+2. When you have multiple modules that define similar but not identical functionality and you want to mix them into a single class or module. The order in which you include these modules may impact the behavior of your class/module, so consider the dependencies carefully.
+3. When the added methods are optional or can be easily overridden by other methods in the class/module.
+4. When working with mixins or libraries that provide additional functionality to your classes or modules.
+
+**Use Cases for Prepend:**
+
+1. When you want to modify existing methods without overriding them completely. By prepending a module, you can add new behavior at the beginning of the method chain, which will be executed before the original implementation of the method. This is useful when you need to perform some additional setup or validation for a method.
+2. When dealing with third-party libraries that provide methods or functionalities that you want to modify or extend without modifying the library's source code directly. Prepending your custom module allows you to hook into existing methods and add new functionality while keeping the original behavior intact.
+3. When working on deeply nested inheritance hierarchies, where you need to modify the behavior of a method at a specific level in the hierarchy. By prepending the modifying module at that level, you can modify the behavior without affecting other levels in the hierarchy.
+
+Limitations and Drawbacks:
+
+1. **Naming Conflicts:** If two included modules or prepended modules define methods with the same name, there will be a naming conflict. In this case, you need to provide an alias or rename one of the conflicting methods.
+2. **Complexity:** Using both `include` and `prepend` in the same class/module can make the codebase more complex and harder to understand for other developers. Try to keep your use of these methods clear and concise.
+3. **Ordering Dependencies:** The order in which you include or prepend modules matters, as it impacts the method chain. Make sure to consider the dependencies carefully and provide a clear ordering if necessary.
+   ### Q:  What are some best practices for managing the order of dependencies when using `include` and `prepend` in Ruby?
+   #### A:  When managing dependencies in Ruby with `include` and `prepend`, here are some best practices to ensure clear and consistent code:
+
+1. **Declare dependencies explicitly:** Make sure to declare all dependencies (included modules or prepended modules) at the beginning of your class definition, preferably in the order they should be processed. This makes it easier for other developers to understand the flow of your code.
+
+2. **Use descriptive names:** Give meaningful and descriptive names to your modules to make it clear what functionality they provide. This helps when determining the correct order of dependencies.
+
+3. **Minimize the number of dependencies:** Try to keep the number of dependencies to a minimum, as more dependencies lead to increased complexity and potential for conflicts. If possible, refactor your code to reduce the number of dependencies.
+
+4. **Consider encapsulation:** Encapsulate related functionality within the same module or library to minimize dependency conflicts and simplify the ordering process.
+
+5. **Maintain a clear documentation:** Clearly document each module's purpose and intended use, along with any specific requirements or dependencies. This will help other developers understand the context of your code.
+
+6. **Test thoroughly:** Thoroughly test your code to ensure that the order of dependencies does not impact the functionality or behavior of your classes or modules. This can help you identify and resolve potential conflicts early in the development process.
+   ### Q:  A possible follow-up question could be: "What are some common pitfalls to avoid when managing dependencies with `include` and `prepend` in Ruby?" or "Can you provide examples of how these best practices for managing dependencies with `include` and `prepend` in Ruby can be implemented in practice?"
+   #### A:  When managing dependencies with `include` and `prepend` in Ruby, there are some common pitfalls to avoid:
+
+1. **Naming conflicts:** As mentioned earlier, if two included modules or prepended modules define methods with the same name, there will be a naming conflict. To avoid this, you can provide an alias or rename one of the conflicting methods. Make sure to check for potential naming conflicts before incorporating new dependencies into your codebase.
+2. **Complexity:** Using both `include` and `prepend` in the same class/module can make the codebase more complex and harder to understand for other developers. Try to keep your use of these methods clear and concise, and avoid adding unnecessary dependencies.
+3. **Inconsistent ordering:** The order in which you include or prepend modules matters. If dependencies are not declared consistently across your codebase, it can lead to unexpected behavior or bugs. Be sure to declare all dependencies at the beginning of your class definition, preferably in the correct order.
+4. **Circular dependencies:** Circular dependencies occur when modules A and B each depend on the other. This can create a deadlock situation where neither module can be loaded properly. Avoid circular dependencies by ensuring that each module depends only on its direct dependencies and not on indirect dependencies.
+5. **Lack of documentation:** Failing to document your dependencies clearly can lead to confusion and misinterpretation of your code. Be sure to provide clear and concise documentation for each module, including its purpose, intended use, and any specific requirements or dependencies.
+
+Here's an example of how you might implement some of these best practices in practice:
+
+```ruby
+# Define a simple logging module with two methods: info and error
+module Logging
+  def log_info(message)
+    puts "[INFO] #{message}"
+  end
+
+  def log_error(message)
+    puts "[ERROR] #{message}"
+  end
+end
+
+# Define a validation module with two methods: validate_presence and validate_format
+module Validation
+  def validate_presence(attribute, value)
+    raise "Attribute '#{attribute}' is missing" if value.nil?
+  end
+
+  def validate_format(attribute, format)
+    raise "Invalid format for attribute '#{attribute}' (expected: #{format})" unless value =~ /#{format}/
+  end
+end
+
+# Define a User class that includes Logging and Validation modules
+class User
+  include Logging
+  include Validation
+
+  attr_accessor :name, :email
+
+  def initialize(name, email)
+    @name = name
+    @email = email
+  end
+
+  # Method to create a new user with validation and logging
+  def create
+    validate_presence(:name, @name)
+    validate_format(:email, /\A[\w+\-.]+@[a-z\d\-]+(\.[a-z\d\-]+)*\.([a-z\d]([a-z\d\-.]*){2,})\z/)
+
+    log_info("Created new user: #{@name}")
+  end
+end
+```
+
+In this example, we define two simple modules (Logging and Validation) with their respective methods. We then include these modules in a User class, which includes both logging and validation functionality. By documenting each module clearly and encapsulating related functionality within the same module, we can minimize complexity and potential for conflicts. Additionally, by declaring dependencies explicitly at the beginning of our class definition, we make it easier for other developers to understand the flow of our code.
+### Q: A possible follow-up question could be: "Can you explain how the order of inclusion matters when dealing with dependencies in Ruby using `include` and `prepend`, and provide an example of unexpected behavior that might occur due to inconsistent ordering?"
+#### A: Absolutely! When managing dependencies in Ruby with `include` and `prepend`, the order in which you include or prepend modules is crucial. This is because the order determines the method chain for each class or module, and can impact the behavior of your code.\
+\
+Let's consider an example where we have two modules, `ModuleA` and `ModuleB`, with each defining a method named `method_x`. If we include or prepend these modules in different orders, it can lead to unexpected behavior:\
+```ruby\n\n# Define ModuleA with method x\nmodule ModuleA\n  def method_x\n    puts "Method X from Module A"\n  end\nend\n\n# Define ModuleB with method x\nmodule ModuleB\n  def method_x\n    puts "Method X from Module B"\n  end\nend\n\nclass MyClass\n  # Inconsistent ordering: include ModuleA, then include ModuleB\n  include ModuleA\n  include ModuleB\n\n  # Expected output: "Method X from Module A" when calling method_x\nend\n\n# Output: "Method X from Module B" instead of "Method X from Module A", due to inconsistent ordering\nMyClass.new.method_x\n```
+In the example above, we define two modules, `ModuleA` and `ModuleB`, each with a method named `method_x`. We then create a class called `MyClass`, which includes both `ModuleA` and `ModuleB` in an inconsistent order. This results in the `method_x` from `ModuleB` being called instead of `ModuleA` when we call `my_class.new.method_x`.
+\
+The inconsistent ordering can cause unexpected behavior because each module extends the previous one, creating a chain of inheritance that determines which method is actually called when you invoke a method with that name. In our example, because we included `ModuleB` after `ModuleA`, Ruby uses the definition of `method_x` from `ModuleB` instead of `ModuleA`.
+\
+To avoid unexpected behavior due to inconsistent ordering, make sure to declare all dependencies at the beginning of your class definition, preferably in the correct order. In our example above, we should have included `ModuleA` before `ModuleB`:
+```ruby\nclass MyClass\n  include ModuleA\n  include ModuleB\n  # Expected output: "Method X from Module A" when calling method_x\nend\n```
+This way, we ensure that the definition of `method_x` from `ModuleA` is used instead of `ModuleB`, as intended.

data/Rakefile

@@ -0,0 +1,12 @@
+# frozen_string_literal: true
+
+require "bundler/gem_tasks"
+require "rspec/core/rake_task"
+
+RSpec::Core::RakeTask.new(:spec)
+
+require "rubocop/rake_task"
+
+RuboCop::RakeTask.new
+
+task default: %i[spec rubocop]

data/lib/reprompt/clients/base.rb

@@ -0,0 +1,10 @@
+class Base
+  attr_accessor :uri
+  
+  def initialize
+  end
+
+  def prompt(question)
+    raise NotImplementedError
+  end
+end

data/lib/reprompt/clients/ollama.rb

@@ -0,0 +1,22 @@
+require 'net/http'
+require 'uri'
+require 'json'
+require_relative 'base'
+
+class Ollama < Base
+  def initialize
+    @uri = URI('http://localhost:11434/api/chat')
+  end
+
+  def prompt(question)
+    response = Net::HTTP.start(@uri.hostname, @uri.port, use_ssl: @uri.scheme == 'https') do |http|
+      http.post(@uri, JSON.dump({
+                                  messages: [{ role: 'user', content: question }],
+                                  model: 'mistral',
+                                  stream: false
+                                }), 'Content-Type' => 'application/json')
+    end
+
+    (JSON.parse(response.body) || {}).dig('message', 'content')
+  end
+end

data/lib/reprompt/conversation.rb

@@ -0,0 +1,67 @@
+class Conversation
+  attr_accessor :max_responses, :conversation_context, :client
+
+  def initialize(client, max_responses = 5, &configuration)
+    @client = client
+    @max_responses = max_responses
+    @stop_condition_block = nil
+    @follow_up_block = nil
+    @conversation_context = []
+    instance_eval(&configuration) if block_given?
+  end
+
+  def stop_condition(&block)
+    @stop_condition_block = block
+  end
+
+  def follow_up_on(&block)
+    @follow_up_block = block
+  end
+
+  def start(initial_question)
+    depth = 0
+    conversation_context.clear
+    current_question = initial_question
+    previous_response = ""
+
+    while continue_conversation?(depth, previous_response)
+      response = @client.prompt(current_question_with_previous_context(current_question, conversation_context))
+      puts "###Q: #{current_question}"
+      puts "####A: #{response}"
+      conversation_context << { role: 'system', content: response }
+
+      previous_response = response
+      depth += 1
+
+      break unless @follow_up_block
+
+      current_question = instance_exec(response, &@follow_up_block)
+    end
+
+    current_conversation
+  end
+
+  private
+
+  def current_question_with_previous_context(current_question, conversation_context)
+    "#{current_conversation}#{current_question}"
+  end
+
+  def current_conversation
+    conversation_context.join("\n")
+  end
+
+  def previous_context
+    conversation_context.join("\n")
+  end
+
+  def continue_conversation?(depth, previous_response)
+    return !@stop_condition_block.call(depth, previous_response) if @stop_condition_block
+
+    depth < @max_responses
+  end
+
+  def prompt(question)
+    client.prompt(question)
+  end
+end

data/lib/reprompt/templates/base.rb

@@ -0,0 +1,14 @@
+require_relative '../clients/ollama'
+
+class Base
+  attr_accessor :client, :conversation, :max_responses
+
+  def initialize(max_responses = 5)
+    @client = Ollama.new
+    @max_responses = max_responses
+  end
+
+  def prompt(question)
+    raise NotImplementedError, "Each template should implement it's own conversation."
+  end
+end

data/lib/reprompt/templates/five_whys.rb

@@ -0,0 +1,20 @@
+require_relative 'base'
+
+class FiveWhys < Base
+  def prompt(question)
+    @conversation = Conversation.new(client, max_responses) do
+      stop_condition do |depth, response|
+        response.include?("i do not know") || depth >= @max_responses
+      end
+
+      follow_up_on do |_response|
+        ['Why is that?',
+         'What do you mean by that?',
+         'Are there other approaches?',
+         'Can you clarify?'].shuffle.first
+      end
+    end
+
+    conversation.start(question)
+  end
+end

data/lib/reprompt/templates/technical_outline.rb

@@ -0,0 +1,17 @@
+require_relative 'base'
+
+class TechnicalOutline < Base
+  def prompt(question)
+    @conversation = Conversation.new(client, max_responses) do
+      stop_condition do |depth, response|
+        response.include?("we are done") || depth >= max_responses
+      end
+
+      follow_up_on do |response|
+        prompt "What is a good follow up question for #{response}? No compliments, no commentary, just a short follow up question. Or are we done?"
+      end
+    end
+
+    conversation.start(question)
+  end
+end

data/lib/reprompt/version.rb

@@ -0,0 +1,5 @@
+# frozen_string_literal: true
+
+module Reprompt
+  VERSION = "0.1.0"
+end

data/lib/reprompt.rb

@@ -0,0 +1,16 @@
+# frozen_string_literal: true
+
+require_relative "reprompt/version"
+require_relative 'reprompt/conversation'
+
+require_relative 'reprompt/clients/base'
+require_relative 'reprompt/clients/ollama'
+
+require_relative 'reprompt/templates/base'
+require_relative 'reprompt/templates/five_whys'
+require_relative 'reprompt/templates/technical_outline'
+
+module Reprompt
+  class Error < StandardError; end
+  # Your code goes here...
+end

data/reprompt.gemspec

@@ -0,0 +1,36 @@
+# frozen_string_literal: true
+
+require_relative "lib/reprompt/version"
+
+Gem::Specification.new do |spec|
+  spec.name = "reprompt"
+  spec.version = Reprompt::VERSION
+  spec.authors = ["Jim Jones"]
+  spec.email = ["jim.jones1@gmail.com"]
+
+  spec.summary = "Create Ruby classes that iteratively solve problems or create content."
+  spec.homepage = "https://www.github.com/aantix/reprompter"
+  spec.license = "MIT"
+  spec.required_ruby_version = ">= 2.6.0"
+
+  spec.metadata["homepage_uri"] = spec.homepage
+  spec.metadata["source_code_uri"] = "https://www.github.com/aantix/reprompter"
+
+  # Specify which files should be added to the gem when it is released.
+  # The `git ls-files -z` loads the files in the RubyGem that have been added into git.
+  spec.files = Dir.chdir(__dir__) do
+    `git ls-files -z`.split("\x0").reject do |f|
+      (File.expand_path(f) == __FILE__) ||
+        f.start_with?(*%w[bin/ test/ spec/ features/ .git .circleci appveyor Gemfile])
+    end
+  end
+  spec.bindir = "exe"
+  spec.executables = spec.files.grep(%r{\Aexe/}) { |f| File.basename(f) }
+  spec.require_paths = ["lib"]
+
+  # Uncomment to register a new dependency of your gem
+  # spec.add_dependency "example-gem", "~> 1.0"
+
+  # For more information and examples about making a new gem, check out our
+  # guide at: https://bundler.io/guides/creating_gem.html
+end

data/sig/reprompt.rbs

@@ -0,0 +1,4 @@
+module Reprompt
+  VERSION: String
+  # See the writing guide of rbs: https://github.com/ruby/rbs#guides
+end

metadata

@@ -0,0 +1,60 @@
+--- !ruby/object:Gem::Specification
+name: reprompt
+version: !ruby/object:Gem::Version
+  version: 0.1.0
+platform: ruby
+authors:
+- Jim Jones
+autorequire: 
+bindir: exe
+cert_chain: []
+date: 2024-03-29 00:00:00.000000000 Z
+dependencies: []
+description: 
+email:
+- jim.jones1@gmail.com
+executables: []
+extensions: []
+extra_rdoc_files: []
+files:
+- ".rspec"
+- ".rubocop.yml"
+- LICENSE.txt
+- README.md
+- Rakefile
+- lib/reprompt.rb
+- lib/reprompt/clients/base.rb
+- lib/reprompt/clients/ollama.rb
+- lib/reprompt/conversation.rb
+- lib/reprompt/templates/base.rb
+- lib/reprompt/templates/five_whys.rb
+- lib/reprompt/templates/technical_outline.rb
+- lib/reprompt/version.rb
+- reprompt.gemspec
+- sig/reprompt.rbs
+homepage: https://www.github.com/aantix/reprompter
+licenses:
+- MIT
+metadata:
+  homepage_uri: https://www.github.com/aantix/reprompter
+  source_code_uri: https://www.github.com/aantix/reprompter
+post_install_message: 
+rdoc_options: []
+require_paths:
+- lib
+required_ruby_version: !ruby/object:Gem::Requirement
+  requirements:
+  - - ">="
+    - !ruby/object:Gem::Version
+      version: 2.6.0
+required_rubygems_version: !ruby/object:Gem::Requirement
+  requirements:
+  - - ">="
+    - !ruby/object:Gem::Version
+      version: '0'
+requirements: []
+rubygems_version: 3.2.3
+signing_key: 
+specification_version: 4
+summary: Create Ruby classes that iteratively solve problems or create content.
+test_files: []