Re: Neat hacks for a birthday
l...@gnu.org (Ludovic Courtès) writes: > Hello Guilers! > > Next week, on February 16th, is the first anniversary of Guile 2.0! > “… [A]nd from the shimmering lake of parens rose a Scheme, small yet strong, bestowing upon the righteous the gift of Elegance and the power to tame the mighty beast known as C. And the devout did embrace this gift and called it by the name of Guile, for it is truly a cunning Scheme.” > Like all great events, it ought to be celebrated. Hear! Hear! > So, here’s a suggestion: let’s write neat hacks that integrate Guile > with some other piece of software, preferably GNU packages. Examples > include extending GCC or GDB extension in Guile, work on Mike’s > Zile-on-Guile, enhanced Guile support in GNU Make, and Hurd file systems > written in Guile. > > Of course, like all quick hacks, these will essentially be proofs of > concept, but hey, perhaps some will eventually become actual software > packages? A worthy goal! The more Guile is used in the wild, the closer we'll be to world peace. > If you’re up to the challenge, you’re welcome to announce your intent > here. On Feb. 16th, we’ll collect the list of neat hacks and let the > world know! I’m in! Details below. > Thanks, > Ludo’. > > PS: I personally intend to come up with a simple GCC plug-in interface > for Guile. Let’s see how it goes… I’ve been working sporadically on a Guile binding to the GPGME[1] library, with the hope that it will encourage others to integrate both Guile and privacy features into their software. At this time GPGME/Guile (read as “GPGME-with-Guile") is not in a pretty (or functional!) state, but I've put it up on Github[2] both as a means of sharing and as a motivator to get to work. I don't want any shoddy code to be marring my public image, after all. With that, I hope to have something worth showing in six days. Till then! -- Atom X http://deadlyhead.com [1]http://www.gnupg.org/related_software/gpgme/ [2]https://github.com/xatom/GPGME-Guile
Re: Neat hacks for a birthday
Well done! Since you mentioned GPG, I recall that I've wrote libgcrypt-guile last year. It's here git://gitorious.org/nacre/libgcrypt-guile.git But I just did the Message Digest Algorithm part, because I need md5 at that time. Then I thrown it to the corner... Anyway, I think it's useful for some guys, and it's easy to use(see README), so I announced it here if someone need it. On Fri, Feb 10, 2012 at 4:49 PM, Atom X wrote: > l...@gnu.org (Ludovic Courtès) writes: > > > Hello Guilers! > > > > Next week, on February 16th, is the first anniversary of Guile 2.0! > > > > “… [A]nd from the shimmering lake of parens rose a Scheme, small yet > strong, bestowing upon the righteous the gift of Elegance and the power > to tame the mighty beast known as C. And the devout did embrace this > gift and called it by the name of Guile, for it is truly a cunning > Scheme.” > > > Like all great events, it ought to be celebrated. > > Hear! Hear! > > > So, here’s a suggestion: let’s write neat hacks that integrate Guile > > with some other piece of software, preferably GNU packages. Examples > > include extending GCC or GDB extension in Guile, work on Mike’s > > Zile-on-Guile, enhanced Guile support in GNU Make, and Hurd file systems > > written in Guile. > > > > Of course, like all quick hacks, these will essentially be proofs of > > concept, but hey, perhaps some will eventually become actual software > > packages? > > A worthy goal! The more Guile is used in the wild, the closer we'll be > to world peace. > > > If you’re up to the challenge, you’re welcome to announce your intent > > here. On Feb. 16th, we’ll collect the list of neat hacks and let the > > world know! > > I’m in! Details below. > > > Thanks, > > Ludo’. > > > > PS: I personally intend to come up with a simple GCC plug-in interface > > for Guile. Let’s see how it goes… > > I’ve been working sporadically on a Guile binding to the GPGME[1] > library, with the hope that it will encourage others to integrate both > Guile and privacy features into their software. At this time > GPGME/Guile (read as “GPGME-with-Guile") is not in a pretty (or > functional!) state, but I've put it up on Github[2] both as a means of > sharing and as a motivator to get to work. I don't want any shoddy code > to be marring my public image, after all. > > With that, I hope to have something worth showing in six days. Till > then! > > > -- Atom X > http://deadlyhead.com > > [1]http://www.gnupg.org/related_software/gpgme/ > > [2]https://github.com/xatom/GPGME-Guile > >
Re: Neat hacks for a birthday
On Thu, Feb 9, 2012 at 9:38 AM, Ian Price wrote:
> l...@gnu.org (Ludovic Courtès) writes:
>
> > So, here’s a suggestion: let’s write neat hacks that integrate Guile
> > with some other piece of software, preferably GNU packages. Examples
> > include extending GCC or GDB extension in Guile, work on Mike’s
> > Zile-on-Guile, enhanced Guile support in GNU Make, and Hurd file systems
> > written in Guile.
> As I said on #guile, I'd like to see someone (i.e not me :) hack scheme
> evaluation into bash.
>
>
Hack scheme evaluation into bash huh?
I love that idea so much!
And I spend some time to read Bash code, then I think there're two ways do
go:
The easy way is to write a loadable builtin command for Bash which can do
the simple Scheme evaluation work with Guile core. And I finished it: git://
gitorious.org/nacre/big.git
PS: 'BIG' for Bash Inner Guile
If you want to load it, type:
# enable -f ./big big
then you may use big in bash:
# big "(+ 1 1)"
2
or run a REPL
# big
Bash inner Guile interpreter!
(define func
(lambda (x) (+ 1)))
==> #
(func 1)
==> 1
type Ctrl+D to quit.
It's so easy that almost useless, one may use Guile REPL rather than BIG or
'guile -c' to eval expressions. But as Ludo said "a proof of concept". ;-)
All I expected is the harder way. But I'm not quite familiar with
Bash architecture, so I just provide some suggestions and wishes here:
We may modify "parser.y" to add S-exp parsing, and eval it with Guile core.
In the original way, if subshell failed to lookup function name, it return
EXECUTION_FAILURE directly. I think there's a way to pass it to Guile core
and evaluate it:
# (+ 1 1) --> '+' is an invalid function --> pass "(+ 1 1)" to
scm_eval_string
If we can use S-exp in Bash, I think these would be interesting:
x=5
echo "$((+ 1 ${x}))" ==> 6
echo "$((expt 2 ${x}))" ==> 32
Moreover, maybe modify the evaluator of Bash and transform "define" to
define a variable in Bash? Then the namespace is unified in Bash, when Bash
code passes exp into Guile, all variables within will be evaluated to the
actual value and Guile will eval the exp. But I think that would bereave
lexical scope of Scheme code.
Anyone comment?
> If you’re up to the challenge, you’re welcome to announce your intent
> > here. On Feb. 16th, we’ll collect the list of neat hacks and let the
> > world know!
> As I also said on #guile, I picked gdbm for the gnu package I'm going to
> integrate. I've already hacked somewhat useful bindings, but still more
> to do. https://github.com/ijp/guile-gdbm if anyone is interested
>
> > PS: I personally intend to come up with a simple GCC plug-in interface
> > for Guile. Let’s see how it goes…
> I look forward to that.
>
> Come on guilers, that's two of us stepped up to the plate so far. What
> are you, chicken? ;-)
>
> --
> Ian Price
>
> "Programming is like pinball. The reward for doing it well is
> the opportunity to do it again" - from "The Wizardy Compiled"
>
>
Re: Neat hacks for a birthday
l...@gnu.org (Ludovic Courtès) writes: > Hello Guilers! > > Next week, on February 16th, is the first anniversary of Guile 2.0! > “… [A]nd from the shimmering lake of parens rose a Scheme, small yet strong, bestowing upon the righteous the gift of Elegance and the power to tame the mighty beast known as C. And the devout did embrace this gift and called it by the name of Guile, for it is truly a cunning Scheme.” > Like all great events, it ought to be celebrated. Hear! Hear! > So, here’s a suggestion: let’s write neat hacks that integrate Guile > with some other piece of software, preferably GNU packages. Examples > include extending GCC or GDB extension in Guile, work on Mike’s > Zile-on-Guile, enhanced Guile support in GNU Make, and Hurd file systems > written in Guile. > > Of course, like all quick hacks, these will essentially be proofs of > concept, but hey, perhaps some will eventually become actual software > packages? A worthy goal! The more Guile is used in the wild, the closer we'll be to world peace. > If you’re up to the challenge, you’re welcome to announce your intent > here. On Feb. 16th, we’ll collect the list of neat hacks and let the > world know! I’m in! Details below. > Thanks, > Ludo’. > > PS: I personally intend to come up with a simple GCC plug-in interface > for Guile. Let’s see how it goes… I’ve been working sporadically on a Guile binding to the GPGME[1] library, with the hope that it will encourage others to integrate both Guile and privacy features into their software. At this time GPGME/Guile (read as “GPGME-with-Guile") is not in a pretty (or functional!) state, but I've put it up on Github[2] both as a means of sharing and as a motivator to get to work. I don't want any shoddy code to be marring my public image, after all. With that, I hope to have something worth showing in six days. Till then! -- Atom X http://deadlyhead.com [1]http://www.gnupg.org/related_software/gpgme/ [2]https://github.com/xatom/GPGME-Guile
Some I/O Questions
Hello, I have some questions regarding Guile I/O and byte order. 1. Is there an I/O function for reading a fixed set of bytes into a buffer, i.e. if I wanted to read a 56-byte string from a binary archive? 2. Is there a way to specifically read a 8/16/32/64-bit string from a file/port? 3. Is there a built-in function for converting between byte orders (i.e. BSD-style htobe32 and such) or must I implement them myself? 4. Is writing an archive manager using Guile for implementing archive formats a bad idea to start with? Thank you for your time, - LM http://entertainingsoftware.com/
Re: Some I/O Questions
Luiji Maryo writes: > Hello, > > I have some questions regarding Guile I/O and byte order. If you are dealing with binary data, you should be using bytevectors and binary ports, rather than strings. > 1. Is there an I/O function for reading a fixed set of bytes into a > buffer, i.e. if I wanted to read a 56-byte string from a binary > archive? For this, In (ice-9 binary-ports) or (rnrs io ports), there is 'get-bytevector-n!' > 2. Is there a way to specifically read a 8/16/32/64-bit string from a > file/port? For reading bytes you can use 'get-u8', and for reading multiple bytes as a bytevector 'get-bytevector-n'. (rnrs bytevectors) contains procedures for setting/getting 8/16/32/64 bit quantities. > 3. Is there a built-in function for converting between byte orders > (i.e. BSD-style htobe32 and such) or must I implement them myself? (rnrs bytevectors) has procedures for dealing with endianness, at the bytevector level. So I can, for instance, use (bytevector-u16-ref bv index (native-endianness)) to extract a 16 bit integer from a given index in a bytevector. If you wanted to specify a particular endianness, I could use (endianness big) or (endianness little). For integers you could use ntohs, ntohl, htons, htonl, but that is native endianness <-> network order only. > 4. Is writing an archive manager using Guile for implementing archive > formats a bad idea to start with? Writing in Scheme is never a bad idea. ;-) -- Ian Price "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
Re: Neat hacks for a birthday
Hi!
Nala Ginrut skribis:
> The easy way is to write a loadable builtin command for Bash which can do
> the simple Scheme evaluation work with Guile core. And I finished it: git://
> gitorious.org/nacre/big.git
> PS: 'BIG' for Bash Inner Guile
Excellent. :-)
[...]
> It's so easy that almost useless, one may use Guile REPL rather than BIG or
> 'guile -c' to eval expressions. But as Ludo said "a proof of concept". ;-)
Yes, that’s the idea. :-)
> All I expected is the harder way. But I'm not quite familiar with
> Bash architecture, so I just provide some suggestions and wishes here:
> We may modify "parser.y" to add S-exp parsing
[...]
> If we can use S-exp in Bash, I think these would be interesting:
> x=5
> echo "$((+ 1 ${x}))" ==> 6
> echo "$((expt 2 ${x}))" ==> 32
Instead of adding an s-exp parser in Bash, how about adding a single new
syntax form, say “$) EXPR ($” (there are few available tokens!), that
would parse EXPR with scm_read, and evaluate it with scm_eval?
> Moreover, maybe modify the evaluator of Bash and transform "define" to
> define a variable in Bash? Then the namespace is unified in Bash, when Bash
> code passes exp into Guile, all variables within will be evaluated to the
> actual value and Guile will eval the exp. But I think that would bereave
> lexical scope of Scheme code.
Actually, Emacs’ Eshell does something like that for ELisp
functions–i.e., one can invoke both ‘ls’ and ‘find-file’, seamlessly.
Food for thought. :-)
Thanks,
Ludo’.
