Lime: Assistance Windows [30 $]

Wow ça a l'air fantastique.

martell [email protected] schrieb :

salut @quarnster ,

Je vais prendre en charge la tâche du port Windows.
Je devrais le faire assez rapidement.

J'ai découvert des erreurs de liaison avec mingw64 et go lang et un patch
devrait être poussé dans le mingw64-crt bientôt pour résoudre le dernier lien
erreur de pygo et autre c lié dépend.

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/limetext/lime/issues/228

Merci!

"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
PASSE
ok citron vert/tiers/libs/gopy 2.592s

Grand succès :)

Waouh, c'est génial !

que dois-je faire après gopy? Le guide a été modifié il y a quelque temps car cmake a été ajouté.
J'ai aussi construit les fixations qt5 :)

J'ai déjà construit onig dans gcc et évidemment python3.3 avec .a libs

EDIT : C'est bon, je vais simplement suivre manuellement les étapes dans les cmakelists :)

Ce serait bien si vous nous disiez comment reproduire la construction python.

J'utilise msys2 et pacman. mingw-w64-x86_64-python3 est un package pour cela.
Nous sommes généralement sur irc sur OFTC # msys2 ajouté de nouveaux packages quotidiennement :)
Vous pouvez le récupérer ici
http://sourceforge.net/projects/msys2/

J'ai récemment ajouté go lui-même, mais nous sommes en train de résoudre les problèmes avec.
Quand la chaux sera terminée, je l'ajouterai en tant que package et le script PKGBUILD pour le construire ;)
python et onig devraient être ici https://github.com/martell/MINGW-packages

Je suis aussi sur msys2. J'ai joué hier avec. Comment avez-vous généré la bibliothèque python statique ? Avez-vous utilisé une chaîne d'outils 32 bits ou 64 bits, allez-y?

Le correctif crt mentionné est-il déjà en ligne ?

https://github.com/martell/MINGW-packages
Python PKGBUILD est dans ce dépôt
Oui Alexey l'a appliqué à la main. Moi-même et mingwandroid essayons de réparer le passage CFLAG de go pour mingw64
Après ça devrait être bon d'y aller :) ... j'espère

Juste "pacman -Syu" pour mettre à jour le crt

Mais python3 est construit en tant que bibliothèque partagée par défaut, n'est-ce pas ? Avec mingw (pas w64), ils ont utilisé pexports. Comment as-tu géré ça? Qu'est-ce qui ne va pas avec le CFLAGS ?

Python3 est compilé avec mingw64, nous n'avons donc pas besoin de faire les exportations.
Nous obtenons le libpython3.3m.a par défaut en conséquence
https://github.com/martell/MINGW-packages/tree/master/mingw-w64-python3

Nous n'utilisons Visual Studio pour rien. Nous ne comptons pas non plus sur les constructions de studio visuel de n'importe quelle bibliothèque

L'équivalent de pexports serait gendef. Nous n'en avons pas besoin ici cependant
http://sourceforge.net/apps/trac/mingw-w64/wiki/gendef

Bon, j'ai réussi à construire l'interface termbox avec mingw64.
Il se ferme gracieusement avec ce message dans le debug.log
[2014/01/25 00:47:11 GMT] ERREUR (main.main:607) Le descripteur n'est pas valide.

La construction qml me donne cette erreur après avoir configuré les liaisons.
Deux liaisons dans un même projet doivent causer des problèmes.
chaux/interface/qml
C:\msys64\tmp\go-build680373563/lime/3rdparty/libs/gopy/lib.a(_all.o) : référence de symbole en double : mingw_onexit dans github.com/niemeyer/qml(.text) et lime/3rdparty /libs/gopy/lib(.text)

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

J'ai construit avec succès la termbox, html et je suis revenu dans le qt5 main.go car le qml ne serait pas lié

Termbox semble le meilleur jusqu'à présent.
Je passe par le chargement de tous les plugins puis plante :/
Joli fichier journal cependant ;)

regardez dans build/bin pour les exe et ne les déplacez pas car ils sont pertinents pour la structure des dossiers

@martell : avez-vous essayé d'exécuter l'interface termbox à partir de l'invite de commande Windows au lieu de mintty ?

@EdVanDance
Oui, j'exécute termbox à partir du cmd.prompt de Windows
Il semble qu'avec un peu plus de travail, cela puisse être résolu.
Nous devons également supprimer setcolormode 256 sur Windows car nous n'avons pas cette fonction

@martell Je n'arrive pas à le faire fonctionner. J'ai installé i686 python3 (je suis sur x86_64). J'ai ouvert une cmd :

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

Et j'obtiens :

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.

Vous ne devriez pas avoir à définir PYTHONHOME car j'ai inclus les dll python
Cela fonctionne pour moi sans cela.

Maintenant, je me trompe peut-être, mais je ne l'ai pas fait de toute façon.

Le patch a été fusionné dans le mingw64-crt et alexey fera bientôt une mise à jour ;)

Si je ne mets pas le PYTHONPATH. Je reçois:

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.

Démarrez-vous l'invite de commande à partir de msys ? Je l'ai démarré directement via Win+R .

Non, je suis allé directement à cmd comme vous l'avez fait, PYTHONHOME n'est pas défini sur mon système.
Je pense que j'ai déjà installé python sur mon système avec le programme d'installation de Windows,
c'est peut-être pourquoi mes fenêtres cmd ne se plaignent pas?

Cela pourrait expliquer pourquoi il se bloque également à un certain moment, peut-être que j'utilise les mauvais fichiers python

Avez-vous installé mingw python3 ou msys2 python3, ils sont très différents

Hum ça pourrait être la raison. Mais je ne comprends pas pourquoi il se plaint après avoir configuré le PYTHONPATH.
Il y a définitivement un module d'encodage.

J'ai compris.
C'est juste:

set PYTHONHOME=...\msys64\mingw32

Sans lib\python3.3 .

Sympa ;) et ta sortie ?

Affiche le contenu du fichier, mais ne réagit pas aux pressions sur les touches. Et se plaint du mode 256 couleurs.

Dans le zip que j'ai téléchargé, j'ai tous mes fichiers cgo.go pour référence si vous voulez construire à partir de la source ;)
J'ai également un paquet sur mon repo mingw-packages pour onig and go dont vous aurez besoin.

Pouvez-vous le coller s'il vous plaît :)

J'arrive jusqu'ici

[2014/01/25 04:08:33 GMT] [INFO](lime/backend/sublime.sublime_Console:87) Python sez : Chargement du plugin Vintageous.jump_list_cmds
[2014/01/25 04:08:33 GMT] [FNST](main.%28 tbfe%29.renderthread:375) Rendu[2014/01/25 04:08:33 GMT] [FNST](lime/backend.%28 commandHandler%29.Register:169) Vous souhaitez enregistrer vi_add_to_jump_list
[2014/01/25 04:08:33 GMT] [FNST](lime/backend.%28 commandHandler%29.Register:194) Commande enregistrée avec succès vi_add_to_jump_list[2014/01/25 04:08:33 GMT] [INFO](lime/backend/sublime.sublime_Console:87) Python sez : Chargement du plugin Vintageous.motion_cmds[2014/01/25 04:08:33 GMT] [FNST](main.%28 tbfe%29.renderthread:375) Rendu
[2014/01/25 04:08:33 GMT] [FNST](lime/backend.%28*commandHandler%29.Register:169) Vous souhaitez enregistrer irreversible_text

Pareil ici:
http://pastebin.com/G2yNjmdp

Bon, je vais essayer de demander à Alexey de fusionner mon package go et mon package partagé onig.
De cette façon, tout le monde peut être sur la même page en termes de construction.
Voici un guide pour construire du début à la fin la rétro-ingénierie à partir du cmakelists.txt ;)

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

Merci beaucoup. Cela aide certainement beaucoup. Avez-vous également essayé une version 64 bits?

Je ne l'ai pas fait mais ça devrait être pareil.
Je suis en train de créer un script où vous pouvez choisir lequel construire :D

OK bien. Pourriez-vous me dire la différence entre les téléchargements de base msys2 et msys64 sur sourceforge ?

Je travaille avec Martell et Alexey Pavlov sur MSYS2 ; J'ai pensé passer et dire "salut".

Certains de ces détails que Martell a déjà mentionnés, mais je peux tout aussi bien les rassembler.

msys64 était un nom WIP, c'est juste MSYS2 maintenant.

Les seuls documents (à part la plupart des trucs pacman/makepkg d'Arch Linux) sont à :
http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/

Il existe 3 référentiels de packages, msys, mingw32 et mingw64.

Les sources du référentiel sont à :
msys : https://github.com/Alexpux/MSYS2-packages
mingw32+mingw64 : https://github.com/Alexpux/MINGW-packages

Je co-maintient les packages et les correctifs Python MinGW-w64 (dont il y en a trop malheureusement) alors n'hésitez pas à poser toutes vos questions et comme l'a dit Martell, passez par # msys2 sur OFTC si vous voulez discuter.

Désolé de ne pas avoir répondu. Github ne m'a jamais donné de notification :/
Merci d'avoir éclairci Ray.
Vous en savez plus sur msys2 et mingw64 que moi donc il vaut mieux que vous expliquiez :)

OK je vois. Merci pour ça les gars.
Pour moi, msys2 est l'un des projets les plus précieux. Surtout avoir pacman est génial.

Merci pour vos mots gentils. Rejoignez-nous, ajoutez des packages et partagez le bien ;-)

EdVanDance, salut !
MSYS2 a des versions 32 et 64 bits. C'est pourquoi il existe deux types d'archives à télécharger.

D'accord. Donc msys2 est probablement 32 bits et msys64 64 bits. :le sourire:

Edit : tant pis, il existe des répertoires distincts pour 32 et 64 bits. Les packages récents sont tous nommés msys2 avec un
suffixe pour 32 bits (i686) et 64 bits (x86_64).

Voici MSYS2 32 bits :
http://sourceforge.net/projects/msys2/files/Base/i686/

Et ici 64 bits :
http://sourceforge.net/projects/msys2/files/Base/x86_64/

Ouais je viens de m'en rendre compte. La prochaine fois, je devrais jeter un œil avant d'écrire et non l'inverse :sourire:

J'ai tendance à m'en tenir à C:\msys64 et j'ai les packages mingw32 et mingw64 dans
là dans C:\msys64\mingw32 et C:\msys64\mingw64 ; pacman gère ça pour
vous si ne vous inquiétez pas à ce sujet.

Le mardi 28 janvier 2014 à 16h30, EdVanDance [email protected] a écrit :

Ouais je viens de m'en rendre compte. La prochaine fois je devrais jeter un oeil avant d'écrire non
l'inverse [image: :smile:]

Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/limetext/lime/issues/228#issuecomment -33495293
.

Maintenant que les sources sont go get -able sur x86/x64 linux/darwin, je suppose qu'il pourrait y avoir des changements nécessaires ici aussi.

Existe-t-il un guide ou un aperçu approximatif des étapes nécessaires pour tout installer sur un nouveau système Windows qui n'a pas déjà été installé ou quoi que ce soit d'autre déjà installé?

https://github.com/limetext/lime/wiki/Building-on-Windows a certainement besoin d'un rafraîchissement/réécriture...

Je m'en occuperai bientôt.

Les fonctionnalités Python sont-elles requises pour un Lime fonctionnel ? J'ai essayé de commenter l'importation de gopy & sublime (et trois lignes qui en dépendent) à la fois dans frontend/html et frontend/termbox, et j'ai également remplacé l'importation de rubex par import (rubex "regexp") ; à la fois html et termbox construits et exécutés sur Windows, mais bizarrement, de manière inutilisable :

• html avait des problèmes d'interprétation des clés (des symboles étranges comme "&" et d'autres apparaissaient à la fois dans Firefox et Chromium)
• termbox n'affichait pas le curseur, et la moitié inférieure de l'écran était étrangement décalée et défilait rapidement vers le bas à chaque pression de touche

des idées? :)

À propos de la termbox, vous pouvez obtenir des informations à partir du fichier journal créé avec chaque version et vous devez savoir que nous avons un plugin vintage qui donne certaines fonctionnalités vim, vous devez donc appuyer d'abord sur i , puis commencer à taper.

@zoli nous n'avons pas pu construire pendant un certain temps car msys a mis à jour mingw python à 3.4 que gopy and go 1.3.1 vient juste de corriger.

Maintenant que les problèmes de python3.4 ont été résolus, j'envisage d'utiliser msys2 et mingw-64 et de créer du texte lime.

Voici mon erreur actuelle

$ 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);

Il semble que ce commit casse Gopy sur Windows
https://github.com/limetext/gopy/commit/8b1545fdde22aad006ba8596dd7e9ad80ff0dec7

Vous voulez soutenir ce problème ? Placez une prime dessus ! Nous acceptons les primes via Bountysource .

Si je les commente, j'obtiens cette erreur
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 avez-vous des idées?

voici le guide de construction pour la construction de limetext dans msys2 sur windows
https://gist.github.com/martell/8588075

un package go 1.3.3 arrivera sur les serveurs demain, espérons-le :)

cinit devrait être ifdef-ed pour Windows ou quelque chose car ce n'est pas pertinent là-bas. En ce qui concerne l'erreur de liaison, trouve-t-il correctement la bibliothèque python ?

Oui, il trouve les bibliothèques correctement.
pkg-config ajoute le répertoire d'inclusion /mingw64/include/python3.
Je m'attends donc à ce qu'il ajoute également la bibliothèque correctement.
Le message d'erreur n'aide pas vraiment beaucoup :(
Nous sommes en territoire inconnu donc je vais essayer de forcer -lpython3
Publier bientôt

Bon alors voici mes résultats.
pkg-config trouve correctement la lib car voici un test sur regex avec et sans onig installé

sans pour autant:
$ 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]

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

Edit: semble que 32 bits continuent sur Windows imprime une erreur plus significative

$ 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

pour résoudre cette erreur de lien, je dois établir un lien avec le runtime Visual Studio, malheureusement, je dois choisir un runtime c++ également comme v110 ou v110, ce qui est ennuyeux pour une application mingw-w64.

ok alors maintenant je peux réellement construire :)
J'espère avoir un exe sous peu

EDIT : je peux créer la termbox mais

qml frontal me donne ceci
Voir la même erreur que ci-dessus le 25 janvier

$ aller construire
github.com/limetext/lime/frontend/qml
C:/msys64/mingw32/pkg/windows_386/gopkg.in/qml.v1.a(_all.o) : référence de symbole en double : mingw_onexit dans github.com/limetext/gopy/lib(.text) et gopkg.in /qml%2ev1(.text)

Voici ma sortie termbox:

Semble un peu mieux qu'il y a quelques mois, mais il plante toujours

[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

Bon travail! Quelle est la trace du crash ?

Si vous le lancez avec "./termbox main.go", essaie-t-il d'afficher correctement ce fichier ?

Si vous commentez les appels gopy import +, est-ce que ça plante toujours ? Si ce n'est pas le cas, il s'agit peut-être de l'un des problèmes standard de Go mingw .

@quarnster : Je n'ai aucune idée de la trace arrière :(
Je ne comprends pas assez bien go lang.
Comment puis-je même le déboguer?

Je ne vois pas la sortie ici est le journal cependant

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

Je vais essayer de supprimer les importations gopy et voir

@martell , Backtrace devrait être vidé sur le terminal normalement, sauf dans ce cas, nous détournons le terminal pour rendre une interface utilisateur afin que cela ne fonctionne pas ;)

Essayez ce correctif et voyez si vous obtenez quelque chose d'utile dans le journal :

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

Ce fil peut-il être réinitialisé dans un nouveau problème avec la mise à jour du statut ?

@techtonik Inutile de fermer :)
Je vais essayer de mettre à jour les packages que nous avons pour aller et faire quelques correctifs pour voir où nous en sommes maintenant

D'accord, il semble qu'actuellement nous en soyons encore au même stade où une partie du langage go lui-même ne fonctionne pas correctement sur Windows.

J'explore 2 différentes solutions possibles à cela.
Les deux nécessiteront un peu de temps pour tester.
Je serai de retour dans environ une semaine avec une mise à jour

La semaine est passée. Ce problème doit être réédité avec un bref résumé - pour l'instant, il est impossible d'agir à ce sujet compte tenu de toutes les limitations de la vie réelle et du temps libre.

martell, quelle partie du langage go ne fonctionne pas correctement sous windows ? Aussi, je pense que vous voulez dire l'implémentation go plutôt que le langage lui-même?

Salut! Quoi de neuf sur le portage sur windows ? Avez-vous des progrès?

Je ne sais pas exactement quels étaient les problèmes, mais Lime-QML se construit et fonctionne correctement pour moi sous Windows. Voici mes instructions : https://github.com/ricochet1k/lime-qml/wiki/Building-on-Windows-using-MSYS2

L'année est 2017, le mois est juin, soit 1250 jours se sont écoulés depuis la création du numéro.
Euh… Bonjour ? Pourrions-nous enfin essayer un binaire Windows pré-compilé, s'il vous plaît ?

ont découvert des erreurs de liaison avec mingw64 et go lang et un patch
devrait être poussé dans le mingw64-crt bientôt pour résoudre le dernier lien
erreur de pygo et autre c lié dépend

me désabonner de ça

Ici..