В Windows пакеты, установленные с помощью cabal, кажутся недоступными в ghc / ghci

#windows #haskell #cabal #haskell-platform

#Windows #haskell #cabal #haskell-платформа

Вопрос:

Я использую последнюю версию платформы Haskell 8.6.3 в довольно стандартной системе Windows 10 x64.

Теперь я нахожусь в тупике, чтобы установить пакеты из Hackage для надежной работы. Приписывая мои проблемы проблемам локальной конфигурации, я предпринял все шаги, за исключением запуска моей установки Windows. Я удалил и переустановил Hackage, перезагрузился, просмотрел все последние файлы конфигурации, которые мог, в любом скрытом каталоге или иным образом, удалил все разделы реестра, по-видимому, связанные с Haskell, большинство из них несколько раз, все безрезультатно:

Пакеты, установленные с помощью cabal, просто недоступны в ghci, WinGHCi, либо для интерактивной загрузки с помощью (: m) в ghci, либо при компиляции с использованием ghc в WinGHCi, независимо от того, что я делаю.

Ниже приведены некоторые симптомы. Есть предложения?

 #cabal new-update
Downloading the latest package list from hackage.haskell.org
To revert to previous state run:
    cabal new-update 'hackage.haskell.org,2019-04-02T19:24:19Z'

#cabal new-install --lib vector
Resolving dependencies...
Up to date

#ghci
Prelude> :m Data.Vector

<no location info>: error:
    Could not find module ‘Data.Vector’
    Perhaps you meant Data.Functor (from base-4.12.0.0)

#ghc -O -optc-O3 -funfolding-use-threshold=16 -fexcess-precision -Wall -Wno-type-defaults -Wno-unused-imports -Wno-unused-top-binds -rtsopts "P663.hs"
[1 of 1] Compiling Main             ( P663.hs, P663.o )

P663.hs:54:1: error:
    Could not find module ‘Data.Vector.Unboxed’
    Use -v to see a list of the files searched for.
   |
54 | import           Data.Vector.Unboxed (Vector, (!))    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 #ghc-pkg list
C:Program FilesHaskell Platform8.6.3libpackage.conf.d
    Cabal-2.4.0.1
    Win32-2.6.1.0
    array-0.5.3.0
    base-4.12.0.0
    binary-0.8.6.0
    bytestring-0.10.8.2
    containers-0.6.0.1
    deepseq-1.4.4.0
    directory-1.3.3.0
    filepath-1.4.2.1
    (ghc-8.6.3)
    ghc-boot-8.6.3
    ghc-boot-th-8.6.3
    ghc-compact-0.1.0.0
    ghc-heap-8.6.3
    ghc-prim-0.5.3
    ghci-8.6.3
    haskeline-0.7.4.3
    hpc-0.6.0.3
    hscolour-1.24.4
    integer-gmp-1.0.2.0
    libiserv-8.6.3
    mtl-2.2.2
    parsec-3.1.13.0
    pretty-1.1.3.6
    process-1.6.3.0
    rts-1.0
    stm-2.5.0.0
    template-haskell-2.14.0.0
    text-1.2.3.1
    time-1.8.0.2
    transformers-0.5.5.0
    xhtml-3000.2.2.1

#ghc-pkg list --user-package-db=C:UsersCarlAppDataRoamingcabalstoreghc-8.6.3package.db
C:Program FilesHaskell Platform8.6.3libpackage.conf.d
    Cabal-2.4.0.1
    Win32-2.6.1.0
    array-0.5.3.0
    base-4.12.0.0
    binary-0.8.6.0
    bytestring-0.10.8.2
    containers-0.6.0.1
    deepseq-1.4.4.0
    directory-1.3.3.0
    filepath-1.4.2.1
    (ghc-8.6.3)
    ghc-boot-8.6.3
    ghc-boot-th-8.6.3
    ghc-compact-0.1.0.0
    ghc-heap-8.6.3
    ghc-prim-0.5.3
    ghci-8.6.3
    haskeline-0.7.4.3
    hpc-0.6.0.3
    hscolour-1.24.4
    integer-gmp-1.0.2.0
    libiserv-8.6.3
    mtl-2.2.2
    parsec-3.1.13.0
    pretty-1.1.3.6
    process-1.6.3.0
    rts-1.0
    stm-2.5.0.0
    template-haskell-2.14.0.0
    text-1.2.3.1
    time-1.8.0.2
    transformers-0.5.5.0
    xhtml-3000.2.2.1

C:UsersCarlAppDataRoamingcabalstoreghc-8.6.3package.db
    primitive-0.6.4.0
    vector-0.12.0.2

#set GHC_PACKAGE_PATH=C:UsersCarlAppDataRoamingcabalstoreghc-8.6.3package.db;
#ghc-pkg list
C:Program FilesHaskell Platform8.6.3libpackage.conf.d
    Cabal-2.4.0.1
    Win32-2.6.1.0
    array-0.5.3.0
    base-4.12.0.0
    binary-0.8.6.0
    bytestring-0.10.8.2
    containers-0.6.0.1
    deepseq-1.4.4.0
    directory-1.3.3.0
    filepath-1.4.2.1
    (ghc-8.6.3)
    ghc-boot-8.6.3
    ghc-boot-th-8.6.3
    ghc-compact-0.1.0.0
    ghc-heap-8.6.3
    ghc-prim-0.5.3
    ghci-8.6.3
    haskeline-0.7.4.3
    hpc-0.6.0.3
    hscolour-1.24.4
    integer-gmp-1.0.2.0
    libiserv-8.6.3
    mtl-2.2.2
    parsec-3.1.13.0
    pretty-1.1.3.6
    process-1.6.3.0
    rts-1.0
    stm-2.5.0.0
    template-haskell-2.14.0.0
    text-1.2.3.1
    time-1.8.0.2
    transformers-0.5.5.0
    xhtml-3000.2.2.1

C:UsersCarlAppDataRoamingghcx86_64-mingw32-8.6.3package.conf.d
    (no packages)
C:UsersCarlAppDataRoamingcabalstoreghc-8.6.3package.db
    primitive-0.6.4.0
    vector-0.12.0.2

# ghci
GHCi, version 8.6.3: http://www.haskell.org/ghc/  :? for help
Prelude> :m Data.Vector
Prelude Data.Vector> toList $ empty

Access violation in generated code when reading 0xffffffffffffffff

 Attempting to reconstruct a stack trace...

   Frame        Code address
 * 0x7e5dd90    0x3d7d618 C:Program FilesHaskell Platform8.6.3binghc.exe 0x397d618
  

Комментарии:

1. В какой-то момент я даже не смог скомпилировать проект шаблона со свежей загрузкой haskell-platform в Windows. Мне пришлось вернуться к более ранней версии ghc, чтобы все заработало, а затем пару месяцев спустя или около того я смог обновиться до последней версии, и это сработало. Возможно, стоит попробовать понизить некоторые вещи, чтобы посмотреть, работает ли это.

2. Мое предложение — делать то, что, как вы знаете, вы должны делать, и использовать unix. Вы можете установить образ в Windows. Оттуда вы можете использовать stack.

3. Это может быть случай, когда работа по потоку выполняется быстрее. Emacs создает прекрасную среду разработки, но для этого потребуется изучить «Способ Emacs». Если вам не нужно ничего, кроме цветовых подсказок, графический vim может соответствовать вашим требованиям.

4. Я не знаю, насколько недавней является ваша установка, но я только что установил haskell на свой компьютер с Windows с нуля около месяца назад, и все это сработало , но я избегал платформы Haskell как чумы и просто установил stack. Это было довольно гладко

5. Я использую stack как в Linux, так и в Windows, поэтому, чтобы быть уверенным, что я работаю с набором пакетов, который не конфликтует. Хотя у него есть свои недостатки (IMO), он значительно упростил обработку пакетов.

Ответ №1:

Похоже, вы решили свою проблему, установив GHC_PACKAGE_PATH , верно? Возможно, вы захотите сообщить об ошибке по этому поводу.

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

https://github.com/commercialhaskell/stack/issues/3765

https://gitlab.haskell.org/ghc/ghc/issues/13112

Предположительно, переход -fexternal-interpreter на ghci является обходным путем. Возможно, вы захотите вручную отредактировать скрипты ghc / ghci shim, чтобы убедиться, что флаг всегда передается, пока ошибка не будет исправлена.

Комментарии:

1. Спасибо за предложение! Я подумал, что сбой может быть связан с тем, что я все еще не правильно установил установку, даже с GHC_PACKAGE_PATH. Но это вполне может быть отдельной ошибкой.

2. К сожалению, добавление -fexternal-interpreter флага не исправляет это, а вместо этого слегка изменяет сообщение и приводит к зависанию ghci, а не к завершению: $ ghci -fexternal-interpreter ... Prelude Data.Vector> toList $ empty Access violation in generated code when reading 0xffffffffffffffff Attempting to reconstruct a stack trace... Frame Code address * 0x486dd90 0xe1e1f8 C:Program FilesHaskell Platform8.6.3libbinghc-iserv.exe 0xa1e1f8

Ответ №2:

Спасибо за все ответы. Я экспериментировал как с запуском ghc на некоторой версии UN * X под VirtualBox, так и с удалением платформы Haskell и переходом исключительно на stack под Windows 10 x64.

Оба, похоже, позволяют избежать многих проблем, которые я перечислил выше, но stack под Windows кажется немного более легким и лучше интегрируется с моими предпочтительными редакторами (Sublime Text и Visual Studio Code), так что это то, чем я сейчас занимаюсь.

В то же время, при всей должной благодарности за всю отличную бесплатную работу, проделанную ребятами из платформы Haskell и автором WinGHCi, я не могу призвать кого-либо, кто читает это достаточно сильно, держаться подальше от этого, в частности версии 8.6.3 под Windows, по крайней мере, до тех пор, пока ситуация не улучшится.

Комментарии:

1. Это не имеет никакого отношения к платформе. интерпретатор объектного кода был сломан в ghc 8.6.3 в Windows. Для решения этой проблемы была выпущена версия 8.6.4.

2. Достаточно справедливо. К сожалению, платформа все еще застряла на 8.6.3, поэтому посторонним сложно сказать.