Thanks for the reply.


On 09/05/2017 05:35 PM, Ronie Salgado wrote:
Hello Jimmie,

On ESUG I only presented it for the innovation award. There is no scientific paper on Lowtalk itself yet, because most of the work on this front end is recently. I am probably submitting.

There is still the possibility on changing the syntax and some of mechanism that are used in Lowtalk, Currently I am showing what is possible to do.

What do you believe the best mailing list to list ask questions at some point in the future?
��
This is a good question. Currently I do not know. This is an early work, and there is still a lot more to do. We now have to discuss about how to proceed. I have to discuss properly with Eliot about how to keep proceeding. I am reusing some of his techniques for implementing some parts such as the stack to context mapping, and immediates objects.

Maybe it is unique enough that it would need its own mailing list at some point. Unless it became potentially a part of Pharo and thus suitable for pharo-dev.

Lowtalk is currently Pharo only, and it is completely standalone from the OpenSmalltalk VM. However, I am going to make a backend for Lowtalk that uses Lowcode to be able to use it inside the current image environment. Both use cases are interesting:
- standalone executables for embedding and soft realtime (videogames).

Would this also be a good way to do mobile, iOS and Android apps?

- keeping the current VM and reusing the in-image environment allows to use the full power of the Pharo/Squeak environment. In this case, Lowtalk can be used for getting a performance boost in numerical intensive software loops (e.g: matrix multiplication, typically an O(n^3) algorithm), without having to resort to the FFI for calling externally compiled C code.
��
I am definitely interested in this. I am interested in arrays of numbers and doing calculations on those numbers. I was thinking that I would be needing to code this in C and call from UFFI. I read your message and I thought that it meant I could code in Lowtalk and then call the new library via UFFI.

So, what I understand here is that I can code in Lowtalk for the Lowcode backend and not require UFFI? At least at some point in the future. That sounds awesome.

I want to use Lowtalk in Woden 2 exactly for the second use case. Currently in Woden 2 I am using the language described in the Lowcode paper. Because the type system introduces dependencies on the compilation order, it does not behave well with Monticello which I had to patch in Woden 2. With Lowtalk I am solving that problem by using standard text files, and multiple semantic analysis passes over the AST to define circular types lazily. for example:

Structure named: #LinkedListNode slots: {
��#next => (LinkedListNode pointer).
��#value => (Void pointer)
}.

Ok. I was confused in my brief look at GitHub as to whether we were programming in the image on with a text editor.
It would be nice if at some point it could be done from the image. Even if it is a with a new editor (possible from the new moldable work) understanding Lowtalk and tools to do compilation.

Possibilities are interesting.

Thanks again. I look forward to seeing what happens.

Jimmie

Best regards,
Ronie


2017-09-05 17:02 GMT+02:00 Jimmie <jlhouchin@gmail.com>:

Hello Ronie,

I think this looks very interesting. I just downloaded your paper to read. I look forward to seeing the video of your ESUG demonstration.

What do you believe the best mailing list to list ask questions at some point in the future?

Thanks again for your work on this interesting project.

Jimmie




On 08/30/2017 11:05 AM, Ronie Salgado wrote:
Hi All,

I am finally glad to announce an initial version of my secret experiment, Lowtalk: https://github.com/ronsaldo/lowtalk

Lowtalk is a new Smalltalk dialect that generates relocatable binary object code, that can be linked with any C program or used to generate a standalone executable with the C linker. I am designing Lowtalk as a language for video game developing, where performance and multi-threading support is important. The Lowtalk compiler is completely written in Pharo.

The main features of Lowtalk are the following:
- The compiler is actually a meta circular evaluator, whose features are used for bootstraping the Lowtalk kernel.
- The Lowtalk object model, including the layout of the objects is defined in the language itself.
- Direct interface with C. There is an almost 1:1 mapping between the Lowtalk native types and the C types. There is a syntax extension for calling C functions.
-Support for real multi-threading.
- The current object model uses automatic reference counting, which is slow, but makes supporting real multi-threading easier.
- Immediates are based on the Spur object model.
- Partial support for generating debugging information in the DWARF standard. It is possible to place breakpoints and get correct stack traces with gdb.

Lowtalk is on the line of my work with Lowcode, and I am planning on making a Lowtalk backend that uses Lowcode. The Lowtalk type system is almost the same as the one that I described at the paper: Lowcode: Extending Pharo with C Types to Improve Performance

I will make a video later, and a proper demonstration at ESUG.

Best regards,
Ronie