Специально спрашивал у американцев как звучит. Именно так )
Вы ведь переводите, а не транскрибируете. Вот и переводите.
А как там американцы произносят свои названия — это их личные трудности. Они и Рейгана «Риганом» называли, и Чикаго у них «Шикагоу».
Я помню как в 80-х говорили именно так: КОБОЛЬ и ФОРТРАН. До сих пор говорят «си плюс плюс», а не «си плас плас».
«Коболь» никогда не говорили. Потому что в русском языке окончание «ол» в названиях языков всегда было твердым: алгол, кобол.
Вообще, удивлен вашей отсылкой к 80-м годам. Мало ли что было тогда — то была совсем другая эпоха, эпоха ЭВМ, АЦПУ, НГМД и прочих КУВТ ДВК. Вы пишете перевод не для ископаемого советского инженера, заправляюшего свитер в трусы, а бороду в брюки. Вы пишете для современной аудитории.
это уже на мой взгляд не близко к тексту )
Меняйте взгляды.
Хороший перевод — это не подстрочник, который нужно разгадывать, а текст, максимально точно, полно и понятно передающий написанное в оригинале.
Мне не хотелось использовать готовые решения в виде веб-сервисов, по появилась мысль написать консольную утилиту, которая бы прошлась по всем файлам и устанавливала расширения автоматически. Для написания утилиты был выбран Python по многим очевидным причинам.
В линуксах существует прекрасная утилита 'file', которая делает ровно то, что вам нужно: определяет тип файла по содержимому. И есть готовая ее сборка для windows. Правда, она выдает слишком многословный выхлоп, но жизнь можно упростить использованием ключа -i (выдавать mime-type вместо подробного описания).
Вызываем ее как внешнюю команду из своего скрипта, парсим выхлоп и переименовываем по мере сил. По крайней мере, она умеет отличать файлы docx от зип-архивов. :)
Мы будем считывать лишь первые 32 байта, так остальные нам попросту не нужны, а полное считывание большого файла будет занимать много времени.
Некоторые форматы содержат нули далеко за пределами 32 байт. Например, в файлах ISO чуть ли не 16 килобайт с начала файла — нули. :)
Но ведь rm -r должна была удалить файлы, лежащие в каталоге ostechnix, правильно?
То есть получается, что maybe еще и файловые пути выводит неправильно.
Думаю, если запихнуть обычный HDD в масло, он долго не протянет. Потому как негерметичен, а в масле блины не шибко раскрутишь.
Другое дело SSD — там движущихся деталей нет.
Интересны в этом плане надутые гелием HDD — они-то должны быть герметичны по определению, т.к. гелий через любое отверстие улетучится за считанные часы.
Однако не редконередко они сами этого не знают и довольствуются тем, что есть.
Сурово пишете, но неубедительно. :)
Забавно, что если выключать винду при открытом главном окне VirtualBox — вылезает пачка абсолютно бессмысленных мессаджбоксов про то, что не удалось что-то там «с ключём». Хэдлайнеры мейнстрима, ля.
А финансы — это почти единственное, что Вам смогут предложить для переманивания.
Нет, ну почему же. Зависит от обстоятельств. Бывают начальники-временщики, которым главное — закончить текущий проект и уйти на повышение, а дальше хоть трава не расти.
Могут предложить релокейшен в зарубежный офис, например. Сам такое наблюдал.
Правда, если согласишься — то начинается тянучка: «ну, ты же понимаешь, сначала надо проект закончить / с бухгалтерией все решить / вызов оформить / еще какая-нибудь отмазка из списка».
Конвертор для Рус <-> Лат написать даже на Lua не проблема. Т.о. создаётся закрытая экосистема и лояльные пользователи. Условно назовём эту версию LuaPLUS
LuaPLUS — это если в язык добавить поддержку нелатиницы и выпустить локализации на нескольких языках.
А то, что вы предлагаете, — это кривенькая русификация. Тогда уж давайте это чудо назовем LuaRUS.
Что для этого надо сделать? необходимо добавить в исходники lua возможность использовать:
русские имена переменных и функций
1. В какой кодировке? UTF-8? Или windows-1251?
2. Насколько я понимаю, для поддержки национальных кодировок достаточно подмандить парсер.
Получение денег от краудсорсинга – если проект зацепит, скорей всего можно будет собрать какуюто сумму денег с разработчиков торговых роботов для QUIK и разработчиков игровых движков
Собственно от Вас мне бы хотелось получить оценку идеи,
«Осень, осень плёхо».
Ну сами-то прикиньте на пальцах.
Сколько там в луа зарезервированных слов? Десятка два (включая стандартную библиотеку)? Выучить их — абсолютно не проблема, кому надо — тот на бумажке напишет.
Текст компьютерной программы все равно не похож на нормальный русский язык, даже если перевести все словеса на русский язык. Т.е. человеку все равно придется хоть как-то вникать в синтаксис языка.
Что касается сообщений об ошибках — в луа они бывают весьма бестолковыми (следствие упрощенного синтаксиса). Человека, не знакомого с программированием, они только собьют с толку.
Опять же, чтобы вносить в программу какие-то осмысленные правки, человек должен хоть немного понимать принцип работы программ.
Вы что же думаете, человек без опыта в программировании придет, откроет текст торгового плагина для QUIK, увидит там русские буквы и сразу же все поймет? И сразу же сможет написать свой похожий плагин? Это будет чудо.
LuaPLUS это не для программистов, это для конечных юзеров которые программистами не были и ими никогда не станут.
Тогда они не смогут сделать с модулем ничего осмысленного независимо от того, какие там в тексте слова — русские или английский.
Для них просто хорошё, а ещё проще ещё лучше.
Хорошё, значит… М-да.
Давайте посмотрим, посмеемся:
Исходный текст на луа (взят с какого-то онлайн-туториала):
function square(iteratorMaxCount,currentNumber)
if currentNumber<iteratorMaxCount
then
currentNumber = currentNumber+1
return currentNumber, currentNumber*currentNumber
end
end
for i,n in square,3,0
do
print(i,n)
end
Теперь переведем его на русский:
функция квадрат(итераторМаксКолич,текущийНомер)
если текущийНомер<итераторМаксКолич
тогда
текущийНомер= текущийНомер+1
возврат текущийНомер, текущийНомер*текущийНомер
конец
конец
для и,н в квадрат,3,0
делай
печать(и,н)
конец
Я б не сказал, что стало понятнее. Смешнее — да. Понятнее — нет.
Да ничего вы толком не описали. Так, общие рассуждения и минимум конкретики.
Самое обидное — вы оставили за бортом самый главный вопрос: с чем боремся-то? С жЫром или с тормозами?
А вот это не так — достаточно сравнить программы разных версий, тот же браузер. Ну или заняться более глубоким анализом.
Браузер — очень неудачный пример. Поддержка свежих стандартов в новых версиях небесплатна и требует добавления кучи кода, не нужного ранее.
Вот если взять классический пример «блоатвари» — просмотрщик ACDSee, то да, была легенькая фиговинка, стал монструозный комбайн с кучей мало кому нужных функций. Но тут — опять же — возникает вопрос: так ли здесь важен язык программирования или фреймворк? Потому как гораздо важнее — решения по добавлению в программу всяческого барахла, принятые менеджерами.
Мешанина какая-то.
Ну да, драйстоуны, ветстоуны, компиляторы, интерпретаторы, байткод, кэш, code bloat — все это прекрасные слова, но зачем вы все это свалили в одну кучу и приправили жиденькими, бесполезными рекомендациями?
Рекомендации должны быть предметными, а не «вообще».
— Важна производительность именно вычислительная? Тогда — компилируемые языки, многопоточность, распаралеливание, использование GPU (OpenCL, CUDA), распределенные вычисления. У вас из всего этого — только мутноватые рассуждения о производительности и издевательские рекомендации писать на ассемблере. Издевательские — потому что современные компиляторы генерируют код весьма высокого качества, а попытки оптимизировать его вручную обычно приводят к тому, что «оптимизированная» программа работает медленнее оригинала. Кроме того, писать на ассемблере под тот же ARM — занятие для истинных гурманов.
— Важен отклик пользовательского интерфейса программы? Тогда — правильное проектирование, обработка длительных операций в отдельном потоке, и пофиг на язык программирования. Время комфортного отклика на действия пользователя — ЕМНИП, что-то около 250 миллисекунд. На такую производительность вполне способны даже весьма медленные языки программирования.
— Важен малый объем программы? Тогда — использование «легких» фреймворков, языков программирования, выдающих компактный результирующий код, и т. п.Но лично мне проблема «жира» в программах кажется слегка надуманной: на десктопных компьютерах основное ОЗУ жрут картинки и иконки, а на всяческих маломощных контроллерах обычно выбор языка программирования невелик: или пишешь на том, что предоставил производитель контроллера, или не пишешь вообще.
Если оклад зависит от часов — люди будут спать, заниматься своими личными делами и т. п. на работе.
Если оклад фиксированный плюс штрафы/бонусы — то будет повышенная текучка. Это только в воспаленном мозгу директора, получающего фиксированный оклад, может возникнуть мысль, что штраф приведет к повышению качества работы. По факту штраф — это обида сотрудника на компанию, т.к. в большинстве случаев сотрудник себя виноватым не считает. Плюс снижается его уверенность в завтрашнем дне.
Если человек не может спланировать расходы из-за того, что его зарплата «болтается» туда-сюда из-за штрафов и бонусов — это минус. Допустим, к бонусам можно отнестись как к неожиданному приятному сюрпризу (при этом приязнь не переносится на компанию). Но вот штраф — однозначно трактуется как «меня тут не ценят». Как следствие — пара штрафов, и специалист уходит к конкурентам, которые не внедряют таких «прогрессивных схем оплаты».
И ещё, я предполагаю что там ошибка в утилите, потому как там в результате выводятся сектора через интервал, меньший чем размер области. Это подходит для обоих вариантов мегабайта. По крайней мере так происходит на больших значениях. 420 пробовал.
Вот, собственно, код, который вычисляет границы области:
// we have a span. Define its lower and higher boundaries.
qint64 const offset = ( badBlock * SECTORSIZE ) / minSpan;
qint64 const lowBlock = ( offset * minSpan ) / SECTORSIZE;
qint64 const uppBlock = lowBlock + minSpan / SECTORSIZE;
minSpan — это размер области в байтах, badBlock — номер сбойного сектора, SECTORSIZE = 512.
Итого теоретически имеем:
— lowBlock выравнивается на нижнюю границу области (в секторах).
— uppBlock — тупо прибавляем к lowBlock размер области в секторах.
Как оно могло выдать интервал, меньший размера области — не понимаю. :)
Действительно, я как-то упустил этот момент.
Просто для меня запуск утилит, напрямую работающих с устройствами через файлы в /dev/ — нечто само собой разумеющееся.
Добавлю к комментарию.
Не соглашусь. В IT далеко не все быстро меняется.
Основные технические принципы и решения живут десятилетиями и не меняются.
Основные платформы, языки программирования живут десятилетиями и тоже практически не меняются.
Революции в IT — редкость.
А вот когда в IT влезает политика и бизнес — тут-то и начинаются перемены. Вот только напоминают они мне заполошную беготню туда-обратно:
«Р-р-р-революционное решение! Переворот! Такого еще не было!»
(через год) «Новое рррреволюционное решение взамен устаревшему! Срочно бежим в другую сторону!»
(еще через год) «Мы бежали не туда, но теперь — все поменялось!»
ru.wiktionary.org/wiki/%D0%BA%D0%BE%D0%B1%D0%BE%D0%BB
Вы ведь переводите, а не транскрибируете. Вот и переводите.
А как там американцы произносят свои названия — это их личные трудности. Они и Рейгана «Риганом» называли, и Чикаго у них «Шикагоу».
«Коболь» никогда не говорили. Потому что в русском языке окончание «ол» в названиях языков всегда было твердым: алгол, кобол.
Вообще, удивлен вашей отсылкой к 80-м годам. Мало ли что было тогда — то была совсем другая эпоха, эпоха ЭВМ, АЦПУ, НГМД и прочих КУВТ ДВК. Вы пишете перевод не для ископаемого советского инженера, заправляюшего свитер в трусы, а бороду в брюки. Вы пишете для современной аудитории.
Меняйте взгляды.
Хороший перевод — это не подстрочник, который нужно разгадывать, а текст, максимально точно, полно и понятно передающий написанное в оригинале.
Пурду, ага. В Вестном Лафайетте, государство Индияна.
Коболь, фортрань, паскал.
Смешно.
It seemed more «business» of the two означает «мне казалось, что кобол больше связан с реальным бизнесом».
В линуксах существует прекрасная утилита 'file', которая делает ровно то, что вам нужно: определяет тип файла по содержимому. И есть готовая ее сборка для windows. Правда, она выдает слишком многословный выхлоп, но жизнь можно упростить использованием ключа -i (выдавать mime-type вместо подробного описания).
Вызываем ее как внешнюю команду из своего скрипта, парсим выхлоп и переименовываем по мере сил. По крайней мере, она умеет отличать файлы docx от зип-архивов. :)
Некоторые форматы содержат нули далеко за пределами 32 байт. Например, в файлах ISO чуть ли не 16 килобайт с начала файла — нули. :)
Поэтому — вместе х2.
maybe has prevented rm -r ostechnix/ from performing 5 file system operations:
delete /home/sk/inboxer-0.4.0-x86_64.AppImage
delete /home/sk/Docker.pdf
delete /home/sk/Idhayathai Oru Nodi.mp3
delete /home/sk/dThmLbB334_1398236878432.jpg
delete /home/sk/ostechnix
Но ведь rm -r должна была удалить файлы, лежащие в каталоге ostechnix, правильно?
То есть получается, что maybe еще и файловые пути выводит неправильно.
Другое дело SSD — там движущихся деталей нет.
Интересны в этом плане надутые гелием HDD — они-то должны быть герметичны по определению, т.к. гелий через любое отверстие улетучится за считанные часы.
Картина Репина «Приплыли»: всю ночь гребли, а лодку отвязать забыли.
Сурово пишете, но неубедительно. :)
Забавно, что если выключать винду при открытом главном окне VirtualBox — вылезает пачка абсолютно бессмысленных мессаджбоксов про то, что не удалось что-то там «с ключём». Хэдлайнеры мейнстрима, ля.
Нет, ну почему же. Зависит от обстоятельств. Бывают начальники-временщики, которым главное — закончить текущий проект и уйти на повышение, а дальше хоть трава не расти.
Могут предложить релокейшен в зарубежный офис, например. Сам такое наблюдал.
Правда, если согласишься — то начинается тянучка: «ну, ты же понимаешь, сначала надо проект закончить / с бухгалтерией все решить / вызов оформить / еще какая-нибудь отмазка из списка».
LuaPLUS — это если в язык добавить поддержку нелатиницы и выпустить локализации на нескольких языках.
А то, что вы предлагаете, — это кривенькая русификация. Тогда уж давайте это чудо назовем LuaRUS.
1. В какой кодировке? UTF-8? Или windows-1251?
2. Насколько я понимаю, для поддержки национальных кодировок достаточно подмандить парсер.
«Осень, осень плёхо».
Ну сами-то прикиньте на пальцах.
Сколько там в луа зарезервированных слов? Десятка два (включая стандартную библиотеку)? Выучить их — абсолютно не проблема, кому надо — тот на бумажке напишет.
Текст компьютерной программы все равно не похож на нормальный русский язык, даже если перевести все словеса на русский язык. Т.е. человеку все равно придется хоть как-то вникать в синтаксис языка.
Что касается сообщений об ошибках — в луа они бывают весьма бестолковыми (следствие упрощенного синтаксиса). Человека, не знакомого с программированием, они только собьют с толку.
Опять же, чтобы вносить в программу какие-то осмысленные правки, человек должен хоть немного понимать принцип работы программ.
Вы что же думаете, человек без опыта в программировании придет, откроет текст торгового плагина для QUIK, увидит там русские буквы и сразу же все поймет? И сразу же сможет написать свой похожий плагин? Это будет чудо.
Тогда они не смогут сделать с модулем ничего осмысленного независимо от того, какие там в тексте слова — русские или английский.
Хорошё, значит… М-да.
Давайте посмотрим, посмеемся:
Исходный текст на луа (взят с какого-то онлайн-туториала):
Теперь переведем его на русский:
Я б не сказал, что стало понятнее. Смешнее — да. Понятнее — нет.
Да ничего вы толком не описали. Так, общие рассуждения и минимум конкретики.
Самое обидное — вы оставили за бортом самый главный вопрос: с чем боремся-то? С жЫром или с тормозами?
Браузер — очень неудачный пример. Поддержка свежих стандартов в новых версиях небесплатна и требует добавления кучи кода, не нужного ранее.
Вот если взять классический пример «блоатвари» — просмотрщик ACDSee, то да, была легенькая фиговинка, стал монструозный комбайн с кучей мало кому нужных функций. Но тут — опять же — возникает вопрос: так ли здесь важен язык программирования или фреймворк? Потому как гораздо важнее — решения по добавлению в программу всяческого барахла, принятые менеджерами.
Ну да, драйстоуны, ветстоуны, компиляторы, интерпретаторы, байткод, кэш, code bloat — все это прекрасные слова, но зачем вы все это свалили в одну кучу и приправили жиденькими, бесполезными рекомендациями?
Рекомендации должны быть предметными, а не «вообще».
— Важна производительность именно вычислительная? Тогда — компилируемые языки, многопоточность, распаралеливание, использование GPU (OpenCL, CUDA), распределенные вычисления. У вас из всего этого — только мутноватые рассуждения о производительности и издевательские рекомендации писать на ассемблере. Издевательские — потому что современные компиляторы генерируют код весьма высокого качества, а попытки оптимизировать его вручную обычно приводят к тому, что «оптимизированная» программа работает медленнее оригинала. Кроме того, писать на ассемблере под тот же ARM — занятие для истинных гурманов.
— Важен отклик пользовательского интерфейса программы? Тогда — правильное проектирование, обработка длительных операций в отдельном потоке, и пофиг на язык программирования. Время комфортного отклика на действия пользователя — ЕМНИП, что-то около 250 миллисекунд. На такую производительность вполне способны даже весьма медленные языки программирования.
— Важен малый объем программы? Тогда — использование «легких» фреймворков, языков программирования, выдающих компактный результирующий код, и т. п.Но лично мне проблема «жира» в программах кажется слегка надуманной: на десктопных компьютерах основное ОЗУ жрут картинки и иконки, а на всяческих маломощных контроллерах обычно выбор языка программирования невелик: или пишешь на том, что предоставил производитель контроллера, или не пишешь вообще.
Если оклад зависит от часов — люди будут спать, заниматься своими личными делами и т. п. на работе.
Если оклад фиксированный плюс штрафы/бонусы — то будет повышенная текучка. Это только в воспаленном мозгу директора, получающего фиксированный оклад, может возникнуть мысль, что штраф приведет к повышению качества работы. По факту штраф — это обида сотрудника на компанию, т.к. в большинстве случаев сотрудник себя виноватым не считает. Плюс снижается его уверенность в завтрашнем дне.
Если человек не может спланировать расходы из-за того, что его зарплата «болтается» туда-сюда из-за штрафов и бонусов — это минус. Допустим, к бонусам можно отнестись как к неожиданному приятному сюрпризу (при этом приязнь не переносится на компанию). Но вот штраф — однозначно трактуется как «меня тут не ценят». Как следствие — пара штрафов, и специалист уходит к конкурентам, которые не внедряют таких «прогрессивных схем оплаты».
Двоичных:
Вот, собственно, код, который вычисляет границы области:
minSpan — это размер области в байтах, badBlock — номер сбойного сектора, SECTORSIZE = 512.
Итого теоретически имеем:
— lowBlock выравнивается на нижнюю границу области (в секторах).
— uppBlock — тупо прибавляем к lowBlock размер области в секторах.
Как оно могло выдать интервал, меньший размера области — не понимаю. :)
Просто для меня запуск утилит, напрямую работающих с устройствами через файлы в /dev/ — нечто само собой разумеющееся.
Добавлю к комментарию.
Основные технические принципы и решения живут десятилетиями и не меняются.
Основные платформы, языки программирования живут десятилетиями и тоже практически не меняются.
Революции в IT — редкость.
А вот когда в IT влезает политика и бизнес — тут-то и начинаются перемены. Вот только напоминают они мне заполошную беготню туда-обратно:
«Р-р-р-революционное решение! Переворот! Такого еще не было!»
(через год) «Новое рррреволюционное решение взамен устаревшему! Срочно бежим в другую сторону!»
(еще через год) «Мы бежали не туда, но теперь — все поменялось!»