Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names.

[Andy Wingo]

On Sun 01 May 2011 23:48, Mark H Weaver  writes:

> on some systems (e.g. Windows NT) filenames are considered character
> data, or at least so says PEP 383
> 

Ah, interesting, I was blissfully ignorant; not the desired state when
one is hacking file-name encoding :)

Still, though, I think the basic point stands: copy what Racket does,
because they actually do run well on windows and are happy with their
abstraction.  It's the sincerest form of flattery :)

> Ideally, we should try to come up with a coherent story and set of
> APIs for dealing with all of these data that are string-like, but
> actually bytevectors on some systems.

Environment variables and command-line arguments being the other ones
that you mentioned; and yes, some common conventions here would be good.
I still think, though, that path objects need their own data type.

Peace,

Andy
-- 
http://wingolog.org/

Re: Guile virtual machine targets

[Marijn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ewan,

On 04/20/11 12:57, Ewan Higgs wrote:
> With regards to libJit, I tried to download it and go through the tutorial 
> code, 
> but it appears to have been deserted. The link to download the source[2] is 
> dead 
> though there is a package on the gnu ftp for version 0.1.0[3].

I checked my distribution packages and since they included version 0.1.2
I decided to investigate a bit further. This version was released in
2008 and you can it from
http://download.savannah.gnu.org/releases/dotgnu-pnet/libjit-releases/

Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2+h+QACgkQp/VmCx0OL2zOJgCfV89GR3/3gDCQnPUddlqU8SoB
cSEAn17uHDfWK7/FjHgamm6yMTI3VCg0
=JCwP
-END PGP SIGNATURE-

[Q] unparse-uri is has been canceled?

[B.Tag]

hi all.

   (web uri) unparse-uri  is has been canceled of guile 2.0.1?



-- 
http://www.boolsir.com

Re: [Q] unparse-uri is has been canceled?

[Andy Wingo]

On Mon 02 May 2011 16:29, "B.Tag"  writes:

>    (web uri) unparse-uri  is has been canceled of guile 2.0.1?

Before 2.0.0 it was changed to uri->string.  2.0.1 does not change that,
AFAIK anyway.

Happy hacking,

Andy
-- 
http://wingolog.org/

Re: Queries about while doc and (ice-9 command-line)

[Neil Jerram]

Andy Wingo  writes:

>> Does this code mean that we load the script twice, in the -ds case?
>
> I think so, yes; unfortunately.  Fixed.  Would this merit a quick 2.0.2,
> you think?

I guess that would be better, if Ludo has time to make the release.

>> Do we go interactive after seeing a -e option?  I don't see a setting of
>> the interactive? variable that would prevent this?
>
> This appears to be the old behavior.  Am I mistaken?

No, sorry, I was.  This is fine then.

Regards,
Neil

g-wrap - fresh git clone - can't find libguile.h:

[David Pirotte]

Hello,

After having just installed a guile fresh git clone, g-wrap [fresh git clone
too] won't make.

Any idea?
Cheers,
David

;; --

uname -r:   2.6.38-2-amd64
guile:  guile (GNU Guile) 2.0.1.17-f3c6

'Related' variables defined:

LD_LIBRARY_PATH=/usr/local/lib

%load-path
$1 = ("/usr/local/share/guile/2.0" "/usr/local/share/guile/site/2.0"
"/usr/local/share/guile/site" "/usr/local/share/guile")

[getting a fresh git clone of g-wrap]
./autogen.sh --prefix=/usr/local
make
... ...
make[4]: Entering directory `/usr/local/src/g-wrap/git-clone/guile/g-wrap'
/bin/bash ../../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../..
-I../../g-wrap  -I../.. -I../../lib -I../../guile-g -O2 -Wall
-Wmissing-prototypes -Werror -std=gnu99 -MT guile-runtime.lo -MD -MP
-MF .deps/guile-runtime.Tpo -c -o guile-runtime.lo guile-runtime.c libtool:
compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../g-wrap -I../.. -I../../lib
-I../../guile -g -O2 -Wall -Wmissing-prototypes -Werror -std=gnu99 -MT
guile-runtime.lo -MD -MP -MF .deps/guile-runtime.Tpo -c guile-runtime.c  -fPIC 
-DPIC
-o .libs/guile-runtime.o In file included from
guile-runtime.c:32:0: ../../guile/g-wrap/guile-compatibility.h:25:22: fatal 
error:
libguile.h: No such file or directory compilation terminated. make[4]: ***
[guile-runtime.lo] Error 1 make[4]: Leaving directory
`/usr/local/src/g-wrap/git-clone/guile/g-wrap' make[3]: *** [all-recursive] 
Error 1
make[3]: Leaving directory `/usr/local/src/g-wrap/git-clone/guile/g-wrap' 
make[2]:
*** [all-recursive] Error 1 make[2]: Leaving directory
`/usr/local/src/g-wrap/git-clone/guile' make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/g-wrap/git-clone' make: *** [all] 
Error 2
david@idefix:/usr/local/src/g-wrap/git-clone 10 $ 

guile-gnome gives a strange 'guile not found' message

[David Pirotte]

Hello,

After having just installed a guile git clone and a fresh guile-gnome-platform
git clone too, [even though I still haven't g-wrap installed] I tried 
./autogen.sh
and got this:

./autogen.sh --prefix=/usr/local
... ...
checking for Guile... configure: error: Guile 1.8.0 or newer is 
required,
but you only have .  configure failed

Cheers,
David

;; --

uname -r:   2.6.38-2-amd64
which guile:/usr/local/bin/guile
version:guile (GNU Guile) 2.0.1.17-f3c6

'Related' variables defined:

LD_LIBRARY_PATH=/usr/local/lib

%load-path
$1 = ("/usr/local/share/guile/2.0" "/usr/local/share/guile/site/2.0"
"/usr/local/share/guile/site" "/usr/local/share/guile")

Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names.

[Ludovic Courtès]

Hi,

Andy Wingo  writes:

> Basically I think the plan should be to add scm_from_locale_path,
> scm_from_raw_path, etc to filesys.[ch], and change any
> pathname-accepting procedure in Guile to accept path objects, producing
> them from strings when given strings, and pass the bytevector
> representation to the raw o/s procedures like `open' et al.

Seems to like a disjoint type “just for Windows” would be overkill, no?

MIT/GNU Scheme has something this overkill [0].

Bigloo has just one variable, ‘file-separator’, which is either #\/ or
#\\ [1].  Vicinities in SLIB/SCM are similar, with ‘vicinity:suffix?’
abstracting over slash vs. backslash [2].  I’m not sure how they handle
MS-DOS volume names.

Thanks,
Ludo’.

[0] 
http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Pathnames.html
[1] 
http://www-sop.inria.fr/mimosa/fp/Bigloo/doc/bigloo-7.html#System-Programming
[2] http://people.csail.mit.edu/jaffer/slib_2.html

Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names.

[Andy Wingo]

On Mon 02 May 2011 22:58, l...@gnu.org (Ludovic Courtès) writes:

> Andy Wingo  writes:
>
>> Basically I think the plan should be to add scm_from_locale_path,
>> scm_from_raw_path, etc to filesys.[ch], and change any
>> pathname-accepting procedure in Guile to accept path objects, producing
>> them from strings when given strings, and pass the bytevector
>> representation to the raw o/s procedures like `open' et al.
>
> Seems to like a disjoint type “just for Windows” would be overkill, no?

Maybe you're right; hummm!  I have added a kind racketeer on Cc; perhaps
if he has time, he might have some thoughts in this regard.  :-)

> Bigloo has just one variable, ‘file-separator’, which is either #\/ or
> #\\ [1].

The funny thing is that this doesn't matter at all.  Well, I mean that
it's valid to construct pathnames with / as the separator on Windows, as
/ and \ are equivalent there.

I still think that we need at least the ability to pass a bytevector as
a path name, on GNU systems; and that if we can do so, then any routine
that needs to deal with a path name would then need to deal in byte
vectors in addition to strings, and at that point perhaps it is indeed
useful to have a path library.

> Vicinities in SLIB/SCM are similar, with ‘vicinity:suffix?’
> abstracting over slash vs. backslash [2].  I’m not sure how they handle
> MS-DOS volume names.

I don't think that they do handle volume names; at least, from what I
could see in the API description there.

Good questions!

A
-- 
http://wingolog.org/

Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names.

[Ludovic Courtès]

Hello!

Andy Wingo  writes:

> On Mon 02 May 2011 22:58, l...@gnu.org (Ludovic Courtès) writes:

[...]

> The funny thing is that this doesn't matter at all.  Well, I mean that
> it's valid to construct pathnames with / as the separator on Windows, as
> / and \ are equivalent there.

Oh, good.

> I still think that we need at least the ability to pass a bytevector as
> a path name, on GNU systems; and that if we can do so, then any routine
> that needs to deal with a path name would then need to deal in byte
> vectors in addition to strings, and at that point perhaps it is indeed
> useful to have a path library.

To accommodate various file name encodings, right?  Then yes.

I think GLib and the like expect UTF-8 as the file name encoding and
complain otherwise, so UTF-8 might be a better default than locale
encoding (and it’s certainly wiser to be locale-independent.)

>> Vicinities in SLIB/SCM are similar, with ‘vicinity:suffix?’
>> abstracting over slash vs. backslash [2].  I’m not sure how they handle
>> MS-DOS volume names.
>
> I don't think that they do handle volume names; at least, from what I
> could see in the API description there.

So volumes matter in the file name canonicalization of the .go cache
right?

Couldn’t we mimic /cygdrive/c, etc.?

Thanks,
Ludo’.

Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names.

[Eli Barzilay]

[Second attempt, my Emacs has unfortunate issues with Ludovic's
name...]


An hour ago, Andy Wingo wrote:
> On Mon 02 May 2011 22:58, l...@gnu.org (Ludovic Courtès) writes:
> 
> > Andy Wingo  writes:
> >
> >> Basically I think the plan should be to add scm_from_locale_path,
> >> scm_from_raw_path, etc to filesys.[ch], and change any
> >> pathname-accepting procedure in Guile to accept path objects,
> >> producing them from strings when given strings, and pass the
> >> bytevector representation to the raw o/s procedures like `open'
> >> et al.
> >
> > Seems to like a disjoint type “just for Windows” would be
> > overkill, no?
> 
> Maybe you're right; hummm!  I have added a kind racketeer on Cc; perhaps
> if he has time, he might have some thoughts in this regard.  :-)

I don't think that I can contribute much -- I'm mostly looking at
these things from a user's point of view...  Roughly speaking (mostly
because I don't know what the issues that you're up against), our path
values have "just paths" for whatever the OS wants -- so on Windows
they might have either backslashes or slashes (since Racket accepts
both).

To write portable code we don't have a `file-separator' thing,
instead, we have `build-path' that combines two paths with the right
separator.  Similarly, we have `split-path' to split up a path to the
directory part and the last part.  I think that it's generally better
this way, since it represents the higher level operation rather than
fiddling with the semantics of where and how to put separators
directly (but this is not some religious issue, just seems to me like
it would be more convenient).

Also, we have cases where we want something that looks like a portable
path (for example, naming relative file names in `require') -- for
those we use /-separated strings that are limited to "safe"
characters.  And related, in cases where we want to encode path in
code (for example, some macro that wants to generate a path), we'll
use strings or byte strings, with the latter more common for lower
level things.

(But I'm just rambling now, I haven't slept in N days -- so feel free
to ignore me...)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!