+1

Это похоже на настраиваемую конфигурацию, включающую conemu, clink и (необязательно) msysgit. Clink - это в основном строка чтения, которая нам больше не нужна. mintty может быть более легкой альтернативой conemu.

Да, думаю, дело в этом. Поскольку я сам не использую Windows, я несколько не осведомлен об этих инструментах, но мне было бы больше интересно убедиться, что работа будет максимально приятной, чем минимизировать размер зависимости. Mintty просто не выглядит так красиво, как cmder.

Я вполне доволен mintty, используемым Cygwin и MSYS2 (хотя все еще есть ошибка, из-за которой Julia не очень удобна в mintty, я должен проверить, правда ли это в conemu), я не вижу особой необходимости в вкладках консоли. В # 6795 есть обсуждение этих и других альтернатив.

Любые ошибки, которые происходят с тем, что мы выберем, будет сложнее правильно сообщить или исправить, если мы воспользуемся чем-то, что является вилкой-вилкой-вилкой (или оболочкой-оболочкой-оболочкой). Babun - еще один аналогичный из этих проектов, который выглядит блестяще, но на самом деле это просто настраиваемая версия Cygwin.

Вот безумный план вдохновителя. Давайте создадим внешний интерфейс для ноутбука repl и / или IJulia для LightTable и отправим его вместе с ним!
А если серьезно, чем больше я ковырялся в LightTable, тем больше я мог представить себе правильную «Julia IDE», встроенную в хороший плагин Julia. У него есть вся расширяемость, позволяющая реализовать что-то вроде RStudio или MatLab IDE, но даже лучше, потому что вы можете создавать встроенные графики или что-то вроде ноутбука, где выполнение программы «основано на графах», а не на построчном репликации. Я думаю, что GSoC Майка - отличное начало в освоении основ, но в этом есть огромный потенциал.

Во всяком случае, я отвлекся. Думаю, здесь неплохие раны - хороший вариант.

Я просмотрел и попробовал несколько из этих вариантов. cmder действительно выглядит достойно.

С помощью Console2 я смог вручную настроить его для загрузки Джулии (добавив «вкладку» Джулии в Настройки - есть файл конфигурации xml, чтобы это можно было автоматизировать), а затем запустить его как Console.exe -t Julia . Однако Console2 не исправила проблемы с отображением Unicode. Поведение при выборе текста по умолчанию довольно ужасно, вы удерживаете левый Shift, затем щелкаете и перетаскиваете. Держать клавишу для выбора может быть неудобно на ноутбуке.

Я не мог заставить cmder запускать Julia напрямую, но запуск вручную работал нормально и правильно отображал простой юникод. Cmder зависит от DLL среды выполнения MSVC, были ли проблемы с лицензией в конкретных условиях, в соответствии с которыми вы можете распространять их? Поведение выбора по умолчанию здесь также было левым сдвигом (или щелчком правой кнопкой мыши по значку, переходом к редактированию и переключению в режим отметки, так же, как в стандартной консоли Windows), но я нашел, как изменить его, чтобы не требовать одновременного нажатия клавиши + мыши .

У ConEmu есть несколько действительно раздражающих действий по умолчанию: он хочет сохранить свою конфигурацию в реестре по умолчанию, выскакивает диалоговое окно подтверждения каждый раз, когда я его закрываю, и т.д. Было легко запустить его непосредственно в Julia, и простой юникод работал.

Mintty потребует немного усилий, но в конечном итоге будет самым легким и простым вариантом для пользователей. Некоторые из текущих проблем с mintty связаны с более серьезными проблемами libuv, которые, надеюсь, будут исправлены вместе. Где-то есть код, который тестирует специально для именованных каналов Cygwin и MSYS2, которые, я думаю, необходимо проверить и изменить для работы с автономной загрузкой mintty. Возможно, мы могли бы использовать версию mintty от MSYS2, но тогда нам понадобится msys-2.0.dll который примерно в 4 раза больше, чем msys-1.0.dll который мы в настоящее время включаем в состав msysgit.

Ни один из этих вариантов не выглядит особенно легко компилируемым с MinGW, и я бы не хотел пробовать кросс-компиляцию. Но для этого достаточно просто загрузить двоичный файл релиза.

@ihnorton , здесь вы сказали:

+1 за мятный на данный момент. Исходя из моего собственного опыта, я бы категорически против упаковки конему.

можешь уточнить, почему именно здесь?

@StefanKarpinski в основном потому, что каждый раз, когда я пробовал это, слишком много вещей просто _off_. Я не помню всех проблем, но очень хорошо помню худшую: она плохо справляется с подпроцессами и делает создание гораздо медленнее, чем в Windows.

noop.bat: <strong i="7">@echo</strong> off

 julia> <strong i="10">@time</strong> for i in 1:1000
       open(`noop.bat`,"r")
       end

время в секундах, по две попытки:

    default console: 1.30,1.31
    cmder: 53.0, 61.6 (actually restarted twice more and got similar times)

Фактически, моя мышь начинает зависать при запуске этого тестового кода под cmder - но такой проблемы нет в стандартной консоли Julia.

См. Здесь частичную причину: https://code.google.com/p/conemu-maximus5/wiki/ConEmuHk
и из FAQ:

Q. mingw/bash/git works slow in ConEmu.
A. In rare cases on some configurations users may notice lags while executing commands in ConEmu tab. This may be when many child processes are created while command execution. I you are so unlucky - just uncheck "Inject ConEmuHk" on Features page. I'm still looking for the cause of the problem.

Эту «особенность» можно отключить, но плохая производительность респауна была известной проблемой уже несколько лет . Беспокоит то, что такая неработающая функция включена по умолчанию (и, как я уже сказал, это только худшая проблема).

@tkelman :

Cmder зависит от DLL среды выполнения MSVC, были ли проблемы с лицензией в конкретных условиях, в соответствии с которыми вы можете распространять их?

Да, они не могут распространяться с помощью программного обеспечения GPL. Теперь технически мы не будем связывать это с Джулией. Не знаю, меняет ли это что-нибудь.

+1 за мятный. Я все равно использую MSYS2 + Julia, и он отлично работает :)

Использование mintty из MSYS2 теперь по существу работает, если вы также включаете stty.exe , msys-2.0.dll , msys-intl-8.dll и msys-iconv-2.dll . И вам нужно явно указать set HOME=%HOMEDRIVE%%HOMEPATH% перед запуском, иначе mintty попытается установить HOME там, где он находится.

Я также пробовал использовать версию mintty от MSYS1, поскольку у нас уже есть msys-1.0.dll с msysgit, но это не совсем сработало. Кажется, что в mintty MSYS1 uv_pipe_getsockname(pipe, NULL, &len) в jl_uv.c возвращает 0.

mintty кажется наименее плохим вариантом. Просто помните, что поддержка обстрела вещей с использованием API консоли Windows может быть нестабильной . Я думаю, выбери свой яд, но мне это кажется нормальным в обмен на лучшее «все остальное».

(Вы пробовали что-то вроде git diff - пейджер работает?)

Нет, не похоже, что пейджер работает, но это может быть просто потому, что мы используем версию less из msysgit, которая не работает с mintty должным образом. Внутри полной установки MSYS2 или Cygwin less отлично работает от Джулии (называя эту среду версией less). Пытался просто копировать MSYS2 меньше, и dll это зависит от (ncurses и, ха, pcre), но по какой-то причине это, похоже, дамп стека ...

@tkelman Я считаю, что добился успеха с версией less от gnuwin32 , хотя она совсем не актуальна.

Я попробую. Может быть, не так уж сложно просто написать пейджер на чистой Джулии, не так ли?

Я думаю, что интеграция lighttable / sublime / ijulia будет подходящим вариантом. но это более важный вопрос, как эффективно объединять пакеты (возможно, 8745 поможет с этим)

Я все еще собираюсь работать над mintty для базового REPL. Юнона незрелая и мне пока не по душе, IJulia неудовлетворительно зависит от Python. Я все еще планирую улучшить удобство использования базового REPL. Однако эта работа заблокирована в libgit2, поскольку нам нужно будет внести довольно существенные изменения в упаковку Windows, когда мы удалим git из командной строки.

Я только что открыл для себя Powershell ISE. Это действительно здорово, если вы используете версию 3.0 или новее. Джулия сейчас не заводится, я понимаю

julia.exe : ERROR: `convert` has no method matching convert(::Type{TTY}, ::Pipe)
At line:1 char:49

но это можно поправить. Если так, может, стоит добавить в него ярлык для запуска Джулии.

Похоже на mintty, Powershell ISE использует каналы для stdout и stderr, за исключением того, что stdin является обычным tty. Каналы для stdout и stderr не имеют имен, насколько я могу судить, оба вызова uv_pipe_getsockname в jl_ispty возвращают 0. Если я пропущу первый ранний возврат и сделаю jl_ispty return 1, когда len == 0 после второго вызова uv_pipe_getsockname , тогда Джулия может начать, но он полностью не отвечает. И, похоже, он тоже не распознает цветовые коды. Судя по http://blogs.msdn.com/b/powershell/archive/2009/02/04/console-application-non-support-in-the-ise.aspx, это могло быть невозможно, но да ладно, было стоит попытаться.

FWIW, я попробовал форк Console2 под названием ConsoleZ . Изменяя значения по умолчанию, я получаю разумное поведение копирования и вставки (выбор левой кнопкой мыши), но, как и в случае с Console2 проблемы с юникодом остаются.

Нам по-прежнему нужен лучший эмулятор терминала для Windows. Наблюдать, как люди борются с cmd.exe , ужасно - Джулии нужно обеспечить лучший опыт по умолчанию из коробки.

Согласен, если детали удастся выковать. Хотя IJulia, безусловно, сглаживает это, по крайней мере, в классах Julia, в которых я участвовал за последний месяц.

(Более высоким приоритетом будет что угодно, чтобы ускорить операции Pkg , которые кажутся слишком медленными в Windows.)

Как я уже говорил в декабре https://github.com/JuliaLang/julia/issues/7267#issuecomment -67761899, я буду работать над включением mintty. Но только после того, как мы избавимся от git в командной строке, поскольку все это потребует значительного переписывания того, как собираются двоичные сборки Windows. Можем ли мы перейти к переходу libgit2?

Хорошо , спасибо решена .

Мне нравится план с mintty, но я думаю, было бы хорошо, если бы он не был по умолчанию, если Julia установлена ​​в системе Win10. Win10 поставляется с капитальным ремонтом консоли, который, вероятно, решает все текущие проблемы, и я считаю, что Джулии следует просто придерживаться (тогда) хороших системных параметров по умолчанию. Текущая конечная версия Win10 RTM, похоже, на июнь / лето, так что определенно до Julia 0.5, и это означает, что 0.4 будет версией, которую люди будут использовать в Win10.

@davidanthoff да, я хотел попробовать наконец-то не дрянную консоль в Win10 (и до сих пор не понимаю, что они пропустили 9). Подход, который, как мне кажется, я выберу здесь, - это собрать mintty и включить его в двоичные файлы, а также установить отдельный ярлык для запуска Julia внутри него. Я не хочу делать что-либо слишком сложное с определением версий Windows, когда появятся 7 и 8, и что большинство пользователей Windows будут использовать в течение некоторого времени. Судя по посещаемости в списке рассылки Cygwin, они следят за изменениями в предварительных версиях и следят за тем, чтобы mintty и другие мелочи продолжали работать.

@tkelman Это определенно сработает. С другой стороны, мне нравятся разумные настройки по умолчанию, и я не большой поклонник, если новым пользователям приходится делать выбор, которого они не понимают, когда они впервые хотят запустить julia. Подавляющее большинство пользователей понятия не имеют, что означает mintty, поэтому, когда они увидят два ярлыка для запуска julia, а один называется чем-то вроде JuliaMintty, они не будут знать, что им делать. Может быть, установщик смог определить версию windows, а затем создать соответствующий ярлык по умолчанию? С другой стороны, я согласен, это не должно стать сверхсложным проектом, поэтому, если нет простого способа добиться этого, ваше предложение все равно может быть лучшим.

Установка двух ярлыков во всех версиях, в то время как большинство пользователей не должны использовать консоль (на чем-либо <10), мне не нравится. Лучше пока используйте одну и ту же консоль везде, и, возможно, однажды обнаружите, что Windows 10 будет использовать там консоль по умолчанию. В настоящее время пользовательская база не использует Windows 10, поэтому это не должно быть в центре внимания.

Ярлык также не является строго необходимым. Если пользователи Windows 10 хотят запускать Julia в стандартной консоли вместо mintty, они должны иметь возможность просто дважды щелкнуть bin/julia.exe .

@tkelman Да, если есть еще способ запустить julia без mintty, тогда все хорошо, ярлык не нужен.

Так что технически я думаю, что нам придется использовать копию mintty из Cygwin или MSYS2, а также несколько других файлов, перечисленных выше https://github.com/JuliaLang/julia/issues/7267#issuecomment -49097410. Версия mintty для MSYS1 не выполняет те же функции именованных каналов, которые мы ожидаем, поэтому ее было бы намного сложнее поддерживать.

Как только этот http://midipix.org/ будет выпущен, я, вероятно, посмотрю на него и посмотрю, есть ли какие-либо преимущества в создании mintty против этого нового слоя posix (musl на win32 ... интересная комбинация).

Есть ли что-то, что мы можем сделать на данный момент, чтобы улучшить работу с Windows в краткосрочной перспективе, пока не будет выпущен мидипикс?

Давайте выделим midipix в отдельную тему и сосредоточим внимание на поставках с mintty, что, я думаю, мы должны сделать поспешно.

Одна вещь, о которой я недавно думал, - это использовать Blink.jl + VT100.js (эмулятор JuliaBox) в качестве терминала. Поскольку Blink выполняет всю сантехнику, это просто случай подключения js-терминала stdin / stdout к REPL и связывания его с Julia. (Некоторые терминалы JS даже поддерживают графический вывод.)

Кроме того, это открывает путь к доставке Джулии таких вещей, как прекрасные автономные средства просмотра профилей, окна просмотра / редактирования фрейма данных и т. Д. (Которые могут быть или не быть в разработке ...).

Основное предостережение - это зависимость от AtomShell, но ее можно удалить, приложив немного усилий.

Во всяком случае, это еще один вариант.

Процитирую мудрого мастера: Let's make the Blink thing a separate issue and keep this focused on shipping with mintty, which I think we should do post haste. .

+1. Я буду работать над этим. Было бы разумно просто упаковать то, что нам нужно, и включить это в сборку Windows, а также изменить NSIS для создания соответствующей ссылки.

Я очень не решаюсь связывать mintty до тех пор, пока мы не удалим git из командной строки. Проблема, опять же, в том, что mintty MSYS1 нам не подходит, но git командной строки полагается на msys-1.0.dll. Доставка двух разных несовместимых слоев posix (msys-1.0.dll для git, msys-2.0.dll для mintty) звучит как напоминание о проблемах.

Если не мятный, можем ли мы отправить cmder?

Я определенно ожидаю, что Blink станет долгосрочным решением. Давайте обсудим это в другом месте, независимо от этого вопроса, который является весьма важным.

См. Выше ряд аргументов против cmder.

Что касается Blink, я бы категорически против того, чтобы AtomShell зависел от базовой Julia.

Мидипикс - отдельная тема, и сфокусируйтесь на поставках с minty.

На самом деле я планировал использовать midipix для создания mintty, или, по крайней мере, пытался. В отличие от MSYS2 или Cygwin, в идеале это должно позволить нам статически связывать любые части слоя posix, которые необходимы, в mintty.exe. Части мидипикса доступны для публичного просмотра на http://git.midipix.org/ , но пока не выглядят пригодными для использования или документированными.

Значит ли это, что нет решения лучше, чем использование командной строки Windows?

Мы можем попробовать с mintty MSYS2 (или Cygwin, они должны быть почти идентичны). Простое изменение ярлыка не сработает, поскольку запуск Julia в mintty устанавливает переменную среды HOME на что-то странное, что препятствует загрузке файла истории ответов или правильной работе пакетов. Создание файла julia.bat со следующим

<strong i="8">@echo</strong> off
set HOME=%HOMEDRIVE%%HOMEPATH%
start %~dp0\bin\mintty.exe -h error %~dp0\bin\julia.exe
exit

кажется, работает, но мигает временно открыть окно cmd. Не знаю, как от этого избавиться, у командных файлов msys2 такая же проблема.

О, слава богу, разработчики Git-for-Windows наконец-то опомнились и выпустят 2.x на основе MSYS2 вместо MSYS1: https://github.com/git-for-windows/git/issues/25

Итак, мы должны получить mintty бесплатно, просто нужно подождать, чтобы заменить наш git из командной строки на обновленную версию.

У меня есть полуработающий хак с использованием mintty от msys2. Чтобы избавиться от фонового окна консоли, необходимы две вещи:

• cygwin-console-helper
• mintty должен быть в пути, заканчивающемся на usr/bin/ (: confused :)

Настройка выглядит так:

Затем я сделал ярлык в Julia-... со следующей целью:
C:\opt\Julia-0.4.0-dev-ee316f2197\mtty\usr\bin\mintty.exe ./env HOME=%HOMEDRIVE%%HOMEPATH% ..\..\..\bin\julia.exe

Этот ярлык запускает Джулию правильно, и основы работают, за исключением (пока) того, что команда загрузки PowerShell не работает.

• mintty должен находиться в пути, заканчивающемся на usr / bin / (: confused :)

что за?

команда загрузки PowerShell не работает

Есть признаки ошибки или тихого зависания, или?
(для контекста - https://github.com/JuliaLang/BinDeps.jl/pull/124)

Захватывающий прогресс, несмотря на странности.

что за?

Я в тупике. Запуск его из пути установки msys не вызывает всплывающего окна консоли, поэтому я знал, что _had_ это возможно, и пробовал некоторые варианты, пока не обнаружил, что usr/bin/ работает.

Есть признаки ошибки или тихого зависания, или?

Не то чтобы я мог видеть. Я предполагаю, что это проблема с ручками ввода-вывода консоли.

Не то чтобы я мог видеть. Я предполагаю, что это проблема с ручками ввода-вывода консоли.

Хм. Я могу выложить PowerShell от Джулии, работающей внутри mintty Cygwin, интересно, в чем разница?

Есть что-нибудь, что я могу попробовать? Я работал с несколькими пользователями Windows в течение последних нескольких дней, и мне действительно жаль, что я использовал наше текущее решение.

Я должен иметь возможность дать полезный отзыв о mintty и, возможно, даже попросить нескольких других попробовать его и понаблюдать за ними, но мне понадобится сборка, которую я могу загрузить.

@tkelman

Хм. Я могу выложить PowerShell от Джулии, работающей внутри mintty Cygwin, интересно, в чем разница?

Но можно ли его использовать? Я могу использовать PowerShell как из msys2, так и из cygwin mintty, но приглашение не отображается, и когда я выхожу, Джулия получила все _input_. Я использую PowerShell по умолчанию в Windows 7 (обозначаемый как «Copyright 2009»)

Другая, возможно, связанная с этим проблема заключается в том, что git-пейджер не работает.

@ViralBShah

Есть что-нибудь, что я могу попробовать? Я работал с несколькими пользователями Windows в течение последних нескольких дней, и мне действительно жаль, что я использовал наше текущее решение.

Установите MSYS2 отдельно, но не копию git от MSYS2 (поскольку это приведет к поломке диспетчера пакетов, пока мы не заменим оболочку на libgit2). Откройте терминал msys2 и запустите в нем Юлию.

@ihnorton

Но можно ли его использовать?

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

Другая, возможно, связанная с этим проблема заключается в том, что git-пейджер не работает.

Git-for-Windows на базе MSYS2, похоже, скоро будет выпущен. Я бы предпочел, чтобы мы попробовали это. (libgit2, конечно, будет на порядки лучше, но для переключения на нее потребуется больше работы)

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

Я попытался добавить -Noninteractive в команду загрузки powershell в bindeps, но это не помогло. Procmon сообщает мне, что загрузка выполняется до завершения, затем один из потоков завершается и процесс, по-видимому, никогда не возвращается.

@tkelman превью msys2 git-for-windows выглядит очень красиво. Вы где-нибудь видели план / график выпуска?

Перекрестные ссылки https://github.com/git-for-windows/git/issues/74 (для моей будущей справки, я знаю, что вы там прокомментировали).

Не знаю. У них есть предварительные сборки sdk, но я еще не очень много с ними играл. Было желание помочь им настроить аппвейор, но было немного занято.

Если мы планируем сделать это для версии 0.4, каково решение - не кажется ли, что оно решено? Кроме того, это легко можно сделать в версии 0.4.x. Это важно, но никак не ломается.

Итак, здесь мы можем сделать несколько вещей. Если мы попробуем заменить наш встроенный git командной строки на новый git 2.x на основе msys2, мы могли бы просто использовать включенный там mintty. Я так много не тестировал, но нам нужно внимательно проверить, не слишком ли отличается структура папок (и это сделает двоичные файлы немного больше, чем git 1.x) и Pkg прежнему работает исправно.

Я воздержался от этого, потому что # 11196 выглядит так, как будто он на самом деле довольно близок к работе, но для выпуска v0.23 потребуется libgit2, чтобы мы могли использовать https в Windows без необходимости иметь дело с openssl. Если мы переключимся на git 2.x сейчас, просто чтобы начать использовать mintty, нам нужно будет отменить большую часть этой работы и заново провести все тесты, когда мы переключимся на libgit2.

Просто для контекста: теперь мы знаем, что Win10 будет выпущен 7/31, так что, возможно, даже раньше, чем julia 0.4. Это будет бесплатное обновление почти для всех, и MS явно продвигает его на машины, больше похоже на пакеты обновления в прошлом (например, все текущие машины Windows теперь уже просят людей через Центр обновления Windows подписаться на обновление на 7/31).

Так что, с моей точки зрения, если ресурсов не хватает, я все еще не уверен, что поставка более качественной консоли julia является приоритетной задачей, когда у Windows будет хорошая консоль через несколько недель, а люди, использующие более старые версии Windows, могут просто используйте Console2 или что-то в этом роде. Я не говорю, что было бы неплохо иметь один, но мне кажется, что есть очень длинный список других вещей, которые имеют более высокий приоритет для 0.4.

Не стесняйтесь игнорировать этот комментарий;)

@tkelman :

Cmder зависит от DLL среды выполнения MSVC, были ли проблемы с лицензией в конкретных условиях, в соответствии с которыми вы можете распространять их?

Да, они не могут распространяться с помощью программного обеспечения GPL. Теперь технически мы не будем связывать это с Джулией. Не знаю, меняет ли это что-нибудь.

Я прочитал это далеко. Я попытался посмотреть, предустановлен ли MSVC в Windows. Кажется, MSVC все еще распространяется, но нужна ли вам более новая версия для работы cmder? Если установлен MSVC в системе Windows, поддерживаемой Julia, то вы можете распространять Cmder (или что-то еще) и Julia (включая библиотеки под GPL) под «исключением системных библиотек» GPL.

Нет, если вам нужна более новая версия MSVC, чем установлена, вы можете обновить ее позже или установить в более старых версиях Windows, которые могут не иметь ее.

Это всего лишь терминальная программа. Неужели ей нужна новая версия - в целях безопасности?

Если нет MSVC, вы можете отказаться от терминала, пока MSVC не будет установлен. GPL не запрещает это.

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

Что касается Windows 10, никогда не стоит недооценивать нежелание пользователей Windows обновлять свою ОС. Что касается пропускной способности, места на жестком диске и времени на настройку, из того, что я видел, люди обычно предпочитают ждать, пока они купят новый компьютер для обновления, чем обновлять существующие машины. Хотя я видел всплывающее сообщение «Установите Windows 10» - я еще не понял, как его убрать.

Хотя я видел всплывающее сообщение «Установите Windows 10» - я еще не понял, как его убрать.

Вероятно, есть групповая политика, позволяющая полностью отключить ее (у нас ее нет на наших рабочих компьютерах), но вы сможете скрыть ее с помощью параметра «Настроить ...» во всплывающем меню на панели задач.

PowerShell - это то, что вам нужно. Он зрелый, расширяемый, и Microsoft много в него вложила. Было бы неплохо с ним лучше интегрироваться.

PowerShell или cmd не имеют значения, поскольку они оба используют примерно одно и то же окно терминала. Оба будут включать новые функции, такие как перекомпоновка текста в Windows 10 AFAIK.

@pao спасибо, я тупой, я не трогал эту кнопку настройки как минимум несколько лет

@wildart на самом деле обсуждается, как заставить режим оболочки проходить через PowerShell, по крайней мере, необязательно, в # 11478

Сам Powershell на самом деле не «лучший терминал», это лучший интерпретатор оболочки. Powershell ISE - действительно хороший терминал с intellisense и т. Д., Но из моих экспериментов с ним я не смог найти способ запустить через него интерактивную программу репликации без Powershell.

@tkelman : «Если мы собираемся связать лучшую программу терминала с Джулией, мы должны использовать ту, которая может быть включена по умолчанию». да, если это был ответ мне, то я предполагал, что вы можете включить cmder или что-то еще для Windows. Может быть, не для самых старых версий, скажем Windows XP, это вроде как не поддерживается Джулией (официально) в любом случае .. [Я не уверен, где будет находиться поддерживаемая линия ..] Получение того же, что и сейчас, на более старых, и если вы хотите, на самом деле возможность включения на всех старых платформах путем загрузки распространяемого пакета кажется нормальным? На самом деле много программистов Julia работает на XP? Не то чтобы они не могли его использовать или запускать программы julia.

Был в ответ на https://github.com/JuliaLang/julia/issues/7267#issuecomment -110402050 - в настоящее время Джулия не зависит от библиотеки времени выполнения MSVC более новой, чем та, которая предустановлена ​​в Windows. Мы не можем распространять новую библиотеку времени выполнения MSVC в комплекте с программным обеспечением GPL, исходя из моего понимания лицензий. Если для включения лучшего терминала требуется вручную установить отдельную новую библиотеку времени выполнения MSVC, я не думаю, что это хорошее направление.

Как я уже упоминал ранее в этом выпуске, cmder объединяет несколько вещей, которые нам не нужны. Если мы хотим изучить какое-то решение на основе ConEmu, было бы удобно, если бы существовал способ извлечения только стандартных конфигураций cmder вокруг ConEmu, поэтому нам не нужно делать столько работы, чтобы настроить ConEmu, чтобы сделать его терпимым, но избегайте используя остальную часть cmder, которая зависит от библиотек времени выполнения MSVC и ненужных компонентов, таких как clink.

А как насчет бесплатного распространения GPL? Похоже, мы очень близко подходим. Хотя было бы неплохо не иметь этого ограничения.

conemu - это bsd-3, mintty - это gpl (и полагается на gpl cygwin / msys2 dll, если в конечном итоге midipix не работает), cmder - это MIT, но пакеты clink, которые являются gpl. Нам нужно будет чертовски настроить conemu, чтобы сделать его достойным, и нужно внимательно следить за проблемами производительности, упомянутыми выше.

"cmder - это MIT, но связки звенят, что gpl".

Поскольку он включает в себя программное обеспечение GPL, могу ли я предположить, что они не включают в себя Microsoft
проприетарный распространяемый продукт, несовместимый с GPL как
комбинация? То есть он уже установлен в (большинстве версий) Windows
подпадают под исключение GPL "Системная библиотека".

Я бы не стал слишком беспокоиться о том, что дистрибутив Julia полностью
Без GPL для любого терминала (только, если хотите, системные библиотеки
звонит от Юлии). Это функция, которую легко отключить, заменить и
не сделает Юлию "вирусной" по GPL.

[Есть вероятность, что cmder будет использовать clink (что я не
уверен, что есть) как отдельный процесс ("на расстоянии вытянутой руки" / хотя четко определенное
API) как "простую агрегацию", что Юлия сделала бы, а затем освободилась бы.
ограничений GPL и будет включать в себя распространяемый компонент .. Джулия делает (или
будет делать?) аналогично с libgit2, то есть GPL .. (при этом явно разрешая
статическая ссылка).]

Похоже, что комбинация clink в cmder и библиотеки времени выполнения msvc может нарушать условия распространения gpl и / или microsoft. Не уверена.

Сегодня я удалил каталог Git из двоичной установки, загрузил последний переносимый Git и немного поработал. Пока рано говорить окончательно, но похоже:

1. новый git работает как замена старого git; и
2. монетный двор успешно работает с Юлией.

Надеюсь, мы сможем закрыть это в ближайшие несколько дней.

отличный! было бы хорошо изменить это в make-файлах в ближайшее время, чтобы люди могли начать с ним тестирование (и выяснить, как лучше всего изменить запуск, чтобы фактически использовать mintty).

https://github.com/git-for-windows/git/wiki/FAQ#some -native-console-programs-dont-work-when-run-from-git-bash-how-to-fix-it

Я предполагаю, что на данный момент подобные вещи будут отложены до версии 0.4.1, так что у 0.4.0 в какой-то момент есть шанс выпустить? Это действительно кажется мне изменением, которое потребует некоторого тестирования, и с небольшим количеством тестеров Windows, вероятно, было бы лучше не иметь этого в 0.4.0 просто из-за потенциальных проблем и вероятности того, что это может задержать выпуск 0.4.0 далее.

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

Да, базовые тесты многообещающие, но мы бы хотели быть более тщательными в отношении тестирования того, что все по-прежнему работает должным образом в целом ряде вариантов использования в пакетах, прежде чем нажимать на курок. И нам придется снова провести тот же набор тестов для libgit2, после чего мы удалим командную строку git из двоичных файлов, сделав большую часть первого набора работы по тестированию избыточной.

Кроме того, мне кажется, что это то, что вам нужно протестировать в разных выпусках Windows, в x86, x64 и т. Д.

Я использовал Джулию с PowerShell и с PowerShell в ConEmu. Проблем не было, поэтому я не уверен, почему это так необходимо. Я предполагаю, что большинство пользователей Windows будут стремиться использовать IDE для Julia. Подмножество, использующее терминал, вероятно, будет иметь что-то уже настроенное разумное (conemu, console2 и т. Д.) И будет запускать Юлию непосредственно из exe, не беспокоясь о связанном терминале IMO. Я думаю, что лучше было бы потратить время на разработку какой-то matlabish IDE.

Мои наблюдения за пользователями Windows заставили меня поверить, что это не так.

Разработка IDE (или, точнее, интеграции интеллектуального редактора) какое-то время будет идти вне базы, а REPL никуда не денется.

В настоящее время связанная версия git, которую мы используем, всегда 32-битная, так как мы используем только ее, но, вероятно, было бы хорошей идеей использовать теперь доступную 64-битную сборку Git в 64-битных двоичных файлах Julia, чтобы использовать libcurl и другие библиотеки зависимостей git через ccall . Я сомневаюсь, стоит ли пытаться использовать настройки make-файла и работу по тестированию в серии 0.4.x. Если кто-то хочет подготовить PR, мы можем легко собрать тестовые двоичные файлы из ветки.

Оглядываясь назад, я поспешил предложить заменить распространенный Git как часть решения этой проблемы. Во- первых , как предлагает libgit2 (надеюсь, при моей жизни). Потребность в не совсем дерьмовом терминале для Windows сохранится еще долго.

Тем не менее, я думаю, что стоит рассмотреть возможность использования msys2 версии mintty в качестве краткосрочного решения. Мы бы просто связали его независимо от git. Да, это будет означать, что нам нужно будет отправить огромные msys-2.0.dll , но мне кажется, что это относительно небольшая цена. (Кроме того, двоичные файлы станут значительно меньше, когда мы перейдем к libgit2 , верно?)

Я немного поигрался с автономными mintty и julia . Я пока не видел никаких проблем, за исключением того, что нам может потребоваться / нужно исправить его, чтобы использовать cmd в качестве оболочки по умолчанию вместо bash .

Либо версия mintty для msys2, либо версия mintty для cygwin должны быть в целом эквивалентными. На самом деле нам не нужно искажать путь msys, поэтому я бы предпочел то, что проще получить и использовать. Я планирую справиться с этим вместе с удалением командной строки git из двоичных файлов, как только libgit2 будет на месте.

@tkelman , рад помочь чем

Я считаю, что нам нужны stty.exe вместе с mintty.exe и либо cygwin1.dll или msys-2.0.dll . stty.exe ссылается на cygintl-8.dll (или msys-intl-8.dll ), а это на cygiconv-2.dll (или msys-iconv-2.dll ), я еще не копал чтобы найти, из каких пакетов извлечь каждый из этих файлов. MSYS2 досадно размещает свои двоичные файлы пакетов на sourceforge, хотя я думаю, что они находятся в процессе миграции в другое место. Cygwin является зеркалом MIT по адресу http://mirrors.mit.edu/cygwin/, что, по моему опыту, было очень надежным.

редактировать:
немного синтаксического анализа ini из http://mirrors.mit.edu/cygwin/x86_64/setup.bz2, чтобы получить последние номера версий всего, затем
http://mirrors.mit.edu/cygwin/x86_64/release/mintty/ за mintty.exe
http://mirrors.mit.edu/cygwin/x86_64/release/cygwin/ за cygwin1.dll
http://mirrors.mit.edu/cygwin/x86_64/release/coreutils/ за stty.exe
http://mirrors.mit.edu/cygwin/x86_64/release/gettext/libintl8/ за cygintl-8.dll
http://mirrors.mit.edu/cygwin/x86_64/release/libiconv/libiconv2/ за cygiconv-2.dll

Просто mintty + DLL не работают. mintty хочет bash . Я посмотрю, есть ли простой способ исправить mintty чтобы убрать его с bash .

РЕДАКТИРОВАТЬ: установка HOME=%USERDRIVE%%USERPROFILE% и SHELL=cmd продвинула меня немного дальше ( mintty cmd по умолчанию будет использовать

РЕДАКТИРОВАТЬ 2: Когда я запускаю mintty c:\path\to\julia.exe с версией cygwin, я получаю два окна: одно пустое окно и одно с Джулией. С версией msys2 я получаю только одно окно.

РЕДАКТИРОВАТЬ 3: просто перечитайте ветку и увидите настройку HOME . При просмотре файла .bat для установки переменной HOME обе версии msys и cygwin открывают два окна. Вздох.

ах, верно, забыл о штуке cygwin-console-helper из https://github.com/JuliaLang/julia/issues/7267#issuecomment -84674766

@tkelman , я /usr/bin должен быть абсолютным, полагая, что это сделает его не стартером для любого жизнеспособного потенциального решения.

Моя версия этого хака уже работает. Мне пришлось переместить env HOME=... перед вызовом в mintty чтобы он мог найти домашний каталог и сохранить свои настройки. Я сейчас пытаюсь составить пиар.

12879 теперь минимально функционален, за исключением того, что julia выдает ошибку при двойном щелчке по ярлыкам, если только рабочий каталог для ярлыка не mintty\usr\bin . Проблема в том, что julia ожидает stty на пути. Я попытался расширить путь с помощью другого вызова env но (1) я не мог заставить его работать правильно (с исполняемыми файлами cygwin) и (2) в любом случае это сделало командную строку ярлыка слишком длинной .

Может быть, подойдет патч к base ? Похоже, что все вызовы stty находятся в Terminal.jl в блоках, специфичных для Windows.

Я бы закинул патч в:
https://github.com/JuliaLang/julia/blob/master/contrib/windows/juliarc.jl
вот где такие взломы, как правило, живут, пока не попадут на базу или не могут быть решены каким-либо другим способом

@vtjnash ,: +1:

Кстати, я заметил, что версия cygwin mintty , которую я использую в # 12879, выполняет временное мигание второго окна, тогда как версия msys2 установленная на моем компьютере, нет. Меня это не особо беспокоит, но если это беспокоит критическую массу пользователей, мы можем захотеть перейти на версию msys .

Мы могли бы спросить разработчиков Mintty об этой проблеме. Недавно он был принят новым сопровождающим, который проявил гораздо больше активности.

Я пробовал # 12879 и столкнулся с несколькими проблемами. Я упомяну их здесь, поскольку я не совсем уверен, как отслеживать проблемы, связанные с PR.

В основном все работает, включая Pkg , BinDeps и WinRPM . Однако при попытке Pkg.add("ImageView") казалось, что все зависает при загрузке ImageMagick . Убил и перезапустил с Pkg.build("ImageView") . Он двигался, но затем снова завис при загрузке innounp . Я убил и снова позвонил Pkg.build , и все прошло без жалоб.

Кроме того, кажется, что два процесса mintty запущены, пока терминал открыт. Я полагаю, один из них - тот, который проглотил cygwin-console-helper . Это не проблема как таковая, просто немного неинтуитивно.

Кроме того, Ctrl+C при запуске подпроцесса убивает mintty а не подпроцесс, возвращаясь к julia . Например, попытка прервать IJulia.notebook() закрыла терминал, но оставила процесс зомби python .

Возможно, вы столкнулись с той же проблемой видел @ihnorton ? Какая версия винды?

Не могли бы вы очистить загрузку bindeps из Images.jl, удалить :powershell из https://github.com/JuliaLang/BinDeps.jl/blob/5cf51cbea127ec5fd498efa14602c648dd75e52d/src/BinDeps.jl#L#L#L#L снова?

@twadleigh , можете ли вы сообщить о проблемах, относящихся к # 12879, в этом PR и, возможно, добавить флажки для дел, если это необходимо? В противном случае любой, кто смотрит на этот PR, видит только заполненные флажки и «Это в основном работает для меня на данный момент», что может создать ложное впечатление о том, насколько он готов к слиянию.

@tkelman Я использую Windows 7 Professional. Я удалил Images , удалил :powershell и повторил попытку. Работало нормально. Так что мы можем списать это на проблему BinDeps . Я полагаю, он уже подан.

@stevengj Я

Таким образом, мы можем списать это на проблему BinDeps . Я полагаю, он уже подан.

Я согласен с диагнозом, но об этом раньше не сообщалось. В новом выпуске BinDeps мне было бы любопытно узнать, является ли это проблемой только при запуске Julia в mintty или вы можете воспроизвести из обычного julia.exe.

@tkelman : Ах, я неправильно понял. Да, я подтвердил, что это проблема, специфичная для mintty -wrapped julia . Я открою вопрос по адресу BinDeps.jl .

В версии 0.4.1 вы можете запустить Git/git-bash.exe затем запустить ` cygpath -m $PWD /../ bin / julia`. Может, нам стоит просто задокументировать это.

Разве мы не можем сделать его по умолчанию, если он явно лучше?

Еще нет, пока не будет решен https://github.com/JuliaLang/BinDeps.jl/issues/167 .

Это сообщает о последних обновлениях собственной командной строки Windows. Вероятно, главная новость заключается в том, что они, похоже, стремятся привести свою реализацию последовательности управления VT в форму.

Я не думаю, что Джулия должна поставляться с терминалом на Windows. С такими альтернативами, как vs-code и juno (которые решают основную проблему здесь), похоже, что он не предлагает много возможностей для доставки и обслуживания терминала с julia на Windows.

Они подходят для пользователей, которым нужна IDE или тяжеловесный редактор, но mintty cygwin - намного лучший интерфейс терминала, чем стандартные окна Windows, и его стоит добавить в нашу установку. Модернизированная версия https://github.com/JuliaLang/julia/pull/12879 находится где-то в конце моего списка дел, у меня есть код переупаковки в репо, который берет только те части cygwin, которые нам нужны. Не срочно, потому что это хорошо, но мы все равно должны это сделать.

Я постоянно вижу пользователей Windows, страдающих от терминала Windows и Джулии.

Вкладки появятся для встроенного терминала в Windows со следующим выпуском Win 10 осенью ...

Я думаю, нам нужно что-то с этим сделать: cmd.exe действительно дает плохие возможности в Windows. Два комментария, с которыми я столкнулся за последние 24 часа:

• «Мне, как новичку, нравится скорость тестирования в терминале. Если кто-то из разработчиков Julia читает, пожалуйста, интегрируйте ctrl + v в терминал. Язык, который входит в тройку лучших петафлопсов, должен иметь возможность копировать пасту, как и все другие приложения»
• «Спасибо, работает также с Emojis, даже несмотря на то, что Windows cmd.exe не может правильно отображать большинство из них в 2018 году»

Я вообще-то не понимаю, почему копипаст не работает. Когда я запускаю PowerShell или старый cmd.exe в недавней Windows, такие вещи, как Ctrl + v, работают сразу же из коробки. Они просто не работают в julia ... Итак, я запускаю экземпляр PowerShell, копипаст работает. Затем я запускаю julia из этого экземпляра PowerShell, а затем копипаст больше не работает (в julia). Как только я останавливаю julia, копипаст снова работает в PowerShell.

Кроме того, в осеннем обновлении Windows появилось много нового: https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introduction-the-windows-pseudo- консоль-conpty /. Может ли это помочь?

Вкладки, правда, в следующем выпуске убрали. Насколько я понимаю, это может произойти позже, но все же.

Это интересно: Ctrl-c для копирования тоже работает.

Вы знаете, как с этим справляются? Это просто вопрос добавления привязки Ctrl-v к Julia REPL?

Если вставка исправлена, она все еще недокументирована (https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences). Новый материал ConPty хорош, так как нам больше не нужно ждать, пока MS исправит это, и вместо этого можно дождаться, пока кто-нибудь портирует MinTTY / ConEmu / Console2 / и т. Д. На новый API и добавит там поддержку.

Вы знаете, как с этим справляются? Это просто вопрос добавления привязки Ctrl-v к Julia REPL?

Понятия не имею...

Но я тоже нашел это . Мне неясно, применимо ли это только к WSL, или это будет работать в целом для всех приложений cmdline ... Я думаю, что это, вероятно, также появится в следующем осеннем выпуске Windows.

Собственная сборка на cygwin облегчит интеграцию с «настоящим» эмулятором терминала, но: # 28891.

Свет в конце туннеля, который может быть или не быть встречным поездом:

https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introduction-the-windows-pseudo-console-conpty/

Обратите внимание, что терминал не открывается сразу; Conpty необходимо будет сначала интегрировать в cygwin, который является средой выполнения для mintty, прежде чем будут установлены преимущества.
Простой перенос на cygwin (должна быть некоторая базовая отладка Makefile, поскольку Julia доступна для Linux) уже упростит беспрепятственное использование mintty.

Может ли это помочь?

Я в этом сильно сомневаюсь - мы немедленно выводим консоль из режима «тупой» / «строка чтения», чтобы получить доступ к функциям, выходящим за рамки основного вывода текста. Раньше это всегда отключало все новые функции. (что имеет смысл, поскольку они могут конфликтовать с нашими функциями интеграции и нарушать их).

Меня очень интересует нижняя часть скриншота:

Очевидно, он получил поддержку UTF-8! Какой большой шаг вперед по сравнению с UCS-2. Ура, так будет удобнее и полезнее.

Об этом говорилось в недавней ветке «Первые впечатления» на Discourse:

https://discourse.julialang.org/t/first-impressions/22318

Было предложено использовать git bash с https://gitforwindows.org, и это кажется прекрасным вариантом.

Похоже, gitforwindows просто использует mintty? Смотрите их FAQ .

Это. Запуск Джулии внутри Git bash (Mintty) - приятное занятие. В Juno также открыт запрос функции для запуска консоли внутри Mintty вместо консоли по умолчанию. Он устраняет большинство, если не все, проблем с консолью Windows.

@braamvandyk , я

Я согласен с тем, что mintty кажется хорошим вариантом, намного превосходящим консоль Windows!

(Ортогональная проблема связана с объединением Джулии с улучшенным режимом оболочки; см. # 23703)

Знаем ли мы, каковы текущие проблемы с консолью Windows? Просто некоторые символы Unicode не отображаются должным образом? Я думаю, это единственное, о чем упоминалось в этой беседе?

Если да, то какие именно? Потому что, по крайней мере, те, которые я пробовал, работают нормально?

Другая проблема, о которой я знаю, - это поддержка копирования / вставки. Я не понимаю, что там происходит, но стоит отметить, что он отлично работает в обычной командной строке Windows, а то только в julia перестает работать. Может, стоит сначала разобраться, почему это так?

Другой вариант такой:

если бы нам удалось настроить файл ярлыка, указывающий на исполняемый файл julia, с включенной по умолчанию этой опцией через установщик, это, вероятно, решило бы проблему копирования / вставки.

Эта опция работает внутри julia REPL.

Я повторяю @davidanthoff , я думаю, что большинство проблем связаны только с символами Unicode и вставкой. Что еще предлагает mintty, чтобы получить более приятное впечатление? FWIW Я использовал julia с conemu и считаю, что это нормально, кроме вставки и символов Unicode (трудно найти хороший шрифт, а conemu не реализует резервные символы)

Кажется, что проблему с вставкой можно решить, воспользовавшись новым контентом в окнах

Цвета не работают должным образом, если вы не запустите WSL и linux julia (оба скриншота в cmd.exe):

Также отсутствие брекет-пасты сильно раздражает.

Я считаю, что все это должно быть исправлено с помощью conpty вместо winpty

Для справки здесь упоминается, что теперь они поддерживают 24-битные цвета (хотя, предположительно, только для приложений conpty), и это объясняет, как можно подключиться к материалам conpty.

Рассуждая об этом, мы никогда не решаем эту проблему ...

Цвет - определенно проблема со стороны julia / libuv. Я просто поигрался с API консоли win и смог сгенерировать это в обычном окне командной строки julia в Windows:

Я открыл здесь еще один выпуск, который описывает то, что я нашел до сих пор. Но я думаю, что для обсуждения здесь это означает, что в настоящее время Джулия просто не подключается должным образом к полной поддержке консоли, которую Windows в настоящее время предлагает в Windows 10, и что по крайней мере некоторые из этих болевых точек, вероятно, можно решить, исправив это.

Знаем ли мы, каковы текущие проблемы с консолью Windows? Просто некоторые символы Unicode не отображаются должным образом? Я думаю, это единственное, о чем упоминалось в этой беседе?

В этом обсуждении перечислены некоторые символы, но, вероятно, есть целые блоки, которые не отображаются.

Режим оболочки также работает в Mintty, что, конечно, не относится к консоли Windows.

Хотя https://github.com/JuliaLang/julia/issues/31491 разбирается, и мы надеемся, что в какой-то момент в будущем Microsoft и libuv исправят свои действия, и когда-нибудь мы сможем получить нормальное поведение терминала по умолчанию в Windows, можем ли мы рассмотреть возможность поставки Джулии терминала, который действительно работает сегодня с широко используемыми версиями Windows? Если бы мы сделали это в 2014 году, вместо того, чтобы решить, что не должны, потому что это должно было быть исправлено, подумайте о том, сколько боли и страданий пользователей Windows можно было бы спасти.

Например, очевидно, что консоль Windows по- прежнему не поддерживает должным образом резервные шрифты для рендеринга символов Юникода, которые недоступны в текущем шрифте? По состоянию на 14 февраля 2019 года они все еще «работают над этим».

В mintty это было исправлено в 2016 году (mintty / mintty # 573) с использованием собственных библиотек Uniscribe от Microsoft.

Нам действительно следует отправить сюда мяту.

Я за мятный, если он работает хорошо, но разве? Сам я с ней не играл, но чтение их номера №56 не вызывает у меня теплого тумана. Еще в 2015 году они специально предостерегали от использования его в интерактивных программах, таких как Python REPL, но, возможно, некоторые из этих проблем уже решены. В последнее время они, похоже, ждут улучшений Windows ConPTY, как и мы. В любом случае, вам должны понравиться теги по этой проблеме: Difficulty-Insane и Priority-None . :)

Есть ли где-нибудь подробное описание всех проблем с консолью Windows? Единственное, что меня действительно раздражает, - это отсутствие запасного шрифта (например, вертикальные эллипсы в rand(40,40) почти никогда не отображаются). С другой стороны, у меня CTRL-C отлично работает как SIGINT, так и как копия, что мне никогда не удавалось хорошо работать на других консолях, с которыми я экспериментировал.

Я предпринял, возможно, безуспешную попытку заставить Джулию и Минтти поиграть еще в # 12879. Кажется, я припоминаю, что я застопорился, когда казалось, что следующим шагом будет поиск способа исправить mintty. Именно тогда я решил, что проблема вышла за рамки, на которые я мог потратить силы.

Я уверен, что с конца 2015 года по настоящее время многое изменилось, но цепочка и работа над этим недоработанным пиаром, вероятно, по-прежнему являются хорошим ориентиром для тех, кто хочет, чтобы это произошло.

mintty - это то, что обычно используют и поддерживают Windows-разработчики Юлии (например, я). Хотя их проблема 56 не вызвала каких-либо конкретных действий вверх по течению, обратите внимание, что мы уже «решили» большинство этих проблем в Джулии (например, см. Мой комментарий в этом выпуске). OTOH, copy (paste) - это ctrl (shift) -insert, и я не думаю, что когда-либо удосужился сделать CTRL-C нефатальным.

Я внимательно следил за этим обсуждением и уже комментировал это раньше. Думаю, если вам действительно нужна эта интеграция, вам лучше сначала исправить # 28891. Это даст вам бесшовную интеграцию без каких-либо изворотливых обходных путей.

Еще одна новость от MS о будущем терминала на Windows здесь . Краткое описание: «Терминал Windows» - это собственный новый терминал Microsoft. Это открытый исходный код, и сейчас его можно скомпилировать и протестировать. Летом 2019 года они отправят бета-версию через магазин Windows, а финальная версия выйдет зимой 2019 года в магазине (по крайней мере, это их план). Они также включают новый шрифт (с открытым исходным кодом) специально для консоли.

Список функций обычно выглядит так, как будто он решит большинство (все?) Проблем, с которыми мы боролись, по крайней мере, для меня он читается как последний недостающий элемент во всем обновлении интерфейса консоли Windows.

Было бы интересно посмотреть, насколько хорошо с этим справляется Юлия. Я подозреваю, что как минимум # 31491 нужно будет исправить на стороне julia, чтобы все работало плавно.

Мне не ясно, на каких версиях Windows это будет работать. Только последняя версия Windows 10 или более широкая поддержка? Мне непонятно.

Похоже, мы этого ждали: https://www.theverge.com/2019/5/6/18527870/microsoft-windows-terminal-command-line-tool

Похоже, @davidanthoff опубликовал то же самое!

Ссылка не для реблоггера: https://devblogs.microsoft.com/commandline/introduction-windows-terminal/

Еще одна причина, по которой я думаю, мы должны просто закрыть этот выпуск. Я действительно не думаю, что Джулия должна отвечать за доставку «годного к употреблению терминала».

В этом потоке упоминается несколько элементов, которые можно исправить, что значительно улучшит работу с терминалом.

Действенный

• [] Поддержка 256 цветов, исправляемая улучшением передачи последовательностей VT в libuv, см. Https://github.com/JuliaLang/libuv/pull/2 https://github.com/JuliaLang/julia/issues/31491 . Здесь есть некоторые проблемы с libuv, которые необходимо решить ( @vtjnash - наиболее осведомленный человек в отношении проблем здесь)

• [] Более удобный режим оболочки https://github.com/JuliaLang/julia/pull/31490

Внешний

• [] Поддержка шрифтов и эмодзи (исправлено в новом терминале Windows). Обратите внимание, что mintty не поддерживает эту функцию, и нет терминала в Windows, чтобы это исправить.
• [] Более приятные функции терминала, такие как режим вставки в скобках и т. Д. Предположительно исправлено за счет улучшения передачи последовательностей VT в сочетании с новым терминалом Windows.

Откат шрифтов и поддержка эмодзи (исправлено в новом терминале Windows). Обратите внимание, mintty не поддерживает это ...

Mintty предоставляет резервные шрифты под управлением Windows и поддерживает эмодзи, включая последовательности эмодзи и предпочтительный стиль отображения эмодзи.

@mintty Кажется, я не могу указать цепочку

Нет, это можно настроить в реестре Windows :(

Похоже, что пройдут годы, прежде чем новый Windows Terminal (в настоящее время находится в «очень ранней альфа-версии») будет установлен на большинстве компьютеров с Windows. Между тем, если бы мы просто использовали дополнительный 1% пространства, необходимого для доставки Mintty, у нас могло бы быть решение прямо сейчас.

Я действительно не думаю, что Джулия должна отвечать за доставку «годного к употреблению терминала».

Тогда у большинства пользователей Windows еще долгие годы будет плохой опыт работы с Julia REPL. В чем проблема с доставкой mintty, кроме усилий по разработке, необходимых для ее плавной интеграции?

Почему бы вам не потратить немного усилий, чтобы исправить проблему сборки на cygwin (упомянутую выше)?
При желании я бы предложил поддерживать пакет cygwin для Джулии.
Это позволит любому запустить Julia в mintty без каких-либо проблем с интеграцией.

Мы обязательно должны отправить его без упаковки. Нет причин не делать этого.

@mintty , это отличное предложение, но я не думаю, что мы хотим требовать от пользователей Windows установки Cygwin, чтобы получить удобный терминал; мы бы очень предпочли поставлять минималистичную сборку Mintty в качестве отдельного терминала с Julia. Поскольку он нужен нам только для запуска Julia, мы можем использовать упомянутые выше stty-хаки, которые уже работают, чтобы избежать необходимости в сборке cygwin (# 24128).

Я думаю, что было бы здорово исправить Mintty, чтобы он был совместим с Julia. Но я думаю, что Mintty должен поставляться только с JuliaPro, а не с Julia; по той же причине, что Juno не входит в стандартный установщик Julia.

Цель Джулии не в том, чтобы поставлять «пригодный для использования» терминал (я заключил его в кавычки, потому что текущий интерфейс терминала пригоден для использования, на самом деле я использую его регулярно / ежедневно и не имею всех жалоб людей). Опыт работы с терминалом не лучше / хуже, чем у Python, и они не поставляются с «пригодным для использования терминалом». Мои основные жалобы на терминал в значительной степени можно исправить, улучшив Julia, и не исправлены отправкой Mintty (см. Https://github.com/JuliaLang/julia/issues/7267#issuecomment-490134045).

Похоже, что пройдут годы, прежде чем новый Windows Terminal (в настоящее время находится в «очень ранней альфа-версии») будет установлен на большинстве компьютеров с Windows. Между тем, если бы мы просто использовали дополнительный 1% пространства, необходимого для доставки Mintty, у нас могло бы быть решение прямо сейчас.

Я считаю преувеличением утверждать, что на строительство нового терминала уйдут годы. По сообщению MSFT, в середине июня официальная предварительная сборка появится в магазине приложений MSFT. И, имея опыт работы с WSL, они быстро улучшали консоль с тех пор, как начали над ней работать.

Таким образом, было бы здорово исправить Mintty с помощью Julia и отправить его с удобным для пользователя дистрибутивом JuliaPro, но доставка Mintty не решает всех наших проблем.

@musm : Рассматриваемая несовместимость

@stevengj : Я понимаю, что вы не хотите использовать cygwin для этой цели, но ошибку сборки все равно нужно исправить, так как трудно понять, что пакет, который строится на Linux, не строится на cygwin.

Я считаю преувеличением утверждать, что на строительство нового терминала уйдут годы.

Конечно, в среде, где у вас есть полный контроль над версией Windows, это было бы разумно. В корпоративных средах пользователи часто отстают на 2-3 версии, поэтому добавьте еще год или два, пока MS не отгрузит новый терминал, пока пользователи Windows в корпоративных средах не получат его в свои руки. Ради всего святого, наша система SAP по-прежнему требует IE11. Не будет даже работать на Edge, не говоря уже о Chrome. С моей точки зрения, доставка Джулии с Mintty из коробки была бы потрясающей.

Целью Джулии не является поставка «годного к употреблению» терминала.

Как доставка приличного терминала отвлечет от цели Джулии? Судя по количеству жалоб за последние годы, кажется довольно очевидным, что лучший терминал позволит избежать множества пользовательских проблем, которые отвлекали от Джулии в Windows. Я не понимаю, в чем вы возражаете, кроме как отрицать наличие проблемы.

И я не сказал, что Microsoft потребуются годы, чтобы «закончить» лучший терминал, я сказал, что потребуются годы, чтобы «установить на большинстве машин с Windows», что, я думаю, очевидно, верно, даже если мы ограничимся научные пользователи / разработчики. Сначала его нужно завершить, затем установить по умолчанию в выпуске Windows, а затем подождать, пока большинство пользователей обновится.

Мои основные претензии к терминалу можно исправить, улучшив Julia.

Так, например, вы не можете исправить отсутствие поддержки альтернативных шрифтов.

Кажется, здесь есть два разных рабочих пакета: а) доставка терминала с julia и b) исправление https://github.com/JuliaLang/julia/issues/31491 (т.е. заставить julia правильно взаимодействовать с консольным API в современной Windows. системы).

Я думаю, что было бы здорово решить обе проблемы, но с ограниченными ресурсами я надеюсь, что мы сможем сначала исправить b). Я думаю, что это принесет больше пользы: он исправит эти вещи во встроенных терминалах в VS Code (конечно) и Juno (я думаю), это будет означать, что julia будет вести себя должным образом во многих отличных сторонних терминалах, поставляемых в настоящее время, и это означает, что он будет правильно работать в следующем терминале Windows. Кроме того, я думаю, что исправление ошибок перед добавлением функций - это хорошо :)

Что касается а), я думаю, что главный вопрос заключается в том, подойдет ли кто-нибудь и сделает это. Если это произойдет, я думаю, было бы важно, чтобы это было как-то необязательно. Например, может быть две опции начального меню: одна для терминала Mintty, другая без и т. Д.

Я не думаю, что кто-то возражает против исправления ошибок / ограничений терминала libuv в Windows. И вы правы в том, что в конечном итоге это зависит от кого-то, кто сделает эту работу. Но я думаю, что излишнее отрицание здесь отговорит людей от работы над этим - почему продвижение # 31491 должно сопровождаться работой по поставке лучшего терминала?

Если это произойдет, я думаю, было бы важно, чтобы это было как-то необязательно.

Вы уже можете запустить Юлию в любом терминале, который захотите. Зачем нам нужен второй вариант консоли в меню «Пуск» или для двойного щелчка?

почему отстаивание # 31491 должно сопровождаться фальшивой работой над поставкой лучшего терминала?

Это вовсе не входило в мои намерения, как я только что написал, я думаю, что поставить терминал получше было бы здорово. Однако я чувствую, что оба проекта прямо сейчас потребуют времени от @vtjnash , и если это так, мне было бы гораздо больше интересно увидеть исправленные проблемы libuv :) Конечно, @vtjnash будет делать то, что он хочет, в любом case, так что просто примите это как список приоритетов от одного пользователя;)

Если это произойдет, я думаю, было бы важно, чтобы это было как-то необязательно.

Вы уже можете запустить Юлию в любом терминале, который захотите. Зачем нам нужен второй вариант консоли в меню «Пуск» или для двойного щелчка?

На самом деле, я не очень хорошо это выразил. На самом деле я имею в виду, что я бы хотел, чтобы обычный ярлык julia в меню «Пуск» запускал julia в Терминале Windows в системах, в которых он есть (после его поставки), а не в mintty. Я не знаю, как это будет работать с точки зрения сроков выпуска релизов, но исходя из информации, которая у нас есть прямо сейчас, кажется вполне разумным предположить, что julia 1.3 и Windows Terminal будут поставляться примерно в одно и то же время (конец года ?), и тогда было бы неплохо, если бы все работало из коробки для пользователей, у которых есть Windows Terminal.

Судя по моему ограниченному пониманию темы, обсуждаемой с

Конечно, работа по упаковке mintty как части Julia, безусловно, может продолжаться в ожидании работы с libuv и исправлений mintty.

Я думаю, что оставил у вас неправильное впечатление о нескольких вещах. В libuv необходимы улучшения для поддержки новых функций conhost (не mintty), чтобы другие программы могли писать в терминал, не испортив julia. Чтобы воспроизвести мою обычную среду разработки для mintty, нам просто нужно изменить копию кода распространения поверх двоичного файла stty.exe уже присутствующего во время сборки. В долгосрочной перспективе мы могли бы подумать о повышении эффективности, перенеся их новый https://github.com/rprichard/wslbridge на Win32 (может быть, это уже https://github.com/rprichard/winpty?) И добавив для этого поддержку, или добавление поддержки ConPty в mintty (~ https: //github.com/mintty/mintty/issues/804~) и добавление тех же вышеупомянутых функций в libuv.

Первая предварительная версия нового Терминала Windows выпущена в магазине Windows, см. Здесь .

@davidanthoff , отлично! Теперь нам просто нужно подождать еще несколько лет, чтобы он появился по умолчанию на большинстве компьютеров с Windows. А пока мы можем что-нибудь отправить?

Это просто проблема загрузки и включения mintty в наши двоичные файлы и, возможно, изменения файла запуска .bat? Очень немногие люди знакомы со сборкой окон Julia. Возможно, только @musm и @staticfloat.

Когда-нибудь мы оглянемся назад и зададимся вопросом, почему мы потратили десять лет на искаженное отображение Unicode на большинстве компьютеров Windows, чтобы сэкономить 1% в размере загрузки, не объединяя mintty…

Теперь, если мы хотим отображать разреженные матрицы шрифтом Брайля и что консоль Windows сломана (https://github.com/JuliaLang/julia/pull/33821#issuecomment-559596284), это веский аргумент, чтобы наконец выпустить Mintty ...

Я думаю, что единственное, что мешает этому на данный момент, - это кто-то подает PR.

Я думаю, было бы замечательно, если бы мы могли _также_ исправить способ взаимодействия Джулии с консольным API в Windows. Прямо сейчас некоторые вещи, которые все исправлены в современных версиях Windows, по-прежнему не работают должным образом, потому что Джулия неправильно использует API.

К сожалению, лишь немногие люди, составляющие релизы Windows Julia, могут практически сделать этот пиар.

Это также не способствует поощрению PR, если буквально каждый раз, когда эта проблема возникает, кучка людей вскакивает, чтобы сказать, что Microsoft исправит это Real Soon Now, и в любом случае мы должны сначала поработать над какой-то другой проблемой и, кстати, выпустить свою Терминал был бы какой-то невыразимой, но необъяснимой бестактностью .

мы должны сначала поработать над другим вопросом

Я специально (и очень нарочно) _не_ сказал этого :) И ни о чем другом, что вы упомянули во втором абзаце.

Несмотря на такие замечания, как «У Windows будет хорошая версия через несколько недель», «с ограниченными [ed] ресурсами, я надеюсь, что мы сможем сначала исправить b)» и «было бы хорошо, если бы это не было по умолчанию», @davidanthoff , правда, есть гораздо более пренебрежительные замечания о доставке мяты от других; Я не собирался выделять тебя.

Cygwin 3.1.0 был выпущен с поддержкой ConPTY. Это означает, что mintty, скорее всего, можно использовать без исправлений.

@mintty Есть ли отдельный двоичный файл, который мы можем связать с установкой Julia?

Нет, кому-то придется собрать его на основе cygwin 3.1.0 и связать с ним библиотеку cygwin DLL.

Хотя это было совсем непросто, благодаря @vtjnash у меня есть рабочий набор двоичных файлов, который я загрузил на https://github.com/JuliaLang/mintty-julia

Попробуйте, запустив path-to-mintty\mintty path-to-julia\julia . Кажется, в значительной степени работает. Я пробовал UnicodePlots и ProgressMeter. Я думаю, что правильным решением будет отправить его как часть Windows-дистрибутива Julia и настроить так, чтобы двойной щелчок по Julia автоматически загружался в mintty.

Эти строки убивают дополнительную консоль, которая, кажется, открывается для меня.

julia> ccall("GetConsoleWindow", stdcall, Ptr{Cvoid}, ())
Ptr{Nothing} <strong i="11">@0x00000000001b0090</strong>

julia> ccall(("ShowWindow","user32"), stdcall, Cint, (Ptr{Cvoid}, Cint), ans, 0)

24

Было бы здорово, если бы люди попробовали это и помогли сделать его частью установщика julia.

Большой!

Работает в моей системе (то же самое с дополнительной консолью, которую нужно убить с помощью вашего кода). Я использую последнюю версию Windows 10.

Можно ли увеличить шрифт по умолчанию? Все началось с размера шрифта 9pt, что выглядело не очень хорошо.

Где хранятся настройки для этого? Наверное в реестре где-нибудь? В конкретном месте Джулии? Я думаю, это было бы лучше, чем делиться с другими установками mintty? И мы должны убедиться, что установщик удаляет эти настройки во время удаления.

Думаю, в диспетчере задач тоже не очень хорошо смотрится, вот что я получаю после его запуска:

Было бы лучше, если бы для Джулии была запись верхнего уровня, как сегодня, когда Джулия запускается с помощью ярлыка:

О, и только что заметил еще одну вещь: также было бы хорошо, если бы значок (как в окне, так и на панели задач) был значком Джулии, а не значком Mintty.

Просто из любопытства (не думаю, что это важно): поддерживает ли это вкладки?

И еще одна (не очень важная) идея: можем ли мы сделать комбинации клавиш копирования / вставки по умолчанию такими же, как и в Windows Terminal? Это будет Ctrl+Shift+C и Ctrl+Shift+V .

Думаю, это появится в следующем выпуске патча https://github.com/mintty/mintty/issues/8?

Я думаю, что где-то может быть файл .minttyrc чтобы сохранить значения по умолчанию.

В конце концов, нам нужно каким-то образом настроить все, чтобы окно консоли не открывалось, а не открывалось и сразу закрывалось, что было бы раздражающей вспышкой каждый раз, когда вы запускаете Julia.

@musm Похоже, вы больше всего знаете о процессе установки Windows. У вас будет время, чтобы помочь интегрировать mintty в установщик Windows?

Возможно, шрифты DejaVu также необходимо установить и использовать в mintty по умолчанию, чтобы максимально эффективно использовать Unicode, по крайней мере, в Windows 7.

https://github.com/JuliaLang/julia/blob/master/doc/build/windows.md

Возможно, Windows 10 в этом отношении лучше.

Мне нравится эта идея, и я попробовал. Вот что я испытал:

• Я попытался изменить рабочий каталог в julia с помощью cd() но это не удалось.
• Ctrl + C не прерывает работу функции, но убивает Джулию.
• Печать большего количества текстов (например, shell> git status в каталоге git) кажется медленнее, чем то же самое из командной строки.
• Я счастлив, что наконец-то вижу значок закрепленных пакетов (⚲)
• И я согласен с тем, что по умолчанию следует установить более крупный шрифт.

Когда просто запускаю julia, работает:

C:\Users\cstamas\Documents\GIT\mintty-julia>julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.3.1 (2019-12-30)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> pwd()
"C:\\Users\\cstamas\\Documents\\GIT\\mintty-julia"

julia> cd(raw"C:\Users\cstamas\Documents\GIT\JuDocPlottest")

julia> pwd()
"C:\\Users\\cstamas\\Documents\\GIT\\JuDocPlottest"

julia>  

И командой:

C:\Users\cstamas\Documents\GIT\mintty-julia>mintty.exe -ha julia

Я получил:

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.3.1 (2019-12-30)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> pwd()
"C:\\Users\\cstamas\\Documents\\GIT\\mintty-julia"

julia> cd(raw"C:\Users\cstamas\Documents\GIT\JuDocPlottest")

julia> ERROR: IOError: could not spawn `stty raw -echo onlcr -ocrnl opost`: no such file or directory (ENOENT)
Stacktrace:
 [1] _spawn_primitive(::String, ::Cmd, ::Array{Any,1}) at .\process.jl:99
 [2] #554 at .\process.jl:112 [inlined]
 [3] setup_stdios(::Base.var"#554#555"{Cmd}, ::Array{Any,1}) at .\process.jl:196
 [4] _spawn at .\process.jl:111 [inlined]
 [5] #run#565(::Bool, ::typeof(run), ::Cmd, ::Base.TTY, ::Vararg{Base.TTY,N} where N) at .\process.jl:439
 [6] run(::Cmd, ::Base.TTY, ::Vararg{Base.TTY,N} where N) at .\process.jl:438
 [7] raw!(::REPL.Terminals.TTYTerminal, ::Bool) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\Terminals.jl:129
 [8] prompt!(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\LineEdit.jl:2383
 [9] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\LineEdit.jl:2301
 [10] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\REPL.jl:1045
 [11] run_repl(::REPL.AbstractREPL, ::Any) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\REPL.jl:201
 [12] (::Base.var"#770#772"{Bool,Bool,Bool,Bool})(::Module) at .\client.jl:382
 [13] #invokelatest#1 at .\essentials.jl:709 [inlined]
 [14] invokelatest at .\essentials.jl:708 [inlined]
 [15] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at .\client.jl:366
 [16] exec_options(::Base.JLOptions) at .\client.jl:304
 [17] _start() at .\client.jl:460
julia: Exit 1.

Следующая команда выдает ту же ошибку:

C:\Users\cstamas\Documents\GIT\mintty-julia>mintty.exe --dir C:\Users\cstamas\Documents\GIT\JuDocPlottest\ -ha julia

Результат:

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.3.1 (2019-12-30)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

ERROR: IOError: could not spawn `stty raw -echo onlcr -ocrnl opost`: no such file or directory (ENOENT)
Stacktrace:
 [1] _spawn_primitive(::String, ::Cmd, ::Array{Any,1}) at .\process.jl:99
 [2] #554 at .\process.jl:112 [inlined]
 [3] setup_stdios(::Base.var"#554#555"{Cmd}, ::Array{Any,1}) at .\process.jl:196
 [4] _spawn at .\process.jl:111 [inlined]
 [5] #run#565(::Bool, ::typeof(run), ::Cmd, ::Base.TTY, ::Vararg{Base.TTY,N} where N) at .\process.jl:439
 [6] run(::Cmd, ::Base.TTY, ::Vararg{Base.TTY,N} where N) at .\process.jl:438
 [7] raw!(::REPL.Terminals.TTYTerminal, ::Bool) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\Terminals.jl:129
 [8] prompt!(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\LineEdit.jl:2383
 [9] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\LineEdit.jl:2301
 [10] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\REPL.jl:1045
 [11] run_repl(::REPL.AbstractREPL, ::Any) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\REPL.jl:201
 [12] (::Base.var"#770#772"{Bool,Bool,Bool,Bool})(::Module) at .\client.jl:382
 [13] #invokelatest#1 at .\essentials.jl:709 [inlined]
 [14] invokelatest at .\essentials.jl:708 [inlined]
 [15] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at .\client.jl:366
 [16] exec_options(::Base.JLOptions) at .\client.jl:304
 [17] _start() at .\client.jl:460
julia: Exit 1.

Я не уверен, что происходит, потому что я не могу запустить mintty из другой папки:

C:\Users\cstamas\Documents\GIT\JuDocPlottest>C:\Users\cstamas\Documents\GIT\mintty-julia\mintty.exe -ha julia

Результаты в:

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.3.1 (2019-12-30)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

ERROR: IOError: could not spawn `stty raw -echo onlcr -ocrnl opost`: no such file or directory (ENOENT)
Stacktrace:
 [1] _spawn_primitive(::String, ::Cmd, ::Array{Any,1}) at .\process.jl:99
 [2] #554 at .\process.jl:112 [inlined]
 [3] setup_stdios(::Base.var"#554#555"{Cmd}, ::Array{Any,1}) at .\process.jl:196
 [4] _spawn at .\process.jl:111 [inlined]
 [5] #run#565(::Bool, ::typeof(run), ::Cmd, ::Base.TTY, ::Vararg{Base.TTY,N} where N) at .\process.jl:439
 [6] run(::Cmd, ::Base.TTY, ::Vararg{Base.TTY,N} where N) at .\process.jl:438
 [7] raw!(::REPL.Terminals.TTYTerminal, ::Bool) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\Terminals.jl:129
 [8] prompt!(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\LineEdit.jl:2383
 [9] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\LineEdit.jl:2301
 [10] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\REPL.jl:1045
 [11] run_repl(::REPL.AbstractREPL, ::Any) at D:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.3\REPL\src\REPL.jl:201
 [12] (::Base.var"#770#772"{Bool,Bool,Bool,Bool})(::Module) at .\client.jl:382
 [13] #invokelatest#1 at .\essentials.jl:709 [inlined]
 [14] invokelatest at .\essentials.jl:708 [inlined]
 [15] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at .\client.jl:366
 [16] exec_options(::Base.JLOptions) at .\client.jl:304
 [17] _start() at .\client.jl:460
julia: Exit 1.

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.3.1 (2019-12-30)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> using JuDoc

julia> serve()
Activating environment at `C:\Users\cstamas\Documents\GIT\JuDocPlottest\Project.toml`
→ Initial full pass...
┌ Warning: I found an {{insert ...}} block and tried to insert 'C:\Users\cstamas\Documents\GIT\JuDocPlottest\src\_html_parts\..\..\assets\menu7\test\plotly1.html' but I couldn't find the file. Ignoring.
└ @ JuDoc C:\Users\cstamas\.julia\packages\JuDoc\Q8uS7\src\converter\html_functions.jl:60
→ Starting the server...
✓ LiveServer listening on http://localhost:8000/ ...
  (use CTRL+C to shut down)
julia: Interrupt.

Если вам нужен более естественный опыт, новый терминал Windows можно установить из Магазина Windows.

Он еще не поддерживает эмодзи (скоро появится), но другой юникод работает хорошо. UnicodePlots работает. На самом деле, даже смайлы работают, если вы подключаетесь к оболочке Linux (через WSL или SSH). Пользуюсь им последние несколько месяцев и не пропустил свой терминал OSX.

Я не знал, что он доступен в магазине приложений. Следует ли это просто задокументировать - чтобы люди могли получить терминал Windows в магазине приложений или загрузить mintty с нашего сайта?

По-видимому, Windows 7 EOL вышла пару дней назад: https://support.microsoft.com/en-us/help/4057281/windows-7-support-ended-on-january-14-2020

@aviks , глупый вопрос: заставляет ли это ;ls работать так, как ожидают те из нас, кто имеет укоренившиеся привычки Linux? Если да, вы просто устанавливаете Терминал Windows, а затем запускаете julia из его приглашения?

Я думаю, вы буквально просто получите терминал. Так что режим оболочки, вероятно, ничего не сделает. Но вы можете установить WSL и Ubuntu или что-то еще, чтобы получить все это.

Да, это в основном эмулятор терминала (и хост консоли). Внутри него все еще работает оболочка Windows (Cmd или PS), поэтому встроенные функции оболочки не работают в соответствии с этой старой проблемой: https://github.com/JuliaLang/julia/issues/6316

Если вам нужна оболочка Linux, то WSL довольно прост в использовании (я использую его часто), но это, конечно, дополнительный уровень.

По-видимому, вам нужно обновление Windows 10 1903 для Терминала, которое было выпущено в мае 2019 года. Похоже, что это автоматическое обновление, поэтому оно должно быть у всех пользователей Windows 10.

https://github.com/microsoft/terminal#prerequisites

Была ли заброшена идея связать Git bash с Джулией? Это решило бы как проблему приличного терминала, так и базовую функциональность оболочки.

почти у всех пользователей Windows 10 это должно быть

К сожалению, еще не совсем. Многие компании медленно обновляются. В этом отчете за октябрь 2019 года около 40% используют старые сборки: https://reports.adduplex.com/#/r/2019 -10

Как упоминалось выше в https://github.com/JuliaLang/julia/issues/7267#issuecomment -505099197:

Теперь нам просто нужно подождать еще несколько лет, чтобы он появился по умолчанию на большинстве компьютеров с Windows. А пока мы можем что-нибудь отправить?

Я наконец-то понял, как получить точное разделение ОС на основе наших данных телеметрии VS Code, и я сообщу, как только переведу его в более удобный формат. Это должно дать нам хорошее представление о том, сколько людей использует какую версию Windows.

Основная проблема, как и в случае шпионского сюжета с шаблоном Брайля, заключается в том, что нам необходимо 100% покрытие на всех поддерживаемых платформах.

Как mintty устраняет недостаток режима «оболочки» в Windows? Нет, или я ошибаюсь?

Этот вопрос касается неисправного терминала, а не неисправной оболочки.

Да, но почему бы не подумать об обоих одновременно? Выход есть ...

Вот разделение пользователей, которое у нас есть для расширения VS Code, я думаю, что-то вроде последних 90 дней или около того (не совсем уверен насчет временного окна):

Да, но почему бы не подумать об обоих одновременно? Выход есть ...

Может отдельная тема? Я чувствую, что это уже поздно, и мы должны его принять. Замените его на что-нибудь получше позже, когда оно будет готово.

Мне кажется хорошим продолжить поставки мяты; людям не обязательно его использовать, но, по крайней мере, это хороший готовый опыт. Надо было сделать много лет назад, но лучше поздно, чем никогда.

Это будет улучшение, это ясно.

В чт, 16 января 2020 г., 16:51 Стефан Карпински [email protected]
написал:

Мне кажется хорошим продолжить поставки мяты; людям не нужно
используйте его, но, по крайней мере, это хороший готовый опыт. Должен иметь
было сделано много лет назад, но лучше поздно, чем никогда.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/JuliaLang/julia/issues/7267?email_source=notifications&email_token=ACLGGWBWIMVNME772K5KVQDQ6D6KDA5CNFSM4AQRFZ6KYY3PNVWWK3TUL52HSG43JNVI8CNVWWK3TUL52XG4DFVWK3TREVMXW2CXWMXWMXWM8CXWM8CMXWM8CXWM8
или отписаться
https://github.com/notifications/unsubscribe-auth/ACLGGWCHSZ3HAHZTZNSHYNDQ6D6KDANCNFSM4AQRFZ6A
.

Для меня ctrl-c не убивает терминал, а ctrl-d работает правильно.
cd не работает и вызывает сбой mintty / julia.

Кажется, что настройки также нельзя сохранить на диск, поскольку mintty жалуется на несуществующий файл .minttyrc, хотя я создал его вручную. Возможно, это общая проблема с файловой системой.

К вашему сведению, самая свежая версия - 3.0.2, которая не является последней.

Кроме того, у меня не возникает никаких проблем, когда я использую версию, поставляемую с MSYS2, так что это, вероятно, проблемы с компиляцией.

Я предполагаю, что ctrl-c будет mintty вместо Julia. Возможно, есть способ изменить эти значения по умолчанию. Мне пришлось использовать мяту, которую мне предоставил

Я заметил, что предоставленный вами двоичный файл mintty оставляет пустое пустое окно «mintty.exe» при запуске julia через командную строку с «mintty% julia path% julia.exe». Если я отправлю ctrl + c в это пустое окно, он прервет выполнение кода в julia, не закрывая mintty.exe. Это не то поведение, которое я наблюдаю в mintty 2.9.5. По крайней мере, в качестве дрянной работы мы можем легко скрыть дополнительное окно, перехватить ctrl + c, пока julia REPL является активным окном, и перенаправить его в скрытое окно mintty.exe.

Однако есть одна проблема: ctrl + c, отправленная, когда julia не выполняет код, приведет к его выходу.

РЕДАКТИРОВАТЬ:
Похоже, что байт в ячейке памяти 0x1004AA3C8 хранит состояние выполнения julia. 1 = готово, 0 = занято. Это для 64-битного julia.exe.

EDIT2: адрес предназначен для Mintty.exe, на котором размещается julia.exe.
Я сделал два скрипта на основе моего предыдущего поста. Один использует Mintty 3.0.2 , который Другой - с использованием Mintty 2.9.5 . Последний не дает сбоев при cd () и вместо отправки нажатий клавиш отправляет SIGINT напрямую julia.exe через Windows API.

Недавно я нашел этот новый кроссплатформенный и настраиваемый терминал. Он поддерживает

• Гиперссылки
• Образ
• Поддержка мыши
• ...
  https://github.com/ismail-yilmaz/upp-components/tree/master/CtrlLib/Terminal

Он поддерживает Linux, Windows, macOS и даже веб-браузер!
Смотрите демо здесь:

Windows Terminal 1.0 отправлен сегодня .

Терминал Windows - это то, что нужно использовать. Однако проблема в том, что, похоже, требуется гораздо более новая версия Windows, чем та, которую мы поддерживаем. Можно ли отправить Терминал Windows (не знаю, насколько это просто) и вернуться к cmd, если он не запускается?

winget решает за нас все эти проблемы?

Можно уже закрыть этот вопрос? Мы явно никогда не собираемся ничего с этим делать.

Терминал Windows не является сам по себе терминалом. Это диспетчер терминалов, использующий другие терминалы. Если мы хотим использовать терминал Microsoft, мы должны использовать PowerShell Core.

Я предложил здесь настоящий терминал с поддержкой мыши и изображений.
https://github.com/JuliaLang/julia/issues/7267#issuecomment -583810189

Можно уже закрыть этот вопрос? Мы явно никогда не собираемся ничего с этим делать.

100% Пожалуйста, сделайте это. Ничего продуктивного из этого обсуждения не получилось.

Можно уже закрыть этот вопрос? Мы явно никогда не собираемся ничего с этим делать.

100% Пожалуйста, сделайте это. Ничего продуктивного из этого обсуждения не получилось.

Этот вопрос еще не решен. Для отказа от уведомлений есть кнопка отказа от подписки.

Большинство (все?) Проблем с неадекватным доступом к средствам операционной системы через режим оболочки можно решить, запустив редактор из Git bash. Например, VS code, Atom, Sublime Text. Все будет запускать Джулию в совместимом эмуляторе терминала с ожидаемыми командами Linux, работающими в режиме оболочки. На мой взгляд, добавление поддержки Windows Terminal не добавит ничего, кроме сложности.

Для отказа от уведомлений есть кнопка отказа от подписки.

Хорошая точка зрения. Это официально первый выпуск Джулии, от которого я отказался от подписки. Кто-нибудь пришлет мне голограмму, когда эта проблема будет ~ решена ~ закрыта без каких-либо действий в 2026 году 👋🏼

Я установил Git-Bash и просто использовал его.

Терминал Windows не является сам по себе терминалом. Это диспетчер терминалов, использующий другие терминалы. Если мы хотим использовать терминал Microsoft, мы должны использовать PowerShell Core.

Я предложил здесь настоящий терминал с поддержкой мыши и изображений.
# 7267 (комментарий)

Это неправда. PowerShell Core, или теперь просто PowerShell (начиная с версии 7), представляет собой _shell_, как и cmd, pwsh и bash. С другой стороны, Windows Terminal - это _console или terminal_, как и множество других доступных терминалов, включая MinTTY, ConEmu и т. Д.

Я имею в виду графический интерфейс терминала / консоли / оболочки. Меня не волнует имя. У Джулии уже есть REPL со своими правилами, и использование его из CMD аналогично использованию из PowerShell. Хорошая причина использовать что-то новое - добавить некоторые функции графического интерфейса.

Терминал Windows не добавляет много функций графического интерфейса, и для его вызова требуется оболочка (например, CMD или PowerShell).

Тогда можем ли мы перестать беспокоиться о проблемах с отображением Unicode для людей, использующих консоль Windows?

Например, можем ли мы объединить # 33821 и сказать пользователям Windows, которым не нравится видеть разреженные матрицы, отображаемые как ?????? загрузить более совершенный терминал?

Или мы продолжим ограничивать наши возможности отображения низкой полосой, установленной консолью Windows в течение следующих 5-10 лет, пока терминал Windows не станет по умолчанию во всех поддерживаемых системах Windows? (В настоящее время мы поддерживаем Windows 7, выпущенную 11 лет назад. Сколько времени пройдет, пока мы не прекратим поддержку всех систем Windows, которые не поставляются с Windows Terminal?)

Например, можем ли мы объединить # 33821 и сообщить пользователям Windows, которым не нравится видеть разреженные матрицы, отображаемые как ?????? скачать лучший терминал?

ИМО, некоторые могут не согласиться, но я думаю, что это вполне разумный подход, поскольку он позволяет нам вводить новшества. Мы можем добавить Windows 7 в список «поддерживаемых», но не все функции с точки зрения рендеринга шрифтов могут быть доступны по умолчанию без установки лучшего терминала в список платформ.

Хотя Windows 10 остается полностью поддерживаемой, мы добавляем ссылку на новый Терминал Windows. Например, этот PR отлично отображается с новым Терминалом, поскольку он также включает приличный шрифт с лигатурами.

Думаю, надо объединиться и двигаться дальше. Учитывая обилие вариантов, не стоит считать это нашей проблемой. Я также считаю, что это разумный способ закрыть эту проблему - мы не отправляем терминал (мы не отправляем его ни на одной ОС).

Хорошо.

(Для Windows всегда были лучшие терминалы, поэтому я ожидаю, что выпуск Windows Terminal ничего не решит в течение нескольких лет, пока он не станет стандартным - это не остановит бесконечный поток жалоб на рендеринг Unicode. в Windows. Большинство пользователей Windows до сих пор не знают, как запустить Джулию в более совершенном терминале. Но если мы официально откажемся от готовых решений и скажем: «Получите лучший терминал», я думаю, это один из способов ответьте на эти вопросы.)

Да, были доступны терминалы получше, но мне почему-то кажется, что сегодня их гораздо проще установить, чем год назад.

Чтобы избежать жалоб - есть ли способ проверить, используется ли "хороший" терминал, чтобы можно было выдать предупреждение?

Многие пользователи Windows в настоящее время также используют Juno / vs-code, который, вероятно, нормально работает с отображением Unicode.

Как и в случае с другими ОС, теперь мы будем ожидать, что пользователи «принесут свой собственный терминал». Когда Терминал Windows станет более распространенным, мы надеемся обнаружить его и запустить Юлию с его помощью и т. Д.

Обновлена ​​документация по терминалам, и мы также обновили страницу загрузок, чтобы требовать Windows 10.