Vscode не находит бинарь

По крайней мере он так говорит

Бинарь в PATH

Интересно, такого вообще не бывает

Ну я хз, смотрел в сорцы всякие, враппер дергаю

Hie билдил как рекомендуют

Но нихуя не работает

Hie билдил как рекомендуют

Это каке-то неправильные рекомендации, бинарь hie лучше в $PATH не класть

А куда?

Что показывает вызов stack exec -- hie --version в каталоге проекта?

Показывает вот что: $ stack exec -- hie --version Version 0.2.0.0, Git revision c34c08eeced8173983601e98304258075f3057e1 (1459 commits) x86_64 ghc-8.2.2

А куда?

Просто билдить stack --stack-yaml stack-X.X.X.yaml build --copy-compiler-tools

Показывает вот что: $ stack exec -- hie --version Version 0.2.0.0, Git revision c34c08eeced8173983601e98304258075f3057e1 (1459 commits) x86_64 ghc-8.2.2

И все равно не видит MissingH?

Я делал make build

Неа.

Как в README

При этом tsack exec работает нормально.

Как в README

Ну они там хотят, чтобы собирали несколько бинарей hie-8.X, похоже, это не оч работает

При этом tsack exec работает нормально.

tsack?

stack

а, stack

Ну они там хотят, чтобы собирали несколько бинарей hie-8.X, похоже, это не оч работает

Там собирается несколько

И враппер есть

Который запускает нужный

А что я мог с батником напутать? Батник сам запускается из bash Нормально.

Который запускает нужный

Это типа самописный?

ВОт так выглядит запуск батника из bash $ D:/Bitmaps3/Telegram2.bat 2018-06-08 13:42:07.7656925 [ThreadId 3] - run entered for HIE(hie.EXE) Version 0.2.0.0, Git revision c34c08eeced8173983601e98304258075f3057e1 (1459 commits) x86_64 ghc-8.2.2 2018-06-08 13:42:07.7666926 [ThreadId 3] - Current directory:D:\haskell_1\hippo

Это типа самописный?

От авторов hie

А что я мог с батником напутать? Батник сам запускается из bash Нормально.

Посмотри каким-нибудь process explorer, что вообще происходит

От авторов hie

Ну, вот он, видимо и не работает

Ну, вот он, видимо и не работает

Попробую без него

hie не висит в процессах, если стартовать из Атома.

это все проблемы из-за держания нескольких hie для разных компиляторов?

я с этим вообще не стал связываться

hie не висит в процессах, если стартовать из Атома.

Ну значит а атома нжно спрашивать)

я с этим вообще не стал связываться

Руками каждый раз собираешь?

Путь к батнику вот так указан D:\Bitmaps3\Telegram2.bat

ну у меня есть некая рабочая версия компилятора и все проекты в основном под нее, которые с другой версией - ну что поделать - hie не будет с ними работать

С обратными слешами тоже не видит.

Удали остальные редакторы, learning emacs the hard way

В таких случаях я пользуюсь седом и катом

С обратными слешами тоже не видит.

Ну, у меня с "/" vscode все видит

С обратными слешами тоже не видит.

Там должно быть две настройки useCustomHieWrapper и useCustomHieWrapperPath

Обе стоят. И галка, и путь к батнику.

Что интересно - без батника hie запускается и сидит в трее...

Что интересно - без батника hie запускается и сидит в трее...

а что в батнике написано?

@stack exec -- hie %*

ну или если уж совсем никак без hie - можно же конкретный hie прописать в локальных для проекта настойках (в vscode по крайней мере)

попробуй просто --lsp вместо %*

ну или если уж совсем никак без hie - можно же конкретный hie прописать в локальных для проекта настойках (в vscode по крайней мере)

Ещё успеем откатиться, это как вариант.

Похоже, атом тоже не передает параметры

Можно выключить custom wrapper, и путь к батнику написать туда, где должен быть просто hie. Путь он видит правильно (меняю букву в пути - и не видит), запускает hie. Всё равно не видит MissingH.

Так без custom wrapper он запускает hie, который остался где-то в %PATH%

Я вместо hie вписал в первую строку, которая путь к hie, сразу наш батник.

Если туда вписать просто hie, он запустит из path. А так есть обоснованное предпоолжение, что он батник подхватывает.

Была же гипотеза, что он не видит батник. Так точно видит.

Щас попробую stack exec -- hie --lsp --debug -l /tmp/hie.log

Лог вот что говорит 2018-06-08 15:27:18.8346778 [ThreadId 3] - run entered for HIE(hie.EXE) Version 0.2.0.0, Git revision c34c08eeced8173983601e98304258075f3057e1 (1459 commits) x86_64 ghc-8.2.2 2018-06-08 15:27:18.8346778 [ThreadId 3] - Current directory:C:\Users\Hippo\AppData\Local\atom\app-1.27.2

совпадает с тем, что получается из bash. То есть stack запускает hie таки.

Внезапно появились подсказки под мышей, типа Char -> Char. Это что? Hoogla нет, висит balloon.

Думаю - а чего current directory Current directory:C:\Users\Hippo\AppData\Local\atom\app-1.27.2

а не директория проекта?..

та-ак... а у меня же билд идёт через Script, который запускает runhaskell... Атом-то не подсвечивает import Data.String.Utils уже давно...

https://news.ycombinator.com/item?id=17258680

Прекрасный тред. > I was once called "too academic" for using PHP's array_map function, by someone who thought it was perfectly reasonable to have a class called ServiceControllerServiceProvider...

Так без custom wrapper он запускает hie, который остался где-то в %PATH%

Скрипт запускает билд так - в path должны быть runhaskell/ghc...

Кажется, остался последний шаг...

когда там уже лтс с 8.4.3? а то без бинарного кэша переходить стрёмно

$ runhaskell D:/Haskell_1/hippo/src/Main.hs вот эта фигня говорит, что не видит MissingH. Понятно, конь-текста нет...

?-текста

?-текста

?-спиролог

Похоже, туда надо впихнуть $ stack build $ stack exec

?-текста

Хаск-?

Хаск-?

??ия Hask

??ия Hask

Не распарсил... ?

Не распарсил... ?

Типа категория, созвучно

Катэ ладно ? Гор? ?

тигор...

Буква т дважды заюзал, не идеально)

Нужен смайл егор-а

КАтегория а не КОтегория

нужна Катя к Егору

Ну чо, заёл вроде.

Завёл.

Остались некоторые нюансы. Подскажите пожалуйста... [Command: stack D:\Haskell_1\hippo\src\Main.hs] stack: WARNING! Expecting stack options comment at line 1, column 1 stack: WARNING! Missing or unusable stack options specification stack: WARNING! Using runghc without any additional stack options "d" [Finished in 1.438s]

ЧТо надо стеку передавать, чтобы такого не было?

Ясно, что stack build --exec hippo

Но не получается...

Expecting stack options как бы говорит нам

надо начать файл с волшебного комментария -- stack --resolver=... script

если файл начинается с шебанга, то стэковый комментарий лучше писать после шебанга

https://twitter.com/phadej/status/1005096232438718467 хоть какая-то польза от вашего цурихака

Ага. Но мне так не нравится. Ясно, что надо передавать правильно сформированный запрос через Script, а оно не выходит.

Сейчас напишу автору на Гитхаб.

если файл начинается с шебанга, то стэковый комментарий лучше писать после шебанга

Там же проект есть, а получается, что мы дублируем указание резолвера в файле программы.

Там же проект есть, а получается, что мы дублируем указание резолвера в файле программы.

stack-script и проект — разные вещи, не надо их смешивать