Lime: Suporte do Windows [$30]

Uau, isso soa fantástico.

martell [email protected] schrieb:

oi @quarnster ,

Vou assumir a tarefa da porta do Windows.
Eu deveria ter feito isso em breve.

Eu descobri erros de vinculação com mingw64 e go lang e um patch
deve ser enviado para o mingw64-crt em breve para resolver o último link
erro de pygo e outro c ligado depende.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/limetext/lime/issues/228

Obrigado!

"C:\msys64\mingw32\pkg\tool\windows_386\8l.exe" -o "C:\msys64\tmp\go-build836004963\lime\3rdparty\libs\gopy_test\gopy.test.exe" -L "C :\msys64\tmp\go-build836004963\lime\3rdparty\libs\gopy_test" -L "C:\msys64\tmp\go-build836004963" "C:\msys64\tmp\go-build836004963\lime\3rdparty\libs\ gopy_test\main.a"
$WORK\lime\3rdparty\libs\gopy_test\gopy.test.exe
PASSAR
ok lime/3rdparty/libs/gopy 2.592s

Grande sucesso :)

Uau, isso é incrível!

o que eu faço depois do gopy? O guia foi alterado há algum tempo porque o cmake foi adicionado.
Eu também construí as ligações qt5 :)

Eu já tenho uma compilação no gcc e obviamente python3.3 com .a libs

EDIT: Tudo bem, vou seguir os passos nos cmakelists manualmente :)

Seria bom se você nos dissesse como reproduzir a compilação do python.

Estou usando msys2 e pacman. mingw-w64-x86_64-python3 é um pacote para isso.
Geralmente estamos no irc no OFTC #msys2 adicionamos novos pacotes diariamente :)
Você pode pegar aqui
http://sourceforge.net/projects/msys2/

Recentemente, adicionei o próprio go, mas estamos resolvendo os problemas com ele.
Quando o lime estiver pronto, vou adicioná-lo como um pacote e o script PKGBUILD para construí-lo;)
python e onig devem estar aqui https://github.com/martell/MINGW-packages

Também estou no msys2. Eu brinquei ontem com ele. Como você gerou a biblioteca python estática? Você usou uma cadeia de ferramentas de 32 ou 64 bits, vá?

A correção crt mencionada já está online?

https://github.com/martell/MINGW-packages
Python PKGBUILD está neste repositório
Sim, alexey aplicou à mão. Eu e o mingwandroid estamos tentando consertar o CFLAG de go passando para mingw64
Depois disso deve ser bom para ir :) ... espero

Apenas "pacman -Syu" para atualizar o crt

Mas python3 é construído como uma biblioteca compartilhada por padrão, não é? Com mingw (não w64) eles usaram pexports. Como você lidou com isso? O que há de errado com os CFLAGS?

Python3 é compilado com mingw64, então não precisamos fazer as exportações.
Obtemos o libpython3.3m.a por padrão como resultado
https://github.com/martell/MINGW-packages/tree/master/mingw-w64-python3

Não usamos o visual studio para nada. Também não contamos com compilações de estúdio visual de qualquer biblioteca

O equivalente a pexports seria gendef. Nós não precisamos disso aqui embora
http://sourceforge.net/apps/trac/mingw-w64/wiki/gendef

Ok, então eu construí com sucesso o frontend termbox com mingw64.
Ele fecha normalmente com esta mensagem no debug.log
[2014/01/25 00:47:11 GMT] EROR (main.main:607) O identificador é inválido.

A compilação qml me dá esse erro depois de configurar as ligações.
Duas ligações em um projeto devem causar problemas.
lime/frontend/qml
C:\msys64\tmp\go-build680373563/lime/3rdparty/libs/gopy/lib.a(_all.o): referência de símbolo duplicada: mingw_onexit em github.com/niemeyer/qml(.text) e lime/3rdparty /libs/gopy/lib(.texto)

https://www.dropbox.com/s/2ibydge1x8k9s1w/lime.7z

Eu construí com sucesso o termbox, html e voltei ao qt5 main.go, pois o qml não ligaria

Termbox parece o melhor até agora.
Eu carrego todos os plugins e depois trava :/
Bom arquivo de log embora ;)

procure em build/bin por exe's e não os mova, pois eles são relevantes para a estrutura de pastas

@martell : você tentou executar o frontend termbox no prompt de comando do Windows em vez de mintty?

@EdVanDance
Sim, estou executando o termbox do windows cmd.prompt
Parece que com um pouco mais de trabalho em andamento que isso pode ser resolvido.
Também precisamos remover setcolormode 256 no Windows, pois não temos essa função

@martell Não consigo executá-lo. Eu instalei o i686 python3 (estou no x86_64). Abriu um cmd:

set PYTHONHOME=...\msys64\mingw32\lib\python3.3
termbox.exe

E eu recebo:

Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Você não deveria ter que definir PYTHONHOME, pois incluí as dlls do python
Funciona para mim sem isso.

Agora eu talvez errado, mas eu não fiz isso de qualquer maneira.

O patch foi mesclado no mingw64-crt e o alexey fará uma atualização em breve ;)

Se eu não definir o PYTHONPATH. Eu recebo:

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Você inicia o prompt de comando de dentro do msys? Eu comecei diretamente via Win+R .

Não, eu fui diretamente para o cmd como você fez, PYTHONHOME não está definido no meu sistema.
Acho que instalei anteriormente o python no meu sistema com o instalador do Windows,
talvez seja por isso que meu windows cmd não reclama?

Isso poderia explicar por que ele trava em um certo ponto também, talvez eu esteja usando os arquivos python errados

Você instalou mingw python3 ou msys2 python3 eles são muito diferentes

Hum, esse pode ser o motivo. Mas não entendo por que ele reclama depois de configurar o PYTHONPATH.
Há definitivamente um módulo de codificações.

Eu entendi.
É apenas:

set PYTHONHOME=...\msys64\mingw32

Sem lib\python3.3 .

Legal ;) e sua saída?

Mostra o conteúdo do arquivo, mas não reage ao pressionamento de teclas. E reclama do modo de 256 cores.

No zip que enviei tenho todos os meus arquivos cgo.go para referência se você quiser compilar a partir da fonte ;)
Eu também tenho um pacote no meu repositório mingw-packages para onig and go que você precisará.

Você pode pastebin-lo por favor :)

eu chego até aqui

[2014/01/25 04:08:33 GMT] [INFO](lime/backend/sublime.sublime_Console:87) Python sez: Carregando plugin Vintageous.jump_list_cmds
[2014/01/25 04:08:33 GMT] [FNST](main.%28 tbfe%29.renderthread:375) Renderização[2014/01/25 04:08:33 GMT] [FNST](lime/backend.%28 commandHandler%29.Register:169) Deseja registrar vi_add_to_jump_list
[2014/01/25 04:08:33 GMT] [FNST](lime/backend.%28 commandHandler%29.Register:194) Comando registrado com sucesso vi_add_to_jump_list[2014/01/25 04:08:33 GMT] [INFO](lime/backend/sublime.sublime_Console:87) Python sez: Carregando plugin Vintageous.motion_cmds[2014/01/25 04:08:33 GMT] [FNST](main.%28 tbfe%29.renderthread:375) Renderização
[2014/01/25 04:08:33 GMT] [FNST](lime/backend.%28*commandHandler%29.Register:169) Deseja registrar irreversible_text

Mesmo aqui:
http://pastebin.com/G2yNjmdp

Ok Bem, vou tentar fazer com que o alexey mescle meu pacote go e o pacote compartilhado onig.
Dessa forma, todos podem estar na mesma página em termos de construção.
Aqui está um guia para construir do início ao fim engenharia reversa do cmakelists.txt ;)

https://gist.github.com/martell/c178f674188cb779b8fd

Muito obrigado. Isso definitivamente ajuda muito. Você também tentou uma compilação de 64 bits?

Eu não, mas deve ser o mesmo.
Atualmente fazendo um script onde você pode escolher qual construir :D

OK, fixe. Você poderia me dizer a diferença entre os downloads base msys2 e msys64 no sourceforge?

Eu trabalho com Martell e Alexey Pavlov no MSYS2; pensei em passar por aqui e dizer "oi".

Alguns desses detalhes Martell já mencionou, mas eu também posso juntar tudo.

msys64 era um nome WIP, agora é apenas MSYS2.

Os únicos documentos (além da maioria das coisas pacman/makepkg do Arch Linux) estão em:
http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/

Existem 3 repositórios de pacotes, msys, mingw32 e mingw64.

As fontes do repositório estão em:
msys: https://github.com/Alexpux/MSYS2-packages
mingw32+mingw64: https://github.com/Alexpux/MINGW-packages

Eu co-mantenho os pacotes e patches do Python MinGW-w64 (dos quais existem muitos, infelizmente), então sinta-se à vontade para fazer qualquer pergunta que tiver e, como Martell disse, passe por # msys2 no OFTC se quiser conversar.

Desculpe por não responder. Github nunca me deu uma notificação :/
Obrigado por esclarecer isso Ray.
Você sabe mais sobre msys2 e mingw64 do que eu, então é melhor você explicar :)

OK eu vejo. Obrigado por isso caras.
Para mim, o msys2 é um dos projetos mais valiosos. Especialmente ter pacman é incrível.

Obrigado pelas suas amáveis ​​palavras. Junte-se a nós, adicione pacotes e compartilhe a bondade ;-)

EdVanDance, oi!
MSYS2 tem versões de 32 e 64 bits. É por isso que existem dois tipos de arquivos para download.

OK. Portanto, msys2 é provavelmente 32 bits e msys64 64 bits. :sorrir:

Edit: Não importa, existem diretórios separados para 32 e 64 bits. Todos os pacotes recentes são nomeados msys2 com um
sufixo para 32 bits (i686) e 64 bits (x86_64).

Aqui está o MSYS2 de 32 bits:
http://sourceforge.net/projects/msys2/files/Base/i686/

E aqui 64 bits:
http://sourceforge.net/projects/msys2/files/Base/x86_64/

Sim, acabei de perceber isso. Da próxima vez eu deveria dar uma olhada antes de escrever e não o contrário :smile:

Eu costumo ficar em C:\msys64 e tenho os pacotes mingw32 e mingw64 em
lá em C:\msys64\mingw32 e C:\msys64\mingw64; pacman lida com isso para
você embora assim não se preocupe com isso.

Em terça-feira, 28 de janeiro de 2014 às 16h30, EdVanDance [email protected] escreveu:

Sim, acabei de perceber isso. Da próxima vez eu deveria dar uma olhada antes de escrever não
ao contrário [imagem: :smile:]

Responda a este e-mail diretamente ou visualize-o no Gi tHubhttps://github.com/limetext/lime/issues/228#issuecomment -33495293
.

Agora que as fontes são go get -able em x86/x64 linux/darwin, estou presumindo que pode haver mudanças necessárias aqui também.

Existe um guia ou esboço das etapas necessárias para instalar tudo em um novo sistema Windows que ainda não tenha sido instalado ou qualquer outra coisa já instalada?

https://github.com/limetext/lime/wiki/Building-on-Windows certamente precisa de uma atualização/reescrita...

Vou cuidar disso em breve.

Os recursos do Python são necessários para um Lime em funcionamento? Eu tentei comentar a importação de gopy & sublime (e três linhas que dependem disso) em frontend/html e frontend/termbox, e também substituí import de rubex por import (rubex "regexp") ; ambos html e termbox construídos e executados no Windows, mas estranhamente, de maneira inutilizável:

• html teve problemas para interpretar chaves (símbolos estranhos como "&" e outros apareceram no Firefox e no Chromium)
• termbox não mostrou o cursor, e a metade inferior da tela foi estranhamente deslocada e rolando rapidamente para baixo a cada pressionamento de tecla

alguma ideia? :)

Sobre o termbox você pode obter informações do arquivo de log que é criado com cada compilação e você deve saber que temos um plugin vintage que fornece alguns recursos do vim, então você deve pressionar i primeiro e começar a digitar.

@zoli , não conseguimos construir por um bom tempo, pois o msys atualizou o mingw python para 3.4, que gopy and go 1.3.1 acabou de ser corrigido.

Agora que os problemas do python3.4 foram resolvidos, estou usando o msys2 e o mingw-64 e vou construir o texto do lime.

Aqui está o meu erro atual

$ go get github.com/limetext/lime/frontend/termbox # github.com/limetext/gopy/lib ..\..\..\mingw64\src\github.com\limetext\gopy\lib\utils.c: In function 'cinit': ..\..\..\mingw64\src\github.com\limetext\gopy\lib\utils.c:503:11: error: 'sigaltstack' undeclared (first use in this function) stub(&sigaltstack); ^ ..\..\..\mingw64\src\github.com\limetext\gopy\lib\utils.c:503:11: note: each undeclared identifier is reported only once for each function it appears in ..\..\..\mingw64\src\github.com\limetext\gopy\lib\utils.c:504:11: error: 'signal' undeclared (first use in this function) stub(&signal); ^ ..\..\..\mingw64\src\github.com\limetext\gopy\lib\utils.c:505:11: error: 'sigaction' undeclared (first use in this function) stub(&sigaction);

Parece que este commit quebra o gopy no windows
https://github.com/limetext/gopy/commit/8b1545fdde22aad006ba8596dd7e9ad80ff0dec7

Quer apoiar esta questão? Coloque uma recompensa nele! Aceitamos recompensas via Bountysource .

Se eu comentar, recebo esse erro
github.com/limetext/gopy/lib(.text): undefined: github.com/limetext/gopy/lib(/4292) github.com/limetext/gopy/lib(.text): undefined: github.com/limetext/gopy/lib(/6573) github.com/limetext/gopy/lib(.text): undefined: github.com/limetext/gopy/lib(/6545) github.com/limetext/gopy/lib(.text): undefined: github.com/limetext/gopy/lib(/6513) too many errors
@quarnster tem alguma ideia?

aqui está o guia de construção para construir limetext em msys2 no windows
https://gist.github.com/martell/8588075

um pacote go 1.3.3 chegará aos servidores amanhã, espero :)

cinit deve ser definido para windows ou algo assim, pois não é relevante lá. Em relação ao erro de vinculação, ele encontra a lib python corretamente?

Sim, ele encontra as bibliotecas corretamente.
O pkg-config está adicionando o diretório de inclusão /mingw64/include/python3.
Portanto, espero que também adicione a lib corretamente.
A mensagem de erro não ajuda muito :(
Estamos em território desconhecido, então tentarei forçar -lpython3
Poste novamente em breve

Ok, então aqui estão meus resultados.
pkg-config está encontrando a lib corretamente porque aqui está um teste em regex com e sem onig instalado

sem:
$ go test github.com/limetext/rubex testmain github.com/limetext/rubex(.text): undefined: onig_free github.com/limetext/rubex(.text): undefined: onig_number_of_captures github.com/limetext/rubex(.text): undefined: onig_number_of_names github.com/limetext/rubex(.text): undefined: onig_region_free github.com/limetext/rubex(.text): undefined: github.com/limetext/rubex(/63) github.com/limetext/rubex(.text): undefined: onig_region_new github.com/limetext/rubex(.text): undefined: github.com/limetext/rubex(/30) github.com/limetext/rubex(.text): undefined: onig_new github.com/limetext/rubex(.text): undefined: onig_error_code_to_str github.com/limetext/rubex(.text): undefined: onig_search github.com/limetext/rubex(.text): undefined: onig_error_code_to_str github.com/limetext/rubex(.text): undefined: onig_match github.com/limetext/rubex(.text): undefined: onig_name_to_backref_number github.com/limetext/rubex(.text): undefined: onig_foreach_name FAIL github.com/limetext/rubex [build failed]

com:
$ go test github.com/limetext/rubex testmain github.com/limetext/rubex(.text): undefined: github.com/limetext/rubex(/63) github.com/limetext/rubex(.text): undefined: github.com/limetext/rubex(/30) FAIL github.com/limetext/rubex [build failed]

Editar: parece que 32 bits no Windows imprime um erro mais significativo

$ go get github.com/limetext/lime/frontend/termbox github.com/limetext/lime/frontend/termbox github.com/limetext/gopy/lib(.text): undefined: _get_output_format github.com/limetext/gopy/lib(.text): undefined: ___lc_codepage_func github.com/limetext/gopy/lib(.text): undefined: ___lc_codepage_func github.com/limetext/gopy/lib(.text): undefined: ___lc_codepage_func github.com/limetext/gopy/lib(.text): undefined: ___lc_codepage_func github.com/limetext/gopy/lib(.text): undefined: ___lc_codepage_func

para resolver esse erro de link, devo vincular ao tempo de execução do visual studio, infelizmente, tenho que escolher um tempo de execução do c++ também como v110 ou v110, o que é irritante para um aplicativo mingw-w64.

ok, então agora eu posso realmente construir :)
Espero ter um exe em breve

EDIT: Eu posso construir o termbox, mas

qml front-end me dá isso
Veja o mesmo erro acima em 25 de janeiro

$ vai construir
github.com/limetext/lime/frontend/qml
C:/msys64/mingw32/pkg/windows_386/gopkg.in/qml.v1.a(_all.o): referência de símbolo duplicada: mingw_onexit em github.com/limetext/gopy/lib(.text) e gopkg.in /qml%2ev1(.texto)

Aqui está minha saída do termbox:

Parece um pouco melhor do que há alguns meses, mas ainda trava

[2014/10/19 11:32:41 BST] [FNST] (github.com/limetext/lime/backend.(*WindowEvent).Call:94) OnNewWindow(2)
[2014/10/19 11:32:41 BST] [FNST] (github.com/limetext/lime/backend.(*ViewEvent).Call:60) OnNew(4)
[2014/10/19 11:32:41 BST] [FNST] (github.com/limetext/lime/backend.(*ViewEvent).Call:60) OnActivated(4)
[2014/10/19 11:32:41 BST] [EROR] (main.setColorMode:614) Unable to use 256 color mode: SetColorMode not implemented on Windows
[2014/10/19 11:32:41 BST] [EROR] (github.com/limetext/lime/backend/packages.func·001:98) Error on walking: GetFileAttributesEx ../../3rdparty/bundles/User: The system cannot find the file specified.
[2014/10/19 11:32:41 BST] [EROR] (github.com/limetext/lime/backend/packages.ScanPackets:110) Can't walk: GetFileAttributesEx ../../3rdparty/bundles/User: The system cannot find the file specified.
[2014/10/19 11:32:41 BST] [INFO] (github.com/limetext/lime/backend.(*Editor).loadKeyBinding:183) Loaded ..\..\packages\Default\Default (OSX).sublime-keymap
[2014/10/19 11:32:41 BST] [FNST] (github.com/limetext/lime/backend.(*Editor).Watch:414) Watch(&{0x12760400})
[2014/10/19 11:32:41 BST] [INFO] (github.com/limetext/lime/backend.(*Editor).loadKeyBinding:183) Loaded ..\..\packages\Default\Default.sublime-keymap
[2014/10/19 11:32:41 BST] [FNST] (github.com/limetext/lime/backend.(*Editor).Watch:414) Watch(&{0x12760420})
[2014/10/19 11:32:41 BST] [INFO] (github.com/limetext/lime/backend.(*Editor).loadKeyBinding:183) Loaded ..\..\packages\Default\Default (OSX).sublime-keymap
[2014/10/19 11:32:41 BST] [FNST] (github.com/limetext/lime/backend.(*Editor).Watch:414) Watch(&{0x127ce180})
[2014/10/19 11:32:41 BST] [INFO] (github.com/limetext/lime/backend.(*Editor).loadKeyBinding:183) Loaded ..\..\packages\Default\Default.sublime-keymap
[2014/10/19 11:32:41 BST] [FNST] (github.com/limetext/lime/backend.(*Editor).Watch:414) Watch(&{0x127ce1a0})
[2014/10/19 11:32:41 BST] [INFO] (github.com/limetext/lime/backend.(*Editor).loadSetting:199) Loaded ../../packages/Default/Preferences.sublime-settings
[2014/10/19 11:32:41 BST] [FNST] (github.com/limetext/lime/backend.(*Editor).Watch:414) Watch(&{0x127e83b0})
[2014/10/19 11:32:41 BST] [INFO] (github.com/limetext/lime/backend.(*Editor).loadSetting:199) Loaded ../../packages/Default/Preferences (Windows).sublime-settings
[2014/10/19 11:32:41 BST] [FNST] (github.com/limetext/lime/backend.(*Editor).Watch:414) Watch(&{0x127d2270})
[2014/10/19 11:32:41 BST] [EROR] (github.com/limetext/lime/backend/packages.(*Packet).Get:47) Couldn't read file: open ../../3rdparty/bundles/User/Preferences.sublime-settings: The system cannot find the path specified.
[2014/10/19 11:32:41 BST] [EROR] (github.com/limetext/lime/backend.(*Editor).loadSetting:197) 1,1: Unexpected EOF, 0-0: "JSON" - Data: ""

[2014/10/19 11:32:41 BST] [FNST] (main.(*tbfe).renderthread:437) Rendering
[2014/10/19 11:32:41 BST] [FNST] (main.(*tbfe).renderthread:437) Rendering
[2014/10/19 11:32:41 BST] [FNST] (main.(*tbfe).renderthread:437) Rendering

Bom trabalho! Qual é o backtrace para o acidente?

Se você iniciá-lo com "./termbox main.go", ele tenta exibir este arquivo corretamente?

Se você comentar a importação + chamadas gopy, ainda falha? Caso contrário, pode ser um dos problemas padrão do Go mingw .

@quarnster : não tenho ideia sobre o rastreamento de volta :(
Eu não entendo o go lang bem o suficiente.
Como faço para depurá-lo?

Eu não consigo ver a saída aqui é o log embora

[2014/10/19 15:26:09 BST] [FNST] (github.com/limetext/lime/backend.(*WindowEvent).Call:94) OnNewWindow(2)
[2014/10/19 15:26:09 BST] [FNST] (github.com/limetext/lime/backend.(*ViewEvent).Call:60) OnNew(4)
[2014/10/19 15:26:09 BST] [FNST] (github.com/limetext/lime/backend.(*ViewEvent).Call:60) OnActivated(4)
[2014/10/19 15:26:09 BST] [FNST] (github.com/limetext/lime/backend.(*ViewEvent).Call:60) OnModified(4)
[2014/10/19 15:26:09 BST] [FNST] (github.com/limetext/lime/backend.(*ViewEvent).Call:60) OnSelectionModified(4)
[2014/10/19 15:26:09 BST] [FNST] (github.com/limetext/lime/backend.(*ViewEvent).Call:60) OnLoad(4)
[2014/10/19 15:26:09 BST] [FNST] (github.com/limetext/lime/backend.(*Editor).Watch:414) Watch(C:\msys64\mingw32\src\github.com\limetext\lime\frontend\termbox\main.go (4))
[2014/10/19 15:26:09 BST] [FNST] (github.com/limetext/lime/backend.(*ViewEvent).Call:60) OnDeactivated(4)
[2014/10/19 15:26:09 BST] [FNST] (github.com/limetext/lime/backend.(*ViewEvent).Call:60) OnActivated(4)

Vou tentar remover as importações gopy e ver

@martell , o Backtrace deve ser despejado no terminal normalmente, exceto que neste caso estamos sequestrando o terminal para renderizar alguma interface do usuário para que não funcione;)

Tente este patch e veja se você obtém algo útil no log:

diff --git a/frontend/termbox/main.go b/frontend/termbox/main.go
index 4ff2426..bdecd51 100644
--- a/frontend/termbox/main.go
+++ b/frontend/termbox/main.go
@@ -711,7 +711,9 @@ func main() {
                termbox.Close()
                log4go.Debug(util.Prof)
                if err := recover(); err != nil {
-                       log4go.Crash(err)
+                       log4go.Debug(err)
+                       log4go.Debug("%s", string(debug.Stack()))
+                       time.Sleep(time.Second) // TODO: see issue #260
                }
        }()

Este tópico pode ser redefinido para um novo problema com a atualização de status?

@techtonik Não precisa fechar :)
Vou tentar atualizar os pacotes que temos para ir e fazer alguns patches neles para ver onde estamos agora

Ok, então parece que atualmente ainda estamos no mesmo estágio em que parte da própria linguagem go não funciona corretamente no Windows.

Estou explorando 2 diferentes soluções possíveis para isso.
Ambos exigirão um pouco de tempo para testar.
Estarei de volta em cerca de uma semana com uma atualização

Semana é passado. Esta questão precisa ser reescrita com um breve resumo - por enquanto é impossível agir sobre ela dada toda a limitação da vida real e do tempo livre.

martell, qual parte da linguagem go não funciona corretamente no Windows? Também acho que você quer dizer a implementação em vez da linguagem em si?

Oi! Quais são as novidades sobre a portabilidade no Windows? Você tem algum progresso?

Eu não sei exatamente quais eram os problemas, mas o Lime-QML compila e funciona bem para mim no Windows. Aqui estão minhas instruções: https://github.com/ricochet1k/lime-qml/wiki/Building-on-Windows-using-MSYS2

O ano é 2017, o mês é junho, ou seja, 1250 dias se passaram desde que a emissão foi criada.
Err… Olá? Podemos finalmente tentar algum binário pré-compilado do Windows, por favor?

descobriram erros de vinculação com mingw64 e go lang e um patch
deve ser enviado para o mingw64-crt em breve para resolver o último link
erro de pygo e outro c ligado depende

me desinscrever disso

Aqui..