программирование под unix
От: Аноним  
Дата: 15.10.08 08:17
Оценка:
нужен совет по выбору IDE и языка прграммирования, ситуация следующая, намечается проект суть которого заключается в обработке больших текстовых данных(xml + различный текст) получаемых по сети, интересует следующее :
— на каком языке сейчс пишут под freebsd ? c++ , c ?
— наиболее удобная/работоспособная ide [хотелось бы что-то аналогичное eclipse или idea 8-) ]
— еще у кого есть опыт разработки под unix, прошу поделиться опытом (xml парсеры, возможно какие-то фреймфорки)
Re: программирование под unix
От: e_k Россия  
Дата: 15.10.08 08:33
Оценка:
Если нравится Eclipse — то и используйте Eclipse
Re: программирование под unix
От: Аноним  
Дата: 15.10.08 08:34
Оценка:
Здравствуйте, Аноним, Вы писали:

А>нужен совет по выбору IDE и языка прграммирования, ситуация следующая, намечается проект суть которого заключается в обработке больших текстовых данных(xml + различный текст) получаемых по сети, интересует следующее :

А> — на каком языке сейчс пишут под freebsd ? c++ , c ?

и на c++ и на c, компилятор(вернее колекция компиляторов) gcc поддерживает и то и то.

А> — наиболее удобная/работоспособная ide [хотелось бы что-то аналогичное eclipse или idea 8-) ]

Для eclipse же есть поддержка C/C++, а для idea нету?
Re: программирование под unix
От: nerozero  
Дата: 15.10.08 11:53
Оценка:
Здравствуйте, Аноним,
IDE уже подсказали, а писать можно и на C#(mono-project) и на Java. ибо если с текстом и нужны сетевые иервисы то на C/С++ писать — долго, сложно и дорого. Это если не в свое удовольствие
Re: программирование под unix
От: Mr.Cat  
Дата: 15.10.08 12:13
Оценка: +1
Здравствуйте, Аноним, Вы писали:
А> — на каком языке сейчс пишут под freebsd ? c++ , c ?
На любом. C, C++, Python, Ruby, Java, Lisp... Я бы выбирал тот, который лучше знаю.
Re: программирование под unix
От: php-coder Чехия http://slava-semushin.blogspot.com
Дата: 15.10.08 12:30
Оценка: +2
Здравствуйте, Аноним, Вы писали:

А>нужен совет по выбору IDE и языка прграммирования, ситуация следующая, намечается проект суть которого заключается в обработке больших текстовых данных(xml + различный текст) получаемых по сети, интересует следующее :


Удивлен, что вам никто не порекомендовал Perl. Я его сам не очень-то использую и недолюбливаю за синтаксис, но, считаю, что в обработке текстовых данных равных ему нет. Собственно, ровно для этих целей он и создавался, так что работает он с текстами очень шустро.
Re: программирование под unix
От: Leogen  
Дата: 15.10.08 12:42
Оценка:
Здравствуйте, Аноним, Вы писали:

А>нужен совет по выбору IDE и языка прграммирования, ситуация следующая, намечается проект суть которого заключается в обработке больших текстовых данных(xml + различный текст) получаемых по сети, интересует следующее :

А> — на каком языке сейчс пишут под freebsd ? c++ , c ?
А> — наиболее удобная/работоспособная ide [хотелось бы что-то аналогичное eclipse или idea 8-) ]
А> — еще у кого есть опыт разработки под unix, прошу поделиться опытом (xml парсеры, возможно какие-то фреймфорки)

Можна предложить в этом варианте с++ и к нему по задачам:
  1. обработка текста: "чистый" C++ плюс контейнеры и алгоритмы STL;
  2. обработка XML: есть сишная, но вполне юзабельная на С++ библиотека libxml2;
  3. сеть: написание на С++ реализации приема больших данных по сети займет не более дня в среднего программиста, имеющего хороший опыт работы с сетями. Я сторонник "низкоуровней" работы с сокетами, но видел и высокоуровневые библиотеки, например в Qt есть класы по работе с сокетами;
  4. IDE: если все машины на UNIX, то eclipse неплохо подходит. (На mono-project уж сильно матюкатся). Если же розработка ведется на машинах с Windows а компилится и тестится на UNIX, тогда связка MS Visual C++ + Visual Assist дают очень удобный редактор кода (дороговатый безспорно ).
"Глухие могут не услышать выстрел, но пулю это не остановит..."
Re[2]: программирование под unix
От: Sheridan Россия  
Дата: 15.10.08 16:54
Оценка: -1
nerozero однажды (15 октября 2008 15:53) писал в rsdn.unix:

> IDE уже подсказали, а писать можно и на C#(mono-project) и на Java. ибо если с текстом и нужны сетевые иервисы то на C/С++ писать — долго, сложно и дорого. Это если не в свое

> удовольствие
шарпу в линуке не место.

--
Бортовой журнал
Posted via RSDN NNTP Server 2.1 beta
Matrix has you...
Re: программирование под unix
От: Sheridan Россия  
Дата: 15.10.08 16:56
Оценка:
Аноним 677 однажды (15 октября 2008 12:17) писал в rsdn.unix:

Выбирай — c++ или perl... Первое из твоего списка, 2 — предлагаю.
В качесве ide — попробуй netbeans

--
Бортовой журнал
Posted via RSDN NNTP Server 2.1 beta
Matrix has you...
Re: программирование под unix
От: crashed США  
Дата: 15.10.08 20:05
Оценка:
Здравствуйте, Аноним, Вы писали:

А> — на каком языке сейчс пишут под freebsd ? c++ , c ?

На каком пишут? На всех ! Но для текста я бы посоветовал Perl или Ruby.
А> — наиболее удобная/работоспособная ide [хотелось бы что-то аналогичное eclipse или idea 8-) ]
Eclipse? Kdevelop? Тру вэй — emacs или vim
А> — еще у кого есть опыт разработки под unix, прошу поделиться опытом (xml парсеры, возможно какие-то фреймфорки)
xml-парсеры:
libxml2 — тяжеловестный, но мощный;
libexpat — легкий, но много велосипедов придется реализовывать самому.
Re[3]: программирование под unix
От: nerozero  
Дата: 16.10.08 10:24
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>шарпу в линуке не место.


Ну, незабывайте при таких высказываниях добавлять "IMHO"
Re[4]: программирование под unix
От: DemAS http://demas.me
Дата: 16.10.08 10:26
Оценка:
On Thu, 16 Oct 2008 10:24:16 GMT
"nerozero" <45173@users.rsdn.ru> wrote:

> Здравствуйте, Sheridan, Вы писали:

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

Именно, тем более, что ряд более известных товарищей
(http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%B3%D0%B5%D0%BB%D1%8C_%D0%B4%D0%B5_%D0%98%D0%BA%D0%B0%D0%B7%D0%B0)
считают иначе
Posted via RSDN NNTP Server 2.1 beta
Re[5]: программирование под unix
От: e_k Россия  
Дата: 16.10.08 11:17
Оценка:
DAS>Именно, тем более, что ряд более известных товарищей
DAS>(http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%B3%D0%B5%D0%BB%D1%8C_%D0%B4%D0%B5_%D0%98%D0%BA%D0%B0%D0%B7%D0%B0)
DAS>считают иначе

Более известные товарищи тоже могут заблуждаться.
ИМХО, разумеется
Re[3]: программирование под unix
От: Roman Odaisky Украина  
Дата: 17.10.08 08:49
Оценка: :)
Здравствуйте, Sheridan, Вы писали:

S>шарпу в линуке не место.


А в FreeBSD — место.
До последнего не верил в пирамиду Лебедева.
Re: программирование под unix
От: Dair Россия  
Дата: 20.10.08 21:30
Оценка:
А>нужен совет по выбору 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'ем). Просто разбив предполагаемую программу на такие модули, можно или поискать уже готовое решение для какой-либо части, или просто предположив, что для этой цели этот язык будет более всего удобным.
Re[4]: программирование под unix
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 25.10.08 15:44
Оценка: -2
Здравствуйте, 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]


Никому не кажется, что тут что-то неладно? ;)) Какого лешего автоматом включена защита? Зачем?
The God is real, unless declared integer.
Re[5]: программирование под unix
От: Mr.Cat  
Дата: 25.10.08 16:09
Оценка: 1 (1) -1
Здравствуйте, 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 на чтение-запись с эксклюзивным (в рамках текущего процесса) правом на запись. Ясное дело, что второй поток открыть не удастся. Так будет и под моно, и под майкрософтовским рантаймом.
Re[6]: программирование под unix
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 25.10.08 16:29
Оценка:
Здравствуйте, 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 — тут проблема дотнета в целом...
The God is real, unless declared integer.
Re[7]: программирование под unix
От: _Ursus_  
Дата: 25.10.08 16:45
Оценка:
Здравствуйте, netch80, Вы писали:


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

А то потом находят "проблемы дотнета в целом" на ровном месте.
Re[7]: программирование под unix
От: Mr.Cat  
Дата: 25.10.08 16:46
Оценка:
Здравствуйте, netch80, Вы писали:

N>Резюмирую — имеем чуждую логику и плохо организованную документацию.

Да, уж. "Дьявол в мелочах" — это девиз мелкомягкой документации. Однако не в этом случае.

N>2. Я внимательно перечитал ещё раз описание поведения данного конструктора на msdn.microsoft.com и не вижу никакого подобного утверждения — так что расскажите, пожалуйста, откуда Вы его взяли.


Вы использовали конструктор FileStream(string, FileMode).

Идем в доку по нему (http://msdn.microsoft.com/en-us/library/47ek66wy.aspx) и читаем:

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).


Идем в моновскую доку (http://www.go-mono.com/docs/index.aspx?link=C%3aSystem.IO.FileStream(System.String%2cSystem.IO.FileMode%2cSystem.IO.FileAccess%2cSystem.IO.FileShare)) и читаем:

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.

Re[7]: программирование под unix
От: Mr.Cat  
Дата: 25.10.08 16:52
Оценка:
Здравствуйте, netch80, Вы писали:
N>1. Проблема в том, что я нарвался на это не в C#, а в IronPython, на встроенной функции file(), которой никакого шаринга задать нельзя — не рассчитана она на это. Можно, конечно, сказать, что это ошибка его (IronPython) авторов, и это будет верно. Но это показывает общую идеологическую проблему перетаскивания средства из чуждого мира.

Приведите пожалуйста код на питоне.
Re[8]: программирование под unix
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 25.10.08 16:56
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Идем в доку по нему (http://msdn.microsoft.com/en-us/library/47ek66wy.aspx) и читаем:

MC>

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).


Понятно. Да уж, давно не сталкивался с такими извращениями, отвык.
Посмотрим дальше — если можно обойтись малой кровью (есть ещё десяток примерно таких же по изврату мест), получим неплохую основу, а они — инсталляционную базу. Только вот боюсь, что легче воспользоваться чем-то менее инопланетянским...
The God is real, unless declared integer.
Re[9]: программирование под unix
От: Mr.Cat  
Дата: 25.10.08 17:04
Оценка:
Здравствуйте, netch80, Вы писали:
N>Понятно. Да уж, давно не сталкивался с такими извращениями, отвык.
Мммм... А чего Вы еще ожидали, открывая файл на запись?
Re[8]: программирование под unix
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 25.10.08 17:07
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, netch80, Вы писали:

N>>1. Проблема в том, что я нарвался на это не в C#, а в IronPython, на встроенной функции file(), которой никакого шаринга задать нельзя — не рассчитана она на это. Можно, конечно, сказать, что это ошибка его (IronPython) авторов, и это будет верно. Но это показывает общую идеологическую проблему перетаскивания средства из чуждого мира.

MC>Приведите пожалуйста код на питоне.


Его слишком много.:(( Вырезать показательный кусок на сейчас не могу. Попробую позже.

Есть ещё ряд интересных аспектов. Например, если я пишу f = file(filename, 'r'); print f.fileno(); — получаю, например, 5, в то время как fstat показывает, что это дескриптор номер 15. Источник проблемы приблизительно понятен, но подобное поведение не подходит — надо передать в дочерний процесс дескриптор вместе с его номером.

Чем заменить select или poll в движке событий, я совсем уже не представляю себе.;(
The God is real, unless declared integer.
Re[10]: программирование под unix
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 25.10.08 17:09
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, netch80, Вы писали:

N>>Понятно. Да уж, давно не сталкивался с такими извращениями, отвык.
MC>Мммм... А чего Вы еще ожидали, открывая файл на запись?

Честно ответить?;)) Ожидал стандартного нормального поведения — никаких блокировок и отказов, пока об этом явно не попросили (т.наз. advisory locking). В общем, того, что ожидается от нормального юникса и реализации на нём. И, естественно, тут не должно было быть никакого неестественного интеллекта с решением за меня, что к чему не пускать (в рамках одного процесса — это ж додуматься надо!)
The God is real, unless declared integer.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.