При этом почти весь РАМ забит (28 из 32 Гб), а видео память только 6 из 12 Гб. Может есть куда двинуть ползунки еще? Контекст поставил 65535, кинул длинную агентную задачу (найти файл, в нем взять список из 10 товарных знаков, по каждому сходить в интернет и проверить срок действия и последние изменения), выполняет все, но сильно медленно конечно. Слабое место - прцессинг промпта (ну или вывода инструментов, в моем случае снапшота chrome dev tools). Агентную задачу выполнил на отлично, выполнял 33 минуты с половиной. Но круто, пока это первая и последняя модель, локально справившаяся с агентной задачей.
Я html пользовался от безысходности. Там в целом все сложнее, чем можно в двух словах описать. В общем, docx обязательное условие, в нем проще всего всем участникам составить и только он был у всех, к примеру, проект договора, дальше самим или с моей помощью расставить тэги для подстановки, а потом этот шаблон просто будет использоваться для генерации готовых документов приложением.
Вся идея в том, что шаблоны то и делают секретари, бухгалтеры и из доступных средств имеют только ворд, и еще тут усилия предстоят объяснить что такое ${var}.
По мне, так дополнительный движок Ashley к LibGDX в разы упрощает понимание игростроя в связке с ООП и дает правильную концепцию деления игровых сущностей, игровых систем и рендеринга. Не знаю насчет Java, но с Kotlin оно спаривается очень хорошо, плюс есть свои ktx на все библиотеки, еще более упрощающие синтаксис.
class Game {
private lateinit var store: Store
private lateinit var question: Question
fun init(context: Context) {
this.store = StoreFactory.getStore(context)
question = store.getQuestionById(1)
}
Когда идиоматичнее так:
class Game(context: Context) {
private val store = StoreFactory.getStore(context)
private var question = store.getQuestionById(1)
А это вы просто пишете с помощью Kotlin на другом каком-то языке, кажется, паскале:
fun getAnswers(): List<Answer> {
val list: MutableList<Answer> = ArrayList(this.answers)
val shouldAdd: Int = 4 - list.size
for (i in 1..shouldAdd) {
list.add(Answer("", -1))
}
return list
}
Я бы предложил так (хотя сама идея добавить пустышками до нужного кол-ва так себе, явно неразумное ограничение, с которым нужно бороться в другом месте):
Rx и Mvp уже пару лет вытесняются Kotlin coroutines и Mvvm/Mvi. Активити фрагментами или вообще Compose. Для json есть библиотеки Kotlin serialization, для андроида — gson, moshi и т.д.
Оставляю, чтоб было что улучшить при следующем взгляде на код) Я потом вынес в константу ключ, по которому взаимодействуют фрагменты, а строки для различения классов, так как используются только в одном месте, оставил бы.
Странно, вроде одни и те же люди так по-разному проголосовали здесь и в соседней статье свежей, где C# сравняли (не сравнили, а именно сравняли) с Kotlin. Там пока навалились шарписты на новые проекты))
Спасибо за статью. Вот, что упростил (если использовать livedata или flow): весь inner class со всеми его методами и проверками заменяется на одну строку на каждый валидатор, привязанный к инпуту:
Разумеется. Но с ним я лично только начал недавно знакомиться (там вообще документации на две тысячи страниц). И тут цель материала вообще изложить основные принципы, на которых строится разработка ORM.
мне кажется, не с проста никто до сих пор этого не сделал…
Есть онлайн OCR, использующий tesseract, там очень плохо с распознаванием контрастно-половинчатых цифр…
Судя по тому, что написано про Go, это язык, разработанный гуглом, преимущественно для системного программирования. И там не то, чтобы хорошо с ООП, там совсем другая парадигма. А я только привык к этой)
При этом почти весь РАМ забит (28 из 32 Гб), а видео память только 6 из 12 Гб. Может есть куда двинуть ползунки еще? Контекст поставил 65535, кинул длинную агентную задачу (найти файл, в нем взять список из 10 товарных знаков, по каждому сходить в интернет и проверить срок действия и последние изменения), выполняет все, но сильно медленно конечно. Слабое место - прцессинг промпта (ну или вывода инструментов, в моем случае снапшота chrome dev tools). Агентную задачу выполнил на отлично, выполнял 33 минуты с половиной. Но круто, пока это первая и последняя модель, локально справившаяся с агентной задачей.
Также благодарю за подсказу по настройкам. Сопоставимый уровень железок, только cpu другой, i7 12700KF, LM STUDIO не хочет больше 4 ядер отдавать.
Это нормальная скорость или можно и лучше? Сейчас схожу в opecode на использовании инструментов ее проверю.
Я html пользовался от безысходности. Там в целом все сложнее, чем можно в двух словах описать. В общем, docx обязательное условие, в нем проще всего всем участникам составить и только он был у всех, к примеру, проект договора, дальше самим или с моей помощью расставить тэги для подстановки, а потом этот шаблон просто будет использоваться для генерации готовых документов приложением.
Вся идея в том, что шаблоны то и делают секретари, бухгалтеры и из доступных средств имеют только ворд, и еще тут усилия предстоят объяснить что такое ${var}.
Интересно, насколько они сами знают свой продукт? Таких вопросов не задаст тот, кто хоть раз двигал изображение в Ворде.
Спасибо!!!!!
Никто не заставляет идти на поводу одисейщиков. Я как летал, так и летаю по настроению.
О, да!!! Спасибо. Наконец-то. Я бы книжку купил на эту тему как про Doom)
По мне, так дополнительный движок Ashley к LibGDX в разы упрощает понимание игростроя в связке с ООП и дает правильную концепцию деления игровых сущностей, игровых систем и рендеринга. Не знаю насчет Java, но с Kotlin оно спаривается очень хорошо, плюс есть свои ktx на все библиотеки, еще более упрощающие синтаксис.
Когда идиоматичнее так:
А это вы просто пишете с помощью Kotlin на другом каком-то языке, кажется, паскале:
Я бы предложил так (хотя сама идея добавить пустышками до нужного кол-ва так себе, явно неразумное ограничение, с которым нужно бороться в другом месте):
Rx и Mvp уже пару лет вытесняются Kotlin coroutines и Mvvm/Mvi. Активити фрагментами или вообще Compose. Для json есть библиотеки Kotlin serialization, для андроида — gson, moshi и т.д.
Оставляю, чтоб было что улучшить при следующем взгляде на код) Я потом вынес в константу ключ, по которому взаимодействуют фрагменты, а строки для различения классов, так как используются только в одном месте, оставил бы.
Спасибо за статью. Вот, что упростил (если использовать livedata или flow): весь inner class со всеми его методами и проверками заменяется на одну строку на каждый валидатор, привязанный к инпуту:
viewModel.eqCount.observe(viewLifecycleOwner) { validateEqCount(); validateXCount() }
viewModel.xCount.observe(viewLifecycleOwner) { validateXCount() }
Есть онлайн OCR, использующий tesseract, там очень плохо с распознаванием контрастно-половинчатых цифр…