Hopefully, try it and less us know.

.hc

On Jun 15, 2010, at 2:43 PM, quietdidit@gmail.com wrote:

Quick question Hans. I've just realized that pd-extended 0.41.4 in
my mac osx 10.6 couldn't load some of the pd.darwin of the
externals. Is this problem solved already in the 0.42? I know I
should try this release myself,just curious though :)

Regards,

Adityo Sent from my BlackBerry® smartphone from Sinyal Bagus XL, Nyambung
Teruuusss...!

-----Original Message----- From: Hans-Christoph Steiner hans@at.or.at Sender: pd-list-bounces@iem.at Date: Tue, 15 Jun 2010 14:36:58 To: PD listpd-list@iem.kug.ac.at Subject: [PD] Pd-extended 0.42.5 release candidate 3 released!

A couple more little fixes, so 0.42.5-rc3:

• delwrite~ should work properly with -nogui
• fonts in properties dialogs on Windows should be the right size
• updated portaudio to hopefully get better ASIO and ALSA support

There are of course many bug fixes and additions since 0.41.4, here are some highlights:

• fixing Graph-On-Parent GUI bugs
• complete 64-bit support for GNU/Linux
• full support for Mac OS X 10.6 Snow Leopard (32-bit)
• a brand new Help Browser that shows all installed libraries

For more details, check the notes on the release wiki page: http://puredata.info/dev/NextRelease

Downloading

You can download builds for Debian, Mac OS X, Ubuntu, and Windows: http://at.or.at/hans/pd/installers.html

You can get the source and build it yourself here: http://puredata.info/docs/developer/GettingPdSource

BUGS

Test away and file bugs in the bug tracker! Also check the bug tracker before reporting bugs, and if you find an existing bug report on the same issue, please add your information there:

http://puredata.info/dev/bugtracker

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf

On 06/15/2010 09:54 PM, Hans-Christoph Steiner wrote:

...

on windows i had a errormessage "allocting font resource" or something like that (sorry, i can not remember the exakt message), during the installation, but only the first time i installed. (maybe some remains of an older pd-extended installation interfered). after unistalling and reinstalling i had no errors.

Which version of Windows?

xp, sp3.

bis denn! martin

On Jun 15, 2010, at 10:09 PM, Mathieu Bouchard wrote:

On Tue, 15 Jun 2010, Hans-Christoph Steiner wrote:

...

You need to do [import hexloader] first, then those objects will
create.

Why isn't hexloader enabled by default ?

It was causing a lot of problems. Check the archives for details.

.hc

              ¡El pueblo unido jamás será vencido!

On Thu, 2010-06-17 at 16:56 -0400, Mathieu Bouchard wrote:

On Wed, 16 Jun 2010, Hans-Christoph Steiner wrote:

...

On Jun 15, 2010, at 10:09 PM, Mathieu Bouchard wrote:

...

On Tue, 15 Jun 2010, Hans-Christoph Steiner wrote:

...

You need to do [import hexloader] first, then those objects will create.

Why isn't hexloader enabled by default ?

It was causing a lot of problems. Check the archives for details.

Actually, I can't get hexloader to work. It seems to have no effect.

I can't instantiate [mtx_+] without first instantiating [mtx_add], which is the same class.

There are pd-extended users who recompile zexy and iemmatrix as big libraries because the system of one-class-per-file of pd-extended doesn't work with those names and the filesystems. It's causing a lot of problems.

Yeah, there have been some troubles. In the case of iemmatrix: most of the aliases were missing completely, so even with hexloader loaded, Pd-extended wouldn't find the correct files. I created a patch that adds all missing aliases for iemmatrix and IOhannes committed it two days ago [1]. I guess you would need to try a current autobuild to be able to create [mtx_+] directly. The rc3 version was released before the patch was applied.

Regarding zexy, I am not aware of any troubles in Pd-extended. Please post bugs, if you find any. I guess we're not far away from the libdirs behaving similar to the original multi-object library format. I personally care most about zexy and iemmatrix, I haven't checked if other libraries also require aliases.

[1] https://sourceforge.net/tracker/?func=detail&aid=3017152&group_id=55...

@ Hans You said you removed hexloader from automatically being loaded, because there have been some troubles in the past. The reason could be found in the list archives. I haven't thoroughly checked everything about hexloader, but it seemed to me that most problems have been solved. If not, can you elaborate a bit the issue? Personally, I think it would help _a lot_ to make Pd patches portable between flavours, if hexloader would be loaded automaticall on start-up of Pd-extended. Please let me know, if you think it is not worth raising this discussion again.

Roman

On Fri, 2010-06-18 at 13:01 -0400, Hans-Christoph Steiner wrote:

On Jun 18, 2010, at 8:49 AM, Roman Haefeli wrote:

...

On Thu, 2010-06-17 at 16:56 -0400, Mathieu Bouchard wrote:

...

On Wed, 16 Jun 2010, Hans-Christoph Steiner wrote:

...

On Jun 15, 2010, at 10:09 PM, Mathieu Bouchard wrote:

...

On Tue, 15 Jun 2010, Hans-Christoph Steiner wrote:

...

You need to do [import hexloader] first, then those objects will
create.

Why isn't hexloader enabled by default ?

It was causing a lot of problems. Check the archives for details.

Actually, I can't get hexloader to work. It seems to have no effect.

I can't instantiate [mtx_+] without first instantiating [mtx_add],
which is the same class.

There are pd-extended users who recompile zexy and iemmatrix as big libraries because the system of one-class-per-file of pd-extended
doesn't work with those names and the filesystems. It's causing a lot of
problems.

Yeah, there have been some troubles. In the case of iemmatrix: most of the aliases were missing completely, so even with hexloader loaded, Pd-extended wouldn't find the correct files. I created a patch that
adds all missing aliases for iemmatrix and IOhannes committed it two days
ago [1]. I guess you would need to try a current autobuild to be able to create [mtx_+] directly. The rc3 version was released before the patch was applied.

Regarding zexy, I am not aware of any troubles in Pd-extended. Please post bugs, if you find any. I guess we're not far away from the
libdirs behaving similar to the original multi-object library format. I personally care most about zexy and iemmatrix, I haven't checked if other libraries also require aliases.

[1] https://sourceforge.net/tracker/?func=detail&aid=3017152&group_id=55...

@ Hans You said you removed hexloader from automatically being loaded,
because there have been some troubles in the past. The reason could be found
in the list archives. I haven't thoroughly checked everything about hexloader, but it seemed to me that most problems have been solved. If not, can you elaborate a bit the issue? Personally, I think it would help _a lot_ to make Pd patches portable between flavours, if hexloader would be loaded automaticall on start- up of Pd-extended. Please let me know, if you think it is not worth
raising this discussion again.

Roman

I don't remember the reasons, I'd have to dig in the archives to
remember :) hexloader has been IOhannes' project. I think in order
for it to work, it should be simplified more. I think it should use a
setup function called setup(), for example. Then it wouldn't need to
do any 0x hex rewriting for the setup function.

I don't see how _not_ loading hexloader automatically on start-up can help here. A supposedly too complex hexloader mechanism is still better that none at all, even more since it is already implemented, no? I personally would welcome if it _would_ be loaded automatically for reasons I mentioned above.

I am probably the wrong person to comment on the technical aspects, but it seems to me that your proposal of having only a setup() function instead of the current classname_setup() function would render it impossible to have a c file provide more than one class. Or am I misunderstanding something here?

Roman

On Jun 19, 2010, at 1:42 PM, Mathieu Bouchard wrote:

On Fri, 18 Jun 2010, Roman Haefeli wrote:

...

I am probably the wrong person to comment on the technical aspects,
but it seems to me that your proposal of having only a setup() function instead of the current classname_setup() function would render it impossible to have a c file provide more than one class. Or am I misunderstanding something here?

No. You can define any number of classes in a setup().

In fact, you can do anything. I once made a library that would only
provide more aliases for existing (builtin) classes, so that I could
instantiate either [inlet] or [inlet~] by writing [inlet.$1] where
$1 was a parameter that could be f, s, ~, # or other.

You can also add methods to existing classes. Thus GridFlow adds
methods "else", "last" and "last_activate" in the "canvas" class.
It's very useful to do so, but Pd doesn't have a plan for
documenting such a situation, because I can't provide a rightclick
helpfile for the extra methods. So, for now, they are still
undocumented, but they are used by [#in], [#many] and [doc_m]
respectively, among other uses...

If you happen to have several files in a big library, and they each
have a setup(), you can name each of the setups differently and call
all of them from the main setup() of the library (except itself). If
you need a library to be compilable in both manners from the same
source, you can use compilation options such as - Dsetup=thisclass_setup or things like that, to rename a plain
setup() to a longer, unique name.

I am saying that each class should have a function called setup().
That's how it works in Max/MSP. I think that having a single function
called setup() load multiple classes is not a good idea. The thing
loading the classes just needs to know not to import the "setup"
symbol, just call the function.

.hc

If you are not part of the solution, you are part of the problem.

On Jun 19, 2010, at 8:46 PM, Mathieu Bouchard wrote:

On Sat, 19 Jun 2010, Hans-Christoph Steiner wrote:

...

I am saying that each class should have a function called setup().
That's how it works in Max/MSP.

I know what you're saying. And I think that whatever it is in Max/ MSP is informative, but it doesn't have to be like that. I don't
especially care what they actually do. Sometimes it's a good
inspiration, but you've got to have a better reason than "it's like
that in Max/MSP". I wouldn't actually even list it in a list of
reasons for doing something, except when making a compatibility
library.

And then, as I just explained, there are many things that you just
can't achieve by considering that the only thing one would ever do
is install a new class.

Some other examples are : the code that adds an inlet to the builtin
comment class. the code that adds extra menu items in the Help menu.
Iemguts modifying the savefn and propertiesfn of the canvas class.
etc.

...

I think that having a single function called setup() load multiple
classes is not a good idea.

Classes in other programming languages are rarely bundled as
separate files. In C and C++, it's usually one big .so file for a
large collection of classes. Even in Java, the paradise of class- files, it didn't take long before people begged that the class-files
be joined together into a few big files, and that's how the JAR
format was born.

A JAR is a .zip file of a folder with individual .class files, one for
each class.

.hc

Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli

On Sat, 2010-06-19 at 21:05 -0400, Mathieu Bouchard wrote:

On Sat, 19 Jun 2010, Hans-Christoph Steiner wrote:

...

A JAR is a .zip file of a folder with individual .class files, one for each class.

Congratulations.

Can we stick to the topic?

I repeat my question: Is there still a good reason not to load hexloader automatically at start-up in Pd-extended?

Thanks Roman

On Sun, 2010-06-20 at 09:26 -0400, Hans-Christoph Steiner wrote:

On Jun 20, 2010, at 8:48 AM, Roman Haefeli wrote:

...

On Sat, 2010-06-19 at 21:05 -0400, Mathieu Bouchard wrote:

...

On Sat, 19 Jun 2010, Hans-Christoph Steiner wrote:

...

A JAR is a .zip file of a folder with individual .class files, one
for each class.

Congratulations.

Can we stick to the topic?

I repeat my question: Is there still a good reason not to load
hexloader automatically at start-up in Pd-extended?

Thanks Roman

If you want to find out, I suggest you read the archives to find out
what the original problem was, and test it again to see if it is still
a problem.

Googling for 'site:lists.puredata.info hexloader' gave me (in non-chronologic order):

http://lists.puredata.info/pipermail/pd-dev/2009-05/013603.html (fixed in Pd-extended-0.42-5-rc2)

http://lists.puredata.info/pipermail/pd-dev/2008-06/011865.html [iemlib/any] does still not load, although [import iemlib] [any] does. Now the problem seems totally unrelated to [hexloader].

http://lists.puredata.info/pipermail/pd-list/2007-04/049085.html (fixed in Pd-extended-0.42-5-rc2)

http://lists.puredata.info/pipermail/pd-dev/2007-09/009544.html (fixed)

http://lists.puredata.info/pipermail/pd-dev/2007-12/010440.html don't know about this one. Still an issue?

http://lists.puredata.info/pipermail/pd-dev/2008-05/011645.html fixed. Though help-file for [.] still not available: sorry, couldn't find help patch for "scalarmult.pd"

http://lists.puredata.info/pipermail/pd-dev/2007-10/009897.html This is about the built-in hexloader, I guess.

http://lists.puredata.info/pipermail/pd-list/2007-01/045955.html Don't know, what this is about exactly. However, I think I can be confident to state, that [hexloader] is generally working with at least Pd-extended-0.42-5-rc2.

http://lists.puredata.info/pipermail/pd-list/2009-09/072587.html fixed in Pd-extended-0.42-5-rc2.

http://lists.puredata.info/pipermail/pd-list/2009-06/070717.html fixed

http://lists.puredata.info/pipermail/pd-list/2009-01/067192.html There problem here seems not related to hexloader.

http://lists.puredata.info/pipermail/pd-dev/2008-07/011950.html This doesn't tell me anything more specific.

When digging some more into google results, it appears that quite a portion of the troubles people have is due to hexloader _not_ being loaded per default.

Hans, please let me know, if I missed the real reason you were talking about and which should be found in the archives.

I feel that you're not much in love with hexloader, probably because quite some portion of all the issues mentioned in any pd-list is somehow related to hexloader. But often it seems, that hexloader is not really the cause of the problem or the problem has been fixed long time ago. Of course, if there is still a serious problem with it, I appreciate your decision not to load it automatically.

Roman

On Sun, 2010-06-20 at 20:09 -0400, Hans-Christoph Steiner wrote:

On Jun 20, 2010, at 5:15 PM, Roman Haefeli wrote:

...

I feel that you're not much in love with hexloader, probably because quite some portion of all the issues mentioned in any pd-list is
somehow related to hexloader. But often it seems, that hexloader is not really the cause of the problem or the problem has been fixed long time ago. Of course, if there is still a serious problem with it, I appreciate your decision not to load it automatically.

Its more IOhannes' call, he wrote the thing. We can try enabling it
by default in Pd-extended 0.43 if someone is willing to fix things
when problems arise.

I think, that would be a good idea. However, I think I will only be able to contribute by testing hexloader and reporting issues. I can't speak for IOhannes, of course, though it'd be great if he'd still be interested in maintaining hexloader <wink> <wink>....

Roman

On Fri, 18 Jun 2010, Hans-Christoph Steiner wrote:

I don't remember the reasons, I'd have to dig in the archives to remember :) hexloader has been IOhannes' project. I think in order for it to work, it should be simplified more. I think it should use a setup function called setup(), for example. Then it wouldn't need to do any 0x hex rewriting for the setup function.

perhaps name it pd_setup() instead to eliminate any remaining possibility of nameclashes with any library being used by the externals...

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

On Jun 15, 2010, at 11:37 PM, Mathieu Bouchard wrote:

On Tue, 15 Jun 2010, Hans-Christoph Steiner wrote:

...

A couple more little fixes, so 0.42.5-rc3:

• delwrite~ should work properly with -nogui

I thought that you had said that it was in rc2 but wasn't listed.

In any case, my fix also fixes two other bugs, which you would know
about if you had read this :

http://sourceforge.net/tracker/index.php?func=detail&aid=2978457&gro...

I will paste it here for you :

• [delwrite~] doesn't honour the sampling rate set by [block~]
• [delwrite~] doesn't honour any change of sampling rate (e.g. 44100

to 22050).

those are fixed by applying the same diff, so, you should put them
in your changelog.

Done. Also, that page is a wiki so you could have added them yourself.

.hc

I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." --Bjarne Stroustrup (creator of C++)

On Jun 17, 2010, at 5:13 PM, Mathieu Bouchard wrote:

On Wed, 16 Jun 2010, Hans-Christoph Steiner wrote:

...

On Jun 15, 2010, at 11:37 PM, Mathieu Bouchard wrote:

...

those are fixed by applying the same diff, so, you should put them
in your changelog.

Done. Also, that page is a wiki so you could have added them
yourself.

Hey, I'm not the one who's applying the diffs to pd-extended,
therefore, I'm not the one who has to track down exactly when you
apply a diff so that I can fix your ChangeLog.

And then I wouldn't even think about the wiki. I don't use it. I
expect the ChangeLog to be in the SVN, for changes that happen in
the SVN. That's the natural place for it. But then, I believe that
many people would only read the announcement on pd-list and skip the
wiki (possibly thinking that they have already read it all as it is).

These things are all true. All I am saying is that you saw the
NextRelease wiki page, and you requested something be added to it.
The edit button is right there :)

Is there any notification system in the wiki so that people are
notified about a change I make ? If so, then who would get those
notifications ?

I think you can do that in the Plone website somehow, but I haven't
done it. I think there is an RSS feed for changes.

.hc

You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie