нужен совет по выбору IDE и языка прграммирования, ситуация следующая, намечается проект суть которого заключается в обработке больших текстовых данных(xml + различный текст) получаемых по сети, интересует следующее :
— на каком языке сейчс пишут под freebsd ? c++ , c ?
— наиболее удобная/работоспособная ide [хотелось бы что-то аналогичное eclipse или idea 8-) ]
— еще у кого есть опыт разработки под unix, прошу поделиться опытом (xml парсеры, возможно какие-то фреймфорки)
Здравствуйте, Аноним, Вы писали:
А>нужен совет по выбору IDE и языка прграммирования, ситуация следующая, намечается проект суть которого заключается в обработке больших текстовых данных(xml + различный текст) получаемых по сети, интересует следующее : А> — на каком языке сейчс пишут под freebsd ? c++ , c ?
и на c++ и на c, компилятор(вернее колекция компиляторов) gcc поддерживает и то и то.
А> — наиболее удобная/работоспособная ide [хотелось бы что-то аналогичное eclipse или idea 8-) ]
Для eclipse же есть поддержка C/C++, а для idea нету?
Здравствуйте, Аноним,
IDE уже подсказали, а писать можно и на C#(mono-project) и на Java. ибо если с текстом и нужны сетевые иервисы то на C/С++ писать — долго, сложно и дорого. Это если не в свое удовольствие
Здравствуйте, Аноним, Вы писали: А> — на каком языке сейчс пишут под freebsd ? c++ , c ?
На любом. C, C++, Python, Ruby, Java, Lisp... Я бы выбирал тот, который лучше знаю.
Здравствуйте, Аноним, Вы писали:
А>нужен совет по выбору IDE и языка прграммирования, ситуация следующая, намечается проект суть которого заключается в обработке больших текстовых данных(xml + различный текст) получаемых по сети, интересует следующее :
Удивлен, что вам никто не порекомендовал Perl. Я его сам не очень-то использую и недолюбливаю за синтаксис, но, считаю, что в обработке текстовых данных равных ему нет. Собственно, ровно для этих целей он и создавался, так что работает он с текстами очень шустро.
Здравствуйте, Аноним, Вы писали:
А>нужен совет по выбору IDE и языка прграммирования, ситуация следующая, намечается проект суть которого заключается в обработке больших текстовых данных(xml + различный текст) получаемых по сети, интересует следующее : А> — на каком языке сейчс пишут под freebsd ? c++ , c ? А> — наиболее удобная/работоспособная ide [хотелось бы что-то аналогичное eclipse или idea 8-) ] А> — еще у кого есть опыт разработки под unix, прошу поделиться опытом (xml парсеры, возможно какие-то фреймфорки)
Можна предложить в этом варианте с++ и к нему по задачам: обработка текста: "чистый" C++ плюс контейнеры и алгоритмы STL;
обработка XML: есть сишная, но вполне юзабельная на С++ библиотека libxml2;
сеть: написание на С++ реализации приема больших данных по сети займет не более дня в среднего программиста, имеющего хороший опыт работы с сетями. Я сторонник "низкоуровней" работы с сокетами, но видел и высокоуровневые библиотеки, например в Qt есть класы по работе с сокетами;
IDE: если все машины на UNIX, то eclipse неплохо подходит. (На mono-project уж сильно матюкатся). Если же розработка ведется на машинах с Windows а компилится и тестится на UNIX, тогда связка MS Visual C++ + Visual Assist дают очень удобный редактор кода (дороговатый безспорно ).
"Глухие могут не услышать выстрел, но пулю это не остановит..."
nerozero однажды (15 октября 2008 15:53) писал в rsdn.unix:
> IDE уже подсказали, а писать можно и на C#(mono-project) и на Java. ибо если с текстом и нужны сетевые иервисы то на C/С++ писать — долго, сложно и дорого. Это если не в свое > удовольствие
шарпу в линуке не место.
Здравствуйте, Аноним, Вы писали:
А> — на каком языке сейчс пишут под freebsd ? c++ , c ?
На каком пишут? На всех ! Но для текста я бы посоветовал Perl или Ruby. А> — наиболее удобная/работоспособная ide [хотелось бы что-то аналогичное eclipse или idea 8-) ]
Eclipse? Kdevelop? Тру вэй — emacs или vim А> — еще у кого есть опыт разработки под unix, прошу поделиться опытом (xml парсеры, возможно какие-то фреймфорки)
xml-парсеры:
libxml2 — тяжеловестный, но мощный;
libexpat — легкий, но много велосипедов придется реализовывать самому.
On Thu, 16 Oct 2008 10:24:16 GMT
"nerozero" <45173@users.rsdn.ru> wrote:
> Здравствуйте, Sheridan, Вы писали: > > S>шарпу в линуке не место. > > Ну, незабывайте при таких высказываниях добавлять "IMHO"
А>нужен совет по выбору IDE и языка прграммирования, ситуация следующая, намечается проект суть которого заключается в обработке больших текстовых данных(xml + различный текст) получаемых по сети, интересует следующее : А> — на каком языке сейчс пишут под freebsd ? c++ , c ?
А под Windows?.. C++? C#? Java? VB.NET? На чем удобно, на том и пишут.
А> — наиболее удобная/работоспособная ide [хотелось бы что-то аналогичное eclipse или idea 8-) ]
Тут промолчу — нет опыта. Эклипс товарищ хвалил, да.
А> — еще у кого есть опыт разработки под unix, прошу поделиться опытом (xml парсеры, возможно какие-то фреймфорки)
libxml, libexpat уже называли.
На самом деле, рекомендую не зацикливаться на каком-то одном языке.
Процессинг текста, возможно, будет удобно сделать на perl. А может, и нет. Получение по сети — C/C++ (маленький модуль, довольно шустро общающийся с сетью) Общение с какой-либо БД (а что еще с получаемым текстом делать?) — python.
Это всего лишь примеры, и, наверняка, не всегда удачные. Я сам не владею некоторыми языками (та же ruby или erlang с haskell'ем). Просто разбив предполагаемую программу на такие модули, можно или поискать уже готовое решение для какой-либо части, или просто предположив, что для этой цели этот язык будет более всего удобным.
Здравствуйте, nerozero, Вы писали:
N>Здравствуйте, Sheridan, Вы писали:
S>>шарпу в линуке не место.
N>Ну, незабывайте при таких высказываниях добавлять "IMHO" ;)
Шарп-то сам по себе не вопрос, а вот реализация Mono — мягко говоря, нецензурна.
Вот маленький кусок кода на тест.
using System;
using System.IO;
class HelloWorld {
public static void Main() {
FileStream f1, f2;
f1 = new FileStream("/dev/null", FileMode.Open);
f2 = new FileStream("/dev/null", FileMode.Open);
f1.Close();
f2.Close();
}
}
А теперь запускаем и удивляемся.
$ mono test2.exe
Unhandled Exception: System.IO.IOException: Sharing violation on path /dev/null
at System.IO.FileStream..ctor (System.String name, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000]
at System.IO.FileStream..ctor (System.String name, FileMode mode) [0x00000]
at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode)
at HelloWorld.Main () [0x00000]
Никому не кажется, что тут что-то неладно? ;)) Какого лешего автоматом включена защита? Зачем?
Здравствуйте, netch80, Вы писали:
N>Шарп-то сам по себе не вопрос, а вот реализация Mono — мягко говоря, нецензурна.
...
f1 = new FileStream("/dev/null", FileMode.Open);
f2 = new FileStream("/dev/null", FileMode.Open);
... N>А теперь запускаем и удивляемся.
... N>Unhandled Exception: System.IO.IOException: Sharing violation on path /dev/null
... N>Никому не кажется, что тут что-то неладно? ) Какого лешего автоматом включена защита? Зачем?
Нет, не кажется. Вы бы, прежде чем делать выводы, изучили документацию по FileStream. Использованный Вами конструктор FileStream открывает /dev/null на чтение-запись с эксклюзивным (в рамках текущего процесса) правом на запись. Ясное дело, что второй поток открыть не удастся. Так будет и под моно, и под майкрософтовским рантаймом.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, netch80, Вы писали:
N>>Шарп-то сам по себе не вопрос, а вот реализация Mono — мягко говоря, нецензурна. MC>... MC>
MC> f1 = new FileStream("/dev/null", FileMode.Open);
MC> f2 = new FileStream("/dev/null", FileMode.Open);
MC>
MC>... N>>А теперь запускаем и удивляемся. MC>... N>>Unhandled Exception: System.IO.IOException: Sharing violation on path /dev/null MC>... N>>Никому не кажется, что тут что-то неладно? ;)) Какого лешего автоматом включена защита? Зачем?
MC>Нет, не кажется. Вы бы, прежде чем делать выводы, изучили документацию по FileStream. Использованный Вами конструктор FileStream открывает /dev/null на чтение-запись с эксклюзивным (в рамках текущего процесса) правом на запись. Ясное дело, что второй поток открыть не удастся. Так будет и под моно, и под майкрософтовским рантаймом.
Видите ли,
1. Проблема в том, что я нарвался на это не в C#, а в IronPython, на встроенной функции file(), которой никакого шаринга задать нельзя — не рассчитана она на это. Можно, конечно, сказать, что это ошибка его (IronPython) авторов, и это будет верно. Но это показывает общую идеологическую проблему перетаскивания средства из чуждого мира.
2. Я внимательно перечитал ещё раз описание поведения данного конструктора на msdn.microsoft.com и не вижу никакого подобного утверждения — так что расскажите, пожалуйста, откуда Вы его взяли. Есть только следующее замечание:
The constructor is given read/write access to the file, and it is opened sharing Read access (that is, requests to open the file for writing by this or another process will fail until the FileStream object has been closed, but read attempts will succeed).
Так как у меня оба открытия — на чтение, то это должно пройти. Или Вы скажете, что System.IO.FileMode.Open — это и запись? Тогда эта логика мне ещё более чужда (и авторам IronPython, очевидно, тоже) — хотя бы потому, что нет аналога O_RDONLY, каким является режим "r" в stdio.
Резюмирую — имеем чуждую логику и плохо организованную документацию. OK, я готов не считать больше, что виновата Mono — тут проблема дотнета в целом...
N>2. Я внимательно перечитал ещё раз описание поведения данного конструктора на msdn.microsoft.com и не вижу никакого подобного утверждения — так что расскажите, пожалуйста, откуда Вы его взяли. Есть только следующее замечание:
N>
N>The constructor is given read/write access to the file, and it is opened sharing Read access (that is, requests to open the file for writing by this or another process will fail until the FileStream object has been closed, but read attempts will succeed).
N>Так как у меня оба открытия — на чтение, то это должно пройти. Или Вы скажете, что System.IO.FileMode.Open — это и запись? Тогда эта логика мне ещё более чужда (и авторам IronPython, очевидно, тоже) — хотя бы потому, что нет аналога O_RDONLY, каким является режим "r" в stdio.
N>Резюмирую — имеем чуждую логику и плохо организованную документацию. OK, я готов не считать больше, что виновата Mono — тут проблема дотнета в целом...
Читайте вминательнее.
constructor is given read/write access to the file, and it is opened sharing Read access (that is, requests to open the file for writing by this or another process will fail
А то потом находят "проблемы дотнета в целом" на ровном месте.
Здравствуйте, netch80, Вы писали:
N>Резюмирую — имеем чуждую логику и плохо организованную документацию.
Да, уж. "Дьявол в мелочах" — это девиз мелкомягкой документации. Однако не в этом случае.
N>2. Я внимательно перечитал ещё раз описание поведения данного конструктора на msdn.microsoft.com и не вижу никакого подобного утверждения — так что расскажите, пожалуйста, откуда Вы его взяли.
Вы использовали конструктор FileStream(string, FileMode).
The constructor is given read/write access to the file, and it is opened sharing Read access (that is, requests to open the file for writing by this or another process will fail until the FileStream object has been closed, but read attempts will succeed). The buffer size is set to the default size of 4096 bytes (4 KB).
Requests to open the file for writing by the current or another thread will fail until the System.IO.FileStream object has been closed. Read attempts will succeed.
Здравствуйте, netch80, Вы писали: N>1. Проблема в том, что я нарвался на это не в C#, а в IronPython, на встроенной функции file(), которой никакого шаринга задать нельзя — не рассчитана она на это. Можно, конечно, сказать, что это ошибка его (IronPython) авторов, и это будет верно. Но это показывает общую идеологическую проблему перетаскивания средства из чуждого мира.
MC>The constructor is given read/write access to the file, and it is opened sharing Read access (that is, requests to open the file for writing by this or another process will fail until the FileStream object has been closed, but read attempts will succeed). The buffer size is set to the default size of 4096 bytes (4 KB).
Понятно. Да уж, давно не сталкивался с такими извращениями, отвык.
Посмотрим дальше — если можно обойтись малой кровью (есть ещё десяток примерно таких же по изврату мест), получим неплохую основу, а они — инсталляционную базу. Только вот боюсь, что легче воспользоваться чем-то менее инопланетянским...
Здравствуйте, netch80, Вы писали: N>Понятно. Да уж, давно не сталкивался с такими извращениями, отвык.
Мммм... А чего Вы еще ожидали, открывая файл на запись?
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, netch80, Вы писали: N>>1. Проблема в том, что я нарвался на это не в C#, а в IronPython, на встроенной функции file(), которой никакого шаринга задать нельзя — не рассчитана она на это. Можно, конечно, сказать, что это ошибка его (IronPython) авторов, и это будет верно. Но это показывает общую идеологическую проблему перетаскивания средства из чуждого мира.
MC>Приведите пожалуйста код на питоне.
Его слишком много.:(( Вырезать показательный кусок на сейчас не могу. Попробую позже.
Есть ещё ряд интересных аспектов. Например, если я пишу f = file(filename, 'r'); print f.fileno(); — получаю, например, 5, в то время как fstat показывает, что это дескриптор номер 15. Источник проблемы приблизительно понятен, но подобное поведение не подходит — надо передать в дочерний процесс дескриптор вместе с его номером.
Чем заменить select или poll в движке событий, я совсем уже не представляю себе.;(
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, netch80, Вы писали: N>>Понятно. Да уж, давно не сталкивался с такими извращениями, отвык. MC>Мммм... А чего Вы еще ожидали, открывая файл на запись?
Честно ответить?;)) Ожидал стандартного нормального поведения — никаких блокировок и отказов, пока об этом явно не попросили (т.наз. advisory locking). В общем, того, что ожидается от нормального юникса и реализации на нём. И, естественно, тут не должно было быть никакого неестественного интеллекта с решением за меня, что к чему не пускать (в рамках одного процесса — это ж додуматься надо!)