I was thinking that it would be nice to have [once] accept a single argument which would set the initial state of the object, just like [spigot]. But this means that it would have to be default closed like spigot, breaking backwards compatibility. Do you mind if I make this change in abstractions/purepd/once.pd and add a warning message on load?
.hc
------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
On Mon, 11 Sep 2006, Hans-Christoph Steiner wrote:
I was thinking that it would be nice to have [once] accept a single argument which would set the initial state of the object, just like [spigot]. But this means that it would have to be default closed like spigot, breaking backwards compatibility.
No, it doesn't mean that. You need to make the creator accept A_GIMME instead of A_DEFFLOAT. Then when you get argc,argv, check whether argc==0.
Do you mind if I make this change in abstractions/purepd/once.pd and add a warning message on load?
Don't accept Pd's limitations, push for $@ and/or $# today!
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sep 11, 2006, at 7:08 PM, Mathieu Bouchard wrote:
On Mon, 11 Sep 2006, Hans-Christoph Steiner wrote:
I was thinking that it would be nice to have [once] accept a single argument which would set the initial state of the object, just like [spigot]. But this means that it would have to be default closed like spigot, breaking backwards compatibility.
No, it doesn't mean that. You need to make the creator accept A_GIMME instead of A_DEFFLOAT. Then when you get argc,argv, check whether argc==0.
[once] is written in Pd, so that doesn't apply.
.hc
Do you mind if I make this change in abstractions/purepd/once.pd and add a warning message on load?
Don't accept Pd's limitations, push for $@ and/or $# today!
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
On Mon, 11 Sep 2006, Hans-Christoph Steiner wrote:
On Sep 11, 2006, at 7:08 PM, Mathieu Bouchard wrote:
No, it doesn't mean that. You need to make the creator accept A_GIMME instead of A_DEFFLOAT. Then when you get argc,argv, check whether argc==0.
[once] is written in Pd, so that doesn't apply.
Ok, so you want to extend the tentacles of Pd's caste system further? Abstractions for the plebe, externals for gentlemen.
It looks like you didn't read that line of mine below?
Do you mind if I make this change in abstractions/purepd/once.pd and add a warning message on load?
Don't accept Pd's limitations, push for $@ and/or $# today!
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Mon, 11 Sep 2006, Mathieu Bouchard wrote:
On Mon, 11 Sep 2006, Hans-Christoph Steiner wrote: Ok, so you want to extend the tentacles of Pd's caste system further? Abstractions for the plebe, externals for gentlemen. It looks like you didn't read that line of mine below?
Don't accept Pd's limitations, push for $@ and/or $# today!
I mean, shouldn't abstractions have access to the same features as externals do? Why would a limitation in the way abstractions currently can accept arguments, define how [once] behaves, forever?
If you can't use $@ and $# because they're not Miller-approved, then what's the problem with using an external that will provide you the kind of argument-fetching that you need, for making the object behave like people would expect? I mean something like MAX's [patcherargs] instead of trying to fit with the dumb ways of $1 and construe it as a feature or as a principle to extend over all the behaviour of Pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Oops, forgot to add, another thing that would be handy is to have the right reset inlet accept floats, then >0 would set status to open and <=0 would set status to closed. AFAIK, that wouldn't really break backwards compatibility.
.hc
On Sep 11, 2006, at 7:07 PM, Hans-Christoph Steiner wrote:
I was thinking that it would be nice to have [once] accept a single argument which would set the initial state of the object, just like [spigot]. But this means that it would have to be default closed like spigot, breaking backwards compatibility. Do you mind if I make this change in abstractions/purepd/once.pd and add a warning message on load?
.hc
--
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
------------------------------------------------------------------------
"[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
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I was thinking that it would be nice to have [once] accept a single argument which would set the initial state of the object, just like [spigot]. But this means that it would have to be default closed like spigot, breaking backwards compatibility. Do you mind if I make this change in abstractions/purepd/once.pd and add a warning message on load?
I've never used [once] but to me it seems that breaking compatibility just for something "that would be nice" may do more harm than good to people who have actually used [once] and who now would need to find and change the patches where they did.
Additionally I would find it confusing to have a [once] which would actually be more like a [nonce] unless called with an argument.
Ciao
On Sep 11, 2006, at 7:47 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I was thinking that it would be nice to have [once] accept a single argument which would set the initial state of the object, just like [spigot]. But this means that it would have to be default closed like spigot, breaking backwards compatibility. Do you mind if I make this change in abstractions/purepd/once.pd and add a warning message on load?
I've never used [once] but to me it seems that breaking compatibility just for something "that would be nice" may do more harm than good to people who have actually used [once] and who now would need to find and change the patches where they did.
Additionally I would find it confusing to have a [once] which would actually be more like a [nonce] unless called with an argument.
I actually think that default closed would be more consistent behavior, especially if [once] uses an argument. Changing [once] to default-closed would make it exactly like [spigot], except with the added feature of closing itself after receiving one piece of data.
The more objects behave consistently with each other, the better Pd will be.
.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
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I actually think that default closed would be more consistent behavior, especially if [once] uses an argument. Changing [once] to default-closed would make it exactly like [spigot], except with the added feature of closing itself after receiving one piece of data.
The more objects behave consistently with each other, the better Pd will be.
I still don't see the Why. [once] is used in a different context than [spigot] and to me, having [once] open as default is more natural for its use which is: let something pass *once* through the open path, then close the path until the object is reset to its initial state: open. Contrary to this [spigot] just like its counterpart in real life, a spigot for water, is normally closed and only opened on demand. (There was a time, when [spigot] didn't accept an argument, that was the time, when people invented [once]).
As I don't use [once] I don't really care much about how [once] behaves, however changing the default is bound to create confusion, just like switching the inlets of atan2 did, and I can't really follow the motivation for this.
Additionally the only use the [once] object has IMO is as a backwards compatibile shortcut for "[spigot 1]-[trigger a b]-[1]" from a time, when [spigot 1] wasn't invented yet. As a "default closed [once]" is so similar to [spigot], the need for having it as an abstraction at all is questionable.
Regarding consistency: I hope you don't intend to switch the inlets of [timer] for the sake of consistency? ;-)
Ciao
Hans-Christoph Steiner wrote:
I actually think that default closed would be more consistent behavior, especially if [once] uses an argument. Changing [once] to
i cannot follow you here: what makes [once] consistent if it was closed by default? while the object should be consistent to other objects (and i don't think it is inconsistent), it should be consistent to itself in the first place. (e.g.: making an empty object [Symbol] output 0 if you bang it (after instantiation without arguments), might be consistent to [f] and [t f], but somehow i have the feeling it should do symbols...;-))
default-closed would make it exactly like [spigot], except with the added feature of closing itself after receiving one piece of data.
i follow frank here: if this object was "exactly like [spigot]" then you should use [spigot]. if there is a need for your suggested hybrid between [spigot] and [once], then this object should be, but with a different name.
The more objects behave consistently with each other, the better Pd will be.
but the more objects will behave as expected, the even better Pd will be. consistency is really a lot about "how do i expect an object to behave"
imho, the biggest inconsistency for [once] is, that you can reset it at all.
mfg.asdr IOhannes
There are many objects that control flow. [spigot], [gate], etc. They take float arguments. Float arguments are initialized to 0. 0 means closed in Pd.
[once] controls flow. It should take a float argument like [spigot] and [gate] so you can choose the default state. No argument implies an argument of 0. Therefore it makes sense that [once] would be default closed. If you want it to be default open, you can easily do [once 1]. This has worked well for [spigot], I think this will work well for [once].
If you doubt that [once] and [spigot] are related, then open up the once.pd and check what is controlling the flow of data. Low and behold, its [spigot].
.hc
On Sep 13, 2006, at 12:31 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I actually think that default closed would be more consistent behavior, especially if [once] uses an argument. Changing [once] to
i cannot follow you here: what makes [once] consistent if it was closed by default? while the object should be consistent to other objects (and i don't think it is inconsistent), it should be consistent to itself in the first place. (e.g.: making an empty object [Symbol] output 0 if you bang it (after instantiation without arguments), might be consistent to [f] and [t f], but somehow i have the feeling it should do symbols...;-))
default-closed would make it exactly like [spigot], except with the added feature of closing itself after receiving one piece of data.
i follow frank here: if this object was "exactly like [spigot]" then you should use [spigot]. if there is a need for your suggested hybrid between [spigot] and [once], then this object should be, but with a different name.
The more objects behave consistently with each other, the better Pd will be.
but the more objects will behave as expected, the even better Pd will be. consistency is really a lot about "how do i expect an object to behave"
imho, the biggest inconsistency for [once] is, that you can reset it at all.
mfg.asdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
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
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
[once] controls flow. It should take a float argument like [spigot] and [gate] so you can choose the default state. No argument implies an argument of 0. Therefore it makes sense that [once] would be default closed.
But then it wouldn't be [once] anymore, as I already remarked.
If you want it to be default open, you can easily do [once 1].
Changing the behaviour of [once] would force anyone who was using [once] to change their patches.
I guess we all agree that adding an argument to [once] can be considered, however IOhannes and I both don't want this if it changes the default behaviour.
As a compromise why not let [once] stay the way it is and as it's used, but instead introduce a new object with a new name. I thought a bit about this, and *if* we want an argument to [once], then this argument should be used for a little bit more than just selecting open or close. The most natural use for an argument I could come up with was to select, after how many incoming messages the object should close. Of course then the name [once] wouldn't be useful anymore as we would also have a reaction to messages coming in "more than once".
So my idea for this object is like this:
[the_object_previously_known_as_once] would close after 0 messages, that is, default is closed just like you wished.
[the_object_previously_known_as_once 1] would be like the old [once]
[the_object_previously_known_as_once 10] would close after 10 in-messages, that is after it has counted down like: 9, 8, 7, 6, 5, 4, 3, 2, 1, liftoff!
That's also the name I finally chose for the new [the_object_previously_known_as_once]:
[countdown]
It's attached.
Ciao
IOhannes stuck [once] into the purepd library. I started that library as a DEVELOPMENT library to explore ideas of how to implement things in Pd. IOhannes replaced my code with [once] without asking me. That's bad CVS etiquette. But [once] was an improvement on what was there. I want to improve it further but you guys are blocking me. So here's what I say: purepd will remain a DEVELOPMENT library. If you want a static, unchanging [once], please include it elsewhere, like zexy. If you want a place to freely explore implementing things in Pd, please include it in the purepd library. Then as interfaces and ideas get solidified, they can be moved elsewhere.
.hc
On Sep 13, 2006, at 7:16 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
[once] controls flow. It should take a float argument like [spigot] and [gate] so you can choose the default state. No argument implies an argument of 0. Therefore it makes sense that [once] would be default closed.
But then it wouldn't be [once] anymore, as I already remarked.
If you want it to be default open, you can easily do [once 1].
Changing the behaviour of [once] would force anyone who was using [once] to change their patches.
I guess we all agree that adding an argument to [once] can be considered, however IOhannes and I both don't want this if it changes the default behaviour.
As a compromise why not let [once] stay the way it is and as it's used, but instead introduce a new object with a new name. I thought a bit about this, and *if* we want an argument to [once], then this argument should be used for a little bit more than just selecting open or close. The most natural use for an argument I could come up with was to select, after how many incoming messages the object should close. Of course then the name [once] wouldn't be useful anymore as we would also have a reaction to messages coming in "more than once".
So my idea for this object is like this:
[the_object_previously_known_as_once] would close after 0 messages, that is, default is closed just like you wished.
[the_object_previously_known_as_once 1] would be like the old [once]
[the_object_previously_known_as_once 10] would close after 10 in-messages, that is after it has counted down like: 9, 8, 7, 6, 5, 4, 3, 2, 1, liftoff!
That's also the name I finally chose for the new [the_object_previously_known_as_once]:
[countdown]
It's attached.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__ <countdown.pd> <countdown-help.pd> _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
IOhannes stuck [once] into the purepd library. I started that library as a DEVELOPMENT library to explore ideas of how to implement things in Pd. IOhannes replaced my code with [once] without asking me. That's bad CVS etiquette. But [once] was an improvement on what was there. I want to improve it further but you guys are blocking me. So here's what I say:
We're not blocking anything: It was you who asked for opinions on a certain change to [once] and I said my opionion, so did IOhannes. I don't see how that is blocking anything.
Additionally I also sat down for 20 minutes and implemented your proposed change, I even extended its features in a way that seemed natural to me. I also don't see how this is blocking development, instead I think, this *is* development.
Third: I thought purepd is meant to "replace standard externals", as stated in the README. Now your proposed change to [once] would actually make [purepd/once] incompatible with the "standard external" [once] in IEM (which actually isn't an external anyways).
Finally: I think I've said all I wanted to say regarding purepd/once.
Ciao
hi.
Hans-Christoph Steiner wrote:
IOhannes stuck [once] into the purepd library. I started that library
true
as a DEVELOPMENT library to explore ideas of how to implement things in
sorry, i had no idea you intended it like that. i always thought that purepd would be a replacement for often-used externals in plain pd, and that it was meant to be a community effort. i was mistaken here.
Pd. IOhannes replaced my code with [once] without asking me. That's
hmm, which code are you talking about? did i _replace_ your code of [once] with (my) [once]? i don't think so. did i replace your code of [oneshot] with one using (my implementation of) [once]? this is true (but the logfiles of [oneshot] state, that it is meant as a "pd-ified version[s] of existing object[s]"; the only known [oneshot] object (at that time) is in MarkEx/Gem, and the original pd-ified object did not properly implement that's behaviour. i thought i was fixing a bug...)
bad CVS etiquette. But [once] was an improvement on what was there. I
thanks for the roses.
want to improve it further but you guys are blocking me. So here's what I say: purepd will remain a DEVELOPMENT library. If you want a static, unchanging [once], please include it elsewhere, like zexy. If you want a place to freely explore implementing things in Pd, please include it in the purepd library. Then as interfaces and ideas get solidified, they can be moved elsewhere.
an this from someone who is known for advocating "standard" behaviour of objects.
purepd is a very catchy name for a mere sandbox.
mfg.adr. IOhannes
Arg... another example of the limitations of email, its so hard to communicate anything where nuance is essential. This discussion would take 10 minutes in person and no one would be annoyed. Maybe I'll try bullet points:
- I want to support collaboration on purepd - I want to implement key objects in Pd in purepd - I think purepd should be a scratchpad to test ideas - I do not care about strict adherence to backwards compatibility - I do care about finding broad standards that make sense in the overall - I did not know that [once] already exists elsewhere outside of purepd - I rarely go against the consensus of opinion on this list, that's what I meant by "blocking"
That's my thoughts on what purepd should be.
.hc
On Sep 15, 2006, at 7:43 AM, IOhannes m zmoelnig wrote:
hi.
Hans-Christoph Steiner wrote:
IOhannes stuck [once] into the purepd library. I started that library
true
as a DEVELOPMENT library to explore ideas of how to implement things in
sorry, i had no idea you intended it like that. i always thought that purepd would be a replacement for often-used externals in plain pd, and that it was meant to be a community effort. i was mistaken here.
Pd. IOhannes replaced my code with [once] without asking me. That's
hmm, which code are you talking about? did i _replace_ your code of [once] with (my) [once]? i don't think so. did i replace your code of [oneshot] with one using (my implementation of) [once]? this is true (but the logfiles of [oneshot] state, that it is meant as a "pd-ified version[s] of existing object[s]"; the only known [oneshot] object (at that time) is in MarkEx/Gem, and the original pd-ified object did not properly implement that's behaviour. i thought i was fixing a bug...)
bad CVS etiquette. But [once] was an improvement on what was there. I
thanks for the roses.
want to improve it further but you guys are blocking me. So here's what I say: purepd will remain a DEVELOPMENT library. If you want a static, unchanging [once], please include it elsewhere, like zexy. If you want a place to freely explore implementing things in Pd, please include it in the purepd library. Then as interfaces and ideas get solidified, they can be moved elsewhere.
an this from someone who is known for advocating "standard" behaviour of objects.
purepd is a very catchy name for a mere sandbox.
mfg.adr. IOhannes
------------------------------------------------------------------------
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Arg... another example of the limitations of email, its so hard to communicate anything where nuance is essential. This discussion would take 10 minutes in person and no one would be annoyed.
Ah, yes, that's so very true... ;)
- I do not care about strict adherence to backwards compatibility
- I do care about finding broad standards that make sense in the overall
- I did not know that [once] already exists elsewhere outside of purepd
A name - of an object or a funicton - always carries some meaning of its own, which should be related to its behaviour. That is my main point against having [once] closed as default: A closed [once] to me more seems like a "[never]". Viewing it from this point was what made me come up with [countdown]. Maybe [countdown] isn't the best name, either. Alternatives could be [manyshot], [someshot], [passmany], [passcount] etc. What do you think?
Ciao
On Sep 16, 2006, at 6:38 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Arg... another example of the limitations of email, its so hard to communicate anything where nuance is essential. This discussion would take 10 minutes in person and no one would be annoyed.
Ah, yes, that's so very true... ;)
- I do not care about strict adherence to backwards compatibility
- I do care about finding broad standards that make sense in the
overall
- I did not know that [once] already exists elsewhere outside of
purepd
A name - of an object or a funicton - always carries some meaning of its own, which should be related to its behaviour. That is my main point against having [once] closed as default: A closed [once] to me more seems like a "[never]". Viewing it from this point was what made me come up with [countdown]. Maybe [countdown] isn't the best name, either. Alternatives could be [manyshot], [someshot], [passmany], [passcount] etc. What do you think?
I can say a [never] object makes no sense, while a [once] object that is default closed would be like "When I tell you to, then let something past just once". In Pd:
| [bang( | | [once 0] |
The question of consistency is a tough one here. Linguistic consistency is what you are outlining. From what I know most programming languages are more likely to adhere consistency of function arguments. But its tough to say what would work better in Pd.
Words can be very vague, especially when you consider that many programmers will be programming in a language that is not their native tongue. So it seems quite difficult to be strictly adherent to the words. Of course, it should be close as possible. But words are how humans communicate with each other, so the meaning of the language should be given attention.
So the other kind of consistency in question here is consistency of usage. All similar functions should have the same arguments, for example. Which type of consistency trumps the other? That's the question at hand.
I personally feel that its not more linguistically consistent to have [once] default open when it has no argument. But this is inconsistent in usage with similar objects ([spigot]...).
.hc
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
So the other kind of consistency in question here is consistency of usage. All similar functions should have the same arguments, for example. Which type of consistency trumps the other? That's the question at hand.
I personally feel that its not more linguistically consistent to have [once] default open when it has no argument. But this is inconsistent in usage with similar objects ([spigot]...).
I would speculate, that users would expect [once] to be open as default. While I generally don't use [once] in its own right, several of my patches have [pd once] subpatches, and these all default to open. There also is a very similar abstraction in the RTC-lib called "first-bang", which is like a [once] that is open as default but additionally passes bangs coming in after the first one to a second outlet. Nowhere in RTC-lib [first-bang] is used with a loadbang to its second, "reset"-inlet.
I guess, basically we disagree about what should be valued higher: consistency or usefulness. I consider a default-closed [once] rather useless. Not completely useless, but "not used 99% of the time" and the 1% can be dealt with through a loadbang, which is contrary to a default-close or default-open [spigot]: Here both versions are used about equally often.
This actually is similar to the inconsistency of [timer]: Most of the time, [timer] follows a [trigger bang bang] object (or rather a [t b b] object which even has the same visual length as [timer]) and the connections are made in a non-crossed fashion. That's the (only?) reason, [timer] has its active inlet on the right. In this case, Miller also chose usefulness over consistency, and I'm glad he did.
Ciao
On Sep 28, 2006, at 4:16 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
So the other kind of consistency in question here is consistency of usage. All similar functions should have the same arguments, for example. Which type of consistency trumps the other? That's the question at hand.
I personally feel that its not more linguistically consistent to have [once] default open when it has no argument. But this is inconsistent in usage with similar objects ([spigot]...).
I would speculate, that users would expect [once] to be open as default. While I generally don't use [once] in its own right, several of my patches have [pd once] subpatches, and these all default to open. There also is a very similar abstraction in the RTC-lib called "first-bang", which is like a [once] that is open as default but additionally passes bangs coming in after the first one to a second outlet. Nowhere in RTC-lib [first-bang] is used with a loadbang to its second, "reset"-inlet.
I guess, basically we disagree about what should be valued higher: consistency or usefulness. I consider a default-closed [once] rather useless. Not completely useless, but "not used 99% of the time" and the 1% can be dealt with through a loadbang, which is contrary to a default-close or default-open [spigot]: Here both versions are used about equally often.
This actually is similar to the inconsistency of [timer]: Most of the time, [timer] follows a [trigger bang bang] object (or rather a [t b b] object which even has the same visual length as [timer]) and the connections are made in a non-crossed fashion. That's the (only?) reason, [timer] has its active inlet on the right. In this case, Miller also chose usefulness over consistency, and I'm glad he did.
Obviously usefulness is essential. [once 1] would provide the default open behavior. I guess it really goes back to whether it always makes sense to init things to zero. Almost always it does, but not here. I suppose the best of both worlds would be to be able to differentiate between 0 and no arg. Then the first argument could be used for open/closed state, and no arg could default to open. $# and $@ would do this if properly implemented.
.hc
On Thu, 28 Sep 2006, Hans-Christoph Steiner wrote:
Obviously usefulness is essential.
Not even: the 6809 CPU has those two curious opcodes in it.
BRA, or branch always, means if(1) goto ...; BRN, or branch never, means if(0) goto ...;
this is among 14 other types of branches like "branch if last result overflowed" and "branch if last result was negative" and other serious stuff.
Note that 6809 already has another goto statement, called JMP.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, Sep 29, 2006 at 12:28:57AM -0400, Mathieu Bouchard wrote:
On Thu, 28 Sep 2006, Hans-Christoph Steiner wrote:
Obviously usefulness is essential.
Not even: the 6809 CPU has those two curious opcodes in it.
BRA, or branch always, means if(1) goto ...; BRN, or branch never, means if(0) goto ...;
this is among 14 other types of branches like "branch if last result overflowed" and "branch if last result was negative" and other serious stuff.
Note that 6809 already has another goto statement, called JMP.
Weird. Does the BRN have the same side effects, number of cycles etc. as a NOP? Likewise for BRA vs JMP?
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
On Fri, 29 Sep 2006, Chris McCormick wrote:
On Fri, Sep 29, 2006 at 12:28:57AM -0400, Mathieu Bouchard wrote:
BRA, or branch always, means if(1) goto ...; BRN, or branch never, means if(0) goto ...; Note that 6809 already has another goto statement, called JMP.
Weird. Does the BRN have the same side effects, number of cycles etc. as a NOP? Likewise for BRA vs JMP?
The main reason for BRA and LBRA is that if you want position-independent code, you need relative jumps, but JMP was absolute-only. Also, BRA was 2 bytes, while both LBRA and JMP were 3 bytes. (L stood for "Long", and a 16-bit offset was kind of long back then)
BRN was really completely useless, but that's because the 16 branch opcodes had a "not" bit, so for example "branch if less than" and "branch if greater or equal" were the same opcode except for that bit; and thus BRN existed only because it was the complement of BRA.
That's only what I figured out; a real 6809 assembly coder could tell you more.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Fri, 29 Sep 2006, Chris McCormick wrote:
On Fri, Sep 29, 2006 at 12:28:57AM -0400, Mathieu Bouchard wrote:
BRA, or branch always, means if(1) goto ...; BRN, or branch never, means if(0) goto ...; Note that 6809 already has another goto statement, called JMP.
Weird. Does the BRN have the same side effects, number of cycles etc. as a NOP? Likewise for BRA vs JMP?
The main reason for BRA and LBRA is that if you want position-independent code, you need relative jumps, but JMP was absolute-only. Also, BRA was 2 bytes, while both LBRA and JMP were 3 bytes. (L stood for "Long", and a 16-bit offset was kind of long back then)
BRN was really completely useless, but that's because the 16 branch opcodes had a "not" bit, so for example "branch if less than" and "branch if greater or equal" were the same opcode except for that bit; and thus BRN existed only because it was the complement of BRA.
One thing that could be done with 6809s and their ilk was self-modifying code, so that for example, a program could replace the opcode at a certain position before executing it, so that a single piece of code could do perform different functions. This was important when you had less than 64k of RAM. I remember disassembling an assembler written in 6502 which would use the same code to do AND, OR, XOR just by replacing that single opcode in a subroutine. It could be more efficient to switch between BRN and BRA than writing two separate subroutines.
Martin
That's only what I figured out; a real 6809 assembly coder could tell you more.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Fri, 29 Sep 2006, Martin Peach wrote:
One thing that could be done with 6809s and their ilk was self-modifying code, so that for example, a program could replace the opcode at a certain position before executing it, so that a single piece of code could do perform different functions. This was important when you had less than 64k of RAM.
Last year or so, I was thinking about writing self-modifying code in order to be able to do something like for (i=0; i<n; i++) a[i]=b; but using all SIMD registers for a, and instead make b an immediate value by modifying the code just prior to running it. This is because there is a power-of-two number of SIMD registers and it's easier to use a power-of-two number of them per loop iteration, so because I would normally need one to store b, I would only be able to use half of them.
But maybe that it's pointless or misguided, due to various things like how many more registers are in SSE or how bigger they are (I only learned MMX1 and that's the only thing GridFlow can use as of now), or where the bottleneck really is - the attempts I've made with MMX didn't pay off enough and I believe that it is because of things I didn't understand.
(do you have any advice?)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 27 Sep 2006, Hans-Christoph Steiner wrote:
From what I know most programming languages are more likely to adhere consistency of function arguments.
Everything that allows default arguments, except pd, doesn't enforce one value of default value, and instead require that a default value be supplied. This is implemented in C++, Java (1.5?), Python, Ruby, Tcl, CommonLISP, and a bunch more.
Words can be very vague, especially when you consider that many programmers will be programming in a language that is not their native tongue. So it seems quite difficult to be strictly adherent to the words.
Maybe you'd like to study the case of Ruby. This is a weird language in the sense that it's been written with English words by a bunch of Japanese people who live in Japan and who use Japanese as their main language.
NotImplementError used to be the name of a kind of error. The Array class has a method called "indexes". But in general it wasn't so much the naming in the code that was bad... when I started 6 years ago, the manual was saying things like "Instance variables are belong to the certain object."
But words are how humans communicate with each other, so the meaning of the language should be given attention.
Right.
I personally feel that its not more linguistically consistent to have [once] default open when it has no argument. But this is inconsistent in usage with similar objects ([spigot]...).
What Would Demux Do?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
Chris McCormick -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach -
Mathieu Bouchard