- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
#!/bin/sh
# ...
# translate args from unix path to windows, if possible (eterbug #4933)
args_to_winpath()
{
for i in "$@" ; do
local TP="$i"
local TR=${i/\~/$HOME}
if [ -r "$TR" ] ; then
WP=$(winepath -w "$TR" 2>/dev/null)
[ -z "$WP" ] || TP="$WP"
fi
echo "$TP"
done
}
# ...
run_wine $(args_to_winpath "$@")
Это WINE@Etersoft. Люди пытались преобразовать системные пути в командной строке во внутренние вайновские. В результате из C:\Program Files больше ничего не запускается.
Follow us!
если бы не /bin/sh a /bin/bash стоял, то можно было на массив переделать. в массиве пробелы должны нормально обрабатываться. работающий пример:
Один хрен башизм.
Кстати, такие извращенцы, пишут [ -z "$WP" ] || TP="$WP" вместо [ "$WP" ] && TP="$WP". Впрочем, на любителя, но мне кажется, что второе понятнее, через положительное условие.
а по поводу [ "$WP" ], это дело вкуса. мне код читается как "если wine_path вернул ошибку".... хотя я лично бы не стал полагатся на stdout в таком случае. я уж на cygwin в свое время подобного гавна наглотался....
Я особо в их код не вникал, но по тому, что я смотрел (особенно учитывая что для компилирования под винду требуется cygwin), то впечатление такое: для совместимости с виндой они реализовали с помощью posix'а частично виндовое API, напр. в processes.c содержится функция CreateProcess.
Под линуксом-то ОК, а вот под виндой моно ведёт себя так забавно: если кодообезьянка пишет new Process(..).Start(), то эта функция вызовет ves_icall_System_Diagnostics_Process_Cre ateProcess_internal, которая вызовет кустарное CreateProcess, которое вызовет fork & execv, которые под виндой в цигвине будут переделаны опять в CreateProcess. Вот же ж пиздец - практически 4 слоя абстракции. То-то моно тормозит.
Хотя могу ошибаться..
Другой вопрос что стандарты разрабатывали с оглядкой на архитектуру nt а не posix, так что mono это конечно забивание шурупов стамеской в кирпич)
Кстати, а зачем mono под винду? Под винду есть реализация .NET от microsoft -- и она даже бесплатная, и даже SDK (компилятор) тоже бесплатный
1) До сих пор есть несовместимости, т.е. под моной может быть иное поведение, нежели под .НЕТ
2) Моно помимо BCL представляет ещё собственных полезных классов в неймспейсу Mono.*, которых нет в .NET + например моно на уровне рантайме поддерживает continuations, а Windows - нет.
3) Более свободный софт-таки)
> Ну mono все таки реализация по стандарту (C# акме скрипт, да и .NET/CLR -- стандарт).
Не, пойнт в том, что можно было бы сделать ифдефы, чотбы под виндой вызывалось не кустарное CreateProcess, а родное винапишное. Я точно не уверен, прав ли я, но проглядев код по диагонали, не нашёл, чтобы вызывалось именно винапишное...
5) Тулза mkbundle, позволяющая сжать весь рантайм в стандалоне эксешник
а так, mono ничем особо не отличается от большинства опенсорсных поделок... те тоже расчитаны в основном на юниксы и в последнюю очередль только портируются под винду, с разными слоями абстракции и костылями...
А я под виндой залез в неймспейс Microsoft, и тоже многое насчитал.
А еще (бьюсь об заклад!) в Mono нет PInvoke и COMInterrop :)
И как у него c MSMQ например?
COMInterop -- есть.
MSMQ - не знаю. Есть System.Messaging и Mono.Messaging, Mono.Messaging.RabbitMQ.dll. Обычно когда в .NET какой-то набор классов кривой или непортируемый, то они делают свою версию с какими-то линукс-специфичными биндингами. Судя по мануалу, основной функционал System.Messaging у них реализован. За свистелками/перделками -- Mono.Messaging...
> А я под виндой залез в неймспейс Microsoft, и тоже многое насчитал.
В профиле mono CLR 2.0 находится 8 библиотек с префиксом Microsoft.
Тоже верно. А кстати, call convension у gtk и win32api совпадает (извините, если это глупый вопрос)?
>>COMInterop -- есть.
Даже на никсах?
> Даже на никсах?
.NET это не common denominator, как ява. Нет, под линукс COM'а нет...
> кстати, call convension у gtk и win32api совпадает (извините, если это глупый вопрос)?
У win32api -- stdcall, у гтк - хрен его знает. Если посомтреть рефлектором, то нигде calling convension не указан, т.е. дефолтится к stdcall. Но это под виндовс, может быть, это специфика сборки гтк под виндовс (libgtk-win32-2.0-0.dll), не знаю.
Ох, доиграется новел..
Считает Столлман:
http://www.fsf.org/news/dont-depend-on-mono
p.s. Вот какие это либы:
Microsoft.Build.Engine.dll
Microsoft.Build.Framework.dll
Microsoft.Build.Tasks.dll
Microsoft.Build.Utilities.dll
Microsoft.JScript.dll
Microsoft.VisualBasic.dll
Microsoft.VisualC.dll
Microsoft.Vsa.dll
Для всего этого есть родные замены, если будут какие-то угрозы - просто удалят из дистра и заменят аналогами.
Разве не лучше было бы сделать человеческий гуй к java?
Или сделать C# для JVM?
или кому-то CLR нравится больше, чем JVM?
Кстати, кто разрабатывает стандарты C# и .NET? Microsoft? Есть ли там аналоги JSR?
> Или сделать C# для JVM?
Это не возможно. JVM не поддерживает указателей, типов по значению, делегатов, свойств, PInvoke и много ещё того, что есть в C# и CLR. В то же время JVM легко хостится внутри CLR (см. IKVM)
> или кому-то CLR нравится больше, чем JVM?
CLR намного больше, чем JVM.
> Кстати, кто разрабатывает стандарты C# и .NET? Microsoft? Есть ли там аналоги JSR?
Microsoft, периодично пропихивая в ECMA. JSR вроде никаких нету.
В чем это заключается? В том, что там не принято засирать язык уродствами типа LINQ и ключевого слова "var"?
И слава Богу)
Хотя скорость разработки java и правда оставляет желать лучшего.
>>это очень бюрократический продукт (нужно проходить сертификации, чтобы называть ява-машиной)
Да, с другой стороны это некоторая гарантия качества, нет?
>>Это не возможно. JVM не поддерживает указателей
Да, там есть только ссылки (хотя и называются они указателями), но кроме как для PInvoke я не знаю, зачем это надо.
>>типов по значению
Это факап джавы, согласен. Отсутствие структур, и невозможность передать через стек ничего, кроме примитивов -- это плохо.
>>PInvoke
PInvoke это все таки часть CLR а не C#.
>>CLR намного больше, чем JVM.
И то и другое -- присловутая платформа, хотя в CLR больше всего.
>>Microsoft, периодично пропихивая в ECMA. JSR вроде никаких нету.
Вот отсутствие JSR это конечно плохо.
Если я хочу новую фичу в джаве -- я могу поднять бучу, и через пару лет добится JSR (а это уже стандарт), а еще через пять лет это будет в новой джаве)
А как добиться этого от microsoft?
И слава Богу)
Да, LINQ как-то избыточен (для меня -- потому что лично мне не нужен), но чем плох var?
Не знаю, в яве буквально всё пропитано духом 90-ых. Вы так не чувсвтвуете?
Да и ява сейчас явно в позиции догоняющего: дженерики, форичи, энумы - все эти "уродства" перенято после сишарпа. Того гляди в следующей версии окажется и var.
> Да, с другой стороны это некоторая гарантия качества, нет?
Ну да. Тут как дилемма: или юзать стабильный Дебиан пятилетней длавности или нестабильную только вышедшую Убунту которая и удобнее, и поддерживает больше современного софта/железа и т. п. Оба варианта хороши, зависит от того, что требуется: функционал или стабильность.
> Это факап джавы, согласен. Отсутствие структур, и невозможность передать через стек ничего, кроме примитивов -- это плохо.
Да, и сэмулировать средствами JVM их поведение было бы очень накладно. Поэтому есть java для .NET (J#), но нет и не было C# для JVM (хотя есть проект GrassHopper, но там наверное куча костылизма и эмуляции).
> PInvoke это все таки часть CLR а не C#.
C# Language Specification
10.5.7 External methods
"When a method declaration includes an extern modifier, that method is said to be an external method. External methods are implemented externally, typically using a language other than C#. Because an external method declaration provides no actual implementation, the method-body of an external method simply consists of a semicolon.
The extern modifier is typically used in conjunction with a DllImport attribute (Section 10.5.1), allowing external methods to be implemented by DLLs (Dynamic Link Libraries). The execution environment may support other mechanisms whereby implementations of external methods can be provided."
> А как добиться этого от microsoft?
НЕ знаю. В .NET нельзя, но в mono -- можно.
Если бы он был библиотекой -- хрен с ним. Но зачем же его в синтаксис пихать? Давайте еще регулярки и сортировку пихнем, как в перле. Потом средства для работы с XML, и язык превратится в нечетаемую кашу.
>> но чем плох var?
Есть хорошие языки со статической типизацией (C# 2.0, Java).
Есть хорошие без нее (python).
Если мы начнем мешать всё в кучу, то получим PHP.
>>Не знаю, в яве буквально всё пропитано духом 90-ых. Вы так не чувсвтвуете?
Они действительно ретрограды. С одной стороны это плохо, с другой -- защищает язык от linq:)
>>дженерики
Дженерики в джаве -- очень больная тема(. Почти в любой программе есть строки @SuppressWarning("unchecked") :(
>> Дебиан пятилетней длавности или нестабильную только вышедшую Убунту которая
В 80% случаев хватит дебиана, имхо))
iptables, apache, vsftpd, perl, php, squid, nginx, java, ради всего этого большинство простых людей ставит линух -- и все это было 5 лет назад)
Проецируя на программирование: Многие программы можно написать на java 1.4.
И я не верю, что какую-то программу не смогли написать на java, потому что она не поддерживает замыканий или рантайм генериков)
>>Поэтому есть java для .NET (J#),
Там какой-то слой абстракции сверху. И проект кстати накрылся, потому что джавистам проще было выучить C#, чем въехать в тонкие отличия java и J#.
Есть еще IKVM (я его юзал для работы с saxon из под .net), но это какой-то изврат, конечно.
Если бы он был библиотекой -- хрен с ним. Но зачем же его в синтаксис пихать?
Да в принципе сишарп тут недалеко ушёл от питона с его, например, list comprehensions. Ничё не напоминает: http://tirania.org/tmp/xbyhja.png
;)
>> Есть хорошие языки со статической типизацией (C# 2.0, Java).
Есть хорошие без нее (python).
> Если мы начнем мешать всё в кучу, то получим PHP.
Причём здесь это? var это выведение типа, а не слабая типизация. Это совершенно никак не относится к питону.
Если есть код:
То у переменной s будет тип StringBuilder и его поменять будет нельзя. Это просто shorthand для:
чтобы не писать дважды тип. Как в бейсике:
> Там какой-то слой абстракции сверху. И проект кстати накрылся, потому что джавистам проще было выучить C#, чем въехать в тонкие отличия java и J#.
Слой абсракции -- это библиотеки явы поверх дотнетовых. Обычное дело. Накрылся потому что проект с самого начала был гнилой, только как приманка. Инттересно ещё будет унать, что j# разрабатывала команда индусов
Извините! листы и мапы были частью питона изначально. Если бы в каждую новую версию питона стали вводить по 10 новых "улучшений языка" -- он быстро потерял бы простоту и привлекательность.
Кроме того встроенные коллекции есть во многих языках (тот же перл например), и в этом нет ничего плохого. Вас же не смущают встроенные массивы? А ведь они есть даже в С:)
А вот встроенного "языка запросов" кроме C# я что-то нигде не видел.
>>var это выведение типа
А разве тип вара вычисляется не в рантайме?
Тогда как же он работает с linq?
Afaik (хотя могу конечно наврать) var был введен нименно для linq, потому что его результат не всегда сразу известен.
Кстати злые языки говорят, что в джаве 7 можно будет не указывать генерики при создании объекта: они будут браться из типа.
>>начала был гнилой, только как приманка.
Интересно, какая судьба ждет managed C++ ?:)
Инновации... (Затухающее эхо.) Инновации... (Едва слышно.) Инновации...
>>var это выведение типа
>А разве тип вара вычисляется не в рантайме?
Это 100% компайл-тайм.
> Тогда как же он работает с linq?
Через интерфейсы.
Напр. в
У переменной numQuery тип в компайл-тайме определён как IEnumerable<int>. Т.е. можно по сути вместо var писать IEnumerable<int>. А внутренняя реализация - System.Linq.Enumerable.WhereArrayIterato r<int> (это класс недоступен публично).
>> MyClass<> foo = new MyClass<Bar>();
Офигенная фича)
пиздить то, что было в лиспах/хацкелях/фортранах писят лет назад - это не инновации
Лист компрехеншн были писят лет назад, но не встроенные запросы.
И неужели сарказма не видно?)
От наркобарыг до международных отношений.
Какая-то компания Ванг давным давно запатентовала метод "получать справку о задаче от другого приложения для успешного завершания задачи". В конце концов её купил Кодак. И Кодак засудил Сан за то, что они "получают справку о задаче от другого приложения для успешного завершания задачи" без отчисления лицензий.
Патенты - это такая смешная штука, что любое опенсорс-поделие 100% нарушает хотя бы один патент, а, стало быть, всё под угрозой, давайте ничего не использовать. Я уверен, что эмакс Столлмана нарушают кучу патентов.
И, вобщем, придираться конкретно к моно потому что она "опасна на патенты" - это лицемерие-оправдание, ведь люди ненавдият моно только потому что она реализуют фреймворк от Большого Злого Дяди Майкрософт, больше причин нет. Патенты, "подсаживание" - это оправдание ненависти. Одни и те же люди кричат "патенты на ПО - лукавое говно тролля" и "моно - в опасности патентной угрозы". Взаимоисключащие параграфы никто не видит?
Такие вот дела.
Только вот боязнь у него какая-то, скажем так, выборочная. Т.е. на моно у него нападки есть, на какие-то иные платформы - нет.
> Так что я полностью согласен с тем, что предупредить людей об опасности надо, особенно когда технология становится гиперпопулярной.
Столлман говорит, что моно опасна, потому что она нарушает мифические патенты и что в неясном будущем майкрософт может их затребовать. Зона риска - это Winforms и подобное ему говно, не покрытое ECMA & обещанием. Я не очень понимаю, как это является угрозой. То моно, которое получает популярность в линуксовых дистрах, это моно + гтк. Юридически майкрософт не могут взять и "убить" моно, максимум - потребовать исключения не-ECMA-компонентов, и юмор, в том, что их никто больно-то и не использует (ASP.NET и Windows входят в так называеемый "Microsoft-compatibility stack.")
Т.е. Столлман спит и видит, как одно прекрасное утро весь Гном входит в анальную оккупацию МС. Но это не так. Если вдруг будут какие-то нападки - никто ВООБЩЕ ничего не заметит. Fspot, Banshee и проч. не юзают Microsoft-compatibility stack (они под виндой вообще не запускаются). Ну перестанет Мигелюшка поддерживать Winforms -- и что? 1) Линуксовые пользователи и программисты ничего не заметят 2) Такое решение только ухудшит позиции .NET'а вне Windows и будет только убыль.
Вообще речи Столлмана похожи на "не выходи на улицу, на голову может упасть кирпич", и явно, что он мало ознакомлен с темой, такой тупой рефлекс: видишь слово "Майкрософт", начинай орать и визжать.
По существу вопроса, к сожалению, ничего не могу сказать, этот вопрос (возможные проблемы с патентами в опенсурсной реализации) не изучал, так что дай-то Бог, чтобы все было хорошо. А там посмотрим:)
Что до речей, то общая ситуация с каким-то лидером, что он должен быть вдвое укрепленнее в соответствующей идее, его последователи тогда будут нормальными носителями идеи, обычное затухание при передаче.
Примерно так:
Столман: ахтунг, нам всем пиздец!
Общество: так, похоже есть проблема.
супротив
Столман: Есть проблема....
Общество: А, опять хуйня какая-то, пофиг.
А чего сомтреть, моне уже 7-8 лет. А сколько дотнету? 10. И ни разу не было никакой претензии.
Кстати, идеи моно постепенно переходят в дотнет. Например, в моно первыми придумали не реализовывать маршаллинг вручную, а через использование экстра-опкодов + джиттер, т.е. пока под в Майкрософт вручную делали нативные-переходы-трамполины для каждой платформы (а чего, майкрософт поддерживает только две - x86 и x64), в то время как в моно процесс был автоматизирован под все платформы. И только в NET 4.0 майкрософтцы стали делать так же (как всегда делая вид что сами дошли :) ).
Ещё есть несколько подобных примеров.
Пока что все-таки не так много народа пользуется, по сравнению с C++, разве нет? У меня цифр нет, но процесс распространения в массы по ощущениям начался где-то года 2-3 назад. Поправьте, если я не прав.
Ну да, где-то так. Т.е. идея такова, что МС заявляется, только когда моно сверхпопулярна - и тогда линукс зохвачен? А до того молчит и претензий не выдвигает?
Ну так это линупсоиды о себе многое думают. < 1% это прям такой огромный соперничащий рынок для майкрософт, чтобы воплощать какие-то грандиозные хитрые планы по его захвату.
У Майкрофоста есть куда больше проблем с Гуглом, с Эпплом, с Сони, чем с мало кому нужным линуксоид-сообществом. Сперва мы должны увидеть, как Майкрософт зохватывает Эппл (моно хоть и заводится на МакОси, но куда менее популярна чем в Лине)...
С позиции МС моно это "детишки возятся в песочнице", сдались они ему.
Ну да ладно, Столмана отмазывать не буду, хоть его паранойю и разделяю.
Часть можно, часть - нет.
Напр., Mono.Posix - винда не позикс... Или Mono.Tasklets - корутины поддерживаются только рантаймом моно. В моно можно сделать микропотоки (см. Mono.MicroThreads), что очень полезно для геймдева, а в .НЕТ - куй.
Вроде бы Mono.Simd можно вставить в .NET, только будет жутко тормозить... В моно-то оно интринзик jit-компилятора...
>>часто используют под win98
Слова "win98" и "часто" стоящие рядом -- пугают меня в 2010м году.