DL
Size: a a a
2019 December 10
AC
Не не было
2019 December 11
V0
repl & cljs detected!
VL
что-то аж в Питер захотелось
m
если
возвращает
не возвращать функцию, сравнивающую передаваемый аргумент с
зачем так:
https://clojuredocs.org/clojure.core/=
?
(= x y)
возвращает
bool, почему бы(= x)
не возвращать функцию, сравнивающую передаваемый аргумент с
x?зачем так:
;; If passed a single value (= x) the result is always true.
(= 1)
(= nil)
(= false)
(= true)
(= {:a 1 :b2})
(= 'false)
;;=> true
https://clojuredocs.org/clojure.core/=
?
m
видимо, для консистентного поведения
AI
для консистентности мультиарного апплая к списку. в хаскеле эти операции строго бинарны и частичное применение искоробки, а в кложе мультиарны - а значит должны себя предстазуемо вести при применении к списку
m
да, логично, спасибо
AI
по большому счету в лиспах эти операции - свертка аргументов по какому-либо моноиду
AV
половина студентов отлетит на установке джавы
жвм с установщика легко ставится что в винде что в убунте, леин в убунте из реп ставится, в винде только скрипт кинуть в PATH. Сложно выбрать редактор, ну тут безболезненных вариантов целых два - найткод и вскод. я бы в школе на инф-ке по кложе учил. на паскаль легче спрыгнуть потом
MP
о, ребят, давайте спрошу, вдруг кто в курсе, у меня тут проблемка:
Есть unforgeable токен (token1), которые нужно иметь возможность "оборачивать" (token2), т.е. добавлять новую информацию (data2) и подписывать своим ключом(secret2). Должны соблюдаться следующие условия:
1. Обладая token2 не должно быть возможности получить валидный token1
2. Верификатор должен иметь возможность проверить валидность всей цепочки.
Структрура токенов примерно следующая:
Используя hmac с симметричными ключами это легко сделать (apikeys в данном случае это просто идентификаторы по которым верификатор получает секреты), на этапе верификации мы просто воспроизводим всю цепочку и сравниваем итоговую подпись. Однако этот подход требует знания верификатором всех секретов.
Идеально было бы использовать асимметричные подписи: подписывать данные разными приватными ключами аккумулируя результат в одну подпись (сохраняя валидным требование 1.), проверять списком публичных.
Наиболее точное описание того, что я хочу я нашел тут [1], но оно все что дальше введения сильное академично, без имплементаций. Возможно, я просто не знаю как надо искать и это общеизвестный алгоритм? Или я хочу неправильного? Спасибо.
[1] https://eprint.iacr.org/2005/335.pdf
Есть unforgeable токен (token1), которые нужно иметь возможность "оборачивать" (token2), т.е. добавлять новую информацию (data2) и подписывать своим ключом(secret2). Должны соблюдаться следующие условия:
1. Обладая token2 не должно быть возможности получить валидный token1
2. Верификатор должен иметь возможность проверить валидность всей цепочки.
Структрура токенов примерно следующая:
token1 = data1.apikey1.signature1
where signature1 = sign(data1.apikey1, secret1)
token2 = data1.apikey1.data2.apikey2.signature2
where signature2 = sign(data1.apikey1.signature1.data2.apikey2, secret2)
Используя hmac с симметричными ключами это легко сделать (apikeys в данном случае это просто идентификаторы по которым верификатор получает секреты), на этапе верификации мы просто воспроизводим всю цепочку и сравниваем итоговую подпись. Однако этот подход требует знания верификатором всех секретов.
Идеально было бы использовать асимметричные подписи: подписывать данные разными приватными ключами аккумулируя результат в одну подпись (сохраняя валидным требование 1.), проверять списком публичных.
Наиболее точное описание того, что я хочу я нашел тут [1], но оно все что дальше введения сильное академично, без имплементаций. Возможно, я просто не знаю как надо искать и это общеизвестный алгоритм? Или я хочу неправильного? Спасибо.
[1] https://eprint.iacr.org/2005/335.pdf
от любой крипты возьми функции.
эфириумовский https://github.com/ethereum/web3.js/ есть на всяких языках,
на java есть тут - https://github.com/nemtech
и еще пробовал от stellar.org, но линк сходу не помню.
Там плюс-минус одинаково сделана подпись.
эфириумовский https://github.com/ethereum/web3.js/ есть на всяких языках,
на java есть тут - https://github.com/nemtech
и еще пробовал от stellar.org, но линк сходу не помню.
Там плюс-минус одинаково сделана подпись.
AD
А кто-нибудь пишет скрипты на кложе?
Я нашел 3 варианта:
1. пробовал создавать файл типа
2. Нагуглил, что люди используют Joker, но нe разобрался, как на нем работать, чтобы были автодополнения, документация и т.д.
3. Видел еще вариант с GraalVM. Т.е. создать обычный проект через
Кажется, третий вариант значительно выигрывает, потому что у тебя есть все инструменты как при обычной кложа-разработке (кроме dynamic class loading). Или я ошибаюсь и у Joker-a есть какие-то плюсы?
Я нашел 3 варианта:
1. пробовал создавать файл типа
#! /usr/bin/env clojureподключать сидер и работать c ним. Все нравится в таком варианте кроме времени старта скрипта.
;; #-*- mode: clojure -*-
(use '[clojure.java.shell :only [sh]])
;; scripts code
2. Нагуглил, что люди используют Joker, но нe разобрался, как на нем работать, чтобы были автодополнения, документация и т.д.
3. Видел еще вариант с GraalVM. Т.е. создать обычный проект через
lein new, собрать в jar и перевести в native граалем.Кажется, третий вариант значительно выигрывает, потому что у тебя есть все инструменты как при обычной кложа-разработке (кроме dynamic class loading). Или я ошибаюсь и у Joker-a есть какие-то плюсы?
TP
ST
и babashka
AD
Ещё lumo
видимо, старт будет медленный?
MP
бабашка вообще топ!
MP
А кто-нибудь пишет скрипты на кложе?
Я нашел 3 варианта:
1. пробовал создавать файл типа
2. Нагуглил, что люди используют Joker, но нe разобрался, как на нем работать, чтобы были автодополнения, документация и т.д.
3. Видел еще вариант с GraalVM. Т.е. создать обычный проект через
Кажется, третий вариант значительно выигрывает, потому что у тебя есть все инструменты как при обычной кложа-разработке (кроме dynamic class loading). Или я ошибаюсь и у Joker-a есть какие-то плюсы?
Я нашел 3 варианта:
1. пробовал создавать файл типа
#! /usr/bin/env clojureподключать сидер и работать c ним. Все нравится в таком варианте кроме времени старта скрипта.
;; #-*- mode: clojure -*-
(use '[clojure.java.shell :only [sh]])
;; scripts code
2. Нагуглил, что люди используют Joker, но нe разобрался, как на нем работать, чтобы были автодополнения, документация и т.д.
3. Видел еще вариант с GraalVM. Т.е. создать обычный проект через
lein new, собрать в jar и перевести в native граалем.Кажется, третий вариант значительно выигрывает, потому что у тебя есть все инструменты как при обычной кложа-разработке (кроме dynamic class loading). Или я ошибаюсь и у Joker-a есть какие-то плюсы?
а чего хочешь добиться?