Годная идея, инпуты разные могут быть и шарить конфиг можно по-разному

да нужно абстрактный стандарт для конфигов

https://xkcd.com/927/

скаланы, подскажите годный чатик питон сообщества

это не мне, друг попросил хДД

скаланы, подскажите годный чатик питон сообщества

@python

есть русский https://t.me/ru_python

спасибо большое

@zuldare ты тот Сальников который старший брат Саши?

@zuldare ты тот Сальников который старший брат Саши?

ахаха да

Лол кек

индийское кино, а не чатик

> Пишите вопрос по своей проблеме. Сразу и одним сообщением. Без приветов. Без прелюдий «кто может помочь». Обращения в ЛС к участникам нежелательны жесткие правила у них

индийское кино, а не чатик

Даниил, ты чтоли?! сколько лет!

Лол кек

а ты тот зуев, который ....? а хз

Зависал как то у вас в Кузьминках

@zuldare работай

Зависал как то у вас в Кузьминках

Текстильщиках

@zuldare работай

Так , кто призвал сюда моего босса?

направьте пожалуйста человека немного работающего с макросами Вопрос: можно ли в whitebox макросе выдернуть имплистный параметр? нашел только вот это - но мне кажется оно слишком старо https://gist.github.com/xeno-by/90daa4b8227034acce36 Конкретнее: есть whitebox макрос он смотрит на некоторые аннотации и догенерирует код хочу в макросе генерить этот код опираясь не на аннотации а на некий имплиситный параметр грубо говоря вместо case class BadAss(@Ann("123") a: Stirng) case class BadAss(a: Stirng) implicit val badAss = AnnLike[BadAss]("123")

направьте пожалуйста человека немного работающего с макросами Вопрос: можно ли в whitebox макросе выдернуть имплистный параметр? нашел только вот это - но мне кажется оно слишком старо https://gist.github.com/xeno-by/90daa4b8227034acce36 Конкретнее: есть whitebox макрос он смотрит на некоторые аннотации и догенерирует код хочу в макросе генерить этот код опираясь не на аннотации а на некий имплиситный параметр грубо говоря вместо case class BadAss(@Ann("123") a: Stirng) case class BadAss(a: Stirng) implicit val badAss = AnnLike[BadAss]("123")

можно. c.typecheck

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

@maximKorolev val expr2 = c.typecheck(expr, mode = c.TYPEmode) - ты получишь на выходе дерево со всеми выведенными импилисит-колами (все имплисит параметры рекурсивно и т.д. - тоже) либо ошибку обычную, если компилятор не шмогла вывести имплиситы.

Сборщик плохо реагирует на high allocation rates. Шипилев обещал фикс

@rudogma спасибо раскопаю

@optician_owl https://twitter.com/AndreiPangin/status/970724126741721089?s=20

угу, видел спасибо

Народ, а как называется код, который находится в теле трэйта?

Генератор NPE

Body

@meln1k Да ты Ванга, не иначе)

Крч, вот такой код: lazy val test=new mutable.HashSet[String] with Savable[String]{override val name = "test"} trait Savable[A] { this:mutable.HashSet[A]=> val name:String Savable.register(this)//Не обращайте внимания, это для сохранения, но там нет проблем try{ new File("./saveble/").mkdirs() val oos = new ObjectInputStream(new FileInputStream("./saveble/"+name))//name==null :D this++=oos.readObject().asInstanceOf[mutable.HashSet[A]] oos.close() }catch { case e:Exception=>e.printStackTrace() } } Как это по нормальному написать, чтобы загрузка выполнялась после override val name?

Не использовать val в трейтах

def?

Как вариант

А в реализации уже оверрайдить в val

Можно тоже def

Или есть разница?

Ну в твоём кейсе и def ок

Но в трейте в конструкторе писать в файл эт писос

Ну, мне хочется использовать сериализацию просто: замиксил трэйт и готово

Работает, спасибо)

Если что, я был бы не против узнать, почему плохо в конструкторе читать из файла)

стереотипы!

Если что, я был бы не против узнать, почему плохо в конструкторе читать из файла)

а если ошибка io будет

У мя там внутри try

а если ошибка io будет

мм, как это связано с локацией в конструкторе?

мм, как это связано с локацией в конструкторе?

я как собака, отвечаю не читая прошлых сообщений

я как собака, отвечаю не читая прошлых сообщений

деградируют в другом чатике

Сделал вот так: теперь сохраняет еще и мапы)) trait Savable[A] { this:Growable[A] with Serializable=>

Ну, не только мапы, а вообще все Growable

Зачем вообще такой костыль, почему бы не сохранять в leveldb или что нибудь нормальное?

есть библиотека booPickle для сериализации https://boopickle.suzaku.io/

Зачем вообще такой костыль, почему бы не сохранять в leveldb или что нибудь нормальное?

Давно левелдиби нормальным стал?)

Зачем вообще такой костыль, почему бы не сохранять в leveldb или что нибудь нормальное?

давно файлы ненормальными стали?

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

Но в трейте в конструкторе писать в файл эт писос

один ПР как-то раз вдохновил нас с @qman228 и @Kvitral попробовать реализовать dsl программирования полностью основанный на линеаризации Сломались на том, что трейт нельзя наследовать дважды и никакие макросы нам не помогли

ERROR: S client not available

Зачем вообще такой костыль, почему бы не сохранять в leveldb или что нибудь нормальное?

Зачем вообще такой костыль, можно же в embedded tarantool или руками файл создать и в текстовом редакторе записать туда всё, что надо

Не использовать val в трейтах

мне кажется в таком коде не грех и early initialization

один ПР как-то раз вдохновил нас с @qman228 и @Kvitral попробовать реализовать dsl программирования полностью основанный на линеаризации Сломались на том, что трейт нельзя наследовать дважды и никакие макросы нам не помогли

А вы затейники

Привет, скаланы! Вопрос такой: какие преимущества имеет Korolev перед всякими js-фреймворками (в моем случае интересует сравнение с Angular)?

@fomkin твой выход

Привет, скаланы! Вопрос такой: какие преимущества имеет Korolev перед всякими js-фреймворками (в моем случае интересует сравнение с Angular)?

1. Lightning-fast page loading speed (~6kB of uncompressed JS) 2. Comparable to static HTML client-side RAM consumption 3. Indexable pages out of the box 4. Routing out of the box 5. Build extremely large app without increasing size of the page 6. No need to make CRUD REST service 7. Connect to infrastructure (DBMS, Message queue) directly from application 8. Data security

9. Автор тут под боком и всегда его можно пнуть в почку и попросить совета/фикса

9-ый пункт внушает

Фомкин написал Asp.Net MVC, шоле?

1. Lightning-fast page loading speed (~6kB of uncompressed JS) 2. Comparable to static HTML client-side RAM consumption 3. Indexable pages out of the box 4. Routing out of the box 5. Build extremely large app without increasing size of the page 6. No need to make CRUD REST service 7. Connect to infrastructure (DBMS, Message queue) directly from application 8. Data security

а 8 пункт откуда там нарисовался?

Фомкин написал Asp.Net MVC, шоле?

с подключением! бегом ставить лойсы королеву

а 8 пункт откуда там нарисовался?

оттуда что самый распространенный секъьюрити-баг в крудах, это когда через эндпоинт утекают данные которые не должны утекать. я один раз видел, как пароли утекали (которые хранились в откртом виде, как это принято делать в БОГАТЫХ компаниях). типа получил список сотрудников, а там пароли в джейсонке.

Фомкин написал Asp.Net MVC, шоле?

Нет.

типа из-за другого интерфейса они будут менее открытые?

Нет.

WebForms?

типа из-за другого интерфейса они будут менее открытые?

типа в королеве не происходит передачи того что ты не показываешь пользователю. такие ошибки нужно будет допускать специально.

WebForms?

на fpconf он хорошо описал королёва, есть в ютубе

типа в королеве не происходит передачи того что ты не показываешь пользователю. такие ошибки нужно будет допускать специально.

всё равно не понял причём тут королёв

всё равно не понял причём тут королёв

ракеты баллистические разрабатывал

ааааа

убедили

Проблема распространена из за того, что бэкедер шлет через круд лишнее по невнимательности. Фронтендер игнорирует это потому что аут оф скоуп. Тестирование не видит проблемы, потому что все работает по спецификации. В королеве нельзя допустить такую ошибку по невнимательности. Ее нужно сделать нарочно: 'span('display @= "hidden", s"Secret: $secret").

Да, тут согласен... Прочитал, аж проняло... Накатили воспоминания...

Это действительно сильное преимущество.

Для меня почему возник вопрос - потому что на мне и front и back... выходит что что бы сделать фичу - ее делаешь "дважды", с отдельными модельками на каждой стороне... на двух языках

А какие минусы? Например, есть ли всякие библиотеки кастомных web-контролов? Т.е. вот это все писать самому... Верно?

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