Энтузиасты запустили Doom с помощью типов TypeScript.
Проект запуска Doom исключительно в системе ввода TypeScript занял 12 дней по 18 часов в сутки. Разработчики провели проверку 3,5 триллиона строк текста, создали виртуальную машину WebAssembly на основе TypeScript и 177 ТБ типов TypeScript.
Ещё раз о количестве способов набрать сдачу в n рублей из заданного набора монет/купюр
Вот известная задача: «Имеется неограниченное количество монет достоинством 1, 2, 5 и 10 рублей. Определить, сколькими способами можно ими выдать сдачу в n рублей».
Я, бывший преподаватель информатики, хочу рассказать профессионалам, экспертам, знатокам и гуру о придуманной мной (если это не «изобретение велосипеда») идее решения задачи без перебора всех возможных вариантов (без четырёх вложенных циклов).
Возможно, эта идея будет полезна в других задачах.
Итак.
При n = 7 все варианты следующие:
1 + 1 + 1 + 1 + 1 + 1 + 1
1 + 1 + 1 + 1 + 1 + 2
1 + 1 + 1 + 2 + 2
1 + 2 + 2 + 2
1 + 1 + 5
2 + 5
Среди них можно выделить те, в которых минимальным слагаемым является 1. Их – 5. В оставшемся шестом варианте минимальным слагаемым является 2. Вариантов, в которых минимальным слагаемым является 5 и 10, в данном случае нет.
При n = 10 все варианты следующие (без знака +):
1111111111, 111111112, 11111122, 1111222, 112222, 111115, 11125, 1225, 22222, 55, 10,
то есть
количество вариантов с минимальным слагаемым 1 равно 8;
количество вариантов с минимальным слагаемым 2 равно 1;
количество вариантов с минимальным слагаемым 5 равно 1;
количество вариантов с минимальным слагаемым 10 равно 1.
Подумав (😊), можем сказать, что при n = 11:
· количество вариантов с минимальным слагаемым 1 будет таким же, как общее число всех вариантов для n = 10 (так как разность 11 – 10 не превышает 1);
· количество вариантов с минимальным слагаемым 2 будет равно сумме количеств с минимальными слагаемыми 2, 5 и 10 для n = 9 (так как разность 11 – 9 не превышает 2);
· количество вариантов с минимальным слагаемым 5 будет равно сумме количеств с минимальными слагаемыми 5 и 10 для n = 6 (так как разность 11 – 6 не превышает 5);
· количество вариантов с минимальным слагаемым 10 будет равно такому же количеству для n = 1 (так как разность 11 – 1 не превышает 10).
Приведённые рекуррентные зависимости применимы для всех значений n, но с некоторыми исключениями – при n = 1 количество вариантов с минимальным слагаемым 1, при n = 2 количество вариантов с минимальным слагаемым 2, при n = 5 количество вариантов с минимальным слагаемым 5 и при n = 10 количество вариантов с минимальным слагаемым 10 будет равно 1 (в перечисленных случаях соответствующие слагаемые появляются впервые).
Допустим, что максимальное значение n равно 99.
В программе, реализующей описанную идею для такого случая, можно использовать двумерный массив из 109 строк и пяти столбцов (10 начальных строк массива являются условными для рекуррентного расчёта значений при n = 1..99).
Вся программа на так называемом «школьном алгоритмическом языке» (система программирования КуМир):
алг
нач цел таб м[-9:99, 1:5], цел n, j
| Нули, в том числе в фиктивных строках
нц для n от -9 до 99
нц для j от 1 до 5
м[n, j] := 0
кц
кц
| Расчёты
нц для n от 1 до 99
если n = 1
то
м[n, 1] := 1
иначе | Рекуррентная зависимость
м[n, 1] := м[n - 1, 5]
все
если n = 2
то
м[n, 2] := 1 иначе
м[n, 2] := м[n - 2, 2] + м[n - 2, 3] + м[n - 2, 4]
все
если n = 5
то
м[n, 3] := 1
иначе
м[n, 3] := м[n - 5, 3] + м[n - 5, 4]
все
если n = 10
то
м[n, 4] := 1
иначе
м[n, 4] := м[n - 10, 4]
все
| Последний столбец
м[n, 5] := м[n, 1] + м[n, 2] + м[n, 3] + м[n, 4]
кц
| Вывод всех значений
нц для n от 1 до 99
вывод нс, n, " | ", м[n, 5]
кц
кон
Конечно, вместо массива из 109 строк можно использовать 10-строковый массив и после расчёта значений для очередной строки переписать массив, отбросив «хвостовую» строку.
Спасибо.
«Пушим байты» в сугробы: новогодняя демосцена 2025
Признанная классика демосцены — PICO-8, в арсенале которой сотни игр разной сложности. Мы же пойдем более оригинальным путем и напишем новогоднюю демку для BytePusher. Эта приставка включает 8-битный процессор, предлагает разрешение 256x256 и 8-битный цвет. Но самое интересное в ней — это OISC-архитектура ByteByeJump (BBJ).
OISC, One-Instruction Set Computer, известна гораздо меньше, чем RISC или CISC. Ее простота, очевидная из названия, привлекает немного энтузиастов, судя по странице BytePusher. Тем интересней будет сделать что-нибудь для нее с нуля.
Этим и занялся в своей статье Пётр Советов, специалист в области разработки DSL-компиляторов и старший научный сотрудник лаборатории специализированных вычислительных систем РТУ МИРЭА. Написал ассемблер на Python, разобрался с вычислениями без АЛУ и «отрисовал» классическое демо с падающим снегом. Еще и со «звездочкой» в виде сугробов и статичных цифр.
Чебурашка
Это история не про окукливание рунета, а про моего старого друга, который обратился ко мне несколько лет назад за консультацией по современным технологиям. Назовём его Чебурашкой, чтобы не палить имена, харизматичный и бессовестный, делал всё красиво, а занимался он мрачным криминалом, самое приличное - обнал.
Обратился как раз он по вопросу как упростить переводы налички, когда некий Шило и Фельдман не хотят палить транзакции и связь между собой, а суммы там должны быть не маленькие.
Погрузившись в себя, я начал обдумывать, как помочь ему в этом сложном и важном деле, да и долг перед ним поджимал (лучше не используйте инвестиции донных дельцов). Долго ли коротко, открыв в очередной раз приложение зелёного банка, я обнаружил новую функцию по снятию денег со своего счёта через авторизацию по QR коду - и тут я увидел решение своего маленького вопросика для больших денег.
Пересылать фото банкомата в секретных чатах? Это не путь настоящего обнальщика.
Схема такая: Сервер для обмена видео по RSTP + Фельдману и Шило по Android телефону, где отправителю денег предаётся видео через эмулирование камеры с камеры получателя.
После этого я набросал, как типичный стартапер, всю схему на салфетке в ресторане при отеле Континенталь и он взял время подумать. Потом я узнал, что проект отдали на аутсорс и в моих услугах не нуждаются, далее у Чебы появились проблемы с неким Эдом и больше мы не виделись.
MVP проекта (вход рубль - выход десять лет по 7 части статьи 159 УК РФ)
В одной из недавних статей узнал про сайт HighLoad.fun, было интересно решить несколько задач и забраться в лидеры. Если кто-то любит highload задачи, то зову принять участие. Общался с автором проекта HL в телеграме - отзывчивый добродушный человек, планируется версия сервера 2.0 с новыми плюшками. Может и выглядит как реклама, но моя заинтересованность чисто спортивная, я решаю такие задачи сколько себя помню, это как кроссворды для меня, а без конкуренции нет желания улучшать результат. В секции C++ конечно соревновательный дух активнее, но я пишу на C# и там результатов не так много.
Наверное, самая безумная и несбыточная моя мечта — Викикодия, хранящая не отдельные сниппеты, а хостящая суровую сетку из функционирующих проектов. Вплоть до их сборки в бинарник (придётся прикрутить онлайн-компиляцию, да).
Да, язык получается прибит гвоздями (видимо, Си). С платформами — проще, викидвижок поддерживает плашки, в которых можно перечислить совместимые платформы. Одна «статья» — одна функция и по одному .obj для каждой платформы. Название «статьи» — название функции вместе со списком аргументов. Синяя ссылка в другой статье — вызов функции (можно и не одну функцию на статью, но видеться будет только «главная»). В возможности существования глобальных переменных, правда, у меня большие сомнения — викидао в том, что для изменения одной статьи не нужно держать в голове структуру всей Википедии.
Сохранить можно только версию статьи, нормально скомпилировавшуюся. Естественно, до патрулирования она недоступна никому, кроме автора и модераторского состава, иначе количество «закладок» быстро станет астрономическим.
Кроме мощного инструмента поддержания порядка в проектах, без превращения их в классификацию животных по Борхесу, эта штука обещает (а чего б ей не обещать, всё равно ж несбыточная!) околонулевой порог вхождения в опенсорс. Связность функций множества проектов, от базовой математики до целевого функционала, и единообразная структура, в которой не надо копаться, чтобы собрать себе персональный билд со своими хотелками.
Которые, возможно,модсостав одобрит для всех.
Тестировал всякое для ATARI XL/XE и написал небольшую демку в 106 Байт.
Чтобы понимать куда именно смотреть - тут экран 48х24, то есть 1152 байта, но в ОЗУ весь экран представлен всего 48 байтами, еще 78 байт (кто захочет посчитать 48+78=126, тут просто кодом реализованы однотипные строки) для программирования видеочипа, которому объяснено, что каждая строка на экране смотрит на одну и ту же часть ОЗУ, так мы заполняем весь экран. Для получения нестандартного узора используется 8 байт и перепрограммирование таблицы символов. Рисунок изначально подбирается так чтобы формировался равномерный узор. Для плавности движения используется VSYNC, анимация реализована битовым сдвигом.
.include "atari.asm"
*= $3000
lda #48
?copy
sta screen-1, y
dey
bpl ?copy
; ldy #$00
iny
?copydl
lda #$42
sta dlist2, y
iny
lda #<screen
sta dlist2, y
iny
lda #>screen
sta dlist2, y
iny
cpy #72
bne ?copydl
lda #>font_data
sta CHBAS
lda #$23
sta SDMCTL
lda #<dlist
sta SDLSTL
lda #>dlist
sta SDLSTL+1
?main
ldx #1
?start
lda RTCLOK+2
?wait
cmp RTCLOK+2
beq ?wait
dex
bpl ?start
?ring
lda font_data, x
asl
adc #00
sta font_data, x
inx
cpx #08
bne ?ring
beq ?main
dlist
.byte $70, $70, $70
dlist2
*= dlist2+72
.byte $41, <dlist, >dlist
screen
*= $7400
font_data
.byte ~11000011
.byte ~10011001
.byte ~00100100
.byte ~01000010
.byte ~01000010
.byte ~00100100
.byte ~10011001
.byte ~11000011upd: -1 байт от @vadimr
upd: -1
Программист из Индонезии разработал небольшой шуточный проект GitHub Profile Roast. Как следует из употреблённого в разговорном оттенке слова «roast» в названии, целью сервиса является творчески и с шутками оскорбить пользователя, максимально используя для этого личные детали. Делать это сервис пытается на основе аккаунта GitHub.
Посетителю предлагается ввести имя своего аккаунта на GitHub. Затем сервис подтянет данные из GitHub и страница выплюнет несколько абзацев креативных оскорблений, умело связанных с личными данными и проектами на заданном аккаунте. К примеру, сервис может ехидно высказаться о низкой популярности профиля или попсовости выбранного стека технологий.
Сервис работает на английском и французском языках, а также на нескольких неевропейских, популярных в Юго-Восточной Азии (хинди, индонезийский, корейский, японский, китайский). Русского в этом списке нет.
Работает это всё через доступ к API компании OpenAI. Какой-либо умной защиты промпта нет. Как продемонстрировали в микроблогах, провести инъекции в промпт было относительно легко.
Из других любопытных наблюдений: сервис отказывается работать с некоторыми профилями. Среди замеченных в подобном Линус Торвальдс (имя пользователя torvalds) и часть аккаунтов компаний, к примеру, Microsoft и Google. Вместо череды колкостей сайт выдаёт вежливый отказ оскорблять этого пользователя. Возможно, это некий чёрный список, который автор сервиса заложил, чтобы сохранить механическую целостность фронтальной части своей головы.
Почему бы не сделать runtime языка С++ проще и легче? почему бы не сделать его перенос в том числе проще? Когда я задался этим вопросом, я решил, что во чтобы то ни стало, я напишу свой RT, для тех, кто пишет под слабые машины, или тех, кто пишет под bare metal среду. результат вы можете посмотреть на гитхабе: вотъ
Когда я работал, я старался максимально всё упростить, при этом сохранив юзабельность. не знаю как для других, но лично мне было важно сохранить исключения, для меня это удобно. но в С++ они жутко дорогие из-за RTTI (RunTime Type Information), и на bare metal реализуется с большим напрягом. выход прост - использовать статусы вместо типов. но чтобы оставить всем знакомый и удобный синтаксис исключений и позволить функциям возвращать что-то вместо статуса, где это везде лепят, я переделал всё на тупо макросах :>
так же я понял, что сложность моей работы и сложность переносимости этой вещицы усложнится, если прям всё с нуля пилить, поэтому просто воспользовался libc, выпилив libc++. Пришлось сделать обёртки над new и delete, но это не так уж и сложно, просто вызывать malloc/free.
Так же я невероятно сильно намучился в попытках сделать всё используя стандартный синтаксис С++. Потратил несколько часов в попытках разобраться как оторвать исключения от использования rtti, возился в флагах, писать cxa, gxx и unwind с нуля, даже лез в ассемблерный код в попытках вырезать надоеду, но по итогу сдался и просто слепил всё из макросов.
Всем добра <3
В продолжение публикации «Загрузка es‑модулей в браузерные приложения» cделал более‑менее практичное веб‑приложение с загрузкой кода из публичных ресурсов (GitHub Pages & jsDelivr).
Приложение позволяет использовать OpenAI API напрямую из браузера. В приложении задействованы следующие библиотеки:
Код приложения - здесь, описание - здесь (на англ.).
Отдельное спасибо @SuperCat911 за комменты про importmap - без них бы не получилось юзать OpenAI-библиотеку :)
Кстати, до 4-версии у OpenAI не было браузерной версии API-клиента (только для nodejs). И несмотря на то, что библиотека написана на TS, для браузера они сделали ES-модули, а не UMD-бандл.
Просто шутка.
Я уже 20 лет плохо сплю (ПТСР), и люблю засыпать под музыку/фильмы/лайв стримы/аудиокниги и пр. Но иногда оно меня будит по ночам. Решил исправить ситуацию. Написал коротенький скрипт, который постепенно сводит звук на ноль:
import re
import subprocess
from time import sleep
LOOK_FOR = re.compile(r'\[(\d+\%)\]')
def decrease_volume(percent) -> int:
info = subprocess.check_output(
['amixer', '-D', 'pulse', 'set', 'Master', f'{percent}%-'],
).decode('utf-8')
return int(LOOK_FOR.findall(info)[0][:-1])
def main() -> None:
while True:
print(f'Volume = {decrease_volume(1)}')
sleep(10.0)
if __name__ == '__main__':
main()
Ну, забавно, что постепенное затихание даже немного помогает заснуть. Я - на боковую. Всем спокойной ночи
Энтузиаст с помощью отладчика Telink RP2040 запустил Micropython на невероятно дешёвых умных часах LT716 за $3.
Устройство работает на процессоре Telink TC32 с тактовой частотой 24 МГц, имеет 512 КБ флэш-памяти и 16 КБ ОЗУ, оснащено экраном разрешением 80x160, поддерживает BLE.
Разработчики обновили плагин vscode-pets (VS Code Pets) для Visual Studio Code. Проект добавляет в редактор кода котиков, собак, уток, скрепыша и змейку (специально для программистов на Python). Миловидные зверьки бегают по окну приложения, ищут баги и создают хорошее настроение во время написания кода. Цифровые помощники могут взаимодействовать с пользователем с помощью мыши, а с помощью команды vscode-pets.throw-ball с ними можно поиграть.
В США разработчикам в экспериментальных целях платят, чтобы они программировали в режиме изменённого сознания (фактически накуренными). В Университете Мичигана проводят исследование «Накуренный во время программирования».
В рамках этого мероприятия планируется изучить влияние определенных веществ на продуктивность. За это платят $80. Для участия надо быть старше 21 года и знать Python.
Ранее исследование показало, что 59% респондентов уже кодили на работе под кайфом или в состоянии алкогольного опьянения.
Друзья! Вышел новый видос, своеобразная экранизация рубрики "сам себе экосистема", где я сам разрабатываю клиенты нужных мне приложений. Пожалуйста, оцените :)
31 июля 2020 года влогер MattKC опубликовал видеоролик, в котором попытался уместить игру в QR-коде. В результате он написал вариант «Змейки», которая занимает 2953 байта. Исполняемый файл такого размера возможно уместить в QR-коде, поскольку этот формат кодирует до 3 КиБ данных.
Эксперимент влогера не остался без внимания. Уже 3 августа свой вариант показал Брайан Каллахан. Эта «Змейка» требует всего 2024 байта. Впрочем, вариант MattKC ужимается с помощью Crinkler до 1,4 КиБ.
Дальнейшие эксперименты ушли ниже тысячи, а потом и сотни байтов. В последние месяцы развернулась борьба за каждый байт. В ноябре 2023 года удалось заменить ассемблерную инструкцию и выиграть целый байт. Ещё два байта сэкономили две недели назад за счёт замены jae и xor на adc.
Итоговый вариант — это «Змейка» на 58 байт для Microsoft DOS. Для сравнения: ничего не выполняющая программа на C gcc -Os -w -xc - <<< "main;"на 64-битном Linux займёт 15 776 Б. 58 байт — это немного даже для текстовых данных: хватит на небольшое предложение или последовательность эмодзи по типу «??❤️?????♀️??❤️???».
Конечно, в QR-коде эта игра тоже уместится. Также автор выложил онлайн-демку (управление по стрелкам клавиатуры на ПК или свайпу на мобильных устройствах).
Поскольку эта суббота является суперпятницей, держите суперпятничное: представьте себе мышку с двумя хвостами, встроенным свитчем, кнопкой переключения и разъёмом под SODIMM.
Для того, чтобы сделать Ctrl+C на одном компе, а Ctrl+V — на другом. А аппаратный буфер обмена — в мышке. Сунуть старую бучную планку «сколько не жалко» и развлекаться :)
Может, можно даже как-то сделать там секьюрный Air Gap, чтобы можно было обменяться только той информацией, которой пользователь открытым текстом приказывает обменяться. Ну, чтобы это не было шизой ради шизы. Но как именно — ХЗ.
Хотя это не обязательно — суперпятница же! Сделайте хаб «Клиника дяди Финика» для ненормального, но не только программирования :)
1 мая стартует новый формат соревнований на HighLoad.Fun, который напомнит вам о первых HighLoad CUP от Mail.Ru в 2017 и 2018 годах.Смысл соревнования написать HTTP сервер на любом языке программирования который реализует API описанный с помощью Swagger'а, запаковать в Docker контейнер и загрузить в registry платформы, где произойдёт тестирование. Чьё решение быстрее и без ошибок обработает входящий поток запросов — победит.
HighLoad.Fun некомерческий продукт, я занимаюсь этим проектом уже несколько лет. У меня нет споносоров, поэтому больших призов не будет, но должно быть весело и интересно.
Ссылка на соревнование: https://highload.fun/timed_competitions/authserver
Система автоматической унификации назначений данных (САУНД) разрабатывается для повышения внятности программирования. Идея обсуждалась ранее. Приведем эксперименты по созданию спецификации языка программирования.
def c = add(a, b, carry=0):
not a and not b =>
carry => c = [carry] else => c = []
else =>
not a => @a = [0]
not b => @b = [0]
a = [a' x]
b = [b' y]
last = (x + y + carry) % base
new_carry = (x + y + carry) // base
c = [add(a', b', new_carry), last]
def m = findmin(a):
m = nil
a =>
run enumerate(i=a.begin):
i < a.end =>
*i < *m => m = i
enumerate(i.next)
def sort(@a):
a =>
a = [x a']
i = findmin(a')
swap(@x, *i)
sort(@a')
def s = sum(a):
a =>
a = [x a']
s = x + sum(a')
else =>
s = 0
def pythagorean_table(n):
run rows(i=1): i <= n =>
run cols(j=1): j <= n =>
print(i * j)
cols(j + 1)
print("\n")
rows(i + 1) Условные конструкции обозначаются символом =>, вместо циклов - рекурсивный вызов функции-блока.
Квадратные скобки обозначают операцию создания списка либо добавления элемента к списку, аналогично MATLAB.
Символ @ используется при вызове функций, чтобы указать на возможность модификации переменной.
Символ * перед переменной обозначает операцию разыменования итератора.
Ключевое слово run используется для запуска функции-блока.
В языке отсутствуют операторы, прерывающие ход выполнения программы, такие как return, break, continue.
Некоторые могут помнить, как в комментариях под одной из своих статей на тему Unsafe в Android я писал, что занимаюсь портированием FFM API на эту платформу. Не так давно API окончательно вышло из предварительного доступа и стало полноправной частью JDK 22. Я поймал за хвост вдохновение и с утроенными силами начал писать код и придумывать как перенести непереносимое. Так начались поиски способа рантайм генерации нативного кода под любую из поддерживаемых андроидом архитектур, и он был найден! Выходом стала системная библиотека libLLVM.so, которая умеет делать всё, что мне нужно. Осталось лишь подключить её к java коду без готового линкера. После серии экспериментов и кучи кода родилось это:
На данном скриншоте видно тестовый запуск генерации простенькой функции с выводом полученного машинного кода (он парсится из выходного ELF файла). Я планирую использовать что-то подобное как часть линкера для FFM API.
В общем, работа кипит, и никакие преграды не страшны, если хорошенько постараться. В будущем надеюсь осилить написание цикла статей про нюансы разработки, с которыми пришлось столкнуться.
Если вас заинтересовала тема, за процессом можно следить на github`е проекта