Re: [PD] import vs namespace

[marius schebella]

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 <[EMAIL PROTECTED] 
> > 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  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


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] import vs namespace

[Mike McGonagle]

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 <[EMAIL PROTECTED]> 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 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
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] import vs namespace

[marius schebella]

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:
>>
>>> http://flossmanuals.net/puredata
>>
>> wow! that is quite impressive!
>> marius.
>>
> 


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] import vs namespace

[Derek Holzer]

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 mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] import vs namespace

[marius schebella]

Derek Holzer wrote:

> http://flossmanuals.net/puredata

wow! that is quite impressive!
marius.

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] import vs namespace

[Derek Holzer]

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

-- 
derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 72:
"Find a safe part and use it as an anchor"

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] import vs namespace

[Derek Holzer]

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?



-- 
derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 39:
"Cut a vital connection"

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] import vs namespace

[Hans-Christoph Steiner]

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!



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] import vs namespace

[Derek Holzer]

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"

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] import vs namespace

[Hans-Christoph Steiner]

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



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] import vs namespace

[Hans-Christoph Steiner]

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



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] import vs namespace

[marius schebella]

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