What's up with 'current-load-port'

What's up with 'current-load-port'

[Thomas Morley]

Hi,

what's up with 'current-load-port'?

Simply checking in a guile-prompt I get:
guile-1.8: #<primitive-procedure current-load-port>
guile-2.0.14: #<procedure current-load-port ()>
guile-2.2.4 and guile-2.9.1:
;;; <unknown-location>: warning: possibly unbound variable `current-load-port'
ERROR: In procedure module-lookup: Unbound variable: current-load-port

It's in the manual, though, without any hint it could be deprecated or
disabled or the need to use a certain module.

What am I missing?


Cheers,
  Harm

Re: What's up with 'current-load-port'

[Alex Vong]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

Hello,

Thomas Morley <thomasmorley65@gmail.com> writes:

> Hi,
>
> what's up with 'current-load-port'?
>
> Simply checking in a guile-prompt I get:
> guile-1.8: #<primitive-procedure current-load-port>
> guile-2.0.14: #<procedure current-load-port ()>
> guile-2.2.4 and guile-2.9.1:
> ;;; <unknown-location>: warning: possibly unbound variable `current-load-port'
> ERROR: In procedure module-lookup: Unbound variable: current-load-port
>
> It's in the manual, though, without any hint it could be deprecated or
> disabled or the need to use a certain module.
>
> What am I missing?
>
Indeed, looking at the (ice-9 ports) module. It seems the
'current-load-port' procedure is not exported for some reason
(forgotten?). A workaround would be to resolve it directly:

  (@@ (ice-9 ports) current-load-port)

>
> Cheers,
>   Harm

Cheers,
Alex

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: What's up with 'current-load-port'

[Thomas Morley]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

Am So., 4. Nov. 2018 um 13:50 Uhr schrieb Alex Vong <alexvong1995@gmail.com>:
>
> Hello,
>
> Thomas Morley <thomasmorley65@gmail.com> writes:
>
> > Hi,
> >
> > what's up with 'current-load-port'?
> >
> > Simply checking in a guile-prompt I get:
> > guile-1.8: #<primitive-procedure current-load-port>
> > guile-2.0.14: #<procedure current-load-port ()>
> > guile-2.2.4 and guile-2.9.1:
> > ;;; <unknown-location>: warning: possibly unbound variable `current-load-port'
> > ERROR: In procedure module-lookup: Unbound variable: current-load-port
> >
> > It's in the manual, though, without any hint it could be deprecated or
> > disabled or the need to use a certain module.
> >
> > What am I missing?
> >
> Indeed, looking at the (ice-9 ports) module. It seems the
> 'current-load-port' procedure is not exported for some reason
> (forgotten?). A workaround would be to resolve it directly:
>
>   (@@ (ice-9 ports) current-load-port)
>
> >
> > Cheers,
> >   Harm
>
> Cheers,
> Alex

Hi Alex,

thanks for the hint.
Would a patch like attached be sufficient?

Best,
  Harm

[-- Attachment #2: 0001-Export-current-load-port-from-ice-9.patch --]
[-- Type: text/x-patch, Size: 752 bytes --]

From 6f85349c6a1353023b06c64985bc59397d9b8bc4 Mon Sep 17 00:00:00 2001
From: Thomas Morley <thomasmorley65@gmail.com>
Date: Sun, 4 Nov 2018 14:10:38 +0100
Subject: [PATCH] Export current-load-port from ice-9

---
 module/ice-9/ports.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/module/ice-9/ports.scm b/module/ice-9/ports.scm
index 8eee22988..061ae1c27 100644
--- a/module/ice-9/ports.scm
+++ b/module/ice-9/ports.scm
@@ -30,6 +30,7 @@
             %port-property
             %set-port-property!
             current-input-port current-output-port
+            current-load-port
             current-error-port current-warning-port
             set-current-input-port set-current-output-port
             set-current-error-port
-- 
2.17.1

Re: What's up with 'current-load-port'

[Alex Vong]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

Thomas Morley <thomasmorley65@gmail.com> writes:

[...]
>
> Hi Alex,
>
> thanks for the hint.
> Would a patch like attached be sufficient?
>
I am not sure. Looking into the source, in the
"Current ports as parameters" section, you can see that
'current-*-port' are being defined. They feel like some kind of wrappers
around the primitive versions defined in libguile. I don't know what are
their uses and whether we should have something similar for
'current-load-port'.

> Best,
>   Harm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: What's up with 'current-load-port'

[Mark H Weaver]

Thomas Morley <thomasmorley65@gmail.com> writes:

> what's up with 'current-load-port'?
>
> Simply checking in a guile-prompt I get:
> guile-1.8: #<primitive-procedure current-load-port>
> guile-2.0.14: #<procedure current-load-port ()>
> guile-2.2.4 and guile-2.9.1:
> ;;; <unknown-location>: warning: possibly unbound variable `current-load-port'
> ERROR: In procedure module-lookup: Unbound variable: current-load-port
>
> It's in the manual, though, without any hint it could be deprecated or
> disabled or the need to use a certain module.

Good catch.  I agree that this was mishandled.

Out of curiosity, what do you use 'current-load-port' for?

Although it's in the manual, the description doesn't really describe
what the procedure returns, or when one can rely upon it being set.  It
only says that it's "used internally by 'primitive-load'".

      Mark

Re: What's up with 'current-load-port'

[Thomas Morley]

Am Mo., 5. Nov. 2018 um 02:43 Uhr schrieb Mark H Weaver <mhw@netris.org>:
>
> Thomas Morley <thomasmorley65@gmail.com> writes:
>
> > what's up with 'current-load-port'?
> >
> > Simply checking in a guile-prompt I get:
> > guile-1.8: #<primitive-procedure current-load-port>
> > guile-2.0.14: #<procedure current-load-port ()>
> > guile-2.2.4 and guile-2.9.1:
> > ;;; <unknown-location>: warning: possibly unbound variable `current-load-port'
> > ERROR: In procedure module-lookup: Unbound variable: current-load-port
> >
> > It's in the manual, though, without any hint it could be deprecated or
> > disabled or the need to use a certain module.
>
> Good catch.  I agree that this was mishandled.
>
> Out of curiosity, what do you use 'current-load-port' for?
>
> Although it's in the manual, the description doesn't really describe
> what the procedure returns, or when one can rely upon it being set.  It
> only says that it's "used internally by 'primitive-load'".
>
>       Mark

Some background:
You probably remember I'm from LilyPond. Currently we still use
guilev-1.8, though have experimental support for guilev2.
I do a lot of support on our user-list, frequently checking things
with my lilypond-guilev2-setup to detect bugs.

Recently a user wrote a large scm-file and put it into lilypond using
'(load file.scm)'.
No problem with guilev1, but with guilev2 'file.scm' is not found.
Thus I tried to track the problem down.
Not a bad start is to rtfm :)
So I found 'current-load-port' and intended to play around with it
whether I can get some useful info out of it.

In short, I likely don't need 'current-load-port' for anything, but
couldn't be sure before I used it. Thus this thread and patch.

While doing rtfm I found 'primitive-load' working for the above
described purpose in guilev1 and guilev2. So the problem is solvable.

Although this doesn't explain why 'load' stopped working for lilypond.
I then started from our master (guilev1) and changed only two things:
- teaching configure to accept guile-2.9.1
- disabling a certain not longer supported function (only needed for
collecting some statistic data and never used afair)
Omitting all other guilev2-patches will ofcourse result in a very
buggy lilypond, if someone would intend to use it, but enough to check
whether 'load' works.
It does not.
So the underlying problem is either already in lilypond-master or
guilev2 changed something in 'load'.

That's my current research-state.

Any hint from the guile side?


Thanks,
  Harm

Re: What's up with 'current-load-port'

[Thomas Morley]

Am Mo., 5. Nov. 2018 um 09:25 Uhr schrieb Thomas Morley
<thomasmorley65@gmail.com>:
>
> Am Mo., 5. Nov. 2018 um 02:43 Uhr schrieb Mark H Weaver <mhw@netris.org>:
> >
> > Thomas Morley <thomasmorley65@gmail.com> writes:
> >
> > > what's up with 'current-load-port'?
> > >
> > > Simply checking in a guile-prompt I get:
> > > guile-1.8: #<primitive-procedure current-load-port>
> > > guile-2.0.14: #<procedure current-load-port ()>
> > > guile-2.2.4 and guile-2.9.1:
> > > ;;; <unknown-location>: warning: possibly unbound variable `current-load-port'
> > > ERROR: In procedure module-lookup: Unbound variable: current-load-port
> > >
> > > It's in the manual, though, without any hint it could be deprecated or
> > > disabled or the need to use a certain module.
> >
> > Good catch.  I agree that this was mishandled.
> >
> > Out of curiosity, what do you use 'current-load-port' for?
> >
> > Although it's in the manual, the description doesn't really describe
> > what the procedure returns, or when one can rely upon it being set.  It
> > only says that it's "used internally by 'primitive-load'".
> >
> >       Mark
>
> Some background:
> You probably remember I'm from LilyPond. Currently we still use
> guilev-1.8, though have experimental support for guilev2.
> I do a lot of support on our user-list, frequently checking things
> with my lilypond-guilev2-setup to detect bugs.
>
> Recently a user wrote a large scm-file and put it into lilypond using
> '(load file.scm)'.
> No problem with guilev1, but with guilev2 'file.scm' is not found.
> Thus I tried to track the problem down.
> Not a bad start is to rtfm :)
> So I found 'current-load-port' and intended to play around with it
> whether I can get some useful info out of it.
>
> In short, I likely don't need 'current-load-port' for anything, but
> couldn't be sure before I used it. Thus this thread and patch.
>
> While doing rtfm I found 'primitive-load' working for the above
> described purpose in guilev1 and guilev2. So the problem is solvable.
>
> Although this doesn't explain why 'load' stopped working for lilypond.
> I then started from our master (guilev1) and changed only two things:
> - teaching configure to accept guile-2.9.1
> - disabling a certain not longer supported function (only needed for
> collecting some statistic data and never used afair)
> Omitting all other guilev2-patches will ofcourse result in a very
> buggy lilypond, if someone would intend to use it, but enough to check
> whether 'load' works.
> It does not.
> So the underlying problem is either already in lilypond-master or
> guilev2 changed something in 'load'.
>
> That's my current research-state.

Addition:
(load "full/path/to/file.scm") does work in LilyPond as opposed to a
relative path.

>
> Any hint from the guile side?
>
>
> Thanks,
>   Harm

Re: What's up with 'current-load-port'

[Ludovic Courtès]

Hi Thomas,

Thomas Morley <thomasmorley65@gmail.com> skribis:

> Recently a user wrote a large scm-file and put it into lilypond using
> '(load file.scm)'.
> No problem with guilev1, but with guilev2 'file.scm' is not found.

In Guile 2.x, there’s a compilation step that did not exist in 1.8, so
the question of how to resolve relative file names passed to ‘load’
becomes trickier.

What Guile 2.x does is that ‘load’ is now a macro that attempts to
resolve file names relative to the location of the *source* file.  So if
you have a.scm and b.scm in the same directory, and a.scm does:

  (load "./b.scm")

then b.scm is searched for in the same directory as a.scm.

Of course if you use an absolute file name, that logic doesn’t come into
play.

I would recommend using modules to the extent possible, or using things
like:

  (search-path %load-path "file.scm")

when you want to search for a file at run time.

HTH!

Ludo’.

Re: What's up with 'current-load-port'

[Thomas Morley]

Am Mo., 5. Nov. 2018 um 11:38 Uhr schrieb Ludovic Courtès <ludo@gnu.org>:
>
> Hi Thomas,
>
> Thomas Morley <thomasmorley65@gmail.com> skribis:
>
> > Recently a user wrote a large scm-file and put it into lilypond using
> > '(load file.scm)'.
> > No problem with guilev1, but with guilev2 'file.scm' is not found.
>
> In Guile 2.x, there’s a compilation step that did not exist in 1.8, so
> the question of how to resolve relative file names passed to ‘load’
> becomes trickier.
>
> What Guile 2.x does is that ‘load’ is now a macro that attempts to
> resolve file names relative to the location of the *source* file.  So if
> you have a.scm and b.scm in the same directory, and a.scm does:
>
>   (load "./b.scm")
>
> then b.scm is searched for in the same directory as a.scm.
>
> Of course if you use an absolute file name, that logic doesn’t come into
> play.
>
> I would recommend using modules to the extent possible, or using things
> like:
>
>   (search-path %load-path "file.scm")
>
> when you want to search for a file at run time.
>
> HTH!
>
> Ludo’.

Hi Ludo,

thanks for all the hints.
Not sure I can work on it before next weekend, though :(

Many thanks,
  Harm