Hi all,
it seems that the ways of dealing with externals and paths is always in flux! I would like to confirm a suspicion that, for the time being, the following works the way I think it does, assuming PD 0.39:
[library/object] imports that specific object into global namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or abstractions in the library path.
[import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different objects with the same name from different libs, as the last library imported will have priority.
Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40?
best! d.
as far as I understood [import] is the same as [declare -lib] and that only adds a library to the local namespace of a patch. see the help file for declare that comes with 0.41. you can declare your library relative to pd [declare -stdlib] or relative to the patch [declare -lib], but - as mentioned in the helpfile
- the name stdpath is confusing!].
it is also not 100% clear, how this works in abstractions and if the behaviour will be consistent with future pd versions. there might be a chance that [import] really adds to the global namespace, but I don't think so. (otoh I don't know how to add something to the global namespace.) the idea was that you can use a certain objectclass in one patch and another one with the same name (but from another lib) in another patch. please correct me, if I'm wrong. marius.
Derek Holzer wrote:
Hi all,
it seems that the ways of dealing with externals and paths is always in flux! I would like to confirm a suspicion that, for the time being, the following works the way I think it does, assuming PD 0.39:
[library/object] imports that specific object into global namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or abstractions in the library path.
[import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different objects with the same name from different libs, as the last library imported will have priority.
Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40?
best! d.
This is only the case on 0.40 and newer. [import] on 0.39 loads into
the global namespace. This stuff is currently alpha and not
complete, so it is not very clear. I think for the manual, the best
bet for Pd-extended is to use the [library/objectclass] format for
objectclasses that aren't loaded by default. That has been supported
by every version of Pd for a long time now (as long as you install
the libraries that way).
.hc
On Apr 8, 2008, at 9:22 AM, marius schebella wrote:
as far as I understood [import] is the same as [declare -lib] and that only adds a library to the local namespace of a patch. see the help
file for declare that comes with 0.41. you can declare your library relative to pd [declare -stdlib] or relative to the patch [declare -lib], but - as mentioned in the
helpfile
- the name stdpath is confusing!].
it is also not 100% clear, how this works in abstractions and if the behaviour will be consistent with future pd versions. there might be a chance that [import] really adds to the global namespace, but I don't think so. (otoh I don't know how to add
something to the global namespace.) the idea was that you can use a certain objectclass in one patch and another one with the same name (but from another lib) in another
patch. please correct me, if I'm wrong. marius.Derek Holzer wrote:
Hi all,
it seems that the ways of dealing with externals and paths is
always in flux! I would like to confirm a suspicion that, for the time
being, the following works the way I think it does, assuming PD 0.39:[library/object] imports that specific object into global
namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or
abstractions in the library path.[import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different
objects with the same name from different libs, as the last library imported will have priority.Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40?
best! d.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
But this way doesn't load abstractions and help patches, AFAIK.
d.
Hans-Christoph Steiner wrote:
This is only the case on 0.40 and newer. [import] on 0.39 loads into the global namespace. This stuff is currently alpha and not complete, so it is not very clear. I think for the manual, the best bet for Pd-extended is to use the [library/objectclass] format for objectclasses that aren't loaded by default. That has been supported by every version of Pd for a long time now (as long as you install the libraries that way).
.hc
On Apr 8, 2008, at 9:22 AM, marius schebella wrote:
as far as I understood [import] is the same as [declare -lib] and that only adds a library to the local namespace of a patch. see the help file for declare that comes with 0.41. you can declare your library relative to pd [declare -stdlib] or relative to the patch [declare -lib], but - as mentioned in the helpfile
- the name stdpath is confusing!].
it is also not 100% clear, how this works in abstractions and if the behaviour will be consistent with future pd versions. there might be a chance that [import] really adds to the global namespace, but I don't think so. (otoh I don't know how to add something to the global namespace.) the idea was that you can use a certain objectclass in one patch and another one with the same name (but from another lib) in another patch. please correct me, if I'm wrong. marius.
Derek Holzer wrote:
Hi all,
it seems that the ways of dealing with externals and paths is always in flux! I would like to confirm a suspicion that, for the time being, the following works the way I think it does, assuming PD 0.39:
[library/object] imports that specific object into global namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or abstractions in the library path.
[import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different objects with the same name from different libs, as the last library imported will have priority.
Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40?
best! d.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Please file bug reports if you can't load abstractions that way. I
think there is one specific case where help patches don't load then,
but I don't remember off hand what it was. A bug report for that
would also be quite helpful.
.hc
On Apr 8, 2008, at 11:37 AM, Derek Holzer wrote:
But this way doesn't load abstractions and help patches, AFAIK.
d.
Hans-Christoph Steiner wrote:
This is only the case on 0.40 and newer. [import] on 0.39 loads
into the global namespace. This stuff is currently alpha and not
complete, so it is not very clear. I think for the manual, the
best bet for Pd-extended is to use the [library/objectclass]
format for objectclasses that aren't loaded by default. That has
been supported by every version of Pd for a long time now (as long
as you install the libraries that way). .hc On Apr 8, 2008, at 9:22 AM, marius schebella wrote:as far as I understood [import] is the same as [declare -lib] and
that only adds a library to the local namespace of a patch. see the
help file for declare that comes with 0.41. you can declare your library relative to pd [declare -stdlib] or relative to the patch [declare -lib], but - as mentioned in the
helpfile
- the name stdpath is confusing!].
it is also not 100% clear, how this works in abstractions and if the behaviour will be consistent with future pd versions. there might be a chance that [import] really adds to the global namespace, but I don't think so. (otoh I don't know how to add
something to the global namespace.) the idea was that you can use a certain objectclass in one patch and another one with the same name (but from another lib) in another
patch. please correct me, if I'm wrong. marius.Derek Holzer wrote:
Hi all,
it seems that the ways of dealing with externals and paths is
always in flux! I would like to confirm a suspicion that, for the time
being, the following works the way I think it does, assuming PD 0.39:[library/object] imports that specific object into global
namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or
abstractions in the library path.[import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have
often found this broken in Extended). It cannot accommodate different
objects with the same name from different libs, as the last library
imported will have priority.Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40?
best! d.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
------- Computer science is no more related to the computer than
astronomy is related to the telescope. -Edsger Dykstra-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 39: "Cut a vital connection"
¡El pueblo unido jamás será vencido!
OK, when I run into it again I'll let you know. Usually this happens in workshops, where other things need to get fixed first ;-)
d.
Hans-Christoph Steiner wrote:
Please file bug reports if you can't load abstractions that way. I think there is one specific case where help patches don't load then, but I don't remember off hand what it was. A bug report for that would also be quite helpful.
.hc
On Apr 8, 2008, at 11:37 AM, Derek Holzer wrote:
But this way doesn't load abstractions and help patches, AFAIK.
d.
Hans-Christoph Steiner wrote:
This is only the case on 0.40 and newer. [import] on 0.39 loads into the global namespace. This stuff is currently alpha and not complete, so it is not very clear. I think for the manual, the best bet for Pd-extended is to use the [library/objectclass] format for objectclasses that aren't loaded by default. That has been supported by every version of Pd for a long time now (as long as you install the libraries that way). .hc On Apr 8, 2008, at 9:22 AM, marius schebella wrote:
as far as I understood [import] is the same as [declare -lib] and that only adds a library to the local namespace of a patch. see the help file for declare that comes with 0.41. you can declare your library relative to pd [declare -stdlib] or relative to the patch [declare -lib], but - as mentioned in the helpfile
- the name stdpath is confusing!].
it is also not 100% clear, how this works in abstractions and if the behaviour will be consistent with future pd versions. there might be a chance that [import] really adds to the global namespace, but I don't think so. (otoh I don't know how to add something to the global namespace.) the idea was that you can use a certain objectclass in one patch and another one with the same name (but from another lib) in another patch. please correct me, if I'm wrong. marius.
Derek Holzer wrote:
Hi all,
it seems that the ways of dealing with externals and paths is always in flux! I would like to confirm a suspicion that, for the time being, the following works the way I think it does, assuming PD 0.39:
[library/object] imports that specific object into global namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or abstractions in the library path.
[import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different objects with the same name from different libs, as the last library imported will have priority.
Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40?
best! d.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 39: "Cut a vital connection"
¡El pueblo unido jamás será vencido!
On Apr 8, 2008, at 6:01 AM, Derek Holzer wrote:
Hi all,
it seems that the ways of dealing with externals and paths is
always in flux! I would like to confirm a suspicion that, for the time being,
the following works the way I think it does, assuming PD 0.39:[library/object] imports that specific object into global
namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or
abstractions in the library path.
You can load abstractions this way too: [library/myabs]. Help
patches should work, there is a bug in 0.39 that I aim to fix in 0.40.
[import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different
objects with the same name from different libs, as the last library imported will have priority.Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40?
It is hopefully properly implemented with canvas-local and global
namespaces. I am aiming to have this all fixed up for the 0.40.3-
extended release at the end of the month, then this will be all
clearer in my head. When's your deadline?
.hc
best! d. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 33: "Cluster analysis"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Access to computers should be unlimited and total. - the hacker ethic
Well, we're working on the FLOSS Manual this week as part of a "book sprint" on the Croatian island of Korcula:
http://flossmanuals.net/puredata
I know, life's hard sometimes... ;-)
We can always add things later, but we'd like something publishable at the end of the week. The we can invite more contributions from others.
Do you think we should hold off for the 0.40 release, or just update later?
d.
Hans-Christoph Steiner wrote:
It is hopefully properly implemented with canvas-local and global namespaces. I am aiming to have this all fixed up for the 0.40.3-extended release at the end of the month, then this will be all clearer in my head. When's your deadline?
It will be twice as nice by the end of the week, we hope! ;-) Then I'll publish a call to contribute new tutorials. Or maybe you can team up with "Screaming" Frank Barknecht to do a German version...
Hope you're interested! best, d.
marius schebella wrote:
Derek Holzer wrote:
wow! that is quite impressive! marius.
I am still interested in producing video tutorials and some use case oriented gem tutorials. but this has to wait a little, right now I don't have the time. marius.
Derek Holzer wrote:
It will be twice as nice by the end of the week, we hope! ;-) Then I'll publish a call to contribute new tutorials. Or maybe you can team up with "Screaming" Frank Barknecht to do a German version...
Hope you're interested! best, d.
marius schebella wrote:
Derek Holzer wrote:
wow! that is quite impressive! marius.
Would be very cool. I plan to do a simple GEM VJ mixer tut with two [pix_film] objects and a crossfader. Would be a good base to build on. Let me know when you have time!
d.
marius schebella wrote:
I am still interested in producing video tutorials and some use case oriented gem tutorials. but this has to wait a little, right now I don't have the time. marius.
Derek Holzer wrote:
It will be twice as nice by the end of the week, we hope! ;-) Then I'll publish a call to contribute new tutorials. Or maybe you can team up with "Screaming" Frank Barknecht to do a German version...
Hope you're interested! best, d.
marius schebella wrote:
Derek Holzer wrote:
wow! that is quite impressive! marius.
While I would think that it would be useful to have tutorials written in other languages, why not use some translation tools to make them? And then we can get someone to proof read them in whatever language they are being translated into, that way these tutorials will all offer the same information, rather than limiting them to only those that speak that language. Does Google have some policy about storing and publishing any translations they make? I am not a lawyer, but there is nothing on their translation page as to what you can do with the translated content, and ( http://www.google.com/accounts/TOS?loc=US ) I am not positive if this is the applicable legalese...
11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services. By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive licence to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services. This licence is for the sole purpose of enabling Google to display, distribute and promote the Services and may be revoked for certain Services as defined in the Additional Terms of those Services.
So, it sounds like you can do whatever you want with it, as long as Google gets to use it as well.
Of Course, that being said, I only speak english, and have rudimentary skills in a couple other languages, so I could only offer to proof read a translation to ensure it makes sense, not that it translated correctly.
I will say from what start you have on this Floss stuff is quite nice. If this sounds like a good idea, I would be more than happy to help out with these things.
On Tue, Apr 8, 2008 at 11:43 AM, Derek Holzer derek@umatic.nl wrote:
It will be twice as nice by the end of the week, we hope! ;-) Then I'll publish a call to contribute new tutorials. Or maybe you can team up with "Screaming" Frank Barknecht to do a German version...
Hope you're interested! best, d.
marius schebella wrote:
Derek Holzer wrote:
wow! that is quite impressive! marius.
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 1: "(Organic) machinery"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Mike,
my experience with Google, Babelfish, Alta Vista and others are that they are useful in a pinch, but they're no replacement for human translation. Especially with technical terms and such, but in general the differences between grammar and such between languages. Lots of proofreading, with the original in hand, would be required... almost as much work as a real translation, I imagine...
Actually some of the other FLOSS Manuals are getting translated into Hindi even as we speak, and there's been a call for Farsi translators as well. I think Adam Hyde (director of FLOSS Manuals project) may also be looking at Dutch translators soon (he lives in NL, which has supported the development of FLOSS Manuals so far through various subsidies). But human translators usually cost some money, so it's all about where the resources can be found to pay them, or where volunteers can be found. But now we get really OT, talking about money ;-)
Thanks for the interest and I'll let everyone know when the project opens up for more input. best, d.
Mike McGonagle wrote:
While I would think that it would be useful to have tutorials written in other languages, why not use some translation tools to make them? And then we can get someone to proof read them in whatever language they are being translated into, that way these tutorials will all offer the same information, rather than limiting them to only those that speak that language.
Does Google have some policy about storing and publishing any translations they make? I am not a lawyer, but there is nothing on their translation page as to what you can do with the translated content, and ( http://www.google.com/accounts/TOS?loc=US ) I am not positive if this is the applicable legalese...
11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services. By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive licence to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services. This licence is for the sole purpose of enabling Google to display, distribute and promote the Services and may be revoked for certain Services as defined in the Additional Terms of those Services.
So, it sounds like you can do whatever you want with it, as long as Google gets to use it as well.
Of Course, that being said, I only speak english, and have rudimentary skills in a couple other languages, so I could only offer to proof read a translation to ensure it makes sense, not that it translated correctly.
I will say from what start you have on this Floss stuff is quite nice. If this sounds like a good idea, I would be more than happy to help out with these things.
On Tue, Apr 8, 2008 at 11:43 AM, Derek Holzer <derek@umatic.nl mailto:derek@umatic.nl> wrote:
It will be twice as nice by the end of the week, we hope! ;-) Then I'll publish a call to contribute new tutorials. Or maybe you can team up with "Screaming" Frank Barknecht to do a German version... Hope you're interested! best, d. marius schebella wrote: > Derek Holzer wrote: > >> http://flossmanuals.net/puredata > > wow! that is quite impressive! > marius. >
translation is afaik treated as a derivative work. right about reuse in other work can be separated from the copyright (bu usually is not). and derivative works are treated slightly different in europe and the US (don't know about the rest of the world). in eu you have more control to what is done with your work when you give away copyright (dealing with some ethical aspects). marius.
Mike McGonagle wrote:
While I would think that it would be useful to have tutorials written in other languages, why not use some translation tools to make them? And then we can get someone to proof read them in whatever language they are being translated into, that way these tutorials will all offer the same information, rather than limiting them to only those that speak that language.
Does Google have some policy about storing and publishing any translations they make? I am not a lawyer, but there is nothing on their translation page as to what you can do with the translated content, and ( http://www.google.com/accounts/TOS?loc=US ) I am not positive if this is the applicable legalese...
11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services. By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive licence to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services. This licence is for the sole purpose of enabling Google to display, distribute and promote the Services and may be revoked for certain Services as defined in the Additional Terms of those Services.
So, it sounds like you can do whatever you want with it, as long as Google gets to use it as well.
Of Course, that being said, I only speak english, and have rudimentary skills in a couple other languages, so I could only offer to proof read a translation to ensure it makes sense, not that it translated correctly.
I will say from what start you have on this Floss stuff is quite nice. If this sounds like a good idea, I would be more than happy to help out with these things.
On Tue, Apr 8, 2008 at 11:43 AM, Derek Holzer <derek@umatic.nl mailto:derek@umatic.nl> wrote:
It will be twice as nice by the end of the week, we hope! ;-) Then I'll publish a call to contribute new tutorials. Or maybe you can team up with "Screaming" Frank Barknecht to do a German version... Hope you're interested! best, d. marius schebella wrote: > Derek Holzer wrote: > >> http://flossmanuals.net/puredata > > wow! that is quite impressive! > marius. > -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 1: "(Organic) machinery" _______________________________________________ PD-list@iem.at <mailto:PD-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list-- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician
-
Derek Holzer -
Hans-Christoph Steiner -
marius schebella -
Mike McGonagle