put же берёт базу параметром

вопрос исчерпан

ага, это per-transaction override если не указать то возьмет базу из транзакции

так ну если выкинуть из рассмотрения RW и RO то все складывается

@qnikst ты говорил про эти биндинги https://github.com/dmbarbour/haskell-lmdb ?

блин, два года назад последний коммит

https://hackage.haskell.org/package/lmdb-high-level-0.1/docs/Lmdb-Connection.html

там особо нечего ж коммитить?

api то стабильный более менее

ну как нечего.. сам автор пишет My original plan was to develop a monadic interface using bytestrings and ST-like references to keep the MDB_val within a transaction. I'd also like to further wrap the database types, e.g. to distinguish maps from multimaps at the type level, i.e. using types to distinguish MDB_DUPSORT databases from other databases. And I'd like to have a clean model above the cursors, perhaps developing a cursor monad. However, none of the above will happen anytime soon. I find myself much more interested in moving on and leveraging LMDB for my other projects rather than further developing the LMDB API.

но видимо дальше Raw дело не пошло

нормально, хорошие raw нужны на самом деле

есть какие-нибудь стандарты, сколько должна загружаться веб-страница, что бы сайт считался ок?

ну там, полсекунды или 0.1 секунды

за что рубиться

от рентабельности зависит

некоторые и по 10 секунд грузятся

есть какие-нибудь стандарты, сколько должна загружаться веб-страница, что бы сайт считался ок?

https://developers.google.com/speed/pagespeed/

ну, типа это не ок

@quetzal мегаспасибо

то, что нужно

@voidlizard я помню ты говорил что у вас первый ангуляр, а как получилось что даже не второй? просто люди пришли которые знали первый?

фронтендщика найти проблема вообще

соотвественно, нашли нормального, на чем он (она) пишет, то и используем

я общался, например, с нашим фронтенщиков в Zyxel/NDM, он мне советовал примерно так поступить и не париться. отзывы о втором ангуларе очень противоречивые

никто не хочет заниматься фронтом )

я вот не понимаю - фронтенд это по сути модель боксов/виджетов и эвентов, причем для последних есть буквально пара-тройка подходов

Кстати, кто тут может популярно объяснить чего такого есть в ангуляре чего нет в том же backbone?

неужели так сложно сделать консистентную библиотеку?

даже хаскельная либа для ncurses-ов есть, там вполне себе модель, которая на веб ложится

неужели такая проблема сделать edsl и вебню генерить из него?

откуда весь этот ад вылезает?

оттуда, что при слове edsl все фронтендщики разбегутся по углам

неужели так сложно сделать консистентную библиотеку?

на хаскеле? )

конечно на нем

да они не нужны будут

помню была опенлазло

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

я на нем сам делал гуйню

есть urweb правда не пойму, насколько он хорош. но по моему он тоже нормально js изолирует

есть xojo

оно генерит вебню и серверную часть, так что не поймешь где что. но работает ведь

есть urweb правда не пойму, насколько он хорош. но по моему он тоже нормально js изолирует

на урвебе кажется кроме рсс читалки Шабанова нет ни одного проекта (да и он наверное уже пожалел что взял его)

в общем для любой более менее консистентной модели gui вполне можно было бы написать 1) edsl ля описания боксов, а если вдруг недостаточно, то 2) edsl типа ivory для описания поведения

т.е это не выглядит все нереализуемым

ну если запилишь такую библиотеку -- будет круто но кажется гуй не оч интересная тема (диссеров не защитить) вот и не делают

откуда берется весь этот ад в виде ghcjs purescript и прочих попыток тащить логику на клиент

точнее, тащить ВСЮ логику на клиент

я ничего не запилю точно, потому что времени ваще нет

Кстати, кто тут может популярно объяснить чего такого есть в ангуляре чего нет в том же backbone?

бэкбон это mvc классическое, ангуляр двинули в сторону декларативности ну и вообще он сильно больше "фреймворк" например тот же бэкбон не менеджит состояние приложения, а у ангуляра есть для этого разное

откуда берется весь этот ад в виде ghcjs purescript и прочих попыток тащить логику на клиент

ну я не уверен что логика на сервере прокатит для всяких rich UI

было что-то на скале такое -- там тоже все на сервере делалось и по вебсокету куски DOM ходили на клиент

о, https://github.com/fomkin/korolev вот оно

Ну, бекбон не совсем классическое мвс, так как в нем есть реактивность как минимум

но да, спасибо за ответ.

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

без каких-либо наблюдаемых причин для этого

ну, вообще причин уйма на самом деле же

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

да не.. хочешь -- делай как делали 10 лет назад и она будет работать другое дело что сейчас хотят в вебе UI такое как будто у тебя нативное приложение

клиенты стали как минмум жирнее и на них перекинули часть работы бекенда

а вот если хочешь такой user experience то понятное дело что "как делали 10 лет назад" уже не прокатит

плюс хотелки бизнеса по всяким эффектам

@quetzal в том то и дело, что нет. все рич гуи фреймворки с библиотеками виджетов как-то стагнируют

некоторые загибаются совсем

ну потому что эти фреймворки -- это путь в никуда реакт вот взлетел потому что фейсбук и потому что модель unidirectional data flow проще

а почему в никуда?

ERROR: S client not available

я что-то не вижу сильно сложных гуи приложений

по сравнению с тем, что лет 5 - 8 назад делали на каком-нибудь qooxdoo

да вспомни как раньше гуй делался. вот эти все MFC, WTL, QT -- библиотеки виджетов это попытка переложить ТЕ идеи на веб

очевидно не взлетело

но сейчас стало только хуже

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

ну первый ангуляр же как раз про декларативный биндинг

в openlaszlo например ты прям в узлах виджетов описывал xpath для того, что на этот виджет забиндить

но да, оказалось что хоть и работает но не то чтоб хорошо

и вообще огонь - гуй на лету рендерился из xml

мне кажется основная проблема тут не в подходе, а в целевой аудитории

реакт и вообще все эти пляски вокруг virtual dom вот взлетели. отсюда и elm с его elm-architecture и порт элма в js под названием redux )

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

я не уверен что подход с "напишем xml из которого нам все сделается" это хорошо j2ee не даст соврать

потому что массы не смогли в xpath

иначе появление и доминирование json + императивного кода для его обработки необъяснимо

хотя это регресс

да не.. я думаю что твой подход покрывает ну 95% случаев но чтобы в его рамках решить оставшиеся 5% -- да проще умереть сразу. вот и не взлетело

я не вижу в вебе таких случаев

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

просто технически решается несколько иначе и всё

но задачи вроде бы всё те же.

раньше ж говорил. задачи те же, но от интерфейсов хотят все большей и большей нативности

и скорости

ну мы не наблюдаем этого

где нативность?

вообще, что это?

вид как у десктопного приложения? нет же такого

это когда user experience ближе и ближе к десктопному приложению

и к этому таки все идет

не вижу противоречий, и хотелось бы примеров

ну посмотри какой-нибудь react native