[WT] [Архив]  [Поиск] Главная Управление
[Совместно с Ычаном]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 19666)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, XCF, ZIP размером до 5000 кБ.
  • Ныне 3229 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 500
15241877094.png-(426.24KB, 720×720, junior_developer_popukko.png)
19666
No. 19666 Закреплено watch    
Здесь можно получить помощь и консультацию по любому языку программирования, в любой сфере разработки. Не важно, программируете ли вы собственного робота, пишете серверную приблуду, интегрируете чужие API, ковыряете игру, или пытаетесь сделать сайт на Wordpress - если аноним что-то об этом знает, он обязательно поможет.

Пополняемая база знаний: http://pastebin.com/AGhLZppH

Не знаете, какой язык и библиотеки взять для вашей задачи? Вам сюда.
Не знаете, где клиент, а где сервер? Вам сюда.
Не понимаете, что такое ООП? Вам сюда.
Написали код, и не понимаете, почему не работает? Вам сюда.
Обнаружили кусок кода, и не понимаете, как оно вообще могло работать? Вам тоже сюда.
Не знаете, как подступиться к проблеме? Вам обязательно сюда.

Другие тематические нити (периодически обновляется): https://pastebin.com/psy43ibG

Примеры кода лучше выкладывать в виде ссылок на http://pastebin.com или http://ideone.com
Фронтендные вещи лучше выкладывать на http://jsfiddle.net

Аноним будет стараться дать максимально точный ответ на ваш вопрос и не пытаться предложить вам поменять весь стек технологий только потому что не знает, как решить проблему с тем что у вас есть. Впрочем, если вы забиваете гвоздь микроскопом, аноним постарается вас об этом предупредить.

Чтобы не сбивать новичков с толку, а также не разбавлять полезную информацию мусором, беспредметные споры типа "какой язык / парадигма / библиотека / етц лучше" здесь запрещены.

Если здесь поселится достаточное количество программистов на одном языке / одной сферы, можно будет их выделить в отдельную нить, а в этой оставить на неё ссылку.
По мере поступления вопросов можно составлять FAQ и базу знаний.

Архив нитей:
http://410chan.org/dev/arch/res/14160.html
http://410chan.org/dev/arch/res/15681.html
http://410chan.org/dev/arch/res/17424.html

Прошлая нить пока тонет тут: >>/dev/17424
272 сообщений пропущено. Показаны 50 последних сообщений Развернуть все изображения
No. 20878    
>>20876
Тут вопрос - а что он из этого вынесет?
No. 20880    
>>20874
Ну не знаю. Мне WildFly понравился. А так, разницы между ними особой нет: https://habr.com/company/otus/blog/344416/

>>20876
Jetty — это контейнер, который как службу не запустишь и мышкой не настроишь. Ну и поддержки JEE можно сказать, что и нет. Значит много вынести от его использования не получится, если, конечно, цель состоит именно в этом.

>>20877
>Tokenizer.java
>строка 55
>менеджер даст (что заведомо абсурдно с его точки зрения) символ лексеру, завершившему работу, a лексер его примет, это и будет ошибкой «недопустимый символ»
Столько про этот кейс говорила, а обработать его забыла. Ну дура же!

Вообще, сейчас уже надо начинать писать юнит-тесты, поскольку отлаживать автоматы автоматов в голове становится всё сложнее. Однако оказалось, что JUnit в виде plain-old-jar больше не поставляется, поэтому надо ставить Maven и переводить проект на него, а уже в настройках проекта указывать зависимость JUnit, чтобы Maven подсосал нужные библиотеки из сети. Надо было сразу это сделать~
No. 20882    
154104702987.png-(220.95KB, 1400×936, Mission_Profile_Tests.png)
20882
>>20880
Когда всё начинает работать с первого раза, становится как-то неинтересно. Теперь надо строить синтаксическое дерево, попутно разбираясь, как устроены известные интерпретаторы в смысле среды исполнения.

Лексер, как можно заметить, работает с лагом в один символ (т.е. look-ahead) для унификации способа работы с отдельными модулями. Парсер так же необходимо сделать look-ahead для удобства разбора приоритетов операторов.
Классификация токенов редуцирована по сравнению, например, с компилятором C, и аналогична таковой для лексического анализатора компилятора Clang. Это позволило убрать зависимость лексера от парсера, т.е. повысить инкапсуляцию алгоритмов и модульность проекта. Задача дальнейшей классификации таких токенов целиком возлагается на синтаксический анализатор. Вообще, как-то не особо понятно, почему классификацией идентификаторов должен заниматься именно лексер, но так сложилось исторически.

Нашел, кстати, неплохой гайд по созданию собственных интерпретаторов: http://craftinginterpreters.com/ Тут предлагают процесс интерпретации сделать через обход дерева с использованием паттерна «Посетитель» или преобразовать дерево в байт-код и сделать виртуальную машину. В принципе, первое проще, но второе лучше разделяется, значит удобнее в разработке, отладке, поддержке и расширении.
No. 20892    
>>20882
пишешь свой яп?
No. 20894    
>>20892
Небольшой интерпретатор в автоматном стиле скорее. Довольно занимательная инженерная задача.

А так, никто по сей день так и не смог сделать ЯП превосходящий Ada 95 (типы и подтипы, определяемые пользователем, иерархии модулей, ADO, GADO, ADT, GADT, метапрограммирование на женериках) и Ada 2005 (интерфейсы, сахарок вида object.method и указание процедур-параметров в женериках с null по умолчанию), так что смысла изобретать велосипед я не вижу.
No. 20901    
154179231667.gif-(110.20KB, 400×433, 002c809093dc00a4829d04740d53fc976cd50e8c.gif)
20901
Чиотян, помоги дуре!

https://stackoverflow.com/questions/17581310/using-enum-for-factory-in-java-a-best-practice/ — какая фабрика лучше, которая с абстрактными методами, которая со ссылками на конструкторы, или которая с классами? Дуре фабрика с классами — просто новые классы добавлять и к 8-й версии не прибита, а тебе?
No. 20902    
>>20901
Я тоже голосую за обычную фабрику с классами: т.е сматчили енум (или что там тебе нужно), и по результатам создали экземпляр нужного класса. Универсально, всегда работает.

Альтернативный способ, если хочется чтобы было альтернативно - сделать мапу строка -> функция (возвращает общий интерфейс). Тело функции - создание экземпляра нужного класса. Тогда ничего самому матчить не надо, достал из мапы по ключу, и вызвал с аргументами (или без). Добавить что-то новое в такую мапу-фабрику тоже элементарно.
No. 20903    
154189101425.png-(71.52KB, 1279×855, Clipboard01.png)
20903
>>20882
Подвисла дура чего-то... Основная задача интерпретатора — это REPL, поэтому такие требования.

В выбранный способ работы не поместилась наивная реализация рекурсивного спуска, бо она не имеет перзистентного состояния. Тогда дура сэмулировала её при помощи программного стэка. Поскольку конкретные исполнители могут и обязаны делегировать разбор другим исполнителям согласно формальным правилам для языка, дура сделала фабрику исполнителей, а так как создавать по исполнителю на каждое рекурсивно определённое правило слишком жирно, дура решила их закэшировать. Результатом работы исполнителя является синтаксическое дерево, которое сохраняется на стэке. Работать должно как-то так:

(Involved performers, Analysis result, Last involved performer)
( 1, In_Progress, Performer.Program)
> function f (x) is
( 2, Delegated,   Performer.Declaration)
( 3, Delegated,   Performer.Function_Declaration)  ->  (enter scope)↑
>> if x < 2 then
( 4, Delegated,   Performer.Statement)
( 5, Delegated,   Performer.If_Statement)          ->  (enter scope)↑
>>> return false;
( 6, Delegated,   Performer.Statement)
( 7, Delegated,   Performer.Return_Statement)
( 7, Finished,    Performer.Return_Statement)
( 6, Finished,    Performer.Statement)
( 5, In_Progress, Performer.If_Statement)
>> end if;
( 5, Finished,    Performer.If_Statement)          ->  (leave scope)↑
( 4, Finished,    Performer.Statement)
( 3, In_Progress, Performer.Function_Declaration)
>> end function;
( 3, Finished,    Performer.Function_Declaration)  ->  (leave scope)↑
( 2, Finished,    Performer.Declaration)           ->  (interpret current subtree)↑
( 1, In_Progress, Performer.Program)

(На самом деле цепочки делегирований более длинные, поскольку BNF этого недо-Паскаля занял пару страниц, ну и половина исполнителей не делает больше ровным счётом ничего, прямо как в жизни.)
По сути, это тот же рекурсивный спуск, только с постоянным состоянием на каждом этапе анализа, ну и один огромный token-driven автомат.

Не нравится, что исполнители вовлекают новых исполнителей самостоятельно, в результате управление слабо централизовано. Ну и поток управления у паровоза lexer->parser->binder->performer начал раздваиваться из-за введения областей видимости. Хотя видится вполне возможным обойтись деревьями утверждений, если всё-равно их потом сплющивать в байт-код.

>>20902
Классика со свичом мне не нравится, если ты про неё: во-первых, нет способа узнать, объекты какого класса создаёт элемент перечисления, во-вторых, элемент и класс создаваемого объекта никак явно не связаны, только через код свича. Ну а ссылки на подпрограммы завезли только в восьмую жабу это вам не Ada 95, где просто статический массив под это дело фигачился: type Constructor is access function return Your_Object'Class; Create : constant array (Your_Enum_Type) of Constructor := ....

Я про enum с классами говорил — способ хороший и наглядный. Но мне не нравится сам метод создания нового объекта и количество исключений, которые при этом кидают Class.getDeclaredConstructor () и Constructor.newInstance ().
No. 20909    
154215526568.png-(268.01KB, 1375×921, Clipboard01.png)
20909
<- У меня глаз замылился.

Поскольку семантику тоже было бы неплохо проверять по мере ввода, а парсер очень глубоко закапывается в стэк, было решено единицей его продукции сделать утверждение (statement) и вынести семантический анализ в отдельную подсистему. Довольно забавно, но семантический анализатор говорит на Лиспе.
No. 20918    
154263549899.jpg-(135.85KB, 720×1280, photo_2018-11-19_14-17-18.jpg)
20918
Тупой анон просит помощи. Язык: Python.
Сижу на олимпиаде (хз как тут оказался). Задача, решить не получается.

Моя попытка:
a = int(input('Vvedite chislo a: '))
b = int(input('Vvedite chislo b: '))
N = int(input('Vvedite chislo N: '))
k = int(input('Vvedite chislo k: '))

#if len(str(a+bN)) > k:

ab = a + b

c = 0

while c <= N:
le = a + (c
b)
c += 1

#sp = str(a) + str(ab) + str(le)
#str(a)
#str(ab)
#tr(le)
#sp = None
#str(sp)
#sp = a + ab + le

sp = str(a) + str(ab) + str(le)
#ka = str(sp[10])

print(sp)
input('PRESS ENTER TO END')

Проблема в том, что цикл добавляет в строку sp только результат последнего витка цикла.
Заранее спасибо тем, кто поможет.
No. 20919    
>>20918
Ни в коем случае не стану, и даже, наверное, желаю тебе отсутствия какой-либо помощи, ибо зло и нечестно это. Могу лишь сказать, что код, судя по, будет автоматически исполняться системою, отчего никакие запросоы а-ля “Input value of x: ” тебе писать не требо.
No. 20920    
Добавлю ещё, пожалуй, что в такого рода олимпиадах ввод будет строго в указанном формате.
No. 20921    
Вывод также должен быть в установленной форме и только.
No. 20922    
>>20918
Так. Я решил.
Код:
a = int(input('Vvedite chislo a: '))
b = int(input('Vvedite chislo b: '))
N = int(input('Vvedite chislo N: '))
k = int(input('Vvedite chislo k: '))

ab = a + b
c = 1
sp = str(a)
while c <= N:
sp += str(a + (c * b))
c += 1

k -= 1

if k > len(sp):
print('-1')
else:
print(sp[k])

input('PRESS ENTER TO END')

Да.. Я думал, что разбираюсь в этом лучше.
No. 20923    
154278354377.png-(117.83KB, 1400×980, Clipboard01.png)
20923
Таки единственный способ при реализации конечного автомата избавиться от богомерзкого switch-case в дзяве — это поюзать таблицу динамической диспетчеризации, которую генерит компилятор, т.е. в enum-е указать абстрактные методы transition и dispatch и реализовать их во всех элементах перечисления.

Количество классов в проекте, тем временем, приближается к сотне.

>>20909
Таки это скобка от if-а, т.е. Compound_Statement. Иначе автомат семантического анализатора не сможет правильно построить граф потока управления.
No. 20924    
154282971698.png-(101.02KB, 1077×936, Clipboard01.png)
20924
http://www.educery.com/papers/patterns/visitors/selective.visitor.html
В общем, я не зна~ю... Можно ли что нибудь сделать с этим кастом? Он мне не нравится, хотя всё в общем-то работает.
No. 20926    
>>20743
Это какая версия акробата? Хочу скачать такую.
No. 20927    
>>20926
Седьмая.
>скачать
Adobe лавочку уже прикрыли, годика этак на два раньше спохватываться надо было.
No. 20929    
154295480293.png-(102.81KB, 715×938, Clipboard01.png)
20929
К сожалению, регулярка $name не свободна от backtraking-а, поскольку перекрывается регуляркой $call. Это можно увидеть на отладочном выхлопе перлового движка: https://pastebin.com/D7DhuvrB

Таким вот забавным образом, кстати, из-за двусмысленности определения вызова функции и обращения к переменной все переменные становятся нульарными функциями пока name resolver не скажет обратного, т.е. надо или давать этим нодам дополнительные декоративные рюши, или бесцеремонно их переделывать уровнем выше.

>>20923
Заметил баг, лол, — этот еврейский калькулятор строит дерево выражения справа-налево.

>>20924
Поменял на
return ((Expression.Visitor<R>) visitor).visit (this);

То ли я чего-то не понимаю, то ли так лучше. В общем-то, стэк хранит объекты надклассового типа AbstractSyntaxTree, так что этот тип должен иметь метод accept даже несмотря на то, что он является абстрактным прародителем иерархии типов.
No. 20939    
154325182517.jpg-(243.27KB, 1000×1280, 4c84a13fb668a24a9b1842d46eb8119dd51d9c97.jpg)
20939
Binder & Name resolver — чего-то опять застряла.

Основная моя идея — преобразовать вновь задекларированные имена в соответствующие объекты в одномерном пространстве биндера-резолвера, тогда обращение к переменной в коде будет просто преобразовываться в ссылку на её объект, а для хранения значений в tree-walker-е использовать локальный на область видимости массив, связывая в биндере его элементы с объектами переменных по индексам (интерпретируя AST/CFG быстрее можно получить что-то работающее). Идея, к сожалению, плоха тем, что:
1) требует свелосипедить особый вид карты (вероятне всего это будет бинарное дерево списков — ну просто потому, что строки в лексере всё-равно надо кэшировать и переводить в числа, а зачем дополнительные коллизии с хэшами от хэшей чисел в HashMap-е?), но это не точно;
2) из-за большого числа коллизий имён поиск пересечений областей видимости в худшем случае будет квадратным — для каждого объекта в списке омонимов убедится, что его scope недоступен из текущего места;
3) из-за разделённости синтаксического и семантического анализаторов и двусмысленности грамматики появляется промежуточный класс SymbolicReference, объекты которого надо кэшировать;
4) REPL требует введения отложенной декларации для взаимно-рекурсивных подпрограмм, значит референсам к таким именам нужно особое хранилище, а конструкциям языка, вводящим новые области видимости, — флаг Incomplete или что-то в этом духе.

Ой!.. Кажется я придумываю GNAT: https://www2.adacore.com/gap-static/GNAT_Book/html/node9.htm
>the Names Table is a hash table with no duplicated names
Дураки одинаково мыслят: “What one fool can do, another can”! Но в отличие от них у меня ScopeStack введён имплицитно через CFGBuilderStack.
No. 20943    
Вечер добрый
Есть ли способ каким то образом вытаскивать и читать xml скриптов для Zennoposter?
Допустим, у меня есть файлик формата xmlz и весь xml который я получил из него это крокозябры.
No. 20944    
>>20943
В xmlz буква z в конце значит zip
No. 20945    
>>20939
По размышлению, идея разбилась о динамические глупости/бакости. Имена в цепи обращений, хотя бы вида a.b, возможно статически разрешить только для а, остальное переносится на рантайм, т.е. невозможно отбросить цепочку SymbolicReference-ов, заменив её прямой ссылкой на конечную ноду. Т.о. большая часть статического анализа идёт лесом, давая взамен ленивую ошибку рантайма “undefined is not a function”. В рантайм так же пойдут такие кейсы, как сложение числа со строкой и деление функции на объект.

Это довольно забавно — для введения подобных ошибок надо обрезать вполне естественные механизмы разрешения имён в семантическом анализаторе и чрезвычайно усложнить рантайм костылями. Так что лучше будет ввести статическую типизацию. Ну в принципе, я что-то подобное и хотела, просто динамика показалась проще...

>промежуточный класс SymbolicReference
— Это, верно, тот самый лес, — размышляла она, — где нет никаких имён и названий {d}. ...

d Таким лесом является на деле вселенная, если рассматривать её как существующую саму по себе, независимо от существ, манипулирующих символами и наклеивающих ярлычки на те или иные её части, поскольку, как заметила ранее с прагматической прозорливостью Алиса, это полезно только для тех, кто этим занимается. Мысль о том, что мир сам по себе не помечен знаками, что между предметами и их названиями нет никакой связи, помимо той, которую придает им интеллект, находящий эти пометки полезными, — совсем не тривиальная философская истина.

© Льюис Кэрролл, «Алиса в Зазеркалье» (Пер. Н.М.Демуровой)
No. 20947    
>>20943
>>20944
>В xmlz буква z в конце значит zip
Соответственно, тебе надо сначала анзипнуть файл стандартными средствами, во временную директорию, или прямо в память если файлы небольшие а потом читать распакованный xml как обычно.
No. 20953    
>>20947
Собственно, именно после такой последовательности действий я и вижу страшные крокозябры
Перепрыгивания с одной кодировки на другую результатов не даёт.
No. 20955    
>>20953
Если xmlz-файл не секретный, можешь приложить его сюда?
No. 20960    
>>20955
Конкретно сейчас мне все равно какой xmlz файл тыкать
Можно, например, этот. Он из примеров Зенопостера
https://yadi.sk/d/Zgxnn_BgANDoWA
No. 20961    
>>20960
Заметил, что он защищен RSA
Придется искать другой способ, видимо
No. 20962    
154366736840.png-(59.89KB, 630×432, Clipboard01.png)
20962
Определилась с архитектурой, т.е. представляю, как оно должно работать без привлечения волшебных гномиков. Описываю классы узлов AST, начинаю понимать, почему челы из AdaCore в рассылках говорили, что нахѣр в компиляторах ваше ООП не нужно. Ненавижу computer science... Что у меня пока получилось:
1. Тип — это дефиниция множества значений.
2. Переменная — это дефиниция значения заданного типа.
3. Функция — это дефиниция операции над значениями заданных типов.
4. Класс — это дефиниция множества операций над множеством значений заданных типов.
5. Выражение — это последовательность операций над значениями заданных типов.
Классы Expression и Definition отделены друг от друга. Если следовать (а и придётся) идеологии программирования посредством расширения, Definition надо наследовать от Expression. Может есть идеи получше?
No. 20963    
>>20961
Посмотрел этот скрипт. Я так понимаю, что суть в том, что ключ лежит прямо рядом, в файле Template.xml.signer, но сам этот файл дополнительно защищен паролем, и не зная пароля получить ключ и расшифровать xml будет затруднительно.

Интересно, все ли темплейты так энкриптятся, или только те, с которыми авторы пожелали так сделать, проследовав вот этим инструкциям: https://zennolab.com/wiki/en:encryption
No. 20964    
>>20924
Можно, кстати, не определять в каждом дочернем абстрактном классе ещё один метод accept (Visitor<R>):R и не имплементить его — интерфейсы-то тоже наследуются от абстрактного предка.

>>20962
>5. Выражение — это последовательность операций над значениями заданных типов.
Последовательность применения операций над значениями заданных типов, если быть точным. Т.е. надо от Expression унаследовать ещё класс ... Action, например, и там уже описывать применение операций. Плюсом пойдёт перегрузка операторов.
Хотя, всё-равно иерархия плохо выглядит как-то.
No. 20972    
154390461655.png-(271.52KB, 425×425, Icon.png)
20972
Привет. У меня есть вопросец плана "что использовать".
Дано: HTTP-сервер. Клиенты шлют запросы с некими данными. Шлют часто, ~10 раз в секунду (суммарно от всех клиентов). Обрабатывать их запрос "вот прям щас", в пределах запроса, задачи не стоит. Клиента не интересует ответ сервера.
Но данные эти важные, и обрабатывать их нужно. Поэтому их нужно куда-то сохранять с тем, чтобы потом их обработать "скопом".
Вопрос: Куда сохранять?
Требования: т.к. запросов много и идут непрерывно, важно их очень быстрое исполнение, читай сохранение данных, по принципу "дал команду сохранить и забыл". Важно также сохранить очерёдность запросов.

Варианты:
1. fifo-файл. Но тут должен быть не только писатель, но и читатель. А читателя может пока и не быть. Он запустится позже, cron-ом.
2. Разнообразные MQ. Аналогично первому, нужен читатель.
3. Табличка в БД. Так и делал. Но когда запускал обработчик накопленных данных, он блокировал таблицу (данных много, запросы тяжёлые, а из таблицы же ещё удалять надо). Insert-ы в эту таблицу блокировались, кол-во процессов http-сервера накапливалось очень быстро, упиралось в лимит, и сервер становился недоступен. В общем принцип "дал команду сохранить и забыл" нарушается.
4. Разные вариации пункта 3. Типа сделать ещё одну таблицу, потом "лёгкими" запросами переносить данные в другую, над которой работать "тяжёлыми" запросами. Сейчас так и есть, да. Но складывается впечатление, что я какой-то хернёй занимаюсь.

В общем, чувствую, что готовый инструмент уже есть, просто я %по своей отсталости% о нём не знаю. Хелб.
No. 20973    
>>20972

>В общем, чувствую, что готовый инструмент уже есть, просто я %по своей отсталости% о нём не знаю. Хелб.
>1. fifo-файл. Но тут должен быть не только писатель, но и читатель. А читателя может пока и не быть. Он запустится позже, cron-ом.
>2. Разнообразные MQ. Аналогично первому, нужен читатель.

В случае с MQ нет ничего страшного в том, что читателя нет прямо сейчас. Читатель может выходить на связь, вычитывать сколько там надо сообщений, и подтверждать брокеру что он вычитал вот ровно столько. Но, важно всё правильно настроить.

Рассмотрим на примере RabbitMQ:
  • Учитывая сколько у тебя сообщений, тебе нужно создать lazy очередь, чтобы данные лились сразу на диск: https://www.rabbitmq.com/lazy-queues.html
  • Дополнительно, тебе надо пометить свою очередь как durable, а свои месседжи как persistent (что частично перекрывается объявлением lazy очереди), чтобы и очередь и месседжи переживали рестарты: https://www.rabbitmq.com/queues.html и https://www.rabbitmq.com/persistence-conf.html
  • Чтобы протухшие сообщения всё же удалялись, надо правильно настроить им TTL: https://www.rabbitmq.com/ttl.html
Соответственно, по завершении настройки у тебя появится очередь, которая пишется прямо на диск, сама растёт, и сама удаляет старые элементы по TTL. Остается только правильно из неё читать. В первую очередь, правильно подтверждать сообщения, чтобы не пометить необработанные данные как уже принятые. Во вторую - не получить весь миллион сообщений оставшийся с прошлого запуска в свой читатель за раз.

С подтверждениями всё относительно просто - подтверждай принятие каждого сообщения только после того, как ты с данными сделал всё что хотел, а не как только ты данные получил. Это значит что нужно отключить autoAck когда ты создаешь читателя (чтобы брокер не считал доставленные сообщения сразу полученными), и затем отправлять подтверждения вручную. Примеры как это делается вот тут внизу: https://www.rabbitmq.com/confirms.html

С получением не более N сообщений за раз всё тоже просто. Нужно настроить prefetch: https://www.rabbitmq.com/consumer-prefetch.html

Итого, читатель будет декларироваться и выходить на связь, он будет получать из очереди пачки установленного размера из ранее не принятых сообщений, обрабатывать их, подтверждая обработку сообщений по факту успешного выполнения операций с данными. Потом по необходимости читатель будет самоустраняться, не влияя на работу очереди. При этом удалением старых сообщений из очереди будет заниматься сам брокер, руководствуясь TTL.

Со стороны очереди у тебя получается саморегулирующаяся очередь, которая переживает рестарты и настроена не жрать оперативную память, а вместо этого агрессивно растёт на диск (которого всё равно больше, чем оперативки).

Вроде звучит как то, что тебе нужно.
Но, конечно, придётся всё вдумчиво настраивать.
No. 20974    
>>20973
По-моему TTL — это не то, что ему нужно:
>Важно также сохранить очерёдность запросов.
No. 20975    
Кто-нибудь знает, что такое NS_ERROR_STORAGE_BUSY и как его правильно обрабатывать?
Рalemoon у меня внезапно стал выдавать это исключение на вызов window.localStorage.getItem в моём скрипте.
Гугл находит кучу сообщений о связанных с ним ошибках и ничего полезного.
No. 20977    
154395081313.mp4-(153.72KB, 1920×1080, Kono Subarashii Sekai ni Shukufuku wo! 2 - Vanir s.mp4)
20977
>>20972

> Клиенты шлют запросы с некими данными. Шлют часто, ~10 раз в секунду (суммарно от всех клиентов).

> запускал обработчик накопленных данных, он блокировал таблицу (данных много, запросы тяжёлые, а из таблицы же ещё удалять надо). Insert-ы в эту таблицу блокировались, кол-во процессов http-сервера накапливалось очень быстро, упиралось в лимит, и сервер становился недоступен.

Сложно советовать, не зная ни средний размер данных в одном запросе, ни среднее количество секунд, требуемых обработчику накопленных данных. Но я попробую.

Если проблема только в том, что исчерпывается лимит количества процессов HTTP-сервера, а других проблем не предполагается (например, не предполагается, что произведение количества поступающих от клиента данных на 10 запросов в секунду и затем ещё на количество секунд, требуемых обработчику накопленных данных, превзойдёт объём доступной памяти), то тогда решение выглядит очень просто: надо использовать такой HTTP-сервер, которому всегда достаточно только одного процесса, а ввод-вывод (то есть и чтение из HTTP-запроса, и запись в базу данных) совершается асинхронным (неблокирующим) способом, аналогичным постановке в очередь событий. В качестве примера такого HTTP-сервера я назову прежде всего Node.js.

В качестве постскриптума я изложу ещё мрачное подозрение о том, что обработчик накопленных данных также есть куда оптимизировать. Быть может, он делает всю работу внутри одной огромной эксклюзивной транзакции, предотвращая запись в таблицу на всё это время (вместо того, чтобы наперёд один раз считать номера строк накопленных в таблице данных, а затем использовать их в запросах для ограничения употребляемого набора данных, чтобы случайно не ухватить более новую строчку, но зато хотя бы разрешать появление таких новых строчек во время выполнения своих запросов, а не тормозить всю запись). Быть может, он удаляет обработанные строки из таблицы поодиночке (вместо того, чтобы поместить список команд, удаляющих эти строки, внутри одной транзакции, чтобы только один раз выполнять блокировку и последующую разблокировку записи в базу и затем сбрасывать системные буферы на диск — только один раз, а не для каждой стираемой строчки).
No. 20978    
>>20975
На самом деле тут ошибка вполне красноречиво называется. Сторадж занят. В данном у Firefox случае localstorage может быть открыть только один раз в один момент времени, если он открыт чем-то и происходит попытка открыть его второй раз, то выплевывается эта ошибка. Детальнее надо смотреть на сам код и сравнивать с тем как оно работает в обычном Firefox. Я вполне допускают, что разработчики Palemoon просто сами наколхозили что-то.
No. 20979    
>>20978
…И после перезагрузки компа больше этот баг не воспроизводится. Всё работает одинаково во всех лисах. Так что теперь я без понятия, что это вообще было.

>надо смотреть на сам код
Код там простейший — пробуем считать настройку из локалстораджа, если её там нет — возвращаем значение по умолчанию.

Наверное, надо будет его тупо обернуть в try/case блок, чтобы скрипт не вылетал при такой фигне.
No. 20980    
>>20979
Я скорее о том, что у того кода с асинхронностью, пытается ли он вызываться одновременно из разных вкладок браузера и т.д. и т.п.
No. 20981    
154411155437.jpg-(161.17KB, 1913×961, screenshot.jpg)
20981
<section class='main'> должно включать в себя сайдбар, но нет. ЧЯДНТ?
No. 20982    
>>20980
Код вызывается из OnLoad, никакой асинхронности я туда не закладывал, других скриптов, юзающих локалсотораж, на сайте нет, вкладка, в которой скрипт выполнялся, была одна.
No. 20984    
>>20981
Выложи текущее состояние вещей на http://jsfiddle.net/ и дай ссылку. Так будет проще всего тебе помочь.
No. 20985    
>>20981
Есть тег <main>, <section> - это разделы, главы. <aside> по семантике должен быть вне <main>, так как там дополнительный контент. <header> и <footer> тоже в <main> не нужны. Но это лирика.
Скорее всего ты сайдбару назначил float: right, либо еще что-то.
No. 20986    
154427538097.jpg-(482.94KB, 1024×768, 34816_galaxy-angel-kobieta.jpg)
20986
Всё-таки, что-то в этом такое есть: https://pastebin.com/k4j6MGCC Замучилась с этими неоднозначностями, если честно, даже пришлось проброс продуктов вверх по стеку делать. И всё-равно, проверка корректности инструкций (statement, «утверждение» звучит как-то криво) вида obj.met (a1, a2) := 1; на этапе синтаксического анализа осталась невозможной. Но в GNAT-е сделано также, да и вообще ARM 5.2-5 просто говорит, что “The target denoted by the variable_name shall be a variable.”, т.е. выносит эту проверку за рамки синтаксического анализа.

Теперь можно заниматься семантикой, т.е. строить из этих полуфабрикатов направленный граф, узлами которого являются направленные ациклические графы: https://web.cs.wpi.edu/~cs544/PLT8.5.5.html С семантикой, вернее с процессом интерпретации графа, меня всю неделю гложет чюрвь сомнения, упорно утверждающий, что потеряна иерархическая связь между средами выполнения (execution environment) в результате чего родительская среда будет погребена на стеке дочерними средами рекурсивно вызываемой подпрограммы.
No. 20987    
Добрый день, анон.

Прошу подсказать, что выбрать для дата сайенсов и машин лернингов, R или Python.

Месяца 3 назад выбрал R по ряду причин, удобная ide RStudio, быстрая установка пакетов, и знакомый, который разбирается в R.

И в целом разочаровался, по причине того, что R не хватает consistency. Такое ощущение, что у него миллион пакетов, каждый из которых работает по-своему, и что все они находятся в пре-альфа состоянии, и их нельзя пихать в продакшн (я не работал с JS, поэтому мне наверное нельзя жаловаться).
Простой sql запрос типа lag over становится нетривиальной задачей на R. Когда хочешь нарисовать график на ggplot2, не смотря на то, что он вроде как задуман быть tidy, все равно приводит к необходимости качать какие-то сторонние недобиблиотеки, которые не работают, и ты все равно в итоге используешь эксель.
Короче, я не вижу в R рабочую лошадь, которую можно использовать на практике. Вроде и гибкий, и с большими возможностями, но это ненадежный инструмент.

Вот я думаю, а python это хорошо, панацея? Стоит смотреть в его сторону?
No. 20988    
>>20987
Выбери математику и задайся вопросом — сможешь ли ты одновременно ботать математику и бороться с языком? — поскольку ЯП тут вторичен. R создавался для непрограммистов, занятых исследовательскими работами (математики и статистики, как правило, не умеют да и не стремятся уметь программировать, и очевидные программистам вещи им, обычно, неочевидны); Python делался для программистов и продакшена. Если тебе R жмёт, то смысла грызть этот кактус дальше нет.
>Такое ощущение, что у него миллион пакетов, каждый из которых работает по-своему, и что все они находятся в пре-альфа состоянии, и их нельзя пихать в продакшн
Это нормальное состояние для Comprehensive Archive Network: здесь всё держится на честном слове крокодилящих авторов модулей, которые, как только популярность проекта начинает падать, тихо ливают в более популярные проекты.
No. 20990    
>>20987
Поддержу >>20988. Нет смысла продолжать бороться с R, если в нем уже неудобно - дальше будет только хуже. Python будет с тобой надолго: на нем легко интерфейситься с разными базами данных, можно работать с крупными структурами данных с помощью Pandas, можно делать быстрые прикидки с графиками с помощью Jupyter. Если очень захочется - можно прикрутить легковесный web-сервер типа Flask, делать визуализации на JS (питонские графики тут не могут сравниться, если тебе хочется "по красоте") и делиться результатами. Можно даже писать на нём под монстров типа Spark/Hadoop. Ну и само собой, весь спектр средств от логистических регрессий до GAN в твоём распоряжении в нормальных, поддерживаемых библиотеках - бери и пользуйся.
No. 20996    
Очередной глупый вопрос. Кто-нибудь знает, сколько по времени может выполняться вычисление корней n-ой степени методом Ньютона с точностью около 10_000 знаков на одном ядре?
No. 20999    
>>20996
Можно попробовать узнать это, или хотя бы прикинуть, основываясь на сложности этого алгоритма: https://stackoverflow.com/a/5005879

>Using Newton's method as described above, the time complexity of calculating a root of a function f(x) with n-digit precision, provided that a good initial approximation is known, is O((\log n) F(n)) where F(n) is the cost of calculating f(x)/f'(x)\, with n-digit precision.
No. 21000    
154510230036.png-(41.06KB, 846×1218, ArchInternalDependencies-DirectoryStructure.png)
21000
Это старый проект библиотеки в объектно-базированном стиле, но его можно использовать, только сначала отрефакторить.

Проблема в том, что он с дурью. Модуль Big_Decimal является, очевидно, слоем абстракции данных и экспортирует приватный контролируемый тип над которым определены базовые арифметические операции и операторы, иными словами, является интерфейсом библиотеки. Модуль Big_Decimal_Core со своими детьми является, собственно, вычислительным ядром и клиенту экспортироваться не должен. В силу наивного подхода к разработке ядро работает в системе счисления с основанием 10^8, но каждая его подпрограмма арифметической операции принимает как аргумент Scale количество цифр после запятой по основанию 10^1.

Дурости:
1. Scale каждый раз пересчитывается в Internal_Scale и обратно. Это приводит к строчке-трём шаблонного кода в каждой процедуре, и вообще раздражает, ибо костыль.
2. Более серьёзная проблема — для связи интерфейса и ядра пришлось ввести в паблик интерфейса контекст ядра. Компилятор тут же потребовал или контекст убрать, или ядро экспортировать. В итоге пошли лесом все оптимизации, ибо экпортируемые подпрограммы инлайнить нельзя, а у ядра высокая инкапсуляция, предполагающая зверские инлайны. Т.е. получается:

big_decimal.gpr
library project Big_Decimal extends "Abstract_Library_Project" is
   for Library_Name use "big_decimal";
   for Library_Interface use ("big_decimal");
   ...
end Big_Decimal;

big_decimal.ads
with Big_Decimal_Core;
package Big_Decimal is
   type Decimal is private;
   ...
private
   type Decimal is new Ada.Finalization.Controlled with
      record
         Value : Big_Decimal_Core.Decimal;
      end record;
   ...
end Big_Decimal;

big_decimal_core.ads
package Big_Decimal_Core is
   type Decimal is private;
   ...
private
   type Decimal is
      record
         ...
         Vector : Digit_Vector;
      end record;
   ...
end Big_Decimal_Core;

И попытка сборки:

$ gprbuild
...
Error: In library project "Big_Decimal"
         Unit "Big_Decimal_Core" is not in the interface set
         but it is needed by the spec of "Big_Decimal"
gprbuild: incomplete Stand-Alone Library interface

Я уже запуталась, что делать. Вынести тип ядра в отдельный Pure-модуль, типа он не реализует ничего и ладно, этот модуль сделать прародителем иерархии ядерных модулей? Но это как-то коряво смотрится, IMO. Убрать контекст ядра в тело реализации интерфейса? Но это: а) пока неясно, как, ибо требуется описать тип в интерфейсе полностью; б) закроет путь для расширения интерфейса дочерними модулями, использующими ядро напрямую.
Удалить сообщение []
Пароль  
[Mod]