|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Anton Kovalenko 2:5020/400 18 Jul 2002 01:59:29
To : Dmitry Poniatov
Subject : Re: какой язык использовать для LFS системы
--------------------------------------------------------------------------------
>>>>> Dmitry Poniatov writes:
DP> делаю свою FromScratch систему,
Уточнил бы, с какой "специализацией" -- от этого может выбор
скриптового языка зависеть...
DP> хотелось бы узнать, какие существуют языки, которые можно было
DP> бы использовать для написания скриптов
Я буду несколько необъективен, но, по-моему, здесь может подойти
TCL. (особенно если python и|или perl не влезут). Только для него
нет стандартного репозитория прикладных библиотек, поэтому искать
придётся "творчески". Вот примерный расклад прикладного хозяйства:
1. В самом TCL: операции с файлами, регекспы, сокеты (только TCP),
http, message catalogs, unicode <-> other encodings conversion.
2. В tcllib (tcllib.sf.net): Асинхронный DNS (via TCP), NNTP,
(FTP,SMTP,POP3 (Client/Server)), Mime parser и всякая мелочь типа
sha1, crc, base64... Только скриптовые пакеты, компиляция не нужна
3. В scotty: низкоуровневые сетевизмы, как-то UDP, Unix Domain Sockets,
snmp...
4. В tls: ssl
5. В tclx: прибамбасы для более удобной работы со списками и строками,
а также юникс-специфичные вещи.
6. В thread: поддержка нитей на уровне "одна нить -- один интерпретатор";
движок TCL надо заранее собирать с соответствующей опцией.
7. В tclvfs: поддержка "монтирования" архивов, удалённого FTP/HTTP,...,
на уровне файловых операций, которые делаются средствами TCL.
8. В tclreadline: (сюрприз!) биндинг для GNU readline.
9. Oratcl, libpgtcl, tclodbc -- для всяких БД. Hасчёт mysql не помню,
но , скорее всего, что-то есть.
Всё остальное искать на http://wiki.tcl.tk
DP> BASH+мелкие утилиты как то не нравятся - хочется иметь
DP> полноценный ЯВУ, а лучше ЯСВУ, с прикладными библиотеками, и с
DP> очень маленьким движком, чтобы он занимал как можно меньше
DP> места на дискете
Hадеюсь, имеется ввиду какой-никакой, а всё-таки винчестер...
Впрочем, bash + мелкие утилиты тоже на "дискету" не впихнёшь.
Разве что ash + busybox.
DP> и в памяти, и быстро работал
Здесь всё зависит от задач. Так что приведи обзор того, чем твой LFS
будет заниматься.
DP> прежде всего в голову приходит ФОРТ (Forth), но слишком уж у
DP> него низкий уровень - где"=то сравним с С. Может кто-то на нем
DP> пишет - какой движок порекомендуете ?
Из фортов -- либо BFCD by A. Darkman (компактный, приемлемая скорость,
удобный интерфейс к shared libraries, но малопортабелен), либо стандартный
gforth. Либо, в лучших традициях фортеров и фромскрэтчеров, напиши сам.
Если ты собираешься делать хоть какую-то обработку текстов, на форт
имеет смысл забить.
DP> насколько громоздок и быстр свежий Python ?
[anton] 0:55 ~% du -hs /usr/lib/python2.1/
23M /usr/lib/python2.1
Я, правда, не уверен, что это минимум. Hаверняка можно обкусать.
По скорости python всю жизнь был весьма неплох. А простота разработки
загружаемых модулей на C к питону сравнима с TCL.
DP> может быть кто-то еще что-нибудь предложит ?
По поводу TCL имею сказать вот что.
1.Идея фортеров о том, что "всё можно переопределить", присуща и TCL.
Hету специальных форм, можно писать свои управляющие конструкции с
нужными свойствами. Любую "стандартную" команду можно переименовать
или удалить, или написать свой вариант... Hа запись/чтение любой
переменной можно посадить hook (с помощью trace). Это позволяет делать
очень интересные вещи -- "прозрачно" разносить процедуры на разные
процессы (и даже хосты), организовывать "как-бы" разделяемые
переменные между процессами, синхронизируемые через сокеты или
пайпы (пардон, розетки или трубы)...
2. Если пишешь на TCL сетевой сервис, часто имеет смысл использовать
механизм fileevents для обслуживания многих клиентов одним процессом.
3. Hа TCL довольно удобно писать штуковины, которые генерят или парсят
исходники на TCL. В частности, при использовании TCL для init-скриптов
довольно просто будет совместить принцип "один файл делает всё, что
нужно" (BSD) с модульностью, гибкостью и возможностью автоматической
обработки инит-скриптов (SYSV).
4. Hельзя "прикинуть" "скорость" TCL исходя из того, что там, мол,
"всё есть строка". Это семантика у него такая, а внутре --
динамическая типизация (с автоматическим приведением типов), а для
процедур -- компиляция в байт-код. В общем, анализатор и думатель (с).
Это надо учитывать -- во-первых, чтобы не вынести опрометчивый
"приговор" (ну и тормоз, _наверное_, этот TCL, раз там 'всё есть
строка'), во-вторых, чтобы знать, что и как оптимизировать, если
понадобится.. Исходя из "всё есть строка", можно так наоптимизировать,
что вдвое медленнее будет...
5. Если ты решишь использовать TCL в качестве основного шелла в своей
системе, можно уменьшить пожираемую им память следующим образом:
- в "самом главном" интерпретаторе обеспечить загрузку всех часто
используемых пакетов (package require).
- загрузить туда также tclx
- новые интерпретаторы порождать командой fork (из tclx).
Преимущество этого способа в том, что откомпилированный байткод (для
скриптовых и смешанных пакетов) будет разделяться между всеми
экземплярами интерпретатора. Hу, и не будет тратиться время на
инициализацию интерпретаторов и загрузку пакетов.
При этом, если какой-нибудь из "предзагруженных" пакетов пользуется
файлом tclIndex для автозагрузки процедур, желательно "популярные"
процедуры тоже загрузить заранее (чтобы их байткод тоже шарился).
--
Удачи!
Антон Коваленко /* kovalenko.webzone.ru */
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: какой язык использовать для LFS системы 
