[Cuis-dev] OMeta working again for Cuis 6.3

[Luciano Notarfrancesco]

Hi Michal,
That’s very interesting. I have a very concrete application for this. I
need to compute with tuples, matrices and polinomials over integers modulo
a small modulus (say, it fits in a register, or half register). These
tuples, polynomials and matrices are stored in arrays (for example
WordArrays, 32 bits per entry). The most critical operation is matrix
multiplication, since a lot of the rest can reduce to matrix
multiplication. I’ve been experimenting with a small external library
written in C that converts to floating point, does matrix multiplication
with a BLAS library, and converts back to modular integers, and i call it
via FFI. Of course I’d prefer to do all in Cuis… so i’m looking forward for
your project!

Regards,
Luciano

On Sat, Apr 13, 2024 at 21:13 Michał Olszewski via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Hi Phil,
>
> Thanks! I was alluding to a past suggestion to use OMeta and Dan Amelang's
> Nile, when they were released back in 2008 as part of VPRI, in Squeak
> Kernel classes to reduce overall complexity of compilation and graphics
> rendering.
>
> And yes, the generated code would be free of any OMeta deps - in this case
> it's simply used as compilation pipeline that transforms input code through
> various compilation stages (AST->AST with optimized special
> sends->bytecode).
>
> It would simplify overall architecture and would perhaps permit to use
> compiler as service for e.g. syntax highlighting or some other stuff that
> requires analysis of source code.
>
> Currently, it seems like, one has to separately implement parser for
> syntax styling etc.
>
> I'm using OMeta for my bachelor thesis (in very very early stages, defense
> is in Feb next year) which is about custom high level dynamic streaming
> language. Pretty much bringing access to high performance computations on
> CPU & GPU to Cuis, without leaving comfort of it :).
>
> I'm going to use it for all stages of compilation (parsing, optimizing,
> generating etc.).
>
> Too early to talk to about details but since I'm going to write the
> thesis, the language is going to be released at least in some usable state
> :) Hopefully more.
>
> Cheers,
> Michał
> On 11.04.2024 08:05, Phil B wrote:
>
> Hi Michał,
>
> I'm still around... just been busy with other things.  Thanks for your
> interest and efforts!  I'll take a look at your changes though it will
> probably be this weekend before I can get to it.
>
> As far as making Cuis a first-class citizen: that's not likely to
> happen, nor would it be desirable. (I experimented with that and the result
> was not good... there's too much of an impedance mismatch)
>
> Regarding the other areas you touched on:
> 1) Debugging: there should be a more robust OMeta parser (i.e. a subclass
> of OMeta2) to better catch more errors (esp. recursion) at parse/compile
> time, when possible.  It's entirely possible that the syntax needs to be
> extended to support this.
> 2) Performance: assuming you're talking about runtime performance where
> you have a parser being called repeatedly you probably want to look at
> creating a parser that targets (i.e. emits) code for a more performant
> parser (there's no law that says OMeta has to always target OMeta!) as
> OMeta's PEG is going to have relatively poor runtime performance vs other
> parser approaches, especially if you have any recursion in your parser
> and/or the input to your parser is characters (i.e. parsing data files at
> runtime, for example.)   I believe that's still an open problem with PEGs.
> (not sure as I haven't kept up with the state of the art on this)
> 3) Cuis compiling etc: use OMeta to emit Cuis/Smalltalk code that is used
> anywhere in the image, sure... as long as said emitted code is free of
> OMeta dependencies.  Put another way: if your generated code is in a
> subclass of OMeta2 and calls the parsing engine it would probably not be
> safe enough to use as an image-level dependency, if your generated code is
> *not* in a subclass of OMeta2 you might be fine.
>
> Thanks,
> Phil
>
> On Wed, Apr 10, 2024 at 4:37 PM Michał Olszewski via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> Hi all,
>>
>> I fixed OMeta package from pbella so now it works again for Cuis 6.3
>> (>6291). Yay! I made a couple of tests with the grammar definitions and
>> syntax highlighting and so far it's kind of back to the working state:
>>
>> https://github.com/michalo1334/OMeta-Cuis
>>
>> Just requested pull to original repo:
>> https://github.com/pbella/OMeta-Cuis but not sure if the author is still
>> active in the community.
>>
>> However, in OMeta-derived classes it incorrectly highlights instance
>> variables in red and displays := instead of <-. If someone has time to
>> take a quick look at the Shout styler code, would be great. Right now
>> it's an ugly fix so that there is any highlighting at all -  it's nice
>> to see a colored text.
>>
>> And then there is the problem to make OMeta first class citizen
>> (debugging, improve performance, maybe even use it for Cuis compiling &
>> code generation machinery?).
>>
>> Cheers,
>> Michał
>>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240414/018a30f2/attachment.htm>