- 1
- 2
- 3
- 4
- 5
let d="please like! "
var c=d
let x=s=>{for(let f=0;f<c.length;f++){eval(s)}}
x("d=d+d")
x("console.log(d)")-
JavaScript / Говнокод #27251
−1
На каком языке это получится сделать короче?
Запостил:
prefix-not,
12 Февраля 2021
Follow us!
Джаваскриптц официально соснул, что и требовалось доказать в очередной раз.
Wir werden angegriffen! Alle posten besetzen. Ich wederchole: wir werden angegriffen!
Wir werden angegriffen! Alle posten besetzen. Ich wederchole: wir werden angegriffen!
bormand, TOPT, JloJle4ka, 3oJloTou_xyu, Fike, defecate-plus-plus, MAKAKA, MapTblwKa, guest6, и некоторым другим, чьи имена я не вспомню, т.к. там много циферок, а память у меня плохая.
Можно ещё короче по убирать ретюрны и функции - но мне лень.
фу
извини, мне мама запрещает трогать eval (разве что в tcl можно, кстати на нем так примерно и будет)
По сути я и на кресты могу переписать:
отлично работает
Во-первых не быстро, во-вторых не безопасно. Это, в общем, мнение любого нормального программиста
Уменьшая количество макак ты уменьшаешь потребность в бонанах.
Как программист, я разумеется считаю, что нода не нужна (как и JavaScript)
Но как реалист, я вынужден с ней мириться
Всмысле изкоробки? Так то gevent в питоне тоже её юзает.
libuv конечно. C рогатым динозавром
asyncio в питоне правда наверное тоже все умеет
зы: о, какой документ годны нашел
https://gist.github.com/andreybolonin/2413da76f088e2c5ab04df53f07659ea
Блин, вот кстати мне виндовая логика больше нравится, чем юниксовая. Я отправляю конкретную задачу и получаю уведомление о завершении. А не жду поступления на сокет неведомой хуйни неизвестного размера перед тем как начать читать.
К слову, boost::asio юзает "виндовую" модель (proactor) а не "юниксовую" (reactor).
Кстати, в винде еще есть оверлапнутное чтение, но оно вероятно уже никому не нужно.
Да, но её всё равно кому-то приходится делать, в худшем случае разрабу самой проги.
Банальная задачка в духе "прочитать 30 байт из сокета" на реакторе превращается в ёбаный ад и наколеночную реализацию половины проактора.
А как работает комплишен порт под копотом, кстати? берет ссылку на твой буфер, и копирует его тредами ядра?
У винды всё ядро асинхронное и на коллбеках, для него этот паттерн вообще родной.
Отправляет твой буфер низлежащему драйверу, подписывается на завершение записи, в коллбеке дёргает твой ИОЦП.
мне было интересно, как драйвер получает мой буфер. Его что, копируют целиком в память ядра? Или он ходит в мою память?
Делает себе копию маппинга (MDL) на ту же физическую память, где лежит твой буфер, насколько я помню.
спасибо, понятно.
У проактора ты идёшь читать, а потом получаешь событие "прочиталось".
Коллбеки у них на разных фазах, короче.
Ты: Привет, ОС! У меня есть восемь файлов, в какой из низ можно писнуть, и сколько?
ОС: Ждите...
ОС: Ждите...
ОС: Так, в третий файл можешь писнуть 40 байт.
Ты: спасибо, пишу....
Ты: так, записал. Надо теперь передвинуть указатель буфера на 40 байт, и дождаться следующего разрешения, чтобы писать дальше.
Проактор:
Ты: Привет, ОС! Сейчас я запишу в эти восемь файлов по гигабайту говна. Скажешь, когда реально запишется?
ОС: Ждите..
ОС: Ждите..
ОС: Третий файл записался.
Эквилибристика с буфером снимается с хрупких плеч прогарммиста
К примеру, ты ставишь контроллеру задачу на чтение с диска или USB и выдаёшь ему буфера. А по завершении он дёргает тебе прерывание.
Реакторная модель разве что во всяких ps/2 да uart осталась.
Видел тут клавиатуру, про которую было написано, что некоторые функциональные клавиши работают только при подключении по ps/2. Очень удивился
Во времена ISA это физически было не реально, без помощи DMA.
На железе очень хорошо видно почему реакт сделать проще, чем проакт.
* Железо само ничего не умело качать (было тупое, не имело DMA чипа)
* Железу не нужно было ходить в память, а только лишь отвечать на запросы, а значит сложный протокол битвы за шину(как в обычнои PCI) и адресации реализовывать не нужно (ISA проще чем PCI)
Пишут кстати, что в Solaris тоже есть аналог комплишенпортов
Действие выполняется где-то в фоне, а тебе возвращают некую хуйню, на которой ты можешь ждать завершения.
Интересно, а почему такую модель выбрали тогда?
Поди ещё с каких-нибудь далёких однозадачных времён, когда select реально обрабатывал пакеты с карточки?
Можно было бы для неблокирующего сокета в read запомнить адрес и размер буфера, вернуть какой-нибудь EPENDING и пометить сокет, чтобы последующие read'ы возвращали EBUSY. А тот код, который пробуждал блокирующие read'ы, мог бы скопировать данные в этот буфер и снять метку с сокета.
А в качестве комплишен порта ты бы мог звать select, который рассказывал бы тебе какие сокеты вышли из pending'а.
Выглядит не особо сложнее текущей реализации, имхо. И не такое навороченное по сравнению с виндовыми overlapped и iocp.
З.Ы. Буфера со стека вот нельзя будет юзать. Возможно, это было критично.
https://www.ibm.com/support/knowledgecenter/SSEPGG_10.1.0/com.ibm.db2.luw.admin.perf.doc/doc/t0054518.html
но прыщам не дано
a select system call that allows device polling. Там речь правда про терминал, как чуть ли не про единственное устройство (книжка описывает BSD середины 80х).
Так что не удивлюс, если select() читал прямо из железного буфера устройства (файла в /dev).
Устройства наверное открывались эксклюзивно
или нет: в прыщах толкучка большая. Накотнибють в какуюнить netbsd
vs
PHP должен быть в помойке, а не на сервере
когда наплыв на сайт закончится (ну там распродажа пройдет), ксеон можно будет продать
let x=(d,s)=>{f>=d.length?0:s+console.log(d) +x(d,f++)};
letter: I letter: e letter: a letter: s letter: e letter: letter: I letter: i letter: k letter: e letter: ! letter:
Даже inputa нет
Б ееееее
let d="please like! "
let f=0
let x=(d,s)=>{f>=d.length?0:s+console.log(d) +x(d,f++)};
x(d,f++)
D = "please, dislike!"
JOIN{$channel}
on NICK{HALT};
x = -> (v) { D.each_char { |c| v.call c } }
~x.call (->(c) { puts "letter: #{c}" })
let d="please like! "
let x=(s,c)=>{for(let f=0;f<d.length;f++){console.log(d)}}
x(d)