@Fsharp_chat

Страница 274 из 772
Nikolay
18.08.2017
20:02:42
Ну или хз как там называть

Я просто могу забить, поэтому пока решил не заводить)

Хотя уже больше половины перевёл

Google
Astmatik
18.08.2017
20:03:38
По идее: F# for fun and profit/learning-fsharp.md
А в какой репе это всё?

Nikolay
18.08.2017
20:04:02
А в какой репе это всё?
https://github.com/fsharplang-ru/translations

Astmatik
18.08.2017
20:05:04
Ооо, в md формате, какая прелесть.

Evgeniy
18.08.2017
20:14:27
Я тоже кое-что приготовил для перевода.

Надеюсь, что успею до конца каникул.

Хочу немного хайпануть на теме Azure Functions. Ну, и для блога Microsoft на хабре отлично подойдет.

https://github.com/fsharplang-ru/translations/issues/24

Nikolay
18.08.2017
20:36:12
На F# for fun and profit очень годные статьи для начинающих

Vlad
18.08.2017
20:38:52
At the risk of starting another argument ... ? Let's not disparage Windows 10, 10 S, UWP, Visual Studio, Fable, Ionide, Desktop Bridge, F#, NET Native, or other technologies here. Frustrations are understandable, but airing those frustrations in a way which trivializes or otherwise insults others or other technologies only increases frustration. I cannot speak towards the priorities of the .NET Native team after they complete .NET Standard 2.0 support (which is, without question, their top priority right now). But I can speak towards our current top priority: completing the Visual Studio tooling support for .NET Core and .NET Standard. Further work to complete the .NET Core picture with Type Providers and proper F# Interactive support are also a very high priority. Furthermore, the success of current and future customers on Azure is also of very high priority for us, and it is an ongoing priority that surfaces in many areas: Azure Functions, Azure Notebooks, being stakeholders in API changes for different services, etc. Not only is Azure used by many F# customers already, but it's an area of growth for F# that is also of massive strategic importance to Microsoft. This does not mean that UWP support is somehow unimportant to us. It's clearly the future platform for Windows, and although it's not the replacement for WinForms and WPF, the ability of UWP to run on Windows Holographic devices represents an exciting area for F# and computing in general. As these devices become more widespread, I personally believe that Windows 10 will also increase in market share as it helps push the boundaries of computing devices. But the fact of the matter is, UWP is a technology that only ~30% of the Windows market can use today. .NET Core and Azure represent a larger addressable market than UWP does, and that is where the lion's share of our time will go for now. We'll remain subject matter experts for the UWP team to work with on .NET Native support, push for F# on their priority list after their .NET Standard support is completed, and we'll also contribute in identifying problems that need to be solved for proper .NET Native support. We'll also be lending similar support to those who work on CoreRT, as true cross-platform native compilation for F# applications is important for .NET Core and Azure customers.

По поводу uwp

Nikolay
18.08.2017
20:44:45
В общем перевёл всё, кроме нескольких моментов: Do understand how partial application works, and try to become comfortable with point-free (tacit) style. And of course, there is no tool to “debug” the compiler and step through its processing (И конечно же нет инструмента для пошаговой “отладки” компилятора) But you will learn much faster if you start with a beginners mind. It is important to understand that functional programming is not just a stylistic difference; it is a completely different way of thinking about programming, in the way that truly object-oriented programming (in Smalltalk say) is also a different way of thinking from a traditional imperative language such as C. (Важно понимать, что функциональное программирование отличается не просто синтаксисом, это совершенно иной способ мышления в программировании. Различия примерно такие же, как между истинным объектно-ориентированным языком программирования (in Smalltalk say) и традиционным императивным языком, таким как C.)

Artemy
18.08.2017
20:45:30
Типа проблемные места?

Nikolay
18.08.2017
20:45:42
Угу, не знаю как сформулировать

Google
Nikolay
18.08.2017
20:46:35
Смысл понятен, объяснять не нужно, вот с формулировкой проблема

Artemy
18.08.2017
20:48:01
Да, так, чтоб литературно и красиво, сложненько.)

Точнее, надо подумать.

> But you will learn much faster if you start with a beginners mind. Вы научитесь быстрее, если станете мыслить как новичок (в программировании).

Это ближе всего к дословному

Nikolay
18.08.2017
20:51:50
Может так: Вы научитесь быстрее, если начнёте с чистого листа

Artemy
18.08.2017
20:52:05
Да, вариант

Nikolay
18.08.2017
20:52:17
Т.к. там в контексте речь идёт о том, что не нужно использовать императивный стиль

Artemy
18.08.2017
20:52:34
Или типа "...если на момент обучения постараетесь забыть всё, что знаете о программировании"

Это уже если от себя добавлять.)

>Do understand how partial application works, and try to become comfortable with point-free (tacit) style. Обязательно поймите/разберитесь, как работает частичное применение и постарайтесь дойти до того, чтобы не испытывать неудобств, имея дело с бесточечным (point-free) стилем.

Правда, немного переосложнил

Friedrich
19.08.2017
05:08:45
А правда что async { } всегда создает новый тред? Если я делаю там что-то тяжелое, но синхронное - это не страшно (нигде НЕ используется RunSynchronized)?
async { } следует понимать не как Task из C#, а как Func<Task>. То есть async — это ещё не запущенное вычисление, и вызыватель может управлять способом запуска (в тредпуле, в отдельном треде, синхронно по месту вызова). Я очень долго к этому объяснению приходил :)

At the risk of starting another argument ... ? Let's not disparage Windows 10, 10 S, UWP, Visual Studio, Fable, Ionide, Desktop Bridge, F#, NET Native, or other technologies here. Frustrations are understandable, but airing those frustrations in a way which trivializes or otherwise insults others or other technologies only increases frustration. I cannot speak towards the priorities of the .NET Native team after they complete .NET Standard 2.0 support (which is, without question, their top priority right now). But I can speak towards our current top priority: completing the Visual Studio tooling support for .NET Core and .NET Standard. Further work to complete the .NET Core picture with Type Providers and proper F# Interactive support are also a very high priority. Furthermore, the success of current and future customers on Azure is also of very high priority for us, and it is an ongoing priority that surfaces in many areas: Azure Functions, Azure Notebooks, being stakeholders in API changes for different services, etc. Not only is Azure used by many F# customers already, but it's an area of growth for F# that is also of massive strategic importance to Microsoft. This does not mean that UWP support is somehow unimportant to us. It's clearly the future platform for Windows, and although it's not the replacement for WinForms and WPF, the ability of UWP to run on Windows Holographic devices represents an exciting area for F# and computing in general. As these devices become more widespread, I personally believe that Windows 10 will also increase in market share as it helps push the boundaries of computing devices. But the fact of the matter is, UWP is a technology that only ~30% of the Windows market can use today. .NET Core and Azure represent a larger addressable market than UWP does, and that is where the lion's share of our time will go for now. We'll remain subject matter experts for the UWP team to work with on .NET Native support, push for F# on their priority list after their .NET Standard support is completed, and we'll also contribute in identifying problems that need to be solved for proper .NET Native support. We'll also be lending similar support to those who work on CoreRT, as true cross-platform native compilation for F# applications is important for .NET Core and Azure customers.
Кто это говорит?

Evgeniy
19.08.2017
05:30:32
@Dolfik Я предлагаю завести WIP PR и обсуждать перевод там.

Vlad
19.08.2017
05:48:57
Кто это говорит?
https://github.com/Microsoft/visualfsharp/issues/1096 Филлип Картер здесь

Evgeniy
19.08.2017
05:50:00
https://github.com/Microsoft/visualfsharp/issues/1096 Филлип Картер здесь
Можно сразу ссылку на комментарий давать. Она в дате публикации комментария спрятана.

Vladimir
19.08.2017
06:28:40
Всем привет) После нескольких неудачных попыток запустил на конкурс голый кестрел, который возвращает "Hello world" на любой запрос и он тоже спекся на 1.5К RPS. Пишут, что это происходит из-за отсутствия поддержки keep-alive на клиенте.

Vladimir
19.08.2017
06:31:22
Насколько я понимаю клиент его обрывает

Google
Vladimir
19.08.2017
06:31:43
Хотя не уверен)

Но факт что оно не переиспользуется

Nikolay
19.08.2017
06:33:15
А отключить можно?

Vladimir
19.08.2017
06:33:43
https://github.com/sat2707/hlcupdocs/issues/3

что отключить?

Nikolay
19.08.2017
06:37:03
А, я кажется понял в чём суть)

Vladimir
19.08.2017
06:41:48
В чем же суть?) Я например не очень понимаю, почему из-за этого "системы заточенные на асинхронную обработку запросов проигрывают"

Nikolay
19.08.2017
06:54:06
Могу предположить, что в случае асинхронной обработки запросов, сервер принимает соединение сразу же, как только поступает запрос, и через keep-alive говорит ему, подожди, я сейчас тебя обработаю. Когда появляется возможность, он обрабатывает запрос и шлёт ответ. А в случае с синхронной обработкой запросов, запрос просто отправляется и висит, пока сервер не закончит обработку предыдущего запроса.

Astmatik
19.08.2017
07:39:36
шутка про node.js: "все выполняется асинхронно, кроме вашего кода"

Nikolay
19.08.2017
08:14:44
:)

У кого-нибудь есть русская VS?

Aleksander
19.08.2017
08:27:23
Всем привет) После нескольких неудачных попыток запустил на конкурс голый кестрел, который возвращает "Hello world" на любой запрос и он тоже спекся на 1.5К RPS. Пишут, что это происходит из-за отсутствия поддержки keep-alive на клиенте.
Можно попробовать поставить перед кестрелом nginx, чтобы мультиплексировать 100500 входящих коннекшенов в десяток с keepalive. В latency немного потеряешь, но возможно переживешь 2к rps. Прочие варианты: тюнить кестрел, либо переключится на чистые сокеты.

Вот про nginx - https://www.nginx.com/blog/load-balancing-with-nginx-plus-part2/

На изменение условий в середине конкурса я бы не расчитывал

Igor
19.08.2017
10:02:04
SemaphoreSlim внутри async { } это норма для ограничения доступа к ресурсу?

Anton
19.08.2017
12:01:46


Roman
19.08.2017
12:03:10
А что пишет в ошибках?

Nikolay
19.08.2017
12:03:29
Файл fsx?

Google
Anton
19.08.2017
12:03:34
.fs

Roman
19.08.2017
12:03:48
Не, в fs так нельзя. Только в fsx

Anton
19.08.2017
12:04:00
А в чем у них разница, если вкратце?

А то студия его не обрабатывает совсем :(

Roman
19.08.2017
12:06:07
fsx по идее исполняется в интерпретируемом режиме. И не требует proj файла. Все зависимости разгуливаются директивой #load. Кроме того работают #r и #I и другие директивы интерпретатора.

А fs работает так же как и cs. Там все управление структурой и подгрузка происходит через proj файлы

Anton
19.08.2017
12:07:50
Понял, спасибо большое)

Roman
19.08.2017
12:07:52
А то студия его не обрабатывает совсем :(
Студия говорит что синтаксис #r не валиден для fs файла.

Понял, спасибо большое)
Да. В proj файле последовательность fs-файлов важна.

Nikolay
19.08.2017
13:02:29
Что подразумевается под function pointer?

If you are trying to create a function pointer or delegate, watch out that you don't accidentally create a simple value that has already been evaluated. Если вы пытаетесь создать указатель на функцию, или делегат, следите за тем, чтобы случайно не создать обычное значение, которое уже вычислено

Не уверен, что правильно перевёл

Vladimir
19.08.2017
13:20:05
Думаю тут имеется ввиду что указатель на функцию это и есть делегат

Astmatik
19.08.2017
15:18:02
Ну что же, RavenDB оказывается умеет сериализовать list и seq из коробки.



И Map тоже

Nikolay
19.08.2017
15:24:46
И Map тоже
А option/tuple/du/records?

Astmatik
19.08.2017
15:25:10
records - конечно

tuple, да

Nikolay
19.08.2017
15:26:33
records - конечно
А без CLIMutable?

Google
Astmatik
19.08.2017
15:36:46
А без CLIMutable?
Успешно сохраняется в базу, с ним и без него.



Nikolay
19.08.2017
15:37:23
Успешно сохраняется в базу, с ним и без него.
Круто, респект разработчикам RavenDB :)

Astmatik
19.08.2017
15:39:00
Не любит, когда ему голый seq/list пихают. А в составе record норм.

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

Igor
19.08.2017
15:43:35
Я бы на твоём месте посмотрел на MailboxProcessor.
Пытался, но проблема в том что есть 2 независимых “таски”, у которых нет общего кода (который можно было бы вынести в агента), но нужен доступ к 1 ресурсу.

Igor
19.08.2017
15:45:34
Так ресурс и вынеси в актор
А трогать его как? В Msg лямбду прокидывать?

Roman
19.08.2017
16:04:31
А трогать его как? В Msg лямбду прокидывать?
Создаёшь команду. В акторе вызываешь нужную ф-цию

Igor
19.08.2017
16:05:24
Создаёшь команду. В акторе вызываешь нужную ф-цию
Ооо, так я и думал что к этому сведется - нет это придется все переписывать (и главное писать доп. обвязки и паттерматчинг). Короче спасибо, пока на slimsemaphore посижу.

Evgeniy
19.08.2017
17:54:34
F# Weekly #34, 2017 – Choose your 2017 F# Heroes ! https://sergeytihon.com/2017/08/19/f-weekly-34-2017-choose-your-2017-f-heroes/amp/

Vladimir
19.08.2017
22:29:15
Доброй ночи) Nginx помог, 2К выдержаны)

Aleksander
19.08.2017
22:33:35
latency сильно упала?

Evgeniy
20.08.2017
05:08:05
Хороший рассказ про использование провайдеров типов в продакшене. https://cboudereau.github.io/fsharp/data/prod/2017/08/18/why-we-use-fsharp-data-in-prod.html

Пожалуй, я соглашусь, что для data engineering очень полезны провайдеры типов. Скорее бы их на .Net Standard завели.

Но FSharp.Data, например, в заброшенном состоянии.

https://github.com/fsharp/FSharp.Data/pull/1056

Много PR висит.

Страница 274 из 772