[Cuis-dev] OMeta working again for Cuis 6.3

Luciano Notarfrancesco luchiano at gmail.com
Sun Apr 14 01:07:58 PDT 2024 

Yes, Nile was amazing. It would be great to bridge the gap between
Smalltalk and high performance computing with something on those lines. It
also brings to mind BLIS https://github.com/flame/blis

On Sun, Apr 14, 2024 at 11:26 Andres Valloud <ten at smallinteger.com> wrote:

> That Nile bit is a great example of code reduction.  The demos were
> quite impressive and the whole thing was around IIRC 400 LOC or so.  Ian
> Piumarta's talk re: to build a better mouse trap is also related because
> of the reference to Earley parsers.
>
> On 4/13/24 20:14, Luciano Notarfrancesco via Cuis-dev wrote:
> > 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 <mailto: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 <mailto: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
> >>         <https://github.com/michalo1334/OMeta-Cuis>
> >>
> >>         Just requested pull to original repo:
> >>         https://github.com/pbella/OMeta-Cuis
> >>         <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 <mailto:Cuis-dev at lists.cuis.st>
> >>         https://lists.cuis.st/mailman/listinfo/cuis-dev
> >>         <https://lists.cuis.st/mailman/listinfo/cuis-dev>
> >>
> >     --
> >     Cuis-dev mailing list
> >     Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
> >     https://lists.cuis.st/mailman/listinfo/cuis-dev
> >     <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/faf39d66/attachment-0001.htm>

More information about the Cuis-dev mailing list