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 w
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.
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 sam
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
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,
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
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 consiste
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
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 an
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
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
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 of
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. Tha
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
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
> defaul
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 imp
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
> imho, the biggest inconsistency for [once] is, that you can reset it at all.
Yes, let's rename [once] to [onceagain]! ;)
Ciao
--
Frank Barknecht _ __footils.org_ __goto10.org__
_
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
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 feat
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
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 limi
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 sp
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
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
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
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 ab
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 compatibi
27 matches
Mail list logo
