<div dir="auto">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 <a href="https://github.com/flame/blis">https://github.com/flame/blis</a></div><div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 14, 2024 at 11:26 Andres Valloud <<a href="mailto:ten@smallinteger.com">ten@smallinteger.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">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 > <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>>> 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 >> <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>>> 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: >> >> <a href="https://github.com/michalo1334/OMeta-Cuis" rel="noreferrer" target="_blank">https://github.com/michalo1334/OMeta-Cuis</a> >> <<a href="https://github.com/michalo1334/OMeta-Cuis" rel="noreferrer" target="_blank">https://github.com/michalo1334/OMeta-Cuis</a>> >> >> Just requested pull to original repo: >> <a href="https://github.com/pbella/OMeta-Cuis" rel="noreferrer" target="_blank">https://github.com/pbella/OMeta-Cuis</a> >> <<a href="https://github.com/pbella/OMeta-Cuis" rel="noreferrer" target="_blank">https://github.com/pbella/OMeta-Cuis</a>> 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 >> <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a>> >> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> >> <<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a>> >> > -- > Cuis-dev mailing list > <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a>> > <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> > <<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a>> > > </blockquote></div></div>