[Cuis-dev] OMeta working again for Cuis 6.3
Andres Valloud
ten at smallinteger.com
Sun Apr 14 05:28:38 PDT 2024
And look at that, written in C99, a nice "vanilla" flavor of C!
On 4/14/24 1:07 AM, Luciano Notarfrancesco wrote:
> 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
> <https://github.com/flame/blis>
>
> On Sun, Apr 14, 2024 at 11:26 Andres Valloud <ten at smallinteger.com
> <mailto: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>
> <mailto: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>
> <mailto: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>
> >> <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>
> >> <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>
> <mailto: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>
> >> <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>
> <mailto: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>
> > <https://lists.cuis.st/mailman/listinfo/cuis-dev
> <https://lists.cuis.st/mailman/listinfo/cuis-dev>>
> >
> >
>
More information about the Cuis-dev
mailing list