Цитата:
Про Mobile Studio от Эмбы ничего печального.
эх, ты не понял мой сарказм
» Вопросы по Embarcadero RAD Studio XE3
Цитата:
эх, ты не понял мой сарказм
здрасьте. ВОзможно ли в версию стартер запихнуть компонент XmlDocument со страницы интернет?
Цитата:
может FastMM обновить ?
нет, проблема с атрибутами в FastMM с sf.net в 64-разрядном остается
а багу на SF повесил ?
XE3 мне не нравятся - не работает FIBPlus
Добавлено:
На треккерах его тоже хают
Добавлено:
На треккерах его тоже хают
Цитата:
а багу на SF повесил ?как бы. Но этот проект с сентября не обновлялся. Что-то не верится, что исправят скоро. Да к тому ж эта проблема еще на xe2 была.
Добавлено:
Цитата:
XE3 мне не нравятся - не работает FIBPlus
Добавлено:
На треккерах его тоже хают
что бы это значило?
Здравствуйте!
Перешел с XE2 на XE3, в настройках вроде ничего не трогал.
(только выставил: Editor Options - Code Insight - Auto invoke = True)
Возможно конечно, случайно в настройках что-то тыкнул, не помню..
Сейчас вот заметил, что окно "Structure" (верхнее, слева) - пустое, когда я во вкладке "Code".
Как сделать так, как было по умолчанию в XE2 и прошлых версиях?
Перешел с XE2 на XE3, в настройках вроде ничего не трогал.
(только выставил: Editor Options - Code Insight - Auto invoke = True)
Возможно конечно, случайно в настройках что-то тыкнул, не помню..
Сейчас вот заметил, что окно "Structure" (верхнее, слева) - пустое, когда я во вкладке "Code".
Как сделать так, как было по умолчанию в XE2 и прошлых версиях?
GlavBuh
sergionn
У SmartMS вышла beta2 версии 1.1 - _http://smartmobilestudio.com/2013/01/21/smart-mobile-studio-v1-1-beta-2/
Так что с проектом все более менее ок!) Не переживаем))
А то, что паскаль и дельфи - немного разные вещи, это да. В последнее время появилось несколько важных для паскаля вещеий - кроссплатформенный Oxygene на всех мажорных мобильных платформах (iOS, Android, WP), Lazarus релизнулся наконец 1.0, FPC догоняет Delphi по фичам языка (а где то и перегоняет - JVM CodeGen), вышла SmartMS. Это хорошо: конкуренция))
sergionn
У SmartMS вышла beta2 версии 1.1 - _http://smartmobilestudio.com/2013/01/21/smart-mobile-studio-v1-1-beta-2/
Так что с проектом все более менее ок!) Не переживаем))
А то, что паскаль и дельфи - немного разные вещи, это да. В последнее время появилось несколько важных для паскаля вещеий - кроссплатформенный Oxygene на всех мажорных мобильных платформах (iOS, Android, WP), Lazarus релизнулся наконец 1.0, FPC догоняет Delphi по фичам языка (а где то и перегоняет - JVM CodeGen), вышла SmartMS. Это хорошо: конкуренция))
deks
Я больше переживаю за mobile studio и немеряное количество багов в обезьянке.
В оксиджене меня смущает его бесполезность - в нуге он точно повторяет всю экосистему х-кода и стиля обджект-с, поэтому какой смысл писать на нем для osx и ios ибо:
1) Старый паскалевский КОД не прикрутишь без сильных переработок
2) Отсутствует кроссплатформенная прокладка позволяющая писать единый код для разных платформ
3) Лишние танцы с конечным деплойментом программ
4) Зависимость от ремобджектов при выходе новых версий, портировании сторонних либ
проще сразу писать на родном для платформы языке..........
Году этак в 2011 Эрик обмолвился на сайте смарта, что мол готов был начать перекладывать свой dwscript на llmv, но тут поступило предложение от Jon Lennart прикрутить dw к смарту, на что он с удовольствием согласился, впоследствии убрав из опенсорса js кодеген, и сделав его эксклюзивно для смарта. Давеча я закинул на гугль плюс предложение возобновить портирование под llmv - но должного отклика не получил - нах никому это не надо, и тем более самому эрику - ему лишь бы на форуме хрень всякую пописать, куда уж тут до зарабатывания денег.
В смарте мне не нравятся, по аналогии с оксидженом:
1) Серьезные отступления от родного object pascal - сложности при портировании
2) Мало родных паскалевских компонентов - можн осказать их нет почти........
3) Хреновый визуальный дизайнер - можно сказать он нифига не визуальный почти
4) Нет четкой и продуманной системы классов - все примеры имеют оч. разный подходы к реализации
5) Задержки с трансляцией функций от спецификации консорциума - некоторые функции вебкит уже поддерживает уже давно, но ребата из оптималесис их еще не прописали у себя.........
FPC такой же тормозной как и компилятор дельфи,
компоненты по большей части недоделанные, кросплатформенность по части osx и ios можно сказать никакая.
Вышел qt5 - я было обрадовался, но радость была недолгой - ровно 5 минут скачивания и установки,
оказалось нет поддержки visual studio 2012 из коробки (и пока как я понял мало кому удалось перекомпилировать библиотеки под 2012) - а у меня закуплена и стоит только она.
Жду весеннего релиза - обещают поддержку vs, + беты для ios и android суппорта
тут и Moble studio может нарисуется - ВОТ и будут расставлены все точки окончательно.........
сорри за полулирическое отступление..........
Я больше переживаю за mobile studio и немеряное количество багов в обезьянке.
В оксиджене меня смущает его бесполезность - в нуге он точно повторяет всю экосистему х-кода и стиля обджект-с, поэтому какой смысл писать на нем для osx и ios ибо:
1) Старый паскалевский КОД не прикрутишь без сильных переработок
2) Отсутствует кроссплатформенная прокладка позволяющая писать единый код для разных платформ
3) Лишние танцы с конечным деплойментом программ
4) Зависимость от ремобджектов при выходе новых версий, портировании сторонних либ
проще сразу писать на родном для платформы языке..........
Году этак в 2011 Эрик обмолвился на сайте смарта, что мол готов был начать перекладывать свой dwscript на llmv, но тут поступило предложение от Jon Lennart прикрутить dw к смарту, на что он с удовольствием согласился, впоследствии убрав из опенсорса js кодеген, и сделав его эксклюзивно для смарта. Давеча я закинул на гугль плюс предложение возобновить портирование под llmv - но должного отклика не получил - нах никому это не надо, и тем более самому эрику - ему лишь бы на форуме хрень всякую пописать, куда уж тут до зарабатывания денег.
В смарте мне не нравятся, по аналогии с оксидженом:
1) Серьезные отступления от родного object pascal - сложности при портировании
2) Мало родных паскалевских компонентов - можн осказать их нет почти........
3) Хреновый визуальный дизайнер - можно сказать он нифига не визуальный почти
4) Нет четкой и продуманной системы классов - все примеры имеют оч. разный подходы к реализации
5) Задержки с трансляцией функций от спецификации консорциума - некоторые функции вебкит уже поддерживает уже давно, но ребата из оптималесис их еще не прописали у себя.........
FPC такой же тормозной как и компилятор дельфи,
компоненты по большей части недоделанные, кросплатформенность по части osx и ios можно сказать никакая.
Вышел qt5 - я было обрадовался, но радость была недолгой - ровно 5 минут скачивания и установки,
оказалось нет поддержки visual studio 2012 из коробки (и пока как я понял мало кому удалось перекомпилировать библиотеки под 2012) - а у меня закуплена и стоит только она.
Жду весеннего релиза - обещают поддержку vs, + беты для ios и android суппорта
тут и Moble studio может нарисуется - ВОТ и будут расставлены все точки окончательно.........
сорри за полулирическое отступление..........
sergionn
Про оксиджен немного не так:
1) старый код совместим в определенном смысле, поэтому переписать старый код все таки проще на другой диалект Паскаля, чем на другой язык совсем.
2) кроссплатформенная прокладка Sugar есть, но все никак не выйдет из стадии closed beta, но желающие могут получить к ней доступ на github по запросу (пишем marc hoffman);
3) про танцы не понял - никаких особенных танцев нету! генерируется ipa и деплоится; если речь про часть работы, которая на osx происходит - то без этого никуда, так как codesign делается только через xcode commandline tools;
4) никакой зависимости при портировании сторонних либ нету - все что скомпилировано оксидженом спокойно линкуется с любым xcode проектом (такая же lib/framework получается) - по сути дела, оксиджен это тот же objective-с только с более приличным синтаксисом и несколькими плюшками в языке!
Смысл оксиджена есть, когда делаешь свой клиент к своему сервису (или не очень своему) - тогда можно написать свой backend приложения, и он быдет общим для ios/android. У всех приличных сервисов уже есть свои SDK для android и ios, поэтому вижу больше смысла для своего сервиса делать на оксиджене.
Если говорить про UI, то его приходится переписывать под каждую платформу, а это - большая часть клиентского приложения! Тут - на чем писать дело вкуса. Единственный плюс окисджена - что можно юзать ту же vs2012 и для android и для ios-кода.
Вообще, кросс-платформа довольно лукавая штука! Эмро пока отстает сильнее всех: у Ремобджектов уже вполне юзабельные android/ios/wp и win8/osx есть (и linus через mono), у FPC тоже добра хватает..
У Эмро же пока не показано никакого приличного решения для ios и в природе пока вообще нет решения для android/wp. Для osx обезьянка ограниченно подходит, но многовато багов - хотя вполне рабочее решение. А вот для win8 пока эмуляция.. Это не серьезно!
Это что касалось паскалевских вендоров..
Добавлено:
Если брать паскаль в целом, то ситуация не очень веселая.
Под objective-с и android (java) есть почти все sdk/frameworks: хочешь - Facebook, Twitter, хочешь - экзотику типа Parse? Они есть.
Для .net/java/objC есть куча хорошего уровня ORM. У Дельфи нету.
У .net есть приличные серверные решения типа ASP.net, у Java вообще капец сколько серверных технологий. У Дельфей все довольно жидко: DataSnap, Indy, IntraWeb.. Даже те же remobjects имеют большего всего фич в серверной версии на .net.
Я бы на месте Эмро делал бы сообщество на gitHub и спонсировал бы разработку open source фреймворков путем найма разработчиков и работы для open source. А они даже с существующими энтузиастами договорится не могут - типа Synopse, DCEF, UIB, ... Не думаю, чтобы найм по паре инженеров в каждый приличный open-source проект разорил бы Эмро, но может быть мы бы получили бы наконец приличный ORM в Delphi на базе того же mORMot!
Аналог такой деятельности - как MS делает с ASP.NET, которая вроде бы уже сама open source, и активно вбирает в себя другие open-source компоненты типа DotNetOpenAuth, jQuery, knockout.JS! И при этом MS вполне себе продает VS2012)
Про оксиджен немного не так:
1) старый код совместим в определенном смысле, поэтому переписать старый код все таки проще на другой диалект Паскаля, чем на другой язык совсем.
2) кроссплатформенная прокладка Sugar есть, но все никак не выйдет из стадии closed beta, но желающие могут получить к ней доступ на github по запросу (пишем marc hoffman);
3) про танцы не понял - никаких особенных танцев нету! генерируется ipa и деплоится; если речь про часть работы, которая на osx происходит - то без этого никуда, так как codesign делается только через xcode commandline tools;
4) никакой зависимости при портировании сторонних либ нету - все что скомпилировано оксидженом спокойно линкуется с любым xcode проектом (такая же lib/framework получается) - по сути дела, оксиджен это тот же objective-с только с более приличным синтаксисом и несколькими плюшками в языке!
Смысл оксиджена есть, когда делаешь свой клиент к своему сервису (или не очень своему) - тогда можно написать свой backend приложения, и он быдет общим для ios/android. У всех приличных сервисов уже есть свои SDK для android и ios, поэтому вижу больше смысла для своего сервиса делать на оксиджене.
Если говорить про UI, то его приходится переписывать под каждую платформу, а это - большая часть клиентского приложения! Тут - на чем писать дело вкуса. Единственный плюс окисджена - что можно юзать ту же vs2012 и для android и для ios-кода.
Вообще, кросс-платформа довольно лукавая штука! Эмро пока отстает сильнее всех: у Ремобджектов уже вполне юзабельные android/ios/wp и win8/osx есть (и linus через mono), у FPC тоже добра хватает..
У Эмро же пока не показано никакого приличного решения для ios и в природе пока вообще нет решения для android/wp. Для osx обезьянка ограниченно подходит, но многовато багов - хотя вполне рабочее решение. А вот для win8 пока эмуляция.. Это не серьезно!
Это что касалось паскалевских вендоров..
Добавлено:
Если брать паскаль в целом, то ситуация не очень веселая.
Под objective-с и android (java) есть почти все sdk/frameworks: хочешь - Facebook, Twitter, хочешь - экзотику типа Parse? Они есть.
Для .net/java/objC есть куча хорошего уровня ORM. У Дельфи нету.
У .net есть приличные серверные решения типа ASP.net, у Java вообще капец сколько серверных технологий. У Дельфей все довольно жидко: DataSnap, Indy, IntraWeb.. Даже те же remobjects имеют большего всего фич в серверной версии на .net.
Я бы на месте Эмро делал бы сообщество на gitHub и спонсировал бы разработку open source фреймворков путем найма разработчиков и работы для open source. А они даже с существующими энтузиастами договорится не могут - типа Synopse, DCEF, UIB, ... Не думаю, чтобы найм по паре инженеров в каждый приличный open-source проект разорил бы Эмро, но может быть мы бы получили бы наконец приличный ORM в Delphi на базе того же mORMot!
Аналог такой деятельности - как MS делает с ASP.NET, которая вроде бы уже сама open source, и активно вбирает в себя другие open-source компоненты типа DotNetOpenAuth, jQuery, knockout.JS! И при этом MS вполне себе продает VS2012)
Цитата:
но должного отклика не получил - нах никому это не надо, и тем более самому эрику - ему лишь бы на форуме хрень всякую пописать, куда уж тут до зарабатывания денег.
А по-моему, он Вам четко ответил, что среди нативных нишу с llvm заняли РемОбжектс (Мак, иОС) и FPC для всех остальных, а него хватает работы по DWS в рамках Smart Mobile Studio и с остальными он напрямую конкурировать не собирается.
...а если немного отвлечься от священных войн. У кого есть Xe3 Update1
пофиксили этот баг или нет ?
-------------------------------------------
program xe2ziptest;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils, System.zip, Classes;
const fn = 'd:\xe2test.zip';
pattern = '0123456789';
var ms: TMemoryStream;
buf: AnsiString;
begin
try
{ TODO -oUser -cConsole Main : Insert code here }
DeleteFile(fn);
buf := pattern;
ms := TMemoryStream.Create;
ms.Write(buf[1], Length(buf));
ms.Position := 5;
// this triggers the bug
// ms.Position := 0;
// // this workarounds the bug
with TZipFile.Create do
try
Open(fn, zmWrite);
Add(ms, 'aaa/bbb.txt');
Close;
finally
Free;
ms.Free;
end;
except
on E: Exception do
Writeln(E.ClassName, ': ', E.Message);
end;
end.
------------------------
что в результате в zip попадёт ?
пофиксили этот баг или нет ?
-------------------------------------------
program xe2ziptest;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils, System.zip, Classes;
const fn = 'd:\xe2test.zip';
pattern = '0123456789';
var ms: TMemoryStream;
buf: AnsiString;
begin
try
{ TODO -oUser -cConsole Main : Insert code here }
DeleteFile(fn);
buf := pattern;
ms := TMemoryStream.Create;
ms.Write(buf[1], Length(buf));
ms.Position := 5;
// this triggers the bug
// ms.Position := 0;
// // this workarounds the bug
with TZipFile.Create do
try
Open(fn, zmWrite);
Add(ms, 'aaa/bbb.txt');
Close;
finally
Free;
ms.Free;
end;
except
on E: Exception do
Writeln(E.ClassName, ': ', E.Message);
end;
end.
------------------------
что в результате в zip попадёт ?
HeMet я знаю что он мне ответил, проблема не в этом,
я хотел в первую очередь получить отклик от сообщества - его нет и видимо не будет - ибо дельфисты уже ретрограды....
Аналогия: когда Брин с сотоварищем создавали свою системку, на поисковом рынке на тот момент было как минимум 5 крупных игроков, которые ДОВОЛЬНО плотно занимали всю НИШУ, НО, тем не менее спустя каких-то пару тройку лет, многие из них канули в лету, ну а гугль...........вы знаете, чем стал гугль.........
я хотел в первую очередь получить отклик от сообщества - его нет и видимо не будет - ибо дельфисты уже ретрограды....
Аналогия: когда Брин с сотоварищем создавали свою системку, на поисковом рынке на тот момент было как минимум 5 крупных игроков, которые ДОВОЛЬНО плотно занимали всю НИШУ, НО, тем не менее спустя каких-то пару тройку лет, многие из них канули в лету, ну а гугль...........вы знаете, чем стал гугль.........
sergionn
Мне кажется, что делфистам (тем кому не пофиг) безразлично кто сделает паскаль поверх llvm, если оно будет работать как надо: EMB, RemObjects или FPC. А вот направлением OP - JS никто кроме Эрика Гранжа не занимается. Да и сдается мне, что нынче голому компилятору без RTL и фреймворков будет тяжело взлететь. Те же RO делают компиляторы, но при этом тянут к себе все что только можно.
P.S. Отходя от глобальных тем: ковыряюсь с мартышкой (пилю тихонько техно-демку) и дошла очередь до иконок для кнопок. Поскольку Мартышка по сути векторная, взор обратился в сторону SVG, тем более, что как бы TPath принимает информацию по кривым, которую как раз использует этот формат. Ну, так вот, ничего сложнее самых простых вещей с ходу нарисоваться не смогло. Полез разбираться почему. Данные парсит и хранит TPathData и там такое... Такое ощущение, что тому кто его писал дали на это пару обеденных перерывов, либо постоянно капали на мозги. Из самого примечательного:
* многослойная копипаста
* старательное избегание case и repeat и промежуточных перменных
* старательное использование TStringBuilder, там где он него никакого толку, т.к. цепочные вызовы не используются (да и вообще, теперь это все сам string умеет)
* таскание по алгоритму пары переменных с одинаковым по сути назначением и перекладывание данных то туда то сюда, а в итоге сами себе на ноги наступают.
* не реализованы почти все команды рисования кривых, хотя в классе уже есть все необходимое (такое ощущение, что начали, но не закончили).
* куча проверок на всякий случай, потому что парсер ведет себя черт знает как
* забивание на то, что написано в спецификации (правда, никто в хелпе не заявлял о поддержке SVG Path)
Итого парсер почти никакой: куча жирного кода, которая работает раз через раз. При этом не в нем нашел только одну ошибку, ЕМНИП.
Поправишь одну ошибку (по-любому, хелперы добавили именно для этого
) и тут же видишь как все криво, отрефакторишь, найдешь ещё что-нить. В итоге, к тому времени, когда правильные svg-пути начали рисоваться как положено, весь парсер оказался переписан почти вчистую, хотя я себе изначально такой цели не ставил.
Но при всем при этом жалоб на более низкие слои Мартышки у меня не возникало, кроме рендеринга текста (ну когда уже через Direct2D текст перестанет рисоваться размытым). Всё весьма шустро работает и по сравнению с чистым Direct2D гораздо меньше возни со всякими ресурсами.
Накопилось
Мне кажется, что делфистам (тем кому не пофиг) безразлично кто сделает паскаль поверх llvm, если оно будет работать как надо: EMB, RemObjects или FPC. А вот направлением OP - JS никто кроме Эрика Гранжа не занимается. Да и сдается мне, что нынче голому компилятору без RTL и фреймворков будет тяжело взлететь. Те же RO делают компиляторы, но при этом тянут к себе все что только можно.
P.S. Отходя от глобальных тем: ковыряюсь с мартышкой (пилю тихонько техно-демку) и дошла очередь до иконок для кнопок. Поскольку Мартышка по сути векторная, взор обратился в сторону SVG, тем более, что как бы TPath принимает информацию по кривым, которую как раз использует этот формат. Ну, так вот, ничего сложнее самых простых вещей с ходу нарисоваться не смогло. Полез разбираться почему. Данные парсит и хранит TPathData и там такое... Такое ощущение, что тому кто его писал дали на это пару обеденных перерывов, либо постоянно капали на мозги. Из самого примечательного:
* многослойная копипаста
* старательное избегание case и repeat и промежуточных перменных
* старательное использование TStringBuilder, там где он него никакого толку, т.к. цепочные вызовы не используются (да и вообще, теперь это все сам string умеет)
* таскание по алгоритму пары переменных с одинаковым по сути назначением и перекладывание данных то туда то сюда, а в итоге сами себе на ноги наступают.
* не реализованы почти все команды рисования кривых, хотя в классе уже есть все необходимое (такое ощущение, что начали, но не закончили).
* куча проверок на всякий случай, потому что парсер ведет себя черт знает как
* забивание на то, что написано в спецификации (правда, никто в хелпе не заявлял о поддержке SVG Path)
Итого парсер почти никакой: куча жирного кода, которая работает раз через раз. При этом не в нем нашел только одну ошибку, ЕМНИП.
Поправишь одну ошибку (по-любому, хелперы добавили именно для этого
) и тут же видишь как все криво, отрефакторишь, найдешь ещё что-нить. В итоге, к тому времени, когда правильные svg-пути начали рисоваться как положено, весь парсер оказался переписан почти вчистую, хотя я себе изначально такой цели не ставил. Но при всем при этом жалоб на более низкие слои Мартышки у меня не возникало, кроме рендеринга текста (ну когда уже через Direct2D текст перестанет рисоваться размытым). Всё весьма шустро работает и по сравнению с чистым Direct2D гораздо меньше возни со всякими ресурсами.
Накопилось
HeMet
да уж код в обезьяне местами как болото.......
а какой конкретно svg файл/путь у тебя не отпарсился нормально?
У евгения был в vgscene пример: svgtool - я пробовал его, он почти все файлы нормально "брал" и знаменитого тигра в том числе. Неужели они как-то коряво перенесли код?
Хотя конечно в svgtool такие джунгли были............
Можешь выложить, хотя бы в квалити централ, что исправлял в парсере, и нам полезно будет, и глядишь 3,5 разработчика внесут изменения в код, наверно... хотя-бы... авось, а вдруг
да уж код в обезьяне местами как болото.......
а какой конкретно svg файл/путь у тебя не отпарсился нормально?
У евгения был в vgscene пример: svgtool - я пробовал его, он почти все файлы нормально "брал" и знаменитого тигра в том числе. Неужели они как-то коряво перенесли код?
Хотя конечно в svgtool такие джунгли были............
Можешь выложить, хотя бы в квалити централ, что исправлял в парсере, и нам полезно будет, и глядишь 3,5 разработчика внесут изменения в код, наверно... хотя-бы... авось, а вдруг
sergionn
Накачал иконок с http://thenounproject.com . Собсвенно, отладку парсера проводил на бутылках http://thenounproject.com/noun/bottles/#icon-No719 и на примерах их спецификации.
А тот парсер, что идет по умолчанию ничего практически не парсит т.к. падает на паре координат, если вторая отрицательная и не отделена пробелом от первой (допускается такая запись, знак воспринимается, как разделитель), а так же не обрабатывает команды "с" и "T(t)".
Цитата:
Куда-нибудь да выложу (и в QC в том числе), как только решу, что мне к этому коду добавить больше нечего. Я не остановился лишь на исправлениях, но и добавил, например, генерацию исключений, которые указывают где произошла ошибка, что парсер ожидал встретить, а что встретил на самом деле.
Накачал иконок с http://thenounproject.com . Собсвенно, отладку парсера проводил на бутылках http://thenounproject.com/noun/bottles/#icon-No719 и на примерах их спецификации.
А тот парсер, что идет по умолчанию ничего практически не парсит т.к. падает на паре координат, если вторая отрицательная и не отделена пробелом от первой (допускается такая запись, знак воспринимается, как разделитель), а так же не обрабатывает команды "с" и "T(t)".
Цитата:
Можешь выложить, хотя бы в квалити централ
Куда-нибудь да выложу (и в QC в том числе), как только решу, что мне к этому коду добавить больше нечего. Я не остановился лишь на исправлениях, но и добавил, например, генерацию исключений, которые указывают где произошла ошибка, что парсер ожидал встретить, а что встретил на самом деле.
HeMet
На GitHub удобно такие проекты выкладывать - там легко делать добавления в проект/контрибуции - простой pull request из форкнутого репозитория. Я смотрю - для многих проектов даже issues сопровождаются pull request с патчем для бага! Хороший вариант, да)
На GitHub удобно такие проекты выкладывать - там легко делать добавления в проект/контрибуции - простой pull request из форкнутого репозитория. Я смотрю - для многих проектов даже issues сопровождаются pull request с патчем для бага! Хороший вариант, да)
Цитата:
Собсвенно, отладку парсера проводил на бутылках http://thenounproject.com/noun/bottles/#icon-No719
действительно родной парсер не берет!
но что интересно!!!!!, парсер который приведен в примере в VGScene svgtool - "взял" бутылки без проблем!
- Или перенесли криво код, или наваяли новый, кривой
Что самое обидное, что они об этом ЗНАЮТ! (т.к. в квалити централе как минимум 3 раза постили это, + я 1 раз на их форуме)
Что исправить на раз ТОЖЕ могут, основываясь хотя бы на коде вышеупомянутого сампла,
НО НИ ХРЕНА этого не делают
((((((( deks можешь по-подробнее про sugar?
deks
Да я не переживаю. Я потихоньку изучаю jQuery. И он мне начинает нравиться.
(Фнукциональное программирование - это круто, да).
Да я не переживаю. Я потихоньку изучаю jQuery. И он мне начинает нравиться.
(Фнукциональное программирование - это круто, да).
Цитата:
изучаю jQuery
хрень ЭТО, а не функциональное программирование, и имеет с ним мало общего, недоразумение, выдача желаемого за действительное.
В принципе как и весь нынешний веб, созданный на коленке, и корчащийся в агонии несовместимостей и нонсенсов.
Вообще глядя на эти "современные" залепухи для якобы программирования: js, jquery, sencha ruby, less и пр. тонны скрипто-костылей, складывается ощущение, что молодняк придумавший и использующих их ТУПО отбросил весь многолетний опыт языков программирования.....
Не от хорошей жизни вскоре появились dart, go, typescript, coffescript - пытаются исправить недоразумения...........
Обрати внимание на smartmobilestudio - код js который она делает, лучше оптимизирован, а писать на паскале гораздо удобней и приятней чем на сляпанном за неделю языке, в купе с сопутствующими костылями-фреймворками.
sergionn
Я как бы держу руку на пульсе, и внимательно слежу за SMS. Но знание JS все равно не помешает - хотя бы отлаживать скомпилированный из SMS JS-код в браузере.
Я как бы держу руку на пульсе, и внимательно слежу за SMS. Но знание JS все равно не помешает - хотя бы отлаживать скомпилированный из SMS JS-код в браузере.
Обещанное исправления TPathData https://bitbucket.org/Hemet/fixmx . Потом выложу в QC: кажется, там есть ещё что исправить, а у EMB, слышал, есть нехороша привычка не обновлять своевременно код, который они откуда-то извне взяли (если они, вдруг, мой примут).
HeMet спасибо тебе за труды....
эта привычка не о том.
Это когда есть хорошая и известная библиотека - например Windows XP Themes, Direct X Show Pack, DUnit - и Эмба берет и копирует их целиком и начинает сама распространять. У исходного проекта кончаются пользователи, а потом разбегаются и разработчики - ибо зачем? А сама Эмба их развивать тоже не собирается - копировали не для разработки, а для галки в анкете.
Что же до QC - то может быть и приложат. А может быть дождуться XE4, когда исправления можно будет продать. Но воообще пока тоьлко два апдейта было - может быть и успеешь предложить... Но в любом случае патч в багтрекере - это именно разовая акция, это становится их код, а н етвоя отдельная билиотека. И тебе никто не мешает в принципе открыть несколько тикетов в QC по мере разработки.
Это когда есть хорошая и известная библиотека - например Windows XP Themes, Direct X Show Pack, DUnit - и Эмба берет и копирует их целиком и начинает сама распространять. У исходного проекта кончаются пользователи, а потом разбегаются и разработчики - ибо зачем? А сама Эмба их развивать тоже не собирается - копировали не для разработки, а для галки в анкете.
Что же до QC - то может быть и приложат. А может быть дождуться XE4, когда исправления можно будет продать. Но воообще пока тоьлко два апдейта было - может быть и успеешь предложить... Но в любом случае патч в багтрекере - это именно разовая акция, это становится их код, а н етвоя отдельная билиотека. И тебе никто не мешает в принципе открыть несколько тикетов в QC по мере разработки.
Arioch1
не открывай америку через форточку - ТАК делают ВСЕ:
дизайнеры, физики, химики, писатели, композиторы, программисты, люди наконец,
КОПИРУЮТ друг у ДРУГА, идеи, наметки, что-то дополняют, что-то тупо выдают за свое,
просто где-то это видно явно, где то завуалировано,
в принципе каждый решает сам для себя - платить своему ВДОХНОВИТЕЛЮ или нет,
- это в принципе НОРМАЛЬНО , так и должно быть - наша сила в количестве,
в том что одну работу ВСЕГДА может ДОПОЛНИТЬ или ЗАКОНЧИТЬ другой, такая эволюция разума................
не открывай америку через форточку - ТАК делают ВСЕ:
дизайнеры, физики, химики, писатели, композиторы, программисты, люди наконец,
КОПИРУЮТ друг у ДРУГА, идеи, наметки, что-то дополняют, что-то тупо выдают за свое,
просто где-то это видно явно, где то завуалировано,
в принципе каждый решает сам для себя - платить своему ВДОХНОВИТЕЛЮ или нет,
- это в принципе НОРМАЛЬНО , так и должно быть - наша сила в количестве,
в том что одну работу ВСЕГДА может ДОПОЛНИТЬ или ЗАКОНЧИТЬ другой, такая эволюция разума................
при чем тут платить, речь именно о перехвате внимания, которое в интрнете куда дефицитнее денег
Цитата:
перехвате внимания
расшифруй, что-то я не "въехал"
вообще я понимаю все так:
Делаешь свой проект, если код оригинальный, или ты очень Важный,
и если ТЫ сильно переживаешь (на уровне копирастической филии) что его СТЫРЯТ
и будут выдавать (продавать) за свой, всегда можно:
1) Не выкладывать исходники
2) Выложить и защитить лицензией - а потом пустить робота и искать кто его подрезал
3) Защитить патентом - а потом продать патентному тролю, который будет искать и иметь того кто использовал
4) Вообще не писать ничего и никогда, а сидеть дома и боятся что у тебя украдут чего-нибудь, внимание например
))) а если серьезно, обычно, в 99%, если ты сделаешь, что то нужное
и действительно ценное, то награда всегда находит своего героя,
а если сидеть и пускать сопли что emb или кто либо еще использовал твой код,
и поэтому скрывать его от глаз или вообще ничего не делать - то кроме соплей в инете, от нас не останется ничего в этом мире.............
Вопрос не в "стырят", а в "стырят и бросять гнить"
Цитата:
Цитата:
Эмба берет и копирует их целиком и начинает сама распространять. У исходного проекта кончаются пользователи, а потом разбегаются и разработчики - ибо зачем? А сама Эмба их развивать тоже не собирается
Цитата:
У исходного проекта кончаются пользователи, а потом разбегаются и разработчики - ибо зачем? А сама Эмба их развивать тоже не собирается
Цитата:
в 99%, если ты сделаешь, что то нужное
и действительно ценное, то награда всегда находит своего героя,
а если сидеть и пускать сопли что emb или кто либо еще использовал твой код,
и поэтому скрывать его от глаз или вообще ничего не делать - то кроме соплей в инете, от нас не останется ничего в этом мире.............
Никакая эмба ничего тебе противопоставит не сможет если:
1) твой код АКТУАЛЕН - и ты вносишь изменения, развиваешь его,
зачем я буду пользоваться "заброшенным" кодом эмбы - это БРЕД!
Я лучше ДАМ тебе немного денег, а если твой код ВОСТРЕБОВАН то еще тысячи заинтересованных человек
сделают то же самое, и ты будешь его поддерживать и развивать и все будут в шоколаде.
Код это же не трусы на распродаже - урвал и убежал,
код нуждается в АКТУАЛИЗАЦИИ, ПОЛИРОВКЕ и т.п.
Страницы: 1234567891011121314151617181920212223242526272829303132333435363738
Предыдущая тема: [Delphi XE2] Размер PNG
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.