Lime: Windows-Support [$30]

Wow das klingt fantastisch.

martell [email protected] schrieb:

Hallo @quarnster ,

Ich werde die Aufgabe der Windows-Portierung übernehmen.
Ich sollte es ziemlich bald machen lassen.

Ich habe Verknüpfungsfehler mit mingw64 entdeckt und gehe lang und einen Patch
sollte bald in das mingw64-crt geschoben werden, um die letzte Verknüpfung aufzulösen
fehler von pygo und anderen c gebundenen hängt ab.

---

Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/limetext/lime/issues/228

Danke!

"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
PASSIEREN
ok lime/3rdparty/libs/gopy 2.592s

Großer Erfolg :)

Wow das ist großartig!

was mache ich nach gopy? Die Anleitung wurde vor einiger Zeit geändert, weil cmake hinzugefügt wurde.
Ich habe auch die qt5-Bindungen gebaut :)

Ich habe bereits einen Build in gcc und offensichtlich python3.3 mit .a libs

BEARBEITEN: Es ist in Ordnung, ich folge einfach den Schritten in den cmakelists manuell :)

Es wäre nett, wenn Sie uns sagen würden, wie wir den Python-Build reproduzieren können.

Ich verwende msys2 und Pacman. mingw-w64-x86_64-python3 ist ein Paket dafür.
Wir sind normalerweise im IRC auf OFTC #msys2, das täglich neue Pakete hinzufügt :)
Sie können es hier abholen
http://sourceforge.net/projects/msys2/

Ich habe kürzlich go selbst hinzugefügt, aber wir arbeiten an den Problemen damit.
Wenn Lime fertig ist, füge ich es als Paket und das PKGBUILD-Skript hinzu, um es zu bauen;)
Python und Onig sollten hier sein https://github.com/martell/MINGW-packages

Ich bin auch auf msys2. Ich habe gestern damit rumgespielt. Wie haben Sie die statische Python-Bibliothek generiert? Hast du eine 32-Bit- oder 64-Bit-Toolchain verwendet?

Ist der erwähnte crt-Fix bereits online?

https://github.com/martell/MINGW-Pakete
Python PKGBUILD befindet sich in diesem Repo
Ja, Alexey hat es von Hand aufgetragen. Ich selbst und mingwandroid versuchen, die CFLAG-Übergabe von go für mingw64 zu reparieren
Danach sollte es gut gehen :) ... hoffentlich

Einfach "pacman -Syu", um die crt zu aktualisieren

Aber python3 ist standardmäßig als Shared Lib erstellt, nicht wahr? Mit mingw (nicht w64) verwendeten sie pexports. Wie hast du das gehandhabt? Was ist los mit den CFLAGS?

Python3 wird mit mingw64 kompiliert, sodass wir die Exporte nicht durchführen müssen.
Als Ergebnis erhalten wir standardmäßig die libpython3.3m.a
https://github.com/martell/MINGW-packages/tree/master/mingw-w64-python3

Wir verwenden Visual Studio für nichts. Wir verlassen uns auch nicht auf visuelle Studio-Builds irgendeiner Bibliothek

Das Äquivalent zu pexports wäre gendef. Das brauchen wir hier aber nicht
http://sourceforge.net/apps/trac/mingw-w64/wiki/gendef

Okay, ich habe das Termbox-Frontend erfolgreich mit mingw64 erstellt.
Mit dieser Nachricht im debug.log wird es ordnungsgemäß geschlossen
[25.01.2014 00:47:11 GMT] FEHLER (main.main:607) Das Handle ist ungültig.

Der qml-Build gibt mir diesen Fehler nach dem Einrichten der Bindungen.
Zwei Bindungen in einem Projekt müssen Probleme verursachen.
lime/frontend/qml
C:\msys64\tmp\go-build680373563/lime/3rdparty/libs/gopy/lib.a(_all.o): doppelte Symbolreferenz: mingw_onexit sowohl in github.com/niemeyer/qml(.text) als auch in lime/3rdparty /libs/gopy/lib(.text)

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

Ich habe die termbox, html erfolgreich erstellt und bin in qt5 main.go zurückgefallen, da das qml nicht verlinkt werden konnte

Termbox scheint bisher das Beste zu sein.
Ich gehe durch das Laden aller Plugins und stürzt dann ab :/
Schöne Logdatei aber ;)

Suchen Sie in build/bin nach Exe-Dateien und verschieben Sie sie nicht, da sie für die Ordnerstruktur relevant sind

@martell : Haben Sie versucht, das Termbox-Frontend über die Windows-Eingabeaufforderung anstelle von Mintty auszuführen?

@EdVanDance
Ja, ich führe termbox über die Windows-cmd.prompt aus
Es scheint, als ob dies mit etwas mehr Arbeit behoben werden kann.
Außerdem müssen wir setcolormode 256 unter Windows entfernen, da wir diese Funktion nicht haben

@martell Ich kann es nicht zum Laufen bringen. Ich habe i686 python3 installiert (ich bin auf x86_64). Cmd geöffnet:

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

Und ich bekomme:

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.

Sie sollten PYTHONHOME nicht festlegen müssen, da ich die Python-DLLs eingeschlossen habe
Bei mir funktioniert es auch ohne.

Jetzt habe ich mich vielleicht geirrt, aber ich habe das sowieso nicht getan.

Der Patch wurde in das mingw64-crt eingebunden und Alexey wird bald ein Update machen ;)

Wenn ich den PYTHONPATH nicht setze. Ich bekomme:

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.

Starten Sie die Eingabeaufforderung in msys? Ich habe es direkt über Win+R gestartet.

Nein, ich bin wie Sie direkt zu cmd gegangen, PYTHONHOME ist auf meinem System nicht definiert.
Ich glaube, ich habe Python zuvor mit dem Windows-Installationsprogramm auf meinem System installiert.
Vielleicht beschwert sich deshalb mein cmd-Fenster nicht?

Dies könnte auch erklären, warum es an einem bestimmten Punkt abstürzt, vielleicht verwende ich die falschen Python-Dateien

Haben Sie mingw python3 oder msys2 python3 installiert, sie sind sehr unterschiedlich

Hm das könnte der Grund sein. Aber ich verstehe nicht, warum es sich nach dem Einrichten des PYTHONPATH beschwert.
Es gibt definitiv ein Codierungsmodul.

Ich habe es verstanden.
Es ist nur:

set PYTHONHOME=...\msys64\mingw32

Ohne lib\python3.3 .

Schön ;) und deine Ausgabe?

Zeigt den Dateiinhalt an, reagiert aber nicht auf Tastendruck. Und beschwert sich über den 256-Farbmodus.

In der von mir hochgeladenen Zip-Datei habe ich alle meine cgo.go-Dateien als Referenz, wenn Sie aus dem Quellcode erstellen möchten;)
Ich habe auch ein Paket in meinem Mingw-Packages-Repo für Onig und Go, das Sie benötigen werden.

Kannst du es bitte einfügen :)

Ich komme bis hierher

[25.01.2014 04:08:33 GMT] [INFO](lime/backend/sublime.sublime_Console:87) Python-Sez: Laden des Plugins Vintageous.jump_list_cmds
[25.01.2014 04:08:33 GMT] [FNST](main.%28 tbfe%29.renderthread:375) Rendern[25.01.2014 04:08:33 GMT] [FNST](lime/backend.%28 commandHandler%29.Register:169) Möchte vi_add_to_jump_list registrieren
[25.01.2014 04:08:33 GMT] [FNST](lime/backend.%28 commandHandler%29.Register:194) Erfolgreich registrierter Befehl vi_add_to_jump_list[25.01.2014 04:08:33 GMT] [INFO](lime/backend/sublime.sublime_Console:87) Python-Sez: Laden des Plugins Vintageous.motion_cmds[25.01.2014 04:08:33 GMT] [FNST](main.%28 tbfe%29.renderthread:375) Rendern
[25.01.2014 04:08:33 GMT] [FNST](lime/backend.%28*commandHandler%29.Register:169) Will irreversible_text registrieren

Hier gilt das gleiche:
http://pastebin.com/G2yNjmdp

Okay Nun, ich werde versuchen, Alexey dazu zu bringen, mein go-Paket und das gemeinsam genutzte Onig-Paket zusammenzuführen.
Auf diese Weise können sich alle auf der gleichen Seite befinden.
Hier ist eine Anleitung zum Erstellen von Anfang bis Ende durch Reverse Engineering aus der cmakelists.txt ;)

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

Vielen Dank. Das hilft auf jeden Fall sehr. Hast du auch einen 64bit Build probiert?

Ich nicht, aber es sollte das gleiche sein.
Erstellen Sie derzeit ein Skript, in dem Sie auswählen können, welches erstellt werden soll: D

OK gut. Können Sie mir den Unterschied zwischen den msys2- und msys64-Basisdownloads auf Sourceforge erklären?

Ich arbeite mit Martell und Alexey Pavlov an MSYS2; Ich dachte, ich komme vorbei und sage "Hallo".

Einige dieser Details hat Martell bereits erwähnt, aber ich kann sie genauso gut zusammenfassen.

msys64 war ein WIP-Name, jetzt ist es nur noch MSYS2.

Die einzigen Dokumente (abgesehen von den meisten pacman/makepkg-Zeugs von Arch Linux) sind unter:
http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/

Es gibt 3 Paket-Repositories, msys, mingw32 und mingw64.

Die Repository-Quellen befinden sich unter:
msys: https://github.com/Alexpux/MSYS2-packages
mingw32+mingw64: https://github.com/Alexpux/MINGW-packages

Ich betreue die MinGW-w64-Python-Pakete und -Patches (von denen es leider zu viele gibt) mit, also zögern Sie nicht, Ihre Fragen zu stellen, und wie Martell sagte, schauen Sie bei #msys2 auf OFTC vorbei, wenn Sie chatten möchten.

Tut mir leid, dass ich nicht geantwortet habe. Github hat mir nie eine Benachrichtigung gegeben :/
Danke, dass du das geklärt hast, Ray.
Du weißt mehr über msys2 und mingw64 als ich, also ist es besser, wenn du es erklärst :)

OK, ich verstehe. Danke dafür Jungs.
Für mich ist msys2 eines der wertvollsten Projekte. Besonders Pacman zu haben ist großartig.

Danke für deine netten Worte. Machen Sie mit, fügen Sie Pakete hinzu und teilen Sie die Güte ;-)

EdVanDance, hallo!
MSYS2 hat sowohl 32- als auch 64-Bit-Versionen. Aus diesem Grund gibt es zwei Arten von Archiven zum Herunterladen.

OK. Also msys2 ist wahrscheinlich 32-Bit und msys64 64-Bit. :Lächeln:

Bearbeiten: Egal, es gibt separate Verzeichnisse für 32 und 64 Bit. Die letzten Pakete heißen alle msys2 mit einem
Suffix für 32 Bit (i686) und 64 Bit (x86_64).

Hier ist 32-Bit-MSYS2:
http://sourceforge.net/projects/msys2/files/Base/i686/

Und hier 64-Bit:
http://sourceforge.net/projects/msys2/files/Base/x86_64/

Ja, das ist mir gerade aufgefallen. Nächstes Mal sollte ich erst schauen bevor ich schreibe und nicht umgekehrt :smile:

Ich neige dazu, mich an C:\msys64 zu halten und sowohl mingw32- als auch mingw64-Pakete zu haben
dort in C:\msys64\mingw32 und C:\msys64\mingw64; Pacman kümmert sich darum
Sie aber, also mach dir keine Sorgen.

Am Dienstag, den 28. Januar 2014 um 16:30 Uhr schrieb EdVanDance [email protected] :

Ja, das ist mir gerade aufgefallen. Das nächste Mal sollte ich vor dem Schreiben nicht nachsehen
umgekehrt [Bild: :smile:]

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHubhttps://github.com/limetext/lime/issues/228#issuecomment -33495293 an
.

Jetzt, da die Quellen auf x86/x64 Linux/Darwin go get -fähig sind, gehe ich davon aus, dass auch hier Änderungen erforderlich sein könnten.

Gibt es eine Anleitung oder einen groben Überblick über die Schritte, die erforderlich sind, um alles auf einem neuen Windows-System zu installieren, auf dem noch nicht go oder etwas anderes installiert ist?

https://github.com/limetext/lime/wiki/Building-on-Windows muss sicherlich aktualisiert/umgeschrieben werden...

Ich werde mich bald darum kümmern.

Sind die Python-Funktionen für einen funktionierenden Lime erforderlich? Ich habe versucht, import von gopy & sublime (und drei Zeilen, die davon abhängen) sowohl in frontend/html als auch in frontend/termbox auszukommentieren, und auch import von rubex durch import (rubex "regexp") ersetzt; Sowohl HTML als auch Termbox wurden unter Windows erstellt und ausgeführt, aber seltsamerweise auf unbrauchbare Weise:

• html hatte Probleme beim Interpretieren von Schlüsseln (seltsame Symbole wie "&" und andere tauchten sowohl in Firefox als auch in Chromium auf)
• termbox zeigte keinen Cursor und die untere Hälfte des Bildschirms war seltsam verschoben und scrollte bei jedem Tastendruck schnell nach unten

irgendwelche Ideen? :)

Über die Termbox können Sie Informationen aus der Protokolldatei abrufen, die mit jedem Build erstellt wird, und Sie sollten wissen, dass wir ein klassisches Plugin haben, das einige vim-Funktionen bietet, also sollten Sie zuerst i drücken und dann mit der Eingabe beginnen.

@zoli Wir konnten eine ganze Weile nicht bauen, da msys mingw python auf 3.4 aktualisiert hat, was gopy and go 1.3.1 gerade erst behoben hat.

Nachdem die Probleme mit Python 3.4 behoben wurden, schaue ich mir die Verwendung von msys2 und mingw-64 an und gehe zum Erstellen von Kalktext.

Hier mein aktueller Fehler

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

Es scheint, dass dieser Commit Gopy unter Windows bricht
https://github.com/limetext/gopy/commit/8b1545fdde22aad006ba8596dd7e9ad80ff0dec7

Möchten Sie dieses Problem unterstützen? Setzen Sie ein Kopfgeld darauf! Wir akzeptieren Prämien über Bountysource .

Wenn ich sie auskommentiere, bekomme ich diesen Fehler
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 hast du ideen?

Hier ist die Erstellungsanleitung zum Erstellen von Limetext in msys2 unter Windows
https://gist.github.com/martell/8588075

ein go 1.3.3 Paket wird hoffentlich morgen auf die Server kommen :)

cinit sollte für Windows oder ähnliches ifdef-ed werden, da es dort nicht relevant ist. Findet es in Bezug auf den Verknüpfungsfehler die Python-Bibliothek korrekt?

Ja, es findet die Bibliotheken richtig.
pkg-config fügt das Verzeichnis /mingw64/include/python3 hinzu.
Ich erwarte also, dass es auch die Bibliothek korrekt hinzufügt.
Die Fehlermeldung hilft nicht wirklich weiter :(
Wir befinden uns auf unbekanntem Gebiet, also werde ich versuchen, -lpython3 zu erzwingen
Poste bald wieder

Okay, hier sind meine Ergebnisse.
pkg-config findet die Bibliothek korrekt, da hier ein Test für Regex mit und ohne installiertem Onig ist

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

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

Bearbeiten: Scheint, dass 32-Bit unter Windows einen aussagekräftigeren Fehler ausgibt

$ 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

Um diesen Link-Fehler zu lösen, muss ich mit der Visual Studio-Laufzeit verknüpfen. Leider muss ich eine C++-Laufzeit wie v110 oder v110 auswählen, was für eine Mingw-W64-Anwendung ärgerlich ist.

Okay, jetzt kann ich tatsächlich bauen :)
Hoffentlich habe ich in Kürze eine Exe

EDIT: Ich kann die termbox aber bauen

qml Frontend gibt mir das
Siehe gleichen Fehler wie oben am 25. Januar

$ los bauen
github.com/limetext/lime/frontend/qml
C:/msys64/mingw32/pkg/windows_386/gopkg.in/qml.v1.a(_all.o): doppelte Symbolreferenz: mingw_onexit sowohl in github.com/limetext/gopy/lib(.text) als auch in gopkg.in /qml%2ev1(.text)

Hier ist meine Termbox-Ausgabe:

Scheint etwas besser zu sein als vor ein paar Monaten, aber es stürzt immer noch ab

[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

Gute Arbeit! Was ist der Hintergrund für den Absturz?

Wenn Sie es mit "./termbox main.go" starten, versucht es diese Datei korrekt anzuzeigen?

Wenn Sie die Aufrufe von gopy import + auskommentieren, stürzt es immer noch ab? Wenn nicht, könnte es sich um eines der Standardprobleme von Go mingw handeln .

@quarnster : Ich habe keine Ahnung von der Rückverfolgung :(
Ich verstehe go lang nicht gut genug.
Wie kann ich es überhaupt debuggen?

Ich bekomme die Ausgabe hier nicht zu sehen, aber das Protokoll

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

Ich werde versuchen, die Gopy-Importe zu entfernen und zu sehen

@martell , Backtrace sollte normalerweise auf das Terminal übertragen werden, außer in diesem Fall entführen wir das Terminal, um eine Benutzeroberfläche zu rendern, damit es nicht funktioniert;)

Probieren Sie diesen Patch aus und sehen Sie, ob Sie etwas Nützliches im Protokoll finden:

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

Kann dieser Thread in ein neues Problem mit Statusaktualisierung zurückgesetzt werden?

@techtonik Keine Notwendigkeit zu schließen :)
Ich werde versuchen, die Pakete, die wir für Go haben, zu aktualisieren und ein paar Patches darauf zu machen, um zu sehen, wo wir jetzt stehen

Okay, es scheint, dass wir uns derzeit noch in der gleichen Phase befinden, in der ein Teil der Go-Sprache selbst unter Windows nicht richtig funktioniert.

Ich untersuche 2 verschiedene mögliche Lösungen dafür.
Beide benötigen etwas Zeit zum Testen.
Ich melde mich in etwa einer Woche mit einem Update zurück

Woche ist vergangen. Dieses Problem muss mit einer kurzen Zusammenfassung neu bearbeitet werden - im Moment ist es angesichts der Einschränkungen des wirklichen Lebens und der Freizeit unmöglich, Maßnahmen zu ergreifen.

Martell, welcher Teil der Go-Sprache funktioniert unter Windows nicht richtig? Ich denke auch, Sie meinen eher die Go-Implementierung als die Sprache selbst?

Hallo! Was gibt es Neues zur Portierung auf Windows? Hast du Fortschritte?

Ich weiß nicht genau, was die Probleme früher waren, aber Lime-QML baut und läuft gut für mich unter Windows. Hier ist meine Anleitung: https://github.com/ricochet1k/lime-qml/wiki/Building-on-Windows-using-MSYS2

Das Jahr ist 2017, der Monat ist Juni, dh seit der Ausgabe sind 1250 Tage vergangen .
Äh … Hallo? Könnten wir bitte endlich eine vorkompilierte Windows-Binärdatei ausprobieren?

habe linkfehler bei mingw64 entdeckt und gehe lang und einen patch
sollte bald in das mingw64-crt geschoben werden, um die letzte Verknüpfung aufzulösen
fehler von pygo und anderen c gebundenen hängt ab

entbinde mich davon

Hier..