Это да. У меня это даже получалось где то с год назад. Но сейчас пробовал по ссылке с оф. сайта f# поставить рекомендованный тулинг - то ли я тупой то ли гвозди, то ли ссылка на этот тулз сломана

ссылка сломана, подтверждаю

:D

Hopac кто нибудь ментайнит? У меня создается ощущение, что библиотека дохнет. А жалко, сильнее я не видел...

haf мейнтейнит на уровне - обновить версию paket

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

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

Да поставить community а работать в vs code

Hopac кто нибудь ментайнит? У меня создается ощущение, что библиотека дохнет. А жалко, сильнее я не видел...

Либа стейбл если чо. Я бы туда впиливал фичи типа вытесняющего шедулера, транзакционные альтернативы и "одноразовые" стримы.

haf мейнтейнит на уровне - обновить версию paket

Жаль. Haf мог бы и посерьезнее.

Хотя бы чистый standard впилить. Попробую на выходные.

Хотя бы чистый standard впилить. Попробую на выходные.

так впилили ж недавно

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

И правда..

Упустил

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

Да он вроде по работе уже не успевает.

Отдал сообществу

Сообщество не осилило) никто не отваживается трогать

А F# + xamarin точно могут в UWP? В том числе и на десктопе? А то я как то забил и даже не пробовал.

Ну я просто вижу заявлена поддержка UWP и f#, правда по отдельности :D сам я конечно же не проверяла

Вытясняющий шедулер - это ка в erlang?

Вытясняющий шедулер - это ка в erlang?

ага

как в любой нормальной ОС. каждые N миллисекунд вытесняем тред из ЦПУ и даём поработать другим

Там инструкции считаются, а у нас как?

Понял.

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

Причина вытеснения - расход времени проца?

Причина вытеснения - расход времени проца?

решает проблему fairness. Т.е. рано или поздно любой job получит возможность выполнится

что важно для всяких телекомов и высоконадёжных систем

Да преимущества я понимаю - опять же смотри erlang. А вот схему реализации пока не уловил.

на самом деле за 20мс можно сделать миллиарды инструкций) по меркам современных машин это вечность

Да преимущества я понимаю - опять же смотри erlang. А вот схему реализации пока не уловил.

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

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

ну и жонглируем ими туда-сюда

А на коротких - получится голенг

кернел тоже может сорвать на любой инструкции. Как реализовать софтварно - я бы с удовольствием послушал умных людей

Там очередь с нарастающими приоритетами на переключение. В принципе не сложно.

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

кернел тоже может сорвать на любой инструкции. Как реализовать софтварно - я бы с удовольствием послушал умных людей

Unsafe. Пример - любой осовский планировщик

я знаю как в CML сделали. там у каждой джобы был флаг - отдавала ли она добровольно выполнение, или её вытесняли. Если за квант вытеснения джоба была вытеснена насильно, то в следующий квант она отправлялась в отдельную очередь выполнения, которая была низкоприоритетная по шедулингу.

таким образом джобы которые до последнего все 20мс выбирали время, работали реже чем те, которые работали по 1 мс например

короче, я бы с удовольствием занялся проблемой. Жалко это всё придётся в нерабочее время делать

Что не всегда хорошо. А где оно рабочее время? На бессмысленное ООП уходит. ?

Unsafe. Пример - любой осовский планировщик

Ну так-то да. Я вот для этой темы линуксовый кернел изучал, т.к. виндовый мне никто не дал посмотреть)))

Что не всегда хорошо. А где оно рабочее время? На бессмысленное ООП уходит. ?

могу сказать что моя работа платит мне именно за F# хехехе

Линуксовый лучше написан. Я виндовый видел. Лучшне не надо ?. Лучшая реализация, которую я видел - это в RSX. Несмотря на возраст.

Линуксовый лучше написан. Я виндовый видел. Лучшне не надо ?. Лучшая реализация, которую я видел - это в RSX. Несмотря на возраст.

а где виндовый можно посмотреть?

могу сказать что моя работа платит мне именно за F# хехехе

Завидую ?

Декомпиле

Найду скину

Ну да, об этом я чот не подумал) Не, ну С я ещё могу читать, но асемблер тяжко даётся

Есть декоппилеры в С, кривоватые правда ?

Ничо, подождём винду в опенсорс :D

Недолго осталось

Net core я поставил. Была бы она одна в зависимостях fable - б- г бы с ней. Похоже без microsoft build tools ( или как он там зовётся) ionide работает не правильно или не работает. Оно собственно так и сказано в доках

dotnet sdk тебе хватит

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

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

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

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

И честно говоря, когда разберёшься, особо сложного не видно. просто надо закодить

да, надо учесть приоритетные очереди, стилинг алгоритмы между ядрами (а в случае языковой реализации тредами) и кой чо другое

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

Ну да, об этом я чот не подумал) Не, ну С я ещё могу читать, но асемблер тяжко даётся

Нем огу il читать Выбешивает совсем

Дмитрий Вьюков

нашёл имя

Нем огу il читать Выбешивает совсем

ооо. Я признаться IL не читаю почти, т.к. бизнесу примерно насрать на его существование. НО Однажды была проблема. Приложение, поставляемое корпоративным заказчиком (аддон для CAD системы) из-за хардокодно выставленной локали не запускалось на машинах с другими локалями. Я тогда вообще мало чо понимал, но смог запатчить IL код чтобы выставлять локаль согласно настройкам машины. Гордился собой неимоверно. С тех пор в IL код глядел может раз 5...

кстати, у Дмитрия есть отличный сайт http://www.1024cores.net/ рекомендую к ознакомлению

кстати, у Дмитрия есть отличный сайт http://www.1024cores.net/ рекомендую к ознакомлению

Дмитрий?

Дмитрий?

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

Аа

А видели, что сегодня фшарп 4.5 сегодня релизнулся?)

А видели, что сегодня фшарп 4.5 сегодня релизнулся?)

nuget говорит month ago :) https://www.nuget.org/packages/FSharp.Core

аа, это я решил пэкеджи обновить и июнь с июлем перепутал)

6/7/2018

6/7/2018

есть мнение, это в дебильном US формате

MM/dd/YYYY

ага, так и есть

есть мнение, это в дебильном US формате

Freedom формате

ооо. Я признаться IL не читаю почти, т.к. бизнесу примерно насрать на его существование. НО Однажды была проблема. Приложение, поставляемое корпоративным заказчиком (аддон для CAD системы) из-за хардокодно выставленной локали не запускалось на машинах с другими локалями. Я тогда вообще мало чо понимал, но смог запатчить IL код чтобы выставлять локаль согласно настройкам машины. Гордился собой неимоверно. С тех пор в IL код глядел может раз 5...

Было дело, нам вендор поставил либу для купюроприёмника, написанную на дотнете. По сути либа — обёртка для работы с COM-портом. И вот она у них там в цикле дёргала while(true) { port.Read() }, и сильно потребляла CPU (что для нас было недопустимо — для бизнес-логики с трудом мощности хватает, а тут ещё эта либа дурацкая). Исходников вендор, конечно, не поставляет. Мы сперва попробовали её задекомпилять, добавить туда Thread.Sleep(15) и закомпилять обратно. Но либа была написана очень криво, при пересборке новым C#-компилятором в ней поменялось что-то ещё (лично я грешу на тайминги разных операций в условиях кривой работы с многопоточностью), и стала очень часто падать. Поэтому в итоге мы её задампили ildasm'ом, добавили уже в IL-коде нужный вызов, а потом заассемблили обратно. Работало несколько месяцев в продакшене без нареканий (а потом уже вендор нам прислал исправленную версию).

Чуваки, а у кого-нибудь есть опыт работы с F# на Alpine? У меня что-то докерный образ с Alpine (microsoft/dotnet:2.1.301-sdk-alpine3.7) отказался собирать F#-проект, ругаясь на какие-то неверные коды возврата из шелскриптов. Нет ли у нас в компиляторе бага?

Чуваки, а у кого-нибудь есть опыт работы с F# на Alpine? У меня что-то докерный образ с Alpine (microsoft/dotnet:2.1.301-sdk-alpine3.7) отказался собирать F#-проект, ругаясь на какие-то неверные коды возврата из шелскриптов. Нет ли у нас в компиляторе бага?

У меня если честно даже голый асп нет на c# не получилось завести. Не поверишь, но там было разное поведение альпине и в убунтовом образе (в 1 вылетала куча ошибок на запросах).

У меня если честно даже голый асп нет на c# не получилось завести. Не поверишь, но там было разное поведение альпине и в убунтовом образе (в 1 вылетала куча ошибок на запросах).

У меня чото аспнетовое работало на альпине.

Ладно, хрен с ним, пока решил проблему, переехав на bionic.

Хотел было заюзать дефолтовый дебиан, но там nodejs очень старая в репозиториях, поэтому не вышло :(

Чуваки, а у кого-нибудь есть опыт работы с F# на Alpine? У меня что-то докерный образ с Alpine (microsoft/dotnet:2.1.301-sdk-alpine3.7) отказался собирать F#-проект, ругаясь на какие-то неверные коды возврата из шелскриптов. Нет ли у нас в компиляторе бага?

Вообще да, но я последний раз работал с ней на моно 3 года назад

Ладно, хрен с ним, пока решил проблему, переехав на bionic.

Bionic такой же маленький?

Bionic такой же маленький?

Я думаю, что это убунта.

Ну и на самом деле там всё маленькое по сравнению с объёмом dotnet-sdk :)

Убунта весит 500 метров, моно ставил ещё 400 и это печально. На Альпина для моно нужно было 450. И в итоге образ весил все же меньше полугигабайта. для деплоев всяких это важно)

Ну и на самом деле там всё маленькое по сравнению с объёмом dotnet-sdk :)

а сколько? да и sdk - нужно будет только на билд сервере, не? для деплоя только рантайм же

ой а почему это всё в ф# чате??

а сколько? да и sdk - нужно будет только на билд сервере, не? для деплоя только рантайм же

Около 300 метров накладной образ с SDK, кажется. И, да, он нужен только для билда.

ой а почему это всё в ф# чате??

Ну, я это всё заметил именно при деплойменте F#-проектов :)

Ну, я это всё заметил именно при деплойменте F#-проектов :)

потому что F# требует и коры и моно, а C# может жить только с кором? насколько я понял, F# компилятор и прочее - оно на моне и на кор пока не переехало (а будет ли?)

потому что F# требует и коры и моно, а C# может жить только с кором? насколько я понял, F# компилятор и прочее - оно на моне и на кор пока не переехало (а будет ли?)

Да не, жалуюсь я на microsoft/dotnet-sdk, там все компиляторы. Компилятору F# не нужен Mono, если ты собираешься под неткор.

Да не, жалуюсь я на microsoft/dotnet-sdk, там все компиляторы. Компилятору F# не нужен Mono, если ты собираешься под неткор.

? а почему вскод ионид хотел моно тогда для вскоды?

Я с ними не очень близко знаком, пользуюсь редко, поэтому не знаю.

потому что F# требует и коры и моно, а C# может жить только с кором? насколько я понял, F# компилятор и прочее - оно на моне и на кор пока не переехало (а будет ли?)

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

В плане они на коре не работали

Да.

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

ну я ток месяц назад +- тыкал но я мб просто что-то недоставил, не поставил надо будет посмотерть как ща там в зависимостях

Да.

А где-то в природе есть сравнение перфоманса моно и неткора?

Не встречал, надо спрашивать Егора.

А где-то в природе есть сравнение перфоманса моно и неткора?

у techempower нету разве?