alar

шекспировский вопрос

Fri, 25 Dec 2009 13:06:38 GMT

AMD Geode или Vortex86DX?

Нужно выбрать процессор для промышленного компа. В современные процессоры принято засовывать кучу полезного барахла: видео, изернет, USB, контроллер памяти. Выбор из трёх вариантов, но VIA я отметаю не глядя. Вопрос - с каким из двух оставшихся больше шансов наступить на грабли? И плевать на производительность: всё равно ввод-вывод съест больше 50% процессорного времени, а 5-10% оставшегося хватит на все задачи.

Много картинок и зверюшек

Wed, 23 Dec 2009 06:57:05 GMT

Вот тута: http://drvini.livejournal.com/

via alexeynagaev

Как ведутся холиворы

Tue, 22 Dec 2009 15:15:34 GMT

http://arbat.livejournal.com/404429.html
Текст, вроде бы, серьёзный, но я ржал.

Предвкушая наступающий HUG

Mon, 14 Dec 2009 14:41:27 GMT

Подскажите, унификация в суперкомпиляторах и в прологе - неслучайно одинаково называется?

затуп мозга, haskell

Sun, 01 Nov 2009 14:56:30 GMT

Есть индуктивный тип данных, примерно такое
data InType = In1 InType | In2 InType InType | InL [InType] | In0
и тип, полученный из него разложением на составляющие:
type Key = String
data OutType = Out1 Key | Out2 Key Key | OutL [Key] | Out0

и таких пар несколько (штуки 4). Везде структура сторого типа в точности повторяет структуру первого, за исключением рекурсивности. Как бы сэкономить и не писать такие повторения руками? И вообще, что тут можно сэкономить?
Есть соблазн в каждое рекурсивное вхождение воткнуть Either InType Key, но это перегрузит доступ к типу сборками-разборками Either. И ваще как-то некрасиво.

Боевые промышленные фидорасы

Thu, 29 Oct 2009 14:45:00 GMT

Обнаружил на сервере - регистраторе аварийных ситуаций и прочих полезных параметров DOS-окошко с заголовком
2:5020/795. Удивлён.

Сборка мусора. Вопрос

Thu, 08 Oct 2009 09:21:19 GMT

Где-то я видел ссылку на статью про способ учесть циклические ссылки при сборке мусора путём подсчёта ссылок. Подскажите.

Умные книжки

Fri, 18 Sep 2009 13:20:41 GMT

Немного обозначений из умных книжек:
1. Г |- x ::y "Имеет тип"
В контексте Г x имеет тип y. Справа от знака |- всегда ставится обозначение типа.
2.X Y
-------
Z
"Следует" или "получается". Речь идёт о правилах вывода или системе переписывания. Следует в логике "хост-языка", который заложен в голове у авторов или в реализации языка программирования / системы доказательств. А не в логике предметного языка, поэтому не используется обычное "=>". Сверху от знака "---" перечисляются предпосылки, обычно через пробел, снизу - результат.
3. В логике иногда |= значит "истинно", а |- - "выводимо". Слева стоит контекст, справа выражение, о котором речь.
4. ∀x:X.Y или Πx:X.Y это, оказывается, одно и то же - тип зависимых функций. Частный случай этого типа X => Y (в хаскеле стрелочка такая: ->) , а общий случай отличается от него тем, что в Y может входить переменная x.
5. ∃x:X.Y или Σx:X.Y - тип зависимых пар. Частный случай - тип X × Y (он же X ∧ Y) (в хаскеле (X,Y)), в общем случае в Y может входить x.
to be continued

Про ОПК

Wed, 09 Sep 2009 14:56:07 GMT

http://www.livejournal.ru/themes/id/14883
Вот какое учебное пособие подошло бы для этого предмета.

USB. Как сделать на коленке?

Mon, 10 Aug 2009 07:03:06 GMT

Как быстро сделать устройство ввода данных со скоростью потока до 80 Мбит/с? Данные сыплются непрерывно (это выход с быстрого АЦП). Верно ли, что USB - подходящий интерфейс для такой задачи?

Спамим-спамим!

Tue, 21 Jul 2009 18:28:19 GMT

Первый номер журнала "Практика функционального программирования"

Как это обычно говорится? Срочно выводим в топ!

Мнение: автору статьи о моноидах - респект, статью о состоянии потестю на явщиках. Перевод The Gentle Introduction - это круто, моя первая книжка про Haskell.
Если найду время - попробую помедитировать над адептовскими шашками.

Почему gawk лучше чем Perl

Thu, 16 Jul 2009 13:22:49 GMT

http://swtch.com/~rsc/regexp/regexp1.html
Вкратце: PCRE - на самом деле не совсем регэкспы, и не разбираются конечным автоматом. Поэтому, в перле сложный матчер, который, если знать как, очень легко загнать в экспоненциальное поведение (и Stack Overflow).

ОБН: Для перла уже неактуально

Зависимые типы. Часть 5. Квантор W

Wed, 15 Jul 2009 07:05:30 GMT

Все индуктивные типы данных представляют из себя разновидности деревьев.
Например, список - это дерево, у которого из каждого узла торчит одна ветка или лист. Значит, можно попытаться описать их как один тип.
Пусть A - тип данных, хранящийся в узле. Для List a, A = Either a ⊥ , для ℕ , A = Either T ⊥ , где T - тип из одного элемента (в хаскеле ()), ⊥ - пустой тип. Для типа data BTree a = BNode a (BTree a) (BTree a) | BNull, A = Either A ⊥. B - перечислимый тип, с числом элементов, равным числу "дырок" в узле, в которые "вставляются" поддеревья. Для List a B - или N₁ или ⊥, для ℕ B - или N₁ или ⊥, для BTree a B - или N₂ или ⊥. Значение, хранящееся в узле, определяет тип узла и число ветвей, которые из него торчат. То есть, узел описывается конструкцией (x:A).B(x). Точней, в узле нашего типа IndT хранится x:A и функция subtrees::(B(x)=> IndT), которая по номеру "дырки" извлекает поддерево. Введём обозначение W(x:A).B(x) для таких типов.
Как обычно, нарисуем правила работы с типом:
WF: A:U₀, x:A ⊢ B(x):U₀
-----------------------------------------------
(W x:A).B(x):U₀

WI: a:A, subtrees:(B(a)=>(W x:A).B(x))
--------------------------------------------
Node a subtrees : (W x:A).B(x)

WE: w: (W x:A).B(x) R: (∀a:A).(∀subtrees:(B(a)=>(W x:A).B(x)).(∀y:B(a)).C(subtrees y)=> C(Node a subtrees)
-------------------------------------------------------------------------------------------
Rec w R : C(w)

WC: Rec (Node a subtrees) R -> R a subtrees (λx.Rec (subtrees x) R)

Экстенсиональность
Любой индуктивный ~~(рекурсивный)~~ тип данных представим в виде типа W. В частности, натуральные числа, списки и деревья. Но поведение W-представления отличается от поведения алгебраического типа данных. Например, в узле двоичного ADT-дерева BTree a = BNode a (BTree a) (BTree a) | BNull хранятся: 1. конструктор BTree, 2. значение в узле a, 3. 2 ветки (BTree a) .
В узле двоичного W-дерева хранятся: 1. конструктор, обзовём его WT, 2. элемент данных ∃a:A.N₂, 3. функция N₂=> W (x:A).N₂, которая даёт ветки.
Случай BNull я для упрощения опущу.
Структурное равенство двух деревьев:
1. алгебраических:
BNode a l r == BNode a' l' r' <=>
{BNode == BNode;
a == a';
l == l';
r == r'}
2. W:
WT a:(∃x:A.N₂) subtrees:(N₂=>W(y:A.N₂) == WT a':(∃x:A.N₂) subtrees':(N₂=>W(y:A.N₂) <==>
{ WT == WT;
a == a';
subtrees == subtrees'}
subtrees, subtrees' - функции, их нельзя просто так вот взять и сравнить.
Чтобы операция сравнения на таких деревьях вела себя так, как мы привыкли, надо функции сравнивать экстенсионально - по возвращаемому результату. Подсовывая им в качестве аргумента значение в вершине.
Что из этого следует, я пока ещё не понял, но у экстенсионального сравнения совсем не такие теоретические свойства, как у структурного

Столичная живность.

Mon, 06 Jul 2009 11:48:55 GMT

Неожиданно.
http://oleg-l.livejournal.com/203747.html
Ещё там лоси в парке Сокольники и много совсем мелких животных.

А в наших краях этой весной было нашествие водяных крыс.

А для любителей более изысканных блюд: палехские узоры

VCS as DB

Wed, 01 Jul 2009 08:15:12 GMT

В СУБД бывают всякие служебные таблички со списком всех существующих таблиц и прочего. А в VCS есть какой-нибудь простой-простой способ собрать несколько реп в список? Хочется чего-то вроде "покажи, какие проекты хранятся в VCS на этом сервере".

ФП. Вопрос

Tue, 30 Jun 2009 17:40:43 GMT

Если у потенциального работодателя потенциальный начальник говорит, что Лисп - не функциональный язык - следует ли делать какие-то выводы?

Весёлые картинки

Thu, 25 Jun 2009 06:12:12 GMT

Если кто хочет картинок, хороших и позитивных, рекомендую: eclisse

Увидел тута: http://crazy-zoologist.livejournal.com/430417.html?thread=2907729#t2907729

Цитата дня

Mon, 22 Jun 2009 13:11:21 GMT

желание иметь детей - это скрытая педофилия

L.I.S.P. Вопрос

Thu, 18 Jun 2009 17:43:09 GMT

К Scheme как-нибудь можно прикрутить удобный синтаксис?
Может, можно сделать "автоподставлятор скобок", и в каких-то местах их не писать?
Суть задачи в том, что:
1. надо, чтоб код получился сочетаемым другим схемным кодом. То есть, "возьми другой язык" - не вариант.
2. Но руками пейсать код на этом языке роботов - это мазохизм. Хочется немного подточить синтаксис: мнемоники понятные сделать, скобки куда-нибудь убрать.... Короче, предпроцессор. Желательно при этом не изобретать велосипед, а погнуть уже готовый.

Мифоложка

Thu, 11 Jun 2009 12:59:42 GMT

– Все условия, – сказал Иван-царевич. – Персональная оранжерея. Тропические деревья, штат обслуживающего персонала. Всё, что твоей душе угодно.
– Заманчиво, – признала Жар-птица, и задумчиво пощёлкала клювом. – Я, пожалуй, приму твоё предложение… если ты поможешь мне с одной проблемой.
– Я слушаю? – в голосе царевича слышалась готовность моментально решить любые птичьи проблемы.
– Ты должен найти мне Жар-Птицу.
Иван-царевич внимательно посмотрел на птицу, сидящую перед ним.
– Э? – проговорил он, не в силах придумать ничего лучше.

Существо, сидевшее на ветке перед ним, вздохнуло.
– Вань, я не птица. Я Жар-птиц. Мальчик. Самец. Ну, посмотри на меня!
Птиц встряхнул крыльями, роскошный, сияющий хвост заструился в воздухе. Царевич сощурился и заслонил глаза рукой.

– В животном мире, – наставительно сказал птиц, – так выглядят именно самцы. У самочек, – он мечтательно покачал головой, и выгнул шею, отчего перья на ней засверкали всеми цветами радуги, – у самочек оперение куда скромнее… Что не делает их в наших глазах менее прекрасными, – закончил самец строго.
– А, – отреагировал Иван. – И где эту твою самочку искать?
– Понятия не имею, – ответил птиц с горечью. – Я лично давно ни одной не встречал. Их, видишь ли, переловили да перестреляли. Охотнички, – он обвиняюще посмотрел на Ивана, и тот поспешно передвинул на спину лук, торчавший из-за плеча.
– Да как же, – забормотал царевич, чувствуя, что перспектива заиметь во дворце собственную Жар-птицу стремительно улетучивается, – у кого же рука поднимется?
– Я же уже сказал, – раздражённо напомнил птиц, – что у самочек вид намного скромнее. Их невежественные тупицы обычно вообще не принимают за Жар-птиц.

Повисла пауза. Иван раздумывал, Жар-птиц на дереве терпеливо ждал.
– Хорошо, – сказал наконец царевич. – Я готов… попробовать. Разыскать тебе самочку. Ничего не обещаю, но попробую. Рассказывай, как они, всё-таки, выглядят.

_____

– Я ей непременно понравлюсь, – нервно говорил птиц, расхаживая по комнате из угла в угол. – Вань, ну как я могу ей не понравиться?
– Понравишься, понравишься, – успокоил его Иван. – Но не сразу. Она сейчас проходит курс психологической реабилитации.
– Что с ней, – заволновался птиц, и даже слегка потускнел от переживаний, – Она больна?
– Совершенно здорова, – твёрдо сказал Иван. – Но я же рассказывал тебе. До недавнего времени она не считала себя Жар-птицей, и ей надо привыкнуть.
– Варвары, – птиц схватился крыльями за голову. – Они искалечили девочку!
– Ты должен признать, что их трудно обвинить, – осторожно заметил Иван. – Её внешность…
– Да, разумеется, – саркастически сказал птиц, – Внешность! Но когда она снесла золотое яйцо, уж тогда-то эти идиоты могли бы заподозрить, что существо, которое они держат в своём доме, вовсе не курица!

© silver_mew
источник

Кабала

Tue, 26 May 2009 17:47:34 GMT

Можно ли с помощью кабалы, а именно, build-type: Simple, собрать DLL? С помощью build-type: Make , ясное дело, её собрать можно, но тогда непонятно, зачем, собственно, нужна кабала. Да и забыл я, как мэйкфайлы пишут, слишком мало практики было.

iakovz и гугл нашли мне вот такой файл: http://www.haskell.org/haskellwiki/Cabal
Фактически, оно, после сборки итогового .o, в которое компилируется пакет, выполняет 2 команды:
$(GHC) --mk-dll -o $(DLLFILE) $(OFILE) $(PACKAGES)
cp $(DLLFILE) $(PKGNAME)\$(DLLFILE)
, где
$(OFILE) = HS$(PKGNAME)$(PKGVER).o
$(DLLFILE) = $(PKGNAME).dll
$(PACKAGES) - зависимости пакета, в виде "-package $(PKGNAME)$(PKGVER)"
--mk-dll - устаревший флаг, теперь он называется -shared.
$(GHC),$(PKGNAME),$(PKGVER) и зависимости медленно и печально извлекаются из кабальных структур данных
cp - программа, которая не всегда есть в наличии под Windows.
Больше ничего этот скрипт не делает. Остальное делает Distribution.Simple.
Что поправить, чтоб учесть изменения в структурах кабалы я уже понял, а куда запихнуть зависимости, которые не в виде пакетов, а в виде внешних библиотек - ещё нет. Но самый сложный вопрос - каноничное место, куда надо класть итоговую DLL. И куда воткнуть .def-файл, который в кабале вообще не предусмотрен.

Фактически, правильный собственный кабальный сборщик делается заменой buildHook в simpleUserHooks со стандартного defaultBuildHook на свой. Но,


{- из Distribution.Simple -}
defaultBuildHook :: PackageDescription -> LocalBuildInfo
        -> UserHooks -> BuildFlags -> IO ()
defaultBuildHook pkg_descr localbuildinfo hooks flags = do
  let distPref = fromFlag $ buildDistPref flags
  build pkg_descr localbuildinfo flags (allSuffixHandlers hooks)
  when (hasLibs pkg_descr) $
      writeInstalledConfig distPref pkg_descr localbuildinfo False Nothing
{- из Distribution.Simple.Build -}
build    :: PackageDescription  -- ^mostly information from the .cabal file
         -> LocalBuildInfo -- ^Configuration information
         -> BuildFlags -- ^Flags that the user passed to build
         -> [ PPSuffixHandler ] -- ^preprocessors to run before compiling
         -> IO ()
build pkg_descr lbi flags suffixes = do
  let distPref  = fromFlag (buildDistPref flags)
      verbosity = fromFlag (buildVerbosity flags)
  initialBuildSteps distPref pkg_descr lbi verbosity suffixes
  setupMessage verbosity "Building" (packageId pkg_descr)
  case compilerFlavor (compiler lbi) of
    GHC  -> GHC.build  pkg_descr lbi verbosity
    JHC  -> JHC.build  pkg_descr lbi verbosity
    Hugs -> Hugs.build pkg_descr lbi verbosity
    NHC  -> NHC.build  pkg_descr lbi verbosity
    _    -> die ("Building is not supported with this compiler.")
{- из Distribution.Simple.GHC -}
build :: PackageDescription -> LocalBuildInfo -> Verbosity -> IO ()
build pkg_descr lbi verbosity = do
  let pref = buildDir lbi
      pkgid = packageId pkg_descr
      runGhcProg = rawSystemProgramConf verbosity ghcProgram (withPrograms lbi)
      ifVanillaLib forceVanilla = when (forceVanilla || withVanillaLib lbi)
      ifProfLib = when (withProfLib lbi)
      ifSharedLib = when (withSharedLib lbi)
      ifGHCiLib = when (withGHCiLib lbi && withVanillaLib lbi)

  -- Build lib
  withLib pkg_descr () $ \lib -> do
      info verbosity "Building library..."

      libBi <- hackThreadedFlag verbosity
                 (compiler lbi) (withProfLib lbi) (libBuildInfo lib)

      let libTargetDir = pref
          forceVanillaLib = TemplateHaskell `elem` extensions libBi
          -- TH always needs vanilla libs, even when building for profiling

      createDirectoryIfMissingVerbose verbosity True libTargetDir
      -- TODO: do we need to put hs-boot files into place for mutually recurive modules?
      let ghcArgs =
                 ["-package-name", display pkgid ]
              ++ constructGHCCmdLine lbi libBi libTargetDir verbosity
              ++ map display (libModules pkg_descr)
          ghcArgsProf = ghcArgs
              ++ ["-prof",
                  "-hisuf", "p_hi",
                  "-osuf", "p_o"
                 ]
              ++ ghcProfOptions libBi
          ghcArgsShared = ghcArgs
              ++ ["-dynamic",
                  "-hisuf", "dyn_hi",
                  "-osuf", "dyn_o", "-fPIC"
                 ]
              ++ ghcSharedOptions libBi
      unless (null (libModules pkg_descr)) $
        do ifVanillaLib forceVanillaLib (runGhcProg ghcArgs)
           ifProfLib (runGhcProg ghcArgsProf)
           ifSharedLib (runGhcProg ghcArgsShared)

      -- build any C sources
      unless (null (cSources libBi)) $ do
         info verbosity "Building C Sources..."
         sequence_ [do let (odir,args) = constructCcCmdLine lbi libBi pref
                                                            filename verbosity
                       createDirectoryIfMissingVerbose verbosity True odir
                       runGhcProg args
                       ifSharedLib (runGhcProg (args ++ ["-fPIC", "-osuf dyn_o"]))
                   | filename <- cSources libBi]

      -- link:
      info verbosity "Linking..."
      let cObjs = map (`replaceExtension` objExtension) (cSources libBi)
          cSharedObjs = map (`replaceExtension` ("dyn_" ++ objExtension)) (cSources libBi)
          vanillaLibFilePath = libTargetDir </> mkLibName pkgid
          profileLibFilePath = libTargetDir </> mkProfLibName pkgid
          sharedLibFilePath  = libTargetDir </> mkSharedLibName pkgid
                                                  (compilerId (compiler lbi))
          ghciLibFilePath    = libTargetDir </> mkGHCiLibName pkgid

      stubObjs <- fmap catMaybes $ sequence
        [ findFileWithExtension [objExtension] [libTargetDir]
            (ModuleName.toFilePath x ++"_stub")
        | x <- libModules pkg_descr ]
      stubProfObjs <- fmap catMaybes $ sequence
        [ findFileWithExtension ["p_" ++ objExtension] [libTargetDir]
            (ModuleName.toFilePath x ++"_stub")
        | x <- libModules pkg_descr ]
      stubSharedObjs <- fmap catMaybes $ sequence
        [ findFileWithExtension ["dyn_" ++ objExtension] [libTargetDir]
            (ModuleName.toFilePath x ++"_stub")
        | x <- libModules pkg_descr ]

      hObjs     <- getHaskellObjects pkg_descr libBi lbi
                        pref objExtension True
      hProfObjs <-
        if (withProfLib lbi)
                then getHaskellObjects pkg_descr libBi lbi
                        pref ("p_" ++ objExtension) True
                else return []
      hSharedObjs <-
        if (withSharedLib lbi)
                then getHaskellObjects pkg_descr libBi lbi
                        pref ("dyn_" ++ objExtension) False
                else return []

      unless (null hObjs && null cObjs && null stubObjs) $ do
        -- first remove library files if they exists
        sequence_
          [ removeFile libFilePath `catchIO` \_ -> return ()
          | libFilePath <- [vanillaLibFilePath, profileLibFilePath
                           ,sharedLibFilePath,  ghciLibFilePath] ]

        let arVerbosity | verbosity >= deafening = "v"
                        | verbosity >= normal = ""
                        | otherwise = "c"
            arArgs = ["q"++ arVerbosity]
                ++ [vanillaLibFilePath]
            arObjArgs =
                   hObjs
                ++ map (pref </>) cObjs
                ++ stubObjs
            arProfArgs = ["q"++ arVerbosity]
                ++ [profileLibFilePath]
            arProfObjArgs =
                   hProfObjs
                ++ map (pref </>) cObjs
                ++ stubProfObjs
            ldArgs = ["-r"]
                ++ ["-o", ghciLibFilePath <.> "tmp"]
            ldObjArgs =
                   hObjs
                ++ map (pref </>) cObjs
                ++ stubObjs
            ghcSharedObjArgs =
                   hSharedObjs
                ++ map (pref </>) cSharedObjs
                ++ stubSharedObjs
            -- After the relocation lib is created we invoke ghc -shared
            -- with the dependencies spelled out as -package arguments
            -- and ghc invokes the linker with the proper library paths
            ghcSharedLinkArgs =
>>>               [ "-no-auto-link-packages",
>>>                 "-shared",
>>>                 "-dynamic",
>>>                 "-o", sharedLibFilePath ]
                ++ ghcSharedObjArgs
                ++ ["-package-name", display pkgid ]
                ++ (concat [ ["-package", display pkg] | pkg <- packageDeps lbi ])
                ++ ["-l"++extraLib | extraLib <- extraLibs libBi]
                ++ ["-L"++extraLibDir | extraLibDir <- extraLibDirs libBi]

            runLd ldLibName args = do
              exists <- doesFileExist ldLibName
                -- This method is called iteratively by xargs. The
                -- output goes to .tmp, and any existing file
                -- named  is included when linking. The
                -- output is renamed to .
              rawSystemProgramConf verbosity ldProgram (withPrograms lbi)
                (args ++ if exists then [ldLibName] else [])
              renameFile (ldLibName <.> "tmp") ldLibName

            runAr = rawSystemProgramConf verbosity arProgram (withPrograms lbi)

             --TODO: discover this at configure time or runtime on unix
             -- The value is 32k on Windows and posix specifies a minimum of 4k
             -- but all sensible unixes use more than 4k.
             -- we could use getSysVar ArgumentLimit but that's in the unix lib
            maxCommandLineSize = 30 * 1024

        ifVanillaLib False $ xargs maxCommandLineSize
          runAr arArgs arObjArgs

        ifProfLib $ xargs maxCommandLineSize
          runAr arProfArgs arProfObjArgs

        ifGHCiLib $ xargs maxCommandLineSize
          (runLd ghciLibFilePath) ldArgs ldObjArgs

        ifSharedLib $ runGhcProg ghcSharedLinkArgs

  -- build any executables
  withExe pkg_descr $ \exe@Executable { exeName = exeName', modulePath = modPath } -> do
                 info verbosity $ "Building executable: " ++ exeName' ++ "..."

                 exeBi <- hackThreadedFlag verbosity
                            (compiler lbi) (withProfExe lbi) (buildInfo exe)

                 -- exeNameReal, the name that GHC really uses (with .exe on Windows)
                 let exeNameReal = exeName' <.>
                                   (if null $ takeExtension exeName' then exeExtension else "")

                 let targetDir = pref </> exeName'
                 let exeDir    = targetDir </> (exeName' ++ "-tmp")
                 createDirectoryIfMissingVerbose verbosity True targetDir
                 createDirectoryIfMissingVerbose verbosity True exeDir
                 -- TODO: do we need to put hs-boot files into place for mutually recursive modules?
                 -- FIX: what about exeName.hi-boot?

                 -- build executables
                 unless (null (cSources exeBi)) $ do
                  info verbosity "Building C Sources."
                  sequence_ [do let (odir,args) = constructCcCmdLine lbi exeBi
                                                         exeDir filename verbosity
                                createDirectoryIfMissingVerbose verbosity True odir
                                runGhcProg args
                            | filename <- cSources exeBi]

                 srcMainFile <- findFile (exeDir : hsSourceDirs exeBi) modPath

                 let cObjs = map (`replaceExtension` objExtension) (cSources exeBi)
                 let binArgs linkExe profExe =
                            (if linkExe
                                then ["-o", targetDir </> exeNameReal]
                                else ["-c"])
                         ++ constructGHCCmdLine lbi exeBi exeDir verbosity
                         ++ [exeDir </> x | x <- cObjs]
                         ++ [srcMainFile]
                         ++ ["-optl" ++ opt | opt <- PD.ldOptions exeBi]
                         ++ ["-l"++lib | lib <- extraLibs exeBi]
                         ++ ["-L"++libDir | libDir <- extraLibDirs exeBi]
                         ++ concat [["-framework", f] | f <- PD.frameworks exeBi]
                         ++ if profExe
                               then ["-prof",
                                     "-hisuf", "p_hi",
                                     "-osuf", "p_o"
                                    ] ++ ghcProfOptions exeBi
                               else []

                 -- For building exe's for profiling that use TH we actually
                 -- have to build twice, once without profiling and the again
                 -- with profiling. This is because the code that TH needs to
                 -- run at compile time needs to be the vanilla ABI so it can
                 -- be loaded up and run by the compiler.
                 when (withProfExe lbi && TemplateHaskell `elem` extensions exeBi)
                    (runGhcProg (binArgs False False))

                 runGhcProg (binArgs True (withProfExe lbi))

Выделенные ">>>" строчки нуждаются в замене. Для сборки DLL достаточно флага -shared, а остальное - лишнее. Ради этого переписывать 3 исходных модуля (ведь на верхнем уровне нам доступны только userHooks) в свой кабальный скрипт - это перебор. Создавать свою версию модуля Distribution.Simple и связанных библиотек - развалится, как только кто-нибудь (хотя бы cabal-install) обновит кабалу из hackage. Создавать свой клон кабалы под названием Distribution.VerySimple - порвёт совместимость с кабальными инструментами, ведь наш пакет будет ставиться не cabal-install, а нашей собственной библиотекой. Можно, конечно, сделать бутстрап - сначала кабала собирает пакет Distribution.VerySimple (он у нас будет указан как зависимость), а потом строчка import Distribution.VerySimple в Setup.hs у нашего пакета ставит всё на место.
Оказалось, над проблемой бьются лучшие умы: http://hackage.haskell.org/trac/hackage/ticket/148
Короче, .bat-файл для сборки DLL - не такая уж плохая штука.
Слегка причёсанный Setup.hs из гугла:


import Distribution.Simple
import Distribution.Simple.LocalBuildInfo
import Distribution.PackageDescription
import System.Cmd
import System.Directory
import Data.List
import Distribution.Text


main = defaultMainWithHooks (simpleUserHooks { postBuild = buildDll })
	where
	buildDll _ _ pkg info = do 
		putStrLn "Building Dll..."
		setCurrentDirectory (buildDir info)
		let	buildCmd = concat $ intersperse " " [ghcExe,"-shared","-o",dllFile,oFile,packages]
			dllFile = display (pkgName (package pkg)) ++ ".dll"
			oFile = "HS" ++ (name pkg) ++ ".o"
			packages = concat $ intersperse " " $ map showPackage $ packageDeps info
	-- эта строчка лишняя
			cpDllCmd = "cp " ++ dllFile ++ " " ++ (name pkg) ++ "\\" ++ dllFile
			ghcExe = display $ compilerFlavor $ compiler $ info
			
			showPackage :: PackageIdentifier -> String
			showPackage pi = "-package " ++ display pi
			name :: PackageDescription -> String
			name = display . package 

		putStrLn buildCmd
		system buildCmd
	-- и эти 2 тоже 
		putStrLn cpDllCmd
		system cpDllCmd
		return ()

Но он ещё не умеет учитывать сишные исходники и дополнительные библиотеки.

GCC vs AVR = 1:0

Fri, 22 May 2009 04:02:21 GMT

GCC - хороший компилятор. Но иногда его зарубает: в коде

uint16_t x;
int16_t ref;
uint32_t result;

result += (x-ref)*(x-ref);
он делает всё правильно, за исключением:
1. результат умножения должен быть 32битным
2. надо пользоваться командой перемножения знаковых чисел.
Причём, получить от него 32битный результат, немного пошаманив, можно. Но при этом пациент пытается перемножать 32битные числа! Добиться от него использования команды знакового умножения так и не удалось.

А вот оптимизатор у него - очень качественный: выделение подвыражений (в этом примере x-ref он считает 1 раз), размещение данных в регистрах, толковый пролог у функций и прерываний (я иногда на асме пишу хуже :)).

Украина и Боги Хаоса

Wed, 20 May 2009 04:19:00 GMT

Часть первая: http://v-star-78.livejournal.com/146656.html
Часть вторая: http://v-star-78.livejournal.com/154864.html?nc=10 комменты тоже достойны
Часть третья: http://v-star-78.livejournal.com/157086.html
Часть четвёртая: http://mignews.com.ua/articles/359869.html

разархивирование

Sun, 17 May 2009 13:42:03 GMT

В этом месяце стало модно писать о войне. И о ревизионизме. Вот и меня эта тема затронула. Пишу:

Надо наведаться в ЦАМО. Вопрос: куда к кому там обратиться, что иметь при себе, какие грабли могут ожидать?

Ленивые языки и мелкозернистая многозадачность

Fri, 15 May 2009 09:08:59 GMT

Если я правильно понимаю ситуацию, то ленивое выражение вычислется так:
Выполнятор (RTS или STGM или как оно правильно называется) берёт отложенное вычисление (которое представляет из себя вершину в графе AST) и пытается его форсировать. При этом он натыкается либо на отложенное подвыражение, либо на вызов функции из FFI либо Prelude. В первом случае ситуация повторяется. Во втором случае вызывается нативный код. Если время выполнения каждого нативного вызова предсказуемо, то получается, что выполнятор получает управление через предсказуемые промежутки времени. И может перед каждым шагом вычисления отложенных выражений переключать контекст.

Как бы теперь это к работе приспособить. Нужен легковесный ленивый параллельный язычок для тупых процессоров. И компромиссная библиотека: чем мельче будут раздроблены нативные вызовы, тем больше оверхед, но тем большее разрешение по времени мы получим для нашей многозадачности. А поверх этого надо накрутить какие-нибудь "контракты" с железом - чтобы знать, когда к каким событиям мы должны успеть. Смешение парадигм, однако.
Альтернатива - параллельные сишные программисты, которые умеют точно оценивать время работы своего кода.
Другая альтернатива - брать процессор помощней и надеяться, что всё везде успеет.