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

[Alex Vong]

Hello,

Post by Thomas Morley
Hi,
what's up with 'current-load-port'?
guile-1.8: #<primitive-procedure current-load-port>
guile-2.0.14: #<procedure current-load-port ()>
;;; <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

Post by Thomas Morley
Cheers,
Harm

Cheers,
Alex

[Thomas Morley]

Post by Alex Vong
Hello,

Post by Thomas Morley
Hi,
what's up with 'current-load-port'?
guile-1.8: #<primitive-procedure current-load-port>
guile-2.0.14: #<procedure current-load-port ()>
;;; <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

Post by Thomas Morley
Cheers,
Harm

Cheers,
Alex

Hi Alex,

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

Best,
Harm

[Alex Vong]

Thomas Morley <***@gmail.com> writes:

[...]

Post by Thomas Morley
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'.

Post by Thomas Morley
Best,
Harm

[Mark H Weaver]

Post by Thomas Morley
what's up with 'current-load-port'?
guile-1.8: #<primitive-procedure current-load-port>
guile-2.0.14: #<procedure current-load-port ()>
;;; <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

[Thomas Morley]

Post by Mark H Weaver

Post by Thomas Morley
what's up with 'current-load-port'?
guile-1.8: #<primitive-procedure current-load-port>
guile-2.0.14: #<procedure current-load-port ()>
;;; <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

[Thomas Morley]

Am Mo., 5. Nov. 2018 um 09:25 Uhr schrieb Thomas Morley

Post by Thomas Morley

Post by Mark H Weaver

Post by Thomas Morley
what's up with 'current-load-port'?
guile-1.8: #<primitive-procedure current-load-port>
guile-2.0.14: #<procedure current-load-port ()>
;;; <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

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.
- 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.

Post by Thomas Morley
Any hint from the guile side?
Thanks,
Harm

[Ludovic Courtès]

Hi Thomas,

Post by Thomas Morley
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’.

[Thomas Morley]

Post by Ludovic Courtès
Hi Thomas,

Post by Thomas Morley
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
(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
(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