Зло какое-то

[metaclass]

Школьный Линукс и входной порог разработки

Борландовские Паскали, С и тому подобное работали под досом без плясок с бубном и ставились простым копированием.
Дельфи в 1997 году поставилась на 95 винду и заработала сразу. За день можно написать прототип DB приложения, вообще видя среду разработки в первый раз. Visual C в то же примерно время - то же самое, разве что писать чуть сложнее, это вам не RAD.
Вижуал студия с дотнетом в 2006 вроде бы году - аналогично, поставил, за день разобрался.

А в линуксе до сих пор какое-то вуду, стоит только выйти за рамки стандартных задач.

Comments

[theiced.livejournal.com]

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

PS. ну и справедливости ради - гдб (к коему есть отличная морда для емаксов) всё это умеет искаропки.

[denisioru.livejournal.com]

Между простейшими случаями в один поток и "нормальными" в пары сотни - есть масса вещей, которые встречаются в реальной жизни, но явно отсутствуют в Вашем воображении ;)

[theiced.livejournal.com]

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

[denisioru.livejournal.com]

ок, есть REST-сервис, который ждет изменения состояния неких приборов. Как правило, юзер одновременно мониторит до 10-20 приборов. В некоторых случаях есть условия, при которых изменения надо игнорировать. Условия мониторинга меняются юзером во время ожидания изменения состояний приборов. Хочется поставить контрольную точку и посмотреть ряд параметров в одном из потоков мониторинга, которые получаются при совпадении некоторых условий. А также знать, откуда ноги растут у условий.

[theiced.livejournal.com]

см. ответ на пост ниже.

[metaclass.livejournal.com]

Работа в одном потоке в гуишной проге с неебическими структурами данных. Их визуализировать в лог и потом анализировать заебешся, если честно. Это еще хорошо, когда у них встроенные методы дампа есть, но без этого - проще запустить в VS и посмотреть на значение переменной (оно из ее типа автоматом делает гуишный дампер хитрый).

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

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

[theiced.livejournal.com]

>Работа в одном потоке в гуишной проге с неебическими структурами данных. Их визуализировать в лог и потом анализировать заебешся, если честно. Это еще хорошо, когда у них встроенные методы дампа есть, но без этого - проще запустить в VS и посмотреть на значение переменной (оно из ее типа автоматом делает гуишный дампер хитрый).

если методов дампа нет - то у вас уже всё плохо и проект находися в большой яме с говном. у меня методы дампа есть _всегда_, я живу в паралельном мире.

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

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

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

Честно скажу, необходимость отслеживать стек вызовов возникала у меня всего несколько раз. Но для этого у меня уже было логирование вызова методов (с LOG_LEVEL_DEBUG) сразу ;]

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

[metaclass.livejournal.com]

У меня в продакшене логов столько, что иногда клиенты плачут, просят сделать их round-robin, чтобы место не жрали. У меня не линукс, logrotate нету под руками к сожалению, хорошо хоть log4net сам ротатить умеет.

Ну вообще у вас все правильно написано. Тем не менее - стек вызовов нужен, безальтернативно. Сделать лог, по которому его можно восстановить - это пиздец, нужно логить вообще все, что выполняется.

[theiced.livejournal.com]

int foo(int bar, char *baz, huita *bee) {
  LOG(LOG_LEVEL_TRACE, "CALL: foo(%d, %s, %s)", bar, baz, huita_dump(bee));

не? пишется на полнлом автомате, тратятся на это секунды.

[metaclass.livejournal.com]

Затем при рефакторинге меняются имена методов, списки параметров, и прочая. И вслед за ними - править все логи.
Кстати о huita_dump - строку возвращаемую кто удаляет?

[theiced.livejournal.com]

в стуктуре тупо есть char[xxx] __dump; в отладочном режиме - простейшее решение. есть эзотерические решения на диких макросах (выделение памяти специальным макросом, заносящим выделенный адрес в __dumps и освобождение "своих" строк в конце вызова LOG (написал лет так 8 назад, использую до сих пор).

[metaclass.livejournal.com]

а, т.е. huita_dump __dump заполняет и возвращает его?

[theiced.livejournal.com]

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

[theiced.livejournal.com]

(загробным голосом)

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

[thedeemon.livejournal.com]

>в нормальных случаях (ака пара сотен тредов)

Это нормальный случай только для индусов низшей касты. Пример однозначно плохого дизайна.

[theiced.livejournal.com]

буа-ха-ха. не - если вы хелловолы пишете, то да.

[thedeemon.livejournal.com]

У вас на одной машине пара сотен ядер? Нет? Тогда сотни тредов только жрут ресурсы и мешают друг другу. Несколько потоков + асинхронные операции эффективней, только это ж думать надо, порождать треды проще конечно.

[theiced.livejournal.com]

64 ядра например. оптимально при данной конкретной задачи 150 потоков, нет - распаралелить на несколько боксов не проще.

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

[thedeemon.livejournal.com]

>случай когда потоки большей частью в идле и таки да - они нужны.

Вот так и получаются всякие Аутлуки, которые ничего не делают аж в 50 потоков.

[theiced.livejournal.com]

иногда так надо. честно. если есть желание - завтра как проснусь попробую сформулировать.

[thedeemon.livejournal.com]

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

[metaclass.livejournal.com]

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

[w00dy.livejournal.com]

так бывает надо. В молодости писал софтину для телефонии, мониторили линии, дык у нас там и по 300 тредов было из который 200 в идле. А всё потому что обработка события может занимать ощутимое время. Когда один обработчик держит одну линию, то это пофиг, ибо генератором событий является человек, а он думает дольше. А вот когда один обработчик держит несколько линий, то начинает собираться очередь, плывёт время и наступает жопа.

[w00dy.livejournal.com]

Ситуации разные бывают. Всё зависит от того чем в этих потоках заниматься, если там какой-нить конечный автомат или что-то event-driven, то не вижу никаких проблем чтобы это выпихнуть в отдельные треды и не заморачиваться. Да и в системе явно больше чем 100 потоков числится, и это ей не мешает.

[thedeemon.livejournal.com]

Молодец, вот тебе новый юзерпик: