AI Editor Memory

I’ve been using the AI for the last couple of years, both in my personal life and in my professional life. And, like others, I’ve been using some of the common editors. Among them, one of my favorites is Cursor AI Editor. The reason is very simple. It has a agent driven capability where anyone can develop their application (you need to take the paid plan – off course).

So, in this case, you don’t need to worry about which model you should use as Cursor will do it for you.

Even when this is a great editor for the developers. Still, I felt that one thing is missing is to restore to one of your previous versions in case the new code generates wrong or creates a bug for other areas of your application. This capability is extremely important for me. And, many times, I literally had to spend significant hours trying to restore the previous desired working versions or at least get that version of code & restore it easily all across the board, along with the entire history of changes. Connecting with GitHub may solve the problem if you push your code. However, developers push their code when they feel like achieving some milestones. The do not push intermediate changes while developing the features or capabilities. And, that’s where my new package will fit & work efficiently in conjunction with the Cursor AI Editor. Apart from that, it compresses the entire context apart from maintainign the individual versions of context. So, you can rollback to a certain level or can continue with the latest comprehensive context that is captured within the Graphify package.


Let us understand how that works. But, before that let us understand the demo.

So, as you can see from the above video, I am able to showcase the complete capabilities. Not only are you maintaining an external way of viewing all the prompts along with the entire history, but you can also compare the versions of a single script or even between prompts.

So, you are getting an overall comprehensive picture.


Now, let us deep-dive into some of the major choices user can have.

From the above picture, we have five major sections. The top-right in CYAN shows two tabs – “Graph” & “Versions”. As per the last screenshot, the “Graph” tab is active.

The top-left contains the available options in RED, that has all the options. Initially, by default, it is set to “All types”.

The main YELLOW square-line box contains the main canvas area, which depicts the graphical flow of metadata information.

The GREEN square-line box contains the legend information. And, the lower bottom-right contains the entire codebase for the scripts, packages, & for others.

Another very important capability is to check the entire prompt history in an organized way. This will help people to understand the evolution of the products. The above picture depicts this by showing the highlighted square-line boxes.

Another very important capability is to isolate only the scripts & create a similar graphical representation. This will give developers a cleaner interface to concentrate on the evolution of the scripts rather than concentrating on everything. The highlighted square-line box showcases the selected options & the corresponding script details.

The last important tool is under the “Versions” tab. In this tab, developers have the option to select any target script & then compare the two versions within the evolution & then based on the understanding, either they can enhance/update or restore that specific version in the latest version. This will definitely give developer much needed flexibility.

The above square-line boxes highlight the script name, and the comparison intention between the two certain versions & then the difference between them at the bottom of the screen.


So, we’ve done it. In our next post, we’ll know some of the key snippets from the important scripts for a better understanding of this tool.

I hope you all like this effort & let me know your feedback. I’ll be back with another topic. Until then, Happy Avenging! 

Memory profiler in Python

Today, I’ll be discussing a short but critical python topic. That is capturing the performance matrix by analyzing the memory profiling.

We’ll take any ordinary scripts & then use this package to analyze them.

But, before we start, why don’t we see the demo & then go through it?

Demo

Isn’t exciting? Let us understand in details.

For this, we’ve used the following package –

pip install memory-profiler


How you can run this?

All you have to do is to modify your existing python function & add this “profile” keyword. And this will open a brand new information shop for you.

#####################################################
#### Written By: SATYAKI DE                      ####
#### Written On: 22-Jul-2022                     ####
#### Modified On 30-Aug-2022                     ####
####                                             ####
#### Objective: This is the main calling         ####
#### python script that will invoke the          ####
#### clsReadForm class to initiate               ####
#### the reading capability in real-time         ####
#### & display text from a formatted forms.      ####
#####################################################

# We keep the setup code in a different class as shown below.
import clsReadForm as rf

from clsConfig import clsConfig as cf

import datetime
import logging

###############################################
###           Global Section                ###
###############################################
# Instantiating all the main class

x1 = rf.clsReadForm()

###############################################
###    End of Global Section                ###
###############################################
@profile
def main():
    try:
        # Other useful variables
        debugInd = 'Y'
        var = datetime.datetime.now().strftime("%Y-%m-%d_%H-%M-%S")
        var1 = datetime.datetime.now()

        print('Start Time: ', str(var))
        # End of useful variables

        # Initiating Log Class
        general_log_path = str(cf.conf['LOG_PATH'])

        # Enabling Logging Info
        logging.basicConfig(filename=general_log_path + 'readingForm.log', level=logging.INFO)

        print('Started extracting text from formatted forms!')

        # Execute all the pass
        r1 = x1.startProcess(debugInd, var)

        if (r1 == 0):
            print('Successfully extracted text from the formatted forms!')
        else:
            print('Failed to extract the text from the formatted forms!')

        var2 = datetime.datetime.now()

        c = var2 - var1
        minutes = c.total_seconds() / 60
        print('Total difference in minutes: ', str(minutes))

        print('End Time: ', str(var1))

    except Exception as e:
        x = str(e)
        print('Error: ', x)

if __name__ == "__main__":
    main()

Let us analyze the code. As you can see that, we’ve converted a normal python main function & mar it as @profile.

The next step is to run the following command –

python -m memory_profiler readingForm.py

This will trigger the script & it will collect all the memory information against individual lines & display it as shown in the demo.

I think this will give all the python developer a great insight about their quality of the code, which they have developed. To know more on this you can visit the following link.

I’ll bring some more exciting topic in the coming days from the Python verse. Please share & subscribe my post & let me know your feedback.

Till then, Happy Avenging! 🙂

Note: All the data & scenario posted here are representational data & scenarios & available over the internet & for educational purpose only. Some of the images (except my photo) that we’ve used are available over the net. We don’t claim the ownership of these images. There is an always room for improvement & especially the prediction quality.