Comments 32
А вы ничего не сказали про visual works реализацию? Мы ее в университете использовали.
На сколько я знаю очень много кто из esug предпочитают pharo.
А по делу я думаю вы проделали огромную работу, надеюсь только что она не пройдет для вас даром. Вы молодец.
На сколько я знаю очень много кто из esug предпочитают pharo.
А по делу я думаю вы проделали огромную работу, надеюсь только что она не пройдет для вас даром. Вы молодец.
Спасибо за отзыв!
Да, я хотел подробно расписать все имеющиеся на рынке реализации, но время поджимало, поэтому выложил как есть. Надеюсь, в следующей статье удастся описать.
Pharo тоже достойная альтернатива, и для более менее серьезного использования я бы порекомендовал именно ее. Однако, у Pharo те же самые проблемы с виджетами, что и у любого другого Smalltalk-а.
Собственно в LLST я хотел обкатать Qt интеграцию в «сферических» условиях, дабы потом можно было это перенести в промышленный вариант.
Да, я хотел подробно расписать все имеющиеся на рынке реализации, но время поджимало, поэтому выложил как есть. Надеюсь, в следующей статье удастся описать.
Pharo тоже достойная альтернатива, и для более менее серьезного использования я бы порекомендовал именно ее. Однако, у Pharo те же самые проблемы с виджетами, что и у любого другого Smalltalk-а.
Собственно в LLST я хотел обкатать Qt интеграцию в «сферических» условиях, дабы потом можно было это перенести в промышленный вариант.
UFO just landed and posted this here
Собственно, есть еще вопрос к знатокам C++.
В заголовочном файле memory.h объявляется шаблон
Вопрос состоит в том, можно ли кросплатформенно делегировать оператор
В GCC это можно сделать с помощью такого финта (закомментированный вариант в первой реализации hptr):
Однако, в общем случае подставление типа возвращаемого значения из оператора сделать не получается. Поэтому приходится писать специализацию шаблона, и как следствие, определять в ней все операторы, что есть копипаст и не труъ.
У кого какие соображения?
В заголовочном файле memory.h объявляется шаблон
hptr<>.Вопрос состоит в том, можно ли кросплатформенно делегировать оператор
[] для случая hptr<TObjectArray>, то есть hptr<TArray<TObject*>>? В GCC это можно сделать с помощью такого финта (закомментированный вариант в первой реализации hptr):
template<typename I>
typeof(target->operator[](1))& operator [] (I index) const {
return target->operator[](index);
}Однако, в общем случае подставление типа возвращаемого значения из оператора сделать не получается. Поэтому приходится писать специализацию шаблона, и как следствие, определять в ней все операторы, что есть копипаст и не труъ.
У кого какие соображения?
С интересом прочитал пост. Всегда неравнодушен к любым начинаниям в области языков программирования. Поэтому привет из Академа вам, желаю удачи и всенародного призвания :)
UFO just landed and posted this here
в чем отличие от стандарта?Отличий много. В байткодах, в интерфейсах и иерархии классов. Тут все сильно упрощено. Хотя в принципе, классы никто не запрещает привести в соответствие.
Если интересуют более-менее стандартные реализации, то можно посмотреть сюда: amber-lang.net/
А в RSUG — sugr@googlegroups писали? Там есть энтузиасты.Нет, пока никуда не писал. Это первое явление народу :) Спасибо за ссылку, надо будет и туда запостить.
UFO just landed and posted this here
Амбер вроде как спонсируется фондом object fusion, так что предполагаю что развивается.
Ruby после Smalltalk выглядит громоздким и некрасивым.
Хотя оно может так и практичнее.
Хотя оно может так и практичнее.
Спасибо, язык и платформа отличные и любые работы связанные с ним интересны.
С удовольствием прочитал Вашу статью, все эти мысли (переписывание VM, восхишение Дольфином, но пичалька по поводу заточенности под Windows, попытка прикрутить LLVM к Smalltalk и т.п.) тоже давно мучали мою психику… Я однажды запускал достаточно амбициозный проект в одиночку (нас было всего двое участников) на Dolphin Smalltalk, знаю не понаслышке все прелести Smalltalk и это чудесное ощущение разработки живой программы «на кончиках пальцев», в дебаггере… феноменальная скорость разработки и отзывчивость!
Меня последнее время мучает такая мысль. QТ прекрасно конечно своей портабельносью, но очень сложно будет создать хорошее отображение «мира QT» в «мир Smalltalk». Т.е. клей смоллтока будет связывать C++ клей QT, а тот в свою очередь будет дёргать соотв. нативное API операционной системы. Какгбэ «ну и пусть», но всё-таки избыточно.
Идеальных миров не бывает, самое крутое в «смоллтоковости» было в самом начале, когда VM не была виртуальной, а исполнялось на всамделишнем железе Xerox, и среда Smalltalk была и OS, и средой для пользовательсктх приложений. Времена поменялись, «расцвели тысячи цветов»… и можно потеряться в этом бесконечном разнообразии аппаратуры, операционных систем и интерфейсов. Но вот нить, их связывающая: практически в каждой ОС есть WEB-браузер. И далее: тогда может быть вообще не привязываться к красивым закидонам GUI конкретной OS, и разработать весь GUI разработчика как WEB-интерфейс? VM компилируется как простое консольное приложение для конкретной ОС, и слушает TCP порт? К порту подключаемся WEB-браузером, и поехали! Вот вам Class Browser, вот вам отладчик, вот вам Transcript Window. Ну и ещё: качественный GUI разработчика — это тест на живучесть применённых идей, и там есть всё что нужно и для GUI пользовательских приложений. Все эти TreeView, ListView и всё такое прочее.
Производительность браузеров растёт, стандарты движутся, на HTML5 возможны грандиозные вещи, вплоть до мультимедии и WebGL.
Под некоторые популярные браузеры можно будет создать нативные плагины для отображения DOM напрямую в SmalltalkVM — это может добавить скорости. Этот же плагин может заставить браузер понимать тэг
Ещё одним обширным направлением, связанным с Вашим стремлением в сторону LLVM, может быть исследование возможностей Google Chrome Native Client. Он мог бы затащить Smalltalk VM в браузер прямо из WEB-страницы, оттранслировать его через LLVM в нативный код, и исполнять его там, в браузере, но со скоростью целевого микропроцессора и с уже отображённым DOM в Smalltalk VM. Очень интересным для Вас может показаться тот факт, что Native Client умеет компилировать С/С++ — т.е. ваша Smalltalk VM прямо «просится» туда :)
И наконец, последним приходящим мне в голову важным направлением, может стать популяризация Smalltalk в среде WEB-разработчиков — консольный Smalltalk так и просится стать CGI/FAST CGI/ISAPI (это для Windows IIS) приложением для любого популярного WEB-сервера.
А, вот ещё: желаю Вам не наступить на грабли создателей Dophin Smalltalk и некоторых других VM — экземпляры класса Process обязательно должны исполняться отдельными потоком OS, иначе упрётесь в производительность. Некрасиво в наш многоядерный век крутить всю VM одним ядром ;)
Вроде всё, спасибо за внимание, извините за «много букв».
Меня последнее время мучает такая мысль. QТ прекрасно конечно своей портабельносью, но очень сложно будет создать хорошее отображение «мира QT» в «мир Smalltalk». Т.е. клей смоллтока будет связывать C++ клей QT, а тот в свою очередь будет дёргать соотв. нативное API операционной системы. Какгбэ «ну и пусть», но всё-таки избыточно.
Идеальных миров не бывает, самое крутое в «смоллтоковости» было в самом начале, когда VM не была виртуальной, а исполнялось на всамделишнем железе Xerox, и среда Smalltalk была и OS, и средой для пользовательсктх приложений. Времена поменялись, «расцвели тысячи цветов»… и можно потеряться в этом бесконечном разнообразии аппаратуры, операционных систем и интерфейсов. Но вот нить, их связывающая: практически в каждой ОС есть WEB-браузер. И далее: тогда может быть вообще не привязываться к красивым закидонам GUI конкретной OS, и разработать весь GUI разработчика как WEB-интерфейс? VM компилируется как простое консольное приложение для конкретной ОС, и слушает TCP порт? К порту подключаемся WEB-браузером, и поехали! Вот вам Class Browser, вот вам отладчик, вот вам Transcript Window. Ну и ещё: качественный GUI разработчика — это тест на живучесть применённых идей, и там есть всё что нужно и для GUI пользовательских приложений. Все эти TreeView, ListView и всё такое прочее.
Производительность браузеров растёт, стандарты движутся, на HTML5 возможны грандиозные вещи, вплоть до мультимедии и WebGL.
Под некоторые популярные браузеры можно будет создать нативные плагины для отображения DOM напрямую в SmalltalkVM — это может добавить скорости. Этот же плагин может заставить браузер понимать тэг
<SCRIPT language="Smalltalk">бла-бла-бла</SCRIPT>.Ещё одним обширным направлением, связанным с Вашим стремлением в сторону LLVM, может быть исследование возможностей Google Chrome Native Client. Он мог бы затащить Smalltalk VM в браузер прямо из WEB-страницы, оттранслировать его через LLVM в нативный код, и исполнять его там, в браузере, но со скоростью целевого микропроцессора и с уже отображённым DOM в Smalltalk VM. Очень интересным для Вас может показаться тот факт, что Native Client умеет компилировать С/С++ — т.е. ваша Smalltalk VM прямо «просится» туда :)
И наконец, последним приходящим мне в голову важным направлением, может стать популяризация Smalltalk в среде WEB-разработчиков — консольный Smalltalk так и просится стать CGI/FAST CGI/ISAPI (это для Windows IIS) приложением для любого популярного WEB-сервера.
А, вот ещё: желаю Вам не наступить на грабли создателей Dophin Smalltalk и некоторых других VM — экземпляры класса Process обязательно должны исполняться отдельными потоком OS, иначе упрётесь в производительность. Некрасиво в наш многоядерный век крутить всю VM одним ядром ;)
Вроде всё, спасибо за внимание, извините за «много букв».
Спасибо за столь развернутый отзыв. По поводу Smalltalk для веба — все уже украдено до нас :) Вам следует посмотреть Amber Smalltalk. Это именно то, о чем вы пишете :)
Smalltalk давно и успешно применяется для веба: см. инструментарий Seaside.
По поводу Qt: у меня есть некоторые наработки в плане интерфейса. Собственно варианта два: либо реализовывать зеркалирование классов Qt в Smalltalk, наподобие того что сделается в PyQt, либо прозрачным образом пробрасывать вызовы. К счастью, Qt предоставляет хорошие интерфейсы метаклассов и возможности динамических вызовов. В рамках первых экспериментов я пойду по второму пути. Пример того как это может выглядеть, можно найти в ветке gui в последних строках тестового образа. Читать можно начиная со строки «RAWCLASS QMetaObject». Конечно, это всего лишь наброски и все может поменяться, но для прототипа пойдет.
По поводу многопоточности у меня тоже есть некоторое количество мыслей, которые следует структурировать. Я изначально планировал двигаться в этом направлении. Вообще, в мире есть уже примеры масштабирования Smalltalk на большое количество ядер, так что это все возможно.
Smalltalk давно и успешно применяется для веба: см. инструментарий Seaside.
По поводу Qt: у меня есть некоторые наработки в плане интерфейса. Собственно варианта два: либо реализовывать зеркалирование классов Qt в Smalltalk, наподобие того что сделается в PyQt, либо прозрачным образом пробрасывать вызовы. К счастью, Qt предоставляет хорошие интерфейсы метаклассов и возможности динамических вызовов. В рамках первых экспериментов я пойду по второму пути. Пример того как это может выглядеть, можно найти в ветке gui в последних строках тестового образа. Читать можно начиная со строки «RAWCLASS QMetaObject». Конечно, это всего лишь наброски и все может поменяться, но для прототипа пойдет.
По поводу многопоточности у меня тоже есть некоторое количество мыслей, которые следует структурировать. Я изначально планировал двигаться в этом направлении. Вообще, в мире есть уже примеры масштабирования Smalltalk на большое количество ядер, так что это все возможно.
Я понимаю цену уже существующих Ваших наработок. Но! Прошу заострить внимание на следующей мысли: не тащите за собой Qt и вообще всякого GUI в «ядро» Вашей реализации Smalltalk: оттолкнитесь от простой консольной VM, слущающей порт, всё! Этим обеспечите независиомсть от Qt, это может быть очень ценным. И SeaSide здесь может сослужить плохую службу — он в своей текущей реализации не предоставляет той роскоши разработки, какую обеспеспечивает, например, Dolphin Smalltalk GUI, однако самое интересное, HTML5 может дать вам почти те же навороченные GUI средства, которые даёт вам нативный (как пример) windows comctl32.dll!
Про Amber Smalltalk: он реализует Smalltalk VM средствами JavaScript. Это интересное направление, но хромающее в производительности, интерпретатор в интерпретаторе.
Ещё раз про Chrome Native Client, Вы всё-таки взгляните на него. Вы сможете начать эксперименты по портированию Smalltalk VM на рельсы LLVM прямо из С++ кода. Chrome Native Client уже предустановлен в каждую установку Хрома — огромное пространство, где это могло бы работать. Не говоря уже о том, что для его работы не нужна никакая «установка приложения» — зашли на сайт, и смолтолк уже у вас :)
Удачи Вам во всех начинаниях, и с наступающим Новым Годом!!!
Про Amber Smalltalk: он реализует Smalltalk VM средствами JavaScript. Это интересное направление, но хромающее в производительности, интерпретатор в интерпретаторе.
Ещё раз про Chrome Native Client, Вы всё-таки взгляните на него. Вы сможете начать эксперименты по портированию Smalltalk VM на рельсы LLVM прямо из С++ кода. Chrome Native Client уже предустановлен в каждую установку Хрома — огромное пространство, где это могло бы работать. Не говоря уже о том, что для его работы не нужна никакая «установка приложения» — зашли на сайт, и смолтолк уже у вас :)
Удачи Вам во всех начинаниях, и с наступающим Новым Годом!!!
Да, я понимаю ваши опасения. Просто llst сейчас, это в первую очередь исследовательский проект. Основная цель на данный момент — понять, насколько далеко можно зайти с LLVM. Второе — многопоточность и параллелизм (в том числе автоматический) посредством обмена сообщениями. Я считаю что Smalltalk идеально подходит для распараллеливания потому что сама концепция посылки сообщения, подлинная инкапсуляция данных и слабая связность как будто созданы для этого. Я специально выбрал LittleSmalltalk, как наименее загроможденный и не вставляющий палки в колеса своими ограничениями и «традициями». Так сказать, «свободный полет мысли». Qt и прочие «свистелки» опять же, вторичны. Поэтому я не собираюсь тратить много времени на оформизм (тем более что его у меня не так много).
NaCl обязательно посмотрю.
И вам удачи и спасибо за комментарии. Ради такого диалога я и писал статью.
С наступающим!
NaCl обязательно посмотрю.
И вам удачи и спасибо за комментарии. Ради такого диалога я и писал статью.
С наступающим!
Можно подробнее о том, что вы хотите от LLVM?
Прошу прощения, промазал с ответом. см. ниже.
Довольно много объяснять. Хватит на целый топик. Если в кратце, то построение графа в динамике оптимизация и патчинг кода на лету с учетом контекста выполнения методов
Очень, очень здорово! Лютый восторг. А не будет ли трудно вашему коллеге, humbug, рассказать о том, что он умеет с LLVM и как этому научился? Будет крайне интересно.
Я планирую написать цикл статей об интересных фишках LLVM, где и будут раскрыты мои навыки. К Halt'у присоединился потому, что хотел набраться реального боевого опыта с LLVM, для того, чтобы портировать один малоизвестный, но крайне интересный язык K++ на LLVM. А тут Дима стучится и говорит, что хочет написать llst =)
Научился сам, по интернетам.
Научился сам, по интернетам.
Небольшая поправка. Вместо
надо написать так:
ec.bytePointer += 2;
надо написать так:
ec.bytePointer += sizeof(uint16_t);
Спасибо за комментарий. А в каком случае может возникнуть такое расхождение? Из за выравнивания? Или на некоторых платформах под этот тип может выделяться больше памяти? Но я полагал что stdint типы как раз сделаны для того чтобы быть фиксированными по заявленному размеру вне зависимости от платформы.
Просто я знаю, что там в образе лежит именно два байта. Поэтому смещать указатель мне тоже надо именно на два. И это не зависит от платформы.
Sign up to leave a comment.
LLST: Новая жизнь Little Smalltalk