you can do all this in Jenkins
but don’t
that’s the problem with Jenkins, it promises to be able to do what you want, a few months later you want to throw the server through the window and jump out after it (edited)
@lv пишет
Я помню ...krieger. который умещал шутан уровня ку3 в нескол ко десятков килобайт. Я уверен, что при определенных затратах (и обрезаниях некоторых фишек) можно сделать и мажорный апдейт нормально. Правда тут устанет другой вопрос — а [зачем] тогда новое железо каждый год :)))
вот так-то, учитесь программировать ребятки!
[01:22] <slyfox> As if a bunch of rules would suddenly lose ' | $$$$(dir $$$$@)/.'
[01:25] <jared-w> More $ than a rap video ಠ_ಠ
"I have been obsoleted by a Kmett library." "Yeah, I hear you..."
Some say the pope is the highest cardinal. Others say this cannot be so, for every pope has a successor
лол
посидел в гоферском чате, начал старые новости кидать
еще чучуть посидишь, и будешь Фичи из 80-х обозревать
By the way, I strongly hate it when people say « we deliberately made our language unusable, because we wanted it to be simple ».
Note [Instantiating stupid theta]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Normally, when we infer the type of an Id, we don't instantiate,
because we wish to allow for visible type application later on.
But if a datacon has a stupid theta, we're a bit stuck. We need
to emit the stupid theta constraints with instantiated types. It's
difficult to defer this to the lazy instantiation, because a stupid
theta has no spot to put it in a type. So we just instantiate eagerly
in this case. Thus, users cannot use visible type application with
a data constructor sporting a stupid theta. I won't feel so bad for
the users that complain.
Automatic verification is not about proving correctness, but about
finding bugs much earlier in the development of a system
так то!