hi.
i am looking for a simple and efficient way to record a Pd-session and replay it later. at this early stage i am only interested in replaying the gui part, so basically i want to create a screencast, but without recording a movie.
the idea is, to just capture the network traffic between pd and pd-gui and later feed the traffic pd->gui traffic into a standalone pd-gui.
i am currently experimenting a bit with pcap files (since packet sniffers do not require any intervention on the Pd side), but of course the result is quite verbose and i am not really interested in the tcp/ip handshake between pd and pd-gui. all the available pcap replay tools i found (e.g. tcpreplay) are really tools for testing network infrastructure rather than replaying client/server communication.
my self written tools suffer from big timing issues...
any hints?
fgmasdr IOhannes
On Tue, Dec 02, 2008 at 10:59:04AM +0100, IOhannes m zmoelnig wrote:
i am looking for a simple and efficient way to record a Pd-session and replay it later. at this early stage i am only interested in replaying the gui part, so basically i want to create a screencast, but without recording a movie.
the idea is, to just capture the network traffic between pd and pd-gui and later feed the traffic pd->gui traffic into a standalone pd-gui.
i am currently experimenting a bit with pcap files (since packet sniffers do not require any intervention on the Pd side), but of course the result is quite verbose and i am not really interested in the tcp/ip handshake between pd and pd-gui. all the available pcap replay tools i found (e.g. tcpreplay) are really tools for testing network infrastructure rather than replaying client/server communication.
my self written tools suffer from big timing issues...
Hi IOhannes,
You will almost certainly not like this solution, but you can use my [s-totalrecall] and [s-tr-node] abstractions to record a full session of knob-twiddling to play back later. I use this to record my live sets and then replay them later, off-stage.
Chris.
Chris McCormick wrote:
Hi IOhannes,
You will almost certainly not like this solution, but you can use my [s-totalrecall] and [s-tr-node] abstractions to record a full session of knob-twiddling to play back later. I use this to record my live sets and then replay them later, off-stage.
thanks for mentioning these. indeed they are not what i want. i want to capture a live-coding session rather than "knob-fiddling".
but anyhow, thanks.
i noticed that both abstractions are missing from the puredata repository at sourceforge. after some googling i found your own repo at http://mccormick.cx.
is there any chance to sync the two repositories? (personally i would still suggest an svn:externals link; but let's keep this for later :-))
gfmasdr IOhannes
On Tue, Dec 02, 2008 at 12:17:44PM +0100, IOhannes m zmoelnig wrote:
Chris McCormick wrote:
You will almost certainly not like this solution, but you can use my [s-totalrecall] and [s-tr-node] abstractions to record a full session of knob-twiddling to play back later. I use this to record my live sets and then replay them later, off-stage.
thanks for mentioning these. indeed they are not what i want. i want to capture a live-coding session rather than "knob-fiddling".
Oh I see what you mean. Cool idea!
i noticed that both abstractions are missing from the puredata repository at sourceforge. after some googling i found your own repo at http://mccormick.cx.
is there any chance to sync the two repositories? (personally i would still suggest an svn:externals link; but let's keep this for later :-))
I did have an out-of-date copy of my own s-abstractions repository in the CVS that I would periodically check-in, but I have been really bad at keeping track of whether that still exists in the new SVN layout, or even how to import it now. I sort of made enquiries about this but Hans replied something like "Don't do this unless it's a library." Which I never fully grokked. I agree that an svn:externals link would be a good solution.
Best,
Chris.
On Dec 2, 2008, at 6:36 AM, Chris McCormick wrote:
On Tue, Dec 02, 2008 at 12:17:44PM +0100, IOhannes m zmoelnig wrote:
Chris McCormick wrote:
You will almost certainly not like this solution, but you can use my [s-totalrecall] and [s-tr-node] abstractions to record a full
session of knob-twiddling to play back later. I use this to record my live
sets and then replay them later, off-stage.thanks for mentioning these. indeed they are not what i want. i want to capture a live-coding
session rather than "knob-fiddling".Oh I see what you mean. Cool idea!
i noticed that both abstractions are missing from the puredata repository at sourceforge. after some googling i found your own repo at http://mccormick.cx.
is there any chance to sync the two repositories? (personally i would still suggest an svn:externals link; but let's
keep this for later :-))I did have an out-of-date copy of my own s-abstractions repository in the CVS that I would periodically check-in, but I have been really bad at keeping track of whether that still exists in the new SVN
layout, or even how to import it now. I sort of made enquiries about this but
Hans replied something like "Don't do this unless it's a library." Which I never fully grokked. I agree that an svn:externals link would be a
good solution.
I really don't want to dictate here, but I think we need to decide on
how we use the SVN. svn:externals create more annoying work in
regards to getting Pd-extended builds out, but that is not the only
use of the SVN. I can accept more annoying work, but there needs to
be a good reason.
My question remains, what is the problem we are trying to solve using
svn:externals? If it is to include code that gets built with Pd-
extended, then svn:externals doesn't work well for that, just
importing releases works much better. If it is to make a centralized
place to find all Pd code, then I wonder if there is a better tool
for this, like a special section of SVN for svn:externals outside of
trunk or a wiki page.
I think it's time to have a IRC meeting about this. How about
Thursday? I am trying to be in #dataflow as much as possible these
days, if anyone wants to have an impromptu discussion.
irc://irc.freenode.net/dataflow
.hc
Best,
Chris.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Hans-Christoph Steiner wrote:
On Dec 2, 2008, at 6:36 AM, Chris McCormick wrote:
is there any chance to sync the two repositories? (personally i would still suggest an svn:externals link; but let's
keep this for later :-))
sorry for re-starting the flame-war. it was not my intention but couldn't keep my mouth shut.
I really don't want to dictate here, but I think we need to decide on
how we use the SVN. svn:externals create more annoying work in
regards to getting Pd-extended builds out, but that is not the only
use of the SVN. I can accept more annoying work, but there needs to
be a good reason.My question remains, what is the problem we are trying to solve using
svn:externals? If it is to include code that gets built with Pd- extended, then svn:externals doesn't work well for that, just
importing releases works much better.
this is the main point where i disagree. most Pd-libraries seem to have stopped doing a regular release-cycle. for those included in Pd-extended, this is most likely due to their inclusion in Pd-extended. other libraries do not have a release cycle too, esp. if they are under some kind of public avaible version control system. the reason remains unknown, but i guess for most of these their upstream author consider release cycles for a "minor" library to much of a hazzle.
i totally understand e.g. chris, if he doesn't want to re-import a new version of s-abstractions just because he has added 2 objects. (this is jut my interpretation)
but nevertheless: s-abstractions are in our svn, chris pointed me to s-totalrecall.pd which i thought (rightfully) to be part of s-abstractions (without having ever had a look at this library), i checked whether this lib is in my checkout of the repo (which it is) and i couldn't find the very object. assuming that chris hadn't made fun of me, i checked the logfiles of s-abstractions and noted that there was only a initial submit. i decided to search for the library on other places (using google) and eventually found the upstream repository.
i think such "workflow" does more harm than not.
I think it's time to have a IRC meeting about this. How about
Thursday? I am trying to be in #dataflow as much as possible these
days, if anyone wants to have an impromptu discussion.
i'm at piksel right now, so i will not be able to attend any meeting in this week,
mfga.r IOhannes
On Dec 3, 2008, at 11:56 AM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
On Dec 2, 2008, at 6:36 AM, Chris McCormick wrote:
is there any chance to sync the two repositories? (personally i would still suggest an svn:externals link; but let's keep this for later :-))
sorry for re-starting the flame-war. it was not my intention but couldn't keep my mouth shut.
I really don't want to dictate here, but I think we need to decide on how we use the SVN. svn:externals create more annoying work in regards to getting Pd-extended builds out, but that is not the only use of the SVN. I can accept more annoying work, but there needs to be a good reason.
My question remains, what is the problem we are trying to solve using svn:externals? If it is to include code that gets built with Pd- extended, then svn:externals doesn't work well for that, just importing releases works much better.
this is the main point where i disagree. most Pd-libraries seem to have stopped doing a regular release-cycle. for those included in Pd-extended, this is most likely due to their inclusion in Pd-extended. other libraries do not have a release cycle too, esp. if they are
under some kind of public avaible version control system. the reason remains unknown, but i guess for most of these their upstream author consider release cycles for a "minor" library to much of a hazzle.i totally understand e.g. chris, if he doesn't want to re-import a new version of s-abstractions just because he has added 2 objects. (this is jut my interpretation)
but nevertheless: s-abstractions are in our svn, chris pointed me to s-totalrecall.pd which i thought (rightfully) to be part of s-abstractions (without having ever had a look at this library), i checked whether this lib is in my checkout of the repo (which it
is) and i couldn't find the very object. assuming that chris hadn't made fun of me, i checked the logfiles of s-abstractions and noted that there was only a initial submit. i decided to search for the library on other places (using google) and eventually found the upstream repository.i think such "workflow" does more harm than not.
If you don't like this workflow you don't have to use it. For Pd-
extended, there needs to be little changes to makes sure everything
works together, so svn:externals does not work for that. If you
don't care about Pd-extended, then you don't need to import code into
the SVN there.
I think a reasonable solution to this is to make a section of the
svn, like pure-data/svn-externals, where everyone is free to add
links to there repos. That way people use svn-externals as much as
they want, and changes in their repos don't break the automatic
nightly builds.
.hc
I think it's time to have a IRC meeting about this. How about Thursday? I am trying to be in #dataflow as much as possible these days, if anyone wants to have an impromptu discussion.
i'm at piksel right now, so i will not be able to attend any
meeting in this week,mfga.r IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
Hans-Christoph Steiner wrote:
i think such "workflow" does more harm than not.
If you don't like this workflow you don't have to use it. For
what the...?
i am describing a real-world problem and the only answer you have to it is: "if you don't like it, don't use it"?
Pd-extended, there needs to be little changes to makes sure everything works together, so svn:externals does not work for that. If you don't care about Pd-extended, then you don't need to import code into the SVN there.
where? into Pd-extended? i don't-
I think a reasonable solution to this is to make a section of the svn, like pure-data/svn-externals, where everyone is free to add links to there repos. That way people use svn-externals as much as they want, and changes in their repos don't break the automatic nightly builds.
people who can add links to external repositories can as well add broken code directly, so this is no argument.
the only real drawback about svn:externals is (and we've had this already), that people are using self-signed certificates which stops the build-process (because you cannot tell svn to blindly accept an invalid certificate)
oh, btw, if you don't like svn:externals, just don't check them out: luckily there is the "--ignore-externals" flag.
fgmasr IOhannes
.hc
Hi Hans,
On Tue, Dec 02, 2008 at 12:41:46PM -0500, Hans-Christoph Steiner wrote:
I think it's time to have a IRC meeting about this. How about
Thursday? I am trying to be in #dataflow as much as possible these
days, if anyone wants to have an impromptu discussion.
I am happy to meet on IRC, but it will have to be outside work hours for me here at GMT. Otherwise the weekend is good, but I think maybe this is something that can be solve on-list. I really think you hit the nail on the head with this paragraph:
My question remains, what is the problem we are trying to solve using
svn:externals? If it is to include code that gets built with Pd- extended, then svn:externals doesn't work well for that, just
importing releases works much better. If it is to make a centralized
place to find all Pd code, then I wonder if there is a better tool
for this, like a special section of SVN for svn:externals outside of
trunk or a wiki page.
Can you answer me this: do you see the primary function of Pd public SVN as supporting pd-extended builds? If this is the case, then we need a different part of the repository where external writers and abstraction creators can store their code/patches independent of pd-extended. The reason we need this is that whilst pd-extended is a wonderful project, and definately neccessary, not everyone in the Pd world runs it and probably some people aren't even interested in seeing their work as part of pd-extended, but they are definately interested in participating in the development community of Pd. We can't just have a wiki page as that doesn't suffice for people who want their code versioned inside the world of Pd code but aren't interested in pd-extended.
What about if SVN was the central place where Pd and related code lives, and there was a sub-place within that where pd-extended keeps its source? Most definately snapshots/tags of the former could be copied via standard svn commands into the latter to make them part of pd-extended at stable release. This would probably help with co-ordinating and versioning too. You could tell people "we are coming up for a pd-extended release, please copy your latest tags into the pd-extended folder" or do this yourself for code that you maintain. I guess the crux of what I'm saying is that I don't see the Pd svn trunk as being == to pd-extended. I see pd-extended as being a part of the ecosystem living in the svn trunk. I don't think it's fair for one project to be 100% the boss of trunk. In fact, I find it kind of annoying that once upon a time I could check out people's code from the svn and compile it independently, whereas last time I tried I couldn't do it as a bunch of environment variables weren't set and stuff. I had to hack giant complicated makefiles just to compile one simple external.
Please excuse me if I've missed anything obvious or said anything stupid, and feel free to correct me if I am misguided or wrong about the position of pd-extended in the repository. Maybe it's all just semantics. But I guess semantics are important in human communities.
Loving the broken paradise, :)
Chris.
On Dec 3, 2008, at 6:19 PM, Chris McCormick wrote:
Hi Hans,
On Tue, Dec 02, 2008 at 12:41:46PM -0500, Hans-Christoph Steiner
wrote:I think it's time to have a IRC meeting about this. How about Thursday? I am trying to be in #dataflow as much as possible these days, if anyone wants to have an impromptu discussion.
I am happy to meet on IRC, but it will have to be outside work
hours for me here at GMT. Otherwise the weekend is good, but I think maybe
this is something that can be solve on-list. I really think you hit the
nail on the head with this paragraph:My question remains, what is the problem we are trying to solve using svn:externals? If it is to include code that gets built with Pd- extended, then svn:externals doesn't work well for that, just importing releases works much better. If it is to make a centralized place to find all Pd code, then I wonder if there is a better tool for this, like a special section of SVN for svn:externals outside of trunk or a wiki page.
Can you answer me this: do you see the primary function of Pd
public SVN as supporting pd-extended builds? If this is the case, then we need a different part of the repository where external writers and
abstraction creators can store their code/patches independent of pd-extended. The reason we need this is that whilst pd-extended is a wonderful project, and definately neccessary, not everyone in the Pd world runs it and probably some people aren't even interested in seeing their work as
part of pd-extended, but they are definately interested in participating in the development community of Pd. We can't just have a wiki page as
that doesn't suffice for people who want their code versioned inside the world of Pd code but aren't interested in pd-extended.What about if SVN was the central place where Pd and related code
lives, and there was a sub-place within that where pd-extended keeps its source? Most definately snapshots/tags of the former could be
copied via standard svn commands into the latter to make them part of pd-extended at stable release. This would probably help with co-ordinating and versioning too. You could tell people "we are coming up for a pd-extended release, please copy your latest tags into the pd-extended folder" or do this yourself for code that you maintain. I guess the
crux of what I'm saying is that I don't see the Pd svn trunk as being == to pd-extended. I see pd-extended as being a part of the ecosystem living in the svn trunk. I don't think it's fair for one project to be
100% the boss of trunk. In fact, I find it kind of annoying that once upon a
time I could check out people's code from the svn and compile it independently, whereas last time I tried I couldn't do it as a
bunch of environment variables weren't set and stuff. I had to hack giant complicated makefiles just to compile one simple external.Please excuse me if I've missed anything obvious or said anything stupid, and feel free to correct me if I am misguided or wrong
about the position of pd-extended in the repository. Maybe it's all just semantics. But I guess semantics are important in human communities.Loving the broken paradise, :)
I don't think anyone is saying that pure-data SVN == pd-extended,
plus I don't think anyone is saying that it should be that way. My
objection to svn:externals comes from the fact that I have to do a
lot of annoying work to manage the Pd-extended builds, and so far
svn:externals has only made that worse.
I don't know about svn --ignore-externals, anyone care to expand on
that? (yes, I can RTFM, but I am talking real world experience as
related to Pd, which TFM will not tell me) What about the idea of
having a separate section like /pure-data/svn-externals? If people
object to having the imported releases in trunk, I can easily manage
that in the pd-extended branch.
.hc
Chris.
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
Hans-Christoph Steiner wrote:
On Dec 3, 2008, at 6:19 PM, Chris McCormick wrote:
I don't know about svn --ignore-externals, anyone care to expand on
that? (yes, I can RTFM, but I am talking real world experience as
related to Pd, which TFM will not tell me)
hmm, "--ignore-externals" ignores external-references when doing a checkout/update.
probably a small real-world example can illustrate the use of "--ignore-externals".
one of the projects i am involved in, is the CUBEmixer, basically a big Pd-application. it depends on a few externals, hosted in the pure-data repository.
if you run % svn checkout https://svn.sourceforge.net/svnroot/iem/spatialization/CUBEmixer/trunk/src/l... you will get this directories (1st level): libs/ libs/popup libs/folder_list libs/hdspm_mixer libs/aconnect libs/hcs libs/iem_ambi libs/iem_bin_ambi libs/iemgui libs/iem_spec2 libs/iemlib libs/iemmatrix libs/miXed libs/osc libs/net libs/zexy
however, if you don't care for all the external references, you could do instead: % svn checkout --ignore-externals https://svn.sourceforge.net/svnroot/iem/spatialization/CUBEmixer/trunk/src/l... you will only get: libs/ libs/popup libs/folder_list
so when using the "--ignore-externals" you can checkout a repository as if there were no svn:external properties set in this repo.
What about the idea of
having a separate section like /pure-data/svn-externals? If people
object to having the imported releases in trunk, I can easily manage
that in the pd-extended branch.
to reiterate: i believe that nobody objects to having releases imported. the problem is that people do not make releases that could be imported.
and whatever you can easily manage, has to be managed by you; i don't want to add another piece of work to your heap.
mfga.r IOhannes
On Dec 4, 2008, at 6:10 AM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
On Dec 3, 2008, at 6:19 PM, Chris McCormick wrote:
I don't know about svn --ignore-externals, anyone care to expand on that? (yes, I can RTFM, but I am talking real world experience as related to Pd, which TFM will not tell me)
hmm, "--ignore-externals" ignores external-references when doing a checkout/update.
probably a small real-world example can illustrate the use of "--ignore-externals".
one of the projects i am involved in, is the CUBEmixer, basically a
big Pd-application. it depends on a few externals, hosted in the pure-data repository.if you run % svn checkout https://svn.sourceforge.net/svnroot/iem/spatialization/CUBEmixer/ trunk/src/libs you will get this directories (1st level): libs/ libs/popup libs/folder_list libs/hdspm_mixer libs/aconnect libs/hcs libs/iem_ambi libs/iem_bin_ambi libs/iemgui libs/iem_spec2 libs/iemlib libs/iemmatrix libs/miXed libs/osc libs/net libs/zexy
however, if you don't care for all the external references, you
could do instead: % svn checkout --ignore-externals https://svn.sourceforge.net/svnroot/iem/spatialization/CUBEmixer/ trunk/src/libs you will only get: libs/ libs/popup libs/folder_listso when using the "--ignore-externals" you can checkout a
repository as if there were no svn:external properties set in this repo.
If someone will set this up and manage it when things break, then I
will have no (major) complaints.
What about the idea of having a separate section like /pure-data/svn-externals? If people object to having the imported releases in trunk, I can easily manage that in the pd-extended branch.
to reiterate: i believe that nobody objects to having releases
imported. the problem is that people do not make releases that could be
imported.and whatever you can easily manage, has to be managed by you; i don't want to add another piece of work to your heap.
What about the idea of having a separate section like /pure-data/svn- externals?
.hc
mfga.r IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[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
On Fri, Dec 05, 2008 at 01:06:32AM -0500, Hans-Christoph Steiner wrote:
What about the idea of having a separate section like /pure-data/svn- externals?
I like that as it would solve my immdiate problem of people finding out of date s-abstractions in the pd repo and not require me to do periodic imports. Let's hope people don't get confused between "externals" and "externals".
Best,
Chris.
On Dec 5, 2008, at 5:49 AM, Chris McCormick wrote:
On Fri, Dec 05, 2008 at 01:06:32AM -0500, Hans-Christoph Steiner
wrote:What about the idea of having a separate section like /pure-data/svn- externals?
I like that as it would solve my immdiate problem of people finding
out of date s-abstractions in the pd repo and not require me to do
periodic imports. Let's hope people don't get confused between "externals" and "externals".
Also, it would be nice to see versioned releases of your code as
libdirs. That would be easy to do, easy to use, and versioned
releases are a tried-n-true method of managing changing libraries.
.hc
Best,
Chris.
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
Chris McCormick wrote:
On Fri, Dec 05, 2008 at 01:06:32AM -0500, Hans-Christoph Steiner wrote:
What about the idea of having a separate section like /pure-data/svn- externals?
hmm, i'm trying (not so) hard to remove the ./abstractions folder in favour of a grand unified ./externals folder...
in some other projects i noticed "packages" which are modules containing both the local code plus dependencies (the latter handled solely via svn:externals)
I like that as it would solve my immdiate problem of people finding out of date s-abstractions in the pd repo and not require me to do periodic imports. Let's hope people don't get confused between "externals" and "externals".
at least i keep getting confused when talking about them :-) that's why i always use svn:externals...
fgamdr IOhannes
On Dec 12, 2008, at 3:44 PM, IOhannes m zmölnig wrote:
Chris McCormick wrote:
On Fri, Dec 05, 2008 at 01:06:32AM -0500, Hans-Christoph Steiner
wrote:What about the idea of having a separate section like /pure-data/ svn- externals?
hmm, i'm trying (not so) hard to remove the ./abstractions folder in favour of a grand unified ./externals folder...
That will take a lot of political organizing, as we saw before. In
the mean time, I don't see much harm in having /pure-data/svn-externals
in some other projects i noticed "packages" which are modules
containing both the local code plus dependencies (the latter handled solely via svn:externals)
Using svn:externals for dependencies means that using --ignore- externals would then break. Do you have an example of such a project?
I am currently using OpenEmbedded a lot for the Reware ARM disk
images. OpenEmbedded tracks hundreds of external projects. It uses
git, which has nothing like svn:externals. Instead, the build
system, bitbake, which handles downloading the source code to
package. If we really want to make a distributed build system, then
someone should build it from bitbake or some other proven tool, not
kludge it with svn:externals.
.hc
I like that as it would solve my immdiate problem of people
finding out of date s-abstractions in the pd repo and not require me to do
periodic imports. Let's hope people don't get confused between "externals" and "externals".at least i keep getting confused when talking about them :-) that's why i always use svn:externals...
fgamdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
Hans-Christoph Steiner wrote:
On Dec 12, 2008, at 3:44 PM, IOhannes m zmölnig wrote:
Chris McCormick wrote:
On Fri, Dec 05, 2008 at 01:06:32AM -0500, Hans-Christoph Steiner wrote:
What about the idea of having a separate section like /pure-data/svn- externals?
hmm, i'm trying (not so) hard to remove the ./abstractions folder in favour of a grand unified ./externals folder...
That will take a lot of political organizing, as we saw before. In the mean time, I don't see much harm in having /pure-data/svn-externals
i am more a fan of gradual migration than of sudden switches. this allows people to adapt changes at their own pace. sometimes it is a bit hard to do (e.g. when migrating from cvs to svn), othertimes it is simpler. if we agree that it might be a good idea to merge ./abstractions and ./externals because all of them contain "external objects" (as explained in your other mail), then i don't see a reason to introduce yet another directory that has to be migrated when the time is nigh.
in some other projects i noticed "packages" which are modules containing both the local code plus dependencies (the latter handled solely via svn:externals)
Using svn:externals for dependencies means that using --ignore-externals would then break.
indeed it does!
the two things are unrelated; i was jus trying to add another viewpoint (though i might have forgotten that i already mentioned that). "packages" in this context meant small packages (e.g. "libraries") rather than te entire shebang.
Do you have an example of such a project?
I am currently using OpenEmbedded a lot for the Reware ARM disk images.
OpenEmbedded tracks hundreds of external projects. It uses git, which has nothing like svn:externals. Instead, the build system, bitbake, which handles downloading the source code to package. If we really want to make a distributed build system, then someone should build it from
i do not oppose to explicitely downloading external dependencies at all. via bitbat or whatever mechanism.
bitbake or some other proven tool, not kludge it with svn:externals.
however to claim that "bitbake" is a 'proven tool' opposed to the 'ugly kludge' "svn:externals" is a bit euphemistic. unless of course you compare all the millions of openembedded developers to the handful of people using subversion.
but anyhow: what do we want to solve with all this "external" stuff (be it pushed into the repo, pulled implicitly or pulled explicitly)? adding new "Pd-libraries" (1st level packages) or build-dependencies (2nd level packages). this 2 might well be handled differently.
fgmsdr IOhannes
On Dec 15, 2008, at 3:28 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Dec 12, 2008, at 3:44 PM, IOhannes m zmölnig wrote:
Chris McCormick wrote:
On Fri, Dec 05, 2008 at 01:06:32AM -0500, Hans-Christoph Steiner
wrote:What about the idea of having a separate section like /pure- data/svn- externals?
hmm, i'm trying (not so) hard to remove the ./abstractions folder in favour of a grand unified ./externals folder...
That will take a lot of political organizing, as we saw before.
In the mean time, I don't see much harm in having /pure-data/svn- externalsi am more a fan of gradual migration than of sudden switches. this
allows people to adapt changes at their own pace. sometimes it is a bit hard to do (e.g. when migrating from cvs to
svn), othertimes it is simpler. if we agree that it might be a good idea to merge ./abstractions
and ./externals because all of them contain "external objects" (as
explained in your other mail), then i don't see a reason to
introduce yet another directory that has to be migrated when the
time is nigh.in some other projects i noticed "packages" which are modules
containing both the local code plus dependencies (the latter handled solely
via svn:externals)Using svn:externals for dependencies means that using --ignore- externals would then break.
indeed it does!
the two things are unrelated; i was jus trying to add another
viewpoint (though i might have forgotten that i already mentioned
that). "packages" in this context meant small packages (e.g.
"libraries") rather than te entire shebang.Do you have an example of such a project? I am currently using OpenEmbedded a lot for the Reware ARM disk
images. OpenEmbedded tracks hundreds of external projects. It
uses git, which has nothing like svn:externals. Instead, the
build system, bitbake, which handles downloading the source code
to package. If we really want to make a distributed build system,
then someone should build it fromi do not oppose to explicitely downloading external dependencies at
all. via bitbat or whatever mechanism.bitbake or some other proven tool, not kludge it with svn:externals.
however to claim that "bitbake" is a 'proven tool' opposed to the
'ugly kludge' "svn:externals" is a bit euphemistic. unless of course you compare all the millions of openembedded
developers to the handful of people using subversion.
How many large integration projects are using svn:externals. That's
the real question. I've worked on a few, like WRT54G firmwares and
openembedded. The WRT stuff usually imports the code releases,
OpenEmbedded has a whole system of downloading the right versions
with automatic handling of mirrors.
but anyhow: what do we want to solve with all this "external" stuff
(be it pushed into the repo, pulled implicitly or pulled explicitly)? adding new "Pd-libraries" (1st level packages) or build- dependencies (2nd level packages). this 2 might well be handled differently.
I think it is a good idea to get rid of 'abstractions' and
'externals'. They should probably called 'libraries', or something
like that.
.hc
fgmsdr IOhannes
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
Hello Iohannes,
We use Open Time Line to record and edit a pd live session: http://dh7.free.fr/ http://sourceforge.net/projects/petale Basically it's an open source generalist sequencer in Java. It's a bit complex to run, but it's very flexible.
Maybe it'll suit your needs,
Nicolas
IOhannes m zmoelnig a écrit :
hi.
i am looking for a simple and efficient way to record a Pd-session and replay it later. at this early stage i am only interested in replaying the gui part, so basically i want to create a screencast, but without recording a movie.
the idea is, to just capture the network traffic between pd and pd-gui and later feed the traffic pd->gui traffic into a standalone pd-gui.
i am currently experimenting a bit with pcap files (since packet sniffers do not require any intervention on the Pd side), but of course the result is quite verbose and i am not really interested in the tcp/ip handshake between pd and pd-gui. all the available pcap replay tools i found (e.g. tcpreplay) are really tools for testing network infrastructure rather than replaying client/server communication.
my self written tools suffer from big timing issues...
any hints?
fgmasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Chris McCormick -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Nicolas Montgermont