|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 30 Jan 2003 17:17:13
To : "Igor"
Subject : Re: 386SX and RedHat_8.0
--------------------------------------------------------------------------------
Hi, Igor!
>>>>> "I" == Igor <info@fsps-mo.ru> writes:
VB>> вот только неделю назад я тут провел агромадный ликбез на грани
VB>> оффтопика на счет python для Захара Киселева. Еще несколько людей
VB>> ему рассказывали про tcl.
I> сколько виртуальная машина perl'а занимает оперативки ?
ну, скольк-то там занимает. Я думаешь мерял? ;)
бинарник у перла - ~800K
I> python не знаю . вероятно там тоже виртуальная машина ?
да, там тоже. Бинарник питона - чуть более 800K (можно уменишить,
довольно значительно, думаю из перла тоже можно повыкидыать ненужную тебе
функциональность).
VB>> Hасколько я помню, панасониковские АТСки выдают строки на выход из
VB>> своего порта, там ваще можно перлом парсить, или даже awk'ом.
I> 1.в самом начале дскусии я сказал
I> "... В миниАТС KT-TD1232 не предусмотрен модуль
I> 1. ... управления станций по локальной сети.
I> 2. ... хранения логов/данных. ..."
I> Кроме сливания лога с serial-порта ,надо достучатся к настройкам.
I> 2. И в начале я и предположил либо бинарник или что-нибудь шеловское.
да, но под "управление станцией" можно поинмать много чего :)
но, мы уходим от.
Задача доступа к АТС'ке ведь не требует сильно жестких временных рамок?
Даже если на этапе разработки решения будет некоторый свопинг, это ведь не
будет критично? Я думаю что потерь данных не будет.
Зато, наверняка критично time-to-market - время выхода первого релиза,
или хотя-бы хоть чего-то, на что можно смотреть и думать что с этим делать
дальше.
В принципе, начать можно разумеется и с shell. Глянуть, к чему мы сходу
можем добраться, а к чему не сходу.
Далее, я считаю лучше полученые результаты "проэволюционировать" с shell,
на какой-либо скриптовый язык. По затратам памяти это будет не слиьно
больше (шел, по сути тоже "виртуальная машина", бинарник bash занимает
~500K), зато сильно увеличится комфорт программера.
Я, как человек который можно скзаать не программит на shell (скрипты в
один-два экрана я програмингом назвать не могу ;), обычно сразу перехожу к
этому этапу - к скриптовым языкмм ;)
Если задача похожа на "обработка потока текста" - то к perl, если не очень
- то к python. tcl я гораздо хуже знаю, поэтому к нему не перехожу ваще ;)
Еще вот есть Ruby, который я совсем не знаю, но после знакомства с ним
осталось впечатление что им тоже можно пользоваться, причем как вместо
perl, так и вместо python... Hо особых плюсов я не увидел, зато увидел
минус - мнеьше готовых библиотек, и решил то пока хватить перла с питоном.
Hо! Внезависимости от выбора, в итоге "этапа макетирования" на чем-то
таком высокоуровневом получается вполне рабочая реализация проекта.
Полнофункциональная. Которую можно смело применять в качестве решения
задачи.
В ходе эксплуатации вылезут узкие места в такой "макетной" реализации,
которые можно постепенно переписывать на C/C++, и подключать в виде
модулей к perl/python/итд.
Чем мне нравится такой подход - кроме того, что разработчику просто
комфортнее работать за счет более высокоуровневого инструмента, наличие
"виртуальной машины" позволяет пользовать любую другую платформу для
разработки. Без возни с cross-компиляцией прям с начального этапа. Хотя,
потом, когда нужно будет переписывать компоненты на C/C++ таки прийдется
заняться сборкой cross-gcc.
Hо есть неочевидный и слабо прогнозируемый момент. Мне понравилсь
высказывание Larry Wall (автор перла), что многие идущие по пути "прототип
на перле, проект на С" в фазе начала эксплуатции понимали, что им хватает
аппаратных ресурсов чтоб работал прототип, и даже при наличии людских
ресурсов для переписывания на Си, они далеко не всегда делали это, чтоб не
потерять гибкость и мобильность проекта.
Это все в той-же степени относится к любому инструменту этого уровня.
VB>> Кто скзала что "приложения" можно пистаь только на C++, да еще и
VB>> непременно нужно пользовать STL? Даже если нужна компилируемость (в
VB>> виду ограничения ресурсов), можно не морочить голову, и пользовать
VB>> ANSI C. В это задаче.
I> Тут у меня данных пока нет, насколько долго/быстро будет
I> сборка/компиляция. Просто хотелось на этой машине и девелопить :(
не, лучше забыть про девелопмент на 386/4. Лучше даже и не пытайся.
Линукс поставленый внутри VMWare на Celeron >300MHz будет работать быстрее
чем там, на живом железе.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
