Resigning from Guile maintainership

2010-04-05 Thread Neil Jerram
Hi Everyone!

I feel the time has come for me to step down from the Guile
maintainership.  Andy and Ludo are doing an amazing job as the other
maintainers, and I have no doubt that Guile's future is bright:
technically fascinating, and showing new signs of become ubiquitous
within the GNU project, as was its original intention.

For me personally, the reality is that I've always been more a steady
pair of hands for Guile than a creative powerhouse, and I'd now like to
spend more of my time on many other things that are calling for it - and
without a slight feeling of guilt that I should be keeping that time for
Guile.

I still plan to hang around, as one of Guile's many users and occasional
contributors.  In particular I hope to continue making contributions
towards getting the manual ready for publication sometime this year.
But generally I look forward to sitting back and enjoying the ride!

If there are specific things that people believe to be on my list as a
maintainer, and so were/are expecting me to get to at some point, please
email me (either privately or publicly, as appropriate) so we can decide
what to do about those.

Best wishes to all, and here's looking forward to Guile 2.0!

 Neil




Re: Resigning from Guile maintainership

2010-04-05 Thread Ludovic Courtès
Hi Neil,

Well, I understand your decision.  Thanks again for all the work you’ve
been doing fixing bug, improving the manual, benchmarking, reviewing
patches, and generally improving Guile and making it a nice project to
contribute to!  Your input is always appreciated.

Hope we’ll all keep enjoying the ride towards 2.0!  :-)

Thanks,
Ludo’.


pgp6arWURVXA4.pgp
Description: PGP signature


Re: Resigning from Guile maintainership

2010-04-05 Thread Andy Wingo
On Mon 05 Apr 2010 15:40, l...@gnu.org (Ludovic Courtès) writes:

 Thanks again for all the work you’ve been doing fixing bug, improving
 the manual, benchmarking, reviewing patches, and generally improving
 Guile and making it a nice project to contribute to! Your input is
 always appreciated.

 Hope we’ll all keep enjoying the ride towards 2.0!  :-)

All the same sentiments from me. Thank you very much, and as they say,
so long, but not farewell :-)

Cheers,

Andy
-- 
http://wingolog.org/




Re: optionals in C procedures

2010-04-05 Thread Andy Wingo
Hi,

On Sun 04 Apr 2010 17:15, Zeeshan Ali (Khattak) zee...@gmail.com writes:

 code
 static SCM
 scm_g_irepository_require (SCM scm_repository,
  SCM scm_namespace,
  SCM scm_version,
  SCM scm_flags)
 {
 const char *version;

 if (SCM_UNBNDP (scm_version))
 version = NULL;
 else
 version = scm_to_locale_string (scm_version);
 ...
 }

 scm_c_define_gsubr (g-irepository-require, 2, 2, 0,
 scm_g_irepository_require);


 /code

Whats happening is that my scheme code is not passing any value to
 the optional argument version and guile is not making sure that the
 argument is unbound. Is this a regression or some intentional change?

I think you might need to make clean  make, in Guile and in your
project. (The actual value for SCM_UNDEFINED changed, and I have seen
cases in which automake doesn't get the deps right. This sort of thing
won't happen after 2.0.)

Andy
-- 
http://wingolog.org/




locale-dependent number parsing?

2010-04-05 Thread Linas Vepstas
I've found the following bug/feature with guile-1.8.7 and would like to
solicit for comments.
Is this a guile bug? What's the proper work-around?

I've got a C program that does a setlocale (LC_ALL, );   printf (%f,
0.2000);

In the de_DE.utf8 locale, the result of the print is 0,2000  using a comma,
since
the comma is the decimal separator in most European locales. This numeric
string is then passed to scm_eval_string() which pukes on it, because it
does not
recognize 0,2  as a valid number.This can be confirmed at the guile
command
line interpreter, which pukes on guile (+ 0,2 0,2)  but works fine on (+
0.2 0.2)
even in the de_DE locale.

Is this really the expected behaviour? Is there a suggested work-around?

--linas


Re: Resigning from Guile maintainership

2010-04-05 Thread Mike Gran
Many thanks, Neil.  Good luck.

-Mike




Re: locale-dependent number parsing?

2010-04-05 Thread Linas Vepstas
On 5 April 2010 12:19, Mike Gran spk...@yahoo.com wrote:

 From: Linas Vepstas linasveps...@gmail.com
 
 I've found the following bug/feature with guile-1.8.7 and would like to
 solicit for comments.
 Is this a guile bug? What's the proper work-around?
 
 I've got a C program that does a setlocale (LC_ALL, );   printf (%f,
 0.2000);
 
 In the de_DE.utf8 locale, the result of the print is 0,2000  using a
 comma, since
 the comma is the decimal separator in most European locales. This
 numeric
 string is then passed to scm_eval_string() which pukes on it, because it
 does not
 recognize 0,2  as a valid number.This can be confirmed at the guile
 command
 line interpreter, which pukes on guile (+ 0,2 0,2)  but works fine on (+
 0.2 0.2)
 even in the de_DE locale.
 
 Is this really the expected behaviour? Is there a suggested work-around?

 I know that for the pre-2.0 Guile, I tried to punt that problem upstream to
 libunistring, but, it is not likely to be implemented in libunistring.

 http://savannah.gnu.org/support/?106998

 But, I never got around to working on it, myself.


Yeah, maybe I should say never mind at this point, since I now realize
that
my suggestion would make scheme source code  depend on locale, which
would break source code as it moves across national boundaries... Silly me.
Moral of the story: mixing printf with guile is a bad idea.

--linas


possible soc project: accessing git datastores from guile

2010-04-05 Thread Andy Wingo
Hi,

Crossposting from
http://wingolog.org/archives/2010/04/05/code-not-burgers:

I know your problem: you are a student, and the Google Summer of Code
has started, but you haven't found a project worth doing. Or, perhaps
you have submitted a proposal already, but you're not psyched about it.
You really wanted to munge bytes on disk using Scheme. I totally dig it.

That is why you should make a proposal to make a library for accessing
Git datastores from Guile. Great idea, right? You probably had it too!

The scope of the work would be to write the equivalent of Git's
plumbing layer in Scheme. The first step would be to be able to git
cat-file any object in the database. Then you would need to be able to
insert into the database, via git-hash-object, and then to be able to
update a ref with git-update-ref.

At the same time, all of this functionality should be available on the
command line, via something like a gilt executable: gilt cat-file foo,
for example.

The reason why this work is interesting is N-fold:

* Having a Git library will be nice. Indeed a number of software
  projects use Git as a database.

* Having a Git implementation that can be linked to Guile will be
  good too. (Guile is LGPLv3+, Git is GPLv2 only.)

* It will be interesting to see how fast a Scheme-only solution will
  be. Raw SHA1 calculation will probably still have to be done in C
  though.

* Finally it's going to be total fun! It's a good scope for an SOC
  project: you can implement as far as you get, and you learn skills
  like how to do real-world development in Scheme, producing fast
  code.

Interested? Time is running out. 9 April appears to be the deadline.
Requirements are a proficiency with Git, and you should implement a
command-line Guile program that returns the MD5 or SHA-1 hash of the
file given as its argument. It's OK to copy the MD5 or SHA-1
implementation from elsewhere, but document that; I just want to know if
you can actually wire up the pieces correctly, and beyond that, is your
Scheme in good taste.

So, should this thing be up your alley, reply to this mail, or visit
#guile during the European daytime, and let's talk!

Andy
-- 
http://wingolog.org/




Re: locale-dependent number parsing?

2010-04-05 Thread Ludovic Courtès
Hi Linas,

In 1.9 there’s ‘locale-string-inexact’, which may be what you’re
looking for; see
http://www.gnu.org/software/guile/docs/master/guile.html/Number-Input-and-Output.html.

Thanks,
Ludo’.