Pd-dev October 2011

pd-dev@lists.iem.at

22 participants
138 discussions

Start a nNew thread

makefile template
by Patrice Colet 13 Oct '11

13 Oct '11

Hello is the makefile template able to compile with cpp source files, and how? -- Patrice Colet

2 1

pd-double build still having single externals
by katja 13 Oct '11

13 Oct '11

Hans, there's so many externals in pd-double giving weird output, I couldn't believe it's all wrong in the code. So I searched for a class which is definitely double-ready and which can act as a test class for the build of the lib where it is part of. For cyclone [mean] can do this, see attached patch. It's code is double-ready and does not depend on anything else than m_pd.h. Still it's output makes no sense in pd-double. Apparently, the build rules for the external classes do not include the PD_FLOAT_PRECISION definition.. For this reason, it is at the moment not opportune to announce pd-double ready for testing. If people would really start testing now, a tsunami of bug reports could follow, many of which boil down to this single wrong macro definition. We better avoid such needless administrative hassle. Katja p.s. I was talking about the Pd-0.43.1-double-20111009-macosx106-x86_64.dmg build, which has double precision core. The build in Pd-0.43.1-double-20111010-macosx106-x86_64.dmg crashes at startup on OSX 10.5: Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0 Dyld Error Message: unknown required load command 0x80000022

2 3

CLR loader in Pd-extended?
by Hans-Christoph Steiner 13 Oct '11

13 Oct '11

Now that Martin has nailed now pdlua and its loaded by default in Pd- extended 0.43, and Federico is fixing the last bugs in tclpd and it'll be loaded by default soon, I also remember that Thomas Grill wrote the CLR loader for languages like C#. Thomas, or anyone, what's the status of that? Anyone interested in getting it ready for inclusion into Pd-extended? It needs to build and load on all platforms, that's the jist of it. .hc ---------------------------------------------------------------------------- If you are not part of the solution, you are part of the problem.

1 0

recent pd-double nightly builds crash at start up
by katja 12 Oct '11

12 Oct '11

Hans, pd-double x86_64 nightly builds crash on my computer since two days (10 and 11 October builds). The latest one I can load is Pd-0.43.1-double-20111009-macosx106-x86_64.dmg. What has changed since then? Your latest commit to pd-double was yesterday 10 October, but that was after 10 October's nightly build, no? I can't imagine what can be the cause. Can you load the latest build without crash? report: Date/Time: 2011-10-11 22:45:53.472 +0200 OS Version: Mac OS X 10.5.8 (9L31a) Report Version: 6 Anonymous UUID: 0E22D77C-7F8E-4A17-8200-99C7F4155E8D Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0 Dyld Error Message: unknown required load command 0x80000022 Katja

2 4

"load every help" logs now posted to autobuild.puredata.info
by Hans-Christoph Steiner 12 Oct '11

12 Oct '11

Hey all, I've been working a bit on some testing scripts for Pd-extended. Currently, the main one is load_every_help.py, which does just that: it loads every help file included in Pd-extended, and checks the output. If there is output, it adds that output to the log. The log is uploaded to the auto-build site for that day. http://autobuild.puredata.info/auto-build/2011-10-11/logs/load_every_help_m… Here, for example, you can see lots of interesting things in the 10.6 64-bit build. For example: loading: /Users/pd/auto-build/pd-extended/packages/darwin_app/build/ Pd-0.43.1-extended-20111011.app/Contents/Resources/extra/bsaylor/pvoc~- help.pd warning: extern using garray_getfloatarray() won't work in 64-bit version And here is the use of a function deprecated in 10.5 and removed in 10.6: /Users/pd/auto-build/pd-extended/packages/darwin_app/build/Pd-0.43.1- extended-20111011.app/Contents/Resources/extra/apple/ ambient_light_sensor.pd_darwin: dlopen(/Users/pd/auto-build/pd- extended/packages/darwin_app/build/Pd-0.43.1-extended-20111011.app/ Contents/Resources/extra/apple/ambient_light_sensor.pd_darwin, 10): Symbol not found: _IOConnectMethodScalarIScalarO Referenced from: /Users/pd/auto-build/pd-extended/packages/ darwin_app/build/Pd-0.43.1-extended-20111011.app/Contents/Resources/ extra/apple/ambient_light_sensor.pd_darwin Expected in: dynamic lookup ambient_light_sensor error: ... couldn't create .hc ---------------------------------------------------------------------------- "Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman

1 0

loadbang and sys_vgui
by Jonathan Wilkes 11 Oct '11

11 Oct '11

Hi, I've run into an issue with my tooltips when using manual mode: [loadbang] | [tip 1 hello( | [s foo] [namecanvas foo] This creates a window with a label that has the text "hello". But when loadbang'd the label is set too narrow. The text displayed like this: h e l l o In testing I found I have to use a [del 200] to get the text to display correctly. Seems like the dimensions of the patch window aren't fully set at loadbang time. Any advice on a way to make it display correctly when loadbang'd? Patch is at: https://sourceforge.net/tracker/?func=detail&aid=3383472&group_id=55736&ati… -Jonathan

2 3

[ pure-data-Patches-3421335 ] Bug in bonk~ for Max/MSP
by SourceForge.net 11 Oct '11

11 Oct '11

Patches item #3421335, was opened at 2011-10-10 21:06 Message generated for change (Tracker Item Submitted) made by pfaffian You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421335&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Anthony Lauzon (pfaffian) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in bonk~ for Max/MSP Initial Comment: The file handle allocator was not allocating the right amount of memory for the input file. This patch fixes that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421335&group_…

1 0

[ pure-data-Patches-3421072 ] Streamline s_utf8.c
by SourceForge.net 10 Oct '11

10 Oct '11

Patches item #3421072, was opened at 2011-10-10 03:03 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421072&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marvin Humphrey (creamygoodness) >Assigned to: Miller Puckette (millerpuckette) Summary: Streamline s_utf8.c Initial Comment: There are a number of UTF-8 manipulation routines which were included when the library was added with the justification that they might be used someday. However, time has passed, they are still unused, and some of them have bugs -- so it is time to delete them with a justification of YAGNI (You Ain't Gonna Need It). ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-10-10 16:31 Message: Ok, I say this is ready for Miller to accept, so I'm assigning it to him. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-10-10 16:25 Message: Bryan Jurish: > I didn't see any fix for the NUL-termination problems I saw suggested > on the #dataflow transcript though (and I never noticed any such > segfaults myself): has that problem been confirmed? The NUL-termination problems for u8_inc(), u8_charnum() and u8_offset() were fixed under a different issue: http://sourceforge.net/tracker/?func=detail&atid=478072&aid=3420484&group_i… Those functions were all capable of overrunning the end of a non-NUL-terminated string; u8_offset() could potentially return an incorrect answer depending on what it found there. I never duplicated the segfault myself using the steps that Matthieu described in #dataflow; however, it was very easy to detect the invalid reads by running Pd under Valgrind. If I tried hard I might be able to trigger a segfault consistently by carefully crafting bytes to trick u8_offset() into giving too big a number, resulting in a cursor location beyond the end of a string rather than at the end of a string. In any case, the patch both eliminated the invalid reads *and* sped things up, so I think it was justified even without a consistently segfaulting test case. I suspect that u8_inc_ptr() has problems similar to u8_inc() -- but since it does not seem to be used anywhere at present, I haven't put any time into diagnosing or fixing it. Instead, this patch removes it altogether. We can resurrect it from version control if a need arises in the future and vet it at that time. The patches attached to this issue should be low-risk, as all they do is remove functionality rather than change behaviors. The removed symbols are unused by Vanilla, and seem also to be unused by Pd-extended. The risk is that I missed some usage somewhere, resulting in link-time failure. ---------------------------------------------------------------------- Comment By: Bryan Jurish (mukau) Date: 2011-10-10 15:16 Message: Looks good to me. I can't test anything right now, but Martin's suggestions seem safe and clear. Give it a whirl... I didn't see any fix for the NUL-termination problems I saw suggested on the #dataflow transcript though (and I never noticed any such segfaults myself): has that problem been confirmed? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-10-10 12:37 Message: Makes sense to me. I'm assigning it to Bryan Jurish, the original author of the UTF-8 support, to see if he agrees. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421072&group_…

1 0

[ pure-data-Patches-3421072 ] Streamline s_utf8.c
by SourceForge.net 10 Oct '11

10 Oct '11

Patches item #3421072, was opened at 2011-10-10 07:03 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421072&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marvin Humphrey (creamygoodness) Assigned to: Bryan Jurish (mukau) Summary: Streamline s_utf8.c Initial Comment: There are a number of UTF-8 manipulation routines which were included when the library was added with the justification that they might be used someday. However, time has passed, they are still unused, and some of them have bugs -- so it is time to delete them with a justification of YAGNI (You Ain't Gonna Need It). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-10-10 20:25 Message: Bryan Jurish: > I didn't see any fix for the NUL-termination problems I saw suggested > on the #dataflow transcript though (and I never noticed any such > segfaults myself): has that problem been confirmed? The NUL-termination problems for u8_inc(), u8_charnum() and u8_offset() were fixed under a different issue: http://sourceforge.net/tracker/?func=detail&atid=478072&aid=3420484&group_i… Those functions were all capable of overrunning the end of a non-NUL-terminated string; u8_offset() could potentially return an incorrect answer depending on what it found there. I never duplicated the segfault myself using the steps that Matthieu described in #dataflow; however, it was very easy to detect the invalid reads by running Pd under Valgrind. If I tried hard I might be able to trigger a segfault consistently by carefully crafting bytes to trick u8_offset() into giving too big a number, resulting in a cursor location beyond the end of a string rather than at the end of a string. In any case, the patch both eliminated the invalid reads *and* sped things up, so I think it was justified even without a consistently segfaulting test case. I suspect that u8_inc_ptr() has problems similar to u8_inc() -- but since it does not seem to be used anywhere at present, I haven't put any time into diagnosing or fixing it. Instead, this patch removes it altogether. We can resurrect it from version control if a need arises in the future and vet it at that time. The patches attached to this issue should be low-risk, as all they do is remove functionality rather than change behaviors. The removed symbols are unused by Vanilla, and seem also to be unused by Pd-extended. The risk is that I missed some usage somewhere, resulting in link-time failure. ---------------------------------------------------------------------- Comment By: Bryan Jurish (mukau) Date: 2011-10-10 19:16 Message: Looks good to me. I can't test anything right now, but Martin's suggestions seem safe and clear. Give it a whirl... I didn't see any fix for the NUL-termination problems I saw suggested on the #dataflow transcript though (and I never noticed any such segfaults myself): has that problem been confirmed? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-10-10 16:37 Message: Makes sense to me. I'm assigning it to Bryan Jurish, the original author of the UTF-8 support, to see if he agrees. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421072&group_…

1 0

[ pure-data-Patches-3421072 ] Streamline s_utf8.c
by SourceForge.net 10 Oct '11

10 Oct '11

Patches item #3421072, was opened at 2011-10-10 09:03 Message generated for change (Comment added) made by mukau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421072&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marvin Humphrey (creamygoodness) Assigned to: Bryan Jurish (mukau) Summary: Streamline s_utf8.c Initial Comment: There are a number of UTF-8 manipulation routines which were included when the library was added with the justification that they might be used someday. However, time has passed, they are still unused, and some of them have bugs -- so it is time to delete them with a justification of YAGNI (You Ain't Gonna Need It). ---------------------------------------------------------------------- >Comment By: Bryan Jurish (mukau) Date: 2011-10-10 21:16 Message: Looks good to me. I can't test anything right now, but Martin's suggestions seem safe and clear. Give it a whirl... I didn't see any fix for the NUL-termination problems I saw suggested on the #dataflow transcript though (and I never noticed any such segfaults myself): has that problem been confirmed? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-10-10 18:37 Message: Makes sense to me. I'm assigning it to Bryan Jurish, the original author of the UTF-8 support, to see if he agrees. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421072&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev October 2011