Re: The wip-mescc-module branch

[Jan Nieuwenhuizen]

Timothy Sample writes:

Hey Tim,

> Since we’re CC’ing bug-mes, I should mention that this work is funded by
> NLnet – thanks NLnet!  :)

That's right!  Thank you NlNet!

I figured having a record of these discussions about problems and
progress/process might be a good idea.  We probably should have done
that even with the previous problems you encountered on
wip-guile-modules.  Oh well...

> Jan Nieuwenhuizen <janneke@gnu.org> writes:
>
>> Timothy Sample writes:
>>
>>     mes/module/nyacc/lalr.mes
>>
>> ...and it turns out that file is not used.  Wow, that explains a lot:
>> Why Nyacc is not terribly slow and why the flakey psyntax seemed to be
>> good enough for Nyacc.  I've pushed a patch to remove that file to
>> wip-mescc-module @ gitlab.
>
> That’s actually pretty funny (in a frustrating sort of way)!

Yeah %-)

> Maybe the overhead is mostly constant.  After booting the module system
> and processing the fixed number of ‘define-module’ forms (which
> apparently takes around a second here), the two versions run at about
> the same speed.

Yes, so at least for now we're OK.

> From what I saw profiling, I would argue that evaluation itself is the
> biggest (all the dispatching maybe?),

Ah that could be.  At the time that compiling hello.c took several
hours, the bottleneck was variable lookup.  It makes sense if that it is
no longer the bottleneck.

> with lookups and stack management coming next.  Also (looking at it
> again as I write this), it seems that the lookup time is mostly due to
> lexically-bound identifiers.  The module system seems to slow down
> ‘expand_variable_’ a bit, but that might be because of a poor
> implementation of ‘module_variable’ (maybe using the C stack to
> traverse the module “uses” graph would be faster than fussing with
> ‘append2’).  Either way, ISTM that there are more gains to be made by
> simplifying ‘eval_apply’ and speeding up non-module lookups.

OK.

>> I propose to keep wip-mescc-module (or any another derived branch) at
>> least until that time, cleanup, dig up commits from wip-m2 and work
>> towards a 0.25 release (check it in the guix bootstrap, etc).  It will
>> most probably need some work to support Gash/Gash-Utils too.  As you
>> probably have seen, the SRFI support in Mes (e.g. SRFI-1) is quite
>> minimal: There's only what's needed for running mescc.  One reason for
>> being minimalistic here was that all bindings lived in a global scope,
>> and having usused definitions would only slow down mescc (which was
>> unbearably slow, initially).  I'm hoping that with guile-modules, adding
>> more of SRFI will not have (such) a negative impact.
>
> Sounds good!  I got a start porting Gash to Mes last year, so I’m hoping
> I can reuse that and have the basics running shortly.

That's a pretty exciting prospect.

>> Having seen your work on Mes, I'm happy to give you commit access to
>> savannah.  Maybe that's helpful to give a branch more exposure.
>
> That makes sense.  Having a wip-gash branch on Savannah will make my
> work more visible to passers-by, which is always good.  As a complete
> fluke, I caught some people discussing Gash and Mes at #bootstrappable,
> and I was able to say “I’m working on it!”  I can’t always be on IRC,
> though.  :)

Sure, please just request membership so that I can approve it.

> Agreed for signed commits and linear history (which is also my personal
> preference, so no trouble there).  Also, you’re right that I probably
> won’t be committing to master anyway.

Great,
Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com