Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Geniepro

Страницы: [1] 2 3 ... 131
1
Общий раздел / Re: Online компилятор Oberon-07/11.
« : Январь 22, 2019, 04:14:13 pm »
Есть такой редактор atom. Он вроде как на node.js
У меня появилась мысль использовать его для написания кода вместо конфигуратора 1C
Есть даже какой-то плагин для VSCode для работы с кодом для 1С:
https://marketplace.visualstudio.com/items?itemName=xDrivenDevelopment.language-1c-bsl

2
Общий раздел / Re: Online компилятор Oberon-07/11.
« : Январь 22, 2019, 03:46:48 pm »
Есть такой редактор atom. Он вроде как на node.js
У меня появилась мысль использовать его для написания кода вместо конфигуратора 1C
Atom уже давно не в моде, самый распространённый редактор для программеров -- это VSCode (после него идут IDEA, Emacs, Vim, Sublime).
Плагины для VSCode пишутся на TypeScript, хотя, вроде, и на Javascript должно быть можно.
Доступ к терминалу, командной строке -- это есть.
Работает в винде, линупсе и макоси...

3
Общий раздел / Re: Мы выиграли Старт!
« : Май 21, 2018, 11:12:35 am »
Что с проектом-то? Он жив? Или помер давно? Сайт не открывается...

4
А OberonJS даёт какие-то торможения по сравнению с обычным JS?

5
Говорят, Мозилла со свим Rust'ом оченно сильно ускорила свой JS-движок, какие сейчас там результаты этого теста?

6
Урочище Флуда / Re: Тихий пк
« : Февраль 21, 2018, 06:10:50 pm »
теоретически это всё можно запихнуть в герметичный ящик и залить маслом, а к ящику прикрутить большие радиаторы пассивные, тогда греться не должно...

7
Полгода прошло, какие выводы-то?
Сам я так и не осилил решение на Расте. Вроде на нём можно сделать вполне шустрый код, но выглядит он как говно, смотреть страшно, аж глаза кровоточат...

8
Общий раздел / Re: OberonJS
« : Февраль 18, 2017, 08:31:08 pm »
Вот такой еще вопрос.

PROCEDURE Sin* (x: REAL): REAL;
  VAR res: REAL;
BEGIN
JS.do("res = Math.sin(x)");
RETURN res
END Sin;

Возможно ли вернуть результат без создания переменной res?

А если вот так:
PROCEDURE Sin* (x: REAL): REAL;
BEGIN
JS.do("return Math.sin(x)");
END Sin;

9
Ну, мы уже знаем, в чём причина таких результатов -- в чьей-то криворукости )))

10
Предлагаю добавить в тесты файлы с нестандартными размерами, например 119 946 308 байт или 163 840 004 байт (достаточно большое простое число, умноженное на 4). Идея в том, что бы файл не делился на блоки равных размеров -- это может выявить ошибки в алгоритмах сортировки.
Особенно интересно в этом плане число 163 840 004 -- это 4*(80^4+1)...

11
Предлагаю добавить в тесты файлы с нестандартными размерами, например 119 946 308 байт или 163 840 004 байт (достаточно большое простое число, умноженное на 4). Идея в том, что бы файл не делился на блоки равных размеров -- это может выявить ошибки в алгоритмах сортировки.

12
Решение на модуле-2 (собираемое через gnu modula-2 compiler) работает похоже что корректно. Поэтому запустил прогон. И да, похоже comdiv выкатил новое решение которое снова самое быстрое. :-)

Через 3-4 часа будут результаты.
Чота ты это не в той теме написал ))

13
Хм, на FAT32 все работает, даже XDS.
На FAT32 же нельзя делать файлы объёмом даже в 4 гигабайта ровно -- только меньше...
Это если размер кластера не менять. Но если его увеличить, то и размер файла может быть гораздо больше, чем 4 ГБ.
И как это сделать? Вот я взял и отформатировал флешку 32 ГБт в FAT32, указав максимальный размер кластера -- 64 кБт, но файл размером 4.3 ГБт всё равно не записывается -- запись прерывается на 91% файла. Выходит, что не работает этот рецепт...

14
Это же что-то типа структурной типизации. Вроде в каких-то ML-языках когда-то такое было, может и сейчас есть?

https://dzone.com/articles/duck-typing-scala-structural

Возможно, в питоне что-то такое есть, там же тоже "утиная типизация"...

15
Хм, на FAT32 все работает, даже XDS.
На FAT32 же нельзя делать файлы объёмом даже в 4 гигабайта ровно -- только меньше...

Страницы: [1] 2 3 ... 131