OberonCore https://forum.oberoncore.ru/ |
|
Сделаем процесс написания кода более удобным... https://forum.oberoncore.ru/viewtopic.php?f=1&t=95 |
Страница 1 из 1 |
Автор: | Темиргалеев Дмитрий [ Среда, 11 Январь, 2006 20:18 ] |
Заголовок сообщения: | Сделаем процесс написания кода более удобным... |
Очень просто реализуемое и, на мой взгляд, нужное предложение. При написании модулей часто сталкиваешься с тем, что большой объем кода затрудняет поиск и приходится некоторое время «прыгать» по программе. Поэтому предлагаю помещать разработанный и уже отлаженный код между закладками. При этом между закрытыми закладками можно вставлять краткое описание процедуры. Если процедуры оформлены данным образом, с модулем приятно работать (из личного опыта). Есть один недостаток. Если в закрытой вкладке происходит ошибка, то чтобы ее найти приходится вкладки открывать самому. Поэтому оформлять следует только отлаженные процедуры, причем после компиляции будут закрыты те вкладки, которые помечены символом @, а остальные останутся открытыми и компилятор их как бы не заметит. Я реализовал это следующим образом. В Dev\Mod\Compiler.odc процедуру Do добавлены следующие строки: PROCEDURE Do (source, log: TextModels.Model; beg: INTEGER; opt: SET; VAR error: BOOLEAN); VAR s: TextMappers.Scanner; BEGIN Dialog.MapString("#Dev:Compiling", str); StdLog.String(str); StdLog.Char(" "); s.ConnectTo(source); s.SetPos(beg); Scan(s); WHILE (s.type # TextMappers.eot) & (s.type # module) DO Scan(s) END; IF s.type = module THEN Scan(s); IF s.type = TextMappers.string THEN StdLog.Char('"'); StdLog.String(s.string); StdLog.Char('"') END END; StdFolds.ExpandFolds(source, TRUE, ""); sourceR := source.NewReader(NIL); sourceR.SetPos(beg); Module(sourceR, opt, log, error); StdFolds.CollapseFolds(source, TRUE, "@") END Do; Так же нужно не забыть добавить в список импортируемых модулей модуль StdFolds. Как видим, перед компиляцией модуля все вкладки будут открыты, а после нее, будут закрыты лишь те, которые помечены символом @. Если совсем понравится, можно сделать дополнение и оставлять открытыми те вкладки, в которых произошла ошибка. Большая просьба, если кто-нибудь пользуется какими-либо способами, облегчающими написание кода, расскажите. Например, я написал пару процедур, которые по Crtl+1 комментируют выделенный текст с применением соответствующего стиля, а при нажатии Ctrl+2 восстанавливают исходное состояние. Это делает процесс программирования проще, пусть совсем чуть-чуть. |
Автор: | Илья Ермаков [ Среда, 11 Январь, 2006 21:02 ] |
Заголовок сообщения: | |
Вызывает интерес твой технический прогресс... Вообще говоря, можно бы собрать пакет inetlligence for BlackBox - со всякими такими примочками. Хотя... Intelligence - дело вкуса, и в ББ здорово именно то, что каждый за пять минут может дописать такие вещи именно так, как ему нравится. |
Автор: | Иван Горячев [ Четверг, 12 Январь, 2006 00:30 ] |
Заголовок сообщения: | |
Лучше не надо лазить в компилятор. То же можно было сделать в Menus.odc - "Intelligence.OpenFolds;DevCompiler.Compile;Intelligence.CloseFolds;" - и волки сыты, и овцы в будущем на грабли не наступят |
Автор: | Темиргалеев Дмитрий [ Пятница, 13 Январь, 2006 23:23 ] |
Заголовок сообщения: | |
Я сначала делал через меню. Но потом мне понадобился DevCompiler.CompileThis и пришлось вставлять код в компилятор. |
Автор: | Иван Горячев [ Суббота, 14 Январь, 2006 03:30 ] |
Заголовок сообщения: | |
Тогда написать свой модуль-обёртку над DevCompiler. Потому как иначе Вы замучаетесь править новые версии компилятора (а такие будут, и есть подозрение - довольно часто) |
Автор: | Евгений Темиргалеев [ Пятница, 01 Сентябрь, 2006 02:03 ] |
Заголовок сообщения: | |
Продолжу тему. Тоже считаю удобным при разработке большого модуля, скрывать уже законченные процедуры 0 уровня или вложенные. Читабельность повышается, алгоритмика более понятна. Привожу модифицированную версию. Складки с заданной меткой открываются перед компиляцией, закрываются после, если не было ошибок (изменение DevComplier). Изменен DevDebug - чтобы перед переходом к коду из окна трэпа складки также раскрывались. В этой версии есть минус - с точки зрения элегантности подхода. Работа со складками ведет к обширным изменениям в модели, которые отображаются во временном файле; а сворачивание/разворачивание происходит при каждой компиляции, которые обычно выполняются часто Как вариант - разработка специального считывателя для модели, который будет использоваться во время компиляции и будет выдавать только скрытый текст из складок кода, не зависимо от их состояния. Но это требует довольно серьезной проработки... Ivor писал(а): Лучше не надо лазить в компилятор. К сожалению без этого никак нельзя получить требуемую функциональность малой кровью - чтобы разворачивание/сворачивание складок работало для всех процедур компиляции.Ivor писал(а): Тогда написать свой модуль-обёртку над DevCompiler. Модуль-обертку также не вот напишешь. Чтобы это сделать для каждой процедуры компиляции - придется передирать около половины DevCompiler, которая отвечает за выявление "того, что требуется компилировать".
Чтобы не наступить на грабли, использую такой подход: базовая версия Blackbox стоит отдельно. А все свои модификации Dev..., и прочий рабочий код лежит одельным профилем. И если что-то вдруг пойдет косо, достаточно удалить в профиле соотв. кодовый файл. Кстати, прикол. Нашел интересный концептуальный "баг". Попытка выгрузить DevDebug завершается крахом И действительно, процедура выгрузки лежит в DevDebug, модуль "выгружает сам себя", после чего идет несколько трэпов... Т. е. DevDebug либо не должен выгружать себя, либо должен быть предусмотрен какой-то особый механизм. Собственно сам модуль: MODULE WorkCodeFolds. Код: PacCoder.Decode /.5gBa1H6QW0T4yU6DY3bX9H41e1O181Q1cFn6L2IzYN0Ug:NxsU.d0.pG3kjPqNEkoB7HEtE.VK
zgVrR.sIzkGb/yHkyVSxjXImU4/gc3kXzk/Y/qy.wYrY3Zy0gY5PXWm7g6QUP26RljysJCO28Z00 162ILZga66D7.0SwY5GU3FctUGdh1VivKzOh/IjES22B2IHHBcUtcpY49O6BYHru.24J7qcFNcFS 1GFu0Mt0/Nc:EY66B.l5t1c.ro45c/qU8Qdo.zp:pOzXZa.i0V0Mc8o2Uut1V/:I.Osg6GH/2sH/ 1H/0rg2JMUVW7/.9sEIVHu0YyLReybc1Fi5jEZSYQi8bcj9s4ZujGt9LXo0BtQi9Yrc2fBRYx9Xx we:zpn6SYF13JTc.wprcCBrpbz4kj9u:i8L29oQrc05OSUPqrG2JPZNzEX5nrBaZi/LfZ4g:vW7u 7c9ZazE4/LcYRkPLLRsIOYsfC.RtlqsSPtq/3l3ydQF9eemvlGbyWj/E3SDWwjau4w3Xcw3BasPB o:iPbzP3mPVsj.uKtV.TemhisPUe9diX5.y52zBi28Q0mr4V.pi4hrPWq4p9f6wBkcSasERuhlqR /dBlkxx:yGIgr0YmMPWUr36ytg/HQJTPvWf.O0Tc/MMJVi3bsSHQNqsRHgj/aKr1isylqkb2ZC7l xdWWDsyzDn6HHuyvoDLoeuGKkzHh2giKDY6EO7t0NJmRIFdK9BpKPsM:Fu5Ww4sjBwxj9ebMsvKr PyLNltSEfnswVf04pMi0vZ3D3FttvR4NrYWJrbzWOFGM:enHVXCDO1BM.VFksBBKgTlREFREFccB XqZ4Yhs9x3RyQ0Ib/VzPo3Yw0DvD/ijxM0T9diDWJJuzhiQR5tNJ8DJomcY:eFl7Zbfr:Su8GcnL J75u09zMpEYL0zSy4WKMkwywkNRKeHRf9Q02g2qecQ2ttoTak3uMK3pq:XRrdcB0R9WmkShsxWCb 9bcmm2eXg.dYsrFcJ7LneWZehQGaoIu76kUw8eWX3:Zsgue9ukm2U2U2GTaWQH6rVlXaKYtOoBzp e9MMUzLTDJ23W2fdYHwm9Q2c3QN8a9QL5pO.Gouc2dUzGJ/p1gya76YTLZqxyzLiiHV5q1ZQo0CH KsYB6NrouG9HUUv1C57:p.lTcizVama5NjxgSdEBWvvcdDRuQn3xr4JiCXlN4fvWtXvWSyqsfV3B QTu8wJk1hHvGbRFYCvU9XQKZl4lIdkt/orae5vXJa7bO97.XynIzvW4/XIGxxFP9dh24Ctn0ZUI1 qYoROSyfvr.cT6/UcM0PWyzBofzV8YMRHasO/ZJYxts0Kn94fMBKjSN7Eh:Z15FzCDassl89yx8y TOIWsFr4E9b8Ntvp/5O:jp0gze4NNKF.Th:jqFUdo0wRkqvfr9Bi8DQKUj8ZSsqC3tMjPdhByLQh de:Z5dCZi5haHr4rms7kWz8Ip7r9oR1oXHm0U8y0y9NEI1KtZ.2wTPGrxoFm/M5xiX7mIN7RdYEw McwvKa09Jize5kTSJWs69odsXzbx6pH.iIUX7wYNTO9UaxQz0822ubcRKKfvkQqU8XV9p5BG4OM7 sraDBZLiTjJ3azdV1FuIj6JzOG0OyNbbSj:q67uuoT:M7xcQ5Sh4JCQUbzg7dQCKq/SY34nCKHrn cm.JCl3hweg4tdL:Cf0HRoLzFU8cDHpeB:qRvJ194Ev/MUV1l3X:eS3BoK4xSwXwfeffIz9NEHOZ XPMkSzW/ySHydqlI.B1Jr6IzulWpMoUajukPFuJD6G3KZWv3e/vHoeyXxfDhhg4N4v9ysfQr2zc9 GQwm66JZ9BbjP668rZjTJH8QlmVxQ4TQRrwsC6DfoPR66:YZHHUp:LWV/1Vt2/DhePnoaaFpyqjx H8:BpgToBIfRwnZugO3YULjMhactmYpNm/k6J21bpb:4uFdFICz9:1gEntQBX8vjRY2FhyS2ECnk 9pDYJm6a6HGECt1868TcyKW9Y1Fl1Y1Zgw7rvKNhIvFvqipixL18OVgho:Ssx2fPZ15q6Ry.pq.: .XgNhhShOtVcdtaBc58BDnoXtDR4l0LvwxBtcOS3Vr4LxtbloxbFviWnRj1XVljFYR44WSwYqx0j kajjZ.54OwwncJy:e3ltcjVSD/z4jg5kZpm2NVfbYorfjgVGzdLiLPvSHD:153FaqHr5Ixjgo2Gz NbS2agawIpdjxo9RaJOieukq36Vm9tEXr9lIrOSmKUmsfi1YPYyVxsW:p/yWhwEILKtOdkHL:qpf Lj8ZpSioZt4iBys/xsag90GSHnf9ImnD6minbLNq9gtJqRiYnWLNoTEHjEQz6Cfgt3qRNRtGfgs1 bCRl5Cvi0MtnjQnn33wsuQsjEdnickCRxV7KmNiQmxsNdSZHlniy89jfq5nZ1nN346CRv1Y7/stq NgHXC/OGF5YGkdP5CzDazI2nRhR7.wqxBdTSBpfRLt8SlRWGwvEclTe3ryPUyQv3NxrsBg/jl5Cu zQaxCTvd.CX1bSjaIBQtrmavvfgKIQHy1S43.ue3n6MVl/Sr47TEIxTr4xyV48vILS4e7ofvwxBC UqDnST3wTU9vJKywiJa9WFOzjjD2T:IroSOmDxofbLX:uwwDZYM2wX3FomPd9XrC9sBIxm3y6rbS :lHWZ68BrktXrvfcLloSodWe/g/jsrxJfGHiz4sy77oDW7s3qDiB9dvBxkfnSqQV3jZVLdjwGbOX thmoa59O3VZd3W1rs4u7jdzKpv4iq0Fg4jWjxNu/dFPZv8b4MfLTdtNTX4LqX1lpoD4DNY7:uNmO bQkrP8GMY2rCU2RrkbZCXh4C4iwciL6inf.1PnjpYGiSgtyJi5Ugd8toN:NoVDw/HeydPcOpr8j1 kRPRl2bfnsQN1PSvvgmPtoSvh8sdZrr7a/EJXjtQrFvvs3PNYs5SMnagpvfjuOiQwZI8lZphtVPY limYJ:sRIqHdhtpX1cYppT0CbhUpooiscUw6vcrv9kv3tgf847TKckk4PE3SmxYRzuYLs3r6vH.b W7UIO/yO3FIWwzWPzYk.t.p6K62ch:FS2DLgiJQY/6iev23.jstG/rxaPkbbMxLLoZ/UWOmBi89C XJrPLIa8XMBgfOjG:oprjxFa4r2ED7rM:9HfFywVV/.gNFCraxbiJX8XutfCFG95Ljx5S4FC1au3 X7Qqn7ootxTqsWnogNBJpPP/buXvBbUPW0TD4or27BebO.isYmOgvWBKiywqYaHcdcaDQsvWFW2m .D8T4xlDUzkDSKmrRKiFanybK:hV7mQhbTrBqnUyejJ2qvn/BOry6nIOW/KDzp:7kicZ/GOWH/O4 cjzzs. AtEndOfEncoding |
Автор: | А.П. [ Пятница, 01 Сентябрь, 2006 07:01 ] |
Заголовок сообщения: | |
Евгений Темиргалеев писал(а): Продолжу тему. Тоже считаю удобным при разработке большого модуля, скрывать уже законченные процедуры 0 уровня или вложенные. Читабельность повышается, алгоритмика более понятна.
Привожу модифицированную версию. Складки с заданной меткой открываются перед компиляцией, закрываются после, если не было ошибок (изменение DevComplier). Изменен DevDebug - чтобы перед переходом к коду из окна трэпа складки также раскрывались. В этой версии есть минус - с точки зрения элегантности подхода. Работа со складками ведет к обширным изменениям в модели, которые отображаются во временном файле; а сворачивание/разворачивание происходит при каждой компиляции, которые обычно выполняются часто Может, я неправильно понял. Но мы используем складки для ВРЕМЕННО НЕНУЖНОГО или альтернативного кода, компиляцию которого запрещаем! Мне кажется, идея авторов компилятора была именно в этом! Метка перед складкой - это же новая языковая конструкция, чего нельзя допустить!! Возможно, следует ввести складки ВТОРОГО РОДА с другими стрелками, содержимое которых всегда компилируется и вставляется в объектный код... А разве механизм импорта модулей и возможность создания папки проекта (или подсистемы) не то самое, что предназначено для разработки именно больших программ из многих модулей/процедур?? Отладил процедуру - перенеси ее во внешний модуль, откомплируй его, подправь вызов ее в головной программе и "забудь". Конечно, несколько продолговато получается, но, тем не менее, стОит ли новый огород городить? |
Автор: | Евгений Темиргалеев [ Пятница, 01 Сентябрь, 2006 08:50 ] |
Заголовок сообщения: | |
А.П. писал(а): Метка перед складкой - это же новая языковая конструкция, чего нельзя допустить!! Я имел в виду не какую-то метку в тексте перед складкой; метка - свойство самой складки. Обычные складки с конкретной текстовой меткой мы считаем складками кода. Только они и разворачиваются до компиляции и сворачиваются после. Фактически метка в складке и выделяет ее как "складку ВТОРОГО РОДА"; я согласен, что создание отдельного отображения - более элегантно, но и более долго .Возможно, следует ввести складки ВТОРОГО РОДА с другими стрелками, содержимое которых всегда компилируется и вставляется в объектный код... Цитата: А разве механизм импорта модулей и возможность создания папки проекта (или подсистемы) не то самое, что предназначено для разработки именно больших программ из многих модулей/процедур?? У модуля несколько большее предназначение, нежели просто разбить один большой исходный документ на много маленьких. В частности если Вы описываете некоторое сложное понятие (напр., арифметика многократной точности) для которого вводится сложный тип данных и набор процедур для обработки, то обычно будут присутствовать закрытые процедуры и поля записи, к которым из ДРУГИХ модулей не обратишься...
|
Автор: | Илья Ермаков [ Пятница, 01 Сентябрь, 2006 13:06 ] |
Заголовок сообщения: | |
По поводу выгрузки DevDebug... Есть ряд модулей, которые ничем не импортируются, а загружаются явным Kernel.Load. Они инсталлируют фабрики и хуки в ядро или модули каркаса. Поскольку счетчик ссылок импорта для таких модулей нулевой, то среда позволяет их выгрузить. Однако при первой попытке обращения к фабрике или хуку будет треп... |
Автор: | Trurl [ Пятница, 01 Сентябрь, 2006 13:34 ] |
Заголовок сообщения: | |
А.П. писал(а): Но мы используем складки для ВРЕМЕННО НЕНУЖНОГО или альтернативного кода, компиляцию которого запрещаем! Мне кажется, идея авторов компилятора была именно в этом!
Использовать можно по-разному, но идея точно была не в этом. В Oberon V4, от которого произошел BlackBox складки автоматически раскрываются при компиляции. |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |