я там отписался у себя. надо убрать BOM.

а делал я универсал -- Opera/Firefox. кстати, скрипт многоуважаемого phantom'а я обработал напильником и засунул туда же, в разворачиватель.

phantom, вы не против, надеюсь? кредиты проставлены, всё как полагается. %-)

(Reply to this) (Parent) (Thread)

не против (я игнорирую копирайт),
я даже и кредитов не ставил бы.
если хочется сохранить родословную,
то таблицу символов я взял отсюда:
http://userscripts.org/scripts/review/6565

кстати, у тебя очень полезный скрипт.

какой IDE ты используешь для JS?
существует ли дебаггер для JS?

(Reply to this) (Parent) (Thread)

>не против (я игнорирую копирайт),
аналогично. но кредиты — это не копирайт, это дань уважения предыдущему автору. а так если есть возможность — я свой код обычно кидаю как public domain.

>кстати, у тебя очень полезный скрипт.
tnx. я его делал для себя (как и почти все полезные вещи обычно делаются %-). теперь решил, что ещё кому-то пригодится. заодно попробовал заточку под Firefox (поскольку я тормозиллу не использую, было поучительно).

>какой IDE ты используешь для JS?
ты будешь ржать: mcedit. или joe, в зависимости от настроения.

>существует ли дебаггер для JS?
для Firefox — FireBug или Venkman. я ними не пользовался, не в курсе, насколько они хороши.

для Оперы — только Error Console. были потуги сделать нечто, похожее на дебагер (даже у меня были), но оно того не стоит. ибо идея — в препроцессинге js-кода и хитрых манипуляциях с ним. удолбище выходит.

в принципе, если ты мой скрипт почитаешь, найдёшь там закоментареные остатки логов (opr.postError).

зыж интересно, чей способ разбора строки шустрей: мой через регулярку или твой? я, честно говоря, нифига не понял, что ты там со строкой делаешь, потому тупо переписал. %-)

(Reply to this) (Parent) (Thread)

> FireBug или Venkman. я ними не пользовался, не в курсе, насколько они хороши.

я попробовал FireBug - очень хорош и функционален
только не как дебаггер, а как DOM-explorer и т.п.

> ыж интересно, чей способ разбора строки шустрей: мой через регулярку или твой?

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

> я, честно говоря, нифига не понял, что ты там со строкой делаешь, потому тупо переписал. %-)

я просто JS не знаю, и чтобы не использовать
высокоуровневых функций, сделал по-быстрому:

пробегаем по строке (цикл по i), для каждой позиции
проверяем, входят ли 2 следующих символа в symbols,
если да - это транслитерированная в две русская буква,
если нет, это две различных переведенных русских буквы.
я сразу обобщил на возможные длинные сочетания ("щ"),
но по-простому двух достаточно (внутренний цикл по j).
функция pick(s, i, j) = substring(s, i, j), просто
substring у меня не заработал с ходу, и я переписал.

(Reply to this) (Parent) (Thread)

>разбор строк вручную всегда должен быть быстрей.
э, нет. зависит от реализации строк. в JS они immutable, поэтому, например, charAt() каждый раз создаёт новый объект «строка» из одного символа (как понимаешь, операция не шибко шустрая). так что регулярки могут быть шустрее в разы — у меня один replace. правда, я тоже со строкой манипулирую. лень бенчмарк писать. %-)

>я просто JS не знаю, и чтобы не использовать
>высокоуровневых функций, сделал по-быстрому:
не, я не настолько тупой, %-) я написал криво. надо было написать: «мне лом было разбираться в твоём коде». %-)

зыж гы. таки мой способ медленней. убрал одну регулярку — стал шустрей. переписал без регулярок, с двумя словарями — стало ОХЕРЕННО шустрей. тестировал на spidermonkey, для Оперы не проверял. %-)

твой:
16.67s user 0.49s system 82% cpu 20.781 total
мой:
19.83s user 0.34s system 85% cpu 23.565 total
мой без одной регулярки:
14.19s user 0.25s system 85% cpu 16.848 total
мой без регулярок, с двумя словарями:
js test_$num.js 4.10s user 0.08s system 83% cpu 5.013 total
гы. %-)

невозбранно проапдейтил jsunfold.

(Reply to this) (Parent) (Thread)

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

вот от реализации регулярных выражений
и будет зависеть скорость их работы:
чтобы они действительно быстро работали
они должны быть компилируемыми, а JS,
как известно, интерпретатор, и всегда
регулярные выражения будут медленнее,
чем эквивалентный им строковый парсинг.

(Reply to this) (Parent) (Thread)

>так у меня неоптимизированно было.
да это понятно. %-)

>чтобы они действительно быстро работали
>они должны быть компилируемыми
а фиг знает, что он там в кишках делает — лень исходник читать. я ему позволял сделать прекомпиляцию — я создавал регулярку один раз, а не при каждом вызове test/match/replace.

>всегда
>регулярные выражения будут медленнее,
>чем эквивалентный им строковый парсинг.
неа. %-) в Lua бывает наоборот, особенно на шибко больших строках.

(Reply to this) (Parent)

Значит там плохая библиотека регулярных выражений используется, либо очень неэффективно. Странно.

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent)

> я, честно говоря, нифига не понял, что ты там со строкой делаешь, потому тупо переписал. %-)
А я понял! Я всё переписал, даже пытался ставить разнообразные closure, анонимные функции, addeventlistener и т.п. (всё, о чём прочитал вчера), делать всё одной функцией (с минимумом переменных), но в Опере всё равно не работало.

Преобразование алгоритмически можно делать быстрее, конечно, но смысла нет (и не факт, что в Яваскрипте действительно будет быстрее, да и быстродействие с учётом размеров комментариев неважно) — сэкономить на попытке преобразовать пару символов, когда первый заведомо единственный.
Короче говоря: язык интерпретируемый, без изысков библиотечные регулярные выражения должны работать быстрее, чем циклы и вообще последовательности команд (в особенности функция pick). Всё-таки регулярные выражения такого уровня — конечный автомат, который для поиска всех вхождений проходит по строке ровно один раз.

Вот ketmar указал, что дело скорее всего в байтиках со значениями 128-255 — кодировка не UTF-8. Глюк Оперы, на мой взгляд.
Но после перекодировки в UTF-8 (сначала я просто русский текст переписал: э,Э, утошга каледин, кря, — через \u…, потом табуляцию, потом автоматически обработал, чтобы CRLF) странное сообщение об ошибке исчезло, а работать всё равно не стало. Ну да ладно, посмотрю, как сделал ketmar, в Опере у него определённо должно было заработать, пойму, чего не хватало.

Изучу на досуге Яваскрипт, штука в таком виде (пользовательском) полезная…

(Reply to this) (Parent) (Thread)

>язык интерпретируемый, без изысков библиотечные регулярные выражения
>должны работать быстрее, чем циклы и вообще последовательности команд
а ни разу не факт, потому что все его компилируют в VM. что Опера, что Mozilla.

>Всё-таки регулярные выражения такого уровня — конечный автомат, который
>для поиска всех вхождений проходит по строке ровно один раз.
это если они написаны именно так (лом лезть в исходники spidermonkey).

>странное сообщение об ошибке исчезло, а работать всё равно не стало
гы. а это потому, что сравнение со строкой «[b]kaledin[/b]». а Опера в данном случае выдаёт тэги в upper case. %-) проверь (давай уж на «ты», а? %-), увидишь.

>посмотрю, как сделал ketmar
вот так %-) (это примерно в 4 раза быстрее, чем оригинал). и заменил проверку на case insensetive.

>Изучу на досуге Яваскрипт, штука в таком виде (пользовательском)
>полезная…
на самом деле язык убойный. с поддержкой замыканий, анонимных функций, run-time расширяемых классов с приватными данными и ты пы. только мало кто этот язык знает, хотя и много кто на нём пытается писать. %-)

зыж а ещё в Опере есть свойство innerText (а в тормозилле нет, и поэтому они мудаки странные люди). то же, что innerHTML, только все тэги выкидывает нафиг.

(Reply to this) (Parent) (Thread)

Ясно. Давай. Можешь меня и во "френды" внести (политику твою я читал на этот счёт).

А как проверять быстродействие?

(Reply to this) (Parent) (Thread)

>Можешь меня и во «френды» внести
да на здоровье, мне не жалко. журнал читать пока лень (но в RSS засунул), по общению вроде адекват. %-)

ну, если мой дневник смотрел — я матерюсь, неполиткорректно выражаюсь, мне насрать на чужое мнение и ты пы. если вдруг захочешь «френдовыноса» — пиши, оформим точно так же. %-)

>А как проверять быстродействие?
лично я проверяю консольным интерпретатором js от Mozilla. как обычно — цикл кучу раз и замеряем встроеной в шелл командой time.

то же самое можно делать и в броффзере (см. объект Date, он умеет давать текущее время), но лениво.

консольный инерпретатор я честно собрал из исходников spidermonkey с мозиллосайта. как оно собирается под винду — совершенно не в курсе, к счастью, я уже несколько лет как о ней практически забыл. %-)

(Reply to this) (Parent) (Thread)

консольный инерпретатор я честно собрал
Вряд ли у меня дойдёт до этого…

(Reply to this) (Parent) (Thread)

в линуксе оно просто. svn co, ./configure && make && make install, и всё собралось да поставилось.

ну, пусть не совсем так просто, я для себя ещё руками пилял, но суть не меняет. %-)

(Reply to this) (Parent) (Thread)

svn
Это ты гонишь: у них CVS (который у меня падает при вводе пароля, но всё равно исходники скачать можно). С помощью SVN ты качаешь не с mozilla.org, полагаю.

Потом я долго настраивал Visual Studio (для работы в командной строке: у них есть спец. файл для прописывания путей, но он их прописывает неправильно).

Потом я нарыл make-файл в интернете http://bindzus.wordpress.com/2008/02/08/spidermonkey-solution-file-for-microsoft-visual-studio-2005/ — он подходит для 1.7.0, для текущей ветки не подходит (там какие-то сложности с jsiter, именно как человек и обнаружил и исправлял, не знаю, почему работает под Линуксом).

Так что jsshell.exe у меня теперь свежесобранный (но не из свежайших исходников от разработчиков) есть.

Так что фигня та же (основной геморрой был из-за сбитых настроек VS, которые она сама берётся восстанавливать, но восстанавливает неправильно).

(Reply to this) (Parent) (Thread)

>Это ты гонишь: у них CVS
думаешь, я помню точно, как я там качал кучу месяцев назад? %-)

>не знаю, почему работает под Линуксом
у меня древнючий JavaScript-C 1.8.0 pre-release 1 2007-10-03. новые «фичи» типа итераторов меня совершенно не волнуют, пока их не добавят в Оперу. надеюсь, и не добавят, ибо в стандарте ECMAScript я такого не видел. остальное работает. собралось, помню, без шаманства (или почти без шаманства).

с MSVS работать не умею вообще, MinGW наше всё. %-)

(Reply to this) (Parent) (Thread)

Я скачал стандарт (ECMA-262-3), начинаю читать.

Но для правильного использования всё равно придётся много читать про DOM-ы…

Я вообще больше на Паскале. Поэтому все такие (MSVC) вещи с тормозами получаются.

(Reply to this) (Parent) (Thread)

я тоже паскалист… был. сейчас уже всеядное непоймичто.

(Reply to this) (Parent)

(Сложности с jsiter в 1.7.0 [и 1.60?] исправлены человеком по ссылке, для того и качал make-файл, а в текущей ветке всё немного сложнее. Собрал в итоге 1.7.0 с помощью скачанного make-файла без каких-либо изменений.)

(Reply to this) (Parent)

кстати, есть ли под линукс
(визуальный) дебаггер баша?

(Reply to this) (Parent) (Thread)

фигассе. честно уронил челюсть. %-)

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

собственно, а зачем? если логика настолько сложная, что уже надо отлаживать, не стоит ли подумать о perl/python/Lua/etc?

зыж фтопку баш. zsh наше фсьо. %-) может, в zsh что-то и есть по этому поводу, я всё никак не соберусь сего монстра выучить. %-)

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

честно — по-моему, проще переписать, чем чужой хлам отлаживать. %-)

(Reply to this) (Parent)

>зыж а ещё в Опере есть свойство innerText (а в тормозилле нет, и поэтому
>они мудаки странные люди). то же, что innerHTML, только все тэги
>выкидывает нафиг.

в FF это называется textContent,
что соответствует 3 уровню DOM

(Reply to this) (Parent) (Thread)

да хоть analFixation. ребята из в3ц в очередной раз радостно проигнорили то, что было до них (абсолютно логичный innerText, который можно логически вывести из innerHTML) и придумали свою хуету. «потому что своя». при этом innerHTML не уничтожили и не заменили на htmlContent (см. HTML5, где innerHTML есть официально), как было бы (снова-опять) логично.

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

вообще, DOM API — то ещё говнище. я не знаю, чем думали его авторы, но подозреваю, что это слово начинается на «ж» и заканчивается на «опа».

(Reply to this) (Parent)

>Изучу на досуге Яваскрипт, штука в таком виде (пользовательском)
>полезная…

о, я бы не советовал, а порекомендовал бы
что-нибудь более изысканное, кроме того,
есть ли под JS инструментальная поддержка
(дебаггер и т.п.) - вот в чём вопрос.

ну, может это я привык уже к комфорту,
хотя, отутствие инструментов может тебе
серьёзно затормозить процесс, как кажется

(Reply to this) (Parent) (Thread)

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

Дальше поток сознания.

ну, может это я привык уже к комфорту
Ты забыл, наверное: я Дельфам нередко предпочитаю редактор Фара (что вызвано тормозным вылезанием автодополнения для свойств-методов-элементов классов-объектов-интерфейсов: если знаешь, что хочешь, быстрее набить самому, чем выбрать из списка, тем более, что названия не всегда оптимизированы: бывает много строк, начинающихся, например, на "item", когда чаще всего ты пользуешься, например, "items", ну и для других популярных объектно-ориентированных штук [типа: "somepointer as TMyMiddleClass"] не очень ИСР зажигают).

С js я уже собрал (что тривиально по модулю настроенности инструментов на компьютере) jsshell — текстовую версию в командной строке (spidermonkey), так что какие-то минимальные инструменты есть.

Ява, например, мне отчаянно не нравится (как более мощный и "изысканный" инструмент из другой весовой категории; к тому же в Паскале многие библиотеки для работы с интернетом тоже есть, как и в давно знакомом цепепе), а яваскрипт как помощник при регулярном пользовании броузером — штука гораздо более лёгкая.

Всё упирается в DOM-ы, которые придётся изучать. А также внутреннюю структуру часто посещаемых сайтов. С самим языком проблем нет, ты же, наверное, прочитал ketmar: проблема-то была в том, что Опера переводит метки команд в верхний регистр (что лечится сравнением без учёта регистра), прочитать же и понять код на Яваскрипте я могу и без подготовки, как и передрать какой-нибудь чужой код, по модулю таких заковык.

(Reply to this) (Parent) (Thread)

>Всё упирается в DOM-ы, которые придётся изучать
на самом деле достаточно десятка методов и свойств. я, например, досконально этот идиотский API не знаю. %-)

ещё полезно поучить XPath, чтобы удобно ноды выбирать.

>прочитать же и понять код на Яваскрипте я могу и без подготовки
хихик.

function A () {
  function B () {
    var i = 5;
    return [(i++)+(arguments.length?arguments[0]:0), arguments.callee, function () { return (i++); }];
  }
  var t = B(2);
  var z = 7+t[0]+t[1]()[0];
  z += t[2]()+B()[0]+t[2]();
  return z;
}

результат вызова A()? %-)

(Reply to this) (Parent) (Thread)

да, поддерживаю с xpath,
на него достаточно часа.

в DOM тоже важна идея,
а не реализация - нужен
он лишь для траверса по
XML-дереву, а также для
манипулирования его узлами.

(Reply to this) (Parent) (Thread)

>да, поддерживаю с xpath,
>на него достаточно часа.
и потом немного траханины, чтобы выяснить, где что как реализовано.

>в DOM тоже важна идея,
>а не реализация
но логика ввода/именования методов и свойств там совершенно марсианская.

(Reply to this) (Parent) (Thread)

кстати, про xpath: как выделить нод,
внутри которого выполнены критернии,
например, тэг А, который содержит
определённый текст (заселектить
нужно именно А, а не текст внутри)?

(Reply to this) (Parent) (Thread)

это тебе, я полагаю, надо использовать XPath Axes. например:
//tr[descendant::a[@class='forumlink']]
находит ячейку таблицы, которая содержит ссылку с классом forumlink.

(Reply to this) (Parent)

В общем, в зависимости от того, что считать подготовкой, я разобрался скорее всего с подготовкой:)

Сборку jsshell, наверное, следует считать подготовкой.

Расстановку print() и манипуляции со скобками — тоже, наверное:)

Сперва я зашёл в тупик с вызовом t[2]: думал, ругнётся на отсутствие i.

Потом началась порнография с использованием jsshell…

Спасибо за пример, ты в чём-то прав, но возраст не позволил мне послать неправильный ответ
1. о том, что функция ругнётся на отсутствие i,
2. вторая же версия тоже оказалась неверна (B(...)[2] берёт значение i, дошедшее до неё на момент определения функции),
3. на самом деле f=B(...)[2] держит у себя ?статическую? переменную, создаваемую при вызове B, и при каждом вызове f её увеличивает (но для разных вызовов B переменные эти разные):)

(Reply to this) (Parent) (Thread)

пример, конечно, насквозь artificial, зато показывает заморочки с closures.

для «3» — она не «статическая», она «замкнутая». при вызове функции js создаёт «замыкание» со всеми описаными локальными переменными (но не с аргументами функции! я на этом погорел однажды %-), и дальше этот «микрокосм» живёт себе отдельно. тут бы по совету phantom тебе пригодился опыт со scheme, там замыкания достаточно широко используются. в компилируемых же языках такого механизма в принципе нет (в java есть, но сделано через жопу, многословно и толком всё равно не работает %-).

(Reply to this) (Parent) (Thread)

То, что написал я про "статические" абсолютно верно (я же описал механизм, это то же самое, то, что она не является статической в смысле, например, Цепепе, итак ясно):)

Употреблять слово "замкнутая" — та же фигня, я написал "статическая" как человек новый.

(Reply to this) (Parent) (Thread)

>То, что написал я про «статические» абсолютно верно
да, но лучше применять правильный термин. в этом и был смысл моего уточнения. %-)

а то путаница будет, «статическая» традиционно обозначает static из цэ.

хотя «замкнутая» мне тоже не нравится. но другого нет пока, афаик.

(Reply to this) (Parent) (Thread)

(Reply to this) (Parent)

эта фича традиционно называется
"лексические замыкания", хотя
данное название, как ты понимаешь,
абсолютно неверно и противоречиво.

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

>в компилируемых же языках такого механизма в принципе нет

это в корне неверное утверждение.
замыкания есть почти во всех "свежих"
компилируемых языках, таких как
D, Nemerle, Scala и даже Visual Basic

(Reply to this) (Parent) (Thread)

>в компилируемых же языках такого механизма в принципе нет

это в корне неверное утверждение.
замыкания есть почти во всех "свежих"

Конечно неверное.

Утверждение не моё, но ketmar, наверное, прочтёт этот твой комментарий.

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

(Reply to this) (Parent) (Thread)

>но ketmar, наверное, прочтёт этот твой комментарий.
таки пропустил. %-)

http://lj.rossia.org/users/phantom/33098.html?thread=377418#t377418

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

(Reply to this) (Parent) (Thread)

скорее таки нечто вроде «делегатов»
Их-то наверняка, ибо они и в "Объектном Паскале", и в Дельфах есть. Как продукт вторичный, ФриПаскаль скорее неохотно поддержит чужую фигню, чем сделает по-своему что-то новое.

Сознаюсь/соглашусь: понятия не имею о планах на "замыкания", но какие-то (пока — внутренние) штуки, как-то связанные с функциональной парадигмой там появляются, так что со стороны реализации в компиляторе к "замыканиям" они приближаются (в основном, правда, это SSA и SSU оптимизации, причём SSU, как я понял, может и не появиться, а SSA как-то используется).

Я "делегатами" не пользовался, а вот по (не до конца понятным мне образом увязываемым с "делегатами" как сугубо объектно-ориентированная альтернатива) внутренним классам весьма скучаю.

(Reply to this) (Parent) (Thread)

>Их-то наверняка, ибо они и в «Объектном Паскале», и в Дельфах есть.
это где же в Delphi делегаты? впрочем, я считаю, что Delphi закончился на 7-й версии, дальше пошло какое-то пиздоблядство, которое ни ставить, ни использовать не надо.

>а вот по (не до конца понятным мне образом увязываемым с «делегатами» как
>сугубо объектно-ориентированная альтернатива) внутренним классам весьма
>скучаю.
лучше бы сделали одну простую вещь — защищённые/приватные объявления в модуле.

interface
type private TMyType;
type protected PMyType = ^TMyType;
implementation
type TMyType = ….;

с обычным смыслом protected/private. и да — возможностью объявлять имя в интерфейсе и описание в реализации. мне часто этого не хватало.

(Reply to this) (Parent) (Thread)

Я пользуюсь D2007. Она более готова к современным реалиям: в D7 неправильно работают объекты (хранящийся в стеке аналог класса), ужасная работа с памятью (медленно и глючно, естественно, в условиях большой нагрузки, которую, видимо, не особо отлаживали/предполагали в давние годы).

Часть этого можно исправить какими-то заплатками неофициальными, но поддержка всякой "Просеки" и т.п. даётся с ещё бОльшим трудом (для меня лично камень преткновения — управление памятью).

Мне не нравится среда разработки, но всё равно пользуюсь.

Вот так.

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

(Reply to this) (Parent) (Thread)

>в D7 неправильно работают объекты (хранящийся в стеке аналог класса)
??? O_O это, пардон, бредятина какая-то написана. class — это одно. object — совсем другое. class instance — третье. object instance — четвёртое. ниего не понял.

>жасная работа с памятью (медленно и глючно, естественно, в условиях
>большой нагрузки, которую, видимо, не особо отлаживали/предполагали в
>давние годы).
все давно привинтили fastmem заместо стандартного аллокатора (который дебильный, да). в следующих версиях даже борланды догадались и запихали fastmem в коробку. мне это удивительно, потому что обычно они пихают в коробку наиболее глючный и наименее юзабельный из всех возможных вариантов (FastNet, QuickReport, Rave Reports, Indy).

>Мне не нравится среда разработки
аналогично. потому использовалась только для рисования форм, остальной код делался в фаре. %-) впрочем, формы в Delphi ублюдские — где layout manager? завсегда приходилось накладывать поверх свои костыли.

>Лазарь для графических интерфейсов не годится совершенно.
O_O пуркуа? у меня отлично получалось, чем именно он не годится?

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

(Reply to this) (Parent) (Thread)

??? O_O это, пардон, бредятина какая-то написана
ЧЁД: http://community.freepascal.org:10000/docs-html/ref/refch6.html#x61-690006 (у объектов ключевое слово "object", а не "class")

все давно привинтили fastmem заместо стандартного аллокатора
В принципе да, но неофициально.

аналогично. потому использовалась только для рисования форм, остальной код делался в фаре. %-)
Близко к этому и у меня. Хотя в седьмой версии интерфейс и быстродействие получше обычно.

где layout manager?
Что это?

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

зыж хотя в принципе сам паскаль для GUI непригоден вовсе. как и любой язык, в котором нет сборщика мусора.
Наверное, да. Хотя это не единственное, чего не хватает. Но Яве, например, сборщик мусора не помогает (тормоза).

(Reply to this) (Parent) (Thread)

>у объектов ключевое слово «object», а не "class"
я в курсе, я ещё помню торжественное появление TP5.5. потому и озадачиваюсь — не бывает «хранящихся на стеке объектов», только экземпляры оных. и, кстати, что там работает неверно? по-моему, всё точно как в TP5.5.

>В принципе да, но неофициально.
с D8 или D10 официально.

>Что это?
в двух словах — «автораскладчик» контролов. который криво-криво и тупо-тупо, кряхтя и матерясь, можно сэмулировать кучей панелей и выставлением align: layout managers. нужен для нормального создания «резиновых» морд. align/anchors тут не катит, слишком бедный инструмент.

>войств мало у каких-то стандартных классов, поддержка Дельф хромает
Lazarus is *not* an 'open source Delphi clone'. So don't expect 100% compatibility.

>Яве, например, сборщик мусора не помогает (тормоза)
а это уже другая проблема. см. Oberon — и мусор собирает, и тормозов нет. и дальше BlackBox Component Builder, как очень навороченая RAD с инсталлятором в 5 мб, написаная на Component Pascal — наследнике Oberon.

(Reply to this) (Parent) (Thread)

и, кстати, что там работает неверно?
Исходники не пришлю, но изначально написанное на ФриПаскале в D7 вызывало глюк в компиляторе, в D2007 нормально компилировалось (даже если глюк в программе, в компиляторе он точно есть). Замена объектов на классы проблему решала. Но везде переделывать не хотелось.

с D8 или D10
Это определённо не D7…

layout managers
Да, вещь нужная. Да, её нет.

So don't expect 100% compatibility.
Как я и написал, после выбора Дельф для перехода на Лазаря эта поддержка необходима. Дельфы были выбраны два года назад, тогда Лазарь хромал (кажется, я даже полужирным шрифтом без извращений не мог на форме писать).

см. Oberon
Посмотрю. Но, похоже, больше смотреть мне надо на цепепе, где даже свойств в классах, по словам товарищей, нет: только в интерфейсах. Сейчас в процессе рассмотрения вакансии цепепешной (ради большего количества математики, а не ради цепепе).

(Reply to this) (Parent) (Thread)

>Замена объектов на классы проблему решала.
хм. объекты и классы — сильно разные вещи. подозреваю, что ошибка таки была в логике.

>даже если глюк в программе, в компиляторе он точно есть
и не один. я лично два или три находил.

>Это определённо не D7…
а кто мешает в D7 fastmem всунуть? нигде не сказано, что «нельзя трогать аллокатор из генофонда».

>после выбора Дельф для перехода на Лазаря эта поддержка необходима
да, придётся поработать напильником. зато один раз. %-)

>на цепепе, где даже свойств в классах, по словам товарищей, нет
нет. но это мелочи. труп страуса очень болен фимозом головного мозга был, к сожалению.

>Сейчас в процессе рассмотрения вакансии цепепешной
искренне сочуствую. злейшему врагу не пожелаю работать в цпп-проекте. плавали, знаем…

(Reply to this) (Parent) (Thread)

подозреваю, что ошибка таки была в логике.
1. Во ФриПаскале работало без намёков на проблемы.
2. Никакие ошибки в логике пользовательской программы не должны вызывать исключений в dll-ках компилятора.

а кто мешает в D7 fastmem всунуть? нигде не сказано, что «нельзя трогать аллокатор из генофонда».
Лень мешает и совместимость: нужно всем всовывать. Собирают мои тексты не у меня на машине. Вот переход на D2007 — понятно. А что-то курочить, когда у большинства и так работает — не поймут. И так с надстройками (TMSUnicode, ещё что-то) накладки происходят иногда.

да, придётся поработать напильником. зато один раз. %-)
Ненавижу ковыряться с собственным старым кодом. Я ж не так давно профессионально стал программировать, и тексты у меня весьма корявые.

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

(Reply to this) (Parent) (Thread)

>1. Во ФриПаскале работало без намёков на проблемы.
это ещё не значит, что всё было правильно.

>2. Никакие ошибки в логике пользовательской программы не должны
>вызывать исключений в dll-ках компилятора.
мнэ… а зачем ты с собой эти DLL таскал и использовал? оно лицензией запрещено.

>Лень мешает и совместимость: нужно всем всовывать. Собирают мои тексты не
>у меня на машине.
ну и что? положил к себе в каталог, добавил в bpg — получилось. чем оно отличается от исходников, написаных лично тобой в этом случае? это не компоненты, это модуль, прописал в uses и поехало.

>Ненавижу ковыряться с собственным старым кодом.
хи. а заодно и отрефакторить по пути можно. всяко дело полезное. %-)

>Ява меня пугает больше
как раз жабка проще в плане синтаксиса. для цпп вообще компилятора не существует (вроде бы всё ещё нет; обломки, не реализующие стандарт ANSI, полноценными компиляторами называть нельзя), о чём дальше говорить-то?

а библиотек и там, и там немеряно, запутаешься одинаково.

(Reply to this) (Parent) (Thread)

мнэ… а зачем ты с собой эти DLL таскал и использовал?
Ой! А я просто кнопочку "компилировать" в среде разработки нажимаю, а мне пишут об исключении в DCC70.DLL. Это запрещено лицензией??

это не компоненты, это модуль, прописал в uses и поехало.
В тот момент оказалось, что в D2007 работает, а в D7 — нет. То, что дело именно в управлении памятью, скорее догадка.
О том, что реальные пацаны меняют управление памятью, я узнал существенно позже (переделывать проекты D2007 в D7 наверняка можно, но лень).

хи. а заодно и отрефакторить по пути можно. всяко дело полезное. %-)
Но что-то тоска берёт.

запутаешься одинаково
По-разному. К Яве-то у меня неприязнь. Её ещё преодолеть надо.

(Reply to this) (Parent) (Thread)

>А я просто кнопочку «компилировать» в среде разработки нажимаю
не нажимай. IDE — то ещё глючище, особенно если у тебя компонентов понаставлено. собирай при помощи dcc32.exe

>переделывать проекты D2007 в D7 наверняка можно, но лень
не надо там ничего переделывать. включил в проект fastmem, прописал во всех uses первым и всё. это все изменения.

>К Яве-то у меня неприязнь.
у меня тоже, хрен редьки не слаще, в общем-то.

(Reply to this) (Parent) (Thread)

не нажимай. IDE — то ещё глючище,
Что ж, хороший повод для обновления (правда, среда D2007 глючит в целом больше, но со сборкой проблем меньше).
Честно говоря, сомневаюсь, что dcc32.exe и dcc70.dll существенно отличаются в этом смысле.

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

(Reply to this) (Parent) (Thread)

>Честно говоря, сомневаюсь, что dcc32.exe и dcc70.dll существенно
>отличаются в этом смысле.
ещё как. среда падучая по жизни, и по абсолютно любой непредсказуемой причине. очень много к этому добавляют всякоразные компоненты, которые срут куда не попадя в памяти. вообще, категорически воспрещено юзать что-либо сверх Raize (и иногда TNT). а лучше и без них. и сервиспаки все накатить, натурально.

а в следущих версиях исправили как раз стабильность: падать стало стабильно чаще. %-)

(Reply to this) (Parent)

защищённые/приватные объявления в модуле.
Зачем?

(Reply to this) (Parent) (Thread)

interface

type private TMyOpaque;
type PMyOpaque = ^TMyOpaque;

type TMyOuterClass = class
 protected
  fData: PMyOpaque;
 ….
end;

implementation

type TMyOpaque = record
  …
end;

что даёт рабочую проверку типов, но невозможность «поковыряться» в TMyOpaque.

без такой фигни придётся переносить TMyOpaque в реализацию, делать fData простым указателем и потом без конца трахаться с приведениями. или показывать всем потроха TMyOpaque.

плюс — поскольку TMyOpaque приватная, класс-наследник из другого модуля может юзать указатель TMyOpaque/PMyOpaque, но всё равно внутрь никак не влезет.

модификатор protected нужен для расширяемых записей (вроде в D8 или D9 это появилось).

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

ну, когда ты один код пишешь — вполне пофигу. а вот когда рядом пара обезьянок — лучше от них попрятать всё, что можно. если не спрятать — всенепременно полезут кривыми руками куда не положено.

(Reply to this) (Parent)

>почти во всех «свежих»
>компилируемых языках
из них «компилируемый» — только D. надо глянуть, как оно там сделано — я как-то плохо представляю эффективную реализацию замыканий в «нативном» компияторе. и вообще. так что ни у кого нет. %-)

зыж то, что компиляется в код какой-либо VM, «компилируемым» в моём понятии не является, пока этой VM нет в железе.

(Reply to this) (Parent)

в немерле есть замыкания

(Reply to this) (Parent) (Thread)

так оно ж функциональщина, куда оно без замыканий? %-)

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent)

кстати, немерле (как и жаба) — не «компилируемые» языки. я (виноват, не пояснил) имелл в виду «компилируемые в нативный код».

(Reply to this) (Parent) (Thread)

компилируемость всегда
довольно условное понятие

(Reply to this) (Parent) (Thread)

потому и говорю, что виноват. надо было мне сразу термин определить.

(Reply to this) (Parent)

>jsshell.exe 1.js
37

Это со смыслом ответ, или так?

(Reply to this) (Parent) (Thread)

>Это со смыслом ответ, или так?
надо было до «42» дотянуть, не догадался. так что без смысла, просто цифры. %-)

(Reply to this) (Parent)

>что-нибудь более изысканное
например? (не флейма для)
синтаксис дело десятое. а если всмотреться, то js — гибрид императивщины и функциональщины. %-)
closures есть, lambda calculus есть. не знаю, правда, оптимизируют ли вендоры tail calls.
при этом есть классы с приватными данными и возможностью расширять/урезать/менять методы в рантайме.

если на мой скрипт глянуть — это одна большая анонимная функция. а внутри активно применяются замыкания и даже есть один класс. %-)

(Reply to this) (Parent) (Thread)

несмотря на поддержку этого,
синтаксис JS грязноват -
сказывается возраст и
наследие синтаксиса C.

т.к. ppkk математик,
я бы ему советовал Хаскел или Лисп.
лучше изучить язык с более чистым
синтаксисом, а потом рассматривать
другие языки через призму "чистых",
чем сначала испортиться "грязными",
и смотреть через "грязное" стекло.

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

(Reply to this) (Parent) (Thread)

>т.к. ppkk математик,
>я бы ему советовал Хаскел или Лисп.
поздно, он уже Delphi знает. %-)
а хаскель точно для математиков, я ниасилил. %-)

лисп да, хорошо, писал на нём (на самопальном диалекте). мозг прочищает неплохо.

>сейчас предпочитаю Немерле
моё изучение немерле закончилось на буквах «.Net». после чего поделие отправилось фтопку, а авторам — пожелание убиццо апстену.

(Reply to this) (Parent) (Thread)

а какие у тебя претензии к дотнету,
и какие предлагаешь альтернативы?

хаскел поддается изучению, просто
"с наскока" его изучать не стоит.

(Reply to this) (Parent) (Thread)

>а какие у тебя претензии к дотнету
винда only. mono не предлагать.

>какие предлагаешь альтернативы?
java (Кэтмар блюёт). а вообще — нафига эти монстры? Python+PyQt/PyGTK, Lua+luaqt/luagtk.

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

(Reply to this) (Parent)

ну и, кстати, Oberon.

(Reply to this) (Parent)