<div dir="auto">Hi Michal,</div><div dir="auto">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!</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Luciano</div><div dir="auto"><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 13, 2024 at 21:13 Michał Olszewski via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></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)"><u></u>

  
  <div>
    <p>Hi Phil,</p>
    <p>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.</p>
    <p>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). </p>
    <p>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.</p>
    <p>Currently, it seems like, one has to separately implement parser
      for syntax styling etc.</p>
    <p>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 :). <br>
    </p>
    <p>I'm going to use it for all stages of compilation (parsing,
      optimizing, generating etc.).</p>
    <p>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.</p>
    <p>Cheers,<br>
      Michał<br>
    </p></div><div>
    <div>On 11.04.2024 08:05, Phil B wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hi Michał,
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>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)</div>
        <div><br>
        </div>
        <div>Regarding the other areas you touched on:</div>
        <div>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.</div>
        <div>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)</div>
        <div>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.</div>
        <div><br>
        </div>
        <div>Thanks,</div>
        <div>Phil</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">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>>
          wrote:<br>
        </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)">Hi
          all,<br>
          <br>
          I fixed OMeta package from pbella so now it works again for
          Cuis 6.3 <br>
          (>6291). Yay! I made a couple of tests with the grammar
          definitions and <br>
          syntax highlighting and so far it's kind of back to the
          working state:<br>
          <br>
          <a href="https://github.com/michalo1334/OMeta-Cuis" rel="noreferrer" target="_blank">https://github.com/michalo1334/OMeta-Cuis</a><br>
          <br>
          Just requested pull to original repo: <br>
          <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 <br>
          active in the community.<br>
          <br>
          However, in OMeta-derived classes it incorrectly highlights
          instance <br>
          variables in red and displays := instead of <-. If someone
          has time to <br>
          take a quick look at the Shout styler code, would be great.
          Right now <br>
          it's an ugly fix so that there is any highlighting at all - 
          it's nice <br>
          to see a colored text.<br>
          <br>
          And then there is the problem to make OMeta first class
          citizen <br>
          (debugging, improve performance, maybe even use it for Cuis
          compiling & <br>
          code generation machinery?).<br>
          <br>
          Cheers,<br>
          Michał<br>
          <br>
          -- <br>
          Cuis-dev mailing list<br>
          <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
          <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
        </blockquote>
      </div>
    </blockquote>
  </div>

-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div></div>