Лол. Луп используется совместно с файберами, а не вместо него.

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

Лол. Луп используется совместно с файберами, а не вместо него.

И это именно в вайбе

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

Вообще-то из моей фразы этого не следует. Логика у вас, батенька, однако. :)

И это именно в вайбе

Для непонятливых: луп и файберы - ортогональные понятия.

Для непонятливых: луп и файберы - ортогональные понятия.

Да ладно! О.о

Да ладно! О.о

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

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

Ну спасибо!)

можно и вовсе без лупа через IOCTL на ведре.

Факт остается фактом: ты удивлялся накой файберы нужны в вайбе, я тебе разъяснил. :)

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

ты же говорил о параллельном http-запросе. В одном файбере параллельно низя никак.

А если параллельность не нужна, то и доп. файбер создавать не нужно. Этож очевидно, бро.

А если параллельность не нужна, то и доп. файбер создавать не нужно. Этож очевидно, бро.

)))

а vibed core хороший движок асинхронности?

а vibed core хороший движок асинхронности?

это абстракция, драйверы могут быть разные. как минимум три: libasync, eventcore и libevent

Мой вопрос остается в силе, кто понял тот понял )

Потому что libasync не знает ничего о файберах

Мой вопрос остается в силе, кто понял тот понял )

ты именно о ядре?

Нет, именно о законченной абстракции

Планировщик + IO + фиберы

Планировщик + IO + фиберы

Ну это я и назвал ядром: vibe.core хз, сравнить-то не с чем

IO, кстати не в ядре, я в драйвере. Том самом libevent, libasync и прочее

В D крайне не хватает встроенной асинхронности как в гошечке

Только вайб и есть

И вот если бы vibed.core стало стандартом де факто, то было бы круто, не пришлось бы никому пилить свои фреймворки и проакторы и прочее

И вот если бы vibed.core стало стандартом де факто, то было бы круто, не пришлось бы никому пилить свои фреймворки и проакторы и прочее

типа если бы его в фобос впилили?

А так многие сторонние либы поддерживают vibe

так что можно считать его, с некоторой натяжкой, стандартом в D

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

В D крайне не хватает встроенной асинхронности как в гошечке

Встроенной, насколько я понимаю, не будет никогда.

Да, ну стандартной

Которую бы взял и не думаешь больше об этих движках, подходах и т.д.

А думаешь о проекте и о том как бабло потечет в карман после выхода на IPO )

Которую бы взял и не думаешь больше об этих движках, подходах и т.д.

Ну в этом смысле так и есть. Берешь и используешь. Только вот долгоиграющие баги, меняющееся API, "добавь что хочешь*

В фобос, я считаю, тоже никогда не попадет,

А так, чем не стандарт? Куча либ из реестра dub, поддерживает вайбовские сокеты.

там, ЕМНИП, по умолчанию даже на 64-х битной системе 2Гб виртуальное пространство вроде.

Не так. Если там процесс 32-битный, то ему 2 ГБ доступны обычно. А у 64-битных таких ограничений нет.

Не так. Если там процесс 32-битный, то ему 2 ГБ доступны обычно. А у 64-битных таких ограничений нет.

Нашел, ага, ты прав. 8 терабайт. 2Gb "with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared"

https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits

Ну не знаю. Я не вижу смысла впиливать его в тот же фобос

Зачем?

Зачем?

Согласен. Не место ему там.

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

Если оно будет перенесено в стандартную либу, то ты не сможешь использовать конкретную версию!

А это приведет к вечной поддержки обратной совместимости

Ну или безвозвратной ее нарушении

А это приведет к вечной поддержки обратной совместимости

Поэтому Вадим Лопатин таки выпилил MIR из фобоса

Если это отдельная либа - приципи себе подходящую версию и хоть вечно на ней сиди

Так что минимизация стандартной библиотеки, имхо, только +

Лучше делать качественные сторонние библиотеки

На менеджере зависимостей, который считается стандартом.

А вот то, что есть dub и он считается стандартом - это круто!

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

Вот и все

dub вообще идет с официальным компилятором.

dub вообще идет с официальным компилятором.

И это правильно! Имхо

да, неплохо, не надо его ставить отдельно

Его бы расширить, было бы ещё лучше

Но то такое...

Не все сразу

+ не всем, возможно, это надо

Только вайб и есть

Я вчера по библиотекам гулял, такое ощущение, что сейчас каждый второй строит свой фреймворк с эвентлупом: https://github.com/gecko0307/dlib/wiki/dlib.async https://github.com/dushibaiyu/yu https://docs.caraus.io/tanya/tanya/async.html https://github.com/huntlabs/kiss/tree/master/source/kiss/aio

Я вчера по библиотекам гулял, такое ощущение, что сейчас каждый второй строит свой фреймворк с эвентлупом: https://github.com/gecko0307/dlib/wiki/dlib.async https://github.com/dushibaiyu/yu https://docs.caraus.io/tanya/tanya/async.html https://github.com/huntlabs/kiss/tree/master/source/kiss/aio

А что в этом плохого?

Это же хорошо!

Конкуренция даёт развитие и выбор!

Я к тому, что не вайбом единым.

Кому-то нравится одно апи, другим другое.

Только не представляю, насколько у других закончено это все.

ERROR: S client not available

Я вчера по библиотекам гулял, такое ощущение, что сейчас каждый второй строит свой фреймворк с эвентлупом: https://github.com/gecko0307/dlib/wiki/dlib.async https://github.com/dushibaiyu/yu https://docs.caraus.io/tanya/tanya/async.html https://github.com/huntlabs/kiss/tree/master/source/kiss/aio

Плохо, что каждый норовит свое поделие в реестр DUB засунуть. Как бы оно не превратилось в ад, который сейчас творится в npm

Плохо, что каждый норовит свое поделие в реестр DUB засунуть. Как бы оно не превратилось в ад, который сейчас творится в npm

Ну...

Я вчера по библиотекам гулял, такое ощущение, что сейчас каждый второй строит свой фреймворк с эвентлупом: https://github.com/gecko0307/dlib/wiki/dlib.async https://github.com/dushibaiyu/yu https://docs.caraus.io/tanya/tanya/async.html https://github.com/huntlabs/kiss/tree/master/source/kiss/aio

И тут теже проблемы, что и у вайба

Все в куче

Все в одном продукте

Работа с графикой, с текстом, со звуком

Ну а как иначе? Либо пакетный менеджер используется и засирается, либо не используется и тогда нафиг он нужен.

Чего это не сделать отдельными либами

Ну а как иначе? Либо пакетный менеджер используется и засирается, либо не используется и тогда нафиг он нужен.

Все просто!

Ну а как иначе? Либо пакетный менеджер используется и засирается, либо не используется и тогда нафиг он нужен.

Ну хз. Скажем реестр ruby не засран так

gem rjnjhsq

Если бы dub умел поддерживать несколько источников - то не засираешь общий, а просто поднимаешь свой

Как apt, добавляй свой источник и вперед

Что тут мешает сделать также?

Если бы dub умел поддерживать несколько источников - то не засираешь общий, а просто поднимаешь свой

Ну я общий ради такого засирать бы не стал.

Докер тоже так умеет

Что тут мешает сделать также?

Ничего не мешает. Просто кто-то это должен сделать. Кто?

Ну я общий ради такого засирать бы не стал.

Ради какого?

Ничего не мешает. Просто кто-то это должен сделать. Кто?

Тот, кто dub и пишет

Ради какого?

Ради размещения либ, которые нужны только мне.

Ради размещения либ, которые нужны только мне.

Так не только мне!

Смотри пример:

Я делаю свой фреймворк

И каждый модуль я делаю отдельно от самого ядра

Я делаю свой фреймворк

Остановись, я понимаю о чем ты

Остановись, я понимаю о чем ты

Ну вот

Делаешь свою "репу" и все

Было бы круто

Сам dub единый, но для проекта декларируешь свой источник пакетов, или несколько

Было бы круто

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

А кто-то наверное так делает

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