Ну, вот он, видимо и не работает
Попробую без него
a66ath
Хаскель
hie не висит в процессах, если стартовать из Атома.
A64m
это все проблемы из-за держания нескольких hie для разных компиляторов?
A64m
я с этим вообще не стал связываться
Хаскель
Путь к батнику вот так указан
D:\Bitmaps3\Telegram2.bat
A64m
ну у меня есть некая рабочая версия компилятора и все проекты в основном под нее, которые с другой версией - ну что поделать - hie не будет с ними работать
Хаскель
С обратными слешами тоже не видит.
Евгений
Удали остальные редакторы, learning emacs the hard way
В таких случаях я пользуюсь седом и катом
undefined
С обратными слешами тоже не видит.
Там должно быть две настройки
useCustomHieWrapper и useCustomHieWrapperPath
Хаскель
Обе стоят. И галка, и путь к батнику.
Хаскель
Что интересно - без батника hie запускается и сидит в трее...
Хаскель
@stack exec -- hie %*
A64m
ну или если уж совсем никак без hie - можно же конкретный hie прописать в локальных для проекта настойках (в vscode по крайней мере)
undefined
попробуй просто --lsp вместо %*
Хаскель
ну или если уж совсем никак без hie - можно же конкретный hie прописать в локальных для проекта настойках (в vscode по крайней мере)
Ещё успеем откатиться, это как вариант.
undefined
Похоже, атом тоже не передает параметры
Хаскель
Можно выключить custom wrapper, и путь к батнику написать туда, где должен быть просто hie. Путь он видит правильно (меняю букву в пути - и не видит), запускает hie. Всё равно не видит MissingH.
undefined
Так без 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...
Хаскель
Кажется, остался последний шаг...
Leonid 🦇
когда там уже лтс с 8.4.3? а то без бинарного кэша переходить стрёмно
Хаскель
$ runhaskell D:/Haskell_1/hippo/src/Main.hs
вот эта фигня говорит, что не видит MissingH. Понятно, конь-текста нет...
Leonid 🦇
🐴-текста
Хаскель
Похоже, туда надо впихнуть $ stack build
$ stack exec
Sr
Катэ ладно 🐈
Гор? 🐯
Ilya
тигор...
Sr
Буква т дважды заюзал, не идеально)
Крылатый
Нужен смайл егор-а
Andrew
КАтегория
а не КОтегория
Cheese
нужна Катя к Егору
Alexander
Хаскель
Ну чо, заёл вроде.
Хаскель
Завёл.
Хаскель
Остались некоторые нюансы. Подскажите пожалуйста...
[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
Хаскель
Но не получается...
Cheese
Expecting stack options как бы говорит нам
Cheese
надо начать файл с волшебного комментария
-- stack --resolver=... script
Cheese
если файл начинается с шебанга, то стэковый комментарий лучше писать после шебанга
Leonid 🦇
https://twitter.com/phadej/status/1005096232438718467 хоть какая-то польза от вашего цурихака
Хаскель
Ага. Но мне так не нравится. Ясно, что надо передавать правильно сформированный запрос через Script, а оно не выходит.
Хаскель
Сейчас напишу автору на Гитхаб.
Хаскель
если файл начинается с шебанга, то стэковый комментарий лучше писать после шебанга
Там же проект есть, а получается, что мы дублируем указание резолвера в файле программы.
Cheese
Там же проект есть, а получается, что мы дублируем указание резолвера в файле программы.
stack-script и проект — разные вещи, не надо их смешивать
Cheese
Остались некоторые нюансы. Подскажите пожалуйста...
[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-script, а не проект
Хаскель
Да не, Script это плагин к Атому, который запускает проги по шорткату.
Cheese
stack-script — это условно "весь проект в одном файле"
Cheese
Да не, Script это плагин к Атому, который запускает проги по шорткату.
а, тогда это не про Хаскель
Хаскель
Хаскель, как показывает мой опыт, это 95 процентов усилий по натягиванию системы и 5% чтения литерачи.
Dmitry
Виндопроблемы в целом
Dmitry
На линуксне и маке норм
Хаскель
У меня воркфлоу здоровое. Хачикелль заведётся на Маке, и тотчас упадут скрипты Фотошопа на Жабасрипте.
Leonid 🦇
у винды UX для разработчиков всегда был говно.
Хаскель
Как уже было.
Слава
Виндопроблемы в целом
Это не "виндопроблемы", а небрежность авторов. То им пробелы в именах не нравятся, то платформозависимый разделитель элементов использовать не с руки, то еще чего.
Слава
у винды UX для разработчиков всегда был говно.
MSDN в начале нулевых был недостижимым идеалом для прочих сред. Да и после, а SO еще не было.
Leonid 🦇
я никогда не мог найти в MSDN ничего кроме рекламы. хуже только доки к яве
Pavel
Dmitry
Это не "виндопроблемы", а небрежность авторов. То им пробелы в именах не нравятся, то платформозависимый разделитель элементов использовать не с руки, то еще чего.
Ну ноги растут из того, что когда то МС делал операционную систему, стараясь, что бы была максимально не похожа на юникс