Когда мне нужно передать какую то структуру в канал, я пишу chan <- myStructInstance

Там есть вообще immutable ?

а я не знаю :)

https://github.com/nolka/gooffroadmaster/blob/master/mvc/controllers/track_converter.go#L97

вот пример как я на каналах делал отправку ответов ботом в террограм)

immutable тоже tls. может ограничение связано с этим?

в go есть tls? если нет, то логично что в каналах можно передавать переменные любых потоков

immutable тоже tls. может ограничение связано с этим?

Это ты про мою проблему?

да

оффтоп: Vue Element рулят! Я в полном восторге от них!

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

оффтоп: Vue Element рулят! Я в полном восторге от них!

рассказывай

сейчас исходник кину. Краткая суть. Там шина Vuex, кастомный компонент и в нем уже используется Vue Element

В хроме нужно захостить все через плагин http сервера

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

Я смотрел исходники receiveOnly(T...)(T args) и там как раз похоже на проблему. Сначала создается Tuple!(T) t а потом присваиваются поля t = T.fields как-то так. Но поскольку T уже есть иммтуабельная структура то ничего нельзя ей присвоить.

Пусть даже они и TLS, ведь очень логично же копировать структуру в новую чтобы передавать между тредами, а старую структуру не менять. Я собственно этого и добивался.

tls то просто так их не скопировать между потоками

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

да, но immatable всё равно живёт в своём tls блоке

похоже баг. есть подобное с AA https://issues.dlang.org/show_bug.cgi?id=13930

пиши в багзиллу. может поправят

Reported: 2015-01-04 02:44 UTC by Martin Nowak Status: NEW может поправят БЕЗЫСХОДНОСТЬ

Более реалистично - я сяду и напишу свою реализацию receiveOnly )

ну или так

Но там все очень низкоуровнево, я не знаю как исхитриться и работать с иммутабельным как с мутабельным. Может можно всякие фокусы в compile time сделать, навроде сначала снять атрибут immutable, заполнить структуру, одеть атрибут обратно.

А кто-то знает как работает cast(immutable) ?Что вообще происходит внутри

надо в компилятор лезть

А кто-то знает как работает cast(immutable) ?Что вообще происходит внутри

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

просто кастуешь и меняешь

Да походу проще всего скастовать после получения и не париться

Да походу проще всего скастовать после получения и не париться

но лучше всего копировать)

так надёжней)

Ну структура по-любому скопируется

Но передавать указатель на immutable shared структуру тоже надежно, не надо беспокоиться что кто-то может поменять.

Но передавать указатель на immutable shared структуру тоже надежно, не надо беспокоиться что кто-то может поменять.

вроде в случае immutable 'shared' не нужен

на офф. форуме тоже писали что для передачи immutable shared не нужен

кстати, с днём программиста всех)

с днём программиста

https://sun1-14.userapi.com/c635106/v635106857/5657b/OrfxGEMJRzk.jpg

это точно

Нет идеала, везде будут исключения и какие-то компромиссы. Не нужно все делить на чёрное и белое, всегда было, есть и будет серое. Так что будет код, который компромиссный, и это не всегда костыли, а просто необходимость на тот момент. Лично мне Ди нравится тем, что эти компромиссы ярко выражены и их не скрывают, а честно пытаются исправлять и избавляться от от них. Да, из-за этого страдает обратная совместимость, но одни кричат, что это плохо, другие же кричат, что неконсистеннтно, потому, что устарело или "не верно". Разработчики Ди не боятся улучшать и развивать язык и компилятор! И, имхо, это круто! Если не нравится, никто не мешает зафиксировать версию компилятора и это указать в ридми. Так что хватит ныть и сопли по лицу размазывать, а берите яйца в кулак и вперёд писать проекты!

В ди столько компромиссов что писать проекты просто нереально

Тратишь все время на борьбу с компромиссами

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

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

В ди столько компромиссов что писать проекты просто нереально

Примеры?

Желательно несколько

Желательно несколько

Я же сюда регулярно пишу у меня бомбит )

А мне предлагают костыли обычно )

Давай сейчас

Пример

Я сегодня только вот кидал

Про неизменяемую структуру?

Причем когда я не пишу - это не значит что у меня все гладко разрабатывается, это значит что я пишу на C# :D

Про неизменяемую структуру?

Да.

Да.

Ну так зачем тебе не изменяемая структура?

Блин, ну чтобы ее не изменяли :)

Я вот, на пример, на С# не могу сделать так: Class class {}

Может и можно, честно говоря не знаю наверняка, но думаю не могу

Тут вопрос: зачем?

Тебе тоже не мешает объявить неизменяемой именно переменную, а не сам тип

Но это лирика

Тут вопрос: зачем?

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

Возможно это недочёт документации или реализации.

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

Так зачем тебе сам тип так объявлять?

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

ERROR: S client not available

В этом же и состоит увеличение эффективности разработки. Мне нужно держать в голове меньше особенностей и я могу сконцентрироваться на бизнес логике.

Это же абсолютно очевидная штука - обмен иммутабельными сообщениями. Не знаю как это можно ставить под вопрос :)

А можешь в run.dkang.io написать полный пример который не работает?

https://run.dlang.io/is/9o3ebQ вот такое вот супердно )

Буду помечать такие сообщения тегом #dsuxx

Честно, не понимаю необходимости такого подхода

Это же блокирующее общение между потоками

В чем тогда смысл это делать в отдельном потоке?

В каком месте оно блокирующее?

Чисто для тогобы отделить от общих данных?

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

Пока не получишь ответ, поток не работает дальше

Я о потоке, который принимает

Пока не получишь ответ, поток не работает дальше

Да. Но я упростил, тут нет никакой проблемы. В vibed я обмениваюсь этими структурами в рамках работающей Task поэтому тред на самом деле не блокируется.

Да. Но я упростил, тут нет никакой проблемы. В vibed я обмениваюсь этими структурами в рамках работающей Task поэтому тред на самом деле не блокируется.

Да ладно!

А блокируется Task, ну она и должна ждать пока ей придет сообщение.

А блокируется Task, ну она и должна ждать пока ей придет сообщение.

Так это и есть тред

Task это не тред

Просто это пул тредов, наверное

Это враппер на Fiber

Много Task могут выполняться в одном треде и ничего не блокировать, в этом и есть суть vibe-core

https://dlang.org/phobos/std_parallelism.html#.Task Это?

https://dlang.org/phobos/std_parallelism.html#.Task Это?

Нет, я имел в виду это http://vibed.org/api/vibe.core.task/Task

И тогда явно там используется не нативная функция ресив

Не за нотиуом, посмотрю позже

Ну Людвиг где то писал что встроенные функции std.concurrency.receiveOnly нормально работают с его тасками

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

Хм...

Мало мне в это верится, но ладно

https://dlang.org/library/std/concurrency/receive.html

Receive a message from another thread, or block if no messages of the specified types are available.

А ресивОнли, мне кажется, всего обёртка над простым ресивом