Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
private void ScanDir()
{
CurrentLevel++;
string save_dir=CurrentDir;
int i=0;
if (current_dirs.Length>0)
for (;i<current_dirs.Length;i++)
{
out_data+=current_tabs+"<DIR> "+CutPathName(current_dirs[i])+"\r\n";
try { CurrentDir=current_dirs[i]; }
catch
{
out_data+=current_tabs+"<ошибка доступа>\r\n\r\n";
CurrentDir=save_dir;
continue;
}
waiting=true; // синхронизатор этого потока
Thread.Sleep(120); // задержка, что бы второй поток успел скинуть данные
while (saving) // ожидание флага из потока записи
Thread.Sleep(100);
waiting=false;
ScanDir();
CurrentDir=save_dir;
}
else
out_data+=current_tabs+"<папки отсутствуют>\r\n";
save_dir=null;
string[] inner_files;
try { inner_files=Directory.GetFiles(save_dir); }
catch { out_data+=current_tabs+"<ошибка доступа>\r\n\r\n"; return; }
if (inner_files.Length>0)
for (i=0;i<inner_files.Length;i++)
{
out_data+=current_tabs+CutPathName(inner_files[i])+"\r\n";
inner_files[i]=null;
}
else
out_data+=current_tabs+"<файлы отсутствуют>\r\n";
inner_files=null;
CurrentLevel--;
}
Загрузка списка файлов и директорий на диске.
Оптимизировано для уменьшения потребления памяти и нагрузки CPU.
От одного только описания оптимизации хочется убежать и спрятаться под одеяло:
"Для оптимизации я добавил в глобалку следующую инфу:
1) массив текущих папок;
2) текущий уровень вложения;
3) текущую папку для глобалки;
4) строка табуляции;
5) свойства для п. 2 и 3.
2 для того, что бы в его свойстве (5) менять табулятор (4) по необходимости;
3 добавлено исключительно для свойства (5), в котором подгуржаются текущие папки (1)."
К счастью он еще не работает, человечество пока в безопасности. Пока только заканчивает вуз и делится своими творениями на форумах.
Когда ему сказали про стиль кода - не проникся и ответил, что ему и так норм.
1. а что, кто-то нынче на шарпах без решарпера пишет?
2. Проблема имени Тараса. Надуманная имхо
3. Ну ок, будем хардкодить /r/n во все строки, главное ведь избавиться от ненавистной конкатенации.
у мусо-досников больше проблем с тем что часто у последней строки нет \n. потому что многие виндозники интерпретируют текстовый файл как список строк с \n разделителем. но не все. почему и грабли. в одном редакторе в файле Н строк - в другом Н+1. одна тулза съела файл - друга споткнулась.
по крайней мене на юнихах определение сидит в позикс и разброда и шатания нету: текстовый файл это список строк, каждая из которых заканчивается \n.
а на виндах... я месяц назад из некро-тулчейна ворнинги видел, типа: "у последей строки нет терминатора! я это умею обрабатывать, но дайте я вам в логи все равно посру!!" как если бы назад 20 лет в прошлое вернулся...
Многие мусодосные/виндозные проги одиночный \n вообще за перевод строки не считают. За перевод строки они считают именно комбинацию \r\n (именно так, а не наоборот).
А что касается финального \r\n, то всё так: одни проги считают \r\n окончанием строки, другие — разделителем строк. Это примерно как финальная запятая в инициализации массива, которая в одних ЯП создаёт лишний пустой элемент, в других ЯП игнорируется.
gcc из mingw действительно до сих пор срёт ворнингом, если у последней строки нет терминатора, но... всё нормально компилирует и без него.
на гцц не видел - а вот какие-то тулзы из vs2008 радостно кричали.
с последним \n, на прошлых проектах это была медленная неспешная cold war. придут юниксоиды - в файлы последний \n вставят. след релиз делают жабщики - и ихняя эклипсня на последний \n "жалуется" как на пустую строку - удаляют. самое смешное было что в паре файлов в конце стоял умилительный коммент: "последнюю пустую строку не удалять!!"
это все всплыло когда в геррит в авто-ревьювер вставили эти проверки для текстовых файлов. жабщики сразу вонь подняли: гиги бойлер-плейта в ихнем свинге - это у них всегда пожалуйста, а вот "лишние" концы сторок в паре текстовых файлов... - "но пассаран"!
Надо просто в printf (ну т.е. string.Format) добавить модификатор, который раскрывается в Environment.NewLine, какой-нибудь "%L". Мне даже кажется, я где-то что-то похожее видел, но не помню, где.
я уже пару раз (буквально: два раза) делал обертки для ostream/streambuf в С++ которая конвертила "\n" (и начало строки) в то что было нужно. уверен что даже в вашем шарпе подобное делается.
я к тому что плодить костылей не надо - оно уже давно в большинстве систем спокойно стандартный "\n" работает.
даже на виндах - как долго штатный нотепад не используешь (и им уже давно никто не пользуется) ниразу не заметишь что у тебя файл с юникс концами строк.
В текстовых редакторах \n работает. Во многих ЯП работает. А вот bat-файл и прочая виндопитушня требует \r\n, иначе считает, что это однострочник, и обламывается.
я уверен что VB/VBA тоже обломится. но этим говном нормальные люди все равно не пользются. а те у кого уже некрософто-опухоль-мозга появилась - они живут в своем мрачном мирке и ничего другого и не знают.
Тут вот что интересно:
1. Компиляторам божественной сишечки наплевать на представление концов строк: хоть \n, хоть \r\n работает в любой операционной системе. И многие другие компиляторы терпимо относятся к нестандартным разделителям.
2. Скриптовые языки (bash в никсах, bat в мусодосах/виндовозах) требуют определённого разделителя: в никсах только \n (если где-то встретится \r\n, то интерпретатор ругается на незнакомый ему символ \r), в виндовозах только \r\n (если где-то встретится одиночный \n, то он за разделитель строки посчитан не будет).
Заметим, что по отношению к операционным системам всё симметрично, но по отношению к ЯП неоднообразно.
Это ещё хорошо, что классическая Макось (которая без буквы Х в названии) ушла в анналы истории, потому что в ней разделителем строк был \r.
в старые времена это было CoreFoundation (== stdlib for ObjC) и поверху него Cocoa (CF* классы vs NS* классы (NS == NeXT Step)). CoreFoundation она гуи-лессе в духе, но ОС сама по себе гуи-сентрик поэтому (как и на виндах) различия делать смысла мало.
>Cocoa Umbrella Framework
> Foundation (Foundation.framework). The classes of the Foundation framework (which resides in the Core Services layer) implement data management, file access, process notification, network communication, and other low-level features.
Foundation and Core Foundation provide basic data types and data management features, including the following:
> waiting=true; // синхронизатор этого потока
>Thread.Sleep(120); // задержка, что бы второй поток успел скинуть данные
> while (saving) // ожидание флага из потока записи
> Thread.Sleep(100);
> waiting=false;
Лул, прямо-таки последнее слово синхронизации потоков, Brian Goetz лопнул от зависти, наблюдая такой анскилл многопоточного программирования.
С диска нельзя прочитать байт. Минимальная единица, которую можно прочитать, это сектор.
Тем не менее, на высоком уровне создаётся ощущение, что "прочитать байт" можно: ОС читает сектор и складывает его в кэш, из которого потом можно достать следующие байты.
В общем, необходимая задержка зависит от устройства кэша.
из DRAM тоже нельзя прочитать байт: читать можно только шириной чипа (который может быть меньше байта, лол!). Но благодаря кешу мы про это ничего не знаем.
Просто у диска пенальти больше. Потому все ФС старались выравнивать по границе блока (который был 512 байт до недавнего времени везде)
Пошёл на ютубчик, пересмотрел. Вы всё врёти. Я сказал, что многие известные программисты шмогли без математики. Кому-то она нужна, кому-то не особо. Мне например, в последнее время, всё больше и больше нужна статистика и тервер.
Контроль качества данных. Есть массив данных (~10^9), надо оценить, насколько хороши или плохи различные его срезы. Многие вещи можно проверить только глазами людей, и хочется максимально эффективно использовать человеческий труд, результаты которого, в частности, потом используются для обучения машин.
На одном из предыдущих мест работы мне бы тоже статистика не помешала, но я тогда ещё об этом не знал.
Ты действительно считаешь, что я имел в виду SPJ? Лол, уж он-то знает математику получше нас всех. Я читал многие его статьи (особенно мне доставила статья про алгебру финансовых контрактов, на этих результатах целая индустрия сейчас построена) и смотрел записи его докладов. Умеет, могёт.
Ну и он дело говорит: он не любит держать в памяти всякую ерунду и предпочитает просто использовать мозг, чтобы находить/выводить результаты. Зачем запоминать результаты, которые тривиально выводятся из общих принципов.
Чувак, который пилит реализацию хаскеля, должен хорошо знать свою работу. Он должен уметь хорошо класть керпич на кирпичь. Он должен знать устройство линий кэша, работу конвейера и предиктора команд, чтобы получить пирфоманс. А про математику кукарекают те, кто за свою жизнь не написали ни одной программы.
И да, в JS можно сделать большой typed array и начать его долбить(читать/писать в него), замеряя время задержки. Таким образом можно определить кэши проца
Откуда мне знать? Я уверен, что примерно половина моих коллег на работе (а то и больше) о нём не слышали. Сам понимаешь, шансы у рандомного багора на ГК и того меньше.
noname 12 часов назад
> Ты действительно не умеешь в иронию?
> Ты правда думаешь что я не знаю кто такой JSP, и считаю что ...
Чтобы понимали иронию и оценивали уровень знаний, нужно писать с личной учётной записи.
Даже когда есть "запомненный" результат, неплохо бы уметь его быстро воспроизвести, чтобы проверить.
Я помню, что 7*8 это 56, но обычно всё равно проверяю себя примерно так:
7*8 == 7 * (10 - 2) = 70 - 7+7 = 56
Таблица умножения полезна, но знание простых хаков для быстрого умножения, кмк, полезней — область применения шире.
> намного проще это запомнить
Ну мне, например, настолько редко нужно считать производную отношения двух функций, что мне проще её вывести, когда нужно, хотя и выучить её, казалось бы, просто.
Как секундный слип после чтения каждого байта зависит от устройства кэша? Это в сотни раз больше, чем любой сик по диску, так что на фоне такого слипа похуй откуда байт: из пейджкэша, с соседнего сектора, или с другого края блина.
Дальше и смотреть не стал. Въебал плюсъ.
Пойду глаза с мылом помою
Бесплатные Environment.NewLine; закончились?
Ох, тут два типа нейминга...
А сурьезно - тайком поставь стайлкоп и не давай компилить неотрефакторенный код
Когда ему сказали про стиль кода - не проникся и ответил, что ему и так норм.
Это же пиздец, такую длинную хуйню каждый раз писать, да еще и клеить строки придется
env[enter].nl[enter]?
2. проблема километровой длины не решена
3. проблема конкатенации не решена
2. Проблема имени Тараса. Надуманная имхо
3. Ну ок, будем хардкодить /r/n во все строки, главное ведь избавиться от ненавистной конкатенации.
у мусо-досников больше проблем с тем что часто у последней строки нет \n. потому что многие виндозники интерпретируют текстовый файл как список строк с \n разделителем. но не все. почему и грабли. в одном редакторе в файле Н строк - в другом Н+1. одна тулза съела файл - друга споткнулась.
по крайней мене на юнихах определение сидит в позикс и разброда и шатания нету: текстовый файл это список строк, каждая из которых заканчивается \n.
а на виндах... я месяц назад из некро-тулчейна ворнинги видел, типа: "у последей строки нет терминатора! я это умею обрабатывать, но дайте я вам в логи все равно посру!!" как если бы назад 20 лет в прошлое вернулся...
А что касается финального \r\n, то всё так: одни проги считают \r\n окончанием строки, другие — разделителем строк. Это примерно как финальная запятая в инициализации массива, которая в одних ЯП создаёт лишний пустой элемент, в других ЯП игнорируется.
gcc из mingw действительно до сих пор срёт ворнингом, если у последней строки нет терминатора, но... всё нормально компилирует и без него.
с последним \n, на прошлых проектах это была медленная неспешная cold war. придут юниксоиды - в файлы последний \n вставят. след релиз делают жабщики - и ихняя эклипсня на последний \n "жалуется" как на пустую строку - удаляют. самое смешное было что в паре файлов в конце стоял умилительный коммент: "последнюю пустую строку не удалять!!"
это все всплыло когда в геррит в авто-ревьювер вставили эти проверки для текстовых файлов. жабщики сразу вонь подняли: гиги бойлер-плейта в ихнем свинге - это у них всегда пожалуйста, а вот "лишние" концы сторок в паре текстовых файлов... - "но пассаран"!
Например, \cykablyad
я к тому что плодить костылей не надо - оно уже давно в большинстве систем спокойно стандартный "\n" работает.
даже на виндах - как долго штатный нотепад не используешь (и им уже давно никто не пользуется) ниразу не заметишь что у тебя файл с юникс концами строк.
1. Компиляторам божественной сишечки наплевать на представление концов строк: хоть \n, хоть \r\n работает в любой операционной системе. И многие другие компиляторы терпимо относятся к нестандартным разделителям.
2. Скриптовые языки (bash в никсах, bat в мусодосах/виндовозах) требуют определённого разделителя: в никсах только \n (если где-то встретится \r\n, то интерпретатор ругается на незнакомый ему символ \r), в виндовозах только \r\n (если где-то встретится одиночный \n, то он за разделитель строки посчитан не будет).
Заметим, что по отношению к операционным системам всё симметрично, но по отношению к ЯП неоднообразно.
Это ещё хорошо, что классическая Макось (которая без буквы Х в названии) ушла в анналы истории, потому что в ней разделителем строк был \r.
Потому что языки в жопе.
Это анонимусов. Он попросил сфотографировать, т.к. хотел использовать обе руки для эффектной демонстрации.
последний раз когда трогал - NeXT гуи (Cocoa) во времена 10.3-10.5 - все также послушно использовали разделитель \r.
а когда начинается BSD - то там \n.
но даже и гуи файло/этц с \n читает правильно.
> в никсах только \n (если где-то встретится \r\n, то интерпретатор ругается на незнакомый ему символ \r)
да, это я как то и подзабыл. isblank('\r') != true; почему шелл и попытается \r как команду выполнить, потому что \r валидный символ имени файла.
Foundation это тоже часть кокоа, и кто скажет что NSObject или NSString это GUI тот пусть бросит в меня яблоко.
Гуй это AppKit (или UIKit в случае яблофонов)
>Cocoa Umbrella Framework
> Foundation (Foundation.framework). The classes of the Foundation framework (which resides in the Core Services layer) implement data management, file access, process notification, network communication, and other low-level features.
Foundation and Core Foundation provide basic data types and data management features, including the following:
Collections
https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/OSX_Technology_Overview/CocoaApplicationLayer/CocoaApplicationLayer.html
>Thread.Sleep(120); // задержка, что бы второй поток успел скинуть данные
> while (saving) // ожидание флага из потока записи
> Thread.Sleep(100);
> waiting=false;
Лул, прямо-таки последнее слово синхронизации потоков, Brian Goetz лопнул от зависти, наблюдая такой анскилл многопоточного программирования.
Жидкокристаллический?
@@на коленке
Увидел блики экрана в растекающейся жидкости? Тоже мне - открытие...
Роман Кащицын пытался намекать.
+N = AskUser("Примерно оцените мощность вашего компьютера по шкале от 0 до 1")
+120*N
в добавок, прозрачная авто-коррекция всех возможных ошибок!
бонус: очень экономичный расход памяти!!!
он рендом потому что можно не последовательно читать
и что, без слипа с диска нельзя читать не последовательно?
Тем не менее, на высоком уровне создаётся ощущение, что "прочитать байт" можно: ОС читает сектор и складывает его в кэш, из которого потом можно достать следующие байты.
В общем, необходимая задержка зависит от устройства кэша.
Просто у диска пенальти больше. Потому все ФС старались выравнивать по границе блока (который был 512 байт до недавнего времени везде)
Он тоже любит попиздеть про всякую низкоуровневую хуиту.
Остальные тут или математики (как Рома) или джаваскриптеры, простихосподи
Я вообще ни разу не математик, просто математику люблю.
тебя забыл, правда
ты тоже годный
В интервью на ютубчике, емнип, Роман говорил, что математика программисту не нужна.
Пошёл на ютубчик, пересмотрел. Вы всё врёти. Я сказал, что многие известные программисты шмогли без математики. Кому-то она нужна, кому-то не особо. Мне например, в последнее время, всё больше и больше нужна статистика и тервер.
Контроль качества данных. Есть массив данных (~10^9), надо оценить, насколько хороши или плохи различные его срезы. Многие вещи можно проверить только глазами людей, и хочется максимально эффективно использовать человеческий труд, результаты которого, в частности, потом используются для обучения машин.
На одном из предыдущих мест работы мне бы тоже статистика не помешала, но я тогда ещё об этом не знал.
это тебе не плагины к вордпрессу писать
Кегги у нас вроде самый активный дотнетчик.
Постоянно новеньких как но называть?
А почему я не Борланд?
кегги и борманд разные
вот ты вырастишь в борманда, это точно
Что вообще за Кегги?
Сдохнуть блядь не дадут, J им подавай.
Кегги не дотнетчик. Кегги - фулстек
Я тоже так думал, пока один свой pet-проект в Safari не открыл.
Некорректный вопрос. Я с ним тупо не встречался. Bootstrap юзал.
>> И view ports знаешь что такое?
Видимые полигоны на конкретном фрейме? По работе не использовал
Признайся, ты просто загуглил фразу и процитировал вики
Я про https://www.w3schools.com/css/css_rwd_viewport.asp
Его с головой выдаёт толстота и глубокие познания в C#.
https://github.com/roman-kashitsyn
https://github.com/zawodskoj
https://github.com/bormand
https://github.com/1024--
https://github.com/k32
https://github.com/j123123
https://github.com/NodnolStudio
https://github.com/Abbath
но наверно не полный
давайте палите гитхабы свои
@j123123 Update anal_x86_cs.c
хахах
https://github.com/Kegdan
https://github.com/lure0xaos
> Huffman.hs - Кодирование тескт с помощью арголитма Хаффмана
Вот так и складывается впечатление, что хачкелисты -- неграмотные школьники.
Ты действительно считаешь, что я имел в виду SPJ? Лол, уж он-то знает математику получше нас всех. Я читал многие его статьи (особенно мне доставила статья про алгебру финансовых контрактов, на этих результатах целая индустрия сейчас построена) и смотрел записи его докладов. Умеет, могёт.
Ну и он дело говорит: он не любит держать в памяти всякую ерунду и предпочитает просто использовать мозг, чтобы находить/выводить результаты. Зачем запоминать результаты, которые тривиально выводятся из общих принципов.
Ты правда думаешь что я не знаю кто такой SPJ, и считаю что чувак который пилит реализацию хаскеля не может в математику?
А еще в JS нет 64-битных интов
Откуда мне знать? Я уверен, что примерно половина моих коллег на работе (а то и больше) о нём не слышали. Сам понимаешь, шансы у рандомного багора на ГК и того меньше.
> Ты действительно не умеешь в иронию?
> Ты правда думаешь что я не знаю кто такой JSP, и считаю что ...
Чтобы понимали иронию и оценивали уровень знаний, нужно писать с личной учётной записи.
Мемоизация потому что. Не будешь же ты каждый раз в уме считать 7*8, намного проще это запомнить
Даже когда есть "запомненный" результат, неплохо бы уметь его быстро воспроизвести, чтобы проверить.
Я помню, что 7*8 это 56, но обычно всё равно проверяю себя примерно так:
7*8 == 7 * (10 - 2) = 70 - 7+7 = 56
Таблица умножения полезна, но знание простых хаков для быстрого умножения, кмк, полезней — область применения шире.
> намного проще это запомнить
Ну мне, например, настолько редко нужно считать производную отношения двух функций, что мне проще её вывести, когда нужно, хотя и выучить её, казалось бы, просто.
Помнится, я даже на егэ выводил с нуля всю хрень в духе sin(a+b) = ... т.к. запоминать её было влом.
Я вообще всю эту тригонометрическую ересь забыл почти сразу, как узнал о разложении тригонометрических функций в комплексные экспоненты.
Наконец появились пруфы, что борманда взломал сукаблядь. Все знают, что настоящему было >30.
ceil(31) = 40.
Хаскель он написать осилил, а LINQ изучить нет
Звучит внушительно. "Арго" (тайный язык) и "литм" (от гр. λίθος, камень?) Т.е. окаменевший мемчик?
Нахуя она мне?
— Хватит прикалываться, Настенька!
:M3}|{q TYT ldM
!ld7-ld7-ld7 --
я им читал MSIL
давно было дело