Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Выдаёт такую картинку:
Не получается воспроизвести .
Вызов Dot.Run() приводит к закрытию приложения. FileMon кажет вот такие ошибки:
10:28:03 CSharpGraphvizS:3772 QUERY INFORMATION C:\work\paul\personal\CSharpGraphvizSample\bin\Debug\%WINDIR%\FONTS\Times.ttf PATH NOT FOUND Attributes: Error
10:28:03 CSharpGraphvizS:3772 QUERY INFORMATION C:\work\paul\personal\CSharpGraphvizSample\bin\Debug\%WINDIR%\FONTS\Times.dfont PATH NOT FOUND Attributes: Error
10:28:03 CSharpGraphvizS:3772 QUERY INFORMATION C:\work\paul\personal\CSharpGraphvizSample\bin\Debug\%WINDIR%\FONTS\Times.pfa PATH NOT FOUND Attributes: Error
10:28:03 CSharpGraphvizS:3772 QUERY INFORMATION C:\work\paul\personal\CSharpGraphvizSample\bin\Debug\%WINDIR%\FONTS\Times.pfb PATH NOT FOUND Attributes: Error
10:28:03 CSharpGraphvizS:3772 CREATE C:\work\paul\personal\CSharpGraphvizSample\bin\Debug\c:\temp.bmp.png NAME INVALID Options: OverwriteIf Access: All
10:28:03 CSharpGraphvizS:3772 OPEN C:\work\paul\personal\CSharpGraphvizSample\bin\Debug\c:\ NAME INVALID Options: Open Directory Access: 00000000
Вызов
_dot.TempDir = Path.GetTempPath();
Результата не возимел.
Кстати, а что, Graphviz насмерть завязан на файлы? Т.е. на вход можно только файл на языке dot, а выходе непременно файл с картинкой?
Нельзя туда System.IO.Stream прикрутить?
Павел,
БП>Не получается воспроизвести . БП>Вызов Dot.Run() приводит к закрытию приложения. FileMon кажет вот такие ошибки:
...UZHOS GOES HERE...
БП>Кстати, а что, Graphviz насмерть завязан на файлы? Т.е. на вход можно только файл на языке dot, а выходе непременно файл с картинкой?
Ну ты взгляни на пример — там на вход подаётся простая строка, а файл только на выходе. Брать надо Dot который из Helpers, а не из базового неймспейса.
БП>Нельзя туда System.IO.Stream прикрутить?
Уфф.
extern FILE *aagin, *aagout;
В принципе можно. Только объём работы будет примерно следующим: берём только алгоритмическую часть, а отрисовкой занимаемся сами. В IO.Stream'е, в файле, на абстрактном канвасе, хоть у чёрта на ж***.
А почему так сильно нужен IO.Stream? Политики безопасности мешают прямо файлы создавать?
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Lazy Cjow Rhrr, Вы писали:
S>>>Это понятно, но ведь намного удобнее слева скажем текст вводить, а справа динамически обновляемая картинка... LCR>>Ааа, ты на сайтик заходил? Да, мне тоже понравилось. Ничего подобного для локального использования не видел.
S>*чешет в затылке* S>В принципе софтины то... текст, картинка и поле, и поле ввода, где коммстрока для преобразования одного в другое с кнопочкой "поехали"...
Emacs как всегда впереди планеты всей.
-- Главное про деструктор копирования не забыть --
Извиняюсь не некрофилию, но почему нельзя просто вызывать dot.exe? Это так обязательно, именно в виде библиотеки использовать? Я понимаю, что создание процесса накладно, но если кешировать...
Приветствую, adontz, вы писали:
a> Извиняюсь не некрофилию, но почему нельзя просто вызывать dot.exe? Это так обязательно, именно в виде библиотеки использовать? Я понимаю, что создание процесса накладно, но если кешировать...
Да ты шо, ентож линуховый подход, неспортивно
Здравствуйте, Sheridan, Вы писали:
a>> Извиняюсь не некрофилию, но почему нельзя просто вызывать dot.exe? Это так обязательно, именно в виде библиотеки использовать? Я понимаю, что создание процесса накладно, но если кешировать... S>Да ты шо, ентож линуховый подход, неспортивно
Во-первых, это юниксовый подход. Во-вторых, ненависть к линуксу — это болезнь.
Приветствую, adontz, вы писали:
a> Во-первых, это юниксовый подход.
Пофиг. А в данном контексте вооооооооооооооооооооооооооооооооообче пофиг
a> Во-вторых, ненависть к линуксу — это болезнь.
Ну мне ента болезнь не грозитъ
adontz,
a>>> Извиняюсь не некрофилию, но почему нельзя просто вызывать dot.exe? Это так обязательно, именно в виде библиотеки использовать? Я понимаю, что создание процесса накладно, но если кешировать... S>>Да ты шо, ентож линуховый подход, неспортивно
A>Во-первых, это юниксовый подход. Во-вторых, ненависть к линуксу — это болезнь.
Я так понимаю, генерация картинок может сожрать все ресурсы сервера. Поэтому нужна поддержка ограничений против абузеров — нехороших людей, которые будут генерировать слишком большую картинку, или сразу большую кучу картинок. Даже сейчас есть (давно была?) опасная (тссс!) ситуация с обилием табличных тегов в сообщении из-за чего форматтеру сносило крышу.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Я так понимаю, генерация картинок может сожрать все ресурсы сервера. Поэтому нужна поддержка ограничений против абузеров — нехороших людей, которые будут генерировать слишком большую картинку, или сразу большую кучу картинок. Даже сейчас есть (давно была?) опасная (тссс!) ситуация с обилием табличных тегов в сообщении из-за чего форматтеру сносило крышу.
Ну так тем лучше. Отдельный процесс можно запускать с крайне низким приоритетом и вообще асинхронно.
adontz,
A>Ну так тем лучше. Отдельный процесс можно запускать с крайне низким приоритетом и вообще асинхронно.
Как ему (dot.exe-у) ограничить прожорливость в смысле оперативной памяти? В смысле пиковое потребление памяти может быть очень большим. (Память по-прежнему ресурс на сервере).
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Как ему (dot.exe-у) ограничить прожорливость в смысле оперативной памяти? В смысле пиковое потребление памяти может быть очень большим. (Память по-прежнему ресурс на сервере).
adontz,
LCR>>Как ему (dot.exe-у) ограничить прожорливость в смысле оперативной памяти? В смысле пиковое потребление памяти может быть очень большим. (Память по-прежнему ресурс на сервере).
A>Через Job Object
Ок (хотя не ведаю, шо это такое, но видимо вещь хорошая). Как защититься от дыр и переполнений буферов в самом dot.exe? Я полагаю надо организовать маленький такой сэндбоксик на каждый вызов dot.exe. Или пул сэндбоксиков... Да?
Здравствуйте, AndrewVK, Вы писали:
AVK> Хватит уже зря мечтать. Вариант с внешней программой малоприемлем для януса, nntp, авалона и диска к журналу.
А если попробовать заюзать внешний сервис генерации картинок, а потом их у себя кэшировать? Т.е., по большому счету, картинка же генерится один раз при создании сообщения (или его первом отображении), потом ее забираем, кладем себе и храним сколько жаба позволяет, а форматтеру останется только подставить нужный img src, который можно вычислять каким-нибудь хэшем от содержимого тэга.
Я не думаю, что тэг будет уж очень сильно востребован, чтобы этих картинок было жутко много или чтобы можно было просадить сервис генерации.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вариант с внешней программой малоприемлем для януса, nntp, авалона и диска к журналу.
Вариант с внешней программой по области своей применимости абсолютно ничем не отличается от варианта с внешней неуправляемой DLL. Как техническое обоснование отказа не катит.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>adontz,
LCR>>>Как ему (dot.exe-у) ограничить прожорливость в смысле оперативной памяти? В смысле пиковое потребление памяти может быть очень большим. (Память по-прежнему ресурс на сервере).
A>>Через Job Object
LCR>Как защититься от дыр и переполнений буферов в самом dot.exe?
Думаю, запускать его от имени NETWORK SERVICE вполне достаточно.
LCR>Я полагаю надо организовать маленький такой сэндбоксик на каждый вызов dot.exe. Да?
см. выше. Учётная запись NETWORK SERVICE вполне себе sandbox как раз для таких случаев.
Здравствуйте, adontz, Вы писали:
a> Это гораздо лучше, чем совсем никакой идеи. Кроме того, что мешает вместе с Янусом ставить Graphviz?
+1. В avalon это именно так и реализовано — стоит пакет — рисуем красивые картинки, нет пакета, выдаем as-is. Можно вместо as-is приделать внешний веб-сервис (если кто знает таковой, с которым просто работать наподобии формул LaTeX).
.
Уфф. 
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Да, мне тоже понравилось. Ничего подобного для локального использования не видел.
