Pd-dev September 2018

pd-dev@lists.iem.at

13 participants
34 discussions

Re: [PD-dev] roadmap for Pd-0.49?
by Dan Wilcox 11 Sep '18

11 Sep '18

> On Sep 10, 2018, at 11:02 PM, pd-dev-request(a)lists.iem.at wrote: > > Date: Mon, 10 Sep 2018 12:19:09 -0700 > From: Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> > > To Pd dev - > > I've finally got a version of Tck/Tk 8.5 patched for macintosh to work around > the key-up bug (by back-porting the bugfix from 8.6 and then making a > further mod - the fix is on msp.ucsd.edu/tmp/misc/tk8.5.19-pd49-src.tar.gz <http://msp.ucsd.edu/tmp/misc/tk8.5.19-pd49-src.tar.gz> > if anyone else wants to try it. Sweet. I had forgotten about this. The fix seems to work. I built a 8.5.19 Wish.app for macOS and created a Pd.app using it. If anyone wants to test: http://docs.danomatika.com/pdbuilds/Pd-0.48-2-tk8519-keyfix.zip <http://docs.danomatika.com/pdbuilds/Pd-0.48-2-tk8519-keyfix.zip> Two suggestions on integrating this "custom version" for the release so people can also build Pd with this fix on macOS: 1. Update the default macOS Wish used for Pd: build a new Wish.app to replace the Tk 8.4 "Wish Shell.app" in mac/stuff/wish-shell.tgz. The mac/osx-app.sh script can already handle both "Wish.app" and "Wish Shell.app" naming and the default "make app" result would be to build using this new Tk 8.5 version. If you haven't tried yet, you can build Wish using the mac/tcltcl-wish.sh and pre-downloaded src folders for both tcl and tk using: ./tcltk-wish.sh --build --leave 8.5.19 This will skip downloading the sources and build using the "tcl8.5.19" and "tk8.5.19" folders. The "--leave" flag is important, otherwise the script will remove the folders after it's done. I used this to build a Wish-8.5.19.app using your tk src tarball by first downloading the sources using the script, then replacing the tk src folder with yours. You can download without building using: ./tcltk-wish.sh --download 8.5.19 2. Automatically apply our custom patch when building Tk 8.5.19 for macOS: I generated a diff from the tk source tree changes which could be applied by patch in the tcltk-wish.sh script when building 8.5.19 *only*. As 8.5.19 is basically EOL for now, it should be able to apply cleanly. Since you have the older build machine, I think it's better if you build Wish.app for #1. I can do #2, if wanted. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

declare (again)
by Antoine Rousseau 11 Sep '18

11 Sep '18

I'm also very enthusiast with the new version to come! One thing (among many others!) makes me very happy: the new behavior of [declare -path]. Pd now finds any declared library, wherever the user chose to place it, provided the location (of the library directory) is either relative, standard, or declared in preferences. I think this is the way to build portable patches and abstractions. I would like to propose some steps further: - 1: I think we should now discourage patch builders from using -stdpath or -stdlib, as it would restrain the portability of their patches; this is only a matter of rewriting (one more time...) the declare help patch. - 2: why not introducing a new [declare] functionality, which would allow to avoid the flag (-path -lib -stdpath -stdlib) and cumulate -lib and -path declarations. So we would have for instance: [declare zexy iemlib] instead of [declare -path zexy -lib zexy -path iemlib -lib iemlib] This would in some way resuscitate the old [import] from pd-extended. It seems it's a relatively easy code change, so it's more a matter of decision. It seems to me that the community would benefit from adopting rapidly a new unified way to declare any library, whether binary or abstraction. Antoine Rousseau http://www.metalu.net <http://metalu.net> __ http://www.metaluachahuter.com/ <http://www.metaluachahuter.com/compagnies/al1-ant1/>

1 1

roadmap for Pd-0.49?
by Christof Ressi 11 Sep '18

11 Sep '18

Hi Miller, I just wanted to ask what's your approximate roadmap for Pd 0.49? Do I need to hurry up if I want to propose stuff or is there plenty of time left? :-) Christof

5 18

Re: [PD-dev] roadmap for Pd-0.49?
by Miller Puckette 11 Sep '18

11 Sep '18

To Pd dev - I've finally got a version of Tck/Tk 8.5 patched for macintosh to work around the key-up bug (by back-porting the bugfix from 8.6 and then making a further mod - the fix is on msp.ucsd.edu/tmp/misc/tk8.5.19-pd49-src.tar.gz if anyone else wants to try it. Meanwhile I'm hoping to get 0.49 test1 out today - to do this I'll grab whatever small and uncontroversial PRs I can fold in without too much conflick-resolving and go on and compile everything. Some larger issues are still hanging, for instance, the dollar-zero idea - I don't think I can get these resolved quickly. Also, I have some difficulties dealing with PRs in general that I'd like to open a discussion about in another thread. Meanwhile, going forward, if I've mis-applied PRs (which I bet I have), I'm happy to try to resolve them during the test period, and I'm happy to try to fix remaining reported bugs (when the fix doesn't seem to risk introducing new problems) and merge bug-fixing PRs. cheers - and thanks to everyone who has contributed! Miller

2 2

Re: [PD-dev] roadmap for Pd-0.49?
by Dan Wilcox 10 Sep '18

10 Sep '18

I'd say this is a "paper cut." It's a small issue easily worked around by the addition of an extra step, but that extra step is painful due to it's repetition. Also, I've seen it be a confusing step for many beginners once they learn to use $0 in objects, ie [f $0], [symbol $0], etc. I'm on the side of $0 in message boxes. I don't see how this change would break anything since $0 currently resolves to 0 (I think), and I cannot imagine anyone relying on this. Is it a controversy? > On Sep 4, 2018, at 9:41 AM, pd-dev-request(a)lists.iem.at wrote: > > Date: Mon, 3 Sep 2018 21:02:39 -0700 > From: Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> > To: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > Cc: Henri Augusto Bisognini <msndohenri(a)hotmail.com <mailto:msndohenri@hotmail.com>>, pd-dev > <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] roadmap for Pd-0.49? > Message-ID: <20180904040239.GF25025(a)ucsd.edu <mailto:20180904040239.GF25025@ucsd.edu>> > Content-Type: text/plain; charset=us-ascii > > This one is mired in controversy. Meanwhile, you can get "$0" functionality > in a message box by preceeding it with "list prepend $0" so that $1 in the > message box is teh patch's $0 and the other $ arguments are renumbered by one. > > cheers > Miller -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Re: [PD-dev] savestate
by Dan Wilcox 10 Sep '18

10 Sep '18

What I was implying, then, is that if [savestate] brings this kind of functionality, albeit tangentially, then why not include specific [initbang] and [closebang] objects as well? That would solve a longstanding feature request without kludging the [savestate] mechanism which may/or may not change. > On Sep 8, 2018, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Date: Fri, 7 Sep 2018 22:04:14 +0200 > From: IOhannes m zmölnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] savestate > Message-ID: <0fc97332-28de-103d-22ab-61433ae33c77(a)iem.at <mailto:0fc97332-28de-103d-22ab-61433ae33c77@iem.at>> > Content-Type: text/plain; charset="utf-8" > > On 9/3/18 3:35 PM, Dan Wilcox wrote: >> Also, does the right outlet effectively act as a "save bang"? This might be tangentially useful for some data structure abstractions... > > what i find even more exiting, is that the left outlet effectively acts > as an "init bang", finally allowing you to create abstractions with a > dynamic number of iolets in Pd-vanilla (in a way that survives saving > both the abstraction and its containing patch). > > gfmard > IOhannes -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Fwd: bug in dollar sign handling
by Antoine Rousseau 07 Sep '18

07 Sep '18

Hi, dollar sign handling seems currently broken on master: [b]-[symbol $0-$0]-[print] returns: print: symbol 1003-\\$01003 I guess it could come from the recent backslashes related additions.

2 3

Re: [PD-dev] [PD] Setting Code::Blocks (MinGW64) to compile pd externals
by Christof Ressi 05 Sep '18

05 Sep '18

just to show you, how simple it is. this is how a complete makefile with pd-lib-builder might look like: --- # Makefile for mylib lib.name = mylib class.sources = myclass1.c myclass2.c datafiles = myclass1-help.pd myclass2-help.pd README.txt LICENSE.txt include Makefile.pdlibbuilder --- and building your external is as simple as: > cd /path/to/source > make PDDIR=/path/to/pd Christof > Gesendet: Mittwoch, 05. September 2018 um 16:33 Uhr > Von: "IOhannes m zmoelnig" <zmoelnig(a)iem.at> > An: pd-list(a)lists.iem.at > Betreff: Re: [PD] Setting Code::Blocks (MinGW64) to compile pd externals > > On 2018-09-05 16:25, alfonso santimone wrote: > > I have no good knowledge of cmake. > > to repeat christophs advice: > >> in your case I'd strongly suggest to use the pd-lib-builder makefile > >> template: https://github.com/pure-data/pd-lib-builder > > > Coding for pd and max is always a moving target :-D > > that's a bit far-fetched for an API that has been pretty stable for > about 20 years. > > fgasmkdr > IOhannes > > _______________________________________________ > Pd-list(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list >

1 0

Re: [PD-dev] keep master on github stable
by Dan Wilcox 04 Sep '18

04 Sep '18

OpenFrameworks initially keep the master branch on the latest stable release and used a develop branch for active work. However, this led to many situations where submitters inadvertently did work on their copy of the develop branch and submitted PRs to the master branch. This led to all sorts of issues, especially to newer developers starting out with git. Thankfully it's *much* easier to change the PR branches now, but it still leads to confusion. For a project where users *only* really build the source code (ie. software libraries), then the "master as stable" approach is useful as it means the default clone is always stable. For projects where the majority of users download pre-built binaries (ie. Pd), I think "master as develop" makes sense since most people cloning will be building/developing the software and those that aren't can checkout a stable tag. So the emphasis is based on the predominant use case: in the former, the master as the release and the latter uses master as develop. > On Sep 4, 2018, at 4:53 AM, pd-dev-request(a)lists.iem.at wrote: > > Date: Tue, 4 Sep 2018 04:52:58 +0200 > From: "Christof Ressi" <christof.ressi(a)gmx.at <mailto:christof.ressi@gmx.at>> > To: "Miller Puckette" <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> > Cc: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] keep master on github stable > Message-ID: > <trinity-24063e5f-6755-4798-b27d-4d08994e7ee5-1536029578754@3c-app-gmx-bs59> > > Content-Type: text/plain; charset=UTF-8 > > I see. The reason I was asking is that many OSS projects have both master and develop branches so people can choose between the latest stable version and the newest stuff (accepting possible regressions). So all the real work would happens on the develop branch and whenever a release is out (after the feedback and bug fixes from the test releases) the master branch gets updated. but this is just an idea for the future. don't bother now :-) > > Christof -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 3

keep master on github stable
by Christof Ressi 04 Sep '18

04 Sep '18

hi, just a small question/suggestion: wouldn't it be better if we keep the current master on github to the last stable release (i.e. 0.48.2) and use a dedicated development branch for adding things? Christof

2 2

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