LINUX.ORG.RU

Вышел новый релиз функционального языка программирования Objective Caml 3.04


0

1

Тем кто не в курсе, это одна из реализаций функционального языка программирования ML, которая базируется на диалекте CamlLight плюс ОО расширения и модульная система в стиле Standard ML. Поддерживаются практически все UNIX платформы, а также все виды Windows'а, MacOS, MacOS X. Вся прелесть, в том, что однажды созданный байт-код, может выполняться на всех перечисленных выше платформах (32-х и 64-х разрядных). Конечно есть еще компилятор в high-performance native код, а можно выполнять программу как скрипт ;)

В Changes очень много изменений и добавленных фич.

Кому интересно, могут сходить по ссылке, и посмотреть текущие проекты: http://caml.inria.fr/hump.html

А мне сам язык и идея FP+OOP -- в одном флаконе очень понравились, ИМХО.

>>> Objective Caml 3.04



Проверено:

Вот эквивалент perl-оворго: $s = "hello\n" x $NUM; python-овского s = "hello\n" * num; и PHP-шного не знаю чего, в двух стилях итеративном и рекурсивном, скорость выполения соответсвенно повысилась, но я повторяю что репликация не является воплощением strcat алгоритма из shootout

let replicate rep count = let len = String.length rep in let res = String.create (count * len) in for i = 0 to pred count do String.unsafe_blit rep 0 res (i * len) len done; res let replicate rep count = let len = String.length rep in let off = count * len in let res = String.create off in let rec aux pos = if off = pos then () else begin String.unsafe_blit rep 0 res pos len; aux (pos + len) end in aux 0; res

let n = if Array.length Sys.argv > 1 then int_of_string Sys.argv.(1) else 1 let s = replicate "hello\n" n let _ = Printf.printf "%d\n" (String.length s);

Строки в OCaml скорее всего никогда не будут переделаны (и слава богу), так что он останется "игрушкой-развлекушкой для господ математиков", ну и до кучи всех тех товарищей не-математиков которые на нем пишут.

Насчет дыры в безопасности, у господина "anonymous (*) (2001-12-22 02:37:10.0)" дыра в голове, OCaml кидает exception в случае попытки создания строки большего чем возможно, плюс господин аноним, то что вы чего-то не видели не значит что этого в природе не существует.

По поводу размера. Внутри нативного бинарника собранного OCaml живет: a) Garbage Collector b) Часть стандартной библиотеки c) Значительное кол-во информации описывающей stack frames В связи с выше сказанным сравнение, скорее надо проводить с C++ собраным бинарником, с включенными исключениями и статически слинкованной libstdc++(в случае gcc).

-- malc

anonymous
()
Ответ на: комментарий от anonymous

> репликация не является воплощением strcat алгоритма из shootout

?? 1) что такое репликация? 2) у тебя хватит совести заявить, что во всех
тестовых программах заявленный алгоритм гарантирован?

Тот, кто придумал этот метод тестирования - безнадежный кретин.
Правильным методом тестирования было бы постановка задачи, которую предлагалось бы
в каждом языке решить наиболее эффективным методом. Это вызвало бы хоть какой-то
интерес к результатам. К тому же программисты могли бы присылать свои более
оптимизированные решения. В том виде, в каком задачи поставлены сейчас они
вызывают только улыбку.

В-общем, все очень похоже на карточные фокусы, особенно
в примерах с ocaml. Типа, все видели, да? Алгоритм в тексте соблюден! А теперь voila...
Смотрите, какое это дерьмо php, tcl... a gcc... ну так, тормозит малость ;)
Ах, вы думали, что perl лучше всего годится для работы со строками? Как вы заблуждались...
И далее в таком же духе.

> Строки в OCaml скорее всего никогда не будут переделаны (и слава богу),

Ну тогда просьба, не упоминать ocaml более в контексте универсальных языков...
Мне лень поднимать архивы lor, где господин vcl/anti-чего-то-там с пеной у рта
доказывал, что на ocaml'e можно и нужно писать серверные программы. Оказалось, это
полный обман. Почему я говорю о секюрити? Да ведь этот банальный факт со строками
вскрылся совершенно случайно! То есть теоретически прочитав классные хвалебные статьи
про этот чудесный язычок много новичков могли бы сесть писать на нем что-либо.
И лишь много времени спустя им бы стало мучительно больно за бесцельно убитое на этот язык
время, когда в их программах вдруг стала бы появляться ни о чем не говорящая ошибка
"String argument error". А что, если бы написанная ими программа была к примеру MTA,
а принимаемое важное правительственное сообщение превысило бы допустимый размер?
Я грешным делом думал, что установка лимитов на используемую память - дело
администратора сервера, а не какого=то компилятора. Ошибался значит.

anonymous
()

Работу String.unsafe_blit прокоментируйте, плиз... Ведь в ней вся разгадка фокуса...

anonymous
()

>Ты расскажи этот анекдот программе xml-парсеру или ее пользователю, у которого
>4 Гига памяти на борту. Боюсь, что не поймут ;(
>Настоящий анекдот в том, что увидев сногсшибательные фантастические результаты
>бенчмарков, я первым делом подумал, как здорово будет использовать это чудо для
>написания xml-парсера! Надо ж так обломали ;(

"Садись Иванов два!" (с)
Я лучше буду расказывать анекдот про настоящих программеров пишущих
XML-парсеры, и думают что для того чтобы распарсить файл
его нужно полностью загнать в память в виде строки. Ну ну.
Может я до сих пор чегото в жизни не понимал, но
читать в память файл размером 4Гб в память для
того чтобы его распарсить это позорная практика, а
ведь 4Гб волшебным образом пропадут еще на этапе лексического анализа.

Еще меня радуют изобретатели велосипедов, видно мы стоим у истоков создания
супер-парсера, правда он наверно будет написан на perl или php,
в связи с разочарованностью автора в Caml.
Кстати интересно почему
под Php - парсер + XSLT написан на Си( Sablotron + expat), наверно
потому что php так круто работает со строками, и в нем очень удобно представлять
рекурсивные структуры данных.( Кстати Sablotron - дерьмо еще то,
медленный, малехо глючный, не соответствует стандарту XSLT).
Я еще посмотрел исходники биндинга Sablotrona к php -
у меня волосы на голове начали шевелиться, все через задницу.

Вообще я себе слабо представляю ситуацию когда манипуляция
строками размером больше 1-2 МБ, будет рациональным
решением. Возьмем старый добрый Си,
функция strlen - вспоминаем как она работает, подсчет символов
в строке пока не встретится нуль. Отсюда вытекает что
ее скорость линейно зависит от размера строки, т.е. на длинных строках
функция заведома не эффективна! Но тем не мение она до сих пор в строю!
Почему? Потому что огромные строки не нужны!

Кстати насчет XML парсеров на Caml
Вот этот PXP(http://www.ocaml-programming.de/programming/pxp.html) -
validate парсер, кроме того еще полность перекрывает по
функциональности XSLT.
А этот поменьше и попроще -
(http://www.gaertner.de/~lindig/software/tony.html)

> За что боролись... И этот недоязычек позиционируют
> для управления космической техникой!
Кто это его позиционирует? Чегото я такого не слышал.
Во первых, насколько я понимаю, там нужна система реального времени.
Caml - на таковую никогда не претендовал, кстати как и Linux.
Во вторых, откуда там строки? В космосе, по идее, больше вещественная матиматика
нужна.

> , что ракета не упадет от переполнения буфера?
А проверять входные данные тебя не кто не учил?
Мне еще интересно сколько ракет ты запустил? и сверх быстрый
xml-парсер тебе случайно не для центра управления полетом понадобился?
Ты случайно не с Байконура репортаж ведешь?

> Это МАРАЗМ, который я вижу впервые, которого нет ни в одном
> другом языке. Это крутейший баг и просмотр в реализации.
МАРАЗМ ты тут говоришь, длинна строки приведена в спецификации языка!
Есть переменная Sys.mac_string_length - и если у тебя есть мозги то
ее полезно проверять. А исключение это не баг, а предупреждение
дурному программеру, которыйне проверил входные данные на размер.
> Это огромная дыра в безопасности.
Про то где и у кого дыра читай выше.

> Маленький, компактный, универсальный php-интерпретатор
> в двое быстрее окамловского "нейтив" бинарника.
Еще раз повторяю или не трынди или потрудись привести пример.

> У них там есть скрипт strcat.ocaml2. Это наверное и есть нормальный .
Это не эффективная реализация модуль String используется
когда ты не сильно интенсивно пользуешься конкатенцияй строк.
А вот модуль Buffer - как раз для таких целей когда ты из множества
мелких, но _РАЗНЫХ_ строк собираешь одну большую. Если не сечешь в Caml
то смотри Сишный пример, там как раз этот алгоритм и реализован.
А вот в вашем Perl и PHP насколько мне известно такого механизма нет!
Поэтому в Caml и Си количество выделений памяти это логарифмическая
зависимость от количества добавлений, а в PHP - линейная,
вот вам и скорость. А вариант с
$str = "hello\n" x $NUM (**)
не кактит потому что в Caml и Си можно вместо константной строки
добавлять переменную строку!

> 1) что такое репликация?
Это повторение одной и тойже строки заданное количество раз
смотри (**).

> А ты посмотри кто стоит за Buffer.add_string.
> Потом расскажи что делает unsafe_blit.
И чтоже такого страшного она делает?

>Ну и интересно, а мои (или любые другие) подключенные C
>библиотеки тоже будут работать в этом байткоде под
>любой платформе?
Ясный перец что нет, чудес не бывает. Речь идет о стандартных библиотеках.
Если хочешь чтобы твои работали, позаботься о их портабельности!

>Мне и на TCL/TK не плохо живется :-)
Смотреть сюда
http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html
http://www.maxence-g.net/Tools/zoggy/zoggy.html
http://www.maxence-g.net/Tools/configwin/configwin.html


> 2) у тебя хватит совести заявить, что во всех
> тестовых программах заявленный алгоритм гарантирован?
Если ты считаешь что заявленный алгоритм не выполняется,
или реализован не эффективно, обоснуй, сделай верную
с твоей точкизрения реализацию и отсылай. Если все правильно
то его примут.

> Тот, кто придумал этот метод тестирования - безнадежный кретин.
Судя по вопросу номер один это скорее относится к тебе.

> Ах, вы думали, что perl лучше всего годится для
> работы со строками? Как вы заблуждались...
> И далее в таком же духе.
Перл годится для замены bash. Ну и для недоучек которым нет времени
учится и читать документации, а руки чешутся. Perl - это
вообщем нечто вроде визуал басика только под Юникс.

> много новичков могли бы сесть писать на нем что-либо.
Ох как былобы чудесно. На западе в универах на технических
специальностях язык ML - дается как первый язык программирования!

> Работу String.unsafe_blit прокоментируйте, плиз...
> Ведь в ней вся разгадка фокуса...
Чего коментировать, насколько я помню там Си функция, котроая
кусок строки копирует. А разгадка в эффективном механизме
выделения памяти.

> Мне лень поднимать архивы lor, где господин vcl/anti-чего-то-там с пеной у рта
> доказывал, что на ocaml'e можно и нужно писать серверные программы. Оказалось, это
> полный обман.
К твоему сведению действительно можно.

Ох шото разашелся я.

PS: кстати есть предложение создать рускоязычную группу пользователей
Caml. Кто за? Пишите Caml@sit.kiev.ua



anonymous
()
Ответ на: комментарий от anonymous

To anonymous (*) (2001-12-23 07:23:08.0):
Данная бенчмарка называется strcat = String concatenation, т.е. на входе две строки на выходе одна новая состоящая из двух предыдущих.
$str = "string" x $number; Может испольховаться в контексте данной бенчмарки только если он реализован в виде
$str .= "string" foreach (1..$number); Надеюсь это-то понятно?

Я бы переделал Вашу просьбу в: "не упоминать ocaml более в контексте универсальных языков. Универсальный язык понимать как: ..., и максимальный размер базового типа string должен быть строго равен объему аддресного пространства".

"Совершенно случайно вскрытое" ограничение размеров string и 'a array
описано в http://caml.inria.fr/ocaml/htmlman/manual010.html.

Если Вы действительно пологаете, что недоязычок OCaml так плох и представляет огромную опасность, сходите на http://caml.inria.fr/users_programs-eng.html и оповестите об этом авторов этих приложений.

Btw. Xavier Leroy главный человек стоящий за OCaml, является автором, помимо всего прочего, пакета Linux threads на базе которого реализован pthreads в glibc. В связи с чем не надо считать, что авторы OCaml clueless real-life disconnected mathematicians.

--
malc

anonymous
()
Ответ на: комментарий от anonymous

>Работу String.unsafe_blit прокоментируйте, плиз... Ведь в ней вся >разгадка фокуса...

>anonymous (*) (2001-12-23 07:30:18.0)

String.unsafe_blit = String.blit без bounds checking. Поскольку реализация Buffer.add_string и replicate в моем примере обладают достаточной информацией о том что делают(размеры и смещения всегда в промежутке [0..strlen - 1]), они используют String.unsafe_blit, bounds checking в данном случае не нужен.

-- malc

anonymous
()

#include <stdio.h>
#include <stdlib.h>
#define COMPLETELY_UNFAIR

char *replicate (const char *s, int count)
{
size_t len = strlen (s);
size_t off = len * count;
char *res = malloc (1 + off);
char *p;
for (p = res; p != res + off; p += len) memcpy (p, s, len);
p[1] = 0;
return res;
}

int main (int argc, char ** argv)
{
char *s;
int count;
count = argc < 2 ? 1 : atoi (argv[1]);
s = replicate ("hello\n", count);
#ifdef COMPLETELY_UNFAIR
printf ("%d\n", count * (sizeof "hello\n" - 1));
#else
printf ("%d\n", strlen (s));
#endif
return 0;
}

Вот еще вдогонку
--
malc

anonymous
()

Если говорить о заслугах INRIA то они весьма солидны, они кстати входят в консорциум WC3( http://www.w3.org/ смотреть внизу) так что говорить что онидалеки от народа, весьма неверно!

Мужик который писал GC, ,был вторым кто сломал SSL в 95 году http://pauillac.inria.fr/~doligez/ssl/.

anonymous
()

Кому не нравятся программы на shootout - шлите свои варианты. Автор, правда, не всегда регулярно проверяет почту, но в общем довольно лоялен.

anonymous
()
Ответ на: комментарий от anonymous

> Может я до сих пор чегото в жизни не понимал, но читать в память файл размером 4Гб
> в память для того чтобы его распарсить это позорная практика

Попробуй представить, что один xml-блок (node) может занимать больше 32мег.
Что будешь делать?

> под Php - парсер + XSLT написан на Си( Sablotron + expat), наверно
> потому что php так круто работает со строками,

Удачное замечание, но с опозданием ;(
Смотрим http://www.php.net/ChangeLog-4.php
- Removed the sablotron extension in favor of the new XSLT extension. (Sterling)

> Вообще я себе слабо представляю ситуацию когда манипуляция
> строками размером больше 1-2 МБ

Я тебя понимаю ;( Напиши, плиз, MTA, с таким ограничением. Только, боюсь, что
самая главное трудность будет провести в жизнь расширение для smtp-протокола ;)
А дело будет происходить так:

220 smtp.ocaml.must.die ESMTP
666 String argument error. Exception bla-bla-bla

> Кто это его позиционирует? Чегото я такого не слышал.
> Во первых, насколько я понимаю, там нужна система реального времени.

Точно, угадал!
http://www.cs.caltech.edu/cs134/cs134b/book.pdf
Chapter 1. Introduction. Объясняют, что не хватает в современных языках
и почему нужен ocaml. Что назрела, мол, необходимость в ... идет перечисление:
"Languages for real-time systems like automotive, aercraft, and space application"

> Это не эффективная реализация модуль String используется когда ты не сильно интенсивно
> пользуешься конкатенцияй строк. А вот модуль Buffer - как раз для

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

> Xavier Leroy главный человек стоящий за OCaml, является автором, помимо всего прочего,
> пакета Linux threads на базе которого реализован pthreads в glibc.

Ох-ох. Лучшей антирекламы и не бывает. Одно из самых дерьмовых мест в линуксе это
как раз pthreads...

anonymous
()

to anonymous (*) (2001-12-23 18:17:10.0)

>> Вообще я себе слабо представляю ситуацию когда манипуляция 
>> строками размером больше 1-2 МБ 

>Я тебя понимаю ;( Напиши, плиз, MTA, с таким ограничением. Только, боюсь, что 
>самая главное трудность будет провести в жизнь расширение для smtp-протокола ;) 

А что у нас написано в стандарте? Делаем RTFM:

RFC 821                                                      August 1982
                                           Simple Mail Transfer Protocol
  
            text line
 
               The maximum total length of a text line including the
               &lt;CRLF&gt; is 1000 characters (but not counting the leading
               dot duplicated for transparency).

Однако...

--
SVK

anonymous
()

Вообще-то непонятно, что это за OOP язык с намертво вхераченными базовыми типами. Даже мономорфный haskell может быть расширен почти без напрягов. Кто-нибудь в курсе, есть ли препроцессор на эту тему, чтобы хотя бы можно было арифметические операции делать однообразно как с float, так и c big_int.

anonymous
()
Ответ на: комментарий от anonymous

> The maximum total length of a text line

Тогда уж вернись на год назад, в славный 1981-ый и прочти rfc788.
Привожу соотвествующий отрывок "AS-IS" c исходным форматированием ;)

4.5.3. SIZES

[...]

***************************************************
* *
* TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
* TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
* OF THESE OBJECTS SHOULD BE USED. *
* *
***************************************************

anonymous
()

to anonymous (*) (2001-12-24 00:14:06.0)

>> The maximum total length of a text line 
> Тогда уж вернись на год назад, в славный 1981-ый и прочти rfc788. 

Зачем же? Просто смотрим rfc-index:

0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982. (Format:
     TXT=124482 bytes) (Obsoletes RFC0788) (Also STD0010) (Status:
     STANDARD)

Так что аргумент не принимается. На данный момент стандарт все-таки
RFC 821. (Если его чем-то заменили --- номер в студию.)

Кстати, мы с Вами на брудершафт не пили.

--
SVK

anonymous
()
Ответ на: комментарий от anonymous



>> Xavier Leroy главный человек стоящий за OCaml, является автором, >>помимо всего прочего,
>> пакета Linux threads на базе которого реализован pthreads в >>glibc.

>Ох-ох. Лучшей антирекламы и не бывает. Одно из самых дерьмовых мест >в линуксе это как раз pthreads...

Я сказал, что он автор Linux threads, на котором pthreads построен. Очевидно, что вместо рта у Вас, уважаемый, помойка, так как ничего убедительного из него не выходит. Ваша "оптимизация" strcat довольно неплохо показывает Ваш интелектуальный уровень, а обливание грязью людей и языков о которых Вы очень мало знаете, колоритно дополняет портрет. Очень желаю Вам подрости немного(думаю лет 15 вам хватит).

P.S. Счастливого написания очередного MTA.
--
malc

anonymous
()
Ответ на: комментарий от anonymous

>Вообще-то непонятно, что это за OOP язык с намертво вхераченными >базовыми типами. Даже мономорфный haskell может быть расширен почти >без напрягов. Кто-нибудь в курсе, есть ли препроцессор на эту тему, >чтобы хотя бы можно было арифметические операции делать однообразно >как с float, так и c big_int.

Objects в OCaml в той или иной степени afterthought. И были введены в язык Jerome Vouillon, если память мне не изменяет, во время работы над его Ph.D.

<quote>
OCaml is first a functional langage so I think (I hope) that people do not use objects as heavily as in Java, and for instance use pattern matching rather than only method calls for implementing branches.

Jerome
</quote>

http://caml.inria.fr/archives/200011/msg00138.html - thread по поводу OO и OCaml.

Навскидку, я могу вспомнить только следующие библиотеки которые используют O в OCaml:

PXP - Validating XML parser
LablGTK - на ряду с простым интерфейсом существует набор классов wrapper-ов

Плюс Jacques Garrigue реализовал часть stdlib(контейнеры?) с использованием O.

--
malc


anonymous
()

>Ну ты сам послушай, как криво и погано это звучит. Я уж не говорю >про того, как погано это реализуется. String используется тогда-то, >а вот если это не так, то нужно использовать Buffer, но не >забывайте, что это производная от String, а String имеет сами >хнаете какое ограничение. Лажа полная.

Если быть последовательным, впрочем Вы им не являетесь, то следует в томже обвинить Java, после чего добавить в php,perl,python,ruby GC отличный от refcounting-a и посмотреть на их скорость.

--
malc

anonymous
()
Ответ на: комментарий от anonymous

> Так что аргумент не принимается. На данный момент стандарт все-таки

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

Во-первых, тот лозунг из rfc788 без изменений сохранился в rfc821.
Во-вторых, взгляни хотя бы на rfc2554 SMTP Authentication:

The BASE64 string may in general be arbitrarily long. Clients
and servers MUST be able to support challenges and responses
that are as long as are generated by the authentication
mechanisms they support, independent of any line length
limitations the client or server may have in other parts of its
protocol implementation.

> Кстати, мы с Вами на брудершафт не пили.

Кстати, и никогда не будем... Ты меня абсолютно не интересуешь в качестве собутыльника ;)

anonymous
()
Ответ на: комментарий от anonymous

> Если быть последовательным, впрочем Вы им не являетесь, то следует в томже обвинить Java

Всему свое время, будет обсуждение про Java - будем и жабе перемывать косточки.
Сейчас это вроде как не по топику. Я так понял, никаких контраргументов моим
ответам првести ты уже не можешь. Что-ж, в таком случае тема закрыта.

anonymous
()

to anonymous (*) (2001-12-24 07:01:14.0)

В общем-то, ограничение длины строки или массива мне не кажется важным. Во-первых, оно специфицировано, во-вторых, оно корректно отрабатывается (через exception, а их все равно надо обрабатывать, если вести речь о надежных программах), и наконец, если уж так она нужна неограниченная строка - имея ограниченную на большой длине ее легко сделать. Причем практически без потерь в производительности.

Правда, придется пересобрать библиотеку String. Но больше никого расстреливать не будут. В общем, для GPL-ed реализации языка не такой уж и большой недостаток.

anonymous
()

А я считаю, что ограничение на длину строки это катастрофа. Полный show stopper.
И слава богу, что нигде этого больше нет.

anonymous
()
Ответ на: комментарий от anonymous

>Всему свое время, будет обсуждение про Java - будем и жабе >перемывать косточки. Сейчас это вроде как не по топику. Я так >понял, никаких контраргументов моим ответам првести ты уже не >можешь. Что-ж, в таком случае тема закрыта.

Нет моя задача поскромнее, указать на Вашу непоследовательность и непроходимую тупость, в результате чего люди будут осторожнее относится к Вашим громогласным заявлениям о том что: TGCLS - ПОЛНАЯ ЛАЖА и НАЕБА^H^HДУВАЛОВКА OCaml - недоязычек и прочее.

-- malc

anonymous
()

to anonymous (*) (2001-12-24 06:54:43.0)

>> Так что аргумент не принимается. На данный момент стандарт все-таки 

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

Причем здесь это? Вы аргументируете свои высказывания ссылками на стандарты.
В стандартах указано кое-что другое. Об этом и речь. А насчет ограничений 
на длину строк я *ничего* не утверждаю.

> Во-первых, тот лозунг из rfc788 без изменений сохранился в rfc821. 

Сохранился. Но цитировать так цитировать:

      4.5.3.  SIZES
 
         There are several objects that have required minimum maximum
         sizes.  That is, every implementation must be able to receive
         objects of at least these sizes, but must not send objects
         larger than these sizes.
 
                                    
          ****************************************************
          *                                                  *
          *  TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION  *
          *  TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
          *  OF THESE OBJECTS SHOULD BE USED.                *
          *                                                  *
          ****************************************************

Там чуть повыше понятно написано? Если мне кто-то пришлет данные, превышающие
указанные лимиты, я  с полным правом отправляю его в сад, так как он нарушает
стандарт.

Далее, 

         Errors due to exceeding these limits may be reported by using
         the reply codes, for example:
 
            500 Line too long.
 
            501 Path too long
 
            552 Too many recipients.
 
            552 Too much mail data.

Dixi.


> Во-вторых, взгляни хотя бы на rfc2554 SMTP Authentication: 

> The BASE64 string may in general be arbitrarily long. Clients 
> and servers MUST be able to support challenges and responses 
> that are as long as are generated by the authentication 
> mechanisms they support, independent of any line length 
> limitations the client or server may have in other parts of its 
> protocol implementation. 

Интересное замечание. Принимается условно. Условно потому, что статус
этого документа PROPOSED STANDARD, а RFC 821 --- STANDARD. Формально, 
ESMTP extensions имеют право нарушать некоторые требования *стандарта*, 
в рамках которого они должны работать, но далеко не факт, что такое 
расширение будет в итоге стандартизовано. 

>> Кстати, мы с Вами на брудершафт не пили. 
> Кстати, и никогда не будем... Ты меня абсолютно не интересуешь в 
> качестве собутыльника ;) 

Тогда открытым текстом: неуважение к собеседнику не есть признак
большого ума. Впредь я Вам отвечать не собираюсь. Хватит оффтопика.

--
SVK

anonymous
()

По поводу XML парсеров и памяти.
Не забывайте, что есть SAX и DOM парсеры, надеюсь разницу объяснять не надо.

Havoc ★★★★
()
Ответ на: комментарий от Havoc

> надеюсь разницу объяснять не надо.

Да чего там, объясни уж в качестве гуманиторной помощи товарищам, считающим
что ocaml годится для DOM-парсера в чем они не правы. А то я устал уж объяснять.
Они ведь как Билли Гейтс в свое время... Тот тоже утверждал, что 640К памяти
хватит на все про все выше крыши ;)

anonymous
()
Ответ на: комментарий от anonymous

> Вы аргументируете свои высказывания ссылками на стандарты.
> В стандартах указано кое-что другое.

Ты вот про глупость там что-то вякнул, а как прикажешь расценивать твои словечки?
Ну да, был 1981 год. Были совершенно объективные ограничения по памяти, каналам связи и т.д.
Но даже тогда, двадцать лет назад люди понимали, что в 21-ом веке эти ограничения будут
выглядеть смехотворными. Потому и напечатана была в рамочке БОЛЬШИМИ БУКВАМИ памятка всем
будущим имплементаторам. Но увы, не до всех доходит, не всем дано... ;(

> Интересное замечание. Принимается условно.

Да уж условней некуда. Особенно учитывая, что "стандарт" rfc821 достал уже всех кого можно
и замена ему готовится очень активно.

> Если мне кто-то пришлет данные, превышающие указанные лимиты, я с полным правом отправляю его в сад,

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

> Тогда открытым текстом: неуважение к собеседнику не есть признак

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

anonymous
()

Даааа,
есть ещё идиоты, которые считают,
что всё сообщение надо загнать в один
кусок памяти и весь XML файл туда же :)))))

Мне приходилось учавстововать в написании MTA -
обходились буферами в 10k :) Наверно херовые из
нас программеры :)))))

XML парсеры вообще основаны на потоках....

Может кто знает хоть одну практическую реализацию XML парсера,
где все в одной стоке храниться ?

Представляю - сначала клиент получает от сервера все данные,
терпеливо копит их в строке, если хреновая связь - то долго
ждёт, и вот только затем, когда забьёт всю память - начинает
парсить :)

Да для нормального программера cтрока в 16М это слишком много !!!

anonymous
()

Умник, SAX прасеры таки да, основаны на событиях.
DOM прарсеры строят дерево элементов в памяти, так что таки да, получится, что весь файл, правда в несколько другом виде, весь в памяти. И нет гарантии, что размер элемента не зашкалит за 16 метров.

Конечно, по возможности лучше использовать SAX парсер, но не всегда это выходит и остается DOM.

Кто херовый программер, это еще неизвестно, я же не зря написал, что есть 2 основные разновидности парсеров.

Havoc ★★★★
()

>DOM прарсеры строят дерево элементов в памяти, так что таки да,
>получится, что весь файл, правда в несколько другом виде, весь в
Вот, вот. В несколько другом виде. Документ as string никто
не хранит.

>памяти. И нет гарантии, что размер элемента
>не зашкалит за 16 метров.
Во-первых тебе никто не запрещает хранить ноду
скажем как список строк, так что такого рода проблема
снимается.
Во-вторых, я предполагаю что если у тебя в xml
вдруг возьмется нода такого размера, то чего то ты
где то недокумекал. Это не есть хорошо.

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

anonymous
()
Ответ на: комментарий от Havoc

2Havoc

Вот когда ты сочинишь такой XML, который будет больше
16М и его нужно будет парсить БЕЗ SAX
твой шеф решит, что для хранения твоей
зарплаты будет достаточно одного байта :)

anonymous
()

Я такие файлы не сочиняю, но все таки автор ф-ии sqrt проверяет на недопустимые значения, а не крешит прогу, т.е. кто знает, что юзеру в голову придет.

А если 1 будет соответствовать 1-му килобаксу, то соглашусь и на один байт, я не жадный :)

Havoc ★★★★
()

To Havoc:
>sqrt проверяет на недопустимые значения,
Блин а тут про что говорят. Какой нахрен крэш?
При добавлении строки, проверяется чтобы результирующая строка
была меньше Sys.max_string_len, если условие не выполняется
то библиотека тебе вежливо говорит -
"извините мол", посредством исключения. И никакого крэша.
То что в тесте такое исключение никто не обрабатывает, так
на то он и тест, грубая имитация некоторой типовой операции.

В томже Си есть переменные INT_MAX, UINT_MAX, которые в
особо ответственных случаях не мешает проверять, и никто
не жужит, что мол int оказывается ограничено, и нельзя туды записать
то что дурному программеру в голову взбредет.
Нужны числа произвольной длинны, пользуй соответствующую либу.

anonymous
()

> Вообще писать программы, с предположением того,
> что ресурсы системы неограничены, не есть хорошо.

Есть мнение с полностью противоположным смыслом ;)

> Именно поэтому и появляется туева хуча тормознутых
> здоровенных и неповоротливых монстров.

С умом все надо делать батенька. Где гарантия, что монстры не стали монстрами
только потому, что кто-то когда-то заложился к примеру на 10Кб строку, а потом
осознал свою ошибку и начал лепить кривые костыли, чтобы заделать эту оплошность.
И такое бывает. Потом 32Мб строка... Ну что это такое для машины с 32Гб памяти?
На один зуб... В элементе CDATA xml вполне может быть картинка в бинарном виде
размером в десятки гигабайт. И все, приехали вы господа в этом случае. Вашу
работу отдадут другим, а вы будете продолжать играть в песочнице с ocaml ;)

anonymous
()

> Вашу работу отдадут другим, а вы будете продолжать
> играть в песочнице с ocaml ;)

Чегой то ты так беспокоишься за нашу работу, небоись не
отдадут.

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

А вообще я себе представляю эту картину, звонит
клиент и первым делом спрашивает:
-Вы в строках, храните данные разменром с десятки гигабайт?
Я:
-Нет мы нарезаем по шестнадцать мегабайт.
Заказчик:
-Ну Вы и пидары! Идите тогда нахуй! Я вон лучше к
Васе пойду, он десятигигабайтные данные может в одну
строку загнать, не то что вы, и он действительно крут.
Я:
-Вау, шо вы говорите, в одной строке целых десять гигабайт!!!
Да мы до такого уровня не доросли, видно Вася не
меньше чем доктор наук по информатике, закончил
наверно кембридж, ну или мичиганский политех, где
его лет этак 10 учили как в php со строками работать.

anonymous
()

Интересно, куда господин Антихрист подевался? :)

Havoc ★★★★
()

Похоже ему надоело вести "просветительные работу среди вас" (с). И он ушел на покой. А то видать как с Эпроклятыми императивщиками" поговоришь так потом неделю нервную систему успокаивать нужно. А Новый Год в состоянии аффекта кому хочется справлять? %-)

>> Вообще писать программы, с предположением того, >> что ресурсы системы неограничены, не есть хорошо. >Есть мнение с полностью противоположным смыслом ;) А ну озвучь?

Насколько я понимаю должен, работать принцип "надейся на лучшее, но готовся к худшему". Всегда перед тем как что то написать нужно задать вопрос "А что если?". А что если нет пресловутык десятков или сотен мегабайт ОЗУ на машине? А данные нужно както обрабатывать, и на просто обрабатывать, а эффективно обрабатывать, а не просто своп засерать!

anonymous
()

Похоже ему надоело вести "просветительные работу среди вас" (с).
И он ушел на покой. А то видать как с Эпроклятыми императивщиками"
поговоришь так потом неделю нервную систему успокаивать нужно.
А Новый Год в состоянии аффекта кому хочется справлять?
%-)

>> Вообще писать программы, с предположением того,
>> что ресурсы системы неограничены, не есть хорошо.
>Есть мнение с полностью противоположным смыслом ;)
А ну озвучь?

Насколько я понимаю должен, работать принцип "надейся
на лучшее, но готовся к худшему". Всегда перед тем
как что то написать нужно задать вопрос "А что если?".
А что если нет пресловутык десятков или сотен мегабайт
ОЗУ на машине? А данные нужно както обрабатывать,
и на просто обрабатывать, а эффективно
обрабатывать, а не просто своп засерать!

anonymous
()

Насчет своп засрать. Насколько я понимаю, GC для своей работы требует одновременный доступ ко всем объектам данных. Так что получается, что в свопе данные спокойно не упокоятся. Это так или я чего-то не понимаю?

anonymous
()

> Ну что это такое для машины с 32Гб памяти?

И правда мелочь... А ну если я строку в 64Гб захочу? Ну *большая* у меня картинка, и мне *ну абсолютно* надо хранить ее в XML-теге.

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

> Насколько я понимаю, GC для своей работы требует одновременный доступ ко всем объектам данных. Так что получается, что в свопе данные спокойно не упокоятся.

Зависит. Есть generational collectors, делящие heap на несколько арен-'поколений'; свежесгенерированные объекты идут в самое 'молодое'. Когда происходит GC, работа идет только с младшим поколением; если количество высвобожденной памяти недостаточно, производится сборка в старшем поколении; если объект переживает N сборок, он пересылается в поколение постарше. Так что если 'старые' объекты отсвопованы, нет необходимоcти обращаться к ним при каждой сборке.

Viking
()

И всё же, интересует ответ Антихриста. Я старый лысый императивщик, разрабатываю ПО в области MTA с применением крипто, работа с БД, Банк-Клиент, короче, во в всём его многообразии, цена ошибки довольно высока. Хочется узнать - а не нахую я ли видел твоё ФП, даже в таком мягком виде как Ocaml, если я привык к C++ и довольно неплохо на нём программирую. Зачем мне изучать новый язык? Стоит ли овчинка выделки? Думаю не только меня это интересует. Ты хоть и пидар по жизни, а в математике вроде больше меня сечёшь (во всяком случае пальцы шире расставляешь).

P.S. Между водопадами мата надеюсь услышать аргументы.

С уважением, небогобоязненный христианин.

rabbit
()

И всё же, интересует ответ Антихриста. Я старый лысый императивщик, разрабатываю ПО в области MTA с применением крипто, работа с БД, Банк-Клиент, короче, во в всём его многообразии, цена ошибки довольно высока. Хочется узнать - а не нахую я ли видел твоё ФП, даже в таком мягком виде как Ocaml, если я привык к C++ и довольно неплохо на нём программирую. Зачем мне изучать новый язык? Стоит ли овчинка выделки? Думаю не только меня это интересует. Ты хоть и пидар по жизни, а в математике вроде больше меня сечёшь (во всяком случае пальцы шире расставляешь).

P.S. Между водопадами мата надеюсь услышать аргументы.

С уважением, небогобоязненный христианин.

rabbit
()
Ответ на: комментарий от rabbit

2 rabbit:
>Зачем мне изучать новый язык?
>Стоит ли овчинка выделки?

Вот одно из высказываний ;)
...Why I choose Caml ?
1.it is a functional language, much more safer coding than imperative languages like C, C++, Java. Strong typed
languages are better than weak typed ones, because you need less debbuging effort. High level native objects (lists,
tuples...) and a GC, a modern language must have a GC.
2.it has well designed and powerfull libraries support.
3.it also has imperative support and mutable data who certainly well used, helps.
4.a very high quality implementation so you get a close to C, C++ performance and low memory consumption.
5.it's extensible semantics and easy to interface C API'S or your own libraries. In electronical terms it has a 'wide
bandwidth'.
6.it is quite readable, elegant no need of bloated and unnecessary declarations.
7.it is easy to learn, and it's inherent mathematic coherence helps a lot. At my job two 'clipper' programmers with no
special mathematic background and no OO knowledge are writing very decent code in Caml, they couldn't do it in C++.
8.better than C, C++, JAVA, PYTHON, PERL, RUBY, PASCAL....etc. Finally I am quite impressed with Caml and I
believe that Caml is well suited for really professional apps in the real world, excellent. I have coded a small app (client
SQL graphical tool for GigaBase) whith the bindings for the database and I've used LablGtk from Jacques Garrige for
graphic user interface. I is about 590 lines of code (you must take in account that I am just learning Caml). Similar
programm in C with Glade takes about 1500 lines in the graphic interface and another 1000 lines of app code and a lot
of debbuging. At this time I don't kwnow how to debbug a Caml programm and I've did it!.

ska
() автор топика

Те кто звиздят против функционального прог-я либо не пробовали толком, либо в математике слабо.

babai
()

Но не будешь же ты называть ф-ое программирование One True Way?

Havoc ★★★★
()

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

Например в целях именно самообразования рекомендуется
поковырять haskell, он один из интереснейших языков,
Из классики - Lisp, Схему.

А Caml мало того что сам по себе интересный и красивый язык,
так еще и реализован очень удачно, что очень важно
при практическом прменении.

>> Кто это его позиционирует? Чегото я такого не слышал.
>> Во первых, насколько я понимаю, там нужна система
>> реального времени.

> Точно, угадал!
> http://www.cs.caltech.edu/cs134/cs134b/book.pdf
^^^^^^^^^^^^^^^^^^^^^^^^^^
> Chapter 1. Introduction. Объясняют, что не хватает в современных
> языках
> и почему нужен ocaml. Что назрела, мол, необходимость в ...
> идет перечисление:
> "Languages for real-time systems like automotive,
> aercraft, and space application"

Не надо передергивать.
Ты смотрел где лежит это руководство? Людям там преподают принципы
построения _компиляторов_, поэтому в ведении говорится для
чего может понадобится еще один язык который они возможно _придумают_.
И тот обрывок фразы к Caml не относится, Caml в данном случае
рассматривается как инструмент для построения компилятора языка
"for real-time systems like automotive, aercraft, and space application". А компиляторы - область где Caml наверно
не имеет себе равных.

anonymous
()
Ответ на: комментарий от babai

А никто против и не физдит. Просто вопрос в аудиторию вообще и Антихристу в частности - "Окупится ли моё время, которое я потрачу на изучение ФП и Ocaml в частности?". Вопрос не праздный - время самый дорогой товар. Но похоже всё таки надо попробовать - если окажется лажей, то хоть можно будет грамотно пообламывать пальцЫ Антихристу в одном из флеймов.

rabbit
()
Ответ на: комментарий от rabbit

если с математикой на ты, на мой взгляд, переход будет без проблем. Правда по началу мозги кривит после императивного прог-я, но это быстро проходит :)

babai
()
Ответ на: комментарий от rabbit

> изучение ФП и Ocaml в частности?

Я до недавнего времени почти ничего не знал об этом, но почитав введение в ФП
вдруг обнаружил, что почти всегда писал использую принципы ФП, хотя мой основной язык perl.
То есть утверждения ФП == Caml, а C/perl/python/php == императив не соответствует истине.

> хоть можно будет грамотно пообламывать пальцЫ Антихристу

Да этого антихрена уже опустили дальше некуда. Думаешь чего он забился под лавку и не показывается?
Отымели пиздобола. Чувак начитался умных книжек, а ты попроси его написать пару
строк на том же caml'e. Обделается весь. Это ж не языком молоть.

anonymous
()

> То есть утверждения ФП == Caml,
> а C/perl/python/php == императив не соответствует истине.

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

А вот из C/perl/python/php, насколько я зная пожалуй только
питон немного поддерживает функциональный стиль на уровне конструкций
языка, правда немного кривовато. На остальных чтобы
писать в функциональном стиле требуется конкретные извращения,
потому что языки эти императивные. Можно конечно и ногами
за ухом себе чесать, но удобней и правильней это делать руками.

anonymous
()

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

babai
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.