Pd-dev February 2018

pd-dev@lists.iem.at

14 participants
18 discussions

JIT expr/expr~/fexpr~ clones
by Alex 11 Feb '18

11 Feb '18

With an interest of playing with LLVM based just in time compiling I made a clone of the [expr] family of objects that parses, compiles and then executes the compiled code versions of the expressions you provide it. It could still use a little cleanup but I believe it has all of the features of the cloned objects now, plus a [print( message to print out the generated LLVM assembly. I'm curious if anyone has some CPU intensive expr~ or fexpr~ examples that I could try to benchmark these against? Also, does anyone have a good benchmarking solution for pd? Anyways, if you're interested in checking it out the source is here: https://github.com/x37v/jit-expr I'll submit a deken package once its been tested enough, I resolve a couple questions I have about potential memory leaks and finalize the licensing. -Alex

1 0

Re: [PD-dev] pdlibbuilder and static linking pthread by, default on Windows.
by Dan Wilcox 08 Feb '18

08 Feb '18

You can use the same setup as compiling Pd on Windows. We recently did a bunch of work to make this possible and I documented the build setup: https://github.com/pure-data/pure-data/pull/299/files#diff-48d1bc6644af8a5b… <https://github.com/pure-data/pure-data/pull/299/files#diff-48d1bc6644af8a5b…> It should work with externals + pdlibbuilder and might be good for pdlibbuilder to point to this section in the INSTALL.txt. > On Feb 6, 2018, at 6:02 PM, pd-dev-request(a)lists.iem.at wrote: > > It would be nice if the 'official' tool chain for building externals that > work with vanilla Pd on a Windows machine in 2018 could be explicitly > documented somewhere. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

5 9

pdlibbuilder and static linking pthread by default on Windows.
by Lucas Cordiviola 07 Feb '18

07 Feb '18

We have been working on pdlibbuilder and I've proposed static linking pthread by default. https://github.com/pure-data/pd-lib-builder/issues/42 https://github.com/pure-data/pd-lib-builder/issues/36 My motivation on doing such thing is to prevent people from forgetting to ship libwinpthread-1.dll when needed. There are many chances for this to happen as when we test an compiled [external] it will be working with Pd's libwinpthread-1.dll so we might think that everything is OK. Also people from linux & osx are not really aware that on Windows/MinGW pthread is an specific file. This in turn will let the [external] survive when Pd, in some future, will start using a future MinGW pthread implementation. We discussed this but IOhannes & Dan see static linking as something horrible. I see that there's no difference in shipping the file or statically include it in the [external]. I also tested that [externals] that don't use pthread are immune to the -static flag. Is there something I'm missing? Why not putting a "lifebuoy" by default ? If a dev does not want -static he/she can override it. Some thoughts? community ? I ask this because I care about Windows Pd and [externals]. -- Mensaje telepatico asistido por maquinas.

3 11

Multithreading support for FFT functions
by Pierre Guillot 07 Feb '18

07 Feb '18

Hi, As IOhannes pointed it in this Github pull request ( https://github.com/pure-data/pure-data/pull/81), the FFT functions in d_fft_fftsg.c are not thread-safe. An easy fix would be to set the static variables TLS (*PERTHREAD*). (It doesn't solve the "size problem" of the original pull request but it can be complementary). If it seems good for you, I will add this to the pull request dedicated to the multi-instance/multithreading problems on Github ( https://github.com/pure-data/pure-data/pull/288). Another solution would be to integrate these static variables in the pd instance structure (and to allocate the memory for each instance)? Nevertheless, this second solution would add some code pretty useless if someone use the FFTW wrapper. But is anybody using the FFTW wrapper (d_fft_fftw.c)? If this second solution seems more suitable, I can create a new pull request. Cheers, Pierre

1 0

Re: [PD-dev] Pd-dev Digest, Vol 155, Issue 4
by Dan Wilcox 06 Feb '18

06 Feb '18

CFLAGS works fine via make CFLAGS="-O0 -g" as CFLAGS propagate into CXXFLAGS, as I would expect. I think it was a PEBKAC issue where I was probably misspelling CFLAGS as CLFAGS, was rushed, and didn't notice. > this seems to be related to the confusion of CFLAGS, CPPFLAGS and CXXFLAGS. > - CPPFLAGS flags for the C PreProcessor (and C++ and objective C/C++ > preprocessors) > - CFLAGS flags for the C compiler > - CXXFLAGS flags for the C++ compiler > > since abl_link~ is a C++-external, the CFLAGS don't have any effect and > you should use CXXFLAGS instead. > > gmasdr > IOhannes -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

pdlibbuilder overrides
by Dan Wilcox 05 Feb '18

05 Feb '18

I was trying to make a quick test build of an external which uses pdlibbuilder (abl_link~) and wanted to simply disable optimizations and enable debug symbol generation. I tried a simple CFLAG override but it didn't seem to work: make CFLAGS="-O0 -g" How do override work with pdlibbuilder? Usually, I would expect this to at least append "-O0 -g" to the end of the computed CFLAGS. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 3

gui opt_parser.tcl?
by Dan Wilcox 03 Feb '18

03 Feb '18

Does the gui opt_parser handle anything guis-specific or does it forward argv to the pd core? I'm trying to start the gui directly with commandline args on macOS but it always throws an "unknown option" error on any of the standard core options. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Multi-instance support for key objects
by Pierre Guillot 01 Feb '18

01 Feb '18

Hi, The objects [key], [keyup] and [keyname] can't be used in a multi-instance context. The are bound to **static** symbols generated in the setup() methods so it breaks the multi-instance support. I added a commit to fix this on this Github PR: https://github.com/pure-data/pure-data/pull/288.The PR already integrated the fix for the stack count issue. I hope it's fine for you if I make all my multi-instance and multi-thread corrections in this issue, otherwise I can split everything in separate PR. Cheers, Pierre

1 0

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 February 2018