storing deprecated code

Jun 13, 2006 at 11:22pm

storing deprecated code

Hello again.

I am involved in the cleanup of a patch, and am in the process of
clearing out sections of “dead” code. I wish to get this code out of
the way of the functional patch, but keep it on hand in case of a
rollback. Moving all of the code to a subpatch accomplishes most of
this, but the code is still “active” in the patch, as it uses sends and
receives. What would be *really* nice would be if there was a way to
quarantine this code, but still keep it within the patch.

Is there a way to do this, besides renaming all of the sends and
receives (of which there are many)? To “shutdown” code, but keep it
available within your patches? A Max version of “commenting things out”?

I don’t believe so, but perhaps someone has an idea…

Thanks.


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |

#26404
Jun 13, 2006 at 11:40pm

#78859
Jun 14, 2006 at 12:19am

That’s what I was looking for.

Thanks.


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |

#78860
Jun 14, 2006 at 12:45am

Actually, on second thought, this doesn’t work right.

But, I don’ t think there is any way to do what I want to do, so we’ll
call this a “feature request”.

Making an abstraction automatically means that the dead code is stored
*somewhere else*. I want it in a subpatcher, always within that patch.

There should be a way to “comment out” Max code, so that it isn’t active.

Sometimes Max feels like a Ferrari without windshield wipers…

b

#78861
Jun 14, 2006 at 9:33am

On 14 Jun 2006, at 01:45, Barry Threw wrote:

> Making an abstraction automatically means that the dead code is
> stored *somewhere else*. I want it in a subpatcher, always within
> that patch.

I don’t understand what you gain from this, except for the ability to
completely disable the code (messages, DSP, shared state, etc.). Why
do you want the dead code in the active patcher? Why not in some
other patcher (with the added feature of being able to completely
disable the latter, in case you want to copy/paste some code across)?

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com

#78862
Jun 14, 2006 at 5:56pm

If the deprecated code is in the active patcher then it moves with the
patcher, it is always available for rollback. You can disable
functionality, try to implement something in a new way, and then easily
revert. I’m not sure if you do much coding in a non-graphical world,
but commenting out sections isn’t just useful, its necessary during
development.

Could I copy and past the code somewhere else? Sure. But what are the
disadvantages to this? I have to have an organizational structure in
place that lets me remember where exactly the code went, and what I did
in place. *Especially* with a graphical programming language like Max,
orientation and placement is useful both pragmatically and as a mnemonic.

Is it impossible to manage deprecated code in another patcher? No.
It’s just a pain in the ass.

There are lots of features in Max that seem more superfluous than a
disable feature. I mean come on…imageburgers?

b


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |

#78863
Jun 14, 2006 at 6:13pm

On 14 juin 06, at 19:56, Barry Threw wrote:

> If the deprecated code is in the active patcher then it moves with
> the patcher, it is always available for rollback. You can disable
> functionality, try to implement something in a new way, and then
> easily revert. I’m not sure if you do much coding in a non-
> graphical world, but commenting out sections isn’t just useful, its
> necessary during development.

It sounds like it’s not the job of Max. You can use CVS, subversion
or whatever to do that.

> There are lots of features in Max that seem more superfluous than a
> disable feature. I mean come on…imageburgers?

imageburner. you’re kidding? is really useful to hide max boxes and
display something else… it just depends on what you do with Max.

Best,
ej

#78864
Jun 14, 2006 at 6:55pm

Quote: barry threw wrote on Wed, 14 June 2006 10:56
—————————————————-
> commenting out sections isn’t just useful, its necessary during development.

After years of working with Max and its “unique” methods, I have found that conceptualizing in more traditional ways within Max is extremely useful.

For example, I use very few sends and receives; instead, I use values to function like traditional variables. This ensures that I have the data that I want only when I want it (as opposed to whenever it is sent).

I also try to encapsulate as much as I can, with only one in and one out per patcher.

I find this much easier to debug large programs, and swap patchers/abstractions in and out.

#78865
Jun 14, 2006 at 7:19pm

On 14 Jun 2006, at 18:56, Barry Threw wrote:

> I’m not sure if you do much coding in a non-graphical world, but
> commenting out sections isn’t just useful, its necessary during
> development.

But you can do that in Max by deleting a patch cord.

It sounds as if you’re after something more heavyweight – in which
case a source control system might be appropriate – but, yes, a
feature to completely disable a chunk of a patcher would be useful in
various circumstances.

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com

#78866
Jun 14, 2006 at 8:46pm

These are all good ideas that everyone has had.

But as for version control…I’m looking for a scalpel and not a
sledgehammer. You wouldn’t tell a C programmer that they have to use
CVS and not comments.

It’s a moot point I guess.

The code is dead. Long live the code.


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |

#78867
Jun 14, 2006 at 8:48pm

> There are lots of features in Max that seem more superfluous than a
> disable feature. I mean come on…imageburgers?

very useful for windowed UI.

#78868
Jun 15, 2006 at 8:08am

On 14-Jun-2006, at 22:46, Barry Threw wrote:
> You wouldn’t tell a C programmer that they have to use CVS and not
> comments.

This is true enough. However, Max isn’t C.

One of the things Max *is*, is a graphical programming language. Off
hand, I cannot think of any GPL that supports something like the
commented-out code technique familiar from text-based PLs. But I
don’t claim to know all GPLs. Can anyone reading tell how any of
LabVIEW, CAGE, Reaktor, LogoBlocks, & Co. provide for this sort of
temporary disabling of blocks of code? Do they support it at all?

FTR, the way I’ve dealt with this situation is to make a duplicate of
the patcher in Finder, tag the date onto the duplicate’s file name,
and then return to the original to boldly delete whatever it is I
might want to come back to someday. I might even split an infinitive
while I’m at it.

Maybe less fine than a scalpel but not as brutal as a sledgehammer.

– P.

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter

iCE: Sequencing, Recording & |home | chez nous|
Interface Building for |bei uns | i nostri|
Max/MSP Extremely cool http://www.castine.de

http://www.dspaudio.com/

#78869
Jun 15, 2006 at 10:22am

Correct me if I’m misunderstanding, but isn’t this what gate is for?
Instead of deleting patch cords (or a subpatcher) add a [gate], even
a [gate 1 1], and you can turn on/off the flow of information to that
gate. I use that to “comment out” blocks of max code. As long as
you understand the right-to-left and top-to-bottom flow of
information in Max, it’s a very useful technique.

-Evan

#78870
Jun 15, 2006 at 11:55am

On 15-Jun-2006, at 12:22, evan.raskob [lists] wrote:
> Correct me if I’m misunderstanding, but isn’t this what gate is for?

This, like all the other suggestions made in this thread, are almost-
but-not-quite-exactly-the-same-thing as commenting out code. There
will be arguments for why your approach isn’t quite what someone else
wanted.

But if it works for you, great, and the more suggestions around for
temporarily disabling some processing flow, the better.

– P.

[Please cf the .sig from my previous post on this thread if you need it]

#78871
Jun 15, 2006 at 6:49pm

All of these things work with either small or mid sized patches just
fine. However, once your scale increases, and your development time
speeds up, these solutions just aren’t adequate.

What if you are brought in to work on another patch? What then?

Like all of these suggestions, they seem like workarounds to gain a
functionality that is needed, but not directly supported in the most
intuitive and least time consuming way.

b


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |

#78872
Jun 15, 2006 at 7:06pm

so the enable message doesnt work for what you are trying to do?
i checked out some of my pre-subpatch programs, it seems to work ok
for me, but i didnt use send/recieve objects…

what would dafna do?

#78873
Jun 15, 2006 at 7:24pm

Nah. It doesn’t stop sends and receives.

I guess to clarify, what I need is not to disable blocks of code
(because everyone is right when they say “just delete the patch cord”)
but a way to disable sends and receives.

b


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |

#78874
Jun 15, 2006 at 7:54pm

ok. now thats a different issue. solution… dont use sends and
receives… ;)

maybe make a special subpatch called [send_stuff] and another subpatch
called [recieve stuff]. design your on/off routine in there and make
them remotely assignable. then just paste-replace/find-replace these
subpatches over all your old send receive ojbects.

or brush up on scripting.

#78875
Jun 15, 2006 at 8:26pm

Good idea. I might actually start doing that in some of my patches.

However it is:
a) slower and less intuitive to disable
b) i don’t want to do this for the thousand some odd sends and receives
i have scattered around hundreds of windows.
c) it requires more machinery throughout the patch that i could do without
d) again, it is a hack to create useful functionality that should be
natively supported in the development environment

It is, however, something I hadn’t really thought of…Thanks for that.
There have been alot of great ideas…

b


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |

#78876
Jun 15, 2006 at 8:47pm

sounds like you are narrowing in on a feature request.
how are you thinking this could be made to work intuitively at the
environment level?

were you thinking of highlighting a section of code or subpatch and
then clicking an edit menu and selecting (comment in/out) or
(disable/enable), and then the selected code would get all pastel and
grey and would not be an active part of the patch until you brought it
back to life?

maybe it would work like hide/show. you can see the code its there,
connected and all, but then when you lock the patch it could become
inactive.

#78877
Jun 15, 2006 at 9:18pm

That’s exactly what I want.


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |

#78878
Jun 17, 2006 at 4:30pm

#78879
Jun 17, 2006 at 6:42pm

Accept that it makes the code unreadable.

The point is to be able to quickly glance at old code in line in its
original context.


barry threw :: sound | (if you would see the stars clearly,
http://www.barrythrew.com | look hard at the surrounding darkness)
bthrew(at)gmail(dot)com | -Ooka Makoto
857-544-3967 |

#78880
Jun 18, 2006 at 10:18am

On 17 Jun 2006, at 17:30, Stefan Tiedje wrote:

> If you cut the part you want to disable, it will be represented as
> text in the copy buffer. Then just copy it as it is into a comment
> box and voila its disabled.

I would check that it doesn’t screw up “$”, “#”, commas and
backslashes…

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com

#78881

You must be logged in to reply to this topic.