[10:01:42] <valexеy> .
[10:19:18] <valexеy> "В начале октября стало известно, что Государственная Дума также планирует запретить продажу алкогольных напитков везде, кроме специализированных магазинов."
[15:51:34] <alexey.veselovsky> .
[16:55:22] <alexey.veselovsky> vlad2: жабоскриптописатели тоже циклами озаботились!!!1 http://habrahabr.ru/post/154201/
[18:13:37] <vlad2> Ужос.
[18:15:40] <alexey.veselovsky> на лоре битва за стиль: http://www.linux.org.ru/polls/polls/8224699
[18:15:57] <alexey.veselovsky> кстати, это похоже тот тип срачей который обероновцами еще не опробован в полной мере
[18:20:34] <vlad2> Да, у них редкостное единодушие.
[18:20:55] <alexey.veselovsky> максимально нечитабельный код - наше ффсйо!
[18:20:56] <vlad2> Несколько операторов на строчку - можно назвать чисто обероновским.
[18:20:58] <alexey.veselovsky> ;-)
[18:21:35] <alexey.veselovsky> ну, да. у них же даже такая абстракция как отдельная функция для блока операторов является платной ;-)
[18:21:43] <alexey.veselovsky> инлайна то нетути
[18:22:20] <alexey.veselovsky> а еще однобуквенные названия для переменных и двух-трех буквенные для модулей
[18:22:29] <alexey.veselovsky> афигенно читабельно. никакой обфускатор не нужен!
[18:22:47] <vlad2> Угу.
[18:23:15] <vlad2> А если еще и однобуквенную кириллицу подмешать...
[18:24:06] <alexey.veselovsky> CPB, CPC486, CPE, CPH, CPL486, CPM, CPP, CPS, CPT - набор модулей компилятора
[18:26:38] <alexey.veselovsky> вообще, у меня от просмотра ББшных исходников перманентное ощущение, что этот код был не написан человеком, а сгенерирован автоматически из какого-то нормального исходника
[18:27:42] <alexey.veselovsky> замечу, что от просмотра исходников на хаскелле такого ощущения нет, хотя там однобуквенных переменных полно.
[18:43:32] <vlad2> Это на самом деле признак поколения компьютерщиков до 90-х.
[18:43:53] <alexey.veselovsky> почему?
[18:43:54] <vlad2> Еще времен, когда длина идентификатора была ограничена 8 символами.
[18:44:13] <vlad2> Посмотри зотя бы стандартную cbiye. kb,e/
[18:44:20] <vlad2> сишную либу
[18:44:39] <alexey.veselovsky> дык 8 символов - это ж ДОФИГА!
[18:44:53] <alexey.veselovsky> а они же используют не 8, а от силы 3 символа!
[18:45:06] <vlad2> Не так уж и дофига. open_file уже не напишешь.
[18:45:33] <alexey.veselovsky> fopen и харе :-) но это же лучше чем просто fo
[18:45:36] <vlad2> Потому что удобнее всегда шифровать, чем только тогда, когда не хватает.
[18:46:30] <vlad2> Дык, это стандартная либа - максимально читабельной сделана ;)
[18:46:37] <alexey.veselovsky> кроме того, лимиты у Оберона вроде бы сразу были вменяемыми
[18:47:11] <vlad2> Это мое предположение. Научившись шифровать, потом трудно отказаться :)
[18:48:03] <vlad2> Кроме того, ограничения на длину имени файла тоже были ;)
[18:48:18] <vlad2> А называть файл не как модуль - некошерно.
[18:48:35] <vlad2> Короче, тяжелое детство, деревянные игрушки.
[18:49:11] <mister-kemet> 8 символов в иденте это ладно, но бесконечные идентификаторы с некоторым колвом значимых это блин фигово, хрен найдешь, а вирт такой подход и использует
[18:49:13] <mister-kemet> IF i < 31 THEN name[i] := ch; INC(i); INC(k, ORD(ch)) END ;
Texts.Read(R, ch)
END ;
[18:49:14] <alexey.veselovsky> вообще, в хаскелле очень вменяемые правила гм. шифрофки. например - не имеет смысл подробно обзывать сильно абстрактные локальные переменные (ну например аргументы функции swap), с другой стороны, то что торчит наружу - обзываем подробно. а что-то из предментной конкретной области - уже не экономя на буквах совсем
[18:49:18] <vlad2> Еще есть категория математиков/физиков - у них там никогда длинныхидентификаторов не было.
[18:50:05] <alexey.veselovsky> ну, у хаскелистов они есть, подход см. выше.
[18:50:20] <alexey.veselovsky> а вот фортрановский код математиков и физиков это да-а. на это смотреть нельзя
[18:51:06] <vlad2> Да, я тоже локальные переменные однобуквенными нередко делаю. Все что наружу - полными существительными и глаголами.
[18:51:17] <alexey.veselovsky> mister-kemet: не понял проблемы
[18:51:49] <vlad2> Вообще виртовский код по моему мнению - хуже среднего.
[18:51:53] <alexey.veselovsky> /me еще любит однострочечные функции и тогда злобно ломая стиль кодирования, эту функцию умещает в одну таки строчку
[18:53:54] <mister-kemet> alexey.veselovsky: длина идента неограничена, но значимых в нем к примеру 31, потом фигово читать — нужно в голове учитывать значимую длину
[18:53:55] <alexey.veselovsky> vlad2: ты вот лучше скажи - правда ли, что при вызове любой функции дергается alloca?
[18:54:18] <alexey.veselovsky> mister-kemet: ой, мама. я и не думал что такое бывает!
[18:55:15] <alexey.veselovsky> это ж прям таки Microsoft-style! У них тоже на хотмейле вроде бы, пароли могли быть любой длины, но значимых букафф там было 16ть.
[18:55:41] <vlad2> У борданда первых версий тоже такое было.
[18:55:49] <vlad2> В смысле дерагется alloca?
[18:55:52] <vlad2> C чего вдруг?
[18:56:03] <alexey.veselovsky> ну а как там на стеке иначе место выделяется?
[18:56:20] <vlad2> Где там?
[18:56:23] <alexey.veselovsky> alloca это ж вроде builtin функция компилера
[18:56:46] <alexey.veselovsky> ты вызываешь функцию, прежде чем передать ей управление нужно на стеке фрейм сообразить под её локальные переменные и аргументы
[18:56:56] <alexey.veselovsky> я правильно понимаю что это делается через ту же alloca?
[18:57:01] <mister-kemet> alexey.veselovsky: в оригинальном обероне так и есть — длина неогранеичена, но значимых 31, это, вообщк-то не проблема или подход Вирта, такой подход раньше часто применялся
[18:57:01] <vlad2> Нах?
[18:57:15] <vlad2> Функция сама сдвигает SP на сколько ей надо.
[18:57:53] <vlad2> Там в винде какой-то версии был нюанс, что надо какие-то приседания делать. Но ты так просто на это не наткнешься.
[18:58:28] <vlad2> Если заведешь лоакльный массив более чем 4кб - можно увидеть.
[18:58:36] <alexey.veselovsky> vlad2: ну, это ж стандартный код для сдвигания SP. Ну и вообще, присядания таки нужны бывают.
[18:59:15] <alexey.veselovsky> Я просто ищу то самое место, общее, которое именно этим занимается. Потому как "просто сдвинуть SP" мне не слишком подходит.
[18:59:36] <alexey.veselovsky> вон, в llvm аж специальная инструкция есть: http://llvm.org/docs/LangRef.html#i_alloca
[19:00:27] <alexey.veselovsky> и судя по вот этому: http://llvm.org/demo/index.cgi там таки при вызове функции как раз alloca и юзается
[19:00:33] <vlad2> int f()
{
char a[4096];
}
[19:00:49] <vlad2> ?f@@YAHXZ PROC      ; f

; 2    : {

push ebp
mov ebp, esp
mov eax, 4104    ; 00001008H
call __chkstk

; 3    : char a[4096];
; 4    : }

mov esp, ebp
pop ebp
ret 0
?f@@YAHXZ ENDP      ; f
[19:01:06] <vlad2> __chkstk: http://forum.pellesc.de/index.php?topic=15.0
[19:01:29] <vlad2> Это актуально для винды. Для других платформ, возможно, тоже есть заморочки.
[19:01:32] <alexey.veselovsky> define i32 @f() nounwind uwtable {
 %1 = alloca i32, align 4
 %a = alloca [4096 x i8], align 16
 %2 = load i32* %1
 ret i32 %2
}
[19:02:46] <vlad2> void f2()
{
char a[1024];
}
[19:02:53] <alexey.veselovsky> сзначит что? значит надо добраться до alloca в llvm/clang и подхачить его. либо коварно его обернуть на уровне clang'а
[19:02:57] <vlad2> ?f2@@YAXXZ PROC      ; f2

; 7    : {

push ebp
mov ebp, esp
sub esp, 1032    ; 00000408H

; 8    : char a[1024];
; 9    : }

mov esp, ebp
pop ebp
ret 0
?f2@@YAXXZ ENDP      ; f2
[19:03:24] <vlad2> здесь просто sub esp
[19:03:47] <alexey.veselovsky> и call __chkstk нету
[19:03:59] <vlad2> Дык, я и говорю.
[19:04:17] <alexey.veselovsky> плагинчик к шлангу написать что-ли...
[19:04:28] <vlad2> Оно было актуально для какой-то первой винды.
[19:08:20] <alexey.veselovsky> вау. то что хочу я, то уже сделано давно похоже: http://llvm.org/releases/3.0/docs/SegmentedStacks.html
[19:08:30] <alexey.veselovsky> ну или что-то подобное
[19:09:18] <vlad2> Хе-хе. Только на линуксе и x86.
[19:09:37] <alexey.veselovsky> мне этого достаточно :-)
[19:10:02] <vlad2> Блин. На маке перестала работать распаковка таров и архивов. Файндер просто висит.
[19:10:22] <alexey.veselovsky> это все потому, что он чувствует что ты его не любишь!
[19:10:27] <alexey.veselovsky> вот он и сцыт тебе в тапки!
[19:10:36] <alexey.veselovsky> он же большая кошшка :-)
[19:11:16] <mister-kemet> большая кошка это AROS, вернее маленькая такая кошечка )
[19:11:51] <alexey.veselovsky> да, я эту киску даже ставил помнится
[19:11:58] <alexey.veselovsky> годика 4 назад
[19:12:18] <mister-kemet> не, она счас шибко продвинулась
[19:12:50] <alexey.veselovsky> да? надо будет защупать.  а то тогда было очень уж печально все. та же Haiku уже тогда смотрелась много живее
[19:13:33] <mister-kemet> ну хайку и сейчас живее всех живых, но арос тоже пошла вперед, видимо поняли, что нужно чтото менять
[19:14:23] <alexey.veselovsky> а что там с морфосью? загнулось вместе с пегасосом?
[19:14:28] <vlad2> Пусть не ссыт. Просто в коммандлайн пойду.
[19:14:51] <mister-kemet> видимо
[19:15:45] <mister-kemet> мне морфос не интересно, а арос мы используем для терминалов
[19:15:50] <alexey.veselovsky> а еще там же вроде амигаось 4 вроде как собиралась выйти.
[19:16:01] <alexey.veselovsky> вау! а почему именно арос?
[19:16:47] <alexey.veselovsky> vlad2: вау! эта хрень и в gcc реализована! http://gcc.gnu.org/wiki/SplitStacks
[19:16:59] <alexey.veselovsky> не успел я придумать, а они уже реализовали все!
[19:17:49] <mister-kemet> это торговые терминалы, там на лазаре писанная кассовая программа крутится ну и по мелочи, просто лазарус и сириус портировать под арос было проще чем под хайку )
[19:18:17] <alexey.veselovsky> как побочный эффект от ковыряния в этом, я таки понял как работают goroutines в Go - вот именно так они и работают. в виде такого вот бесконечного двусвязного стека.
[19:18:54] <alexey.veselovsky> mister-kemet: а почему проще, кстати? ведь под гайкой например с Qt все хорошо
[19:20:22] <mister-kemet> ну тогда с кутой было плохо, да и на фрипаскале у нас много софта, а под гайкой оно като не очень, да и сама гайка в этом плане мне не нравится, нужно было маленькую и простую ось, выбрали арос, сейчас пилим А2
[19:20:52] <alexey.veselovsky> прикольно
[19:21:09] <alexey.veselovsky> какой-нибудь syllable os не щупали?
[19:21:31] <mister-kemet> пробовал, но там такая хреня, лазарус трудно портировать
[19:22:12] <mister-kemet> да и оч глючная силабля эта, а уж фс там вообще ненадежная, но драйвера пишутся сильно проше, да
[19:23:05] <alexey.veselovsky> а вообще, по моему, сейчас можно не париццо, взять какую-нибудь рабиспьери-пи, воткнуть туда андроид и радоваться. размером комп будет с кредитку.
[19:23:23] <alexey.veselovsky> гуйня на андроиде ваяется элементарно. под тачскрин все заточено.
[19:24:58] <mister-kemet> alexey.veselovsky: у меня в оснрвном паскалисты работают им андроид противопоказан )) правда сейчас мы в некоторых моментах для себя мигрируем с фрипаскаля на модулу-3
[19:25:35] <alexey.veselovsky> гм. а чо это? ява она такая няшная ведь.. ну только синтаксис другой :-)
[19:26:49] <alexey.veselovsky> о, gcc-шечка рулит:
[19:27:04] <mister-kemet> идеология, трудно менять, да и не нужно, дельфи, фрипаскаль, модула-3 и сириус покрывают 10000% наших интересов и в принципе позволят решать любые задачи
[19:27:05] <alexey.veselovsky> -fsplit-stack
Generate code to automatically split the stack before it overflows. The resulting program has a discontiguous stack which can only overflow if the program is unable to allocate any more memory. This is most useful when running threaded programs, as it is no longer necessary to calculate a good stack size to use for each thread. This is currently only implemented for the i386 and x86_64 back ends running GNU/Linux.
When code compiled with -fsplit-stack calls code compiled without -fsplit-stack, there may not be much stack space available for the latter code to run. If compiling all code, including library code, with -fsplit-stack is not an option, then the linker can fix up these calls so that the code compiled without -fsplit-stack always has a large stack. Support for this is implemented in the gold linker in GNU binutils release 2.21 and later.
[19:27:14] <alexey.veselovsky> теперь даже компилер не нужно хачить. достаточно попробовать поюзать опцию эту.
[19:27:52] <alexey.veselovsky> mister-kemet: у меня постоянно ощущение что вы там то-ли ПО для спутников делаете, то ли торговые системы o_O
[19:29:24] <alexey.veselovsky> если эта опция реально работает, то ЕРЛАНГ НИНУЖЕН!!11 равно как и Go
[19:29:35] <mister-kemet> мы много чего делам, но спутниками не занимаемся ))) так, робототехникой, для экстремальных ситуаций, а торговые терминалы для себя, чтоб деньжат подзаработать
[19:30:22] <alexey.veselovsky> дас, я тут постепенно дозреваю до попытки соорудить какое-нибудь летающее радиоуправляемое чудовище
[19:30:44] <mister-kemet> ага!

[19:30:54] <alexey.veselovsky> /me ожидает веселье с ПИД-регулятором и, возможно, попытками разобраться с фильтром Каллмана
[19:32:39] <mister-kemet> а зачем тебе вертоле
[19:33:00] <mister-kemet> вертолет
[19:34:01] <alexey.veselovsky> ну, вообще я хочу автожир. но поскольку зима близко, а с автожиром по дому не полетаешь, то на поиграться вначале вертолет или какой-нибудь бикоптер или как его там. с парой винтов в общем в разных концах корпуса.
[19:34:07] <alexey.veselovsky> будет смешно.
[19:36:05] <mister-kemet> вертолет над два винта и синхронизировать
[19:36:26] <alexey.veselovsky> мне пока не понятно как вот такое летает: http://ru.wikipedia.org/wiki/Boeing_CH-47_Chinook
[19:36:53] <alexey.veselovsky> или там горизонтальную скорость придает какой-то еще движок кроме несущих винтов?
[19:41:54] <alexey.veselovsky> сегодня у одного сотрудника свежепочиненный вертолет эпично вмазался в дерево (похоже ветром сдуло). понесли чинить обратно :-)
[19:42:22] <mister-kemet> у нас двух винтовые тиоже выпускались, ну оно также летает, винты вроде управляемые, могут менять угол
[19:42:49] <alexey.veselovsky> а-а. если угол менять, тогда да.
[19:43:22] <alexey.veselovsky> просто если один винт помедленней вращать, а другой с прежней скоростью, то он конечно полетит вперед, но еще и вращаться начнет.
[19:52:04] <mister-kemet> хз, там спец трансмиссия же
[19:53:02] <alexey.veselovsky> трансмиссия трансмиссией, но без перекосов винта не обойдешься. ибо закон сохранения момента силы никто не отменял :-)
[19:53:08] <mister-kemet> они не могут с промизвольной скоростью крутится, скорости синхронизированы, второй винт вообщеможет в безмоторном режиме крутится
[19:53:36] <alexey.veselovsky> ага. тогда ясно.
[19:53:43] <mister-kemet> ну управление перекосами и осуществляется
[19:53:50] <alexey.veselovsky> интересно, а как их калибруют? там ведь высокая точность синхронизации нужна
[19:54:08] <alexey.veselovsky> в наколенных поделках синхронизация динамическая, через электронику
[19:54:22] <mister-kemet> механикоа там
[19:54:29] <mister-kemet> механика
[19:55:16] <alexey.veselovsky> ну, ясное дело что механика. но это ж нужно точно все параметры знать, либо делать хитрую динамическую механику которая будет автоматически стабилизироваться в состоянии равновесия
[19:55:27] <alexey.veselovsky> это не программирование, тут думать нужно!
[19:55:42] <mister-kemet> учитывая, что у нас двухосный гдето в 50-х появлся, какая там электроника, все через хитрую траесмиссию

[19:55:54] <alexey.veselovsky> угу
[20:00:34] <mister-kemet> так шо аатоматы перекосов на коленке не склепаешь, но электроника нам поможет!
[20:01:24] <alexey.veselovsky> ну, в данном случае нужно будет еще сервоприводы лепить чтобы перекашивать винты
[20:02:52] <mister-kemet> это да, походу на коленке такое не слепить, остается одновинтовой
[20:04:16] <alexey.veselovsky> можно двувинтовой с соосными винтами + еще один винт на хвост для перекоса самого вертолета (этот винт маленький)
[20:11:13] <mister-kemet> для соосной тоже нужно хитрую трансмиссию, а иначе как поворачивать
[20:11:56] <mister-kemet> блин чето жаба глючит, постоянно из конференции вылетаю
[20:12:16] <mister-kemet> или это клиент глючит
[20:12:24] <alexey.veselovsky> возможно клиент
[20:12:29] <alexey.veselovsky> я не видел чтобы ты вылетал
[20:13:04] <alexey.veselovsky> да, ну для соосной там нужно по сути две трубы - одна в другой. на каждой крутится свой винт.
[20:13:09] <mister-kemet> ха, так у меня почему то вообще не появляется инфы что я вхожу выхожу
[20:13:25] <alexey.veselovsky> вообще в китайских поделках за 600 рублей как раз такая схема
[20:14:14] <mister-kemet> и почемуто у  меня висит опять двойник, вобщем яндекмс наше фсе )))
[20:14:54] <alexey.veselovsky> дык яндекс мессаджи - это тот же джаббер :-)
[20:15:01] <alexey.veselovsky> причем сервак, сколь я помню, на ерланге
[20:15:23] <mister-kemet> это понятно, но вот както глючит
[20:16:40] <mister-kemet> я подключился и с тех пор висю в конференции хотя уже тысячу раз входил выходил, видимо яша держит соединение хотя меня нет в сети
[20:17:11] <alexey.veselovsky> или где-то глюкануло и просто в мозге сервака осталась запись
[20:17:28] <mister-kemet> тоже может быть
[20:17:46] <mister-kemet> тем более постоянные двойники
[20:18:03] <mister-kemet> один с именем второй с логином
[20:18:18] <alexey.veselovsky> поскольку это у тебя такие проблемы сейчас, подозреваю что это яндекс не дружит с jabber.ru <http://jabber.ru> серваком.
[20:18:56] <mister-kemet> у меня такие же подозрения
[20:19:59] <mister-kemet> видимо придется клиента менять
[20:20:16] <alexey.veselovsky> хотя-я. если так посмотреть, то я с аккаунта на jabber.org <http://jabber.org> сюда зайти вообще не могу. точнее заходить то захожу, но ничего не вижу. отсюда следствие - с jabber.ru <http://jabber.ru> нормально сейчас работает только jabber.ru <http://jabber.ru> сам и gmail.com <http://gmail.com>
[20:21:48] <mister-kemet> надо будет под опенсюзей попробовать какойнить клиент поюзать
[20:28:19] <alexey.veselovsky> вообще странно, что такую штуку со стеком ни в одном из оберонов не провернули
[20:28:34] <alexey.veselovsky> штука то полезная. а реализовать её для оберона - раз плюнуть.
[20:30:07] <mister-kemet> а что там, а то не вникалИДЕ
[20:30:28] <alexey.veselovsky> там штука позволяющая делать стек неограниченным
[20:30:42] <alexey.veselovsky> то есть переполнения стека у тебя не будет никогда (пока есть место в ОЗУ)
[20:31:14] <mister-kemet> это как
[20:31:22] <alexey.veselovsky> это означает что в случае многопоточности, тебе не нужно заводить под каждый поток сразу большой стек (и молиться чтобы он не кончился). ты можешь новому потоку выдать 128 байт стека и все.
[20:31:34] <alexey.veselovsky> и он отрастет в случае необходимости
[20:33:01] <alexey.veselovsky> так, что в прелюдии вызова функции проверяется хватит нам стека или нет, если хватит, то все как обычно, если не хватит, то выделяется еще один кусочек памяти под стек, он связвается с предыдущим кусочком (таким образом стек представляет собой двусвязный список) и функция вызывается уже на новом куске
[20:34:04] <alexey.veselovsky> таким образом 100000 потоков в приложении - легко!
[20:34:25] <alexey.veselovsky> что СИЛЬНО упрощает программирование, и, следовательно, сильно повышает надежность приложения
[20:34:46] <mister-kemet> ну просто происходст подмена стека
[20:35:14] <alexey.veselovsky> ну не совсем подмена. организуется двусвязный список из фреймов стека.
[20:35:23] <mister-kemet> т.е. под каждую процедуру может быть свой сенмент стека
[20:35:35] <alexey.veselovsky> стек остается стеком в математическом смысле слова, но перестает быть непрерывной областью памяти
[20:35:42] <alexey.veselovsky> угу
[20:35:50] <alexey.veselovsky> под каждый ВЫЗОВ процедуры
[20:35:53] <mister-kemet> понятно что список, но, вот как быть с прерываниями
[20:36:01] <alexey.veselovsky> процедура то может быть одна и та же (рекурсивная например)
[20:36:17] <alexey.veselovsky> а какие проблемы с прерываниями?
[20:37:07] <alexey.veselovsky> после выхода из прерывания ты вернешься в свой фрейм стека-списка, указатель на предыдущий фрейм у тебя есть.
[20:37:10] <mister-kemet> ну как потом стек восстанавливать
[20:37:55] <alexey.veselovsky> то есть проблем с переключением контекстов как бэ нет.
[20:38:00] <mister-kemet> или в каждом прерывании тоже свой стек делать?
[20:38:31] <alexey.veselovsky> эмм.. погоди. у прерывания (в обработчике прерываний) ведь тоже есть свой стек.
[20:38:41] <alexey.veselovsky> иначе из обработчика прерывания ты не вызовешь функцию.
[20:39:25] <mister-kemet> ну прерывание же использует текущий сегмент?
[20:39:49] <alexey.veselovsky> нет. у них свой контекст вроде бы. если мы про линух говорим.
[20:40:17] <vlad2> alexey.veselovsky: интересно, как будет выглядть крэш такого приложения с сегментирвоанным стэком? ;)
[20:40:25] <alexey.veselovsky> да, сейчас я могу сурово путать прерывания с сигналами юниксовыми (юникс сингал - это софтверное прерывание, а хардверных у прикладного ПО и не бывает)
[20:40:42] <alexey.veselovsky> vlad2: также. :-) поддержка в gdb есть
[20:40:50] <mister-kemet> эээээ я про проц, как оно в железе делается, надо в интеле посмотреть
[20:40:53] <alexey.veselovsky> то есть по стеку ты сможешь нормально погулять
[20:41:12] <alexey.veselovsky> mister-kemet: а зачем процу поддержка такой фигни как стек? :-)
[20:41:26] <alexey.veselovsky> там же из стека только SP и все.
[20:41:34] <alexey.veselovsky> ну и автоинкремент какой-нибудь
[20:41:47] <alexey.veselovsky> стек штука сугубо софтварезная
[20:41:50] <vlad2> Ох уж этот gdb. Он у меня как раз вчера отказался дебагить на OSX.
[20:42:05] <vlad2> Потому что грузит приложение как-то через одно место.
[20:42:16] <alexey.veselovsky> vlad2: ой, как будто вижуал студия не отказалась дебагить под OSX! ;-)
[20:42:35] <vlad2> Грузит dll ниоттуда (и ХЗ почему)
[20:42:40] <alexey.veselovsky> тем более что у OSX альтернативно одаренный формат бинарников.
[20:42:48] <alexey.veselovsky> там же не elf
[20:44:18] <mister-kemet> alexey.veselovsky: ммм, ну sp и какой-нить splimit, и аппаратная поддержка этой байды, это и есть стек, а софтверный стек это ж совсем другое
[20:44:53] <mister-kemet> мы видимо о разных вещах говорим ))
[20:45:05] <alexey.veselovsky> mister-kemet: ну, то есть я даже в такой примитивщине как msp430 не вижу проблем это реализовать (благо все команды его я помню)
[20:45:45] <alexey.veselovsky> ну и судя по тому, что gcc это дело реализовал именно для x86 и x86_64, там тоже проблем нет. железка к счатью не в курсе на счет этих высокоуровневых извращений :-)
[20:46:37] <alexey.veselovsky> а аппаратные прерывания разруливает ядро. а контекст у процесса он обычный линуксовый контекст. он тоже не затрагивается этими изменениями (то есть ядро линукса патчить не нужно для этого0
[20:47:53] <mister-kemet> аппаратные прерывания же не вызывают переключения контекста
[20:48:39] <alexey.veselovsky> угу. их вызывает уже сам обработчик этих прерываний. обработчик прерываний - кусок ядра.
[20:48:47] <mister-kemet> линуксового контекста
[20:48:52] <alexey.veselovsky> ибо понятие контекста, по сути то, софтверное
[20:48:56] <alexey.veselovsky> дык
[20:50:43] <mister-kemet> контекст есть и аппаратный — процессорный, может происходить переключение режимов работы процессора сос меной регистровоготпула
[20:51:30] <alexey.veselovsky> ну, наверно да. но если регистровый пул оно менять не умеет, то его можно поменять и ручками
[20:54:50] <mister-kemet> можно, но вот произошло прерывание, запустился обработчик, в текущем стековом сегменте сохранился адрес возврата и прочая байда… если теперь изменить стековй регистр, то без высокоуровневой ручной работы эту ситуевину не разрулить, иначе возврат из прерывания не произойдет, ибо адреса в текущем подмененном стеке не будет
[20:55:11] <alexey.veselovsky> из процессоров msp430, arm, x86 я хуже всего знаю, пожалуй, x86. точнее вообще не знаю
[20:56:53] <alexey.veselovsky> в каждом узле/сегменте стека-списка есть же указатель на предыдущий сегмент. то есть если ты можешь вернуться в односегментный стек, то сможешь и в мультисегментный
[20:56:57] <alexey.veselovsky> разницы ровно никакой
[20:57:39] <mister-kemet> ну хз, звтра на PDP-11 поэкспериментирую
[20:58:25] <alexey.veselovsky> ты всегда возвращаешься в конкретный сегмент. разница лишь в том, что в этом что в этом сегменте есть указатель на предыдущий сегмент и когда ты делаешь return, а тебе говорят - ой, а куда ваще возвращаться то? сегмент то кончился (underflow) то ты знаешь что в этом случае иди ка ты по указателю на предыдущий сегмент.
[20:58:30] <alexey.veselovsky> грубо говоря
[21:04:29] <mister-kemet> впринципе, если это все выполнять атомарно, а в прерываниях стек не трогать, то проблем точно не будет )
[21:05:37] <alexey.veselovsky> ну, в общем, в линуксе это реально работает :-)
[21:05:55] <alexey.veselovsky> хотя как реально.. я буду экспериментировать :-)
[21:06:15] <alexey.veselovsky> алсо мне не слишком пока понятно каков размер будет этих чанков/сегментов
[21:06:34] <alexey.veselovsky> ибо будет не здорово если начальный размер стека 128 байт скажем, а расти он будет чанками по мегабайту
[21:08:00] <mister-kemet> ну сегментиы можно делать разных размеров и хранить размер
[21:08:33] <alexey.veselovsky> можно. вот мне и любопытно как это в gcc реализовали
[21:09:15] <mister-kemet> опять сегментация будет, если компайлер протупит, да, надо смотреть гцц
[21:09:40] <mister-kemet> сегментация, в смысле оверхед на память
[21:10:09] <alexey.veselovsky> угу.
[21:10:22] <mister-kemet> если в текущий сенмент не влезли, то придется в новый размещаать, а в старом еще память есть
[21:10:32] <alexey.veselovsky> я подозреваю, что в некоторых случаях (в некоторых приложениях) моя идея будет работать таки лучше чем вот это
[21:12:40] <mister-kemet> что за идея
[21:13:14] <alexey.veselovsky> моя идея в следующем - при переключении контекстов (а мы из руками переключаем) содержимое стека мелких потоков/корутин (у них стеки не большие байт 128-256) копировать в бОльший стек (мегабайт 8) в этом случае стек скорее всего не переполнится, даже если там в середине работы он вдруг понадобится такой большой
[21:13:53] <alexey.veselovsky> а поскольку в моем случае переключение контекстов ручное (yield) то оно гарантированно находится где-то не на глубоком уровне вызовов функции
[21:14:32] <alexey.veselovsky> то есть между yield'ами стек может использоваться интенсивно, но к моменту yield'a у нас стек используется мало
[21:15:15] <alexey.veselovsky> итого, имеем дополнительную экономию памяти это рраз. два - имеем стеки в виде непрерывных кусков памяти
[21:15:44] <alexey.veselovsky> из минусов - во время переключения контекстов вместо сохранения регистров и указателя на стек нам придется еще и копировать весь стек.
[21:16:08] <alexey.veselovsky> это будет оправданно если у нас стеки реально маленькие (сотни байт) в моменты вызовов yield'ов.
[21:16:14] <mister-kemet> а эти мелкие сегменты куда? опять фрагментация памяти
[21:16:30] <alexey.veselovsky> как обычно, пул сегментов.
[21:16:46] <alexey.veselovsky> то есть свой аллокатор памяти специально заточенный под эту задачу
[21:16:59] <mister-kemet> вобщем свой менеджер памяти на стековую память
[21:17:16] <alexey.veselovsky> с логгированием если вдруг модель использования отличается от предполагаемого
[21:17:51] <alexey.veselovsky> можно конечно вообще зверь машину сделать - с динамическим переключением стратегий и выбором оптимальной стратегии для каждого из "потоков".
[21:18:23] <alexey.veselovsky> и пусть живые позавидуют мертвым :-)
[21:19:16] <mister-kemet> ну не знаю как оно на суперскалярных будет
[21:19:54] <mister-kemet> я както тестировал на Alpha код что Губанов писал, там что оо с поиском, такая лада выходила
[21:20:12] <alexey.veselovsky> ну, x86 они же суперскаляры нонче
[21:20:12] <mister-kemet> лажа
[21:20:29] <alexey.veselovsky> суперскаляр суперскаляру рознь :-)
[21:20:50] <mister-kemet> так в интеле и амд много чего от альфы
[21:21:04] <alexey.veselovsky> ну и компилер компилеру рознь. навртли Губанов выдавал код не на шарпе и наврятли ты нашел компилер шарпа под альфу
[21:22:23] <mister-kemet> ну дак ) трудности перевода там были минимальны
[21:22:51] <alexey.veselovsky> дьявол мог быть еще и в компиляторе
[21:23:03] <alexey.veselovsky> c# он же под .net, и там оптимизация в несколько стадий идет
[21:23:24] <alexey.veselovsky> и Губанову может казаться что он пишет разный код, а вот эта связка генерит в конечном итоге одно и то же
[21:23:49] <mister-kemet> ну я нашел там более оптимальный вариант, пришлось перпставлять местами ветки условий
[21:27:02] <mister-kemet> лан пошел спать, у нас пол второго уже
[21:28:45] <alexey.veselovsky> короче, при оптимизации все эти высокоуровневые языки головной боли добавляют достаточно. ибо к тараканам программиста и процессора еще добавляются тараканы компилятора и компоновщика, а в случае жабы и .net'а еще и тараканы виртуальной машины
[21:28:49] <alexey.veselovsky> бай
[22:19:37] <vlad2> /me заставил работать beyond compare на маке. счасть есть.
[22:20:48] <vlad2> через wine и питон
[22:47:43] <valexеy> vlad2: ты ИЗВРАЩЕНЕЦ!!!
[22:47:58] <valexеy> ты бы еще это сделал там через far'овский плагин, ога
[22:51:42] <vlad2> Блин. Ну нет для мака нормальной диффалки.
[22:52:04] <vlad2> Последнюю которую нашел (DiffMerge) - тоже с тараканами.
[22:52:23] <vlad2> Например, там нельзя сделать поиск по файлу и скопипастить искомое!
[22:52:24] <valexеy> диффалка дифферент!
[22:53:44] <vlad2> Но ниче. Обещают нэйтив OSX beyond compare
[22:57:21] <valexеy> вот тогда то заживешь!
[23:03:52] <vlad2> Надо просто дропнуть OSX ;)
[23:03:58] <vlad2> Недоплатформа.
[23:04:05] <vlad2> Пусть эппл сам под нее пишет.
[23:04:53] <vlad2> На языке, вобравшем молниеносность small talk и безопасность C.
[23:05:45] <valexеy> :-)
[23:06:02] <valexеy> но на самом то деле под ObjC писать сейчас уже много комфортней чем под pure C
[23:06:10] <valexеy> честно-честно
[23:06:49] <valexеy> нехватает конечно мелких объектиков с перегружаемыми всякими операторами
[23:06:56] <valexеy> но с новыми литералами это уже не так больно
[23:09:11] <valexеy> то есть если выбирать Си или ObjC, то я таки выберу ObjC (при условии что на всех платформах что мне нужны оно поддерживается)
[23:09:32] <valexеy> Ну и аналогично если ко мне с дулом пристанут и скажут - Оберон или ObjC, то мой выбор будет однозначным.
[23:14:54] <vlad2> И каким же? :)
[23:15:16] <valexеy> ObjC конечно
[23:15:23] <valexеy> он более высокоуровнев