Ah, good point. Doing a string look up might not be the best thing, although maybe we can check performance metrics. It's not like there isn't string handling going on already and I doubt that gettext is doing allocations during a lookup.
> On Sep 13, 2018, at 5:40 PM, pd-dev-request(a)lists.iem.at wrote:
>
> 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] translation push
> Message-ID: <af76dab3-e406-004d-54dd-3be83d69f3b4(a)iem.at <mailto:af76dab3-e406-004d-54dd-3be83d69f3b4@iem.at>>
> Content-Type: text/plain; charset="utf-8"
>
> On 9/13/18 3:00 PM, Dan Wilcox wrote:
>> For the developers, could we consider building Pd with gettext support in the core? Then we could translate most of the internal strings without having to resort to string matching on the GUI side.
>
>
> what would be the benefit of that?
> conceptually, i *quite* like the idea of not doing translation work in
> the audio thread.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
Howdy all,
After the dust settles form the 0.49 release, I think it would be good to have a translation push. deken and the new editing functionality have brought some more strings and most of the languages are really just skeletons from Pd-extended. Those of us that are teaching may be able to ask some international students for help on this and it's relatively easy for non-developers to use poedit.
For the developers, could we consider building Pd with gettext support in the core? Then we could translate most of the internal strings without having to resort to string matching on the GUI side.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
Howdy Miller and all,
Just some quick thoughts on git & github workflows for Pd.
Github is useful in that it makes contributing to a project's codebase easier without needing direct access using it's "Pull Request" mechanism. AFAICT, this is something *possible* using just git, but GitHub makes it relatively *painless*. I think it's great to see, at this point, many more people now contributing to Pd but, of course, how do we handle this?
Some observations/ideas:
1. Master branch as develop: The master branch is kept the same between the sourceforge "upstream" and the GitHub "mirror." So far we've managed to keep that true and Miller is the only one moving work from GitHub branches and PRs into "upstream."
2. Release schedule: Since we're on a yearly release schedule, with (possible) bug fixes after about 6 months, PRs and branches now build up on Github in the meantime. This is good. Mostly, we've managed to keep these relatively isolated from each other so they can apply cleanly. This is not always possible, however, for some things (for example, the recent const qualifier additions).
3. Merge order: I think what's important, then, is merge order. The smaller PR's that only touch unconnected files should be merged first. The larger PR's that touch *many things* should be merged later and, only after their author's have updated their branch by merging it with the now updated master. This should make things merge cleanly.
4. Using Github: The PR mechanism on Github also tools to gauge how the proposed changes will affect the codebase. The diffs and commit listing is useful as well as the result of the continuous integration build that IOhannes set up. You can basically see, at a glance, if the PR will merge cleanly or not. If everything is good, the easiest solution is really to use the green "Merge" button on the PR page, then pull those changes from the Github mirror to the upstream sourceforge repo. The push and pull can go *both* ways, with the addition of using the tools that make this easier. (If anyone is in the "I hate GitHub" camp, the same workflow is true with using Merge Requests in Gitlab.)
5. Feedback: As PR authors, we want to help you, Miller! If you're considering merging some work but want a few changes, no problem. Let us know in the PR discussion and someone will probably do it. Then we can make sure the PR branch is up to date and will merge cleanly. Again, the green "Merge" button is easy and useful here. Ideally, all you would need to do to integrate most things, is just hit "Merge" a few times and then pull the changes for the Github mirror.
6. Making changes: In my own Github projects, oftentimes someone gives me a PR which I want, but I will probably change a few details here and there. I usually handle this by merging it on the PR page, pulling, then making a cleanup commit later. This is usually easier than cherry-picking some commits and manually applying parts of others. Again, this works well for small things but not for larger stuff. In the latter case, giving feedback until you are satisfied with the proposed diff is the way to go.
7. Testing before merging: This is possible by adding the PR author's repo as a remote and then pulling whatever branch (master or otherwise) they submitted the PR with. This allows you to essentially do a checkout of their PR branch that you can build locally. I haven't needed to do it myself very often, but it has been useful in providing feedback and updates. There is also a mechanism to make commits to *their* branch before actually accepting the PR, but that's something more GitHub specific through their authentication setup.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
I'm seeing the same on macOS 10.13.6. This is a crash in the GUI and seems to be something to do with the Tk version as running PD with the built-in version of Tk on my system works fine.
> On Sep 12, 2018, at 12:20 AM, pd-dev-request(a)lists.iem.at wrote:
>
> From: jakob skouborg <syntaxerror60(a)hotmail.com <mailto:syntaxerror60@hotmail.com>>
>
> but I think I might have experienced a bug here on OSX 10.10.5(Yosemite):
>
> - When I do a “save as” and I type in the name in the save dialog and then push “ Save as” button, PD crashed. I have not been able to save a patch yet.
>
> Can anyone replicate?
>
> Thanks and have a great evening ;)
>
> Jakob(Jaffasplaffa)
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
Howdy all,
One important point for 0.49 would be to finish off the cross platform font support started in 0.48. The last bit involves loading the included font on Windows and I wrote a tiny Tcl C extension for this which does not require any external extensions. We simply need to integrate it into the Windows package and load it before loading the fonts. The easiest solution is to add a pre-built pdfontloader to the msw/pdprototype.tgz bin directory. Also, the notes in font/README.tcl could be updated to match.
The code and info on how to make it work are all here: https://github.com/pure-data/pdfontloader <https://github.com/pure-data/pdfontloader>
I don't currently have a Windows install, so maybe Christof can help with this? *hint hint*
We could integrate this small codebase into the msw directory and include it in the build process as well, but that could also be left for later.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
Howdy Miller,
The new experimental [savestate] object looks pretty cool! I know you mentioned some ideas about this in June, but I'm pleasantly surprised to see the object now. :)
The help patch says it can send/receive multiple list messages. I've not tried yet, but does this mean it saves multiple #A saved ... lines to the patch file? If so, that's pretty useful as it allows for simple 1 line objects and advanced objects which save using key-value pairs. I have a number of both and look forward to dropping all the save state list processing I'm currently doing.
Also, does the right outlet effectively act as a "save bang"? This might be tangentially useful for some data structure abstractions...
In any case, I will try adapting some of my objects and give further feedback.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
Actually, that's not a bad idea at the expense of a little more searching. [declare] then behaves more like the lua loader which searches for both binary and script modules, which I find relatively easy to use. I don't think this would break existing patches and would also honor the relative path restrictions for self contained projects, where specifying a relative path starting with ./ or ../ only searches locally.
> On Sep 11, 2018, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Date: Tue, 11 Sep 2018 11:42:00 +0200
> From: Antoine Rousseau <antoine(a)metalu.net <mailto:antoine@metalu.net>>
> To: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>>
> Subject: Re: [PD-dev] declare (again)
> Message-ID:
> <CAOCG5Hx19cSDb5GkJ2onAtY8OU_XaQOZs28qXGn=8JZSi1ELKw(a)mail.gmail.com <mailto:CAOCG5Hx19cSDb5GkJ2onAtY8OU_XaQOZs28qXGn=8JZSi1ELKw@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
>>
>> relatively easy code change
>>
>
> ... so I propose step 2 as PR #440 !
>
> cheers
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> 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/>
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/>
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