Results 1 to 8 of 8

Thread: Has anyone tried using the Cursor Editor?

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Feb 2009
    Location
    Fresno, CA
    Posts
    1,084

    Default Has anyone tried using the Cursor Editor?

    The Cursor team was on the Lex Fridman podcast yesterday. Popped up in my feed today. I haven't had time to listen to it yet, but I downloaded the editor to check it out after watching part of a segment.

    Because of course it's not going to work for DataFlex, right? Right?

    I opened one of our Windows .src files to start, and asked it "Where is the cdtApplication class defined?"

    The `cdtApplication` class is likely defined in a custom package or file specific to the Datatech application framework. It's not a standard DataFlex class.

    In DataFlex applications, custom classes are often defined in separate package files (.pkg) or include files (.inc). The naming convention "cdt" at the beginning of the class name suggests it's a custom Datatech class.

    To find where this class is defined, you could:

    1. Look for a file named something like "cdtApplication.pkg" or "cdtApplication.inc" in the project directory or its subdirectories.
    2. Search for "Class cdtApplication" or "Object cdtApplication" in all project files.
    3. Check if there's a base application package file that might include this class definition.

    Without access to the full project structure, it's not possible to pinpoint the exact location. However, it's clear that this is a custom application class built on top of the standard DataFlex framework, likely to add specific functionality for Datatech's applications.
    Um... ok, maybe it knows something about DataFlex? And it's (correctly) assuming/deduced there's a Datatech application framework where we use cdt as prefixes for our classes. Interesting...

    Let's throw it a curveball.

    "How should indicator conditionals in Dataflex be refactored?" (We have a lot of old code that needs to be refactored)

    It produced a comprehensive and largely correct explanation with one hallucination (it thought the syntax [Customer.Balance Gt 1000] was valid).

    I had it refactor a find loop using indicators and it did it with only one error.

    Code:
    [Found] indicate found as (invtran.ord_num=arinvc.ord_num)
    was refactored into:
    Code:
    If (Found) Begin
        If (invtran.ord_num = arinvc.ord_num) Begin
    I explained the error and asked "Can you explain why that would cause a problem?"
    You're absolutely right, and thank you for catching that important detail. This is a critical error in the refactored code that could cause significant issues. Let me explain why this is problematic:
    1. In DataFlex, the Found indicator is automatically set by certain operations like Find commands.
    2. In the original code with indicators, the line:
    [Found] indicate Found as (invtran.ord_num=arinvc.ord_num)
    was re-evaluating the Found condition based on whether invtran.ord_num matched arinvc.ord_num.
    3. By not setting the Found indicator in our refactored code, we're losing this important check. This means that subsequent code that relies on the Found indicator would be working with an incorrect state.
    4. The consequence could be that the code processes records it shouldn't, or fails to process records it should, leading to data integrity issues or incorrect report output.
    Not bad...

    Ok something else I need to do is convert Dataflex finding loops for reports into equivalent SQL to improve performance.

    "Do you understand how to convert conditions in Dataflex to select records in a finding loop to equivalent SQL WHERE clause conditions?"

    In general, yes I understand the concept of converting DataFlex records selection conditions to SQL WHERE clauses...

    (omitted technically correct answer and example)

    Would you like me to attempt a SQL translation of a specific piece of DataFlex code?
    "Yes try the code I've highlighted in the editor"

    And it did take a fairly complex 22 lines of DF selection logic and produced the equivalent SQL WHERE clause. Including actually evaluating what the code did and simplifying it.

    e.g.
    Code:
    Else If (sSaleType="Freight") Begin
        indicate select as (invtran.type=left(sSaleType,1))
    End
    turned into:
    Code:
    WHEN @sSaleType = 'Freight'
        THEN invtran.type = 'F'
    Anyway, very interesting initial results. Will definitely try more with DataFlex code when I have time.

    EDIT:

    This thing is insane, and I feel like I'm just scratching the surface. I was just doing some AI CHAT prompts before.

    Writing new code, it feels like autocomplete on steroids. Entire lines of code are suggested. Sometimes incorrectly, which may mean it needs more source code for context. I think it's only looking at the file(s) I have open in the editor, not our entire codebase right now. I'm curious what will happen if I write comments before code, whether that will affect suggestions.

    Writing a new function "function FindEmployeeRow". After typing that much, pressing tab gives me:

    Code:
    function FindEmployeeRowids integer iPlanNum returns rowid[]
        rowid[] riEmployeeRowids
        function_return riEmployeeRowids
    end_function
    The local variable for the return value is automatically generated, and if you change the type of the return variable in the function declaration the type for the variable declaration is also changed.

    As soon as I added the parameter "date dStarting" to a function declaration the automatic suggestion was "date dEnding" for the next parameter.

    It seems to be learning as it goes. I typed "procedure FindInvoicesByCustomer integer iStartCust" and it suggested "integer iEndCust returns trbInvhdr[]" to finish off the line.

    Now, "trb" is a prefix we use for types that correspond to table buffers ("t"ype "r"ecord "b"uffer). I've just written code with two other types for other tables, trbPrjnlhdr and trbPrjnline. If it were scanning the entire codebase it might have made a better guess at the correct return type, but it seems to have made a reasonable inference "Inv" from "FindInvoicesByCustomer" and "hdr" from "trbPrjnlhdr".

    Another neat trick: I highlighted a chunk of code inside a loop and told it to refactor it into a separate procedure, adding a line to call the procedure and it did it with the correct parameters for the procedure and defining all of the local variables used in that chunk of code. The only thing I had to do was cut/paste the new procedure to the correct location in the file, because it simply replaced the code I had highlighted. I'm very interested to see how good it is at more complicated refactoring.
    Last edited by matthewd; 8-Oct-2024 at 07:24 PM.
    Best regards,

    Matt Davidian
    Datatech
    Fresno, CA
    www.datatechag.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •