LINUX.ORG.RU

Вышел FreePascal 2.4

 , ,


0

0

FreePascal — это кросс-платформенный, свободный компилятор и библитека RTL языка pascal.

Добавлены новые платформы:

  • 64-бит Mac OS X (x86_64/ppc64)
  • iPhone (Mac OS X/Arm)
  • Haiku
  • Улучшена поддержка ARM EABI

Некоторые изменения:

  • файл ppc386.cfg больше не используется;
  • переменные Absolute теперь поддерживаются;
  • добавлено выравнивание для переменных типа record;
  • добавлены типы Byte/Word/Long/Qwordbool;
  • все старые модули сокетов для версии 1.0.x были удалены.

User changes

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: alexsaa (всего исправлений: 3)
Ответ на: комментарий от anonymous

Если интерфейс будет один, то зачем отделять то?

некорректная формулировка: не «будет один», а «планируется один»... а заказчик через полгода после сдачи придёт и скажет «ой, а нам тут надо другой интерфейс» и что, будете всё переписывать?

shty ★★★★★
()
Ответ на: комментарий от anonymous

anonymous> Если интерфейс будет один, то зачем отделять то?

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

Лично я делаю всегда так: Сначала пишу консольную программу, и только потом, если есть надобность, рисую к ней морду. Этот способ отлично оправдывает себя. В результате и отладка кусков кода быстрее и удобнее, и добавление возможностей проще.

Quasar ★★★★★
()
Ответ на: комментарий от shty

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

anonymous
()
Ответ на: комментарий от Quasar

Давайте проверим работоспособность вашей технологии и напишем, например - калькулятор.

anonymous
()
Ответ на: комментарий от Quasar

>Сначала пишу консольную программу

Про разделяемые библиотеки ты конечно не слышал.

anonymous
()
Ответ на: комментарий от anonymous

anonymous> Оценить вероятность множества интерфейсов к одной программе можно просто посчитав кол-во программ с различными видами интерфейсов. Их колличество ничтожно, стало быть и вероятность такого исхода событий мала. И вообще такие вещи нужно оговаривать с заказчиком заранее.

Ужасно глупое суждение в своём корне.

Относительно интерфейсов - зависит от поставленной задачи и заказчика. И вероятностью оценивать это глупо.

Например, есть мелкая конторка с офисом в 4 компьютера. Нужна им простая система автоматизации части их работы. Тут на количество интерфейсов плевать.

Теперь возьмём крупную контору, которой нужна система автоматизации части деятельности. Имеем: филиалы конторы, каждый со своим офисом; огромный документооборот; в сами офисах компьютеров не меньше 10; необходима удобная связь с остальными частями конторы; необходима связь с СУБД FireBird или Oracle, а то и DB2; и т.д.
Вот тут уже придётся хорошенько думать: скорее всего понадобится несколько интерфейсов - оконный локальный интерфейс, вебморда, может для мобильников на жабе захотят простенький и т.д. И даже паскаль тут идёт лесом.

Quasar ★★★★★
()
Ответ на: комментарий от anonymous

anonymous> Про разделяемые библиотеки ты конечно не слышал.

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

Quasar ★★★★★
()
Ответ на: комментарий от anonymous

anonymous> Давайте проверим работоспособность вашей технологии и напишем, например - калькулятор.

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

Quasar ★★★★★
()
Ответ на: комментарий от anonymous

Давайте оценим вероятность такого исхода событий.

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

И трудозатраты на оба варианта.

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

И вообще такие вещи нужно оговаривать с заказчиком заранее.

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

даже в идеальном случае заказчик потом может придти и сказать «мне нужно чтобы теперь это было так, сколько Вы денег за это хотите?»

и мне лишний гемор в таком разе ни разу не нужен... я лучше сразу сделаю чтобы мне было легко и быстро ведь время - это тоже деньги...

короче курите паттерн mvc

shty ★★★★★
()
Ответ на: комментарий от Quasar

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

Или пишешь оконный и ставишь на терминальный сервер.

Или пользуешь 1С 8.2 и получаешь локальный оконный интерфейс и Web интерфейс.

Вообщем зачем отделять интерфейс в вашем случае не понятно.

anonymous
()
Ответ на: комментарий от anonymous

anonymous> Вообщем зачем отделять интерфейс в вашем случае не понятно.

Например, для повышения производительности и масштабируемости вынести логику в отдельный сервер, а сам интерфейс реализовать на стороне.

Quasar ★★★★★
()
Ответ на: комментарий от shty

С заказчиками общался и не раз. Они понятия не имеют о видах интерфейса. Для них главное чтобы работало.
Трудозатраты разные и зависят от уровня абстракции.
Чаще mvc только увеличивает код, и не способствует его эффективности, при этом не добавляет возможности получить доп. вид интерфейса.

anonymous
()
Ответ на: комментарий от anonymous

С заказчиками общался и не раз. Они понятия не имеют о видах интерфейса. Для них главное чтобы работало.

так а что тогда на заказчиков киваете?

Трудозатраты разные и зависят от уровня абстракции.

эммм? Вы в трудозатраты что включаете?

Чаще mvc только увеличивает код, и не способствует его эффективности, при этом не добавляет возможности получить доп. вид интерфейса.

1) чаще чего?

2) «пошли дурака молиться - он и лоб расшибёт» (с)

shty ★★★★★
()
Ответ на: комментарий от Quasar

>Например, для повышения производительности и масштабируемости вынести логику в отдельный сервер, а сам интерфейс реализовать на стороне.

Для этого уже есть СУБД. И не нужно заново изобретать mvc;
Для этого уже есть веб сервера. И не нужно заново изобретать mvc;
Для этого уже есть терминальные сервера. И не нужно заново изобретать mvc;

anonymous
()
Ответ на: комментарий от Quasar

>Для моих нынешних задач вынос функций в библиотеки не имеет смысла

А как же ты собрался гуй писать? Неужели через pipe дёргать?

Плюс сначала проще сделать работающую программу, и только потом решать, что и куда.

Конечно, пока сделаешь парсинг выхлопа, то на другое времени не остаётся :D

anonymous
()
Ответ на: комментарий от anonymous

>Например, для повышения производительности и масштабируемости вынести логику в отдельный сервер, а сам интерфейс реализовать на стороне.

Для этого уже есть СУБД. И не нужно заново изобретать mvc; Для этого уже есть веб сервера. И не нужно заново изобретать mvc; Для этого уже есть терминальные сервера. И не нужно заново изобретать mvc;

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

shty ★★★★★
()
Ответ на: комментарий от shty

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

В трудозатраты я включаю время работы программистов.

чаще чего?

«пошли дурака молиться - он и лоб расшибёт» (с)

т.е по существу вопроса возразить нечем.

anonymous
()
Ответ на: комментарий от anonymous

anonymous> А как же ты собрался гуй писать? Неужели через pipe дёргать?

1. Наворотить над уже имеющейся программой прямо в коде (функции есть - осталось поставить GUI)

2. Если уж совсем много - в отдельную библиотеку вынести. Но то, что я сейчас пишу, не такое большое.

Quasar ★★★★★
()
Ответ на: комментарий от anonymous

Ну... тут вопрос такой... MVC для клиента - пустой звук, для разработчика, особливо, стороннего - способ быстрее разобраться с кодом... Хотя и лажа бывает. Например, dotnetnuke - сколько модулей под него напейсано, столько и «видений» MVC :)

impfp
()
Ответ на: комментарий от anonymous

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

не надо ляля, вот Ваша фраза:

И вообще такие вещи нужно оговаривать с заказчиком заранее.

и следующая:

С заказчиками общался и не раз. Они понятия не имеют о видах интерфейса. Для них главное чтобы работало.

не ощущаете пресловутого диссонанса?

В трудозатраты я включаю время работы программистов.

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

shty ★★★★★
()
Ответ на: комментарий от anonymous

> «пошли дурака молиться - он и лоб расшибёт» (с) т.е по существу вопроса возразить нечем.

это вполне по существу, или расшифровать?

shty ★★★★★
()
Ответ на: комментарий от Quasar

Вот видишь? Интерфейс будет уже отделён от логики.

От бизнес логики.
Или логики работы интерфейса?
Или логики обработки данных?

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

Использовал готовые библиотеки php?

Использовал готовые СУБД?



anonymous
()
Ответ на: комментарий от Quasar

>Наворотить над уже имеющейся программой прямо в коде

А как же принцип «гуй отдельно»?

anonymous
()
Ответ на: комментарий от shty

не ощущаете пресловутого диссонанса?

Не ощущаю. В договоре и ТЗ необходимо прописать все что заботит исполнителя и заказчика.

из каких составляющих состоит это время

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

anonymous
()
Ответ на: комментарий от anonymous

Не ощущаю. В договоре и ТЗ необходимо прописать все что заботит исполнителя и заказчика.

конечно не ощущаете, поэтому и пытаетесь указать мне на то что в ТЗ надо прописать вещи которые «заказчика не заботят», более того, вещи о которых заказчики «понятия не имеют»... ещё раз: в общем случае, Вы ошибаетесь

> из каких составляющих состоит это время

Из производительных и непроизводительных затрат.

Производственных и непроизводственных Вы имеете в виду?

Ну что, я так и думал... Вы не рассматриваете трудозатраты на ведение проекта, что очень плохо. Со временем будут накапливаться ошибки которые придётся устранять, и не говорите мне что при «правильном программировании» ошибок не бывает, я не видел ни разу проекта без ошибок, коль скоро он сложнее банального «калькулятора».

Разделение модулей банально позволяет изменять одну часть проекта не трогая другую, что очень ВАЖНО, так как порой регрессионное тестирование проекта целиком может занимать значительное время.

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

ололо, а ведь Вы и правда ведь расшибёте лоб если Вас послать... ещё раз из практики: использование паттерна mvc позволяет существенно упростить ведение проекта (если его использовать с умом конечно)

shty ★★★★★
()
Ответ на: комментарий от Quasar

И? На fpc можно сделать и локальную морду, и веб-интерфейс (в lazarus - с мышевознёй, аяксом, блекджетом и шлюхами - http://code.google.com/p/extpascal/ - даже завёл на локалхосте, пока не баловался особо ^_^), вот только с мобильниками проблема... Кстати, когда пришлось - на яву не заморачивался, а тупо сделал простенький сайтик и встроенными браузерами на него заходил ^_^ Сайтик, опять же, - cgi модуль на fpc ^_^ Правда в конечном итоге решили, что не нужно ^_^

anonymous
()
Ответ на: комментарий от Quasar

Ха! Классно пишется сначала консольная программка, чтобы потом там же графику делать :-D Смысл, если можно всё и сразу, просто в разных модулях? Или, ах, гуй сразу делать сложно, поэтому вначале получаем результат, а потом начинаем пыхтеть над тем, что в удобных IDE решается «мышевознёй»? :-D

И в чём проблема реализовать разделение гуя от логики программы в lazarus? ^_^ Напротив - графика делается в графическом режиме, с button'ами и actionlist'ами, и в ActionXExecute проверяю, что ввёл пользователь, а результат потом «отправляю» в «рукописные» обработчики, вынесенные в другие модули ^_^ Да и консольную отдельно написать можно, только зачем так извращаться? ^_^ И, о Боже, даже библиотеку 0.о Я вот держу несколько unit'ов, связаных друг с другом, которые таскаю из проекта в проект (на линуксе - тупо симлинками :-D)

anonymous
()
Ответ на: комментарий от anonymous

> Ха! Классно пишется сначала консольная программка, чтобы потом там же графику делать :-D Смысл, если можно всё и сразу, просто в разных модулях?

я посмотрел бы, как твоя гуёвая программа обрабатывала бы данные в фоне на сервере, где просто нет иксов...

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

Для серверов - без вопросов... Но пишется отдельно ^_^ И гуй к ней, опять же, свой и общение уже по TCP реализовывать - но это отдельная задача. А писать приложение изначально гуёвое, но так что сначала консольную прогу с логикой, а потом к ней прикручивать графику... Может и хорошо в плане тестирования, но извращение ^_^ А «Ха!» было к тем двум вариантам Quazar'a, которые уже всякий смысл от консолеписания сводили на нет :-D

anonymous
()
Ответ на: комментарий от anonymous

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

korvin_ ★★★★★
()
Ответ на: комментарий от shty

По поводу ТЗ и интерфейсов - забавный случай был ^_^ Попросили в маркетинговом сделать для них программку, а я занят был, сказал - «Ну, несите ТЗ, там посмотрим» ^_^ Принесли - папку с кучей рисунков форм и «рассказами» - что будет, если нажать ту, или иную кнопку :-D Как потом оказалось - пришлось даже с магнитными картами дисконтными учиться работать ^_^

anonymous
()
Ответ на: комментарий от korvin_

Для каких-то «фундаментальных» вещей, навроде mplayer, mpg123 (только с мультимедиа так связывался, так что примеры другие сложно привести ^_^) - да, конечно... Да и ладно, вообще соглашусь - не извращение ^_^ Но, повторюсь, на fpc (и Lazarus) такое реализовать тоже легко и удобно.

Лично мне хватает разделения гуя и логики по модулям в одном проекте. По-крайней мере, когда пришлось вернуться к проекту после года отсутствия (армия ^_^) - полностью (т.е. удалил старую форму и создал новую) изменить внешний вид программы удалось меньше чем за день, с сохранением всего функционала (просто не трогал остальные юниты).

anonymous
()
Ответ на: комментарий от shty

более того, вещи о которых заказчики «понятия не имеют»... ещё раз: в общем случае, Вы ошибаетесь


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

Вы не рассматриваете трудозатраты на ведение проекта.

Естетсвенно, я ведь для вас не тренинг по управлению проектами провожу.

Со временем будут накапливаться ошибки которые придётся устранять, и не говорите мне что при «правильном программировании» ошибок не бывает

Вы телепат?

ещё раз из практики: использование паттерна mvc позволяет существенно упростить ведение проекта


Вы мне этим паттерном mvc тычете, как будто его использование решит все проблемы. Давайте расскажите как он поможет при написании калькулятора. Какие преимущества такой подход дает модулям Moodle в которых приходится через атрибуты одного класса передавать данные другому классу визуализации.

ололо, а ведь Вы и правда ведь расшибёте лоб если Вас послать...

Снова телепатия?

ещё раз из практики: использование паттерна mvc позволяет существенно упростить ведение проекта (если его использовать с умом конечно)


Я не против mvc в принципе. Естественно её (модель) нужно применять с умом. Речь шла об отделении интерфейса от реализации, о том что этого избегать нелья. Я говорю о том, что в некоторых случаях можно. А в других о этом за вас позаботились разработчики библиотек Qt или VCL. К тому-же часто читал на ЛОРе о том что такое разделение якобы легко позволяет реализовать различные виды интерфейсов (web, WIMP). Это не так. Это сложная задача, которая под силу далеко не всем командам разработчиков. И примеров реализации этой идеи исчезающе мало. Тратить время на реализацию этой идеи глупо, эсли вы не разработчик мега GUI библиотеки.
<telepat>
И не нужно думать, что код моих программ состоит из одной функции
в одном модуле. Или из одного класса. Или что мне не известны способы
распределения работ между исполнителями.
</telepat>

anonymous
()
Ответ на: комментарий от anonymous

Теперь я понимаю почему ваши заказчики могут менять задание на ходу.

Ну что Вы Равшана с Джамшутом от программирования изображаете? ТЗ могут меняться в силу разных обстоятельств, не всегда зависящих от меня или даже от моих заказчиков. В таком случае ТЗ мне помогает описать изменения которые необходимо будет внести в проект и обосновать стоимость и перенос сроков. И по результатам переговоров, коли заказчик доволен, составляется дополнение к ТЗ. Так понятнее?

> Вы не рассматриваете трудозатраты на ведение проекта.

Естетсвенно, я ведь для вас не тренинг по управлению проектами провожу.

Тренинг как раз для Вас просто необходимо провести в связи с демонстрируемыми подходами и пониманием.

Я не против mvc в принципе. Естественно её (модель) нужно применять с умом.

конечно, тут договорились :)

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

А где я на это возражал?

А в других о этом за вас позаботились разработчики библиотек Qt или VCL.

эммм... здесь не согласен, даже с использованием этих библиотек (а уж использование бывших borland'овских продуктов вообще подталкивает к этому) спокойно можно писать «некошерный» код, который потом придётся долго распутывать

shty ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.