Download here:
http://devel.goto10.org/listing.php?repname=maximus&path=%2Fhsext%2F&...
Caveats:
- only one instance of [hsext]
- only one inlet for a single float
- only one outlet for a single float
- only one hardcoded stateless function from float to float
- probably a nightmare to compile on systems other than the machine I
wrote it on
But:
- the function in caveat 4 is written in Haskell
See what I mean about proof-of-concept ;)
Any/All feedback appreciated :)
Claude
Have you seen the "loader" functionality? If you made this into a
Haskell loader, then you could write native Pd objects in Haskell.
There is the CLR loader and API, which is a complete example.
.hc
On Jan 5, 2007, at 6:43 AM, Claude Heiland-Allen wrote:
Download here:
http://devel.goto10.org/listing.php?repname=maximus&path=%2Fhsext% 2F&rev=0&sc=0
Caveats:
- only one instance of [hsext]
- only one inlet for a single float
- only one outlet for a single float
- only one hardcoded stateless function from float to float
- probably a nightmare to compile on systems other than the
machine I wrote it on
But:
- the function in caveat 4 is written in Haskell
See what I mean about proof-of-concept ;)
Any/All feedback appreciated :)
Claude
http://claudiusmaximus.goto10.org
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
On Fri, 5 Jan 2007, Hans-Christoph Steiner wrote:
Have you seen the "loader" functionality? If you made this into a Haskell loader, then you could write native Pd objects in Haskell.
Claude has already written a pd object class in Haskell.
Now, will you stop claiming that the loader functionality has more power than what it really has. The loader isn't what enables one to write native Pd objects. :-(
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 6, 2007, at 9:51 AM, Mathieu Bouchard wrote:
On Fri, 5 Jan 2007, Hans-Christoph Steiner wrote:
Have you seen the "loader" functionality? If you made this into a
Haskell loader, then you could write native Pd objects in Haskell.Claude has already written a pd object class in Haskell.
Now, will you stop claiming that the loader functionality has more
power than what it really has. The loader isn't what enables one to
write native Pd objects. :-(
The loader is the final piece in the puzzle that was preventing
people from writing native objects in other languages. Yes, you
still have to port the Pd API to whatever language you are using,
that's why I pointed to the CLR version.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
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
On Sat, 2007-01-06 at 17:25 -0500, Hans-Christoph Steiner wrote:
The loader is the final piece in the puzzle that was preventing
people from writing native objects in other languages.
because people were to lazy to type an additional word into an object box?
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
You can play a shoestring if you're sincere John Coltrane
On Sat, 6 Jan 2007, Tim Blechmann wrote:
On Sat, 2007-01-06 at 17:25 -0500, Hans-Christoph Steiner wrote:
The loader is the final piece in the puzzle that was preventing people from writing native objects in other languages.
because people were to lazy to type an additional word into an object box?
What additional word? I've over a hundred classes made with Ruby code that don't require any additional word in the objectbox, compared to anything else.
Just wrap class_new()... that's the final piece in the puzzle.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 6, 2007, at 6:00 PM, Tim Blechmann wrote:
On Sat, 2007-01-06 at 17:25 -0500, Hans-Christoph Steiner wrote:
The loader is the final piece in the puzzle that was preventing people from writing native objects in other languages.
because people were to lazy to type an additional word into an object box?
The lack of class-specific help patches and properties panels for
each class is what I am talking about. AFAIK, you can't do that with
[py].
.hc
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
You can play a shoestring if you're sincere John Coltrane
If you are not part of the solution, you are part of the problem.
On Sun, 7 Jan 2007, Hans-Christoph Steiner wrote:
On Jan 6, 2007, at 6:00 PM, Tim Blechmann wrote:
On Sat, 2007-01-06 at 17:25 -0500, Hans-Christoph Steiner wrote:
The loader is the final piece in the puzzle that was preventing people from writing native objects in other languages.
The lack of class-specific help patches and properties panels for each class is what I am talking about. AFAIK, you can't do that with [py].
for a class to be recognised as a pd class (so that looking for helpfiles works), it needs to be created using class_new(). I don't know why [py] doesn't use it once per python class that it exports to pd, but it's always been possible to do that, which means since 1996. I've been doing it since 2002, including calling it from outside of the _setup() function.
About properties panels... this has never been in Pd's public API, which is m_pd.h and nothing else.
In both cases, it's hard to consider those features as being implied by the phrase "native object".
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sat, 6 Jan 2007, Hans-Christoph Steiner wrote:
The loader is the final piece in the puzzle that was preventing people from writing native objects in other languages.
Now it doesn't look like you are just being innocently mistaken, it looks like a deliberate lie.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Am 07.01.2007 um 01:20 schrieb Mathieu Bouchard:
On Sat, 6 Jan 2007, Hans-Christoph Steiner wrote:
The loader is the final piece in the puzzle that was preventing
people from writing native objects in other languages.Now it doesn't look like you are just being innocently mistaken, it
looks like a deliberate lie.
Is everything ok with you?
greetings, Thomas
On Sun, 7 Jan 2007, Thomas Grill wrote:
Am 07.01.2007 um 01:20 schrieb Mathieu Bouchard:
On Sat, 6 Jan 2007, Hans-Christoph Steiner wrote:
The loader is the final piece in the puzzle that was preventing people from writing native objects in other languages.
Now it doesn't look like you are just being innocently mistaken, it looks like a deliberate lie.
Is everything ok with you?
What, you aren't going to say that the absence of the new loader feature has ever prevented you from coding your Python externals ?
Is everything ok with you?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Maybe I'm missing the point here, but isn't Haskell a compiled (not interpreted) language? We can add any compiled function, wrapped in a C-written external, just so long as we have the symbols for the function from the binary. *OR* we can write an external in some funky language, so long as we can reference the functions from m_pd.h correctly in that language. I tried to put a Fortran function into an external, once compiled. All I had to do was "grep" for the symbols exactly as they appeared in the binary, and get the variables of the function declaration right. Is this similar? Have I missed the point entirely? Chuck
On 1/6/07, Mathieu Bouchard matju@artengine.ca wrote:
On Sun, 7 Jan 2007, Thomas Grill wrote:
Am 07.01.2007 um 01:20 schrieb Mathieu Bouchard:
On Sat, 6 Jan 2007, Hans-Christoph Steiner wrote:
The loader is the final piece in the puzzle that was preventing people from writing native objects in other languages.
Now it doesn't look like you are just being innocently mistaken, it looks like a deliberate lie.
Is everything ok with you?
What, you aren't going to say that the absence of the new loader feature has ever prevented you from coding your Python externals ?
Is everything ok with you?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
That sounds about right. But having a Pd API in the native language
would be nicer.
.hc
On Jan 6, 2007, at 9:39 PM, Charles Henry wrote:
Maybe I'm missing the point here, but isn't Haskell a compiled (not interpreted) language? We can add any compiled function, wrapped in a C-written external, just so long as we have the symbols for the function from the binary. *OR* we can write an external in some funky language, so long as we can reference the functions from m_pd.h correctly in that language. I tried to put a Fortran function into an external, once compiled. All I had to do was "grep" for the symbols exactly as they appeared in the binary, and get the variables of the function declaration right. Is this similar? Have I missed the point entirely? Chuck
On 1/6/07, Mathieu Bouchard matju@artengine.ca wrote:
On Sun, 7 Jan 2007, Thomas Grill wrote:
Am 07.01.2007 um 01:20 schrieb Mathieu Bouchard:
On Sat, 6 Jan 2007, Hans-Christoph Steiner wrote:
The loader is the final piece in the puzzle that was
preventing people
from writing native objects in other languages.
Now it doesn't look like you are just being innocently
mistaken, it looks
like a deliberate lie.
Is everything ok with you?
What, you aren't going to say that the absence of the new loader
feature has ever prevented you from coding your Python externals ?Is everything ok with you?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[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 Sat, 6 Jan 2007, Charles Henry wrote:
Maybe I'm missing the point here, but isn't Haskell a compiled (not interpreted) language?
It's either. Whether a language is compiled or interpreted, is dependent on compilers and interpreters. There even exists a C interpreter. For Haskell, I think I recall that I tried HUGS in 1998 or so, and that it was an interpreter. Whatever it is, the distinction between compiler and interpreter has been blurred a lot over the year: e.g. the Python "interpreter" compiles code and saves it to disk, and also interprets the "compiled" code.
can write an external in some funky language, so long as we can reference the functions from m_pd.h correctly in that language. I tried to put a Fortran function into an external, once compiled. All I had to do was "grep" for the symbols exactly as they appeared in the binary, and get the variables of the function declaration right. Is this similar?
If FORTRAN supports function pointers and all the other C features that you need, then you could rewrite m_pd.h as FORTRAN code so that you may use the same API; if not, then you would have to either write a translation layer in C which would give you a FORTRAN-friendly API, or if that's not really feasible then you may have to write a code generator that will automatically produce C code which you will link to your FORTRAN code to make it Pd-ready.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, 7 Jan 2007, Mathieu Bouchard wrote:
Whatever it is, the distinction between compiler and interpreter has been blurred a lot over the year: e.g. the Python "interpreter" compiles code and saves it to disk, and also interprets the "compiled" code.
Typo, I meant over the years. Not much really changed in 2006; I meant "in the last 25 years or so" but more particularly during the nineties.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Charles Henry wrote:
Maybe I'm missing the point here, but isn't Haskell a compiled (not interpreted) language?
There are a variety of compilers and interpreters.
We can add any compiled function, wrapped in a C-written external, just so long as we have the symbols for the function from the binary.
True, and almost trivial, which is why the root of this thread mentioned "proof of concept". The slightly non-trivial part is that Haskell has a run-time system, and the rather non-trivial part is dynamically loading Haskell source at runtime.
*OR* we can write an external in some funky language, so long as we can reference the functions from m_pd.h correctly in that language.
False. Pd expects a symbol blah_setup in a file blah.library (where .library is .pd_linux in my case).
I tried to put a Fortran function into an external, once compiled. All I had to do was "grep" for the symbols exactly as they appeared in the binary, and get the variables of the function declaration right. Is this similar?
Not very.
Have I missed the point entirely?
http://claudiusmaximus.goto10.org/gallery/coding/hsext/first-non-trivial.png
The middle window in the top row is the entire source for the object. hsext provides the glue to load that source, with a large portion of rather non-trivial help from:
http://www.cse.unsw.edu.au/~dons/hs-plugins/
Chuck
Claude
I think I understand now. This is quite a bit more complicated than I had thought at first.
Have I missed the point entirely?
http://claudiusmaximus.goto10.org/gallery/coding/hsext/first-non-trivial.png
The middle window in the top row is the entire source for the object. hsext provides the glue to load that source, with a large portion of rather non-trivial help from:
-
Charles Henry -
Claude Heiland-Allen -
Hans-Christoph Steiner -
Mathieu Bouchard -
Thomas Grill -
Tim Blechmann