Metaprog: универсальная графическая среда программирования [в разработке] часть 2

У  нас  была  своя  собственная
телеконференция в  Интернете  --  comp.os.linux, выросшая из  пепла нашей  с
Эндрю Таненбаумом перепалки. И она привлекала орды участников. В  те времена
Internet Cabal (группа администраторов некоторых узлов Интернета) ежемесячно
подводила неофициальную  статистику:  сколько  человек  участвует  в  каждой
конференции. Данные  были не очень  точные,  но они  лучше всего  говорили о
популярности твоего сайта --  в данном  случае, сколько людей интересовалось
Linux.  Неизменным  лидером  среди телеконференций  была alt.  sex. (Я-то ей
особенно  не интересовался.  Хотя и сходил туда пару раз, чтобы  посмотреть,
из-за чего подняли такой шум. Но вообще я был типичным  фригидным ботаником,
которому  гораздо интересней  играть  в процессор  с  плавающей  точкой, чем
следить за новостями  с  сексуального фронта:  о свеженайденных позициях при
половом акте, отчетах о крутых любовных играх  или о  чем там еще говорят на
alt. sex.)
     С  помощью   ежемесячной   статистики  Cabal  легко   было  следить  за
популярностью  comp.os.linux.  Можете не  сомневаться  --  так  я  и  делал.
(Некоторые считают меня чуть ли не народным героем, но я  никогда не был тем
бескорыстным,  самоотверженным  компьютерным  фанатом,  каким меня  пытается
представить  падкая  на  мифы пресса.)  К осени  1992 года  в  нашем  форуме
участвовали десятки тысяч людей. Все эти  люди  следили  за событиями вокруг
Linux, но  не все из них  пользовались самой операционной  системой.  Каждый
месяц  в  момент   подведения  итогов  выпускался  список  из  сорока  самых
популярных телеконференций. Если твой форум не входил в эти  сорок, то о его
популярности можно было узнать из полного отчета,  который распространялся в
специальной  служебной  конференции.  Мне  обычно  приходилось обращаться  к
полному отчету.
     Однако форум Linux неуклонно двигался вверх. В какой-то момент он вошел
в  первые сорок, и  я был  счастлив. Это было круто. Помню, я тогда  написал
довольно злорадное  сообщение в comp.os.linux, в  котором перечислял форумы,
посвященные разным ОС,  включая Minix,  и  говорил: "Смотрите, мы популярнее
Windows!" (Учтите, что в то время любители Windows еще не освоили Интернет.)
Где-то  в  1993-м  мы  вошли в  первую  пятерку.  В  ту  ночь  я  лег  спать
преисполненный самодовольства, в экстазе от того,  что Linux по популярности
почти догнала секс.

public async void handle(SocketConnection connection) {
	var socket = connection.get_socket();
	
	// Шлем клиенту данные
	socket.send((uint8[])"Hello World!".to_utf8());
	
	// Закрываем соединение (не сокет), что бы 
	// браузер корректно отобразил данные!
	socket.shutdown(true, true);
}

public static int main(string[] args) {	
	try {
		var loop = new MainLoop();
		var service = new SocketService();
		
		service.add_inet_port(8080, null);
		
		// Делаем g_signal_connect на подключение!
		service.incoming.connect((connection, source) => {
			handle.begin(connection);
			return false;
		});
	
		service.start();
		
		// Запускаем event-loop!
		loop.run();
	} catch(Error e) {
		print("Error: %s\n", e.message);
	}
	
	return 0;
}

Осенью  1990  года  начался первый учебный  год,  когда в  Университете
Хельсинки  заработала  Unix.  Эта  мощная  операционная  система родилась  в
исследовательском центре Bell Labs компании  AT&T в конце 60-х годов, но
выросла  в других местах.  Когда  я был  на первом  курсе, у нас стоял VAX с
операционной системой VMS. Она была ужасна, про нее никто не сказал бы: "Вот
бы и мне домой такую". Она вызывала иную реакцию: "Как вы умудрились сделать
такое!" Ею  было трудно пользоваться. В  ней  было мало инструментария. С ее
помощью было  сложно выходить в  Интернет, который  работал  под Unix.  Даже
узнать, насколько велик файл, -- и то было  непросто. Надо признать, что для
некоторых  приложений  -- например, для  баз данных -- VMS была очень хорошо
приспособлена. Но она была не из тех операционок, которые вызывают восторг.
     В университете наконец поняли, что с ней  пора кончать.  В научном мире
многие  тогда  увлеклись  Unix, поэтому  университет  приобрел  MicroVAX, на
котором  работала  Ultrix --  вариант  Unix,  созданный корпорацией  Digital
Equipment. Они захотели примериться к Unix.
     Мне не  терпелось поработать с Unix, чтобы  поэкспериментировать с тем,
что я узнал из книги  Таненбаума.  Сколько всего я мог бы сделать, если бы у
меня была 386-я машина!  Однако взять 18 тысяч  финских  марок на ее покупку
мне было негде. Я знал, что с началом учебного семестра я смогу использовать
свой  Sinclair QL для выхода на  новый университетский Unix-компьютер до тех
пор,  пока не  куплю себе  PC -- машину, на которой  можно будет  установить
Unix.
     Поэтому  тем   летом   я   делал   две   вещи:  бездельничал   и  читал
"Проектирование и реализацию операционных  систем". Эти 719 страниц в мягком
красном переплете, можно сказать, поселились у меня в постели.
     Университет  Хельсинки размахнулся на  16-пользовательскую лицензию для
MicroVAX.  Это  значило, что  прием  на курс  "Си и  Unix" ограничивался  32
студентами --  видимо, предполагалось, что 16 человек будут использовать  ее
днем и 16 -- вечером. Преподавателю, как и всем нам, Unix была в новинку. Он
сразу же об этом сказал, так что проблем не было. Но он обычно знал материал
своего курса на одну главу вперед, а студенты иногда уходили вперед главы на
три. Это стало своего рода игрой: студенты пытались подловить преподавателя,
задавая ему вопросы по будущему материалу, чтобы выяснить, читал  он его или
нет.
     Все мы были  младенцами в дебрях  Unix;  курс создавался по ходу нашего
обучения. Однако из него было ясно, что за Unix стоит своя особая философия.
Это становилось понятно после первого  же часа  занятий. В  остальное  время
объяснялись подробности.
     Unix характерна тем, что она утверждает некоторые базовые ценности. Это
цельная и красивая операционная система. Она избегает особых случаев. В Unix
есть понятие процесса: процесс -- это  все,  что  что-нибудь делает. Простой
пример. В Unix команда оболочки, которую  вводят, чтобы  войти в систему, не
встроена в операционку, как в DOS. Это просто задание. Ничем не отличающееся
от остальных. Просто это задание читает с  клавиатуры  и пишет на монитор. В
Unix все, что что-то делает, -- процесс. А еще там есть файлы.
     Простота структуры Unix всегда поражала меня, как и  большинство  людей
(ну  по  крайней  мере  -- нас, хакеров). Почти  все,  что делается  в Unix,
выполняется  с  помощью  шести  базовых  операций  (называемых   "системными
вызовами", потому что они представляют из себя вызовы системы для выполнения
тех или иных действий), А уж из этих шести  базовых  вызовов можно построить
почти все на свете.
     Одной из фундаментальных операций Unix  является  "операция  порождения
(fork)".  Выполняя "fork", процесс создает свою точную копию. Таким  образом
вы получаете две идентичные копии. Порожденная  копия чаще  всего  выполняет
другой  процесс  --  заменяет  себя  новой  программой. Это  вторая  базовая
операция. Оставшиеся четыре вызова -- open (открыть), close  (закрыть), read
(читать)  и write (писать) --  предназначены для доступа к файлам. Эти шесть
системных вызовов представляют  собой простые операции, из которых и состоит
Unix.
     Конечно,  есть еще куча других системных вызовов, которые  осуществляют
детализацию. Но если  вы  поняли шесть базовых -- вы поняли Unix. Потому что
одна  из  прелестей  Unix в  том, что  для создания сложных  вещей  не нужны
сложные интерфейсы. Любого уровня сложности можно достичь за  счет сочетания
простых  вещей.  Для  решения  сложной  проблемы нужно  лишь  создать  связи
("каналы" в терминологии Unix) между простыми процессами.
     Уродство,  когда  для  любого  действия  у  системы  есть   специальный
интерфейс. В Unix -- все наоборот. Она предоставляет строительные блоки,  из
которых можно создать что угодно. Вот что такое стройная архитектура.
     То  же  самое  с  языками. В английском 26  букв, и с  их помощью можно
написать  все.  А  в китайском для  каждой мыслимой  вещи --  своя  буква. В
китайском  вы сразу же получаете в свое  распоряжение  сложные вещи, которые
можно комбинировать ограниченным образом.  Это больше напоминает подход VMS:
есть   множество  сложных   вещей   с  интересным  смыслом,  которые   можно
использовать только одним способом. И в Windows то же самое.
     В Unix, напротив, основная идея: "Чем меньше, тем красивее". Здесь есть
небольшой  набор простых  базовых  строительных  блоков,  из  которых  можно
строить бесконечно сложные конструкции.
     Именно  так, кстати, обстоит  дело  и в физике. Эксперименты  позволяют
открыть фундаментальные законы, которые,  как предполагается, крайне просты.
Сложность  мира  возникает  за  счет  множества  удивительных  взаимосвязей,
которые можно  вывести из этих простых законов, а не из внутренней сложности
самих законов.
     Простота  Unix  не возникла  сама по  себе.  Unix  со  своей концепцией
простых строительных  блоков была  кропотливо разработана  Деннисом  Ричи  и
Кеном Томпсоном в Bell Labs  компании  AT&T.  Простоту вовсе не  следует
отождествлять с легкостью. Простота требует проектирования и хорошего вкуса.
     Если  вернуться к  примеру  с  языками, то  пиктографическое  письмо --
например,  египетские или  китайские иероглифы  -- обычно древнее  и кажется
"примитивнее", а  подход, использующий строительные  блоки,  требует гораздо
более абстрактного мышления. Точно так же и простоту Unix не следует  путать
с отсутствием изощренности -- совсем наоборот.

win = Window()
win.draw_triangle()

	struct Vertex {
		float position[3];
		float color[3];
	};

	// Vertex buffer and attributes
	struct {
		VkDeviceMemory memory;															// Handle to the device memory for this buffer
		VkBuffer buffer;																// Handle to the Vulkan buffer object that the memory is bound to
	} vertices;

	// Index buffer
	struct 
	{
		VkDeviceMemory memory;		
		VkBuffer buffer;			
		uint32_t count;
	} indices;

	// Uniform buffer block object
	struct {
		VkDeviceMemory memory;		
		VkBuffer buffer;			
		VkDescriptorBufferInfo descriptor;
} uniformBufferVS;

			// Create a host-visible buffer to copy the vertex data to (staging buffer)
			VK_CHECK_RESULT(vkCreateBuffer(device, &vertexBufferInfo, nullptr, &stagingBuffers.vertices.buffer));
			vkGetBufferMemoryRequirements(device, stagingBuffers.vertices.buffer, &memReqs);
			memAlloc.allocationSize = memReqs.size;
			// Request a host visible memory type that can be used to copy our data do
			// Also request it to be coherent, so that writes are visible to the GPU right after unmapping the buffer
			memAlloc.memoryTypeIndex = getMemoryTypeIndex(memReqs.memoryTypeBits, VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | VK_MEMORY_PROPERTY_HOST_COHERENT_BIT);
			VK_CHECK_RESULT(vkAllocateMemory(device, &memAlloc, nullptr, &stagingBuffers.vertices.memory));
			// Map and copy
			VK_CHECK_RESULT(vkMapMemory(device, stagingBuffers.vertices.memory, 0, memAlloc.allocationSize, 0, &data));
			memcpy(data, vertexBuffer.data(), vertexBufferSize);
			vkUnmapMemory(device, stagingBuffers.vertices.memory);
			VK_CHECK_RESULT(vkBindBufferMemory(device, stagingBuffers.vertices.buffer, stagingBuffers.vertices.memory, 0));

			// Create a device local buffer to which the (host local) vertex data will be copied and which will be used for rendering
			vertexBufferInfo.usage = VK_BUFFER_USAGE_VERTEX_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT;
			VK_CHECK_RESULT(vkCreateBuffer(device, &vertexBufferInfo, nullptr, &vertices.buffer));
			vkGetBufferMemoryRequirements(device, vertices.buffer, &memReqs);
			memAlloc.allocationSize = memReqs.size;
			memAlloc.memoryTypeIndex = getMemoryTypeIndex(memReqs.memoryTypeBits, VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT);
			VK_CHECK_RESULT(vkAllocateMemory(device, &memAlloc, nullptr, &vertices.memory));
			VK_CHECK_RESULT(vkBindBufferMemory(device, vertices.buffer, vertices.memory, 0));

			// Index buffer
			VkBufferCreateInfo indexbufferInfo = {};
			indexbufferInfo.sType = VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO;
			indexbufferInfo.size = indexBufferSize;
			indexbufferInfo.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT;
			// Copy index data to a buffer visible to the host (staging buffer)
			VK_CHECK_RESULT(vkCreateBuffer(device, &indexbufferInfo, nullptr, &stagingBuffers.indices.buffer));
			vkGetBufferMemoryRequirements(device, stagingBuffers.indices.buffer, &memReqs);
			memAlloc.allocationSize = memReqs.size;
			memAlloc.memoryTypeIndex = getMemoryTypeIndex(memReqs.memoryTypeBits, VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | VK_MEMORY_PROPERTY_HOST_COHERENT_BIT);
			VK_CHECK_RESULT(vkAllocateMemory(device, &memAlloc, nullptr, &stagingBuffers.indices.memory));
			VK_CHECK_RESULT(vkMapMemory(device, stagingBuffers.indices.memory, 0, indexBufferSize, 0, &data));
			memcpy(data, indexBuffer.data(), indexBufferSize);
			vkUnmapMemory(device, stagingBuffers.indices.memory);
			VK_CHECK_RESULT(vkBindBufferMemory(device, stagingBuffers.indices.buffer, stagingBuffers.indices.memory, 0));

			// Create destination buffer with device only visibility
			indexbufferInfo.usage = VK_BUFFER_USAGE_INDEX_BUFFER_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT;
			VK_CHECK_RESULT(vkCreateBuffer(device, &indexbufferInfo, nullptr, &indices.buffer));
			vkGetBufferMemoryRequirements(device, indices.buffer, &memReqs);
			memAlloc.allocationSize = memReqs.size;
			memAlloc.memoryTypeIndex = getMemoryTypeIndex(memReqs.memoryTypeBits, VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT);
			VK_CHECK_RESULT(vkAllocateMemory(device, &memAlloc, nullptr, &indices.memory));
			VK_CHECK_RESULT(vkBindBufferMemory(device, indices.buffer, indices.memory, 0));

			// Buffer copies have to be submitted to a queue, so we need a command buffer for them
			// Note: Some devices offer a dedicated transfer queue (with only the transfer bit set) that may be faster when doing lots of copies
			VkCommandBuffer copyCmd = getCommandBuffer(true);

			// Put buffer region copies into command buffer
			VkBufferCopy copyRegion = {};

			// Vertex buffer
			copyRegion.size = vertexBufferSize;
			vkCmdCopyBuffer(copyCmd, stagingBuffers.vertices.buffer, vertices.buffer, 1, &copyRegion);
			// Index buffer
			copyRegion.size = indexBufferSize;
			vkCmdCopyBuffer(copyCmd, stagingBuffers.indices.buffer, indices.buffer,	1, &copyRegion);

			// Flushing the command buffer will also submit it to the queue and uses a fence to ensure that all commands have been executed before returning
			flushCommandBuffer(copyCmd);

			// Destroy staging buffers
			// Note: Staging buffer must not be deleted before the copies have been submitted and executed
			vkDestroyBuffer(device, stagingBuffers.vertices.buffer, nullptr);
			vkFreeMemory(device, stagingBuffers.vertices.memory, nullptr);
			vkDestroyBuffer(device, stagingBuffers.indices.buffer, nullptr);
			vkFreeMemory(device, stagingBuffers.indices.memory, nullptr);
}