OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 21:26

Часовой пояс: UTC + 3 часа


Правила форума


Посмотреть правила форума



Начать новую тему Ответить на тему  [ Сообщений: 649 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 33  След.
Автор Сообщение
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 05 Март, 2023 12:14 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
перепелил ассемблер до более-менее юзабельного состояния; заодно и дизасм чуть-чуть. потому что никто не использует синтаксис `MOV EAX,globvar` для загрузки значения `globvar`, все пишут `MOV EAX,[globvar]`. ну, и SIB никто не пишет как `var[REG]` и ты пы, как пытается нарисовать дизасм и понимал асм; переделал в нормальное `[REG+var]`. заодно избавился от CPA.Data: это было для систем, где мало памяти и надо perfect hash, а мне плевать. так что формирую набор инструкций оригинальным исходником (который CPA.Data делал).

заодно по дороге починил баг в оригинальном асме: оно segment override вообще не понимало.

в принципе, надо бы дизасм тоже из A2 уволочь, там вроде бы есть SSE и прочая. фоксовый асм там тоже круче, но мне плевать с высокой горки на AVX со товарищи, поэтому не вижу смысла секситься с ним пока. это вот для Гершеля могло бы пригодиться, а мне не надо. ;-)


p.s.: и убрал реинит FPU на каждый чих. посмотрим, что от этого сломается, гыг. следует заметить, что вызов внешних библиотек реинит FPU делает, но только если CP-процедура FPU использует. потому добавил `Kernel.ResetFpuState()`, чтобы можно было руками починить, если чо. в принципе, большинство кода FPU никак не трогает (и вообще почти весь современный код вместо FPU один фиг использует SSE, даже на X86), так что ничего особо поломаться не должно. ну, посмотрим.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 05 Март, 2023 13:37 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
сделал фикс для упомянутой в этой теме ошибки. заодно убрал сохранение ESI и EDI для экспортированых процедур: оно не должно быть необходимо. посмотрим, что сломается от этого. пока что похоже что ничего.

и p.s.: у меня есть огромное желание выкинуть поддержку COM к чёртовой матери. эта хреновина болтается в компиляторе бесполезным грузом: ну кто сейчас реально будет использовать COM, да ещё и к 32-битным процессам? я точно не буду, а если буду — то сделаю себе обёртку руками, и руками же буду за рефами следить, не впервой. за более чем десять лет мне COM понадобилось ровно один раз, и то из сишечки. в своё время омики сделали поддержку, потому что m$ рекламировала COM как киллерфичу, но с тех пор COM тупо издохло. в пень его. с вероятностью почти единица вычищу из компилятора этот бесполезный хлам.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 05 Март, 2023 14:59 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
алсо, подумываю над тем, чтобы писать в sym доку-комментарии. которые начинаются с `(**`, и находятся непосредственно рядом с объявлением процедуры/константы/типа/поля. или (и?) даже сделать специальный тип фолдов: доку-фолды.

идея такая, что разделение документации и кода на разные файлы идеологически, может, и правильно, но с учётом психологии хумансов — очень неудобно. давно замечено, что правка документации, которая живёт в отдельном файле, требует большей ментальной дисциплины, чем правка сразу «по месту». поскольку у нас не просто plain text — то документацию можно писать таки сразу по месту, и прятать в спецфолдах. если её писать в sym (или рядом) — то это позволяет избавиться от Docu-сопроводиловки к модулям вообще: просто одна из опций «показать интерфейс» покажет интерфейс в виде документации. также «найти документацию» не будет зависеть от конвенций: выдёргиваем что надо из sym — и всё.

если сделать удобный интерфейс к этой штуке — то получаем готовый апи для показа хинтов в редакторе, возможность удобно делать интструменты, которые проверят уровень документированности модуля, и прочие прикольные вещи, которыми так кичатся «современные IDE». в общем, упрощается обработка документации машиной, что весьма удобно.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 05 Март, 2023 16:58 

Зарегистрирован: Суббота, 04 Май, 2019 10:21
Сообщения: 29
arisu писал(а):
перепелил ассемблер до более-менее юзабельного состояния; заодно и дизасм чуть-чуть. потому что никто не использует синтаксис `MOV EAX,globvar` для загрузки значения `globvar`, все пишут `MOV EAX,[globvar]`. ну, и SIB никто не пишет как `var[REG]` и ты пы, как пытается нарисовать дизасм и понимал асм; переделал в нормальное `[REG+var]`. заодно избавился от CPA.Data: это было для систем, где мало памяти и надо perfect hash, а мне плевать. так что формирую набор инструкций оригинальным исходником (который CPA.Data делал).

заодно по дороге починил баг в оригинальном асме: оно segment override вообще не понимало.

в принципе, надо бы дизасм тоже из A2 уволочь, там вроде бы есть SSE и прочая. фоксовый асм там тоже круче, но мне плевать с высокой горки на AVX со товарищи, поэтому не вижу смысла секситься с ним пока. это вот для Гершеля могло бы пригодиться, а мне не надо. ;-)
Good news, I'm interested in this feature!
arisu писал(а):
p.s.: and removed the FPU rheinite on every sneeze. let's see what happens, gyg. note that the call to external libraries reinets the FPU does, but only if the CP procedure uses the FPU. so I added 'Kernel.ResetFpuState()' so I could fix it with my hands if cho. basically, most of the FPU code doesn't touch (and in general almost all modern code instead of FPU one fig uses SSE, even on X86), so nothing much should break. well, we'll see.
FPU is heavily used by BB, not only for floating point operations, but also for long int operations. The state of FPU is very important to it, and when calling external functions, the state of FPU is not protected by X86 ABI, so it is necessary to reset it for safety reasons.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 05 Март, 2023 18:21 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
luowy писал(а):
FPU is heavily used by BB, not only for floating point operations, but also for long int operations. The state of FPU is very important to it, and when calling external functions, the state of FPU is not protected by X86 ABI, so it is necessary to reset it for safety reasons.
yes, i know. but that's the thing i am willing to accept: calls to the external libraries should be properly checked and protected by the programmer, and there is no reason to resetup FPU each time we're calling component pascal procedure from another component pascal procedure.

besides, i left FPU reinit after external calls intact for procedures that are using FPU. as changing FPU control word is something majority of the existing code never do, it is mostly safe. the only exception is prolly Direct3D calls, but i'm going to wipe COM support from the compiler anyway, so the programmer should explicitly call `Kernel.ResetFpuState()` when interfacing with such broken libraries.

so i believe that removing such FPU initialisations is safe for well-written CP code. i will prolly add a warning to PSI about resetting FPU state after calling external libraries, though. and maybe i'll force FPU reset code in `[callback]` and `[ccall]` procedures too.


as for built-in assembler, you can easily port it to "mainline" BBCB, i believe. there is one new published procedure in DevCPL486: `GenLinkedAsm()` — it does fixups for the assembled code. you also need to export `ch` and `Number` from DevCPS; and search for `Nassemler` node type to find the other necessary compiler changes. i'm not finished with the thing yet, but it is already usable (and used in some places). you can create inline `<code>` procedures with it, "naked" assembler procedures (the compiler will not emit stack frame setup code), and insert asm code in "normal" procedures anywhere you like. currently, you can only access globals from the same module, and locals by their offset. accessing locals in nested procedures is not supported, and `CALL` to CP procedures is not supported too. i mostly need the asm to write optimised raster operations, so those limitations are not a big deal for me.

p.s.: the asm seems to support instructions up to (and including) SSE3 at least (and several SSE4 instructions are there too). it's more than enough for my needs.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 05 Март, 2023 20:52 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
дарю идею для стартапа. бесплатнобезрегистрациибезсмс. называется «детокс для наркоманов-компиляторщиков»: удобная комната с мягкими стенами, спокойная музыка и избиение табуретом за любую попытку открыть исходники любого компилятора. за «ну я чуть-чуть, только одним глазком!» — двойной табурет.

это, если что, та самая причина, по которой я не хотел лезть в компилятор. помните: завязавших авторов компиляторов не бывает!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 06 Март, 2023 13:19 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
размышления про растровые картинки. я всё думаю над интерфейсом для растров, чтобы можно было пикселями манипулировать. и прихожу к выводу, что для bottleneck надо два метода: `FillRect()` и `BlitScaled()` (оба с альфа-блендингом). это покрывает всё кроме быстрых градиентов. впрочем, если в `BlitScaled()` реализовать билинейную фильтрацию — то и градиенты тоже.

с другой стороны, для штук типа AGGLite всё равно будет иметь смысл реализовать низкоуровневый рендер (который сканлайны заполняет) в двух видах: референсный-портабельный и асм-оптимизированый. а вышеописаный bottleneck для большинства практических задач достаточен (по крайней мере, для моих задач).

идея пока такая: размеры растра при создании задаются в UC, HostPort приводит их к пиксельным, и рядом хранит unit (просто на всякий случай). при запросе размеров созданого растра в UC возвращаются пиксельные, умноженые на сохранённый unit. да, они могут немного отличаться от исходных — но это специфика растров и привязки к пикселам, ничего не поделаешь.

небольшая проблема в том, что чтобы создать растр, нужно иметь фрэйм и порт (райдер). то есть, создавать их придётся отложено, в первом Restore. я пока не уверен, нормально так, или стоит сделать прямой интерфейс к HostPort (ну, в смысле, абстрактный интерфейс создания растров, который HostPort реализует). с одной стороны, у фрэйма не обязан быть нативный дисплейный порт (печать, например, в другой порт идёт). с другой стороны — подобные растры нужны в основном для всякой динамической анимации именно на дисплее, а их печать скорее экзотика.

то есть, пока я вижу смысл и в отдельном интерфейсе «создать дисплейный растр» (видеоигори писать, например), и в интерфейсе райдера, который вызывается из Restore («а этот растр мы будем печатать»). они нужны для разных целей просто, хотя внутреннее представление растра сохраняется одинаковое.


ну да, я согласен, что в общем-то писать видеоигори лучше на OpenGL, но это имеет смысл делать вообще отдельной подсистемой, с независимым окном, и даже своим личным event loop. наверное. но простенькие игрушки типа какого-нибудь Lode Runner можно и чисто на растрах. конечно, и сейчас можно, если загружать графоний из png в существующий растр, но неудобно же.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 06 Март, 2023 14:59 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
и да, я по дороге (пока пилил асм) сделал дейкстра-форму циклов из оберона-07 в CP2. то есть, они от «моих» по синтаксису отличаются только наличием трубы перед `ELSIF`, так что я просто сделал трубу опциональной. мне лично с трубой больше нравится, красившее. в LOOP-варианте трубы остались обязательными, потому что там присутствует начальный `IF`, без труб компилятор усложнится, надо будет делать или look-ahead, или постанализ.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 06 Март, 2023 15:24 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
дарю идею для стартапа. бесплатнобезрегистрациибезсмс. называется «детокс для наркоманов-компиляторщиков»: удобная комната с мягкими стенами, спокойная музыка и избиение табуретом за любую попытку открыть исходники любого компилятора. за «ну я чуть-чуть, только одним глазком!» — двойной табурет.

это, если что, та самая причина, по которой я не хотел лезть в компилятор. помните: завязавших авторов компиляторов не бывает!

У меня есть идея давно прафилактория-санатория для программистов, где бы на Обероне программировали, восстанавливали психику.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 06 Март, 2023 15:33 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Денисов писал(а):
У меня есть идея давно прафилактория-санатория для программистов, где бы на Обероне программировали, восстанавливали психику.
но это же чистый садизм! во-первых, представьте мучения какого-нибудь жаваскриптера или питониста, если его заставить на обероне писать. а во-вторых, если он привыкнет и потом вернётся обратно «в мир» — ему опять придётся писать на жаваскрипте или питоне. двойной даже садизм, пожалуй, получается!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 06 Март, 2023 15:37 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
кстати. официально переименовал язык LC в Ultra Pascal (спасибо Фёдору Васильевичу за это название). потому что делать изменения в компонентном паскале нельзя, это торговая марка омиков, а описывать свои изменения как-то надо. правда, поскольку я использовал оригинальное сообщение о компонентном паскале как базу, то сообщение об ультрапаскале юридически нелегально. надо бы написать омикам и попросить разрешения, но мне пока откровенно лень. может когда-нибудь потом.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 06 Март, 2023 19:59 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
поднатужился — и убрал трубы из `LOOP … IF … DO … ELSIF … DO … END`. к сожалению, получилось грязновато, пришлось вклиниться в разбор IF — но фиг с ним. там можно ещё уменьшить количество копипасты, но не стану, пусть будет, чтобы было ясно видно, какая ветка за что отвечает.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 06 Март, 2023 22:16 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
arisu писал(а):
кстати. официально переименовал язык LC в Ultra Pascal (спасибо Фёдору Васильевичу за это название).

Я думал будет много Компонетных Паскалей, как Оберонов, а оказывается будет много Ультра Паскалей.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 06 Март, 2023 22:42 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
Иван Денисов писал(а):
У меня есть идея давно прафилактория-санатория для программистов, где бы на Обероне программировали, восстанавливали психику.
но это же чистый садизм! во-первых, представьте мучения какого-нибудь жаваскриптера или питониста, если его заставить на обероне писать. а во-вторых, если он привыкнет и потом вернётся обратно «в мир» — ему опять придётся писать на жаваскрипте или питоне. двойной даже садизм, пожалуй, получается!

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 06 Март, 2023 22:47 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Борис Рюмшин писал(а):
arisu писал(а):
кстати. официально переименовал язык LC в Ultra Pascal (спасибо Фёдору Васильевичу за это название).
Я думал будет много Компонетных Паскалей, как Оберонов, а оказывается будет много Ультра Паскалей.
очень уж мне название понравилось, грешно было не украсть.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 06 Март, 2023 22:50 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Денисов писал(а):
но надо ещё подтянуть, чтобы Блэкбокс на маке запускался всё же перед открытием такого санатория.
ну, старый 68к в эмуляторе взлетает, вроде бы, советская кидал скриншоты. исходники омики тоже давали, можно подтянуть под последний офрелиз. а что в эмуляторе — так это даже лучше, по-моему.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Вторник, 07 Март, 2023 17:09 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
поскольку анализатор кода — штука зело полезная, то обучил и её всяким новшествам. заодно потом впилил флаги «глобалы всегда считаются инициализироваными» и «заткнись по поводу неиспользованых аргументов».

на самом деле надо бы немного перепилить сам анализатор, чтобы он, например, не квакал «вложеная функция прочитала outer до записи в него», а сначала посмотрел внимательно. потому что сейчас он, похоже, сразу лезет во вложеную функцию — и, натурально, получается use before init. а надо лезть только когда в основной вызов встретился — тогда и правильные флаги будут готовы. то же самое и с глобалами, кстати.

то есть, сначала надо распарзить всё-всё-всё, а только потом начинать анализ; и делать его не по порядку объявлений.

а вообще, есть мнение, что некоторый анализ можно прямо в компилятор всунуть уже. его там не делали в своё время чтобы не тормозило, я так понимаю, и память не жрало. это уже неактуально. а обнаруживать простейшие «read unintialised value» можно и нужно. естественно, никакими не ворнингами, а полновесными еггогами.

с другой стороны, на такое есть стандартное возражение: «если добавить в компилятор проверки, и они не обнаруживают 100% случаев, то это хуже чем ничего: программист привыкает полагаться на компилятор, и пропускает что-то очевидное потом». ну, стандартный пример про «монтажников-высотников без страховочного пояса».

с третьей стороны — CP2 квакает, если в процедуре-функции нет ни одного RETURN. но спокойно затыкается, если есть хоть один, не пытаясь выяснить, все ли пути ведут к корректному RETURN. яркий пример того, что анализаторы авторы (ещё OP2) считали полезными, просто экономили на них ресурсы.

в общем, я считаю, что надо как минимум довести до ума проверку на наличие RETURN, и сделать «read uninitialised». кстати, второе позволит аннигилировать лишние начальные `p := NIL` по пути. то есть, компилятор сможет сначала потребовать, чтобы они были, а потом их просто поубирать. в итоге и красота, и немного эффективности.

делать это, натурально, надо отдельным модулем-анализатором (или даже несколькими), а не размазывать по коду парзера. 2023-й год на дворе, можно себе позволить несколько раз побегать по дереву.

конечно, это может поломать какой-то код (новые ошибки же!), но у меня всё равно Ultra Pascal теперь, могу себе позволить.

p.s.: имеет ли смысл создавать новую ветку для обсуждения нужности lint-style проверок непосредственно в компиляторе CP, или эту тему уже когда-то забили до смерти, и ну его?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Вторник, 07 Март, 2023 19:18 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
добавил экспериментальный линтер. пока что проверяет на наличие `RETURN` во всех ветках. он глупенький, и LOOP-циклы всегда считает конечными (и я так и оставлю, наверное). зато реагирует на HALT, поэтому после LOOP надо ставить `HALT(122)` (я спёр код 122 из зарезевированых). также он понимает, что `CASE` и `WITH` без `ELSE` трапаются, что считается видом возврата.

пришлось поправить два или три места в коде среды — как раз бесконечные `LOOP`, и пару мест в виндокернале, где выход через ассемблерный RET. то есть, тупо везде докинуть в конец `HALT(122)`.

скорее всего, в каких-то нодах я лажанул, но это выявим в процессе эксплуатации.

кстати, сразу оказалось полезно: нашёлся баг в движке регулярок: таки забытый RETURN, да.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Вторник, 07 Март, 2023 22:22 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
в общем, где-то в этом районе вроде бы допинал линтер, и убрал то недоразумение, которым CP2 пытался эмулировать проверку на наличие RETURN. анализатор ещё не поправил, правда: надо оттуда тоже выкинуть, и тоже тупо позвать линтер.

линтер теперь понимает простейшие бесконечные циклы (LOOP без EXIT, WHILE TRUE, UNTIL FALSE), и не требует в них RETURN. обычно это main loop, и там действительно никаких RETURN не надо.

также: когда анализатор видит ассемблер, то сразу сдаётся: асм в принципе отрубает любой анализ.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Среда, 08 Март, 2023 11:13 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
в общем, с анализатором перменных всё несколько сложнее: реально надо писать полноценный проход с заглядыванием в вызываемые вложеные процедуры, иначе пичаль. штука ещё и в том, что надо вызывать анализатор из top-level уже, а не сразу по окончании парзинга блока, а я в блок засунул. один баг в своём коде я этим поймал, конечно, и наловил кучу false positives. но в принципе — основа заложена, её можно рихтовать потом.

блин, в SSA с этим всем делом значительно проще (хотя и там проблемы с nested procs).


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 649 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 33  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB