Войти
ФлеймФорумПроЭкты

Ü (Programmiersprache) (39 стр)

Страницы: 136 37 38 39 40 41 Следующая »
#570
(Правка: 22:44) 22:41, 9 ноя. 2019

Panzerschrek[CN]
> Сейчас вот надо придумать, как бы сделать так, чтобы всякие функции сишной
> стандартной библиотеки были доступны из браузера. Думаю, без emscripten тут не обойтись.
чоа? а c-runtime под webassembly от llvm не доступен?
я бы вытягивал из браузера браузерные вещи - типа WebGL, может быть манипуляцию с DOM-ом, клава, мышь... что ещё для геймдева нужно :)

просто, если C-runtime тянуть через webassembly, то получится неэффективно.
Т.к. это нужно будет делать через импорт.
WebAssembly->JS->WebAssembly
или ещё хуже, реализовывать в самом JS-е.


#571
22:55, 9 ноя. 2019

skalogryz
> WebAssembly->JS->WebAssembly
Глянул в emscrtipten. Походу, они таки всё что можно, компилируют из C в WebAssembly, а через импорты тянут только самое необходимое.

> c-runtime под webassembly от llvm не доступен?
Быстрый поиск не дал результатов. Да и с чему бы ему там быть? C рантайм это glibc.

> или ещё хуже, реализовывать в самом JS-е.
Какой-нибудь printf на нём придётся реализовывать. Всё остальное - в нормальном языке (Ü, C, C++).

#572
(Правка: 23:09) 23:09, 9 ноя. 2019

Panzerschrek[CN]
> Какой-нибудь printf на нём придётся реализовывать.
ооо! printf() это вообще боль для webassembly
сигнатура функции с фиксированным количеством и типом параметрова должна быть известна заранее;
т.е. функцию с произвольным количеством параметров (переданных через стэк) реализовать не получится.
как минимум, нужно будет организовать массив с укаталеями на параметры; либо городить кучу overload-ов, что не вариант.
(хз как оно в :U)

имхо, проще реализоывать WriteConsole(char* buf, int len) в JS-е, а основное тело printf() в WebAssembly.

#573
12:23, 10 ноя. 2019

Прохладные истории продолжаются.

После перехода на llvm 9 начали валиться сборки на travis-ci. Новый llvm жирнее старого и его сборка не умещалась в лимит.
Решил собирать проект с предсобранным llvm - скачал его, настроил файл проекта под возможность собираться с готовым llvm.
Беда пришла откуда не ждали - компилятор валится на такой фигне:

undefined reference to `typeinfo for llvm::cl::GenericOptionValue'
undefined reference to `typeinfo for llvm::cl::generic_parser_base'
undefined reference to `typeinfo for llvm::cl::Option'

Расследование показало, что всему виной rtti. Бинари llvm собраны без него, а мой проект - с ним. Но почему стреляет только в том месте? А потому, что там в заголовочном файле объявлен шаблонный класс, наследуемый от нешаблонного. Для того нешаблонного класса компилятор ожидает, что кто-то для него создаст rtti. Но при компиляции llvm его никто не создал.

Теперь даже не знаю что делать. Собирать свой проект без rtti как-то не охота - местами используется dynamic_cast и городить его замену я не намерен. Скорее всего, надо как-то другим способом заставить travis-ci собирать проект побыстрее, ну или же увеличить лимит времени на сборку, что может быть небесплатно.

#574
20:40, 13 ноя. 2019

Таки закостылил проект, чтобы он без rtti работал. Костылей, как оказалось, много не понадобилось. При грамотном подходе dynamic_cast почти не нужен.
Теперь проект собирается с предсобранным llvm на travis-ci. Теперь переходу на llvm-9 ничего не мешало и я залил ветку в master.

#575
20:41, 13 ноя. 2019

В заметках о выпуске llvm заметил такой интересный пункт - "проекты с открытым исходным кодом, использующие llvm ${номер_версии}". Надо исследовать, как бы туда можно попасть.

#576
22:28, 18 дек. 2019

Подумываю тут над написанием второго компилятора Ü - написанного на Ü.
Раньше мне это казалось фантастикой, но сейчас это уже кажется реальностью. Главной проблемой я считал работу с llvm - компилятор много создаёт инструкций, работает с llvm-ными структурами данных и т. д. Но сейчас я осознал, что это не такая большая проблема. В llvm есть достаточно объёмный сишный интерфейс для всего этого. А с недавнего времени у меня есть преобразователь сишных заголовочных файлов в Ü. Соответственно, можно сгенерировать нужный заголовочный файл Ü и использовать определения из него.

Сейчас я обдумываю, какие же проблемы могут ещё возникнуть при написании такого компилятора. Пока что обнаружил несколько серьёзных проблем:
1) Проблемы с инстанцированием шаблонных типов. Сейчас при инстанцировании сразу строятся все методы. Из-за этого невозможнопостроить рекурсивные структуры данных. Кажется, это можно решить, откладывая генерацию шаблонных методов на потом.
2) Проблемы с указанием связывания ссылок в сигнатурах методов контейнеров. Это требует получения некоторой информации о типе, и как следствие, не работает на рекурсивных структурах. Для устранения этой проблемы можно было бы отказаться от указывания связывания ссылок, и как следствие, от хранения структур со ссылками внутри в стандартных контейнерах.
3) Текущий компилятор много использует контейнер std::variant. В Ü надо реализовать такой контейнер. Проблема в том, что Ü пока что не поддерживает шаблонов с переменным числом аргументов. Было бы неплохо их добавить в язык.

Когда эти проблемы будут решены, можно будет браться за написание второго компилятора. Но наверняка в процессе ещё вскроются какие-то недоработки в стандартной библиотеке и в дизайне языка. Эти проблемы придётся решить.

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

#577
22:48, 18 дек. 2019

Panzerschrek[CN]
> Проблема в том, что Ü пока что не поддерживает шаблонов с переменным числом
> аргументов.
Шо, даже
UPAIR<T1, UPAIR<T2, UPAIR<T3, T4>>>?

#578
22:52, 18 дек. 2019

1 frag / 2 deaths
> UPAIR<T1, UPAIR<T2, UPAIR<T3, T4>>>
Изврат какой-то.
Не, конечно можно наговнокодить прилично и обойтись без переменного количества аргуметов, но хотелось бы, чтобы шаблонокод был более изящным (насколько это возможно).

> UPAIR
А такого говна у меня нету. В Ü, с недавнего времени, есть кортежи как один из видов типов в самом языке, без всякой шаблоноты.

#579
23:06, 18 дек. 2019

Panzerschrek[CN]
А, ну кортеж и принимай как рагумент

#580
9:07, 19 дек. 2019

1 frag / 2 deaths
> А, ну кортеж и принимай как рагуме
Это какой-то изврат. Лучше запилить всё по-правильному.

#581
22:21, 29 дек. 2019

Вот так примерно учатся выговаривать название моего языка:

#582
11:47, 2 янв. 2020

UP.

Последние месяцы я занимался в основном тем, что писал документацию на Ü. И вот, я её почти написал:
https://u-00dc-sprache.readthedocs.io/ru/latest/index.html

Замечания и комментарии приветствуются.

#583
(Правка: 22:21) 20:59, 13 мар. 2020

Начал тут реализовывать нетривиальное перемещение и возник ряд нюансов, не знаю как быть.

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

#584
22:10, 13 мар. 2020

Panzerschrek[CN]
> В случае **нетривиального** перемещения можно при построении кода запомнить, что
> такая-то переменная была перемещена и поступать с ней соответствующим образом -
> запретить обращение и не вызывать деструктор. В случае **нетривиального**
> перемещения так сделать не получится.
Очепятка?

Почему бы не сделать как в плюсах: деструктор вызывается всегда, а перемещение это просто операция над специальным "типом"?

Страницы: 136 37 38 39 40 41 Следующая »
ФлеймФорумПроЭкты