Нужен отдельный канал для scala-сборов?

у меня уже просто рефлекс на "нужен scala-разработчик в ..." ?

rollback из логов бота > Нужен Scala-разработчик в Ташкенте, не для стартапов и вообще это не предложение касательно работы.

хм, теперь все скрытое (адмнами) не минет глаз моих

Как достали удаленное сообщение ??

я здесь бота подсадил в логах было

Бот на скале написан ?)

ага

В гитхабе есть ?)

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

https://github.com/optician/Telegram-Silencer немножко пиара для репы you are welcome to make pullrequest ©

https://github.com/optician/Telegram-Silencer немножко пиара для репы you are welcome to make pullrequest ©

println("Thank u!")

Очередной тупой вопрос, который не даёт покоя. Допустим, есть какой-то abstract class Foo(bar: String) Можно ли сделать кейс класс, который бы наследовал его и заполнял своим параметром абстрактный член? Ну типа case class BarBar extends Foo BarBar("qwerty"): Foo

Когда подобную фигню надо делать, постоянно дублирую. Жесть какая-то, некрасиво

abstract class Foo(a: String) case class Bar(a: String) extends Foo(a)

так чтоли?

Угу

не нравится что руками приходится прокидывать a?

Ещё бы

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

О, вроде через трейт вместо абстракт класса работает как надо

О, вроде через трейт вместо абстракт класса работает как надо

ну это чутка совсем разные вещи же получается Оо

Смотря для чего, наверно. В моем случае как раз что надо вышло

trait Foo { val name: String } case class BarCustomer(name: String, age: String)

trait Foo { val name: String } case class BarCustomer(name: String, age: String)

abstract class Foo(name:String) - это параметр конструктора (тобишь параметр конкретного метоа), естественно что наследующий класс не может добавить реализацию параметра для какого-то конкретного метода. trait Foo{ def name:String } - это абстрактный член (контрак на реализацию в наследниках. естественно что он может быть реализован через class Bar(val name:String) extends Foo , поскольку в данном случае Bar(val name) - name не только параметр конструктора, но и член Bar, который заодно реализовывает контракт из фу

гитлабупал?

гитлабупал?

просто дропнули опять

If things stay as they are I see no alternative to bringing back the higher-kinded language import and declaring higher-kinded types officially unsound.

https://github.com/lampepfl/dotty/issues/2887

Ну реал, L[F[G[_]]] - это уже Эребор какой-то.

`L[G[F[_], _]]` - перебор ровно до тех пор пока тебе это не понадобиться

Ну реал, L[F[G[_]]] - это уже Эребор какой-то.

OptionT[StateT[F[_], List[String], _]]

Ну реал, L[F[G[_]]] - это уже Эребор какой-то.

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

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

да, упоминали, что баг приносят баунды

OptionT[StateT[F[_], List[String], _]]

не очень. В этом выражении нет кайндов третьего- четвёртого порядка, в отличии от приведённых типов

Учитывая, что субтайпинг-баунды - это чуть ли не основная фича тайпсистемы дотти, выглядит очень тревожно

С другой стороны, может выйти, что сама эта система случайно вышла тюринг полной и проверка хорошести баундов вдруг окажется эквивалентной проблеме останова

видимо не только тут шутки про go

ну вот и в профунктор оптикс улетела картинка

наши агенты повсюду

http://cr.openjdk.java.net/~jrose/values/shady-values.html

есть перевод https://habrahabr.ru/company/jugru/blog/336378/

обновил идею - какая херня вылезла с эдитором - файлы не открываются - тупо постое окно без табов на месте эдитора

тока у меня такое?

обновил идею - какая херня вылезла с эдитором - файлы не открываются - тупо постое окно без табов на месте эдитора

_попробуй переустановить виндоус!_

помогло

я рестартанул идею на самом деле еще раз и это говно прошло

Всем привет. Пытаюсь подключить js модуль к ScalaJS, выдаёт такое: [error] (compile:fastOptJS) org.scalajs.core.tools.linker.LinkingException: There were module imports without fallback to global variables, but module support is disabled. [error] To enable module support, set scalaJSModuleKind := ModuleKind.CommonJSModule. Ок, меняю на CommonJSModule, проект собирается, но при загрузке страницы выдаёт: Uncaught ReferenceError: exports is not defined. Не могу понять, что делаю не так.

Всем привет. Пытаюсь подключить js модуль к ScalaJS, выдаёт такое: [error] (compile:fastOptJS) org.scalajs.core.tools.linker.LinkingException: There were module imports without fallback to global variables, but module support is disabled. [error] To enable module support, set scalaJSModuleKind := ModuleKind.CommonJSModule. Ок, меняю на CommonJSModule, проект собирается, но при загрузке страницы выдаёт: Uncaught ReferenceError: exports is not defined. Не могу понять, что делаю не так.

а js модуль уже в минифицированном или в es6 виде?

обновил идею - какая херня вылезла с эдитором - файлы не открываются - тупо постое окно без табов на месте эдитора

было такое, решал перезапуском идеи

@fomkin порешал с докером то? или так и забил?)

а js модуль уже в минифицированном или в es6 виде?

Я его, кстати, подключил через: jsDependencies += "org.webjars.bower" % "chart.js" % "2.6.0" / "chart.js", надеялся, что таким образом можно будет без NodeJS обойтись.

https://github.com/scala/scala/pull/6050

чат, а есть что годного почитать про лет ит крэш?

чат, а есть что годного почитать про лет ит крэш?

например "Reactive design patterns" у Куна

там и про error kernel расскажут. и еще там куча полезностей

@rudogma Привет! А как в supertagged обстоят дела с наследованием? Попытался заюзать вот так: https://pastebin.com/YgJAbMr5 , но asInstanceOf выглядит грязновато. Мб стоит вообще с другой стороны подойти?

пардон, разобрался )

def parse1(x: Int): Base = Foo(x) нормально работает. IDEA просто подсвечивает странно

@rudogma Привет! А как в supertagged обстоят дела с наследованием? Попытался заюзать вот так: https://pastebin.com/YgJAbMr5 , но asInstanceOf выглядит грязновато. Мб стоит вообще с другой стороны подойти?

есть еще перпендикулярное наследование в тегах через OverTagged

def parse1(x: Int): Base = Foo(x) нормально работает. IDEA просто подсвечивает странно

а зачем так делать? всмысле тегать через Фуу и возвращать Бейс ?

https://gist.github.com/Rudogma/12ebcdae41423a76a3f59b70ef28607e

Есть некий код, которому не важно, Foo там или Bar (т.е. он работает с любым Base). Но насчет parse я спрошу

Есть некий код, которому не важно, Foo там или Bar (т.е. он работает с любым Base). Но насчет parse я спрошу

https://github.com/Rudogma/scala-superquants посмотри суперквантс, там используется этот принцип, только за счет овертаггет

прикольно конечно, но читается тяжело :D

спасибо, надо помедитировать

https://github.com/Rudogma/scala-superquants/blob/master/shared/src/main/scala/superquants/longprecision/length/package.scala

да не. там легко. вот например в этом файлике. делается базовый тип Length (unit family) - для определения семейства длин. затем для каждого юнита Meters & etc - овертег, который является тегом (не мультитегом) к фэмили. Поэтому это получается не мультитегинг, а своеобразное наследование

Учитывая, что тегированное значение сохраняет все свойства основания и может быть использовано как основание, то любой Meters & etc может быть использован там где принимается Length

Но естественно когда ты передаешь в def takeLen(len:Length) => takeLen(5.meters) - ты теряешь инфу о метерс (тайплевел компайлтайм же). но иногда это то, что нужно. в юнитах это имеет значение, потому что метерс не равно километерс, но если овертаггет для кайнд-разделения - то тогда такие вещи могут быть не важны)

и если овертаггет использовать, то имеет смысл для базового типа указывать чуть более развернутое описание типа object Length extends TaggedType[Long] type Length[T] = (Long with Tag[Long, Length.Tag]) @@ T // --- вот эта строчка так с идеей проблем будет меньше, а на юзерспейсе все также останется

Ок, а что здесь T? Т.е. как будет выглядеть метод, который возвращает неизвестно какой Length (Nano, Meters, ... )?

Ок, а что здесь T? Т.е. как будет выглядеть метод, который возвращает неизвестно какой Length (Nano, Meters, ... )?

def len:Length[_] - все как обычно)

там на самом деле можно без T написать. в большинстве случаев тоже самое будет. это мне там для допфишек нужен был Т

@rudogma хм… https://pastebin.com/R50CCbWd

@rudogma хм… https://pastebin.com/R50CCbWd

(Long with Tag[Int, Base.Tag]) - Long => Int

да, точно :D

да, точно :D

но этого мало будет) сейчас гляну

def parse(x: Int): Base[_] = Foo(x) да, так не работает could not find implicit value for parameter tagger: supertagged.Tagger[TagIn,Types2.Foo.Type,Types2.Foo.Tag,Sub,Int]

все вспомнил. мы же тут овертаггет используем. смотри. когда мы просто тегаем, мы тегаем raw основание. но когда мы тегаем Foo который овертаггет, мы должны тегать основание именно овергтаггет. Тобишь не Int, а Base.Type. Итого будет Foo(Base(x))

тайпсейф - он такой, враг не пройдет)

все вспомнил. мы же тут овертаггет используем. смотри. когда мы просто тегаем, мы тегаем raw основание. но когда мы тегаем Foo который овертаггет, мы должны тегать основание именно овергтаггет. Тобишь не Int, а Base.Type. Итого будет Foo(Base(x))

Отлично! Спасибо :) И за отличную библиотеку спасибо. Кстати, посмотрел на разницу в байткоде между обычными типами вроде Int и затеганными. В твоем варианте появляются только дополнительные вызовы статических методов, что в принципе ок. Я тут думал над вариантом типа: Компилятор на stage X видит Length и тем самым гарантируется, что мы используем затеганные значения, но потом на stage X Length превращается в Int. Не силен в стейджах scalac, хз возможно ли вообще такое

Отлично! Спасибо :) И за отличную библиотеку спасибо. Кстати, посмотрел на разницу в байткоде между обычными типами вроде Int и затеганными. В твоем варианте появляются только дополнительные вызовы статических методов, что в принципе ок. Я тут думал над вариантом типа: Компилятор на stage X видит Length и тем самым гарантируется, что мы используем затеганные значения, но потом на stage X Length превращается в Int. Не силен в стейджах scalac, хз возможно ли вообще такое

Да, в памяти все теже 4 байта для инта. 99% бойлерплейта джитом вырезается (по крайней мере по ощущениям)

Скалац обрезает эфемерные типы

В принципе да, jmh показал практически одинаковые значения (я бы даже сказал в пределах погрешности). Другое дело, что было бы вообще супер, если б JIT этим даже не занимался

Отлично! Спасибо :) И за отличную библиотеку спасибо. Кстати, посмотрел на разницу в байткоде между обычными типами вроде Int и затеганными. В твоем варианте появляются только дополнительные вызовы статических методов, что в принципе ок. Я тут думал над вариантом типа: Компилятор на stage X видит Length и тем самым гарантируется, что мы используем затеганные значения, но потом на stage X Length превращается в Int. Не силен в стейджах scalac, хз возможно ли вообще такое

Это точно можно сделать через compiler plugin

У меня была идея - сделать это через semanticdb. Типа выключаемая проверка. Сейчас пытаюсь, но кейсов очень много, и хз как оно будет в бою, скорее всего сильно снизит время проверки, чем через compiler plugin.

А как ты там semanticdb будешь использовать? Он же доступен только после полной компиляции.

Семантикдб для тулзов типа scalafix, которые работают над уже скомпилированным кодом

Да, именно. Грубо говоря, задаешь алиас Weight = Int. Потом проверяешь, что там, где требуется Weight - либо передается Weight, либо пишется что-то вроде foo(x: Weight)

челендж тут в местах типа: val xs: Seq[Weight] = ??? val ys: Seq[Weight] = xs.map { x: Weight => (x + 1): Weight } 1. Проверить, что пишут x: Weight или x (без указания типа), а не x: Int. 2. (x + 1): Weight Вообще я согласен, что идея с semanticdb скорее всего провальная. Но инструмент интересный и есть задача, в которой его можно испытать :)

челендж тут в местах типа: val xs: Seq[Weight] = ??? val ys: Seq[Weight] = xs.map { x: Weight => (x + 1): Weight } 1. Проверить, что пишут x: Weight или x (без указания типа), а не x: Int. 2. (x + 1): Weight Вообще я согласен, что идея с semanticdb скорее всего провальная. Но инструмент интересный и есть задача, в которой его можно испытать :)

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

Согласен :)