Re: Can somebody help to explain why result from atan does not equal a real?

[Mark H Weaver]

I wrote:
> Having looked more closely, I see now that our 'string->number' is also
> less precise than it should be.

Sorry, I was mistaken about this.  Our 'string->number' is fine.

 Mark

Re: First steps towards a window manager

[Ludovic Courtès]

Hi!

Mark Witmer  skribis:

> First of all, I have guile-xlib working with guile-2.0; I'm calling my
> branch "guile2-xlib." You can use git and pull it from
> http://github.com/mwitmer/guile2-xlib or download an archive at
> http://markwitmer.com/dist/guile2-xlib-0.1.tar.gz. I'm still toying with
> the idea of writing some xcb bindings, time permitting!

Excellent!

[...]

> A lot of this is inspired by Stumpwm, a pretty nifty tiling wm written
> in common lisp that's similarly configurable.

In a similar vein, TTN wrote RPX, a Ratpoison clone that runs on Guile
1.4 with his own xlib bindings.

  http://gnuvola.org/software/rpx/

Perhaps it can be ported to your bindings + Guile 2.0?

Thanks,
Ludo’.

Re: [ANN] the Guile 100 Programs Project

[zx spectrumgomas]

On Thu, Jan 31, 2013 at 12:04 AM, Mike Gran  wrote:
> Hello.  I'm pleased to announce the upcoming Guile 100 Programs
> Project.
>
> The Guile 100 Programs Project is an opportunity to show off your
> Guile skills in exchange for a small honorarium.
>
> Each week, on Monday, I'll announce a coding project and ask for
> volunteers.  On Wednesday, a volunteer will be chosen at random from
> all entrants.  The volunteer will have two weeks to complete the task.
> If judged to have completed the task correctly, he or she will receive
> a honorarium of 100 USD.
>
> The task will either be a Scheme script, a bug fix on an existing
> project, or a C code with Guile bindings.

There are still good men in the world.

Re: libguilereadline load

[Dmitry Roshchin]

On Tuesday 22 January 2013 23:09:51 Ludovic Courtès wrote:
> Hi,
> 
> Dmitry Roshchin  skribis:
> > Is it normal, that guile tries to load "libguilereadline-v-18.so" instead
> > of "libguilereadline-v-18.so.18"? Guile  version - 2.0.7.
> 
> You normally have both, as well as libguilereadline-v-18.la, no?
> 
> Guile uses ltdl for dynamic loading (info "(libtool) Using libltdl").
> The rule is to first search for .la files.  The .la file tells ltdl that
> the real library is the .so.18 file, which ltdl then loads.
> 
> When the .la file is missing, ltdl tries the .so file instead (not the
> .so.18 file).
> 

openSUSE packaging policy requires to remove .la files. And .so file is 
contained in guile-devel package. So  it doesn't work by default.

Re: libguilereadline load

[Nala Ginrut]

On Fri, 2013-02-01 at 13:52 +0400, Dmitry Roshchin wrote:
> On Tuesday 22 January 2013 23:09:51 Ludovic Courtès wrote:
> > Hi,
> > 
> > Dmitry Roshchin  skribis:
> > > Is it normal, that guile tries to load "libguilereadline-v-18.so" instead
> > > of "libguilereadline-v-18.so.18"? Guile  version - 2.0.7.
> > 
> > You normally have both, as well as libguilereadline-v-18.la, no?
> > 
> > Guile uses ltdl for dynamic loading (info "(libtool) Using libltdl").
> > The rule is to first search for .la files.  The .la file tells ltdl that
> > the real library is the .so.18 file, which ltdl then loads.
> > 
> > When the .la file is missing, ltdl tries the .so file instead (not the
> > .so.18 file).
> > 
> 
> openSUSE packaging policy requires to remove .la files. And .so file is 
> contained in guile-devel package. So  it doesn't work by default.
> 

And actually, even Fedora remove *.la too:
http://fedoraproject.org/wiki/Packaging:Guidelines

@ludo: Is there any chance to fix it? Folks have to install -devel
packages to run Guile, or there's no *.so file.

Guile OpenGL bindings

[Andy Wingo]

Hi Javier,

Have you had time to think about GL bindings for Guile?  I had been
meaning to do something about it for a long time, and finally got around
to a first hack last week.  Daniel and I are working in this repo:

  https://gitorious.org/guile-figl

The idea is to use the FFI to make a low-level, complete interface, and
then as needed to make higher-level more Scheme-like wrappers.  I also
really wanted documentation, so I munged the upstream docbook into
texinfo and wrote that out into docstrings and .texi files.  The binding
isn't working yet, but maybe soon.  I'd like to avoid C if I can.

Daniel has an FFI-based GLUT wrapper that he is merging in that repo as
well.  Are you interested in joining efforts?  I can add you to the
gitorious project if you like.

Cheers,

Andy
-- 
http://wingolog.org/

Re: Guile OpenGL bindings

[Javier Sancho]

Andy Wingo wrote:
> Hi Javier,

Hi.

> Have you had time to think about GL bindings for Guile?

Not much. I've been a little busy with my first child :-)
Just this week I'm back to thinking about it.

> The idea is to use the FFI to make a low-level, complete interface, and
> then as needed to make higher-level more Scheme-like wrappers.  I also
> really wanted documentation, so I munged the upstream docbook into
> texinfo and wrote that out into docstrings and .texi files.  The binding
> isn't working yet, but maybe soon.  I'd like to avoid C if I can.

Aleix Conchillo is also working with OpenGL and encountered a problem
with glutInit and char**. You can see it at
http://lists.gnu.org/archive/html/guile-devel/2012-07/msg00074.html
Someone mentioned performance issues when using FFI, too.

> Daniel has an FFI-based GLUT wrapper that he is merging in that repo as
> well.  Are you interested in joining efforts?  I can add you to the
> gitorious project if you like.

Well, I can't promise anything, but yes, I'm very interested in this project.

This weekend I'll try to hack a little.

Cheers.

--
Javier Sancho Fernández - http://www.jsancho.org/
Associate Member of the Free Software Foundation - http://www.fsf.org/
Contra el DRM - http://www.defectivebydesign.org/what_is_drm

Re: Guile OpenGL bindings

[Daniel Hartwig]

On 1 February 2013 21:02, Javier Sancho  wrote:
> Aleix Conchillo is also working with OpenGL and encountered a problem
> with glutInit and char**. You can see it at
> http://lists.gnu.org/archive/html/guile-devel/2012-07/msg00074.html

Mark's suggestion is spot on, even points out one issue with memory
that I have missed.

It seems that Aleix later moved to a C binding, though I am confident
this can be avoided (c.f. cl-opengl).  Anyway, this function is
working fine in the bindings I have prepared (sans the memory issue).

GLUT bindings cover all functions, but missing constants.  These to
follow shortly.

Andy's work on the sxml side has the GL bindings *almost* running as
well.  I'll look to finish those in the next few days if someone
doesn't beat me to it.

> Someone mentioned performance issues when using FFI, too.

For modern GL programming without glBegin/End, Vertex/Color/Normal,
etc. the performance impact of FFI should be negligable.  There are
few GL calls compared to the volume of data that is passed.

The real critical part will be how the user manipulates their vertex
data, if this is done frequently on the scheme side.  Mapping (typed)
bytevectors, or srfi-4 to gl arrays will help with that, and avoiding
the implicit type conversions that some other bindings perform.

> Well, I can't promise anything, but yes, I'm very interested in this project.

Nice.

Re: SLIB and guile 2

[Andy Wingo]

On Fri 01 Feb 2013 01:01, Mark H Weaver  writes:

> Andrew Bernard  writes:
>> Does SLIB work with guile 2?
>>
>> With guile 2.0.7 and slib 3b3 on Linux there appear to be
>> incompatibilities. Are there releases that work together?
>
> Andy Wingo recently posted a patch to get slib working with Guile 2.0.
> Hopefully a variant of it will be accepted upstream soon.

It's already upstream in slib.  CVS slib and Guile 2.0.x from git work
well together.

Andy
-- 
http://wingolog.org/

Re: Guile OpenGL bindings

[Mark H Weaver]

Javier Sancho  writes:
> Someone mentioned performance issues when using FFI, too.

That was me, and I regret emphasizing that.  In a couple of years, when
Guile has native compilation, it is likely that the FFI will be as fast
as C wrappers, maybe even a bit faster.

Anyway, as Knuth wrote, "We should forget about small efficiencies, say
about 97% of the time: premature optimization is the root of all evil",
and he was absolutely right.  Countless projects have been ruined by
premature optimization.

It's far more important to write the cleanest, simplest code that will
get the job done.  Only after determining the hotspots (by profiling)
should you optimize those bits.

Plus, as Daniel Hartwig  wrote:

> For modern GL programming without glBegin/End, Vertex/Color/Normal,
> etc. the performance impact of FFI should be negligable.  There are
> few GL calls compared to the volume of data that is passed.
>
> The real critical part will be how the user manipulates their vertex
> data, if this is done frequently on the scheme side.  Mapping (typed)
> bytevectors, or srfi-4 to gl arrays will help with that, and avoiding
> the implicit type conversions that some other bindings perform.

   Regards,
 Mark

Re: [ANN] the Guile 100 Programs Project

[Ian Price]

Mike Gran  writes:

> Hello.  I'm pleased to announce the upcoming Guile 100 Programs
> Project.
>  
> The Guile 100 Programs Project is an opportunity to show off your
> Guile skills in exchange for a small honorarium.
>  
> Each week, on Monday, I'll announce a coding project and ask for
> volunteers.  On Wednesday, a volunteer will be chosen at random from
> all entrants.  The volunteer will have two weeks to complete the task.
> If judged to have completed the task correctly, he or she will receive
> a honorarium of 100 USD.
>  
> The task will either be a Scheme script, a bug fix on an existing
> project, or a C code with Guile bindings.

Cool idea. The Guile community is kinda small, and so it'd be nice to
see some of our quieter members incentivised to hack more openly.

> The first two tasks to be announced will likely be
>  
> Mar 11, 2013 - Implement a version of the commands `cat' and
> `echo' in Scheme.
>  
> Mar 18, 2013 - Implement a reduced functionality version of the
> command `ls' in Scheme.

Heh, reimplementing coreutils in Scheme has been a plan of mine for a
while, as part of justifying my Iteratees library, but that has taken a
sideline to newer and shinier projects.

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Guile 2 birthday potluck

[Ian Price]

Andy Wingo  writes:

> So start your emacsen and get cooking!  We've got 5 weeks until 16
> February, ample time for a delicious concoction :)

Just a PSA, you have 2 weeks left people! If, like me, you'd left it
till February since there was plenty of time to spare, then now is the
time to be getting started.

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Guile and MSWindows

[Ludovic Courtès]

Hi,

"objc"  skribis:

> I just built guile-2.0.7.18-03a2f
> Check out http://branch-twigg.webs.com/ for what I done with it.
> currently playing with BioSchematics - L-System Parser and Drawing tool by - 
> Xavier Raynaud 

Interesting.

> FAIL: tests/alist.test: sloppy-assq not
> FAIL: tests/alist.test: sloppy-assv not
> FAIL: tests/alist.test: assv not
> FAIL: tests/alist.test: assq-ref not
> FAIL: tests/alist.test: assv-ref not
> FAIL: tests/common-list.test: delete-if-not!: non-empty list, remove some

These ones are scary.  Can you try to type them at the REPL, to see what
happens?

> $ cat guile.log | grep ERR
> ERROR: tests/bytevectors.test: 2.9 Operations on Strings: string->utf16 - 
> arguments: ((system-error "string->utf16" "failed to convert string: ~A" 
> ("hello, world") (-1)))

Is GNU libiconv installed?  What’s -1 in errno.h?

> ERROR: tests/coverage.test: instrumented/executed-lines: instr = exec - 
> arguments: ((wrong-type-arg "car" "Wrong type argument in position ~A 
> (expecting ~A): ~S" (1 "pair" #f) (#f)
> ))

Can you try to get a backtrace?

That is, at the REPL, you type:

  (use-modules (system vm coverage)
   (system vm vm)
   (system base compile)
   (srfi srfi-11))

  (define-syntax code
(syntax-rules ()
  ((_ filename snippet)
   (let ((input (open-input-string snippet)))
 (set-port-filename! input filename)
 (read-enable 'positions)
 (compile (read input))

  (define %test-vm (make-vm))
  (let ((proc (code "foo.scm" "(lambda (x y)  ;; 0
 (+ x y)) ;; 1")))
(let-values (((data result)
  (with-code-coverage %test-vm
(lambda () (proc 1 2)
  (and (coverage-data? data)
   (= 3 result)
   (let-values (((instr exec)
 (instrumented/executed-lines data "foo.scm")))
 (and (= 2 instr) (= 2 exec))

and report what happens.

> ERROR: tests/foreign.test: make-pointer: equal? modulo finalizer - arguments: 
> ((misc-error "dynamic-pointer" "Symbol not found: ~a" ("scm_is_pair") #f))

Nothing to worry about, I just committed a workaround.

Thanks!

Ludo’.

Re: [ANN] the Guile 100 Programs Project

[Nala Ginrut]

On Fri, 2013-02-01 at 16:40 +, Ian Price wrote:
> Mike Gran  writes:
> 
> > Hello.  I'm pleased to announce the upcoming Guile 100 Programs
> > Project.
> >  
> > The Guile 100 Programs Project is an opportunity to show off your
> > Guile skills in exchange for a small honorarium.
> >  
> > Each week, on Monday, I'll announce a coding project and ask for
> > volunteers.  On Wednesday, a volunteer will be chosen at random from
> > all entrants.  The volunteer will have two weeks to complete the task.
> > If judged to have completed the task correctly, he or she will receive
> > a honorarium of 100 USD.
> >  
> > The task will either be a Scheme script, a bug fix on an existing
> > project, or a C code with Guile bindings.
> 
> Cool idea. The Guile community is kinda small, and so it'd be nice to
> see some of our quieter members incentivised to hack more openly.
> 
> > The first two tasks to be announced will likely be
> >  
> > Mar 11, 2013 - Implement a version of the commands `cat' and
> > `echo' in Scheme.
> >  
> > Mar 18, 2013 - Implement a reduced functionality version of the
> > command `ls' in Scheme.
> 
> Heh, reimplementing coreutils in Scheme has been a plan of mine for a
> while, as part of justifying my Iteratees library, but that has taken a
> sideline to newer and shinier projects.
> 

Maybe another new project, say, rewrite GNU with Guile, include part of
HURD, heh? I even get the name, GoG, GNU on Guile. ;-P

Re: [ANN] the Guile 100 Programs Project

[Mike Gran]

> From: Nala Ginrut 
 
>> Heh, reimplementing coreutils in Scheme has been a plan of mine for a
>> while, as part of justifying my Iteratees library, but that has taken a
>> sideline to newer and shinier projects.
>> 
> 
> Maybe another new project, say, rewrite GNU with Guile, include part of
> HURD, heh? I even get the name, GoG, GNU on Guile. ;-P

LOL.  I'm not trying to reimplement all of Unix.  I just want a newbie
to be able to compare some Scheme code to a concept that she or he
already understands, to facilitate learning.

Let's not get ahead of ourselves anyway.  We still have the birthday
potluck to get through.  And I still have to write a website for this
madness.

-Mike

Re: libguilereadline load

[Ludovic Courtès]

Dmitry Roshchin  skribis:

> On Tuesday 22 January 2013 23:09:51 Ludovic Courtès wrote:
>> Hi,
>> 
>> Dmitry Roshchin  skribis:
>> > Is it normal, that guile tries to load "libguilereadline-v-18.so" instead
>> > of "libguilereadline-v-18.so.18"? Guile  version - 2.0.7.
>> 
>> You normally have both, as well as libguilereadline-v-18.la, no?
>> 
>> Guile uses ltdl for dynamic loading (info "(libtool) Using libltdl").
>> The rule is to first search for .la files.  The .la file tells ltdl that
>> the real library is the .so.18 file, which ltdl then loads.
>> 
>> When the .la file is missing, ltdl tries the .so file instead (not the
>> .so.18 file).
>> 
>
> openSUSE packaging policy requires to remove .la files. And .so file is 
> contained in guile-devel package. So  it doesn't work by default.

I see.  The problem is that Guile has no way of guessing the .18
extension (it’s a platform-specific extension computed by libtool.)

Debian has a similar policy IIRC, but they ship the .so file as part of
the ‘guile-2.0-libs’ package, perhaps as an exception:

  http://packages.debian.org/sid/hurd-i386/guile-2.0-libs/filelist

Perhaps you could suggest that openSUSE do the same?

Ludo’.

Re: libguilereadline load

[Nala Ginrut]

On Fri, 2013-02-01 at 18:30 +0100, Ludovic Courtès wrote:
> Dmitry Roshchin  skribis:
> 
> > On Tuesday 22 January 2013 23:09:51 Ludovic Courtès wrote:
> >> Hi,
> >> 
> >> Dmitry Roshchin  skribis:
> >> > Is it normal, that guile tries to load "libguilereadline-v-18.so" instead
> >> > of "libguilereadline-v-18.so.18"? Guile  version - 2.0.7.
> >> 
> >> You normally have both, as well as libguilereadline-v-18.la, no?
> >> 
> >> Guile uses ltdl for dynamic loading (info "(libtool) Using libltdl").
> >> The rule is to first search for .la files.  The .la file tells ltdl that
> >> the real library is the .so.18 file, which ltdl then loads.
> >> 
> >> When the .la file is missing, ltdl tries the .so file instead (not the
> >> .so.18 file).
> >> 
> >
> > openSUSE packaging policy requires to remove .la files. And .so file is 
> > contained in guile-devel package. So  it doesn't work by default.
> 
> I see.  The problem is that Guile has no way of guessing the .18
> extension (it’s a platform-specific extension computed by libtool.)
> 
> Debian has a similar policy IIRC, but they ship the .so file as part of
> the ‘guile-2.0-libs’ package, perhaps as an exception:
> 
>   http://packages.debian.org/sid/hurd-i386/guile-2.0-libs/filelist
> 

hmm...almost all 'shared lib packaging policy' needs *-dev package
contains the *.so link to a related versioned library. It's not so easy
to persuade them to make an exception if we don't have a solid reason.
Can you tell me how to do a special detect for loading .18? If the
suggestion failed, at least we have a platform specific patch to fix
that.   

> Perhaps you could suggest that openSUSE do the same?
> 
> Ludo’.
> 
> 

Re: Guile 2 birthday potluck

[Nala Ginrut]

On Fri, 2013-02-01 at 16:22 +, Ian Price wrote:
> Andy Wingo  writes:
> 
> > So start your emacsen and get cooking!  We've got 5 weeks until 16
> > February, ample time for a delicious concoction :)
> 
> Just a PSA, you have 2 weeks left people! If, like me, you'd left it
> till February since there was plenty of time to spare, then now is the
> time to be getting started.
> 

oh~yeah~I'll hack all night tonight since you scared me! hahahahah~

Re: Guile OpenGL bindings

[vimml]

Hej,

this all sounds really cool :-)

I hacked a little bit of code to generate C bindings for what is specified in
the glcorearb.h file. I also wrote a small script to extract the gl constants
and define them as scheme variables.
This is all *really* hacky stuff, but if somebody wants to have a lookt at it...

On 21:29 Fri 01 Feb , Daniel Hartwig wrote:
> The real critical part will be how the user manipulates their vertex
> data, if this is done frequently on the scheme side.  Mapping (typed)
> bytevectors, or srfi-4 to gl arrays will help with that, and avoiding
> the implicit type conversions that some other bindings perform.
I did use r6rs bytevectors (bytevector-i-single-native-ref...) to plow
through my data and it was rather sluggish. It's quite possible that I did
someting terribly wrong, but I went back to do the crunching in C...

On 13:16 Fri 01 Feb , Andy Wingo wrote:
>   https://gitorious.org/guile-figl
Looking forward to have a look at your code :-)

Happy Hacking,
Kai :)

Guile 2 deprecated procedure and SLIB

[Andrew Bernard]

Greetings,

In the latest top CVS of SLIB (as of Feb 2013), with Guile 2.0.7, the 
procedure used in the common lisp time section decode-universal-time use 
the deprecated procedure list->uniform-array.


I am new to Scheme, and not sure how to handle this. Not wanting to 
enable the use of deprecated procedures, how does one proceed?


Is there an active SLIB mailing list for discussion?

Andrew

Re: Guile OpenGL bindings

[Daniel Hartwig]

On 2 February 2013 04:56,   wrote:
> I hacked a little bit of code to generate C bindings for what is specified in
> the glcorearb.h file. I also wrote a small script to extract the gl constants
> and define them as scheme variables.
> This is all *really* hacky stuff, but if somebody wants to have a lookt at 
> it...

For reference, the canonical source of that information is in a set of
spec files .

Re: [ANN] the Guile 100 Programs Project

[Hengqing Hu]

Has somebody tried to implement a gnu cloud os in guile?

Or any ideas about doing this?

在 2013-2-2，1:28，Nala Ginrut  写道：

> On Fri, 2013-02-01 at 16:40 +, Ian Price wrote:
>> Mike Gran  writes:
>> 
>>> Hello.  I'm pleased to announce the upcoming Guile 100 Programs
>>> Project.
>>> 
>>> The Guile 100 Programs Project is an opportunity to show off your
>>> Guile skills in exchange for a small honorarium.
>>> 
>>> Each week, on Monday, I'll announce a coding project and ask for
>>> volunteers.  On Wednesday, a volunteer will be chosen at random from
>>> all entrants.  The volunteer will have two weeks to complete the task.
>>> If judged to have completed the task correctly, he or she will receive
>>> a honorarium of 100 USD.
>>> 
>>> The task will either be a Scheme script, a bug fix on an existing
>>> project, or a C code with Guile bindings.
>> 
>> Cool idea. The Guile community is kinda small, and so it'd be nice to
>> see some of our quieter members incentivised to hack more openly.
>> 
>>> The first two tasks to be announced will likely be
>>> 
>>> Mar 11, 2013 - Implement a version of the commands `cat' and
>>> `echo' in Scheme.
>>> 
>>> Mar 18, 2013 - Implement a reduced functionality version of the
>>> command `ls' in Scheme.
>> 
>> Heh, reimplementing coreutils in Scheme has been a plan of mine for a
>> while, as part of justifying my Iteratees library, but that has taken a
>> sideline to newer and shinier projects.
>> 
> 
> Maybe another new project, say, rewrite GNU with Guile, include part of
> HURD, heh? I even get the name, GoG, GNU on Guile. ;-P
> 
> 
> 

GNU Hurd on $scheme (was: [ANN] the Guile 100 Programs Project)

[Daniel Hartwig]

[Hello l4-hurd, I see you have been quiet lately.]

On 2 February 2013 01:28, Nala Ginrut  wrote:
> On Fri, 2013-02-01 at 16:40 +, Ian Price wrote:
>> Heh, reimplementing coreutils in Scheme has been a plan of mine for a
>> while, as part of justifying my Iteratees library, but that has taken a
>> sideline to newer and shinier projects.
>>
>
> Maybe another new project, say, rewrite GNU with Guile, include part of
> HURD, heh? I even get the name, GoG, GNU on Guile. ;-P
>

Something I have thought about for some time.  Next on the TODO list :-)


There is a paper by Rees, _A Security Kernel Based on the
Lambda-Calculus_.  It discusses a Lisp dialect, Scheme¯, similar to
Scheme but with certain operations removed; in there place are some
logical guarantees with implications for security for any code written
in the dialect.  This is used to construct a security kernel, W7,
which becomes the basis for Scheme48 (a language supporting R5RS).

I don't want to get in to the details of the paper, I think that many
on this list will be familiar with it.  Suffice to say that the
security kernel provides concepts that closely map to a capability
model.  Also, verified processes can run within the same machine
process and I wonder if this has implications for the communication
overhead that microkernel systems tend to get labelled with.  In
theory the security kernel, core services, and any Scheme (and other)
language programs should be able to reside in the same process without
having to implement access restrictions beyond those implicit in the
language.

After bootstrapping my current pet project, I intend to explore the
ideas in this paper as they relate to the Hurd.  As I am quite fond of
Guile I plan to proceed roughly as follows:
- port Scheme¯ to the Guile language stack;
- get W7 or something similar running on this;
- implement required Hurd interfaces;
- port some of the current Hurd servers and userland to the Scheme in
this stack;
- …
- profit!

Maybe bypassing the first stages and use Scheme48 instead.

I believe having some sort of system running in Scheme would be very
useful for exploring design and architectural issues, regardless of
whether it is a practical or fast performing implementation.

Anyone interested in collaborating on such a project, or have comments
regarding the paper and the implications for the Hurd?  Nala, you
sound interested, and we will certainly benefit from some of the
userland being ported as part of the Guile 100 Programs Project.

Regards

Re: [ANN] the Guile 100 Programs Project

[Nala Ginrut]

On Sat, 2013-02-02 at 10:16 +0800, Hengqing Hu wrote:
> Has somebody tried to implement a gnu cloud os in guile?
> 

What is 'cloud os'? 

> Or any ideas about doing this?
> 
> 在 2013-2-2，1:28，Nala Ginrut  写道：
> 
> > On Fri, 2013-02-01 at 16:40 +, Ian Price wrote:
> >> Mike Gran  writes:
> >> 
> >>> Hello.  I'm pleased to announce the upcoming Guile 100 Programs
> >>> Project.
> >>> 
> >>> The Guile 100 Programs Project is an opportunity to show off your
> >>> Guile skills in exchange for a small honorarium.
> >>> 
> >>> Each week, on Monday, I'll announce a coding project and ask for
> >>> volunteers.  On Wednesday, a volunteer will be chosen at random from
> >>> all entrants.  The volunteer will have two weeks to complete the task.
> >>> If judged to have completed the task correctly, he or she will receive
> >>> a honorarium of 100 USD.
> >>> 
> >>> The task will either be a Scheme script, a bug fix on an existing
> >>> project, or a C code with Guile bindings.
> >> 
> >> Cool idea. The Guile community is kinda small, and so it'd be nice to
> >> see some of our quieter members incentivised to hack more openly.
> >> 
> >>> The first two tasks to be announced will likely be
> >>> 
> >>> Mar 11, 2013 - Implement a version of the commands `cat' and
> >>> `echo' in Scheme.
> >>> 
> >>> Mar 18, 2013 - Implement a reduced functionality version of the
> >>> command `ls' in Scheme.
> >> 
> >> Heh, reimplementing coreutils in Scheme has been a plan of mine for a
> >> while, as part of justifying my Iteratees library, but that has taken a
> >> sideline to newer and shinier projects.
> >> 
> > 
> > Maybe another new project, say, rewrite GNU with Guile, include part of
> > HURD, heh? I even get the name, GoG, GNU on Guile. ;-P
> > 
> > 
> > 

Re: [ANN] the Guile 100 Programs Project

[Hengqing Hu]

A virtualization enabler, for eamplex: amazon ec2 and s3.

在 2013-2-2，11:14，Nala Ginrut  写道：

> On Sat, 2013-02-02 at 10:16 +0800, Hengqing Hu wrote:
>> Has somebody tried to implement a gnu cloud os in guile?
>> 
> 
> What is 'cloud os'? 
> 
>> Or any ideas about doing this?
>> 
>> 在 2013-2-2，1:28，Nala Ginrut  写道：
>> 
>>> On Fri, 2013-02-01 at 16:40 +, Ian Price wrote:
 Mike Gran  writes:
 
> Hello.  I'm pleased to announce the upcoming Guile 100 Programs
> Project.
> 
> The Guile 100 Programs Project is an opportunity to show off your
> Guile skills in exchange for a small honorarium.
> 
> Each week, on Monday, I'll announce a coding project and ask for
> volunteers.  On Wednesday, a volunteer will be chosen at random from
> all entrants.  The volunteer will have two weeks to complete the task.
> If judged to have completed the task correctly, he or she will receive
> a honorarium of 100 USD.
> 
> The task will either be a Scheme script, a bug fix on an existing
> project, or a C code with Guile bindings.
 
 Cool idea. The Guile community is kinda small, and so it'd be nice to
 see some of our quieter members incentivised to hack more openly.
 
> The first two tasks to be announced will likely be
> 
> Mar 11, 2013 - Implement a version of the commands `cat' and
> `echo' in Scheme.
> 
> Mar 18, 2013 - Implement a reduced functionality version of the
> command `ls' in Scheme.
 
 Heh, reimplementing coreutils in Scheme has been a plan of mine for a
 while, as part of justifying my Iteratees library, but that has taken a
 sideline to newer and shinier projects.
 
>>> 
>>> Maybe another new project, say, rewrite GNU with Guile, include part of
>>> HURD, heh? I even get the name, GoG, GNU on Guile. ;-P
>>> 
>>> 
>>> 
> 
> 

Re: GNU Hurd on $scheme (was: [ANN] the Guile 100 Programs Project)

[Nala Ginrut]

On Sat, 2013-02-02 at 10:49 +0800, Daniel Hartwig wrote:
> [Hello l4-hurd, I see you have been quiet lately.]
> 
> On 2 February 2013 01:28, Nala Ginrut  wrote:
> > On Fri, 2013-02-01 at 16:40 +, Ian Price wrote:
> >> Heh, reimplementing coreutils in Scheme has been a plan of mine for a
> >> while, as part of justifying my Iteratees library, but that has taken a
> >> sideline to newer and shinier projects.
> >>
> >
> > Maybe another new project, say, rewrite GNU with Guile, include part of
> > HURD, heh? I even get the name, GoG, GNU on Guile. ;-P
> >
> 
> Something I have thought about for some time.  Next on the TODO list :-)
> 
> 
> There is a paper by Rees, _A Security Kernel Based on the
> Lambda-Calculus_.  It discusses a Lisp dialect, Scheme¯, similar to
> Scheme but with certain operations removed; in there place are some
> logical guarantees with implications for security for any code written
> in the dialect.  This is used to construct a security kernel, W7,
> which becomes the basis for Scheme48 (a language supporting R5RS).
> 
> I don't want to get in to the details of the paper, I think that many
> on this list will be familiar with it.  Suffice to say that the
> security kernel provides concepts that closely map to a capability
> model.  Also, verified processes can run within the same machine
> process and I wonder if this has implications for the communication
> overhead that microkernel systems tend to get labelled with.  In
> theory the security kernel, core services, and any Scheme (and other)
> language programs should be able to reside in the same process without
> having to implement access restrictions beyond those implicit in the
> language.
> 
> After bootstrapping my current pet project, I intend to explore the
> ideas in this paper as they relate to the Hurd.  As I am quite fond of
> Guile I plan to proceed roughly as follows:
> - port Scheme¯ to the Guile language stack;
> - get W7 or something similar running on this;
> - implement required Hurd interfaces;
> - port some of the current Hurd servers and userland to the Scheme in
> this stack;
> - …
> - profit!
> 
> Maybe bypassing the first stages and use Scheme48 instead.
> 
> I believe having some sort of system running in Scheme would be very
> useful for exploring design and architectural issues, regardless of
> whether it is a practical or fast performing implementation.
> 
> Anyone interested in collaborating on such a project, or have comments
> regarding the paper and the implications for the Hurd?  Nala, you
> sound interested, and we will certainly benefit from some of the
> userland being ported as part of the Guile 100 Programs Project.
> 

Yes, I'm definitely interested on it. Several years ago, I decided to
become an OS hacker and I want to research OS design, but then I became
a language/compiler hacker after I read SICP, I don't know how it is...
Actually, I planed to implement MiG with Guile, but I delayed that since
I need to read many papers about Hurd which is worthy for the hack. 
Now this kind of OS, I can't find a good entrance for it, maybe this GNU
Hurd on $scheme project is a good way to start.
Anyway, count me in! ;-P

> Regards

Re: Guile OpenGL bindings

[Aleix Conchillo Flaqué]

On Fri, Feb 1, 2013 at 4:16 AM, Andy Wingo  wrote:
> Hi Javier,
>
> Have you had time to think about GL bindings for Guile?  I had been
> meaning to do something about it for a long time, and finally got around
> to a first hack last week.  Daniel and I are working in this repo:
>
>   https://gitorious.org/guile-figl
>
[snip]

These are really good news! Thanks Daniel and Andy!

I stopped working on guile-gl a while ago. I moved from FFI to C
bindings after some messages on the mailing list as Javier pointed.
But after this email I will definitely not retake the work. It doesn't
make a lot of sense to duplicate efforts, specially if the people that
take the effort have more experience.

So, great news!

Aleix

Re: Guile and MSWindows

[objc]

Thanks Ludo,

I'm still gathering information, I have downloaded up-to-date versions of 
GNU,
but I just noticed I'm picking up some *CYG*.DLL, I must check they are the 
ones I built, and get the versions.



So far I have:
==
	
loaded	  required ?File 
paths for modulesversion 
versionDescription

EFSADU.DLLIESHIMS.DLL
WER.DLLc:\windows\system32\MPR.DLL 
5.1.2600.5512c:\cygwin\bin\CYGCRYPT-0.DLL 
N/Ac:\cygwin\bin\CYGGCC_S-1.DLL 
N/Ac:\cygwin\bin\CYGGMP-3.DLL 
N/A	4.1c:\cygwin\bin\CYGINTL-8.DLL 
0.18.1.0c:\cygwin\bin\CYGWIN1.DLL 
1007.16.0.0c:\cygwin\usr\local\bin\CYGFFI-5.DLL 
N/Ac:\cygwin\usr\local\bin\CYGGC-1.DLL 
N/A	7.0c:\cygwin\usr\local\bin\CYGGUILE-2.0-22.DLL 
2.0-022		from guile-2.0.7.18-03a2f
c:\cygwin\usr\local\bin\CYGICONV-2.DLL	1.13.1.0c:\cygwin\usr\local\bin\CYGLTDL-7.DLL 
N/A	1.5.6c:\cygwin\usr\local\bin\CYGUNISTRING-0.DLL 
0.9.3.0


regards,

John Goodwin.
--
From: "Ludovic "Courtès"" 
Sent: Friday, February 01, 2013 5:13 PM
To: "objc" 
Cc: 
Subject: Re: Guile and MSWindows


Hi,

"objc"  skribis:


I just built guile-2.0.7.18-03a2f
Check out http://branch-twigg.webs.com/ for what I done with it.
currently playing with BioSchematics - L-System Parser and Drawing tool 
by - Xavier Raynaud 


Interesting.


FAIL: tests/alist.test: sloppy-assq not
FAIL: tests/alist.test: sloppy-assv not
FAIL: tests/alist.test: assv not
FAIL: tests/alist.test: assq-ref not
FAIL: tests/alist.test: assv-ref not
FAIL: tests/common-list.test: delete-if-not!: non-empty list, remove some


These ones are scary.  Can you try to type them at the REPL, to see what
happens?


$ cat guile.log | grep ERR
ERROR: tests/bytevectors.test: 2.9 Operations on Strings: string->utf16 - 
arguments: ((system-error "string->utf16" "failed to convert string: ~A" 
("hello, world") (-1)))


Is GNU libiconv installed?  What’s -1 in errno.h?

ERROR: tests/coverage.test: instrumented/executed-lines: instr = exec - 
arguments: ((wrong-type-arg "car" "Wrong type argument in position ~A 
(expecting ~A): ~S" (1 "pair" #f) (#f)

))


Can you try to get a backtrace?

That is, at the REPL, you type:

 (use-modules (system vm coverage)
  (system vm vm)
  (system base compile)
  (srfi srfi-11))

 (define-syntax code
   (syntax-rules ()
 ((_ filename snippet)
  (let ((input (open-input-string snippet)))
(set-port-filename! input filename)
(read-enable 'positions)
(compile (read input))

 (define %test-vm (make-vm))
 (let ((proc (code "foo.scm" "(lambda (x y)  ;; 0
(+ x y)) ;; 1")))
   (let-values (((data result)
 (with-code-coverage %test-vm
   (lambda () (proc 1 2)
 (and (coverage-data? data)
  (= 3 result)
  (let-values (((instr exec)
(instrumented/executed-lines data "foo.scm")))
(and (= 2 instr) (= 2 exec))

and report what happens.

ERROR: tests/foreign.test: make-pointer: equal? modulo finalizer - 
arguments: ((misc-error "dynamic-pointer" "Symbol not found: ~a" 
("scm_is_pair") #f))


Nothing to worry about, I just committed a workaround.

Thanks!

Ludo’.

srfi-64 status?

[Aleix Conchillo Flaqué]

Hi,

I was looking how to do unit tests in Guile and I found the unit test
module in guile-lib but also a recommendation from Ludovic to use
srfi-64.

http://lists.gnu.org/archive/html/guile-user/2010-12/msg00061.html

Then, I also found some work done last year:

http://lists.gnu.org/archive/html/guile-user/2012-04/msg6.html

What's the status of this?

What's the current best way to perform unit testing in Guile?

Thanks,

Aleix