Re: [PD] mapping: path setting hell

2009-04-09 Thread cyrille henry



Hans-Christoph Steiner a écrit :


On Apr 8, 2009, at 5:59 AM, cyrille henry wrote:




Hans-Christoph Steiner a écrit :

Inside of the objects themselves, I use always the [mapping/reverse] 
form.  Only in the help patches do I use the [reverse] form.  That 
convention seemed to make sense at the time, but I am not married to it.


since all mapping object are in the same directory, using the  
[reverse] form inside the object will still work on pd-extended.
but it will also make the mapping lib more flexible (you'll be able to 
move the objects / copy them in your patch directory ). So i see this 
as a big improvement of the situation.


do you agree if i change this?



Unfortunately, that's not entirely true, otherwise I would say to change 
it.  Right now, a binary object will trump ANY abstraction, even if it 
is in the same directory.  So if someone loads a binary object called 
reverse, then [reverse] will ALWAYS be that binary, so matter where 
you put reverse.pd or how you load it.  [mapping/reverse] prevents that.

name clash are bad.
curently it's a fact.
things may change in the future, but now nameclash must be avoid.

since there already are nameclash, it's important for a user to have a full 
control of the object used.
i do this by copying abstraction in my patch folder.
it also allow my patch to work latter, when the abstraction have changed.



This is a perfect case of why we should change the load order in Pd.

ok.
change it if you wish. 
but don't find workaround with solution that work only for you.


sorry if i'm rude, but i'm more and more irritated by this problem.
c

 I 
think it should search for all object types in a given path (i.e. .pd 
.pd_linux, .pd_lua, etc.)  THEN it should search the next path.  
Currently the opposite happens: it searches .pd_linux in all paths, then 
the loaders (i.e. .pd_lua) in all paths, then the abstractions in all 
paths.


.hc

 



[W]e have invented the technology to eliminate scarcity, but we are 
deliberately throwing it away to benefit those who profit from 
scarcity.-John Gilmore




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





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


Re: [PD] mapping: path setting hell

2009-04-09 Thread cyrille henry



Hans-Christoph Steiner a écrit :
...


If there is good code out there, I want to use it, not reinvent it. 
having a complex abstraction to replace this : 


loadbang
$1
moses 0

is overkill. it add complexity to a simple patch.

If 
you use mapping in Pd-extended, you never need to know anything about 
what's happening inside, it just works.

if you don't use pd extended, it just don't work.
i already explain why i don't use pd-extended, and will not change my mind soon.


 With a little bit of effort, 
Pd-vanilla users can also acheive this.  That's why I am fixing up 
libdir.c and these libraries in SVN.


i just don't want to add complexity to a simple thing, just because you think 
it's better.



These libraries were a place for me to experiment with ways of handling 
libraries in Pd easier.

for me it was something for everyday use!
and i basically can't use it the way i want, and the way i made it.

 Some of the experiments failed, but I think 
right now its in a pretty good place.  So try it out the way it is now 
and tell me what doesn't work.



to have mapping/reverse in the object break the way i work with pd for the last 
8 years.

to use [float_argument] that is outside the mapping folder cause problem to. 
(remember the pm mapping presentation @ hangar?)
at least, it could be copy / linked on the mapping directory. the best would be 
of course to replace it with a more simpler code based on 3 simple object. 
(well, to revert the change you made to my objects)

this are the biggest problem i've got.


cyrille



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


Re: [PD] mapping: path setting hell

2009-04-09 Thread IOhannes m zmoelnig

cyrille henry wrote:



Hans-Christoph Steiner a écrit :
...


If there is good code out there, I want to use it, not reinvent it. 

having a complex abstraction to replace this :
loadbang
$1
moses 0


shouldn't that be [select 0] rather than [moses 0] ?


mfgasd.r
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] mapping: path setting hell

2009-04-09 Thread cyrille henry

moses 0 filter also negative arguments, they usually are unwanted.
but of course sel 0 is used the rest of the time.

c

IOhannes m zmoelnig a écrit :

cyrille henry wrote:



Hans-Christoph Steiner a écrit :
...


If there is good code out there, I want to use it, not reinvent it. 

having a complex abstraction to replace this :
loadbang
$1
moses 0


shouldn't that be [select 0] rather than [moses 0] ?


mfgasd.r
IOhannes




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


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


Re: [PD] mapping: path setting hell

2009-04-09 Thread Hans-Christoph Steiner


On Apr 9, 2009, at 2:33 AM, cyrille henry wrote:




Hans-Christoph Steiner a écrit :

On Apr 8, 2009, at 5:59 AM, cyrille henry wrote:



Hans-Christoph Steiner a écrit :

Inside of the objects themselves, I use always the [mapping/ 
reverse] form.  Only in the help patches do I use the [reverse]  
form.  That convention seemed to make sense at the time, but I am  
not married to it.


since all mapping object are in the same directory, using the   
[reverse] form inside the object will still work on pd-extended.
but it will also make the mapping lib more flexible (you'll be  
able to move the objects / copy them in your patch directory ). So  
i see this as a big improvement of the situation.


do you agree if i change this?
Unfortunately, that's not entirely true, otherwise I would say to  
change it.  Right now, a binary object will trump ANY abstraction,  
even if it is in the same directory.  So if someone loads a binary  
object called reverse, then [reverse] will ALWAYS be that binary,  
so matter where you put reverse.pd or how you load it.  [mapping/ 
reverse] prevents that.

name clash are bad.
curently it's a fact.
things may change in the future, but now nameclash must be avoid.

since there already are nameclash, it's important for a user to have  
a full control of the object used.

i do this by copying abstraction in my patch folder.
it also allow my patch to work latter, when the abstraction have  
changed.


Copying the abstraction into the same folder as the project will not  
prevent the problem I described above.  As things are, that's not a  
solution. I think it'll work most of time, like most of these methods  
we discuss back and forth.


The namespace prefix like [mapping/reverse] is also not infallable,  
but it is a lot less likely to be affected by nameclashes, since there  
would have to be both a folder and a file named the same.  It seems to  
me a good starting place.  In any case, nameclashes are an old issue,  
many people have tackled it, I think we can learn from them and make a  
Pd-ish implementation of namespaces/import that is not complicated.


I think we can make a solution that always works.  I am not satisfied  
with just using the current situation.  I've been burned too many  
times in projects and while teaching workshops and classes by name  
conflicts.  The output~ one is a recent example.


.hc



This is a perfect case of why we should change the load order in Pd.

ok.
change it if you wish. but don't find workaround with solution that  
work only for you.


sorry if i'm rude, but i'm more and more irritated by this problem.
c

I think it should search for all object types in a given path  
(i.e. .pd .pd_linux, .pd_lua, etc.)  THEN it should search the next  
path.  Currently the opposite happens: it searches .pd_linux in all  
paths, then the loaders (i.e. .pd_lua) in all paths, then the  
abstractions in all paths.

.hc
 [W 
]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it away to benefit those who profit from  
scarcity.-John Gilmore

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








'You people have such restrictive dress for women,’ she said, hobbling  
away in three inch heels and panty hose to finish out another pink- 
collar temp pool day.  - “Hijab Scene #2, by Mohja Kahf




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


Re: [PD] mapping: path setting hell

2009-04-08 Thread cyrille henry



Frank Barknecht a écrit :

Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

Yes, there is some absurdity to this conversation.  I guess Frank and I 
have been doing this for so long, its just part of a game we play ;-)


Anyway, I could give the instructions in one step:

1. use Pd-extended ;-)


But that's exactly what I mean: mapping IMO has become promotion material for
pd-extended, but increasingly hard to use for users of newer Pd versions or
alternative distributions.

specially since it's mainly abstraction, i don't understand why we need to 
install it.
i think for this specific lib, any dependency of object outside it's directory 
can be seen as a bug.

c



I don't think many newbies really want to get into the nitty-gritty of  
hand-built Pd installs, but this conversation did make me smooth out the 
installation process.  Before, the 10 steps were for creating a library 
from scratch.  I think its pretty simple considering.  Now, the libraries 
are pre-built in SVN, so you only need to:


1. cd /path/to/your/extra (or wherever you want to install stuff)
2. svn co 
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mapping
3. svn co 
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/purepd
4. pd -lib libdir -lib purepd -lib mapping


You cheat a bit here: svn co whereverlibdiris; make libdir, and I don't know,
if help-files in mapping work then - with just your sets they won't. And you
still have the requirement of putting the directories mapping and purepd into a
directory in the pd path like extra, so it's still four paths to set, just
like I wrote in my first mail.

Ciao


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


Re: [PD] mapping: path setting hell

2009-04-08 Thread Hans-Christoph Steiner


On Apr 8, 2009, at 5:35 AM, cyrille henry wrote:




Frank Barknecht a écrit :

Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yes, there is some absurdity to this conversation.  I guess Frank  
and I have been doing this for so long, its just part of a game we  
play ;-)


Anyway, I could give the instructions in one step:

1. use Pd-extended ;-)
But that's exactly what I mean: mapping IMO has become promotion  
material for
pd-extended, but increasingly hard to use for users of newer Pd  
versions or

alternative distributions.
specially since it's mainly abstraction, i don't understand why we  
need to install it.
i think for this specific lib, any dependency of object outside it's  
directory can be seen as a bug.


I don't understand this at all.  Why did every modern operating system  
spend massive amounts of work to switch from static linking of  
libraries (i.e. including the library with the program itself) to  
dynamic, shared libraries (i.e. a single copy of a library shared by  
all programs that use it)?


.hc





c

I don't think many newbies really want to get into the nitty- 
gritty of  hand-built Pd installs, but this conversation did make  
me smooth out the installation process.  Before, the 10 steps were  
for creating a library from scratch.  I think its pretty simple  
considering.  Now, the libraries are pre-built in SVN, so you only  
need to:


1. cd /path/to/your/extra (or wherever you want to install stuff)
2. svn co 
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mapping
3. svn co 
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/purepd
4. pd -lib libdir -lib purepd -lib mapping
You cheat a bit here: svn co whereverlibdiris; make libdir, and I  
don't know,
if help-files in mapping work then - with just your sets they  
won't. And you
still have the requirement of putting the directories mapping and  
purepd into a
directory in the pd path like extra, so it's still four paths to  
set, just

like I wrote in my first mail.
Ciao


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






  ¡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] mapping: path setting hell

2009-04-08 Thread Hans-Christoph Steiner


On Apr 8, 2009, at 5:59 AM, cyrille henry wrote:




Hans-Christoph Steiner a écrit :

Inside of the objects themselves, I use always the [mapping/ 
reverse] form.  Only in the help patches do I use the [reverse]  
form.  That convention seemed to make sense at the time, but I am  
not married to it.


since all mapping object are in the same directory, using the   
[reverse] form inside the object will still work on pd-extended.
but it will also make the mapping lib more flexible (you'll be able  
to move the objects / copy them in your patch directory ). So i see  
this as a big improvement of the situation.


do you agree if i change this?



Unfortunately, that's not entirely true, otherwise I would say to  
change it.  Right now, a binary object will trump ANY abstraction,  
even if it is in the same directory.  So if someone loads a binary  
object called reverse, then [reverse] will ALWAYS be that binary, so  
matter where you put reverse.pd or how you load it.  [mapping/reverse]  
prevents that.


This is a perfect case of why we should change the load order in Pd.   
I think it should search for all object types in a given path  
(i.e. .pd .pd_linux, .pd_lua, etc.)  THEN it should search the next  
path.  Currently the opposite happens: it searches .pd_linux in all  
paths, then the loaders (i.e. .pd_lua) in all paths, then the  
abstractions in all paths.


.hc



[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it away to benefit those who profit from  
scarcity.-John Gilmore




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


Re: [PD] mapping: path setting hell

2009-04-08 Thread Hans-Christoph Steiner


On Apr 8, 2009, at 1:54 AM, Frank Barknecht wrote:


Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

You cheat a bit here: svn co whereverlibdiris; make libdir, and  
I  don't
know, if help-files in mapping work then - with just your sets  
they won't.
And you still have the requirement of putting the directories  
mapping and
purepd into a directory in the pd path like extra, so it's still  
four

paths to  set, just like I wrote in my first mail.


How about checking whether help files work before reporting the  
problem?


I wrote I don't know if helpp-files work - but I've tried it now.

You only need to install libdir once.  Plus if you use the latest  
version
of libdir, then 'extra' can be any folder in the path.  I suggest  
one of

these:

http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with-pd-extended


Okay, here's what I did:

$ cp -a SVN/mapping /usr/lib/pd/extra
$ cd SVN/loaders
$ svn update
$ make (to make libdir.pd_linux)
$ pd -lib libdir -lib mapping

gives this:
...
libdir loader $Revision: 1.8 $
   compiled on Apr  8 2009 at 07:46:59
   compiled against Pd version 0.42.4.
mapping: can't load library
...

and I still cannot create any mapping object. I was able to fix that  
by adding
a mapping-meta.pd file manually (copied from some pd-extended source  
on my

disk, could find one in SVN's trunk). Help files still don't work.

According to http://puredata.info/docs/developer/Libdir help-files  
have to be
either in 5.reference/libname or next to the object in question.  
Both is not
the case the way mapping is laid out and again something, that has  
to be done

manually.

That's all pretty complicated for a newbie like me. :)


Luckily the solution is simple:   svn update.  Sounds like you are  
working with an old copy.  The folder externals/mapping/help should  
be gone, all the help patches in externals/mapping, and there should  
be a externals/mapping/mapping-meta.pd file.  Otherwise, you're  
working with old code.


.hc




Ciao
--
Frank

___
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] mapping: path setting hell

2009-04-08 Thread Frank Barknecht
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

 Luckily the solution is simple:   svn update.  Sounds like you are  
 working with an old copy.  The folder externals/mapping/help should be 
 gone, all the help patches in externals/mapping, and there should be a 
 externals/mapping/mapping-meta.pd file.  Otherwise, you're working with 
 old code.

Ah, indeed, I was using the wrong outdated copy, so sorry for the wrong
help-file noise.

Ciao
-- 
Frank

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


Re: [PD] mapping: path setting hell

2009-04-08 Thread Frank Barknecht
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

 On Apr 8, 2009, at 5:35 AM, cyrille henry wrote:
 i think for this specific lib, any dependency of object outside it's  
 directory can be seen as a bug.

 I don't understand this at all.  Why did every modern operating system  
 spend massive amounts of work to switch from static linking of libraries 
 (i.e. including the library with the program itself) to dynamic, shared 
 libraries (i.e. a single copy of a library shared by all programs that 
 use it)?

I think, advantages and disadvantages have to be weighted, and IMO mapping
currently is leaning to a not very user friendly side. For example its use of
[float_argument], [symbol_argument] and [once] from purepd creates a dependency
on purepd that is completely unnecessary: [once] is only used once,
[symbol_argument] also, and float_argument very often is used where a simple [f
$1]  would be enough (its second argument is empty). So I'd say, get rid of it
and be more friendly to users. 

Another case is the standardization to use abstraction names, that require
the (sometimes broken) hexloader: Life would be much easier for a lot of people
without the - convention.

Other cases may not be so easy to fix and some externals are hard to replace,
but as it currenly is, mapping looks like a collection that puts some abstract
design principles higher than actual user demands. Of course that's just my
humble opinion, which is leaning to a much more simplistic side.

Ciao
-- 
Frank

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


Re: [PD] mapping: path setting hell

2009-04-08 Thread Hans-Christoph Steiner


On Apr 8, 2009, at 3:23 PM, Frank Barknecht wrote:


Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:


On Apr 8, 2009, at 5:35 AM, cyrille henry wrote:

i think for this specific lib, any dependency of object outside it's
directory can be seen as a bug.


I don't understand this at all.  Why did every modern operating  
system
spend massive amounts of work to switch from static linking of  
libraries
(i.e. including the library with the program itself) to dynamic,  
shared
libraries (i.e. a single copy of a library shared by all programs  
that

use it)?


I think, advantages and disadvantages have to be weighted, and IMO  
mapping
currently is leaning to a not very user friendly side. For example  
its use of
[float_argument], [symbol_argument] and [once] from purepd creates a  
dependency

on purepd that is completely unnecessary: [once] is only used once,
[symbol_argument] also, and float_argument very often is used where  
a simple [f
$1]  would be enough (its second argument is empty). So I'd say, get  
rid of it

and be more friendly to users.


If there is good code out there, I want to use it, not reinvent it.   
If you use mapping in Pd-extended, you never need to know anything  
about what's happening inside, it just works.  With a little bit of  
effort, Pd-vanilla users can also acheive this.  That's why I am  
fixing up libdir.c and these libraries in SVN.


Another case is the standardization to use abstraction names, that  
require
the (sometimes broken) hexloader: Life would be much easier for a  
lot of people

without the - convention.


Indeed, I fully agree. That's why I fixed it over a year ago :D   
mapping needs to hexloader tricks.


Other cases may not be so easy to fix and some externals are hard to  
replace,
but as it currenly is, mapping looks like a collection that puts  
some abstract
design principles higher than actual user demands. Of course that's  
just my

humble opinion, which is leaning to a much more simplistic side.


These libraries were a place for me to experiment with ways of  
handling libraries in Pd easier.  Some of the experiments failed, but  
I think right now its in a pretty good place.  So try it out the way  
it is now and tell me what doesn't work.


.hc




Ciao
--
Frank

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






All information should be free.  - the hacker ethic





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


Re: [PD] mapping: path setting hell

2009-04-07 Thread Luigi

Hey List.
	not wanting to offend anybody. But this has some good amount of  
absurdity in it, i think.

And for any Newbie following that its actually quite frightening.

Frank calls his way of doing hell and it only includes 3 steps.
And Hans Christoph calls his way easy and it includes 10 steps 

 monster monster-hell..

Another thing i always found strange about tthe mapping-collection. If  
you want to use the helpfiles
in one of your patches and actually use more then one you get into  
conflicts


What needs to be done to restructure mapping ?? I could help maybe,  
because its a library i used very often and found
it very useful. I would be happy to do something good to that  
library ;-)


All the Best

Luigi

Am 06.04.2009 um 15:58 schrieb Hans-Christoph Steiner:



On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:


Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:


1) SVN/externals - otherwise [center_point] isn't found
2) SVN/externals/mapping - to find [mapping/reverse] and
[mapping/disjoin]


These two were meant to have reversed reasons.


Hmm, because you are doing it wrong?  Try this:

1. create a single place to store externals, I recommend ~/pd- 
externals/

2. add it to your path
3. cd /path/to/pure-data/trunk/abstractions/
4. cp -a purepd ~/pd-externals

(mapping is still poorly organized in SVN, so its a bit harder)

5. cd /path/to/pure-data/trunk/externals/mapping
6. mkdir ~/pd-externals/mapping
7. cp -a *.pd ~/pd-externals/mapping
8. cd help
9. cp -a *-help.pd ~/pd-externals/mapping
10. touch ~/pd-externals/mapping/mapping-meta.pd

That's it.  Then if you have the libdir.pd_linux loader loaded, you  
can also load that as a lib using any of the standard methods.   
(you'll need the libdir.c from SVN).


pd -lib libdir -lib mapping
declare -lib mapping
import mapping

.hc



As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously. - Benjamin Franklin




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




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


Re: [PD] mapping: path setting hell

2009-04-07 Thread cyrille henry



Luigi a écrit :

Hey List.
not wanting to offend anybody. But this has some good amount of 
absurdity in it, i think.

And for any Newbie following that its actually quite frightening.

Frank calls his way of doing hell and it only includes 3 steps.

it's not the steps the problem, the problem come from what is imply by this 
step.


And Hans Christoph calls his way easy and it includes 10 steps 


;-)


 monster monster-hell..

Another thing i always found strange about tthe mapping-collection. If 
you want to use the helpfiles
in one of your patches and actually use more then one you get into 
conflicts

i don't understand what you want to do, can you elaborate?



What needs to be done to restructure mapping ?? I could help maybe, 
because its a library i used very often and found

it very useful. I would be happy to do something good to that library ;-)


the problem is not human resource for restructuring this lib.

it's just that Franck and I did not share the same way of thinking than hans.

Cyrille



All the Best

Luigi

Am 06.04.2009 um 15:58 schrieb Hans-Christoph Steiner:



On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:


Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:


1) SVN/externals - otherwise [center_point] isn't found
2) SVN/externals/mapping - to find [mapping/reverse] and
[mapping/disjoin]


These two were meant to have reversed reasons.


Hmm, because you are doing it wrong?  Try this:

1. create a single place to store externals, I recommend ~/pd-externals/
2. add it to your path
3. cd /path/to/pure-data/trunk/abstractions/
4. cp -a purepd ~/pd-externals

(mapping is still poorly organized in SVN, so its a bit harder)

5. cd /path/to/pure-data/trunk/externals/mapping
6. mkdir ~/pd-externals/mapping
7. cp -a *.pd ~/pd-externals/mapping
8. cd help
9. cp -a *-help.pd ~/pd-externals/mapping
10. touch ~/pd-externals/mapping/mapping-meta.pd

That's it.  Then if you have the libdir.pd_linux loader loaded, you 
can also load that as a lib using any of the standard methods.  
(you'll need the libdir.c from SVN).


pd -lib libdir -lib mapping
declare -lib mapping
import mapping

.hc

 



As we enjoy great advantages from inventions of others, we should be 
glad of an opportunity to serve others by any invention of ours; and 
this we should do freely and generously. - Benjamin Franklin




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





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




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


Re: [PD] mapping: path setting hell

2009-04-07 Thread Hans-Christoph Steiner


Yes, there is some absurdity to this conversation.  I guess Frank and  
I have been doing this for so long, its just part of a game we play ;-)


Anyway, I could give the instructions in one step:

1. use Pd-extended ;-)

I don't think many newbies really want to get into the nitty-gritty of  
hand-built Pd installs, but this conversation did make me smooth out  
the installation process.  Before, the 10 steps were for creating a  
library from scratch.  I think its pretty simple considering.  Now,  
the libraries are pre-built in SVN, so you only need to:


1. cd /path/to/your/extra (or wherever you want to install stuff)
2. svn co 
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mapping
3. svn co 
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/purepd
4. pd -lib libdir -lib purepd -lib mapping

If that doesn't work for you, there is a bug.  That has been working  
with Pd-extended for some years now.  As for issues with this setup,  
please elaborate on them so we can fix things.


.hc

On Apr 6, 2009, at 10:37 AM, Luigi wrote:


Hey List.
	not wanting to offend anybody. But this has some good amount of  
absurdity in it, i think.

And for any Newbie following that its actually quite frightening.

Frank calls his way of doing hell and it only includes 3 steps.
And Hans Christoph calls his way easy and it includes 10 steps 

 monster monster-hell..

Another thing i always found strange about tthe mapping-collection.  
If you want to use the helpfiles
in one of your patches and actually use more then one you get into  
conflicts


What needs to be done to restructure mapping ?? I could help maybe,  
because its a library i used very often and found
it very useful. I would be happy to do something good to that  
library ;-)


All the Best

Luigi

Am 06.04.2009 um 15:58 schrieb Hans-Christoph Steiner:



On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:


Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:


1) SVN/externals - otherwise [center_point] isn't found
2) SVN/externals/mapping - to find [mapping/reverse] and
[mapping/disjoin]


These two were meant to have reversed reasons.


Hmm, because you are doing it wrong?  Try this:

1. create a single place to store externals, I recommend ~/pd- 
externals/

2. add it to your path
3. cd /path/to/pure-data/trunk/abstractions/
4. cp -a purepd ~/pd-externals

(mapping is still poorly organized in SVN, so its a bit harder)

5. cd /path/to/pure-data/trunk/externals/mapping
6. mkdir ~/pd-externals/mapping
7. cp -a *.pd ~/pd-externals/mapping
8. cd help
9. cp -a *-help.pd ~/pd-externals/mapping
10. touch ~/pd-externals/mapping/mapping-meta.pd

That's it.  Then if you have the libdir.pd_linux loader loaded, you  
can also load that as a lib using any of the standard methods.   
(you'll need the libdir.c from SVN).


pd -lib libdir -lib mapping
declare -lib mapping
import mapping

.hc



As we enjoy great advantages from inventions of others, we should  
be glad of an opportunity to serve others by any invention of ours;  
and this we should do freely and generously. - Benjamin  
Franklin




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




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






  ¡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] mapping: path setting hell

2009-04-07 Thread Hans-Christoph Steiner


On Apr 6, 2009, at 11:26 AM, Frank Barknecht wrote:


Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:



On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:


Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:


1) SVN/externals - otherwise [center_point] isn't found
2) SVN/externals/mapping - to find [mapping/reverse] and
 [mapping/disjoin]


These two were meant to have reversed reasons.


Hmm, because you are doing it wrong?


I'm not doing it wrong, it works fine.

But because mapping is sometimes using prefixes internally,  
sometimes not (you

get [float_argument] and [purepd/float_argument] or [reverse] and
[mapping/reverse]) this results in users having to add twice the  
amount of

paths or imports.


Inside of the objects themselves, I use always the [mapping/reverse]  
form.  Only in the help patches do I use the [reverse] form.  That  
convention seemed to make sense at the time, but I am not married to it.


.hc




Ciao
--
Frank

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






  http://at.or.at/hans/



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


Re: [PD] mapping: path setting hell

2009-04-07 Thread Frank Barknecht
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

 Yes, there is some absurdity to this conversation.  I guess Frank and I 
 have been doing this for so long, its just part of a game we play ;-)

 Anyway, I could give the instructions in one step:

 1. use Pd-extended ;-)

But that's exactly what I mean: mapping IMO has become promotion material for
pd-extended, but increasingly hard to use for users of newer Pd versions or
alternative distributions.

 I don't think many newbies really want to get into the nitty-gritty of  
 hand-built Pd installs, but this conversation did make me smooth out the 
 installation process.  Before, the 10 steps were for creating a library 
 from scratch.  I think its pretty simple considering.  Now, the libraries 
 are pre-built in SVN, so you only need to:

 1. cd /path/to/your/extra (or wherever you want to install stuff)
 2. svn co 
 http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mapping
 3. svn co 
 http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/purepd
 4. pd -lib libdir -lib purepd -lib mapping

You cheat a bit here: svn co whereverlibdiris; make libdir, and I don't know,
if help-files in mapping work then - with just your sets they won't. And you
still have the requirement of putting the directories mapping and purepd into a
directory in the pd path like extra, so it's still four paths to set, just
like I wrote in my first mail.

Ciao
-- 
Frank

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


Re: [PD] mapping: path setting hell

2009-04-07 Thread Hans-Christoph Steiner


On Apr 8, 2009, at 1:18 AM, Frank Barknecht wrote:


Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

Yes, there is some absurdity to this conversation.  I guess Frank  
and I

have been doing this for so long, its just part of a game we play ;-)

Anyway, I could give the instructions in one step:

1. use Pd-extended ;-)


But that's exactly what I mean: mapping IMO has become promotion  
material for
pd-extended, but increasingly hard to use for users of newer Pd  
versions or

alternative distributions.

I don't think many newbies really want to get into the nitty-gritty  
of
hand-built Pd installs, but this conversation did make me smooth  
out the
installation process.  Before, the 10 steps were for creating a  
library
from scratch.  I think its pretty simple considering.  Now, the  
libraries

are pre-built in SVN, so you only need to:

1. cd /path/to/your/extra (or wherever you want to install stuff)
2. svn co 
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mapping
3. svn co 
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/purepd
4. pd -lib libdir -lib purepd -lib mapping


You cheat a bit here: svn co whereverlibdiris; make libdir, and I  
don't know,
if help-files in mapping work then - with just your sets they won't.  
And you
still have the requirement of putting the directories mapping and  
purepd into a
directory in the pd path like extra, so it's still four paths to  
set, just

like I wrote in my first mail.


How about checking whether help files work before reporting the  
problem?  You only need to install libdir once.  Plus if you use the  
latest version of libdir, then 'extra' can be any folder in the path.   
I suggest one of these:


http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with-pd-extended

.hc




Ciao
--
Frank

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







You can't steal a gift. Bird gave the world his music, and if you can  
hear it, you can have it. - Dizzy Gillespie





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


Re: [PD] mapping: path setting hell

2009-04-07 Thread Frank Barknecht
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

 You cheat a bit here: svn co whereverlibdiris; make libdir, and I  don't
 know, if help-files in mapping work then - with just your sets they won't.
 And you still have the requirement of putting the directories mapping and
 purepd into a directory in the pd path like extra, so it's still four
 paths to  set, just like I wrote in my first mail.

 How about checking whether help files work before reporting the problem?  

I wrote I don't know if helpp-files work - but I've tried it now.

 You only need to install libdir once.  Plus if you use the latest version 
 of libdir, then 'extra' can be any folder in the path.  I suggest one of 
 these:

 http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with-pd-extended

Okay, here's what I did: 

$ cp -a SVN/mapping /usr/lib/pd/extra
$ cd SVN/loaders
$ svn update
$ make (to make libdir.pd_linux)
$ pd -lib libdir -lib mapping

gives this:
...
libdir loader $Revision: 1.8 $
compiled on Apr  8 2009 at 07:46:59
compiled against Pd version 0.42.4.
mapping: can't load library
...

and I still cannot create any mapping object. I was able to fix that by adding
a mapping-meta.pd file manually (copied from some pd-extended source on my
disk, could find one in SVN's trunk). Help files still don't work.

According to http://puredata.info/docs/developer/Libdir help-files have to be
either in 5.reference/libname or next to the object in question. Both is not
the case the way mapping is laid out and again something, that has to be done
manually.

That's all pretty complicated for a newbie like me. :)

Ciao
-- 
Frank

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


Re: [PD] mapping: path setting hell

2009-04-06 Thread Frank Barknecht
Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:

 1) SVN/externals - otherwise [center_point] isn't found
 2) SVN/externals/mapping - to find [mapping/reverse] and
[mapping/disjoin]

These two were meant to have reversed reasons.

Ciao
-- 
Frank

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


Re: [PD] mapping: path setting hell

2009-04-06 Thread cyrille henry



Hans-Christoph Steiner a écrit :


On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:


Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:


1) SVN/externals - otherwise [center_point] isn't found
2) SVN/externals/mapping - to find [mapping/reverse] and
  [mapping/disjoin]


These two were meant to have reversed reasons.


Hmm, because you are doing it wrong? 

no, because mapping is doing it wrong.
i'm more and more convinced that the only way i now have to use the object that 
i write is to fork this lib.
it's a bad solution for everybody, but at last i'll be able to profit from my 
work.

Cyrille

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


Re: [PD] mapping: path setting hell

2009-04-06 Thread Frank Barknecht
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:


 On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:

 Hallo,
 Frank Barknecht hat gesagt: // Frank Barknecht wrote:

 1) SVN/externals - otherwise [center_point] isn't found
 2) SVN/externals/mapping - to find [mapping/reverse] and
   [mapping/disjoin]

 These two were meant to have reversed reasons.

 Hmm, because you are doing it wrong?  

I'm not doing it wrong, it works fine.

But because mapping is sometimes using prefixes internally, sometimes not (you
get [float_argument] and [purepd/float_argument] or [reverse] and
[mapping/reverse]) this results in users having to add twice the amount of
paths or imports.

Ciao
-- 
Frank

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