Re: guile-vm .go files in GUILE_LOAD_PATH

Re: guile-vm .go files in GUILE_LOAD_PATH

[dsmich]

---- Andy Wingo <wingo@pobox.com> wrote: 
> Hi,
> 
> On Thu 18 Sep 2008 00:57, <dsmich@roadrunner.com> writes:
> 
> > Basically, a .go file will be preferred over a .scm file even if the
> > .scm file is earlier in the load-path. I think that the file earlier
> > in the load-path should win.
> 
> A few thoughts:
> 
>  (1) Guile shouldn't have installed paths (its system paths) in its path
>      when running uninstalled, otherwise you can get strange issues like
>      you saw -- it's not limited to .go files, it could be .scm as well

True.

>  (2) I can imagine cases in which you would want compiled files not in
>      the same location as source; e.g. /usr/lib64/guile/ vs
>      /usr/share/guile/; although currently .go files are not
>      platform-dependent (I don't think)

Hmm.  Also true.

>  (4) We already check to make sure that the .go file is newer than the
>      .scm file

Good.

> I would suggest that the current way is sufficient, if we disable
> loading from the installed paths when running pre-inst-guile; because I
> kinda want to allow (2), but I don't want to deal with ordering issues
> within %load-path of "compiled locations" versus "source locations".

I'm pretty sure the case of not using the already installed system .scm files while building is handled now.  I'm thinking more along the lines of some user wanted to override a system file for some reason. This issue came up for me when I wanted to use a newer gnus than what came with the system supplied emacs.  At that time I didn't have admin privs so I just installed gnus somewhere under my home dir and made sure that the emacs load path searched there first.  Can this situation ever come up in Guile?  Maybe.

As Neil mentioned, emacs is a good example to follow.  That's why I'm suggesting this.

> Sorry about your bug, I know it was a bit painful. But you would not
> have had it if guile were operating correctly in the first place,
> regardless of the .go vs .scm issue.

No problem there.  Finding (and fixing) bugs is what makes using developing code fun. ;^)

Thanks,
   -Dale

Re: guile-vm .go files in GUILE_LOAD_PATH

[Andy Wingo]

Heya Dale,

On Thu 18 Sep 2008 22:49, <dsmich@roadrunner.com> writes:

> I'm pretty sure the case of not using the already installed system .scm
> files while building is handled now.

It is, but only because the uninstalled dirs are before the installed
dirs.

I committed a patch to the vm branch to remove the installed dirs from
guile's load path when running as pre-inst-guile:

    http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=02b84691b274155f4528f99e90fbe39c77ed546d

NB, relative to master, that patch depends on this one:

    http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=be52b55a3213c8f683d1007a542771daa3f9a06b

> I'm thinking more along the lines
> of some user wanted to override a system file for some reason. This
> issue came up for me when I wanted to use a newer gnus than what came
> with the system supplied emacs. At that time I didn't have admin privs
> so I just installed gnus somewhere under my home dir and made sure that
> the emacs load path searched there first. Can this situation ever come
> up in Guile? Maybe.

Sure it can. Hopefully you could get through it via the newer-than
check... but I do see your point.

> As Neil mentioned, emacs is a good example to follow. That's why I'm
> suggesting this.

I did look at its docs for quite some time before implementing it the
way that I did. That said, your solution may be the better one in the
long term. Does anyone else have an opinion?

Cheers,

Andy
-- 
http://wingolog.org/

Re: guile-vm .go files in GUILE_LOAD_PATH

[Ludovic Courtès]

Hi,

<dsmich@roadrunner.com> writes:

> I'm pretty sure the case of not using the already installed system
> .scm files while building is handled now.  I'm thinking more along the
> lines of some user wanted to override a system file for some
> reason. This issue came up for me when I wanted to use a newer gnus
> than what came with the system supplied emacs.  At that time I didn't
> have admin privs so I just installed gnus somewhere under my home dir
> and made sure that the emacs load path searched there first.  Can this
> situation ever come up in Guile?  Maybe.

That can be handled by setting $GUILE_LOAD_PATH appropriately; even
`boot-9.scm' can be overridden this way (which `-L' and `%load-path' do
not allow).

Thanks,
Ludo'.

guile-vm .go files in GUILE_LOAD_PATH

[dsmich]

I've been tracking the guile-vm branch lately and had a recent problem.  After much head scratching we finally figured out that a previously installed .go file was being used during the buld.

We (Andy and I on irc) hacked around it by creating a new environment variable that pre-inst-guile-env can use to override or disable things that libguile adds to the load-path.  However, I think there is still a problem.

Basically, a .go file will be preferred over a .scm file even if the .scm file is earlier in the load-path.  I think that the file earlier in the load-path should win.

Thoughts?

-Dale

Re: guile-vm .go files in GUILE_LOAD_PATH

[David Séverin]

Le Wed, 17 Sep 2008 18:57:19 -0400,
<dsmich@roadrunner.com> a écrit :

> I've been tracking the guile-vm branch lately and had a recent problem.
> After much head scratching we finally figured out that a previously
> installed .go file was being used during the buld.
> 
> We (Andy and I on irc) hacked around it by creating a new environment
> variable that pre-inst-guile-env can use to override or disable things that
> libguile adds to the load-path.  However, I think there is still a problem.
> 
> Basically, a .go file will be preferred over a .scm file even if the .scm
> file is earlier in the load-path.  I think that the file earlier in the
> load-path should win.
> 
> Thoughts?
> -Dale

Should it not be a user responsibility? I mean:

I would place my .go files next to my .scm files and expect the
loading process to warn me if the .scm file was newer, but still would
load all .go files when available.

David

Re: guile-vm .go files in GUILE_LOAD_PATH

[Neil Jerram]

2008/9/18  <dsmich@roadrunner.com>:
> Basically, a .go file will be preferred over a .scm file even if the .scm file is earlier in the load-path.  I think that the file earlier in the load-path should win.
>
> Thoughts?

I agree.  I think that's what Emacs does, and Emacs is a good example
to follow.  It may also be worth checking out what Python does.


    Neil

Re: guile-vm .go files in GUILE_LOAD_PATH

[Andy Wingo]

Hi,

On Thu 18 Sep 2008 00:57, <dsmich@roadrunner.com> writes:

> Basically, a .go file will be preferred over a .scm file even if the
> .scm file is earlier in the load-path. I think that the file earlier
> in the load-path should win.

A few thoughts:

 (1) Guile shouldn't have installed paths (its system paths) in its path
     when running uninstalled, otherwise you can get strange issues like
     you saw -- it's not limited to .go files, it could be .scm as well

 (2) I can imagine cases in which you would want compiled files not in
     the same location as source; e.g. /usr/lib64/guile/ vs
     /usr/share/guile/; although currently .go files are not
     platform-dependent (I don't think)

 (3) Currently there is no linkage between the absolute directory of the
     .scm file and the .go file, neither in the compilation nor in the
     loading; but there is a linking with the relative path if you use
     primitive-load-path

 (4) We already check to make sure that the .go file is newer than the
     .scm file

I would suggest that the current way is sufficient, if we disable
loading from the installed paths when running pre-inst-guile; because I
kinda want to allow (2), but I don't want to deal with ordering issues
within %load-path of "compiled locations" versus "source locations".

Sorry about your bug, I know it was a bit painful. But you would not
have had it if guile were operating correctly in the first place,
regardless of the .go vs .scm issue.

We certainly need to have a better story regarding versioning, so we
don't load incompatible .go files.

Andy
-- 
http://wingolog.org/