Где {{ pis }}
Альтруизм в программировании |
Привет, Гость! Войдите или зарегистрируйтесь.
Вы здесь » Альтруизм в программировании » "Испражнения" мозга » Кодировка
Ну то есть, всё-равно, сначала должны быть какие-то определённые кирпичики, из которых складывается здание.
Ведь кирпич - это что?
- определённый материал (кирпич из глины или силикатный кирпич, шамотный - для печей ... и. т.п.)
- определённый размер
Зная эти свойства и параметры кирпича, далее проектируют, расчитывают и строят здание ...
Так я не навязываю, а, так сказать для информации ...
Да-да, я понял и согласился. Тем более, когда инфа уже в тексте - ей легче и оперировать, давая лишь ссылочку на прочтение. Кстати, у flamehowk тоже много рациональных зёрен, на которые можно и опереться, продвигая идею дальше... ))) Моя беда ещё и в том, что я не только всё ещё не научился программировать, но и быть лидером идеи - также не умею. Всё время жду некоего "вождя", который обладает жилкой "внедренчества"... )))
Думал над тем, что Вы сказали про точки ...
Надумал вот что ...
Точка ... переменная или объект.
Вертикальная черта ... значение переменной.
Стрелка влево ... присвоение.
Из этого набора можно составить выражение: точка-стрелка влево-вертикальная черта, которое будет обозначать графическое представление: объявление переменной и присваивание ей значения.
Плюс - сложение.
Очень жду Вашего мнения по этому поводу, а пока разбираюсь с SVG...
Точка ... переменная или объект.
- Оно бы всё хорошо и если бы не было уже существующих стандартов, на том бы и порешили, создав с нуля некую "исключительно правильную", единую и всеобъемлющую глифику, но...
Наше "новое" должно коренным образом отличаться от уже существующих стандартов, дабы не путать внешний вид написанного и нарисованного "стандартным путём" - от придуманного нами и предназначенного исключительно для программирования "образа написания".
[html]<style>p{padding: 2px; background-color:#cff;}</style>
<p>Чтобы отпала сама необходимость использования спец-знаков для отделения спец-скрипта от обычного текста и обычных картинок. <br>
Чтобы фрагменты текста при плавном (анимированном) svg-масштабировании не прыгали со строки на строку, а также плавно, как и другие элементы svg меняли свой размер. <br>
Чтобы и человек и интерпретатор поняли, что это - <a href="https://habr.com/post/101007/">программный код и не что иное.</a></p>
<p>Например, в svg-формате есть ещё мало освоенная <a href="https://codepen.io/warsan/pen/ZRQwve">"графо-текстовая"</a> ниша, имеющая особенности, отличающие её от написания обычного текста в обычном редакторе. Вот её и желательно изучить и дополнить, чтобы использовать в продвижении дальнейших новинок для программирования. Например:</p>
<box style="display: inline-block; width:40%"><p>Желаю увидеть масштабирование текста вместе с рисунком.</p>
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" width="200" height="200" viewBox="0 0 200 200" style="overflow: visible;">
<!-- Материализация якорей -->
<symbol id="penta" width="200" height="200" viewBox="0 0 200 200" >
<polygon id="star" points="100,0 40,180 195,70 5,70 160,180"
style="cursor: pointer; fill-rule: nonzero; fill: #bbaa00; stroke: none; stroke-width: 1px;" /><path d="M40, 2 L40,72
M10,20 L60,20
M10,40 L60,40
M10,60 L60,60" stroke="grey" />
<!-- Якоря в действии -->
<text text-anchor="start" x="40" y="20" font-size="15">Верх</text>
<text text-anchor="middle" x="40" y="40" font-size="15">Центр</text>
<text text-anchor="end" x="40" y="60" font-size="15">Низ</text>
</symbol>
<text x="110" y="10" font-size="20">Клик по звезде</text>
<use xlink:href="#penta" x="0" y="10" width="200" height="200">
<animate attributeType="xml" attributeName = "viewBox" xlink:href="#penta"
begin = "star.click" dur = "5s"
values = "0 0 200 200;-900 -900 2000 2000;0 0 200 200"
fill = "freeze" repeatCount="1"/>
</use>
</svg>
</box>
<box style="display: inline-block;" >
<p>Теперь я хочу увидеть, как уменьшается в размерах наш скрипт: (жмём на кнопки)</p>
<svg viewBox="0 0 200 200" width="200" height="200" xmlns="http://www.w3.org/2000/svg" version="1.1" style="overflow: visible;">
<style>
text{font: 20px Verdana, Helvetica, Arial, sans-serif;}
tspan{fill: red; font-weight: bold}
.txt {visibility: visible;}
#влё, #улё {cursor: pointer;}
</style>
<symbol id="текст" x="0" y="0" width="300" height="40" viewBox="0 0 300 200" >
<rect id="txt" x="0" y="-10" width="300" height="200" fill="#ace"/>
<text x="10" y="-20" >Здесь будет <tspan>ваш скрипт</tspan>:</text>
<text x="10" y="10" style="transform: skewX(-30deg);">тело скрипта</text>
<text x="10" y="30" style="transform: matrix(1, 0, -.5, 1, 10, 0);";>тело скрипта</text>
</symbol><symbol id="влё" >
<rect id="влё" x="0" y="0" width="100" height="40" fill="#5c2"/>
<text id="влё" x="20" y="20">влёт</text>
</symbol>
<symbol id="улё">
<rect id="улё" x="0" y="0" width="100" height="40" fill="#c52"/>
<text id="улё" x="20" y="20">улёт</text>
</symbol>
<use xlink:href="#текст" x="0" y="0" width="200" height="200"></use>
<use xlink:href="#влё" x="0" y="160" width="200" height="200"></use>
<animate xlink:href="#текст" attributeType="XML" attributeName="viewBox"
from="0 0 3000 3000" to="0 0 300 200" dur="0.8s"
begin="влё.click" fill="freeze" />
<use xlink:href="#улё" x="100" y="160" width="200" height="200"></use>
<animate xlink:href="#текст" attributeType="XML" attributeName="viewBox"
from="0 0 300 200" to="0 0 3000 3000" dur="0.8s"
begin="улё.click" fill="freeze" />
</svg> <p>- В "улётном" состоянии строим из скриптов драконовские "последовательности" и "параллельности", <br>а во "влётном" состоянии - редактируем каждый из скриптов-коробочек... </p>
</box>[/html]
[html]
<iframe width="100%" height="600" src="https://s.codepen.io/warsan/debug/GGOxjb/VJkxxVGGEqvk" allowfullscreen="allowfullscreen" allowpaymentrequest frameborder="0"></iframe>
[/html]
К сожалению еще всю переписку не перечитал, но УЖО имею наглость выступить адвокатом дь... программистов.
Это по поводу буковок и в том числе текстового языка описания аппаратуры.
Сначала, как водится - оправдание. Основные языки программирования, на которых до сих пор держится весь мир были созданы еще в те времена, когда не только не существовало графических интерфейсов, но даже мышек не было. А именно:
"Си (англ. C) — компилируемый статически типизированный язык программирования общего назначения, разработанный в 1969—1973 годах сотрудником Bell Labs Деннисом Ритчи как развитие языка Би."
И...
"Первым компьютером, в набор которого включалась мышь, был мини-компьютер Xerox 8010 Star Information System (англ.), представленный в 1981 году. Мышь фирмы Xerox имела три кнопки и стоила 400 долларов США, что соответствует почти 1000 долларов в ценах 2012 года с учётом инфляции."
Хотя...
"9 декабря 1968 года компьютерная мышь была представлена на показе интерактивных устройств в Калифорнии[1]. Патент на этот гаджет получил Дуглас Энгельбарт в 1970 году."
Так вот - так исторически сложилось, что когда только стали появляться все условия для появления графических интерфейсов, текстовое программирование УЖЕ сложилось как явление и было очень широко распространено.
Но, если оставить оправдания и перейти к объяснению, то заковыка кроется на самом деле не в том, что с помощью текста удобнее программировать, нежели путем создания графических блок-схем (как пример). Заковыка кроется в том, что ИМЕННО с помощью текстов удобнее всего хранить ЛЮБУЮ логически связанную информацию.
Вот, к примеру, графическое изображение NAND ячейки, состоящей из 4 транзисторов (затворов):
В принципе этот рисунок можно сжать до 10 кБ на пределе качества, если учесть, что его еще нужно разделить на слои и добавить несколько слоев проводников, которые идут над комплиментарными элементами. Теперь давайте посчитаем:
10 кБ / 4 Тр = 2.5 кБ/Тр
На современных чипах при техпроцессе в 7 нм на площади 1 мм может размещаться до 100 млн транзисторов. Умножаем:
2.5 кБ * 100 МТр = 250 ГБ.
Теперь учтем, что минимальный современный чип, это порядка 3х4 мм, что равно 12 мм.кв. площади - получаем, что минимальное затрачиваемое место на диске для хранения графического представления одного чипа = 250 ГБ * 12 = 3 ТэраБайта!!!
Вот...
А теперь давайте прикинем, что получается у нас с текстом.
Вот тот же NAND в Verilog включая описание присоединенных контактов:
module NAND
(
input wire Din,
input wire Clk,
output wire Out
);
assign Out = ~(Din & Clk);
endmodule
Всего вместе - это 106 знаков, включая пробелы. То есть это 106 Байт всего.
Множим:
106 Б * 100 МТр * 12 = 127.2 ГБ
Как Вы можете понять - такой файл приблизительно равноценен стандартному современному фильму в хорошем качестве. Передать его на производство - никаких проблем не составляет. А вот с файлом в 3 Тэра Байта такие проблемы возникли бы даже просто при банальном хранении на диске, не то что - с передачей.
И это еще не все.
Главное здесь в том, что когда Вам придется сделать в файле какие-то изменения или исправить ошибку, то графический файл придется перерисовывать ВЕСЬ С НУЛЯ!!! А вот в текстовый файл внести исправления - дело двух минут. Потом специальная программа уже на заводе из этого текстового файла СИНТЕЗИРУЕТ все необходимые изображения для каждого слоя будущего процесса литографии - и дело в шляпе.
Так то вот, Господа.
Так что как тут не крути, но как минимум для хранения информации, особенно с учетом необходимости ее распознавания, анализа, трансляции в другие форматы и так далее - тексты просто НЕ ЗАМЕНИМЫ!
Хотя, сам процесс программирования действительно давным-давно уже нужно было перевести на ВИЗУАЛЬНЫЙ.
Надеюсь кому-то было полезно.
По поводу Триггеров.
Триггер - это не ключ. Триггер - это память. А роль ключа играют различные логические элементы - AND например... В определенных ситуациях роль ключа играет целое сложное устройство, состоящее из множества логических элементов, например "сравнитель" чисел.
Про процессоры.
На самом деле никаких "всех видов" процессоров не существует. Существует всего пару распространенных архитектур, типа x86 и ARM, под которые давным давно написаны все библиотеки и компиляторы еще на С, а современные языки программирования, особенно скриптовые - просто используют эти библиотеки, являясь по сути - надстройками второго и третьего уровня.
Архитектуры обоих типов на самом деле вполне себе открыты и хорошо известны. Так что под них можно писать хоть в машинных кодах, если пожелаете.
Что касается нового процессора, то его не так сложно разработать, как изготовить. По нынешним временам это обойдется в сотню-другую тысяч долларов. Есть, конечно, еще как вариант прототипирование на ПЛИС (FPGA), но это скорее так - для отработки отдельных узлов и блоков, либо для отработки Управляющих Программ под него...
В общем - первым делом, первым делом самолеты...
Нужно инвестирование найти, чтобы двигаться дальше, а за идеями дело не постоит.
Куда Деда пропал? Я его ужо выдергиваю, выдергиваю... а он все никак в гости не идет.
И вообще, ВЫ тут все много интересных тем затронули, по поводу которых мне уже давно есть что сказать. Но все требует дальнейших усилий в разработке.
Отредактировано flamehowk (05-20-2019 01:47:29)
По поводу Триггеров.
- Да, можно и так, хотя и выключатель на стене - тоже память.
(- memory, или "мем", поскольку конструктивно он тоже предназначен "запоминать" своё состояние, как и шаговый искатель, как и кнопка у шариковой ручки и т. д...)))
Отнёс к разряду "ключей" для классификации, чтобы уйти от более длинного и иностранного слова "триггер".
Причины: слово "ключ" - короткое, но достаточно ёмкое, чтобы под него подпадали все дискретные "мем-понятия".
(вспомним хотя бы режим D в усилителях, или - "ключевой режим" работы транзистора, как "дискретный" режим, на котором и зиждется вся эта "компо-кухня")))
Про процессоры.
- И да, всё верно. Всюду деньги. Да и совершенствовать процики надо бы кодеру-электронщику, а не простому программисту.
Куда Деда пропал?
Думаю, Деда пропал не просто так. Если он человек дела - ему достаточно скучно в нашем "сонном царстве". Вот изобретёт что-нибудь великое - и придёт...
(и скажет: "Берите, люди, - пользуйтесь!")))
Все-таки по поводу триггеров - не согласен.
Ключ - это ключ, а память - это память. Если мы память будем называть "ключом", то как же мы тогда будем называть "ключи"? Память запоминает состояния и не обязательно 2, их может быть намного больше. Она может удерживать эти состояния длительное время и по-этому никак не работает как ключ. А ключ, например в транзисторе (затвор/база) - работает постоянно. Он либо запирает канал, либо его открывает. По сути сток/исток транзистора можно представить "замком", а затвор - "ключом". Если мы хотим, чтобы в качестве затвора/базы работал триггер, который память, то он будет всего-лишь промежуточным звеном, через которое будет подаваться сигнал на КЛЮЧ транзистора. То бишь все-равно ключом не будет.
Таким образом слово "ключ" все-таки лучше применять для затвора транзистора или для той части комплексного устройства, которая отвечает за управление этим устройством, например управляющие сигналы в мультиплексоре. В худшем случае переносить этот термин на весь транзистор, но никак не на память, которая состоит из множества таких транзисторов, в которых некоторые выходы (замки) играют роль "ключей" для других входов (замков), что приводит к квантовой запутанности - кто кому кум, а кто кому сват и в результате чего сущностное явление "ключа" как такового растворяется в сферической парадигме микрокосмоса.
А триггер (защелка) - это сугубо понятие памятное для нашего сердца. Моя флешка, например, содержит 100 миллиардов триггеров (ячеек памяти) и все они могут годами хранить заданный набор информации, при этом эта информация ничем не управляет, и ничего не открывает - это просто художественный фильм, например. Можем ли мы сохранив здравый смысл говорить, что моя флешка выполняет роль 100 миллиардов ключей?
В общем: ключ - это активный управляющий элемент. Память - это пассивный, управляемый ключами, хранящий или пустующий элемент. Не может быть кучер одновременно и каретой.
Так что предлагаю триггеры обозвать "памятью" да и все. Ячейка памяти. Если хотите "лукошко сВЕДений"... 
Страшное дело...
Сегодня мне ответили из Байкал Электроникс. Предложили ряд вакансий. А я непростительно внаглую предложил им идею реализации своего процессора, суть которого Вы так быстро раскусили. Вот бы они согласились...
Хотя, лучше себя особо надеждами не тешить. Но вроде как новость все-таки - так что написал.
(как я утверждался в своих "предпочтениях", прежде чем...)
[html]<a href="https://www.babla.ru/%D0%B0%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9-%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9/trigger">Перевод слова «trigger»</a>
<br><a href="https://wooordhunt.ru/word/trigger">Тоже неплохой перевод</a>
<br><a href="https://context.reverso.net/%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4/%D0%B0%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9-%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9/trigger">Ещё один перевод</a>
<br><a href="https://chto-eto-takoe.ru/trigger">Триггер — что это такое?</a>
[/html](о "петлях гистерезиса" упоминал тоже)
Страшное дело...
- Ну а чё, а вдруг получится?
Так как изначально триггер рассматривался как электронное устройство, а не как значение английского слова, которым это устройство было названо, то, думаю, было бы корректнее рассматривать суть устройства и его функциональное назначение. А об этом здесь есть все необходимое (практически исчерпывающий материал):
Триггер
Отредактировано flamehowk (05-20-2019 21:37:28)
Ну что, на работу они меня готовы рассмотреть даже без высшего образования, попросили только резюме написать, а вот насчет разработки инновационных процессоров - пока глухо, сказали - денег маловато.
Ну что, на работу они меня готовы рассмотреть даже без высшего образования, попросили только резюме написать
- Считаю, что это уже хорошо. (и поздравляю с "признанием нужности")))
Насчёт Триггер (читаю:)
По характеру действия триггеры относятся к импульсным устройствам — их активные элементы работают в ключевом режиме, а смена состояний длится очень короткое время.
Элементы триггера соединены так, что их состояния являются противоположными и взаимоудерживаемыми, поскольку:
памятью для элемента Q1 является (им же и удерживаемое) ключевое состояние элемента Q2
памятью для элемента Q2 является (им же и удерживаемое) ключевое состояние элемента Q1
В любом случае роль "памяти" здесь выполняет "удерживаемое ключевое состояние противоположного ему элемента".
Да, ну все верно, ведь в основе триггера лежат транзисторы - каждый из которых "работает в режиме ключа".
Что же касается...
памятью для элемента Q1 является ключевое состояние элемента Q2
памятью для элемента Q2 является ключевое состояние элемента Q1
То все не совсем так, как Вы думаете. На самом деле в триггерах нет элементов, которые выполняют роль "памяти" друг для друга. Вся хитрость в том, что там есть ДВА контура, имеющих смежные цепи по входам сигнала, но раздельные цепи по выходам. При переключении триггеров просто замыкаются разные контуры - вот и все. Что-то вроде восьмерки. В первом состоянии замкнут верхний круг и по нему бегает ток, и от этого верхнего круга есть отвод, который выдает результат "высокое напряжение". На нижнем контуре в этот момент бегает "низкое напряжение". И наоборот. Когда триггер переключается - замкнут нижний контур и по нему бегает "высокое напряжение", а верхний в этот момент ганяет "низкое". Соответственно в этом случае высокое напряжение будет на отводе, который идет от нижнего контура.
Если сильно захотите, я поставлю Джаву, врублю Логисим и сделаю на нем демонстрацию - как там все происходит. Щас не могу, я то я как раз только систему переустановил, еще не все стоит, а кажный день на работу + еще по вечерам делаю тестовое задание по поводу одного трудоустройства (это не про Байкал).
Если интересно, можете посмотреть мое кратенькое резюме, которое я им сварганил, я закину в "общую" папку...
Кстати - что там по Cup-у? Есть замечания/предложения/суровая критика?
Варлам Ерофеич, не сочтите за наглость, но решил у Вас спросить - не будете ли Вы так любезны сделать маленькое, но доброе дело? Мне нужна простенькая анимашка в SVG формате для моего видео, которое я запланировал делать. Конечно, я могу ее и в 3D заварганить, но это будет долго, а у меня щас лишнего времени совсем нету. Самому же делать - это нужно сначала разобраться в этих редакторах и вообще в сути дела, а это тоже время. А Вы, я смотрю, просто обожаете делать всякие такие вещи. Не могли бы Вы потратить немного времени и сделать эту штуковину?
Со своей стороны могу Вас уверить, что дело я делаю абсолютно альтруистичное и весьма полезное для мировоззренческого развития человечества, так что Ваши труды не пропадут за даром.
Если согласитесь, я объясню более подробно - что требуется. Ну и, естественно, ролик как выложу тоже дам ссылку - посмотрите на какие нужды пошли Ваши "мультики".
- Зачем его оборачивать в скрипт, ведь это уже анимированный svg-файл, - И вот он уже, под спойлером... (жмём кнопочки и радуемся переключениям)))
[html]<iframe name="pen" src="https://upload.wikimedia.org/wikipedia/commons/4/49/Transistor_Bistable_interactive_animated-ru.svg" width="100%" height="680vh" align="center" frameborder="0"></iframe>[/html]
Правда здесь я его фреймом пустил, но это не беда, его можно и скачать... (если появится необходимость)))
- И да, поэтому я слово "память" и заковычил, плюс к этому решил подредактировать коммент, добавив фразу (им же и удерживаемое)...
По документации cup - прочёл, написано очень доходчиво, однако я ещё присмотрюсь к некоторым мелочам и непременно радирую об этом. )))
> ...маленькое, но доброе дело?
- Да, я весь внимание и если дело действительно маленькое - нет проблем!..
(резюме тоже интересное, написано с юмором, - ценю)))
Оно как бы и "да", но это не совсем тот триггер. Сейчас то весь кремний работает исключительно на полевых транзисторах, да и в качестве памяти используются триггеры более сложной конструкции... Я щас покажу.
Смотрите на рисунки. Слева - это в транзисторном виде, а справа - в формате логических элементов. На левых рисунках тоже присутствуют логические элементы, но это условность, требуемая для правильно работоспособности схемы, чтобы не загромождать ее транзисторами. По сути мы видим два инвертора из которых выполнена предельно простая ячейка памяти. Справа же имеем полноценный SR-trigger на соответствующих логических элементах.
Как можно видеть, при переключении триггера замыкаются два противоположных контура, а сигнал на выход снимается с одного из них.
По поводу мультипликации - щас сварганим.
Отредактировано flamehowk (05-24-2019 20:37:09)
Итак, суть дела такова:
Вот собрана система из двух цилиндров, соединенных трубой. В цилиндрах два поршня, соединенных весами.
Нужно создать первую SVG-шку так, чтобы в цилиндрах над поршнями была жидкость (просто эффект заполнения одним цветом). В левом жидкость красного цвета, а в правом - зеленого. Поршни должны двигаться вверх-вниз. Естественно, если правый поднимается, то зеленой жидкости должно становиться меньше, а красной больше, при этом - красный поршень опускается. Ну и так до упора, пока в одном из цилиндров не останется жидкости совсем.
По кнопкам... Должно быть три кнопки - "правый", "левый", и "стоп". Кнопки должны быть расположены удаленно от общей картинки, чтобы их было не видно во время съемки анимации.
При нажатии на кнопку "правый" - правый поршень должен подниматься вверх и медленно ползти до упора.
При нажатии на кнопку "левый" - то же должно происходить с левым поршнем - левый вверх, а правый вниз.
Скорость движения приблизительно 5 секунд от нейтрального положения до упора. То есть, если полное движение от верха до низа - 10 секунд. Приблизительно. Главное, чтобы я успевал реагировать на движение и нажимать нужные кнопки.
При нажатии на кнопку "стоп" - анимация должна замирать в том состоянии, в котором она находится в момент нажатия.
После нажатия на "стоп" при нажатии на "правый" или "левый", анимация должна возобновляться с положения "замирание" и идти дальше в указанную сторону (в зависимости от того - что нажал - "правый" или "левый")
По первой анимашке - все.
Вторая - точно такая же, только с добавлением балансира, который должен быть жестко привязан к штанге весов:
Нужно, чтобы я мог включить программу съемки экрана, зайти в браузер на страничку нужной анимашки и поклацать ее вверх-вниз в нужном мне режиме, а это все записалось в качестве видео. Потом так же со второй. Вот, собственно и вся задача. Делать это в 3D - геморройно, думаю, что в SVG будет намного проще и живее.
Как - выполнимо?
Если да, то все файлы в png с прозначным фоном для анимации я скинул в папку "общие", а заодно залил туда фотошопский файл со слоями, где уже собрана вся конструкция...
Отредактировано flamehowk (05-24-2019 21:52:36)
Как - выполнимо?
В некоторой степени - да, выполнимо. Эффекты светотени, (блики, отражения, как от реального предмета), - уже трудней, но в более упрощенном виде - получится.
Остановка анимации в любом месте, (а также пуск с того же момента), труднее, (анимации svg отрабатывают полные циклы до их завершения), но будем пробовать тоже...
(весь цикл можно разбить на пол-циклы и четверть-циклы)
Варлам Ерофеич, а зачем игра и светотени? Я же Вам все эти картинки в png с прозрачным фоном скинул, нужно их только вставить и заанимировать...
Честно говоря, я так в общем виде почитал об этом в википедии, посмотрел что там есть какой-то скриптовый язык на базе XML и подумал, что там вообще никаких проблем нет с процессами анимации... Просто изучать его не хочу - это опять кучу времени нужно потратить, а его и так нет. А похоже выходит, что там даже вставляемые объекты не поддерживаются... В общем - ничего не понятно. Возможно это совсем не то, что мне нужно и стоит поискать что-нибудь "поумнее" этих SVG-ешек.
В общем, я тут подумал, раз в SVG не поддерживается загрузка готовых изображений и нужно их рисовать какими-то непонятными методами, то я заморочусь и сделаю все прямо в SonyVegas-е. Там нужно будет повозиться с объектами, но по крайней мере их не нужно будет рисовать.
Звыняйтэ, шо зря только Вас дергал.
По поводу Cup-а, это только разработка концепции. По сути - процесс только идет и все время что-то добавляется, изменяется... Так что можете смело набрасывать идеи и свои видения. Будем творить вместе...
даже вставляемые объекты не поддерживаются...
- Поддерживаются (частично), просто я не совсем профи и с картинками "извне" мне придётся дополнительно экспериментировать.
Да и преимущества svg-формата проявляются лишь в упрощенной (мультяшной) графике, ну а если перевести фото высокого качества в svg-формат - его размер непомерно раздуется и перегонит png...
Альтернатива - использование clipPath, то-есть картинку извне, вставляемую в "svg-трафарет".
Приветствую.
По поводу Байкаловцев - пока тишина. Отправил резюме, а от них - молчок. Так что, видимо, не на таких гениев они рассчитывали...
Придется искать себе заработки в других сферах.
Варлам Ерофеич, у Вас уже возникли какие-то предложения/возражения/идеи по Cup-у? Если что - выкладывайте...
предложения/возражения/идеи по Cup-у?
- Нет пока возражений. Документация - на высоте! Жду "первый блин", чтобы можно было опробовать наяву... )))
Ну а пока - смотрю и пробую поделки "дяденьки-араба"
PWCT не является мастером для создания приложения за 1 2 3 шага. PWCT - это язык визуального программирования общего назначения, предназначенный для начинающих и опытных программистов.
Начинающий программист может использовать PWCT для изучения таких концепций программирования, как структуры данных, структуры управления и парадигмы программирования. Опытный программист может использовать PWCT для создания любого большого и сложного программного обеспечения.
Используя PWCT, мы разработали текстовый язык программирования Compiler и Virtual Machine без написания единой строки кода, где процесс программирования выполнялся с использованием визуальных компонентов PWCT. Этот язык называется Supernova и является бесплатным открытым исходным кодом.
Многие приложения баз данных, мультимедиа, сети, AI, Simulation & Math разработаны с использованием PWCT
Вы можете увидеть / редактировать сгенерированный исходный код. PWCT поддерживает Harbor, Supernova, C, Python и C # .NET, и вы можете расширить PWCT для поддержки генерации кода на любом текстовом языке программирования.
PWCT поставляется со многими образцами, учебными пособиями и фильмами.
Одно плохо: русский язык в его редакторе выводится арабскими каракулями.
Хотя после компиляции - да, всё встаёт на свои места...
Я посмотрел... как-то это все больше на Дельфи похоже. Отдаленно, конечно, но направление ближе к этому, чем к реально визуальному языку программирования.
По ходу пока круче Дракона реально ничего со строгим алгоритмическим уклоном нету...
Ну да Вам на пенсии все-равно чем душу развлекать, так что - веселитесь. А я покамест пытаюсь решить свои проблемы с трудоустройством.
Вы здесь » Альтруизм в программировании » "Испражнения" мозга » Кодировка
