Larry Troxler:
Kjetil, speaking of paths, it would be better IMO if you use the PD search path to load your scheme files, instead of only looking in the current directory. What I did in my pd_scheme external was to define a C callback in scheme, which callled the PD path search routine.
Okey, I'll let it look in the current directory first and the check out the PD search path, and after that, perhaps the guile %load-path?
I think this bit is very much needed for practical use, unless people want to copy all the scheme files they use into the directory that they run PD from.
I allways do it like that. Cd into a project directory where and have all my files, and start pd.
For example, your help file doesn't run as is, with your current approach.
No, you must cd into the k_guile directory. :) Oh well.
Understand, please, that this is a minor point overall, and I thank you for providing this way cool tool for us PD users!
Another minor point, it would be nice if PD timers (or maybe "clocks" is the PD nomenclature, I don't remember) were supported as well.
Hmm, are you sure its not easier to use metro or something? It shouldn't be to hard to implement though.
But really, actually, either of the above two points I could tackle myself. Just let me know (a) if you want me to,
Yes, that would be very nice. If you have access to the pure data cvs, please commit. If not, just e-mail the patches to me.
On Sunday 11 January 2004 11:36, Kjetil Svalastog Matheussen wrote:
Hmm, are you sure its not easier to use metro or something? It shouldn't be to hard to implement though.
Not to me, but then again, everyone's different, and with something so open-ended as PD, who knows, I could be the only person who misses a built in timer.
Once I had scheme inside a PD box, I wanted to make sequencers, rhythm generators, etc.
Sure, you could have an output of the scheme box be a delay time till the next trigger, but then you have to wire it through a [delay] and back to some input pin. I just personally found it worthwhile to implement internally, rather than having to go through this artificial external self-patching each time ., that's all. No big deal.
Larry
On Sun, 11 Jan 2004, Larry Troxler wrote:
On Sunday 11 January 2004 11:36, Kjetil Svalastog Matheussen wrote:
Hmm, are you sure its not easier to use metro or something? It shouldn't be to hard to implement though.
Not to me, but then again, everyone's different, and with something so open-ended as PD, who knows, I could be the only person who misses a built in timer.
Once I had scheme inside a PD box, I wanted to make sequencers, rhythm generators, etc.
Sure, you could have an output of the scheme box be a delay time till the next trigger, but then you have to wire it through a [delay] and back to some input pin. I just personally found it worthwhile to implement internally, rather than having to go through this artificial external self-patching each time ., that's all. No big deal.
I thought about having a metro sending a bang to a k_guile object to make a timer. Something like this:
(pd-inlet 0 'bang (lambda () (set! time (+ time 1))))
(pd-inlet 0 'reset (lambda () (set! time 0)))
But I agree something like this would be nice too:
(pd-delay 1000 (lambda () (pd-display "one second later")))
Kjetil, I'm very confused now, upon reading the source for k_guille: what's the point of the "global_scm.txt" and "local_scm.txt" files that are included in the source and evaluated. Why not just (load) the corresponding scheme files instead?
Larry
On Mon, 12 Jan 2004, Larry Troxler wrote:
Kjetil, I'm very confused now, upon reading the source for k_guille: what's the point of the "global_scm.txt" and "local_scm.txt" files that are included in the source and evaluated. Why not just (load) the corresponding scheme files instead?
Oops, global_scm.txt and local_scm.txt isn't supposed to be in the repository. They are autogenerated by the gen_c_scheme.py program. Will remove. But, local.scm can't be (load)-ed, because its inside a function called "pd-instance-func" (see k_guile_load). The function works like this:
(define (pd-instance-func pd-instance) (eval-file "local.scm") (eval-file file) (pd-set-inlet-func) (pd-set-cleanup-func))
and is created and defined for each time a file is loaded in k_guile.
The second reason is that by including global.scm and local.scm directly into the k_guile.pd-linux binary instead of loading the files somehow, there is no problem finding those files when running the k_guile external. local.scm and global.scm aren't supposed to be changed very often anyway.
On Tuesday 13 January 2004 08:13, Kjetil Svalastog Matheussen wrote:
On Mon, 12 Jan 2004, Larry Troxler wrote:
Kjetil, I'm very confused now, upon reading the source for k_guille: what's the point of the "global_scm.txt" and "local_scm.txt" files that are included in the source and evaluated. Why not just (load) the corresponding scheme files instead?
Oops, global_scm.txt and local_scm.txt isn't supposed to be in the repository. They are autogenerated by the gen_c_scheme.py program. Will remove.
Yep, this much I understand.
But, local.scm can't be (load)-ed, because its inside a function called "pd-instance-func" (see k_guile_load). The function works like this:
(define (pd-instance-func pd-instance) (eval-file "local.scm") (eval-file file) (pd-set-inlet-func) (pd-set-cleanup-func))
and is created and defined for each time a file is loaded in k_guile.
Hmm, I guess I have to learn more about Scheme to understand this - until now, I've been used to using Common Lisp, and have never really learned the standard Scheme language.
I have to say, it does seem very strange that you would have to resort to such a horrible klugde to boot up your scheme code. Does it have something to do with the fact that you want a seperate interpreter for each object?
Incidently, I'm really doubting about how using seperate interpreters for each object could work for someone who wants to use Common Music in scheme within PD.
But hopefully other people who are more experienced in Scheme as a opposed to Common Lisp, will chime in here. It could well be that I'm missing some level of understanding, or am simply of the minority opinion.
The second reason is that by including global.scm and local.scm directly into the k_guile.pd-linux binary instead of loading the files somehow, there is no problem finding those files when running the k_guile external. local.scm and global.scm aren't supposed to be changed very often anyway.
I personally don't agree with this argument. No matter what, in order to make use of your external, those scheme files need to be available. The only distinction is whether you need them at the time you build the external, or whether they need to be there at the time you load the external into PD. Either way, they need to be there.
Whatever, I think I'm probably confused based on my lack of knowledge of Scheme as opposed to Common Lisp, and/or we have different goals.
Larry Troxler
On Tue, 13 Jan 2004, Larry Troxler wrote:
But, local.scm can't be (load)-ed, because its inside a function called "pd-instance-func" (see k_guile_load). The function works like this:
(define (pd-instance-func pd-instance) (eval-file "local.scm") (eval-file file) (pd-set-inlet-func) (pd-set-cleanup-func))
and is created and defined for each time a file is loaded in k_guile.
Hmm, I guess I have to learn more about Scheme to understand this - until now, I've been used to using Common Lisp, and have never really learned the standard Scheme language.
I have to say, it does seem very strange that you would have to resort to such a horrible klugde to boot up your scheme code. Does it have something to do with the fact that you want a seperate interpreter for each object?
Not exactly, all code is run in the same interpreter. But the (define) thing is to let each instance run in its own namespace.
Say you have the following script called setnum.scm:
(define number 0) (pd-inlet 0 'setnum (lambda (n) (set! number n))
If you have two [k_guile setnum.scm] objects in a pd patch and the scripts are loaded into the global environment, "number" will be written from both objects, because they both use the same "number" variable.
Incidently, I'm really doubting about how using seperate interpreters for each object could work for someone who wants to use Common Music in scheme within PD.
But hopefully other people who are more experienced in Scheme as a opposed to Common Lisp, will chime in here. It could well be that I'm missing some level of understanding, or am simply of the minority opinion.
Scheme is built around environments, which is a namespace. For each new lambda/define a new environment is made. (Or something like that, at least)
The second reason is that by including global.scm and local.scm directly into the k_guile.pd-linux binary instead of loading the files somehow, there is no problem finding those files when running the k_guile external. local.scm and global.scm aren't supposed to be changed very often anyway.
I personally don't agree with this argument. No matter what, in order to make use of your external, those scheme files need to be available. The only distinction is whether you need them at the time you build the external, or whether they need to be there at the time you load the external into PD. Either way, they need to be there.
Users don't have (or at least shouldn't have) any need for local.scm or global.scm by runtime, and the files are therefore unnecesarry when running k_guile. Letting the files be loaded at runtime only introduce extra unnecesarry complexity for the user.
On Wednesday 14 January 2004 10:22, Kjetil Svalastog Matheussen wrote:
Not exactly, all code is run in the same interpreter. But the (define) thing is to let each instance run in its own namespace.
Is what you refer to as a "namespace", the same as what Common Lisp would refer to as a "closure"? In common lisp, such a function definition would create a "closure", which is I think a persistent "environment", and "environment" being a set of symbol bindings more or less.
Say you have the following script called setnum.scm:
(define number 0) (pd-inlet 0 'setnum (lambda (n) (set! number n))
If you have two [k_guile setnum.scm] objects in a pd patch and the scripts are loaded into the global environment, "number" will be written from both objects, because they both use the same "number" variable.
Ok, I'll try that - should be an interesting experiment.
But still, the problem is, if I want to load Common Music for example, where would I do that? Certainly I don't think it would work to re-load it upon every PD object instantiation, because who knows what when it first gets loaded. And certianly, the global symbols in Common Music should remane truly global. I think the only safe thing would be to load it once only, before any PD objects that use scheme get loaded. Or else have some global flag somewhere that causes Common Music to load only on the first object that needs to use it. But again, my experience is with Common Lisp, and not Scheme, so it's entirely possible that the difference between these languages has my very confused at the moment.
Incidently, I'm really doubting about how using seperate interpreters for each object could work for someone who wants to use Common Music in scheme within PD.
But hopefully other people who are more experienced in Scheme as a opposed to Common Lisp, will chime in here. It could well be that I'm missing some level of understanding, or am simply of the minority opinion.
Scheme is built around environments, which is a namespace. For each new lambda/define a new environment is made. (Or something like that, at least)
The second reason is that by including global.scm and local.scm directly into the k_guile.pd-linux binary instead of loading the files somehow, there is no problem finding those files when running the k_guile external. local.scm and global.scm aren't supposed to be changed very often anyway.
I personally don't agree with this argument. No matter what, in order to make use of your external, those scheme files need to be available. The only distinction is whether you need them at the time you build the external, or whether they need to be there at the time you load the external into PD. Either way, they need to be there.
Users don't have (or at least shouldn't have) any need for local.scm or global.scm by runtime, and the files are therefore unnecesarry when running k_guile. Letting the files be loaded at runtime only introduce extra unnecesarry complexity for the user.
On Wed, 14 Jan 2004, Larry Troxler wrote:
On Wednesday 14 January 2004 10:22, Kjetil Svalastog Matheussen wrote:
Not exactly, all code is run in the same interpreter. But the (define) thing is to let each instance run in its own namespace.
Is what you refer to as a "namespace", the same as what Common Lisp would refer to as a "closure"? In common lisp, such a function definition would create a "closure", which is I think a persistent "environment", and "environment" being a set of symbol bindings more or less.
I don't know what a closure is actually. But you can think of an environment (which defines the nearest namespace) as a stack only that it doesn't dissapear unless not referenced to anymore. Its not complicated, I just dont know how to explain properly.
Say you have the following script called setnum.scm:
(define number 0) (pd-inlet 0 'setnum (lambda (n) (set! number n))
If you have two [k_guile setnum.scm] objects in a pd patch and the scripts are loaded into the global environment, "number" will be written from both objects, because they both use the same "number" variable.
Ok, I'll try that - should be an interesting experiment.
But still, the problem is, if I want to load Common Music for example, where would I do that?
In the CVS I added (load-if-exists "/etc/k_guile.scm")(load-if-exists "$HOME/.k_guile.scm") into global.scm.
So if you put something like the following code:
" (define common-music-loaded #f) (define (load-common-music) (if (not common-music-loaded) (load "path-to-common-music/cm.scm")) (set! common-music-loaded #t)) "
into /etc/k_guile.scm, you can safely call (load-common-music) in your scheme programs used for k_guile.
Certainly I don't think it would work to re-load it upon every PD object instantiation,
Yest, that would not be a good thing.
because who knows what when it first gets loaded. And certianly, the global symbols in Common Music should remane truly global.
(load file) always puts the file into the global environment, not matter if you are in another environment.
On Thursday 15 January 2004 05:14, Kjetil Svalastog Matheussen wrote:
On Wed, 14 Jan 2004, Larry Troxler wrote:
On Wednesday 14 January 2004 10:22, Kjetil Svalastog Matheussen wrote:
Not exactly, all code is run in the same interpreter. But the (define) thing is to let each instance run in its own namespace.
Is what you refer to as a "namespace", the same as what Common Lisp would refer to as a "closure"? In common lisp, such a function definition would create a "closure", which is I think a persistent "environment", and "environment" being a set of symbol bindings more or less.
I don't know what a closure is actually. But you can think of an environment (which defines the nearest namespace) as a stack only that it doesn't dissapear unless not referenced to anymore. Its not complicated, I just dont know how to explain properly.
Ok, understood. When you said "namespace", I started wondering whether scheme had a mechanism similar to Common Lisp's "packages".
So, if I understand you correctly, a "namespace" in scheme is a staticly scoped environment.
In the CVS I added (load-if-exists "/etc/k_guile.scm")(load-if-exists "$HOME/.k_guile.scm") into global.scm.
Finally got it (after waiting the sourceforge lag-time - they really have to do something about that if they're serious about keeping projects on their site). At the moment I'm not sure if this is working - I'm using (display) in my .k_guile.scm to announce itself but I hear nothing, and it should be also loading Common Music. Probably I need to go to a Scheme site and learn more about Scheme output to the console.
So if you put something like the following code:
" (define common-music-loaded #f) (define (load-common-music) (if (not common-music-loaded) (load "path-to-common-music/cm.scm")) (set! common-music-loaded #t)) "
into /etc/k_guile.scm, you can safely call (load-common-music) in your scheme programs used for k_guile.
Isn't this called from global.scm, which is run when the library is first loaded? Isn't this script called from the "setup" function? (I think this is the source of all my confusion - what does PD do about loading libraries that define a single extern). If so, why do you need that singleton pattern?
Larry Troxler
On Sat, 24 Jan 2004, Larry Troxler wrote:
On Thursday 15 January 2004 05:14, Kjetil Svalastog Matheussen wrote:
On Wed, 14 Jan 2004, Larry Troxler wrote:
On Wednesday 14 January 2004 10:22, Kjetil Svalastog Matheussen wrote:
Not exactly, all code is run in the same interpreter. But the (define) thing is to let each instance run in its own namespace.
Is what you refer to as a "namespace", the same as what Common Lisp would refer to as a "closure"? In common lisp, such a function definition would create a "closure", which is I think a persistent "environment", and "environment" being a set of symbol bindings more or less.
I don't know what a closure is actually. But you can think of an environment (which defines the nearest namespace) as a stack only that it doesn't dissapear unless not referenced to anymore. Its not complicated, I just dont know how to explain properly.
Ok, understood. When you said "namespace", I started wondering whether scheme had a mechanism similar to Common Lisp's "packages".
So, if I understand you correctly, a "namespace" in scheme is a staticly scoped environment.
Hmmmm. :) Don't know what scoped means... (Don't know common lisp!) Can't you just try things out and see how it behaves?
In the CVS I added (load-if-exists "/etc/k_guile.scm")(load-if-exists "$HOME/.k_guile.scm") into global.scm.
Finally got it (after waiting the sourceforge lag-time - they really have to do something about that if they're serious about keeping projects on their site). At the moment I'm not sure if this is working - I'm using (display) in my .k_guile.scm to announce itself but I hear nothing, and it should be also loading Common Music. Probably I need to go to a Scheme site and learn more about Scheme output to the console.
(display) should work, but you must remember to use (newline) afterwords. (pd-display) does both.
So if you put something like the following code:
" (define common-music-loaded #f) (define (load-common-music) (if (not common-music-loaded) (load "path-to-common-music/cm.scm")) (set! common-music-loaded #t)) "
into /etc/k_guile.scm, you can safely call (load-common-music) in your scheme programs used for k_guile.
Isn't this called from global.scm, which is run when the library is first loaded?
Yes, thats right.
Isn't this script called from the "setup" function?
Its called inside the k_guile setup function. The function that defines the k_guile external in pd. Its only called once.
(I think this is the source of all my confusion - what does PD do about loading libraries that define a single extern). If so, why do you need that singleton pattern?
I think you just have to try things out.
-
Kjetil Svalastog Matheussen -
Larry Troxler