From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <20100217133109.GA10816@nibiru.local> <599f06db1002170606l2178c152i2f92a36fbf405163@mail.gmail.com> <20100217212630.GA15480@gradx.cs.jhu.edu> Date: Wed, 17 Feb 2010 15:22:34 -0800 Message-ID: <3e1162e61002171522tb34e196pf393f996d76a61ac@mail.gmail.com> From: David Leimbach To: ebo@sandien.com, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cd70d14086185047fd4201e Subject: Re: [9fans] Binary format Topicbox-Message-UUID: d65a75bc-ead5-11e9-9d60-3106f5b1d025 --000e0cd70d14086185047fd4201e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 17, 2010 at 3:16 PM, EBo wrote: > Nathaniel W Filardo said: > > > On Wed, Feb 17, 2010 at 03:06:57PM +0100, Gorka Guardiola wrote: > > > > * each module may have an entry point (main module w/o is allowed, > > > > even if it wouldn't make much sense ;-o), these are called after > > > > relocation, along the dependency tree, from leaf to root. > > > > > > no modules. > > > > That's not entirely true; there's (experimental ?) work for dynld(2), and > > the shipping compilers can already produce DLMs. (That said, libdynld is > > not yet part of the base system.) dynld(2) provides a system reminiscent > of > > dlopen() and dlsym(), but no dynamic linkage is supported (only dynamic > > loading). It is quite tastefully done and is useful to have for some > > applications (the python port springs to mind). > > Is dynamic loading and linkage something that people want? I have some old > experimental code written in Spirit++ (a C++ template library which > functionally replaces lex and yacc, and reads like EBNF). The old code is > for > a runtime polymorphic parser for RS274 (CNC g-code). I was experimenting > with > parsing historic CNC code, and play with different geometry engines. This > old > project is WAY down on my to-get-around-to list, but it might be an > interesting testbed for something later on. This would be useful for stuff > like a motion controller for the RepRap and DIY 3D Fab machines. > > For that matter, is there anything like Spirit++ > in > Plan9/Limbo? When I developed the code for my fist thesis I developed a > parser for some oddball finite difference equations produced by some > modeling > software. It was nice to have the code read like EBNF. > > Spirit is pretty amazing in that you can write very succinct and powerful code with it, and yet it is terrible in that when you get an error message you can end up with quite a disaster (due to the templates). I particularly like the Phoenix submodule in the new boost libraries for writing little functional tidbits with STL looping constructs and iterators. Speaking of which, Spirit appears to borrow pretty heavily from Parsec which is a monadic parser combinator framework for Haskell that I believe will work with Hugs, that also works on Plan 9. (I think Andrey ported Hugs a long time ago). I'd LOVE to have GHC on Plan 9, but my first attempts to get anything building with it were pretty frustrating. There's scheme language implementations available for plan 9, and I think one could either find or come up with a parsing framework like spirit for scheme that relied on continuations (more "native" to scheme than monads, though you could use monads too). Dave > EBo -- > > > --000e0cd70d14086185047fd4201e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 17, 2010 at 3:16 PM, EBo <ebo@sandien.com&g= t; wrote:
Nathaniel W Filardo <nwf@cs.jhu.edu> said:

> On Wed, Feb 17, 2010 at 03:06:57PM +0100, Gorka Guardiola wrote:
> > > * each module may have an entry point (main module w/o is al= lowed,
> > > =A0even if it wouldn't make much sense ;-o), these are c= alled after
> > > =A0relocation, along the dependency tree, from leaf to root.=
> >
> > no modules.
>
> That's not entirely true; there's (experimental ?) work for dy= nld(2), and
> the shipping compilers can already produce DLMs. =A0(That said, libdyn= ld is
> not yet part of the base system.) =A0dynld(2) provides a system remini= scent of
> dlopen() and dlsym(), but no dynamic linkage is supported (only dynami= c
> loading). =A0It is quite tastefully done and is useful to have for som= e
> applications (the python port springs to mind).

Is dynamic loading and linkage something that people want? =A0I have some o= ld
experimental code written in Spirit++ (a C++ template library which
functionally replaces lex and yacc, and reads like EBNF). =A0The old code i= s for
a runtime polymorphic parser for RS274 (CNC g-code). =A0I was experimenting= with
parsing historic CNC code, and play with different geometry engines. =A0Thi= s old
project is WAY down on my to-get-around-to list, but it might be an
interesting testbed for something later on. =A0This would be useful for stu= ff
like a motion controller for the RepRap and DIY 3D Fab machines.

For that matter, is there anything like Spirit++ <http://boost-spirit.com> in
Plan9/Limbo? =A0When I developed the code for my fist thesis I developed a<= br> parser for some oddball finite difference equations produced by some modeli= ng
software. =A0It was nice to have the code read like EBNF.


Spirit = is pretty amazing in that you can write very succinct and powerful code wit= h it, and yet it is terrible in that when you get an error message you can = end up with quite a disaster (due to the templates). =A0I particularly like= the Phoenix submodule in the new boost libraries for writing little functi= onal tidbits with STL looping constructs and iterators. =A0

Speaking of which, Spirit appears to borrow pretty heav= ily from Parsec which is a monadic parser combinator framework for Haskell = that I believe will work with Hugs, that also works on Plan 9. =A0(I think = Andrey ported Hugs a long time ago).

I'd LOVE to have GHC on Plan 9, but my first attemp= ts to get anything building with it were pretty frustrating.

=
There's scheme language implementations available for plan 9= , and I think one could either find or come up with a parsing framework lik= e spirit for scheme that relied on continuations (more "native" t= o scheme than monads, though you could use monads too).

Dave
=A0
=A0EBo --



--000e0cd70d14086185047fd4201e--