для работы нужен ArcGIS Desktop и ArcGIS Server которые стоят вместе около двух лямов

а нужны по факту лишь для перепроецирования изображений и отдачи их по http (в виде специального сервиса)

крутой софт

не софт реально крутой, просто используется на тысячную долю процента

да и то как видно из видео — через зад

и мне кажется C# и .NET используются не из-за GUI

ну это да, но в плане ГУИ то что? Почему его так никто и не написал? Там же вроде бы все не сложно должно быть. Окошко, кнопочку нарисовать...

Что-то мне подсказывает, что в «несложном» фреймворке, например, виджет таблицы не будет уметь в настройку иконок в сортируемых столбцах, не будет уметь подгружать только видимые данные из гигантских или бесконечных таблиц, будет иметь ограничения на то, какой виджет можно встроить в качестве инпута для редактируемого поля и что делать с этим виджетом при потере фокуса. Ещё я могу выдумать миллион требований к такому виджету, как контекстное меню (хочу там кнопки, как в Файрфоксе!). Или обычное меню (хочу там поле поиска!). Или кнопка (хочу там дропдаун справа, но с кастомной иконкой). Так что нет, GUI, на который можно было бы положиться без боязни однажды упереться в потолок – это совсем не просто. Это скорее «как Qt», чем «просто».

К сожалению, полностью этот страх упереться в потолок исчезает только при использовании HTML, наверное. :-/

С html тоже бывает. Сейчас уже почти всё ок, но я ещё помню времена, когда всё было довольно печально.

А более-менее норм стало из-за стандартизации и когда куча народу стали делать что-то одно, а не каждый свой велосипед.

Ну, я имел в виду именно «сейчас уже почти всё ок», что аж целые browser.html и прочие Атомы появляются. С привязкой к конкретному движку.

То есть я не про веб, а про использование своего окошка с вебом внутри в качестве интерфейса программы. Это ведь уже повсеместно. И на мобилках много этого, как я понимаю.

Это грустно и далеко от красивого декларативного описания одинаковых внешне меню, но это практичный выход, видимо

Ах если бы для системного кроссплатформенного гуя появилась аналогичная стандартизация и было бы вбухано столько же ресурсов. При том и упор мог быть сделан уже не на цвет тенюшечек и скруглённые уголки с кастомными гарнитурами, а на корректную работу всего этого с любой мышкой, клавиатурой, тачскрином, всякими штуками для незрячих и т.п. Да ещё с красивым даунгрейдом вплоть до того, чтобы тот-же интерфейс и к дисплею с очень малым разрешением/глубиной цвета адаптировался и к терминальному с псевдографикой и т.п.

А то веб то стандартизирован вроде, но интерфейсы то один хрен все или через какие-нибудь jQuery-плагины делаются или на коленке под каждый конкретный случай.

И чаще всего весьма ограниченно. Вплоть до того, что какой-нибудь селектбокс не може получить фокус по табуляции, а если и может, то один хрен с клавиатуры не управляется. А если и как-то открывается и листается, то нельзя нажав первую букву списка автоматом прокрутить (на этот случай в лучшем случае строка поиска есть).

Закрыть какое-нибудь всплаывающее окно или ответить "нет" по esc? Не, не слышали.

В общем графика пока сильно перевешивает юзабилити.

А всё потому, что всё делается под каждый конкретный случай, а реализовывать все эти ньюансы для сайта с 1к юзеров из которых из будут использовать пятеро никто не будет.

В доке вычитал: Status registers are not saved by the current implementations. This means floating point exception status bits (overflow, divide by 0), rounding mode and similar stuff is set per-thread, not per Fiber! Получается что фиберы значение регистров не сохраняют?

Отработали и все

нет, тут про другое

https://en.wikipedia.org/wiki/Status_register

это регистры, в которых хранится немного другая инфа

Блин

флаг переполнения например

вот они не сохраняются

Просто нефига не понятно куда они данные при переключении к другому файберу кладут

В оперативку? Но тогда это как переключить контекст тоже самое

мы же уже это обсуждали

это переключение контекста и в том и другом случае

только в режим ядра не уходит ос

А ну это то да. Это обсуждали)

И дальше. Месседж пассинг получается просто надстройка над тредами?

а месседж пассинг тут причём вообще?

Я просто про разные режимы многопототочности читаю или как ее там конкаренси на инглише вроде более грамотно называют

Тупо сижу пытаюсь в голове все уложить

месседж пассинг не имеет отношения к смене контекста

Он же между потоками верно идет?

Тоесть выделяется общая область памяти откуда каждый читает сообщение и может писать (возможно не в одну а в разные области)

Ребят, я понимаю что всех тут с многопоточностью уже наверно достал, но все же вот хороший материал, где все внятно написано https://crystal-lang.org/docs/guides/concurrency.html Я думаю Ди тут не сильно отличается

Спасибо

Там написано что crystal не поддерживает параллелизма, D поддерживает. А когда реально работает несколько потоков это совсем не та многозадачность, про которую там говорится.

И spawn там только fiber'ы умеет

Так что это скорее хороший материал по fiber'ам, а не по многозадачность/многопоточности в целом

Опробовал libuid — заебись. При статической компиляции, вместе с фобосом, бинарник второго примера выходит 500кб.

Порадовала возможность рисовать через Area.

Для простых задач должно быть самое то.

Не плохо бы еще вебкит туда поиметь.

угу

супер тема

а как ты статически компилируешь? можешь команду показать?

Опробовал libuid — заебись. При статической компиляции, вместе с фобосом, бинарник второго примера выходит 500кб.

dmd или ldc2?

dmd

а как ты статически компилируешь? можешь команду показать?

Напомни в четверг. Я за пределами цивилизации)

ok

ELF x86_64

В принципе, ничего нового в статической компиляции нет.

Кстати, на Линуксе, dmd для компоновки и линковки передает управление gcc :)

Кстати, на Линуксе, dmd для компоновки и линковки передает управление gcc :)

как ты это выяснил?

Какой-то вербоуз флаг ткнул, кажется -r

никогда просто не обращал внимание

Он сначала собрал *.о файл, потом скормил его gcc

не -r а -v

Компоновка — компиляция всего в машинный код. Линковка - слепка всего вместе и вставка ссылок на нужные куски так?

ERROR: S client not available

Ртфм, м?

разве это не одно и то же? (я безнадёжный неуч во всём этом)

Машкод после линковки

*.о это инструкции для линковщика

Линкер герерит асм файлы и вызывает асм)

Компоновка — компиляция всего в машинный код. Линковка - слепка всего вместе и вставка ссылок на нужные куски так?

вроде же так

и *.o это уже бинарный файл, не?

https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D1%8B%D0%B9_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D1%8C Объектные файлы представляют собой блоки машинного кода и данных, с неопределенными адресами ссылок на данные и процедуры в других объектных модулях, а также список своих процедур и данных. Компоновщик собирает код и данные каждого объектного модуля в итоговую программу, вычисляет и заполняет адреса перекрестных ссылок между модулями.

так что .o это уже скомпилированный код, а не инструкции для линковщика

Короче итоге моего копания с файберами. Лучше туда вообще не лезть. Все что отличается от потоков крайне сильно ОС и CPU специфично. Точный выигрыш назвать крайне и крайне сложно. Там кучу моментов нужно учитывать т.к. даже в рамках одной архитектуры могут быть очень большие отличия. Файберы — по большей части это попытка добавить многозадачность которая была во времена Win98 в совремнные системы т.е. каждое волокно (или поток времен Win98) тупо сам решает когда ему отдать управление. Соответственно у него есть ряд состояний (но это сейчас не важно). В некоторых ОС типа DragonFlyBSD файберы вообще из себя представляют из себя потоки в режиме пользователя (как я понял). Было бы очень интересно тест провести, но не уверен что компилятор D для DragonFly есть.

Ситуацию сильно осложняет многоядерность т.к. на многоядерных компах еще больше нюансов нужно учитывать. Чисто субъективно сложилось мнение что они как были, так и будут где-то сбоку. Вероятно куда разумнее Пулы Тредов создавать (я пока про это только читал). Уж слишком много гемора с файберами. Однако вроде как (это не точно) каждая функция приема входящего подключения в vibed — это файбер. т.е. стоит она очень мало.

эмм

с файберами как раз гемороя нет

они точно одновременно не выполняются, поэтому не нужно организовывать защиту доступа к данным

а это основной геморой с тредами

А треды в Ди разве не изолированы (точнее данные в них)?

а кто-то отменял shared?

так по дефолту то не shared

вообще полностью изолированные потоки достаточно бесполезны, они всё-равно как-то должны общаться

общение с помощью сообщений нормально? или Минусы есть?

Короче итоге моего копания с файберами. Лучше туда вообще не лезть. Все что отличается от потоков крайне сильно ОС и CPU специфично. Точный выигрыш назвать крайне и крайне сложно. Там кучу моментов нужно учитывать т.к. даже в рамках одной архитектуры могут быть очень большие отличия. Файберы — по большей части это попытка добавить многозадачность которая была во времена Win98 в совремнные системы т.е. каждое волокно (или поток времен Win98) тупо сам решает когда ему отдать управление. Соответственно у него есть ряд состояний (но это сейчас не важно). В некоторых ОС типа DragonFlyBSD файберы вообще из себя представляют из себя потоки в режиме пользователя (как я понял). Было бы очень интересно тест провести, но не уверен что компилятор D для DragonFly есть.

файберы - это сопрограммы Они нужны не для параллелизма, а асинхронности - это понятия ортогональны Выйгрыш они могут давать, а могут и не давать - по факту они обеспечивают как-бы-отсутствие блокрировок (нет)

нормально

А почему тогда только механизм месседж-пассинга не оставлен с целью не плодить лишние сущности?

файберы - это сопрограммы Они нужны не для параллелизма, а асинхронности - это понятия ортогональны Выйгрыш они могут давать, а могут и не давать - по факту они обеспечивают как-бы-отсутствие блокрировок (нет)

Вот если есть шедулер, который будет расидывать нити по пулу потоков - то это просто зашибись и здорово

Просто я читал что есть языки где только он

в любом случае очередь сообщений это shared массив

Вот если есть шедулер, который будет расидывать нити по пулу потоков - то это просто зашибись и здорово

так вроде vibe делает

общение с помощью сообщений нормально? или Минусы есть?

Смотря для чего Есть много моделей асинхронности/многопоточности CSP, те же акторы

Акторы это перспективная тема? Или тоже местячковое решение?

Смотря для чего

Тут вообще все концепции "местячковые"

Просто по идее же со временем все к какой-то унификации должно двигаться