Lime: Soporte de Windows [$30]

Vaya, eso suena fantástico.

Martell [email protected] Schrieb:

hola @quarnster ,

Voy a asumir la tarea del puerto de Windows.
Debería tenerlo hecho bastante pronto.

Descubrí errores de vinculación con mingw64 y go lang y un parche
debe insertarse en mingw64-crt pronto para resolver la última vinculación
el error de pygo y otros c enlazados depende.

---

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/limetext/lime/issues/228

¡Gracias!

"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\ prueba_gopy\principal.a"
$TRABAJO\lime\3rdparty\libs\gopy_test\gopy.test.exe
PASAR
ok lima/tercero/libs/gopy 2.592s

Gran éxito :)

¡Wow eso es impresionante!

que hago despues de gopy? La guía se cambió hace un tiempo porque se agregó cmake.
También construí los enlaces qt5 :)

Ya tengo onig build en gcc y obviamente python3.3 con .a libs

EDITAR: Está bien, solo seguiré los pasos en las cmakelists manualmente :)

Sería bueno si nos dijera cómo reproducir la compilación de python.

Estoy usando msys2 y pacman. mingw-w64-x86_64-python3 es un paquete para ello.
Por lo general, estamos en irc en OFTC #msys2 agregamos nuevos paquetes diariamente :)
Puedes recogerlo aquí
http://sourceforge.net/proyectos/msys2/

Recientemente agregué go, pero estamos resolviendo los problemas con él.
Cuando termine, lo agregaré como un paquete y el script PKGBUILD para construirlo;)
python y onig deberían estar aquí https://github.com/martell/MINGW-packages

También estoy en msys2. Ayer jugué con eso. ¿Cómo generaste la librería estática de python? ¿Usaste una cadena de herramientas de 32 o 64 bits?

¿La corrección crt mencionada ya está en línea?

https://github.com/martell/MINGW-paquetes
Python PKGBUILD está en este repositorio
Sí, alexey lo aplicó a mano. Mingwandroid y yo estamos tratando de arreglar el pase CFLAG de go para mingw64
Después de eso, debería estar listo :) ... con suerte

Simplemente "pacman -Syu" para actualizar el crt

Pero python3 está construido como una biblioteca compartida de forma predeterminada, ¿no es así? Con mingw (no w64) usaron pexports. ¿Cómo manejaste eso? ¿Qué tiene de malo el CFLAGS?

Python3 está compilado con mingw64, por lo que no necesitamos hacer las exportaciones.
Obtenemos libpython3.3m.a por defecto como resultado
https://github.com/martell/MINGW-packages/tree/master/mingw-w64-python3

No usamos Visual Studio para nada. Tampoco confiamos en las compilaciones de Visual Studio de ninguna biblioteca.

El equivalente a pexports sería gentilef. Aunque no lo necesitamos aquí
http://sourceforge.net/apps/trac/mingw-w64/wiki/gendef

De acuerdo, construí con éxito la interfaz de termbox con mingw64.
Se cierra con gracia con este mensaje en el debug.log
[2014/01/25 00:47:11 GMT] ERROR (main.main:607) El identificador no es válido.

La compilación qml me da este error después de configurar los enlaces.
Dos enlaces en un proyecto deben causar problemas.
lima/frontend/qml
C:\msys64\tmp\go-build680373563/lime/3rdparty/libs/gopy/lib.a(_all.o): referencia de símbolo duplicado: mingw_onexit en github.com/niemeyer/qml(.text) y lime/3rdparty /libs/gopy/lib(.texto)

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

He creado con éxito el termbox, html y volví a qt5 main.go ya que el qml no se vincularía

Termbox parece el mejor hasta ahora.
Paso por cargar todos los complementos y luego falla :/
Sin embargo, buen archivo de registro;)

busque en build/bin para los exe y no los mueva, ya que son relevantes para la estructura de carpetas

@martell : ¿intentó ejecutar la interfaz de termbox desde el símbolo del sistema de Windows en lugar de mintty?

@EdVanDance
Sí, estoy ejecutando termbox desde Windows cmd.prompt
Parece que con un poco más de trabajo, esto se puede resolver.
También necesitamos eliminar setcolormode 256 en Windows ya que no tenemos esa función

@martell No puedo hacer que se ejecute. Instalé i686 python3 (estoy en x86_64). Abrió un cmd:

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

Y obtengo:

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.

No debería tener que configurar PYTHONHOME ya que he incluido los dll de Python
Me funciona sin eso.

Ahora tal vez me equivoque, pero no hice eso de todos modos.

El parche se fusionó con mingw64-crt y alexey hará una actualización pronto;)

Si no configuro PYTHONPATH. Yo obtengo:

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.

¿Inicia el símbolo del sistema desde dentro de msys? Lo comencé directamente a través Win+R .

No, fui directamente a cmd como lo hiciste tú, PYTHONHOME no está definido en mi sistema.
Creo que previamente instalé python en mi sistema con el instalador de Windows,
¿tal vez por eso mi cmd windows no se queja?

Esto también podría explicar por qué falla en cierto punto, tal vez estoy usando los archivos de python incorrectos

Instalaste mingw python3 o msys2 python3 son muy diferentes

mmm esa puede ser la razon. Pero no entiendo por qué se queja después de configurar PYTHONPATH.
Definitivamente hay un módulo de codificaciones.

Lo tengo.
Es solo:

set PYTHONHOME=...\msys64\mingw32

Sin lib\python3.3 .

Niza;) y su salida?

Muestra el contenido del archivo, pero no reacciona al presionar las teclas. Y se queja del modo de 256 colores.

En el zip que cargué, tengo todos mis archivos cgo.go como referencia si desea compilar desde la fuente;)
También tengo un paquete en mi repositorio mingw-packages para onig and go que necesitará.

Puedes pegarlo por favor :)

llego hasta aquí

[2014/01/25 04:08:33 GMT] [INFO](lime/backend/sublime.sublime_Console:87) Python sez: cargando complemento Vintageous.jump_list_cmds
[2014/01/25 04:08:33 GMT] [FNST](main.%28 tbfe%29.renderthread:375) Representación[2014/01/25 04:08:33 GMT] [FNST](lime/backend.%28 commandHandler%29.Register:169) Quiero registrar vi_add_to_jump_list
[2014/01/25 04:08:33 GMT] [FNST](lime/backend.%28 commandHandler%29.Register:194) Comando registrado correctamente vi_add_to_jump_list[2014/01/25 04:08:33 GMT] [INFO](lime/backend/sublime.sublime_Console:87) Python sez: cargando complemento Vintageous.motion_cmds[2014/01/25 04:08:33 GMT] [FNST](main.%28 tbfe%29.renderthread:375) Representación
[2014/01/25 04:08:33 GMT] [FNST](lime/backend.%28*commandHandler%29.Register:169) Quiero registrar irreversible_text

Aquí igual:
http://pastebin.com/G2yNjmdp

De acuerdo, intentaré que alexey fusione mi paquete go y el paquete compartido onig.
De esa manera, todos pueden estar en la misma página en cuanto a construcción.
Aquí hay una guía para construir de principio a fin con ingeniería inversa a partir de cmakelists.txt;)

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

Muchas gracias. Eso definitivamente ayuda mucho. ¿También probaste una compilación de 64 bits?

No lo hice, pero debería ser lo mismo.
Actualmente estoy haciendo un script donde puedes elegir cuál construir :D

Ok, perfecto. ¿Podría decirme la diferencia entre las descargas base msys2 y msys64 en sourceforge?

Trabajo con Martell y Alexey Pavlov en MSYS2; Pensé en pasar y decir "hola".

Martell ya mencionó algunos de estos detalles, pero también puedo ponerlos todos juntos.

msys64 era un nombre WIP, ahora es solo MSYS2.

Los únicos documentos (aparte de la mayoría de las cosas de pacman/makepkg de Arch Linux) están en:
http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/

Hay 3 repositorios de paquetes, msys, mingw32 y mingw64.

Las fuentes del repositorio están en:
msys: https://github.com/Alexpux/MSYS2-packages
mingw32+mingw64: https://github.com/Alexpux/MINGW-packages

Co-mantengo los paquetes y parches de Python MinGW-w64 (de los cuales hay demasiados, lamentablemente), así que no dude en hacer cualquier pregunta que tenga y, como dijo Martell, visite #msys2 en OFTC si desea chatear.

Lo siento por no responder. Github nunca me dio una notificación :/
Gracias por aclarar eso Ray.
Sabes más sobre msys2 y mingw64 que yo, así que es mejor que lo expliques :)

OK veo. Gracias por eso chicos.
Para mí, msys2 es uno de los proyectos más valiosos. Especialmente tener pacman es increíble.

Gracias por tus amables palabras. Únase a nosotros, agregue paquetes y comparta la bondad ;-)

EdVanDance, hola!
MSYS2 tiene versiones de 32 y 64 bits. Es por eso que hay dos tipos de archivos para descargar.

Está bien. Entonces msys2 es probablemente de 32 bits y msys64 de 64 bits. :sonreír:

Editar: no importa, hay directorios separados para 32 y 64 bits. Todos los paquetes recientes se denominan msys2 con un
sufijo para 32 bits (i686) y 64 bits (x86_64).

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

Y aquí de 64 bits:
http://sourceforge.net/projects/msys2/files/Base/x86_64/

Sí, me acabo de dar cuenta de eso. La próxima vez debería echar un vistazo antes de escribir, no al revés :smile:

Tiendo a apegarme a C:\msys64 y tengo los paquetes mingw32 y mingw64 en
allí en C:\msys64\mingw32 y C:\msys64\mingw64; pacman maneja eso para
aunque no te preocupes por eso.

El martes 28 de enero de 2014 a las 4:30 p. m., EdVanDance [email protected] escribió:

Sí, me acabo de dar cuenta de eso. La próxima vez debería echar un vistazo antes de escribir no
al revés [imagen: :sonrisa:]

Responda a este correo electrónico directamente o véalo en Gi tHubhttps://github.com/limetext/lime/issues/228#issuecomment -33495293
.

Ahora que las fuentes son go get -capaces en x86/x64 linux/darwin, supongo que podría haber cambios necesarios aquí también.

¿Existe una guía o un resumen aproximado de los pasos necesarios para instalar todo en un nuevo sistema Windows que aún no tiene go o cualquier otra cosa instalada?

https://github.com/limetext/lime/wiki/Building-on-Windows ciertamente necesita una actualización/reescritura...

Me ocuparé de eso pronto.

¿Se requieren las funciones de Python para que Lime funcione? Intenté comentar la importación de gopy & sublime (y tres líneas que dependen de ella) tanto en frontend/html como en frontend/termbox, y también reemplacé la importación de rubex con import (rubex "regexp") ; tanto html como termbox creados y ejecutados en Windows, pero extrañamente, de manera inutilizable:

• html tenía problemas para interpretar las claves (símbolos extraños como "&" y otros aparecían tanto en Firefox como en Chromium)
• termbox no mostraba el cursor, y la mitad inferior de la pantalla se desplazaba de manera extraña y se desplazaba rápidamente hacia abajo con cada pulsación de tecla

¿algunas ideas? :)

Acerca del cuadro de términos, puede obtener información del archivo de registro que se crea con cada compilación y debe saber que tenemos un complemento antiguo que brinda algunas características de vim, por lo que debe presionar i primero y luego comenzar a escribir.

@zoli no pudimos compilar durante bastante tiempo, ya que msys actualizó mingw python a 3.4, que gopy and go 1.3.1 acaba de arreglar.

Ahora que los problemas de python3.4 se han resuelto, estoy considerando usar msys2 y mingw-64 y voy a compilar texto de cal.

Aquí está mi error actual

$ 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 compromiso rompe gopy en Windows
https://github.com/limetext/gopy/commit/8b1545fdde22aad006ba8596dd7e9ad80ff0dec7

¿Quieres respaldar este problema? ¡Pon una recompensa por ello! Aceptamos recompensas a través de Bountysource .

Si los comento me sale este error
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 ¿tienes alguna idea?

aquí está la guía de compilación para compilar limetext en msys2 en Windows
https://gist.github.com/martell/8588075

un paquete go 1.3.3 llegará a los servidores mañana con suerte :)

cinit debe estar definido para Windows o algo así, ya que no es relevante allí. Con respecto al error de vinculación, ¿encuentra correctamente la lib de python?

Sí, encuentra las bibliotecas correctamente.
pkg-config agrega el directorio de inclusión /mingw64/include/python3.
Así que espero que también agregue la lib correctamente.
El mensaje de error realmente no ayuda mucho :(
Estamos en un territorio desconocido, así que intentaré forzar -lpython3
Vuelva a publicar pronto

Bien, aquí están mis resultados.
pkg-config está encontrando la lib correctamente porque aquí hay una prueba en expresiones regulares con y sin onig instalado

sin:
$ 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]

con:
$ 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 en Windows imprime un error más 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 este error de enlace, debo vincular contra el tiempo de ejecución de Visual Studio, desafortunadamente tengo que elegir un tiempo de ejecución de C ++ también como v110 o v110, lo cual es molesto para una aplicación mingw-w64.

bien, ahora puedo construir :)
Espero tener un exe en breve

EDITAR: puedo construir el cuadro de términos pero

qml front-end me da esto
Ver el mismo error que el anterior el 25 de enero

$ ir a construir
github.com/limetext/lime/frontend/qml
C:/msys64/mingw32/pkg/windows_386/gopkg.in/qml.v1.a(_all.o): referencia de símbolo duplicado: mingw_onexit en github.com/limetext/gopy/lib(.text) y gopkg.in /qml%2ev1(.texto)

Aquí está mi salida de termbox:

Parece un poco mejor que hace unos meses, pero sigue fallando

[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

¡Buen trabajo! ¿Cuál es el rastro del accidente?

Si lo inicia con "./termbox main.go", ¿intenta mostrar este archivo correctamente?

Si comenta las llamadas gopy import +, ¿todavía falla? De lo contrario, podría ser uno de los problemas estándar de Go mingw .

@quarnster : no tengo idea sobre el rastro posterior :(
No entiendo go lang lo suficientemente bien.
¿Cómo lo depuro?

Aunque no puedo ver el resultado aquí es el registro

[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)

Intentaré eliminar las importaciones gopy y veré

@martell , Backtrace debería volcarse en la terminal normalmente, excepto que en este caso estamos secuestrando la terminal para mostrar algo de interfaz de usuario para que no funcione;)

Pruebe este parche y vea si obtiene algo útil en el registro:

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
                }
        }()

¿Se puede restablecer este hilo a un nuevo problema con la actualización de estado?

@techtonik No hay necesidad de cerrar :)
Intentaré actualizar los paquetes que tenemos para ir y haré algunos parches en ellos para ver cuál es nuestra posición ahora.

De acuerdo, parece que actualmente todavía estamos en la misma etapa en la que parte del lenguaje go no funciona correctamente en Windows.

Estoy explorando 2 posibles soluciones diferentes para esto.
Ambos requerirán un poco de tiempo para probar.
Volveré en aproximadamente una semana con una actualización.

Se pasa la semana. Este problema debe volver a emitirse con un breve resumen; por ahora, es imposible tomar medidas al respecto debido a todas las limitaciones de la vida real y el tiempo libre.

martell, ¿qué parte del lenguaje go no funciona correctamente en Windows? También creo que te refieres a la implementación de go en lugar del lenguaje en sí.

¡Hola! ¿Qué novedades hay sobre la portabilidad en Windows? ¿Tienes algún progreso?

No sé por completo cuáles eran los problemas, pero Lime-QML se compila y funciona bien para mí en Windows. Aquí están mis instrucciones: https://github.com/ricochet1k/lime-qml/wiki/Building-on-Windows-using-MSYS2

El año es 2017, el mes es junio, es decir, pasaron 1250 días desde que se creó la emisión.
Err… ¿Hola? ¿Podríamos probar algún binario de Windows precompilado por fin, por favor?

he descubierto errores de vinculación con mingw64 y go lang y un parche
debe insertarse en mingw64-crt pronto para resolver la última vinculación
error de pygo y otro c enlazado depende

darme de baja de esto

Aquí..