markdown sync

[ddkwork]

Describe the feature

After some testing, Label doesn't seem to be suitable for AI chat scenarios, while Markdown does, almost all AI models return MD format, CoreDOM doesn't seem to have a way to insert text in threads, can you add this feature?

Relevant code

package main

import (
    "cogentcore.org/core/gi"
    "fmt"
    "math/rand"
    "time"
    "unsafe"
)

func main() {
    b := gi.NewBody("ollama gui")
    label := gi.NewLabel(b)
    go func() {
        orig := "orig "
        for i := 0; i < 30000; i++ {
            start := label.UpdateStart()
            s := orig + randStr(i) + fmt.Sprint(i)
            if len(s)%10 == 0 {
                s += "\n"
            }
            label.SetTextUpdate(s)
            label.UpdateEndLayout(start)
            time.Sleep(200 * time.Millisecond)
        }
    }()
    b.RunMainWindow()
}

// ////////
const letters = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"

var src = rand.NewSource(time.Now().UnixNano())

const (
    // 6 bits to represent a letter index
    letterIdBits = 6
    // All 1-bits as many as letterIdBits
    letterIdMask = 1<<letterIdBits - 1
    letterIdMax  = 63 / letterIdBits
)

func randStr(n int) string {
    b := make([]byte, n)
    // A rand.Int63() generates 63 random bits, enough for letterIdMax letters!
    for i, cache, remain := n-1, src.Int63(), letterIdMax; i >= 0; {
        if remain == 0 {
            cache, remain = src.Int63(), letterIdMax
        }
        if idx := int(cache & letterIdMask); idx < len(letters) {
            b[i] = letters[idx]
            i--
        }
        cache >>= letterIdBits
        remain--
    }
    return *(*string)(unsafe.Pointer(&b))
}

[ddkwork]

You can use any model normally, if your machine configuration is high enough, test the super-large model under Linux and Windows, and when I have time, I want to test it under termux, and then let the Android phone have a local AI

---Original--- From: @.> Date: Tue, Mar 12, 2024 11:17 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

I do not understand; every time the program crashes, you should be able to easily copy the stack trace. However, if you want a simple overview of how the stylers are called, here it is:

Stylers are set using the Style method, which adds to a Stylers slice on WidgetBase

In a later function call, ApplyStyleTree, the ApplyStyleWidget method is called for each widget, which goes through the stylers and applies them to the widget's styles before it is rendered

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

By the way, if you have free time, update the implementation of the disk storage permission of the Android system. See if you can get permission to the sdcard directory.

---Original--- From: @.> Date: Tue, Mar 12, 2024 11:17 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

I do not understand; every time the program crashes, you should be able to easily copy the stack trace. However, if you want a simple overview of how the stylers are called, here it is:

Stylers are set using the Style method, which adds to a Stylers slice on WidgetBase

In a later function call, ApplyStyleTree, the ApplyStyleWidget method is called for each widget, which goes through the stylers and applies them to the widget's styles before it is rendered

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[kkoreilly]

Yep, I will test the models on my computer soon, and I will work on improving mobile filesystem support when I have the time.

[ddkwork]

Looking at https://github.com/cogentcore/cogent/blob/main/ai%2Fai.go#L97-L98, because I am not currently connected to a wired network communication, I have been using my mobile phone to send hotspots to tablets to provide network support, so I wrote the minimum model, when you test the large model, you need to change the comment back to let it download the super large model you selected. Because if I click on the wrong big model here, the traffic of the mobile phone will be exhausted after a while.

---Original--- From: @.> Date: Tue, Mar 12, 2024 13:21 PM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

Yep, I will test the models on my computer soon, and I will work on improving mobile filesystem support when I have the time.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

this feature is very nice, could you please implement it?

https://markmap.js.org/repl

---Original--- From: @.> Date: Tue, Mar 12, 2024 11:17 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

I do not understand; every time the program crashes, you should be able to easily copy the stack trace. However, if you want a simple overview of how the stylers are called, here it is:

Stylers are set using the Style method, which adds to a Stylers slice on WidgetBase

In a later function call, ApplyStyleTree, the ApplyStyleWidget method is called for each widget, which goes through the stylers and applies them to the widget's styles before it is rendered

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[kkoreilly]

At some point that could be implemented, but it is not a super high priority. You should file another issue for it if you want it.

[ddkwork]

Ok

---Original--- From: @.> Date: Wed, Mar 13, 2024 03:48 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

At some point that could be implemented, but it is not a super high priority. You should file another issue for it if you want it.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

HI, would it be convenient for you to create a chart like this one? It's easy to understand.

[kkoreilly]

I will consider graphical representations of our architecture when I write more documentation soon.

[ddkwork]

Oh my God, you woke up very early today. I just found out that removing child will cause null pointers in the process of adding model tags and using nary-tree, maybe the ki tree also has this situation, and what happens is that ki deletes the node, and the style of the deleted node is naturally nil. This is quite in line with my illusion that style is random nil, since deleting nodes is controlled by the behavior of events.

---Original--- From: @.> Date: Wed, Mar 13, 2024 22:40 PM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

I will consider graphical representations of our architecture when I write more documentation soon.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

One global safe solution is not to call the slices.delete function, as it executes the compiler's built-in function clean(), which will directly remove the node from physical memory. However, it also feels weird if the node doesn't call it and deletes it but isn't nil.

---Original--- From: @.> Date: Wed, Mar 13, 2024 22:40 PM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

I will consider graphical representations of our architecture when I write more documentation soon.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

I've managed to capture the root cause of all the widget style callbacks being nil

[ddkwork]

Another solution, I don't know if I'm right: each widget in each layout in a body corresponds to a node in the ki tree, and each node corresponds to a firstsTyles styling callback function slice, and the same goes for last. In a sense, the widgetbase struct is equivalent to the ki node struct, because they seem to be interacting directly with the field data, so: can we move the two style callback function slices of widgetbase to the node struct of ki, so that when the node is deleted, the style callback function pointed to by the subscript in the style callback function slice is also deleted, so that there should be no nil when any widget executes it. I can still see a lot of kid traversal to determine whether ki is nil or not, in the slice file of the ki package, when calling to delete the node, you should also delete the ki pointed to by the subscript, so that you don't have to determine whether ki is nil when any widget traversal operation occurs. The method of managing with this is this(), which should not be judged.

---Original--- From: @.> Date: Tue, Mar 12, 2024 11:17 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

I do not understand; every time the program crashes, you should be able to easily copy the stack trace. However, if you want a simple overview of how the stylers are called, here it is:

Stylers are set using the Style method, which adds to a Stylers slice on WidgetBase

In a later function call, ApplyStyleTree, the ApplyStyleWidget method is called for each widget, which goes through the stylers and applies them to the widget's styles before it is rendered

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[kkoreilly]

Calling stylers in the inspector is not a normal or intended use case, and I have been trying to disable that. The reason that panics is that the inspector does not pass the style object to the styler because it has no reason to. Please tell me whether there is ever a nil style panic outside of the inspector. If there is not, there is no issue except for the inspector, which I am working on fixing. If there is, then please send me the stack trace. As I have said multiple times, please do not spend your time debugging these issues. Your time is much better spent working on things like Cogent AI. It is much more efficient for me to fix the nil panics, and I will work on fixing all nil panics that you send me stack traces for.

[kkoreilly]

Also, please run goimports on your code; your editor should do it automatically, but all of your imports are improperly formatted. Furthermore, please use ki.Node trees for any tree object you need, not your own type.

[ddkwork]

goland doesn't seem to have the feature you said, for ki I'm not sure if it has an implementation of depth-first traversal and breadth game traversal, if you're not going to implement these methods, don't limit them too much, otherwise it will be puzzling

---Original--- From: @.> Date: Thu, Mar 14, 2024 03:16 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

Also, please run goimports on your code; your editor should do it automatically, but all of your imports are improperly formatted. Furthermore, please use ki.Node trees for any tree object you need, not your own type.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[kkoreilly]

Do you see a File Watcher: goimports option in Preferences > Tools > Actions on Save? If so, can you turn it on? Ki has depth-first traversal (Ki.WalkPre) and breadth-first traversal (Ki.WalkBreadth).

[ddkwork]

To be honest, I'm very uncomfortable with these abbreviated methods of naming, parameter naming and field naming, what idx, pre, xe, selval, selidx... I'm sorry that until this is improved, I can only use it in a way that I am familiar with

---Original--- From: @.> Date: Thu, Mar 14, 2024 07:14 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

Do you see a File Watcher: goimports option in Preferences > Tools > Actions on Save? If so, can you turn it on? Ki has depth-first traversal (Ki.WalkPre) and breadth-first traversal (Ki.WalkBreadth).

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[kkoreilly]

If there are any more uses of Sel, Idx, and Val for exported fields and functions, please tell me and I will change them. However, for local variables and package names, the names will be short. I will consider renaming WalkPre to WalkDepth.

[ddkwork]

Second, in the case of breadth-first traversal, the most intuitive idea is whether the node is a container-type node, whether it has children, etc. When I looked at the ki implementation earlier, you seemed to redefine the container type node as a new type for slices. A discerning person may not understand in 1 minute that your definition of slice tyle is containerNode, and I need to be more intuitive.

---Original--- From: @.> Date: Thu, Mar 14, 2024 07:14 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

Do you see a File Watcher: goimports option in Preferences > Tools > Actions on Save? If so, can you turn it on? Ki has depth-first traversal (Ki.WalkPre) and breadth-first traversal (Ki.WalkBreadth).

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

It's true that the package name can't be too long, but if you ask 100 people about the name xe, none of them will know what your bag is for. A long time ago, my own library repository was also densely packed with packages, and even a file operation was a package, and I couldn't always name the io package directly. Later, I found that the package division was too fine, and it was difficult to remember the package name in the case of frequent imports, so I simply moved all the frequently used functions and methods to the stream package, and continued to merge its internal packages. In this way, when I use it, I can all introduce a stream, and goland will automatically complete the import for me, which is convenient to use

---Original--- From: @.> Date: Thu, Mar 14, 2024 08:10 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

If there are any more uses of Sel, Idx, and Val for exported fields and functions, please tell me and I will change them. However, for local variables and package names, the names will be short. I will consider renaming WalkPre to WalkDepth.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[kkoreilly]

If you ask 100 people without any prior knowledge what Fyne or Gio or Ebiten would do, they would have no idea. xe provides a specific set of functionality that is completely different from anything else in Cogent Core, and it does not make sense for it to be part of another package.

[ddkwork]

I'm not suggesting that XE be merged into other packages, what I'm describing is: how I handle it myself when there are too many packages, and the package names and standard libraries are confusing and difficult to import and remember. The division of functions must be the best for you.,In addition,There's a parameter and struct field called par.,I remember the first time I looked at the code my first impression would be "pair".,Similar to the key pair naming of the RSA algorithm.,What to deal with in pairs in this GUI.。。。 Later found out that it's parent.,It's very confusing.,PreNeedless to say, the first instinct will think of "the previous one and the last one".,IDX and SEL you don't accept it, I can't help it.,Just make it i,ID is more intuitive than IDX.,SELIDX, every time you use this widget, you have to find it for 20 seconds.。。。 In general, it is not necessary to read comments for every method and function, even if the person writing the code is not fluent in English like me, it can remember many words accurately, and the comments only need to look at the logic to implement complex scenarios

[ddkwork]

Renaming and the like is easy to do in Goland, where I usually put dozens of modules into the workspace, rename one of the modules in the code, and the others will be refreshed along with it. As far as core is concerned, as long as the core cogen, emer, etc. is 200 modules of code, as long as you put it into the workspace, renaming any place will reference all the code to rename, similar to the operation: I create a module in the root of the workspace and implement a unified update of all the core and my own lib, maintaining hundreds of modules is not a problem, the workspace is a good thing for me.

[ddkwork]

func TestFmtAllMod(t *testing.T) {
    cmd.RunArgs("go work use -r .")
    lines, ok := stream.NewReadFile("go.work").ToLines()
    if !ok {
        return
    }
    mods := make([]string, 0)
    for _, line := range lines {
        line = strings.TrimSpace(line)
        if strings.HasPrefix(line, ".") {
            abs, err := filepath.Abs(line)
            if !mylog.Error(err) {
                return
            }
            mods = append(mods, abs)
        }
    }

    for _, mod := range mods {
        join := filepath.Join(mod, "go.mod")
        println(join)
        toLines, o := stream.ReadFileToLines(join)
        if !o {
            continue
        }

        lib := "    github.com/ddkwork/golibrary v0.0.0-20240314012741-de4758c6256c"
        core := "    cogentcore.org/core v0.0.8-0.20240313183652-97397a76cc05"
        for i, line := range toLines {
            switch {

            case strings.Contains(line, "golibrary") && !strings.Contains(line, "require") && !strings.Contains(line, "golibrary"):
                toLines[i] = lib
            case strings.Contains(line, "golibrary") && strings.Contains(line, "require") && !strings.Contains(line, "golibrary"):
                toLines[i] = "require " + lib

            case strings.Contains(line, "cogentcore.org/core") && !strings.Contains(line, "require"):
                toLines[i] = core
            case strings.Contains(line, "cogentcore.org/core") && strings.Contains(line, "require"):
                toLines[i] = "require " + core

            }
        }
        toString := stream.New("").LinesToString(toLines)
        stream.WriteTruncate(join, toString)
    }

    //modChan := make(chan string, len(mods))
    //
    //for i, mod := range mods {
    //tdo add lock ?
    //  go func() {
    //      if !mylog.Error(os.Chdir(mod)) {
    //          return
    //      }
    //      cmd.Run("go get -v -d github.com/ddkwork/golibrary@" + "c64ada78854c43fddbc1eda97e50c632922c6920")
    //      run := cmd.Run("go get -v -d cogentcore.org/core@" + "bdafc24c3306d3a8603f019ab965f92e1272c6b4")
    //      //cmd.Run("go get -v -u all")
    //      //cmd.Run("go mod tidy -v")
    //      if i > 0 {
    //          cmd.Run("gofumpt -l -w .")
    //      }
    //      modChan <- run.CurrentDirectory //todo why
    //  }()
    //}
    //
    //Wait := func() {
    //  for {
    //      select {
    //      case mod := <-modChan:
    //          mylog.Success("finished mod", strconv.Quote(mod))
    //          if len(modChan) == 0 {
    //              return
    //          }
    //      }
    //  }
    //}
    //
    //Wait()

    mylog.Success("all work finished")
}

[ddkwork]

For me I need simple, easy-to-remember interface signatures like types to make it easy to manipulate the n-ary tree.

type RowData[T any] interface {
    Clone(newParent *Node[T], preserveID bool) *Node[T]
    CellData(columnID int, data any)
    String() string
    Enabled() bool
    CopyFrom(from *Node[T])
    ApplyTo(to *Node[T])
    UUID() uuid.UUID
    Container() bool
    kind(base string) string
    GetType() string
    SetType(t string)
    Open() bool
    SetOpen(open bool)
    Parent() *Node[T]
    SetParent(parent *Node[T])
    HasChildren() bool
    Children() []*Node[T]
    SetChildren(children []*Node[T])
    clearUnusedFields()
    AddChild(child *Node[T])
    Sort(cmp func(a T, b T) bool)
    Depth() int //todo
    InsertItem(parentID uuid.UUID, data T) *Node[T]
    CreateItem(parent *Node[T], data T) *Node[T]
    RemoveChild(id uuid.UUID)
    Update(id uuid.UUID, data T)
    Find(id uuid.UUID) *Node[T]
    Walk(callback func(node *Node[T]))
    WalkContainer(callback func(node *Node[T]))
    Format(root *Node[T]) string
    format(root *Node[T], prefix string, isLast bool, s *stream.Stream)
    formatData(rowObjectStruct any) (rowData string)
}

type (
    RowConstraint[T any] interface {
        comparable
        RowData[T]
    }
    Model[T RowConstraint[T]] interface {
        RootRowCount() int
        RootRows() []T
        SetRootRows(rows []T)
    }
    SimpleTableModel[T RowConstraint[T]] struct{ roots []T }
)

func (m *SimpleTableModel[T]) RootRowCount() int    { return len(m.roots) }
func (m *SimpleTableModel[T]) RootRows() []T        { return m.roots }
func (m *SimpleTableModel[T]) SetRootRows(rows []T) { m.roots = rows }

[kkoreilly]

I understand that our short names cause problems for you, and as I have said before, I am perfectly willing to replace the usage of Idx and Sel in field and function names if you tell me where we still use that. However, local variable and package names must be short. For WalkPre, we are following the naming convention stated here: https://en.wikipedia.org/wiki/Tree_traversal#:~:text=Pre%2Dorder%2C%20NLR%5Bedit%5D. Please use ki instead of your own tree package.

[ddkwork]

Node traversal with children does not necessarily have to be called breadth, fyne calls it branch, unison calls it container, you call it breadth, after comparison, the container is more suitable for me, it is easy to remember, and the expression is sufficient: for the tree, having a child node means that there is a containment function, which is very close to the function of the container. And the breadth is too wide, and the breadth does not only refer to the scene of the tree, but it is not easy to remember in one word.

---Original--- From: @.> Date: Fri, Mar 15, 2024 12:53 PM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

I understand that our short names cause problems for you, and as I have said before, I am perfectly willing to replace the usage of Idx and Sel in field and function names if you tell me where we still use that. However, local variable and package names must be short. For WalkPre, we are following the naming convention stated here: https://en.wikipedia.org/wiki/Tree_traversal#:~:text=Pre%2Dorder%2C%20NLR%5Bedit%5D. Please use ki instead of your own tree package.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

In addition, I have recently expanded the meaning of tree to table, container nodes have their own properties, in the tree table, the level name needs the type method, which has been done in my implementation, and the container node will also talk about extending the sum function of calculating the child node, I am expanding these methods. I don't understand a little bit as to why you have such an inexplicable restriction and what is the reason why you have to use ki

---Original--- From: @.> Date: Fri, Mar 15, 2024 12:53 PM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

I understand that our short names cause problems for you, and as I have said before, I am perfectly willing to replace the usage of Idx and Sel in field and function names if you tell me where we still use that. However, local variable and package names must be short. For WalkPre, we are following the naming convention stated here: https://en.wikipedia.org/wiki/Tree_traversal#:~:text=Pre%2Dorder%2C%20NLR%5Bedit%5D. Please use ki instead of your own tree package.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

One last point, I want to make it clear that any AI GUI uses Core just to show the interface, not for the implementation process, and it doesn't make sense for any implementation to limit this limitation. Another one you won't improve ki and clean up the code according to my description, such as ki's method of deleting nodes, why do you want to have a large piece of code yourself, slices.delet a single sentence of code is done. I cleaned up some redundant code in the fork repository and was able to run the demo, and nothing unusual happened. There are many ways to optimize ki-slicing. But what does this mean? It's also impossible for you to clean them up to optimize logic and readability.

[ddkwork]

I don't want to continue it anymore, it's tiring to go on with such endless arguments, all close this issue

[kkoreilly]

I would be happy to review any PR improving the structure of ki or the naming of our exported fields and functions. I agree that it is tiring to continue these arguments, so you can just develop Cogent AI the way you want to, and I will not restrict you from doing anything.

[ddkwork]

All right. At present, I realize that all models and dozens of tags corresponding to each model may not be conducive to user operation after being stuffed into a linear display table, because it is too much trouble to find tags for specific models, and then the continuous refresh of models and parameters by ollama officials may cause HTML feature code changes, so I need to save some necessary unit tests and files, if this will cause an increase in the size of the repository, I will remove them. I just talked about the display of models in the table: my idea is to either use a tree shape, with the model on the left and a list of model tags on the right, or all the model tags are arranged linearly into the table like now, and the last one is a tree table, which is not possible at the moment. However, I will use this AI project to simulate the behavior of real data in a tree table to deepen my understanding of it, because I also need Nary Tree to manipulate other things in other projects. When I'm done with more unit tests, I'll move the package to my lib and redirect the model-related calls to the ki package. Also, I'm not too happy with the look of the svg, which is why I added extra svg in my repo before. The next thing is to improve the dialog layout: user input and AI replies need to be categorized layout, I don't know how to lay it out and can't describe it in correct English, I'll send you a picture to show you later.

[ddkwork]

[kkoreilly]

For the message interface, you just need to make a new frame for each message, and you can set s.Align.Self to styles.Start and styles.End for the two different types of messages.

[ddkwork]

You change it first, I'll sleep for a while, I'm a little tired

---Original--- From: @.> Date: Sat, Mar 16, 2024 02:14 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

For the message interface, you just need to make a new frame for each message, and you can set s.Align.Self to styles.Start and styles.End for the two different types of messages.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

Can you categorize core's issue Labels by function? It's easier to navigate through the issue list!

[ddkwork]

[ddkwork]

i do not known how to let it more beautiful, could you please change it

[ddkwork]

In addition, how MD copies the content above, the mouse cannot select the content

[ddkwork]

[kkoreilly]

I will work on improving the Cogent AI interface soon.

[kkoreilly]

I implemented a working history display and improved some error handling and model loading logic. Please pull the latest version and let me know what you think.

[ddkwork]

I noticed that you did readall before scan body, so that goquery will read a nil body, just guessing, I haven't read all the changes yet

---Original--- From: @.> Date: Mon, Mar 18, 2024 06:01 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

I implemented a working history display and improved some error handling and model loading logic. Please pull the latest version and let me know what you think.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

Sorry, I read the logic wrong, you are right. Also, I'm happy with the naming change.

---Original--- From: @.> Date: Mon, Mar 18, 2024 06:01 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

I implemented a working history display and improved some error handling and model loading logic. Please pull the latest version and let me know what you think.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

I've just pulled your changes, the logic of the sending message part does not conform to the AI model's subsequent reply scenarios and extends more model features, such as: we will definitely implement the user to continuously enter the question to talk to the AI at some point in the future, and the current logic becomes: the user can only always enter once and the session will end. So we also need to implement: support the user and AI in the current round of conversations to implement multiple input and reply to messages from both sides, form a list, and support scrolling this view. The next thing is not to delete the new session button, it will perform the current round of conversation actions clearly, of course the history is a good thing, when the new session button is executed we can save the current conversation list. This button seems to have been renamed a long time ago. On the other hand, limit the size of the text edit box for entering the message, you can try to copy a large piece of text, it will almost fill the entire layout, and you have to limit it.

---Original--- From: @.> Date: Mon, Mar 18, 2024 06:01 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

I implemented a working history display and improved some error handling and model loading logic. Please pull the latest version and let me know what you think.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

I don't know if I've explained this mood clearly, for example: I am discussing a very complex problem with you, I need to ask you 10 sentences, and you reply 9 sentences, at which point we can end the conversation satisfactorily, at this time, it makes sense to click the new conversation button. The current logic is that the need to send and receive messages multiple times during a session becomes one message that can only be sent or received once.

---Original--- From: @.> Date: Mon, Mar 18, 2024 06:01 AM To: @.>; Cc: @.>;"State @.>; Subject: Re: [cogentcore/core] markdown sync (Issue #929)

I implemented a working history display and improved some error handling and model loading logic. Please pull the latest version and let me know what you think.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[ddkwork]

this is one topic only~

[kkoreilly]

Yes, you can add back the new topic button. The Go convention is to capitalize JSON and other acronyms. Also, it would be helpful if you can use more accurate commit messages if possible.

[ddkwork]

i am sorry,i forgot test run model, it is seems good