Perguntas[go](coding)

Estou iniciando um novo projeto e vi uma biblioteca muito interessante para GO que é um pouco parecida com o fasthtml, chamada go-app.

Estou com dificuldades para executar comandos JS simples como console.log ou alert. Ou estou esquecendo de algo?

type Button struct {
    app.Compo
}

func (b *Button) OnClick(ctx app.Context, e app.Event) {
    // NONE of these codes works when clicking the button.

    //e.JSValue().Call("alert", "e jsvalue call Button clicked!")
    //ctx.JSSrc().Call("alert", "ctx jssrc call Button clicked!")

    //app.Window().Get("alert").Call("window get call Hello world")
    //app.Window().Call("alert", "window call Button clicked!")
    app.Window().Get("console").Call("log", "window get call log")
}

func (b *Button) Render() app.UI {
    return app.Button().
        ID("button").
        Text("Click me!").
        OnClick(b.OnClick)
}

Ao escrever um serviço web acessado por navegadores web, um co-mantenedor sugeriu que permitíssemos que os usuários escolhessem fazer login em uma sessão sem usar cookies. (Usar formulários HTML ocultos é outra coisa que consideramos, mas não estou muito interessado na ideia. JavaScript não é aceitável.)

Usando o servidor HTTP da biblioteca padrão Go ou talvez outros mecanismos, ao definir Connection: keep-alive, é possível identificar de qual conexão de rede uma solicitação de entrada se originou?

• Armazenar um ponteiro para http.Request.TLS(a tls.ConnectionState) não funcionará porque sua memória pode ser liberada e o endereço pode ser reutilizado, possibilitando o sequestro de sessões.
• Não vejo valores úteis em http.Request.

É definitivamente possível implementar isso aceitando solicitações como uma conexão TCP/TLS/etc simples, armazenar algumas informações e construir o http.Requests eu mesmo; mas isso parece bem trabalhoso.

Entendo o seguinte ponto em relação ao recover()comportamento em Go. recover()Segue avaliação imediata, mas execução atrasada .

Então, se ele não for chamado dentro de uma função adiada (trecho de código 1), ele recover()será avaliado naquele momento e, nesse ponto, ele ainda estará lá nile, portanto, nosso código entra em pânico.

Se for chamado dentro de uma função adiada, a chamada da função será registrada, mas recover() será chamada depois que ocorrer panice será recuperada com sucesso.

package main

import "fmt"

func main() {
    defer recover() // since not called inside a deferred func, it will not recover successfully

    panic("This is a panic")

}

Agora, tendo isso em mente, escrevi o código abaixo.

import (
    "fmt"
)

func main() {

    defer func(){
        customRecover()
    }()

    panic("This is a panic")

}

func customRecover(){
    if r:= recover(); r!= nil{
        fmt.Println("Custom Recovery for: ",r)
    }
}

Pesquisei online o raciocínio e obtive a mesma resposta que

O valor de retorno de recover é nulo se qualquer uma das seguintes condições for atendida:

• o argumento do pânico era nulo;
• a goroutine não está em pânico;
• recover não foi chamado diretamente por uma função adiada.

Mas não consigo entender por que o segundo snippet não está funcionando?!?

Ela satisfaz todas as 3 condições estritamente falando. Há alguma ressalva que eu esteja esquecendo? Acho que a 3ª condição não é satisfeita porque ela não é chamada diretamente, mas por meio de uma chamada de função aninhada. Mas por que ela precisa estar dentro de deferred somente?

Perguntas semelhantes: aqui , aqui , aqui e aqui .

Lendo simultaneidade em Go .

Tentando entender o padrão do canal or-done .

Estou com dificuldade para entender o fluxo de execução.

Mencionei o número na linha de onde vem minha dúvida.

1. Por que nenhuma returndeclaração em inner <-donecomo temos em outer select? Por causa de nenhuma returndeclaração, a próxima iteração será executada e se nessa iteração tivermos ambos <- donee <-cdisponíveis. Sabemos select-caseque escolheremos qualquer um dos casos arbitrariamente se vários casos estiverem disponíveis. Isso significa que há uma possibilidade de que <-cserá executado mesmo se <-doneestiver disponível?

2. Já que select-casearbitrariamente escolhe um caso quando vários casos estão disponíveis, é correto assumir que o <- doneserá escolhido eventualmente , mas não é necessário que seja escolhido imediatamente assim que for fechado. Claro, essa dúvida é quando ambos os casos, ie <-donee <-cestavam disponíveis.

3. Existe uma possibilidade que <- vnão está escrita valStreamquando doneé fechada e é perdida para sempre, correto?

orDone := func(done, c <-chan interface{}) <-chan interface{} {
    valStream := make(chan interface{})
    go func() {
        defer close(valStream)
        for {
            select {                   //2
            case <-done:
                return
            case v, ok := <-c:
                if ok == false {
                    return
                }
                select {
                case valStream <- v:   //3
                case <-done:           //1
                }
            }
        }
    }()
    return valStream
}

Basicamente, corrija-me se eu estiver errado ou confirme que meu entendimento da execução está correto. De fato, há "brechas" no código e isso é apenas comportamento do canal aqui.

Pergunta semelhante aqui

Eu escrevi o seguinte programa golang para main.goaprender dbus em Go:

package main

import (
    "fmt"
    "github.com/godbus/dbus/v5"
    "time"
)

// Listener function to listen for D-Bus signals
func runListener() {
    // Create a new D-Bus connection for the listener
    conn, err := dbus.SessionBus()
    if err != nil {
        fmt.Println("Listener: Failed to connect to session bus:", err)
        return
    }
    defer conn.Close()

    // Request a unique name for the listener
    busName := "org.example.Listener"
    if _, reqErr := conn.RequestName(busName, dbus.NameFlagDoNotQueue); reqErr != nil {
        fmt.Println("Listener: Failed to request name:", reqErr)
        return
    }
    fmt.Println("Listener: Listening for messages on", busName)

    // Add a match rule for the specific signal
    err = conn.AddMatchSignal(
        dbus.WithMatchInterface("org.example.ListenerInterface"), // Match interface
        dbus.WithMatchMember("Message"),                          // Match signal member
    )
    if err != nil {
        fmt.Println("Listener: Failed to add match rule:", err)
        return
    }

    // Create a channel to receive signals
    c := make(chan *dbus.Signal, 10)
    conn.Signal(c)

    // Listen for messages
    fmt.Println("Listener: Waiting for D-Bus messages...")
    for signal := range c {
        fmt.Printf("Listener: Received message: %v\n", signal.Body)
    }
}

// Sender function to send a D-Bus signal
func runSender() {
    // Wait briefly to ensure the listener is ready
    time.Sleep(2 * time.Second)

    // Create a new D-Bus connection for the sender
    conn, err := dbus.SessionBus()
    if err != nil {
        fmt.Println("Sender: Failed to connect to session bus:", err)
        return
    }
    defer conn.Close()

    // Define the signal details
    objectPath := dbus.ObjectPath("/org/example/Listener") // Convert string to ObjectPath
    interfaceName := "org.example.ListenerInterface"
    signalName := interfaceName + ".Message"

    // Emit the signal
    fmt.Println("Sender: Sending message to listener...")
    err = conn.Emit(objectPath, signalName, "Hello from the sender!")
    if err != nil {
        fmt.Println("Sender: Failed to send message:", err)
        return
    }

    fmt.Println("Sender: Message sent successfully!")
}

func main() {
    // Run the listener and sender as separate goroutines
    go runListener()
    go runSender()

    // Prevent the program from exiting immediately
    select {}
}

O problema que estou tendo é que o programa gera com sucesso:

Listener: Listening for messages on org.example.Listener Listener:
Waiting for D-Bus messages... Sender: Sending message to listener...
Sender: Message sent successfully!

Mas observe que não há saída "Listener: Received message"...

Também tentei fazer isso usando dois main.goarquivos separados em dois diretórios de projeto separados (Listener, Sender), mas não consegui configurar corretamente o GoLand para executar os dois main.goarquivos ao mesmo tempo, pois recebi um erro do GoLand: package dbus_messenger is not in std (/usr/lib/golang/src/dbus_messenger) .

Aqui está um exemplo mínimo de funcionamento:

package main

import (
    "fyne.io/fyne/v2/app"
    "fyne.io/fyne/v2/container"
    "fyne.io/fyne/v2/layout"
    "github.com/fyne-io/terminal"
    "log/slog"
    "os"
    "os/exec"
    "sync"
)

func main() {
    err := runMain()
    if err != nil {
        slog.Error(err.Error())
        os.Exit(1)
    }
}

func runMain() error {
    wg := sync.WaitGroup{}
    wg.Add(1)

    term := terminal.New()
    go func() {
        var err error

        // This works
        // err = term.RunLocalShell()

        // This does not work, blank screen...
        cmd := exec.Command("/usr/bin/bash")
        si, err := cmd.StdinPipe()
        if err != nil {
            slog.Error(err.Error())
            os.Exit(1)
        }
        so, err := cmd.StdoutPipe()
        if err != nil {
            slog.Error(err.Error())
            os.Exit(1)
        }
        err = cmd.Start()
        if err != nil {
            slog.Error(err.Error())
            os.Exit(1)
        }
        slog.Info("started", "pid", cmd.Process.Pid)
        err = term.RunWithConnection(si, so)

        if err != nil {
            slog.Error(err.Error())
        }

        wg.Done()
    }()

    a := app.New()
    go func() {
        wg.Wait()
        a.Quit()
    }()
    w := a.NewWindow("Test")
    w.SetContent(container.New(layout.NewStackLayout(), term))
    w.ShowAndRun()
    return nil
}

Então term.RunLocalShell()funciona, mas a conexão manual stdout e stdin de uma chamada os.Exec para term.RunWithConnection(in, out)não funciona. Ele exibe uma tela em branco, e não há nenhuma mensagem de erro.

O que há de errado aqui?

Posso ver que terminal.RunLocalShell chama terminal.open() e que usa github.com/creack/pty para criar um pty. No entanto, terminal.pty não é um campo público, ele não pode ser acessado de fora. Meu objetivo é executar um comando shell remotamente e exibi-lo em um emulador de terminal local. Por exemplo, o exemplo dado é realmente mínimo, na realidade stdin e stdout são pipes conectados com TCP a um processo remoto.

Sobre o programa: Estou tentando implementar o padrão pipeline por meio do meu próprio tipo de primeira classe intJob. A função main, que agrega os pipelines, é ExecutePipeline2e, como posso dizer, exatamente ela está causando problemas.

Por que continuo tendo deadlocks? Para mim, parece que fecho todos os canais que são usados ​​pelos leitores após cada goroutine. Além disso, criar canais com buffer não ajuda, então fiquei completamente sem ideias e ficarei muito grato pela sua ajuda.

IMPORTANTE : Não posso alterar a mainfunção e implementar essa ideia somente a partir de outras funções, quando a base (função mencionada) permanece constante e inalterada.

type intJob func(a, b chan int)

func ExecutePipeline2(jobs ...intJob) {
    outs := make([]chan int, len(jobs)+1)
    wg := sync.WaitGroup{}

    for i := 0; i < len(outs); i++ {
        outs[i] = make(chan int)
    }

    for i, job := range jobs {
        job := job
        in, out := outs[i], outs[i+1]
        i := i
        wg.Add(1)
        go func() {
            job(in, out)
            fmt.Printf("job %d closed\n", i)
            close(out)
            wg.Done()
        }()
    }

    wg.Wait()
}

func pipe(_, b chan int) {
    for i := 0; i < 5; i++ {
        b <- i
    }
}

func main() {
    inputData := []int{0, 1, 1, 2, 3, 5, 8}

    hashSignJobs := []intJob{
        intJob(func(in, out chan int) {
            for _, fibNum := range inputData {
                out <- fibNum
            }
        }),
        intJob(pipe),
        intJob(func(in, out chan int) {
            for val := range in {
                fmt.Println(val)
            }
        }),
    }

    ExecutePipeline2(hashSignJobs...)
}

Emitir

O problema imediato é que uma função do tipo func() Foonão pode ser atribuída func() anyem Golang. Talvez esse seja um problema XY, então explicarei por que exatamente estou nessa situação.

Exemplo

Basicamente, tenho algo como um pacote de verificação de integridade (este é um modelo simplificado para simplificar):

//package: internal/health
type Check struct {
    Name  string
    Func func() (metadata any, err error)
}

type Manager struct {
    checks []Check
}

func (m *Manager) RegisterCheck(check Check) {
    m.checks = append(m.checks , check)
}

func (m *Manager) PrintHealth() {
    for _, check := m.checks {
        output, _ := check.Func()
        slog.Info("Health", slog.Any("output", output))
        // In the actual implementation, I aggregate the checks and JSONify them
    }
}

Então talvez eu tenha outro pacote que tenha métodos que eu queira adicionar às verificações:

//package: internal/service
type Foo struct {}

func (f Foo) Health() (string, error) {
    return "baz", nil
}

type Bar struct {}

func (b Bar) Health() (map[string]int, error) {
    return map[string]int{"qux": 1} , nil
}

//package: cmd/app
func main() {
    foo := service.Foo{}
    bar := service.Bar{}

    h := health.Manager{}
    h.RegisterCheck(health.Check{
        Name: "Foo",
        Func: foo.Health, // This is where the type error occurs
    })
    h.RegisterCheck(health.Check{
        Name: "Bar",
        Func: bar.Health, // This is where the type error occurs
    })
}

O que eu tentei/considerei?

• Adicionar parâmetro de tipo para ManagereCheck
  • Problema? Managersó seria capaz de adicionar verificações de um determinado tipo, o que significaria que Fooe Barnão seria capaz de ser adicionado ao mesmo Manager, que é essencialmente compartilhado por todo o aplicativo.
• Adicionar parâmetro de tipo para RegisterCheckeCheck
  • Problema? Golang não suporta parâmetros de tipo para métodos.

Veja o exemplo de gobyexample.com: https://gobyexample.com/timers

timer2 := time.NewTimer(time.Second)
go func() {
    <-timer2.C
    fmt.Println("Timer 2 fired")
}()
stop2 := timer2.Stop()
if stop2 {
    fmt.Println("Timer 2 stopped")
}

Pergunta: depois de parar o cronômetro fica go func()travado para sempre? E se sim, qual seria a maneira correta de lidar com esse caso?

Estou tentando validar um campo struct em Golang usando o pacote go-playground/validator/v10. Especificamente, quero usar a tag oneof para validar que o valor do campo corresponde a um dos valores predefinidos, que inclui strings com aspas simples ('). Aqui está o código que estou usando:

package main

import (
    "fmt"

    "github.com/go-playground/validator/v10"
)

// Struct with validation tag
type Award struct {
    Title string `validate:"oneof=palm'dor level'dor 'state award'"`
}

func main() {
    validate := validator.New()

    // Test cases
    testCases := []Award{
        {"palm'dor"},    // Expected: Valid
        {"level'dor"},   // Expected: Valid
        {"state award"}, // Expected: Valid
        {"other"},       // Expected: Invalid
    }

    for _, testCase := range testCases {
        err := validate.Struct(testCase)
        if err != nil {
            fmt.Printf("Input: %q - Invalid (%v)\n", testCase.Title, err)
        } else {
            fmt.Printf("Input: %q - Valid\n", testCase.Title)
        }
    }
}

Comportamento esperado: O programa deve validar "palm'dor", "level'dor" e "state award" como entradas válidas. Qualquer outro valor deve ser marcado como inválido.

Problema: Quando executei o programa, obtive a seguinte saída:

Input: "palm'dor" - Invalid (Key: 'Award.Title' Error:Field validation for 'Title' failed on the 'oneof' tag)
Input: "level'dor" - Invalid (Key: 'Award.Title' Error:Field validation for 'Title' failed on the 'oneof' tag)
Input: "state award" - Valid
Input: "other" - Invalid (Key: 'Award.Title' Error:Field validation for 'Title' failed on the 'oneof' tag)