ну, shared_ptr

Это refcounter. Даже два : weak и strong

его можно реализовать на япе так что он выглядит как gc

Ну хз хз... Я как о gc слышу, так сразу проблемы многопотока и stop-the-world в голове... (А так-же то, как определить когда объект действительно будет уничтожен) Поэтому я так его не вижу)

его можно реализовать на япе так что он выглядит как gc

И там помоему есть требование о возможности конвертации из shared_ptr в unique_ptr без копирования, если только одна ссылка на shared_ptr, поэтому нет, нельзя одним лишь gc)

Ну хз хз... Я как о gc слышу, так сразу проблемы многопотока и stop-the-world в голове... (А так-же то, как определить когда объект действительно будет уничтожен) Поэтому я так его не вижу)

так я и говорю - стащить модель из .NET или жавы

там в многопотоке все пашет и с GC

так я и говорю - стащить модель из .NET или жавы

Ну там gc супер комплексный. И stop-the-world в каком-то варианте всё равно есть. В микро варианте, но всё равно ощутимо может быть

ясно

опять своё выдумывать

Ну там gc супер комплексный. И stop-the-world в каком-то варианте всё равно есть. В микро варианте, но всё равно ощутимо может быть

Есть ситуации, когда и shared_ptr неприменимы, tbh) Поэтому... Да... Я вообще сейчас в свободное время модель zig по работе с объектами пытаюсь в плюсы затащить) все классы POD, явная деинициализация через defer... Посмотрим, что получится)))

опять своё выдумывать

Там нечего выдумывать. Просто на всех стульях не получится усидеть, и всё тут)

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

Там нечего выдумывать. Просто на всех стульях не получится усидеть, и всё тут)

И это нормально.

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

выделяем 1000 флоатов посредством FFI

и опа - общий указатель

мьютексы, все дела - и вот тебе объект общий для 2х независимых настоящих луашных потоков

и опа - общий указатель

Можно. Хотя и с нюансами.

канеш с нюансами

и тем более смотри

вряд ли тебе понадобится что-то тяжелое, если это нельзя запихнуть в FFI

это или моделька какая-нибудь для opengl, или текстура, или файл какой-то

так что вполне кмк хорошее решение

Можно. Хотя и с нюансами.

и мне нужны тестировщики которые посмотрят на яп и скажут чё говно а что нет всё что там есть - я выдумал в одну каску

документация есть уже на англ, кусочек

так что вполне кмк хорошее решение

Явное управление памятью таких расшареных объектов правда) а так да, давно уже делают похожее. Даже дока луаджита по ффи где-то это упоминала помню.

документация есть уже на англ, кусочек

кода пока особо нету но я его как раз пишу

luarlibs

там включена еще библиотека рантайм типов....

и мне нужны тестировщики которые посмотрят на яп и скажут чё говно а что нет всё что там есть - я выдумал в одну каску

Ну тут как получится... Языки, в целом, трудно объективно оценивать...

Ну тут как получится... Языки, в целом, трудно объективно оценивать...

За исключением отдельных выдающихся случаев...

там включена еще библиотека рантайм типов....

А что они дают-то?

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

setfenv(1, namespace.use(getfenv(), ns));

я уже вижу способ завернуть это в сахар но зачем хз

могут быть решения получше

А что они дают-то?

например жысоны перекладываешь

и определяешь структуру жысона

и по этой структуре валидируешь

могут быть решения получше

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

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

https://t.me/ProLuaSnooze/43428

я примерно об этом кажется и сказал

https://t.me/ProLuaSnooze/43428

Ну да, и забить на этот namespace.use()

А то это страшный комар какой-то...

Ну да, и забить на этот namespace.use()

https://t.me/ProLuaSnooze/43431 ))))))))))))))

дошла мысля

как-то так получается

щас я еще проверю что делает setfenv с require

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

а определенные непосредственно в модуле в глобальный неймспейс не суются

вообще имба, оставляю эту либу

barka.luar local namespace = require "luar/namespace"; local ns = {bar = print}; setfenv(1, namespace.use(getfenv(), ns)); require "kurwa"; kurwa2 = fn() {}; bar("kurwa:", kurwa);

вообще имба, оставляю эту либу

штош, мы пытались тебя отговорить...

а что страшного если она работает?

причем как задумано

это же гениально, это просто шедевр

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

это как lookup of keys in __index

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

Это для дебага функционал... Как-никак... Мне кажется, что есть кейсы, где это может теоретически навернуться... namespace.use этот вот

Но у меня голова уже не варит совсем) пойду отдыхать

Это для дебага функционал... Как-никак... Мне кажется, что есть кейсы, где это может теоретически навернуться... namespace.use этот вот

печально

но в дебаге отдельная функция

но в дебаге отдельная функция

Да, это в новой луашке, больше 5.1. До этого они были в _G

а теперь тут _ENV

печально

Не, на самом деле может и можно, но очень осторожно

и что _ENV уже не только для дебага?

надо бенчмарки сделать

и что _ENV уже не только для дебага?

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

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

но не скорость

надо бенчмарки сделать

В твоём случае в новой луашке всё бы решилось переопределением local _ENV в начале, да.

хм но у меня не новая луашка а луажит

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

Jit может негодовать от нетривиального метаметода __index на env функции, но это только спекуляция.

Jit может негодовать от нетривиального метаметода __index на env функции, но это только спекуляция.

Надо мерять

да это и так глобальные переменные...

вот код на засыпку - реализация неймспейсов... local iter = require "luar/iterator"; local namespace = {}; local upper = {}; namespace.upper = upper; local operator<index> ~. = rawget; local operator<newindex> ~. = rawset; fn namespace.use(env, ns) { ns =~ or {}; if (rawget(env, upper)) { for k, v in pairs(ns) do env[k] = v; return env; } local newtab = {[upper] = env}; newtab._G = newtab; for k, v in pairs(ns) do { newtab[k] = v; } setmetatable(newtab, { __index = fn(self, k) { return rawget(self, k) or rawget(self, upper)~.(k); }, __pairs = fn(self) { // @todo not loop local tbls = {env}; local i = 1; while tbls[i]~.(upper) do { tbls[i + 1] = tbls[i]~.(upper); i = i + 1; } tbls.n = 0; return iter.mulnext, tbls; } }); return newtab; } return namespace;

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

но зачем? а главное - ...