pgTune - не открывается. Настройки Постгресса, сделали, размещён в системе виртуализации, как и MsSQL. Разница во времени выполнения запроса, по сравнению с MsSQL, на таблице с миллионом записей в 100 раз (2с vs 0.02с). План запроса - нормальный, индексы используется (запрос, элементраный, оптимизировать - нечего). Каким образом протестировать Постгресс, что бы можно было сказать, что он работает достаточно производительно на выделенных ресурсах или, что ресурсов не достаточно?
Разрешение лучше, ибо по 2к на каждый глаз в сумме даёт 4к и больше, что гораздо лучше впариваемых везде 1080 по вертикали.
"Руки" не нужны, прекрасно цепляются станадртыне органы управления.
Стол не нужен, я программирую лёжа в кровати с ноутом или беспроводной клавиатурой - очень удобно для тела, но не для шеи, возможность комфортно глядеь в потолок полностью разгрузить шею, и при этом иметь возможность быстро сменить положение на полусидячее или любое другое, мгновенно перенеся экран в удобное положение, это очень хорошая фишка.
Возможно, появятся массирующие проставки, давление - никуда не денется, зато появится омолаживающий и терапевтический эффект, дарю идею!
Воздействие на глаза, меня тоже очень беспокоит, пожалуй самый весомый пункт, будем ждать статистику.
На самом деле, фамильные деревья создаются не потому что хочется что-то узнать, а по той же причине, по какой разрешено иметь одну жену или мужа: наследование и переход имущества и прав. То есть это финасово-политический roadmap, при этом генетическое родство, по сути не имеет никакого значения, если доказано право. Наоборот, генетическое дерево, это попытка хакнуть эту систему, типа "незаконно рождённый сын из рода, происходящего от самого бога и людские законы ему - не указ". Вы же, делая дерево "родства" никак не поможете определить кто на что может претендовать.
А вариант: нагуляла, папа отрёкся, а настоящий отец не известен?
Женщины также имеют возможность отречься от своего ребёнка, в отличии о мужчин, не знаю, может ли при этом остаться только папа у ребёнка. В общем, я к тому, что фамильная связь и генетическая, это два разных дерева. И всяких нюансов может быть масса: хоть партогенез и не находит подтверждения у человека, зато химеризм и инцест - да.
>Ну, во-первых, «мультипрограммным агрегатом» являются не только компьютеры общего назначения.
Именно. Микроконтроллеры, где допустимы разные упрощения, это своеобразная ниша, для внедрения новой архитектуры, это мелковато.
>Только у мультиклеточной архитектурыпрограммный код может быть исполнен на любом количестве клеток и с полной реализацией параллелизма, который присутствует в коде.
Только клетка, это не ядро, заявление из разряда: все регистры процессора доступны в полном объёме и в любой момент, для вычислений без обращения к памяти, а то что их надо постоянно сохранять и восстанавливать, для использования.. То же и с клетками: что толку, что они МОГУТ быть использованы, если в этот момент, они не доступны ни для какого кода, пока весь параграф полностью не будет выполнен? Если у вас ядро состоит из 16 клеток и на на этом ядре выполняется код, который требует всего 3 клетки, от этого ни жарко не холодно, потому что код, исполняемый на соседнем ядре и никакой другой тоже, не может использовать оставшиеся 13 клеток, более того, если конкретной процедуре нужно 256 клеток для исполнения, то он будет довольствовать лишь 16тью, а остальные ядра будут простаивать. Группировка клеток по ядрам, (по четыре клетки :-) ), хоронит саму суть Мультиклеточной архитектуры
Программа может использовать любое количество из 256 клеток, если это количество не более четырёх, ну - отлично!
Да, конечно, я не правильно использовал понятие потоков, подразумевалось, исполнение одновременно нескольких программ, у каждой хотя бы 1 поток, что недальновидно было сокращено до "многопоточности".
У мультирограммности, нет задачи полностью утилизировать ресурсы, а стоит задача именно одновременной работы нескольких программ. Если такой возможности нет, то вы вынуженны будете пользоваться своеобразными коммбайнами, где в текстовом редакторе, будет и проигрыватель и часы и браузер интернета, но при этом программист будет специалистом только по текстовым редкторам, а графического редактра, там не будет и в помине, поэтому, переодически, вам придётся этот комбайн закрывать и открывать графический редактор. Поэтому путь, когда программы узкоспециализированы, но при этом вынуждены работать независимо, это был естественный эволюционный, однако он порождает проблемы с распределением ресурсов.
Пример, с 4мя функциями, это то, как мультирограммность влияет на исполнение кода, а в современном качестве, к этому ещё добавляются всякие малые ядра и динамическое изменение частоты процессора. Но если вкратце, то имея в своём распоряжении 4 ядра, некую функцию, отрабатывающую, в среднем, за одно время и массив данных, то простейший алгоритм параллельной обработки, ничем не будет отличаться от развёртки цикла, мы просто запускаем по функции на ядро и ждём, когда они все отработают, после начинаем следующую итерацию, такой себе синхронный подход. Очевидно, что при мутипрограммности, время исполнения функции на одном ядре, перестаёт быть адекватно прогнозируемой величиной и мы вынуждены построить сложный планировщик процессов, а к нему внутрипрограммную обвязку из семафоров, приоритетов и т.п. И тут, мы вспоминаем, что есть такая вещь, как исполнение по готовности, причём, количество обслуживающих это действо клеток может меняться динамически. Тогда, возникает идея: выделит по 1 клетке на программу, и пусть уже не ОС, а сам процессор, по готовности, отдаёт оставшиеся клетки программам, при этом, если какие-то программы находятся в ожидании, а другой нужно много ресурсов, то именно она и получит их все.
Именно на это я и пытаюсь обратить внимание, что утилизация процессора одной программой, это хорошо, но компьютер общего назначения, это прежде всего мультипрограммный агрегат, а с этой точки зрения, мультиклеточная архитектура не несёт никаких плюсов, более того, клетки придётся объединить в ядра, а это значит, что отдельную программу уже не получиться выполнить на всех клетках процессора, то есть, если он имеет 256 клеток, но в ядрах по 4 штуки, придётся довольствоваться лишь 4мя при использовании механизма "по готовности", а всё остальное будет работать так же, как и в обычных процессорах с классическими ядрами, то есть, выгоды никакой не будет.
Вы хорошо рассказываете про автораспараллеливание комманд в рамках одного процесса, но современные реалии таковы, что компьютеры используются в мультипрограммном, а значит и в многопоточном режиме. Это означает, что одновременно исполняются программы, которые ничего друг о друге не знают, и не имеют общую кодовую базу. Это так же означает, что, например, на 4 ядерном процессоре нельзя одновременно запустить 4 функции, выполняющие один и тот же объём работ и, таким образом, ускорить, практически, без накладных расходов, программу в 4 раза. Нет, "соседняя", программа будет работать на тех же 4 ядрах, поэтому, один экземпляр функции будет выполняться на 1 ядре, второй на 0.1 ядре, а ещё два будут ждать освобождение ресурсов (соответственно, ждать окончания исполнения такого "пакета", что бы начать выполнять следующий - контрпродуктивно, потому что ожидание может затянуться на 10x и более, тогда как ускорение возможно только в 4x, далее идут накладные расходы на диспетчеризацию и загрузку ресурсов и всё это становится очень непростым делом), именно это очень сильно осложняет параллельное программирование, а не внеочередное исполнение потока комманд.
Наскольо я знаю, в планах мультиклет, было выпустить 256 клеточный процессор, но через некоторое время, вы их изменили, на более реалистичный сколько-то ядер по 4 клетки. И тут, мы приходим к тому, что разделяя клетки на группы, вы расписываетесь в полной беспощности в работе с многопоточным ПО. Если бы было всё так хорошо с выполнением по готовности, то это выглядело бы как: 1 клетка на поток и ещё 200 клеток, мигрирующих по потокам, прибивающимися туда, где они требуются, но у вас будут ядра по 4 клетки и, соответственно, не более 4 клеток на поток (либо софтовое распределене ресурсов на уровне ОС), печалька.. :(
всегда на север, все страны всегда рисуются ориентированными на север,
Нет, в Австралии, не так.
Ваши аргументы похожи на спор о религии, но вы же понимаете, что карта была "вещью в себе" лишь в древности, и, может, в правилах было не только "на север", а и за случайно брошенный взгляд - ослепляли.
Если же говорить о картах, как о утилитарных вещах, то важны не они сами, а область их применения: плывёте по морю, из ориентиров только компас, не нужен маршрут, а только направление и от ветра зависит всё? Отлично, зафиксированная на север карта - ваш выбор, и вот, вы уже соотносите только курс с вертром и, фактически, пофиг на карту.
Идёте по сложной городской застройке, а экран смартфона - вытянутая дощечка? Вот вы и расположили свой путь, так что бы он максимально влезал в экран, что бы видеть все переходы и выделить ориентиры, которые бы, помогли не потеряться среди одинковых зданий, и вообще - можно ли там пройти или где срезать. Едете в метро (внезапно, ветки весьма сильно виляют, а не такие прямые как на карте) и хотите понять, в какую сторону вам выходить: располжите карту по ходу двжиения, и ваша задача - упростится.
Раньше, смотрел видео с Ютьюба, через VLC на 3x+ скорости, сейчас заменил lua на указанный вами, но ничего не изменилось: как затыкается каждую секунду, так и осталось.
Так что, приходится. как последнему тормозу, смотреть на 2x. Да и сам lua от февраля, когда статью-то готовили?
Автор гонит какую-то дичь. Во первых, в 1С8, у реквизитов есть ограничение типа, которое позволяет конкретизировать тип: Дата или ДатаВремя, поэтому любые запросы к базе данных будут типизироваться правильно.
Во вторых, автор вообще не понимает что такое типы, время в языке 1С дискретно поэтому 23.59.59, это всё равно что индекс 9 у массива из 10 элементов, у него нет никакого состояния конца 9го элемента или начала следующего, это конретный индекс.
В третьих, у ссылок, например, на документы, есть уникальный идентификатор, который можно считать ключём и если в массив по индексу 9 поместить пачку документов, то всегда можно их перебрать в порядке возрастания этого ключа, то есть выстроить в определённую последовательность и даже, это можно сделать с разными типами документов в перемешку (UIUD он такой). Но при этом доступ к этим документам, как было по индексу 9, так и остётся, очвидно, что как бы мы не перебирали элементы внутри пачки, на индекс 9 и его связь с пачкой это никак не влияет. Как показывает практика, порядок документов - важен и выборка пачки документов каждый раз в разном порядке, может сильно влиять на вычисления, поэтому в 1С дали возмоность с таким упорядочиванием работать, обозначив позицию в последовательности как момент времени, а ГраницаПериода всего лишь новый тип данных, который хранит одновремено два значения (Дата+UUID). Фактически, вместо примитивного типа, дали объект и методы работы с ним, но применимость у этого объекта весьма узкая, хоть и сильно упрощает многие моменты. Да в 1С много объектных фишек на уровне языка запросов, подобного SQL, но всё довольно примитивно. С введением, в новой платфоре, возможности работать с UUID в запросах, нет никаких сложностей полностью отказаться от момента времени и границы и сортировать "вручную" и резать последовательности по UUID, получая в точности тот же результат, но работая при этом раздельно со Ссылкой и с Датой. без всяких "непонятных" сущностей.
Статья типичного гумманитария, который познаёт цифровой мир через бесконеч-вечное и настолько преисполнился в своей мудрости, что готов изложить центральные концепции машины времени и вести нас в прекрасное будущее, которое наступит 1 января 4000 года .
В обращении они напоминают, что в 30-е и 40-е годы россиянам уже приходилось
Приходилось, это потому что - коммунисты, а свободные личности, спокойно до этого, себе работали по 8 дней и 1 день нихрена не делали. Тут, даже вводить ничего не надо, надо только - отменить, всё что навводили!
Нарушение целостности и целесообразность, это разные вещи. У вас есть таблица с 10 миллионами пользователей и табличка с данными привелеггий 8 вип персон. Связь 1 к одному. Но мы же чисто технически можем добавить в первую таблицу почти 10 миллионов нулов, построить индекс, что бы не идти фулсканом по 10 миллионам записям при проверке на вип персону, да, и будет - круто!
Ну, собственно говоря, причины появления camelCase не потому что это более удачная вещь, по сравнению со snake_case, чем PascalCase. Причины, в общем-то, лежат на поверхности: PascalCase решили немного кастрировать, для языков, где очень много слов начинающихся одинаково (например: get/set), в этом случае, строчные буквы переносят акцент на следующее слово, маскируя "однообразную" часть.
В статье вы пишите, что разные стили используются для разных сущностей, а в голосовалке предлагаете голосовать за один для всех... facepalm
Я использую PascalCase для процедур и функций и snake_case для переменных. Если бы я использовал camelCase тогда бы процедуры и переменные состоящие из одного слова невозможно было бы различить (camal процедура и snake переменная).
P. S. 1. "СлипшиесяСловаТрудноЧитать", не соглашусь, 90% времени они используются как токен, подошла бы даже картинка, это не художественный текст, что-то у вас не так с критериями.
" Одноимённые имена файлов" Шта?! Какое отношения имена файлов имеют к языку?
type TDayTime = (dMorning, dDay, dEvening, dNight); const Names : array [TDayTime] of string = ('Morning', 'Day', 'Evening', 'Night');
В 1С: создаёте перечисление в конфигураторе, а потом просто выводите его синоним(есть имя и синоним). Ещё можно создать составной тип (аналогично у них есть синонимы), а потом Строка(ОписаниеТипов.Типы()[Index]). Как обычно, любой кусок кода не даёт никакого понятия зачем это нужно, когда речь идёт о задаче, внезапно, выясняется, что такой код и не нужен, а можно сделать всё по другому и, возможно, более просто. "Адекватный" перевод, в языках программирования, это аналог Калиграфии: совершенно ненужная хрень, в наше время.
P.S. Адресовать перечислениями или строками, можно много где.
Соот = Новый Соответствие; Соот.Вставить(Перечисление.dMorning, "Morning") Соот[Перечисление.dMorning]
Структ = Новый Структура("dMorning, dDay", "Morning", "Day"); Структ["dMorning"]
В Паскале, поскольку есть строгая типизация, то на начальном уровне, действительно, сложно понять как она сочетается с указателями. Например, вами ничего не сказано о типе Pointer, это уже не годится как "ввведение". Передача параметров по ссылке и по значению и на фоне этого параметр типа СсылкаНаСсылку.
Сам я хорошо изучил эту тему: дву/много связанные списки, FreeMem/GetMem, выделение/освободжение в разных модулях, ссылки на процедуры и функции и т.п. И при этом, меня до сих пор вводит в ступор слово "разыменование", наиболее неудачного термина невозожмно было придумать, есть какие-то другие варианты?
Под видом документов мы регистрируем в системе некие события. Каждое событие располагается где-то на временной оси. Но сам процесс ввода (и тем более последующей корректировки) документов тоже разворачивается во времени!
В настоящий момент, как мне кажется, этот принцип не соблюдается ни в одной конфигурации 1С:Предприятие.
Не понял, какие у вас претензии к 1С. Есть документ и есть документ корректировки, никто не заставляет править документы в защищённом периоде.
Как вам уже написали, делая кроссплатформенный ассемблер, вы приходите к языку высокого уровня.
Выглядит это примерно так: на одном процессоре есть какие-то инструкции, а на другом нет. Значит берём некое очень ограниченное подмножество инструкций, которые есть на всех рассматриваемых процессорах, а потом для каждого конкретного сворачиваем последовательность микрокодов в одну инструкцию с помощью хинтов (фактически - шаблонов), а там, где не свернулось, работает эта самая микропрограмма. пусть и не так эффективно (и даже может быть свёрнута в несколько операндов). Микрокоды, это некая стековая машина, PI код, или LLVM IR, поэтому, фактически, мы можем придти к тому. что сами микрокоды вообще не являются усечённым подмножеством любой из архитектур, а являются полностью виртуальными. На втором шаге, выделив типовые последовательности, микрокодов, для конкретных программ, даём им имена и получаем операторы ЯВУ и конкретный кроссплатформенный язык.
pgTune - не открывается. Настройки Постгресса, сделали, размещён в системе виртуализации, как и MsSQL. Разница во времени выполнения запроса, по сравнению с MsSQL, на таблице с миллионом записей в 100 раз (2с vs 0.02с). План запроса - нормальный, индексы используется (запрос, элементраный, оптимизировать - нечего). Каким образом протестировать Постгресс, что бы можно было сказать, что он работает достаточно производительно на выделенных ресурсах или, что ресурсов не достаточно?
Разрешение лучше, ибо по 2к на каждый глаз в сумме даёт 4к и больше, что гораздо лучше впариваемых везде 1080 по вертикали.
"Руки" не нужны, прекрасно цепляются станадртыне органы управления.
Стол не нужен, я программирую лёжа в кровати с ноутом или беспроводной клавиатурой - очень удобно для тела, но не для шеи, возможность комфортно глядеь в потолок полностью разгрузить шею, и при этом иметь возможность быстро сменить положение на полусидячее или любое другое, мгновенно перенеся экран в удобное положение, это очень хорошая фишка.
Возможно, появятся массирующие проставки, давление - никуда не денется, зато появится омолаживающий и терапевтический эффект, дарю идею!
Воздействие на глаза, меня тоже очень беспокоит, пожалуй самый весомый пункт, будем ждать статистику.
На самом деле, фамильные деревья создаются не потому что хочется что-то узнать, а по той же причине, по какой разрешено иметь одну жену или мужа: наследование и переход имущества и прав. То есть это финасово-политический roadmap, при этом генетическое родство, по сути не имеет никакого значения, если доказано право. Наоборот, генетическое дерево, это попытка хакнуть эту систему, типа "незаконно рождённый сын из рода, происходящего от самого бога и людские законы ему - не указ". Вы же, делая дерево "родства" никак не поможете определить кто на что может претендовать.
Кровное родствоУсыновление/удочерениеА вариант: нагуляла, папа отрёкся, а настоящий отец не известен?
Женщины также имеют возможность отречься от своего ребёнка, в отличии о мужчин, не знаю, может ли при этом остаться только папа у ребёнка. В общем, я к тому, что фамильная связь и генетическая, это два разных дерева. И всяких нюансов может быть масса: хоть партогенез и не находит подтверждения у человека, зато химеризм и инцест - да.
> Все это было реализовано в процессоре R1
Да, я тоже, надеюсь, что динамическая реконфигурация - спасёт "отца русской демократии"!
>Ну, во-первых, «мультипрограммным агрегатом» являются не только компьютеры общего назначения.
Именно. Микроконтроллеры, где допустимы разные упрощения, это своеобразная ниша, для внедрения новой архитектуры, это мелковато.
>Только у мультиклеточной архитектуры программный код может быть исполнен на любом количестве клеток и с полной реализацией параллелизма, который присутствует в коде.
Только клетка, это не ядро, заявление из разряда: все регистры процессора доступны в полном объёме и в любой момент, для вычислений без обращения к памяти, а то что их надо постоянно сохранять и восстанавливать, для использования.. То же и с клетками: что толку, что они МОГУТ быть использованы, если в этот момент, они не доступны ни для какого кода, пока весь параграф полностью не будет выполнен? Если у вас ядро состоит из 16 клеток и на на этом ядре выполняется код, который требует всего 3 клетки, от этого ни жарко не холодно, потому что код, исполняемый на соседнем ядре и никакой другой тоже, не может использовать оставшиеся 13 клеток, более того, если конкретной процедуре нужно 256 клеток для исполнения, то он будет довольствовать лишь 16тью, а остальные ядра будут простаивать. Группировка клеток по ядрам, (по четыре клетки :-) ), хоронит саму суть Мультиклеточной архитектуры
Программа может использовать любое количество из 256 клеток, если это количество не более четырёх, ну - отлично!
Да, конечно, я не правильно использовал понятие потоков, подразумевалось, исполнение одновременно нескольких программ, у каждой хотя бы 1 поток, что недальновидно было сокращено до "многопоточности".
У мультирограммности, нет задачи полностью утилизировать ресурсы, а стоит задача именно одновременной работы нескольких программ. Если такой возможности нет, то вы вынуженны будете пользоваться своеобразными коммбайнами, где в текстовом редакторе, будет и проигрыватель и часы и браузер интернета, но при этом программист будет специалистом только по текстовым редкторам, а графического редактра, там не будет и в помине, поэтому, переодически, вам придётся этот комбайн закрывать и открывать графический редактор. Поэтому путь, когда программы узкоспециализированы, но при этом вынуждены работать независимо, это был естественный эволюционный, однако он порождает проблемы с распределением ресурсов.
Пример, с 4мя функциями, это то, как мультирограммность влияет на исполнение кода, а в современном качестве, к этому ещё добавляются всякие малые ядра и динамическое изменение частоты процессора. Но если вкратце, то имея в своём распоряжении 4 ядра, некую функцию, отрабатывающую, в среднем, за одно время и массив данных, то простейший алгоритм параллельной обработки, ничем не будет отличаться от развёртки цикла, мы просто запускаем по функции на ядро и ждём, когда они все отработают, после начинаем следующую итерацию, такой себе синхронный подход. Очевидно, что при мутипрограммности, время исполнения функции на одном ядре, перестаёт быть адекватно прогнозируемой величиной и мы вынуждены построить сложный планировщик процессов, а к нему внутрипрограммную обвязку из семафоров, приоритетов и т.п. И тут, мы вспоминаем, что есть такая вещь, как исполнение по готовности, причём, количество обслуживающих это действо клеток может меняться динамически. Тогда, возникает идея: выделит по 1 клетке на программу, и пусть уже не ОС, а сам процессор, по готовности, отдаёт оставшиеся клетки программам, при этом, если какие-то программы находятся в ожидании, а другой нужно много ресурсов, то именно она и получит их все.
Именно на это я и пытаюсь обратить внимание, что утилизация процессора одной программой, это хорошо, но компьютер общего назначения, это прежде всего мультипрограммный агрегат, а с этой точки зрения, мультиклеточная архитектура не несёт никаких плюсов, более того, клетки придётся объединить в ядра, а это значит, что отдельную программу уже не получиться выполнить на всех клетках процессора, то есть, если он имеет 256 клеток, но в ядрах по 4 штуки, придётся довольствоваться лишь 4мя при использовании механизма "по готовности", а всё остальное будет работать так же, как и в обычных процессорах с классическими ядрами, то есть, выгоды никакой не будет.
Вы хорошо рассказываете про автораспараллеливание комманд в рамках одного процесса, но современные реалии таковы, что компьютеры используются в мультипрограммном, а значит и в многопоточном режиме. Это означает, что одновременно исполняются программы, которые ничего друг о друге не знают, и не имеют общую кодовую базу. Это так же означает, что, например, на 4 ядерном процессоре нельзя одновременно запустить 4 функции, выполняющие один и тот же объём работ и, таким образом, ускорить, практически, без накладных расходов, программу в 4 раза. Нет, "соседняя", программа будет работать на тех же 4 ядрах, поэтому, один экземпляр функции будет выполняться на 1 ядре, второй на 0.1 ядре, а ещё два будут ждать освобождение ресурсов (соответственно, ждать окончания исполнения такого "пакета", что бы начать выполнять следующий - контрпродуктивно, потому что ожидание может затянуться на 10x и более, тогда как ускорение возможно только в 4x, далее идут накладные расходы на диспетчеризацию и загрузку ресурсов и всё это становится очень непростым делом), именно это очень сильно осложняет параллельное программирование, а не внеочередное исполнение потока комманд.
Наскольо я знаю, в планах мультиклет, было выпустить 256 клеточный процессор, но через некоторое время, вы их изменили, на более реалистичный сколько-то ядер по 4 клетки. И тут, мы приходим к тому, что разделяя клетки на группы, вы расписываетесь в полной беспощности в работе с многопоточным ПО. Если бы было всё так хорошо с выполнением по готовности, то это выглядело бы как: 1 клетка на поток и ещё 200 клеток, мигрирующих по потокам, прибивающимися туда, где они требуются, но у вас будут ядра по 4 клетки и, соответственно, не более 4 клеток на поток (либо софтовое распределене ресурсов на уровне ОС), печалька.. :(
Нет, в Австралии, не так.
Ваши аргументы похожи на спор о религии, но вы же понимаете, что карта была "вещью в себе" лишь в древности, и, может, в правилах было не только "на север", а и за случайно брошенный взгляд - ослепляли.
Если же говорить о картах, как о утилитарных вещах, то важны не они сами, а область их применения: плывёте по морю, из ориентиров только компас, не нужен маршрут, а только направление и от ветра зависит всё? Отлично, зафиксированная на север карта - ваш выбор, и вот, вы уже соотносите только курс с вертром и, фактически, пофиг на карту.
Идёте по сложной городской застройке, а экран смартфона - вытянутая дощечка? Вот вы и расположили свой путь, так что бы он максимально влезал в экран, что бы видеть все переходы и выделить ориентиры, которые бы, помогли не потеряться среди одинковых зданий, и вообще - можно ли там пройти или где срезать. Едете в метро (внезапно, ветки весьма сильно виляют, а не такие прямые как на карте) и хотите понять, в какую сторону вам выходить: располжите карту по ходу двжиения, и ваша задача - упростится.
С чем вы вообще спорите?
Раньше, смотрел видео с Ютьюба, через VLC на 3x+ скорости, сейчас заменил lua на указанный вами, но ничего не изменилось: как затыкается каждую секунду, так и осталось.
Так что, приходится. как последнему тормозу, смотреть на 2x. Да и сам lua от февраля, когда статью-то готовили?
Автор гонит какую-то дичь. Во первых, в 1С8, у реквизитов есть ограничение типа, которое позволяет конкретизировать тип: Дата или ДатаВремя, поэтому любые запросы к базе данных будут типизироваться правильно.
Во вторых, автор вообще не понимает что такое типы, время в языке 1С дискретно поэтому 23.59.59, это всё равно что индекс 9 у массива из 10 элементов, у него нет никакого состояния конца 9го элемента или начала следующего, это конретный индекс.
В третьих, у ссылок, например, на документы, есть уникальный идентификатор, который можно считать ключём и если в массив по индексу 9 поместить пачку документов, то всегда можно их перебрать в порядке возрастания этого ключа, то есть выстроить в определённую последовательность и даже, это можно сделать с разными типами документов в перемешку (UIUD он такой). Но при этом доступ к этим документам, как было по индексу 9, так и остётся, очвидно, что как бы мы не перебирали элементы внутри пачки, на индекс 9 и его связь с пачкой это никак не влияет. Как показывает практика, порядок документов - важен и выборка пачки документов каждый раз в разном порядке, может сильно влиять на вычисления, поэтому в 1С дали возмоность с таким упорядочиванием работать, обозначив позицию в последовательности как момент времени, а ГраницаПериода всего лишь новый тип данных, который хранит одновремено два значения (Дата+UUID). Фактически, вместо примитивного типа, дали объект и методы работы с ним, но применимость у этого объекта весьма узкая, хоть и сильно упрощает многие моменты. Да в 1С много объектных фишек на уровне языка запросов, подобного SQL, но всё довольно примитивно. С введением, в новой платфоре, возможности работать с UUID в запросах, нет никаких сложностей полностью отказаться от момента времени и границы и сортировать "вручную" и резать последовательности по UUID, получая в точности тот же результат, но работая при этом раздельно со Ссылкой и с Датой. без всяких "непонятных" сущностей.
Статья типичного гумманитария, который познаёт цифровой мир через бесконеч-вечное и настолько преисполнился в своей мудрости, что готов изложить центральные концепции машины времени и вести нас в прекрасное будущее, которое наступит 1 января 4000 года .
Приходилось, это потому что - коммунисты, а свободные личности, спокойно до этого, себе работали по 8 дней и 1 день нихрена не делали. Тут, даже вводить ничего не надо, надо только - отменить, всё что навводили!
Нарушение целостности и целесообразность, это разные вещи. У вас есть таблица с 10 миллионами пользователей и табличка с данными привелеггий 8 вип персон. Связь 1 к одному. Но мы же чисто технически можем добавить в первую таблицу почти 10 миллионов нулов, построить индекс, что бы не идти фулсканом по 10 миллионам записям при проверке на вип персону, да, и будет - круто!
Ну, собственно говоря, причины появления camelCase не потому что это более удачная вещь, по сравнению со snake_case, чем PascalCase. Причины, в общем-то, лежат на поверхности: PascalCase решили немного кастрировать, для языков, где очень много слов начинающихся одинаково (например: get/set), в этом случае, строчные буквы переносят акцент на следующее слово, маскируя "однообразную" часть.
В статье вы пишите, что разные стили используются для разных сущностей, а в голосовалке предлагаете голосовать за один для всех... facepalm
Я использую PascalCase для процедур и функций и snake_case для переменных. Если бы я использовал camelCase тогда бы процедуры и переменные состоящие из одного слова невозможно было бы различить (camal процедура и snake переменная).
P. S. 1. "СлипшиесяСловаТрудноЧитать", не соглашусь, 90% времени они используются как токен, подошла бы даже картинка, это не художественный текст, что-то у вас не так с критериями.
" Одноимённые имена файлов" Шта?! Какое отношения имена файлов имеют к языку?
"CSS" Мы о языках программирования или о чём?
какая-то дичь, дальше анализировать не стал.
В 1С: создаёте перечисление в конфигураторе, а потом просто выводите его синоним(есть имя и синоним). Ещё можно создать составной тип (аналогично у них есть синонимы), а потом Строка(ОписаниеТипов.Типы()[Index]). Как обычно, любой кусок кода не даёт никакого понятия зачем это нужно, когда речь идёт о задаче, внезапно, выясняется, что такой код и не нужен, а можно сделать всё по другому и, возможно, более просто. "Адекватный" перевод, в языках программирования, это аналог Калиграфии: совершенно ненужная хрень, в наше время.
P.S. Адресовать перечислениями или строками, можно много где.
Соот = Новый Соответствие;
Соот.Вставить(Перечисление.dMorning, "Morning")
Соот[Перечисление.dMorning]
Структ = Новый Структура("dMorning, dDay", "Morning", "Day"); Структ["dMorning"]
to SalamWord
В Паскале, поскольку есть строгая типизация, то на начальном уровне, действительно, сложно понять как она сочетается с указателями. Например, вами ничего не сказано о типе Pointer, это уже не годится как "ввведение". Передача параметров по ссылке и по значению и на фоне этого параметр типа СсылкаНаСсылку.
Сам я хорошо изучил эту тему: дву/много связанные списки, FreeMem/GetMem, выделение/освободжение в разных модулях, ссылки на процедуры и функции и т.п. И при этом, меня до сих пор вводит в ступор слово "разыменование", наиболее неудачного термина невозожмно было придумать, есть какие-то другие варианты?
Не понял, какие у вас претензии к 1С. Есть документ и есть документ корректировки, никто не заставляет править документы в защищённом периоде.
Предложения по нововведениям в последней платформе, можно оставлять в этом канале:https://t.me/platform_suggestions
Как вам уже написали, делая кроссплатформенный ассемблер, вы приходите к языку высокого уровня.
Выглядит это примерно так: на одном процессоре есть какие-то инструкции, а на другом нет. Значит берём некое очень ограниченное подмножество инструкций, которые есть на всех рассматриваемых процессорах, а потом для каждого конкретного сворачиваем последовательность микрокодов в одну инструкцию с помощью хинтов (фактически - шаблонов), а там, где не свернулось, работает эта самая микропрограмма. пусть и не так эффективно (и даже может быть свёрнута в несколько операндов). Микрокоды, это некая стековая машина, PI код, или LLVM IR, поэтому, фактически, мы можем придти к тому. что сами микрокоды вообще не являются усечённым подмножеством любой из архитектур, а являются полностью виртуальными. На втором шаге, выделив типовые последовательности, микрокодов, для конкретных программ, даём им имена и получаем операторы ЯВУ и конкретный кроссплатформенный язык.
Без октадона, этот обзор - не будет полным.
Что насчёт закрытых полостей типа грот, у которых через дно есть выход на верх? Два сообщающийся сосуда?