Re: [PD] [PD-announce] pd 0.48-0test1 released

[Miller Puckette]

I'm baffled so far.  I notice that your patch misbehaves in commit
82adaf15f0ff2928c26e261b76d1d5ed809d5788 - the subpatch creeps up one
pixel each time.  Then after the next commit, 
dfbfc754b30e26da2d105fa85cb73152ce9e40b5, the patch jumps down about
the height of the menu bar each time.  The difference is the addition
of these lines:

+ 
+ # on X11 measure the size of the window decoration, so we can open windows
+ if {$::windowingsystem eq "x11"} {
+ regexp -- {([0-9]+)x([0-9]+)\+([0-9]+)\+([0-9]+)} [wm geometry .pdwind
+ _ _ _left _top
+ set ::windowframex [expr {[winfo rootx .pdwindow] - $_left}]
+ set ::windowframey [expr {[winfo rooty .pdwindow] - $_top}]
+ }
... but those are teh same lines that were added in commit f0703a40810,
and sometime between f0703a40810 and 82adaf15f0f (feb 16 and June 22) they
got taken out again.

So those lines were present ina "good" version, then gone in a "slightly
bad" one, then got reinstated and made things worse than before.  They
must be interacting with sonething else, but I don't know what.

M

> Hey all
> 
> I'm experiencing window position troubles on X11 (Ubuntu 16.04,
> fluxbox). When loading patches in Pd 0.48 that were last saved with Pd
> 0.47, the windows appear at the correct positions. But when saving and
> reloading them on 0.48, they move upwards and slightly to the left on
> each cycle. Furthermore, when opening and closing subpatches, their
> windows move downwards by ~30 pixels on each cycle. This is a
> regression since the last Pd release.
> 
> IOhannes addressed window positioning on X11 with commit f0703a40810,
> which fixed almost all window positioning troubles know to me,  but its
> effect got lost soon after. I have troubles finding out what exactly
> broke it, but it might be a commit or merge that happened after Feb
> 2017. 
> 
> Attached is a patch that illustrates the canvas movement.
> 
> Roman
> 
> https://github.com/pure-data/pure-data/commit/f0703a408103fff236f5b
> 
> 
> On Fre, 2017-07-14 at 16:34 -0700, Miller Puckette wrote:
> > To Pd-announce:
> > 
> > The first test version of Pd 0.48 (source, adn compiled versions for
> > MacOS and Windows) is available at:
> > 
> > http://msp.ucsd.edu/software.htm
> > 
> > or (source code only) via github:
> > 
> > https://github.com/pure-data/pure-data
> > 
> > cheers
> > Miller
> > 
> > ___
> > Pd-announce mailing list
> > pd-annou...@lists.iem.at
> > https://lists.puredata.info/listinfo/pd-announce

> #N canvas 23 64 414 275 10;
> #N canvas 437 108 358 161 bla 1;
> #X restore 267 201 pd bla;
> #X obj 17 109 s pd-bla;
> #X obj 17 13 loadbang;
> #X obj 17 34 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1
> ;
> #X obj 17 56 metro 1000;
> #X msg 17 89 vis 0 \, vis 1;
> #X text 259 31 window is moving ->;
> #X connect 2 0 3 0;
> #X connect 3 0 4 0;
> #X connect 4 0 5 0;
> #X connect 5 0 1 0;




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


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

Re: [PD] [PD-announce] pd 0.48-0test1 released

[Miller Puckette]

Cool, that seems to be working... 

I think I'll have to confront fractional font sizes pretty soon - more and
more stuff is going to start breaking in TK 8.4.

cheers
Miller

P.S. I hope fatherhood and germany-moving-in are going well - thanks for
being so present on the list while all that's going on!

On Sun, Jul 16, 2017 at 10:34:30PM +0200, Dan Wilcox wrote:
> 
> > On Jul 16, 2017, at 9:38 PM, Miller Puckette  wrote:
> > 
> > Sure enough - with TK 8.5, font sizes are no longer integers; the
> > "font metrics" command appears to return the next-higher integer
> > sizes (thus throwing off box sizes and messing up selecting text within
> > boxes).
> > 
> > I'm not sure what to do - try to adapt Pd to deal with fractional font
> > sizes, or find some way to force TK 5 to use integer-sized fonts, or
> > just give up and use 8.4 for another cycle...
> 
> I'd say keep using the included Wish in mac/stuff. It's Tk 8.4 and still 
> works fine. Then we can work out the kinks in the sizing for the next release 
> and bring in Deja Vu Sans Mono cross platform. I was hesitant to push that 
> for this release as it obviously still needs some attention and testing. I've 
> tried a few fixes now and then, but nothing stuck so far. Frankly, there were 
> many other things that came up first.
> 
> > Incidentally, 8.4 isn't yet building on my MacOS 10.6... maybe I can just
> > include the system-provided one :)
> 
> Any mac TK 8.4 Wish will work, I think. The included one in mac/stuff or the 
> one bundled with macOS. The default behavior for "make app" is to use the 
> traditional, included one to match your previous releases. The system one can 
> be had with:
> 
> mac/osc-app.sh -s 8.4 0.48.0
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 

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

Re: [PD] [PD-announce] pd 0.48-0test1 released

[Dan Wilcox]

> On Jul 16, 2017, at 9:38 PM, Miller Puckette  wrote:
> 
> Sure enough - with TK 8.5, font sizes are no longer integers; the
> "font metrics" command appears to return the next-higher integer
> sizes (thus throwing off box sizes and messing up selecting text within
> boxes).
> 
> I'm not sure what to do - try to adapt Pd to deal with fractional font
> sizes, or find some way to force TK 5 to use integer-sized fonts, or
> just give up and use 8.4 for another cycle...

I'd say keep using the included Wish in mac/stuff. It's Tk 8.4 and still works 
fine. Then we can work out the kinks in the sizing for the next release and 
bring in Deja Vu Sans Mono cross platform. I was hesitant to push that for this 
release as it obviously still needs some attention and testing. I've tried a 
few fixes now and then, but nothing stuck so far. Frankly, there were many 
other things that came up first.

> Incidentally, 8.4 isn't yet building on my MacOS 10.6... maybe I can just
> include the system-provided one :)

Any mac TK 8.4 Wish will work, I think. The included one in mac/stuff or the 
one bundled with macOS. The default behavior for "make app" is to use the 
traditional, included one to match your previous releases. The system one can 
be had with:

mac/osc-app.sh -s 8.4 0.48.0


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] [PD-announce] pd 0.48-0test1 released

[Roman Haefeli]

Hey all

I'm experiencing window position troubles on X11 (Ubuntu 16.04,
fluxbox). When loading patches in Pd 0.48 that were last saved with Pd
0.47, the windows appear at the correct positions. But when saving and
reloading them on 0.48, they move upwards and slightly to the left on
each cycle. Furthermore, when opening and closing subpatches, their
windows move downwards by ~30 pixels on each cycle. This is a
regression since the last Pd release.

IOhannes addressed window positioning on X11 with commit f0703a40810,
which fixed almost all window positioning troubles know to me,  but its
effect got lost soon after. I have troubles finding out what exactly
broke it, but it might be a commit or merge that happened after Feb
2017. 

Attached is a patch that illustrates the canvas movement.

Roman

https://github.com/pure-data/pure-data/commit/f0703a408103fff236f5b


On Fre, 2017-07-14 at 16:34 -0700, Miller Puckette wrote:
> To Pd-announce:
> 
> The first test version of Pd 0.48 (source, adn compiled versions for
> MacOS and Windows) is available at:
> 
> http://msp.ucsd.edu/software.htm
> 
> or (source code only) via github:
> 
> https://github.com/pure-data/pure-data
> 
> cheers
> Miller
> 
> ___
> Pd-announce mailing list
> pd-annou...@lists.iem.at
> https://lists.puredata.info/listinfo/pd-announce#N canvas 23 64 414 275 10;
#N canvas 437 108 358 161 bla 1;
#X restore 267 201 pd bla;
#X obj 17 109 s pd-bla;
#X obj 17 13 loadbang;
#X obj 17 34 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1
;
#X obj 17 56 metro 1000;
#X msg 17 89 vis 0 \, vis 1;
#X text 259 31 window is moving ->;
#X connect 2 0 3 0;
#X connect 3 0 4 0;
#X connect 4 0 5 0;
#X connect 5 0 1 0;


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.48-0test1 released

[Miller Puckette]

Sure enough - with TK 8.5, font sizes are no longer integers; the
"font metrics" command appears to return the next-higher integer
sizes (thus throwing off box sizes and messing up selecting text within
boxes).

I'm not sure what to do - try to adapt Pd to deal with fractional font
sizes, or find some way to force TK 5 to use integer-sized fonts, or
just give up and use 8.4 for another cycle...

Incidentally, 8.4 isn't yet building on my MacOS 10.6... maybe I can just
include the system-provided one :)

M

On Sat, Jul 15, 2017 at 11:22:35PM +0200, Dan Wilcox wrote:
> I've added  a macOS 32bit 0.48.0-test1 build using the normal (old, included) 
> Tk 8.4 wish: http://docs.danomatika.com/pdbuilds/ 
> 
> 
> >> On Jul 15, 2017, at 11:02 AM, pd-list-requ...@lists.iem.at 
> >>  wrote:
> >> 
> >> I notice it looks quite differently in Mac OS, like there is a new font, 
> >> but it still seems it is Monaco. But the font size is smaller and the 
> >> boxes are thinner and wider. A subpatch will also have an extra space to 
> >> the right after the text/name of the subpatch.
> > 
> > You are seeing the retina rendering with a newer Tk, which still has those 
> > font issues as the rendered box size does not quite fit the font. I haven't 
> > been able to track down a fix yet.
> > 
> > It's weird, though, as this shouldn't be the default yet and Pd should 
> > still be using 8.4 which is pixelated on retina screens but has correct 
> > object sizing.
> > 
> > Miller, how did you build the mac distribution app?
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 

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


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

Re: [PD] [PD-announce] pd 0.48-0test1 released

[Jonathan Wilkes via Pd-list]

> The "bad" behavior is that, fro instance, 0 in gives 1 out.  That happened 
on everyone's machine except mine (so I was blissfully unaware that anything 
was wrong).  I'm running fedora linux.  Even debian linux machines gave the 
wrong answer while my machine kept giving me the right one.  Im not going 
to try to figure out what the #$&^ was going on :)

If someone can point clearly to the source of undefined behavior in that 
seemingly simple code then it would seem appropriate to just fix the bug 
and move on.

Otherwise it appears to be deterministic bug (excepting one unexplained 
edge case) that almost certainly has resulted in patches out in the wild 
behaving 
and/or sounding one way and not another. A compatibility case seems warranted 
for this.
-Jonathan

> M



On Sun, Jul 16, 2017 at 06:51:03PM +, Jonathan Wilkes via Pd-list wrote:
> > That's just the question - is it worth keeping an old bug available for 
> compatibility?  In this case, perhaps yes - although you'd have to 
> explicitly set a compatibility flag in Pd to get eh old behavior.
> 
> > (incidentally teh old behavior was machine-dependent - this complicates it 
> even further :)
> I didn't notice that it's machine-dependent-- it just appears as the wrong 
> algorithm 
> to me.
> 
> Is there undefined behavior there?
> -Jonathan

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



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

Re: [PD] [PD-announce] pd 0.48-0test1 released

[Miller Puckette]

The "bad" behavior is that, fro instance, 0 in gives 1 out.  That happened
on everyone's machine except mine (so I was blissfully unaware that anything
was wrong).  I'm running fedora linux.  Even debian linux machines gave the
wrong answer while my machine kept giving me the right one.  Im not going
to try to figure out what the #$&^ was going on :)

M

On Sun, Jul 16, 2017 at 06:51:03PM +, Jonathan Wilkes via Pd-list wrote:
> > That's just the question - is it worth keeping an old bug available for 
> compatibility?  In this case, perhaps yes - although you'd have to 
> explicitly set a compatibility flag in Pd to get eh old behavior.
> 
> > (incidentally teh old behavior was machine-dependent - this complicates it 
> even further :)
> I didn't notice that it's machine-dependent-- it just appears as the wrong 
> algorithm 
> to me.
> 
> Is there undefined behavior there?
> -Jonathan

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


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

Re: [PD] [PD-announce] pd 0.48-0test1 released

[Jonathan Wilkes via Pd-list]

> That's just the question - is it worth keeping an old bug available for 
compatibility?  In this case, perhaps yes - although you'd have to 
explicitly set a compatibility flag in Pd to get eh old behavior.

> (incidentally teh old behavior was machine-dependent - this complicates it 
even further :)
I didn't notice that it's machine-dependent-- it just appears as the wrong 
algorithm 
to me.

Is there undefined behavior there?
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.48-0test1 released

[Miller Puckette]

That's just the question - is it worth keeping an old bug available for
compatibility?   In this case, perhaps yes - although you'd have to
explicitly set a compatibility flag in Pd to get eh old behavior.

(incidentally teh old behavior was machine-dependent - this complicates it
even further :)

On Sun, Jul 16, 2017 at 01:41:22PM -0300, Alexandre Torres Porres wrote:
> 2017-07-16 13:03 GMT-03:00 Jonathan Wilkes via Pd-list  >:
> 
> > Hi Miller,
> >
> > Should there be a compatibility path for the following bugfix:
> >
> > https://sourceforge.net/p/pure-data/pure-data/ci/
> > fc1dd9b0d93e9b039719103155b5772f20762c7e/
> >
> > Looks like the old behavior was there for awhile.
> >
> 
> hmm, more than a "behaviour", seems to me like a wrong mathematical output,
> a bug.

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


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

Re: [PD] [PD-announce] pd 0.48-0test1 released

[Alexandre Torres Porres]

2017-07-16 13:03 GMT-03:00 Jonathan Wilkes via Pd-list :

> Hi Miller,
>
> Should there be a compatibility path for the following bugfix:
>
> https://sourceforge.net/p/pure-data/pure-data/ci/
> fc1dd9b0d93e9b039719103155b5772f20762c7e/
>
> Looks like the old behavior was there for awhile.
>

hmm, more than a "behaviour", seems to me like a wrong mathematical output,
a bug.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.48-0test1 released

[Miller Puckette]

Yeah, been trying to decide if this rises to the level of needing a
compatibility path.  I'll try to get to that later today.

On Sun, Jul 16, 2017 at 04:03:38PM +, Jonathan Wilkes via Pd-list wrote:
> Hi Miller,
> Should there be a compatibility path for the following bugfix:
> 
> https://sourceforge.net/p/pure-data/pure-data/ci/fc1dd9b0d93e9b039719103155b5772f20762c7e/
> Looks like the old behavior was there for awhile.
> -Jonathan

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


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

Re: [PD] [PD-announce] pd 0.48-0test1 released

[Jonathan Wilkes via Pd-list]

Hi Miller,
Should there be a compatibility path for the following bugfix:

https://sourceforge.net/p/pure-data/pure-data/ci/fc1dd9b0d93e9b039719103155b5772f20762c7e/
Looks like the old behavior was there for awhile.
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.48-0test1 released

[cyrille henry]

thanks,
it works now : I just compile it and start a complex patch : everything look 
like working.
i'll do more test later.

cheers
c


Le 16/07/2017 à 04:18, Miller Puckette a écrit :

Duh, may bad - I've updated the source tarball to be the actual git sources
(I had been using a script I wrote many years before Git appeared.)  It should
work now to download the new source (msp.ucsd.edu) and compile.

thanks
Miller

On Sat, Jul 15, 2017 at 11:09:14PM +0200, Dan Wilcox wrote:

Simple answer: looks like the mac folder is missing in the source distribution 
tarball.


On Jul 15, 2017, at 11:02 AM, pd-list-requ...@lists.iem.at wrote:

autogen fail on ubuntu linux 16.04 for me :

chnry@hnry:~/pd/pd$ ./autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4/generated -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'm4/config'.
libtoolize: copying file 'm4/config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4/generated'.
libtoolize: copying file 'm4/generated/libtool.m4'
libtoolize: copying file 'm4/generated/ltoptions.m4'
libtoolize: copying file 'm4/generated/ltsugar.m4'
libtoolize: copying file 'm4/generated/ltversion.m4'
libtoolize: copying file 'm4/generated/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf --force
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:164: installing 'm4/config/compile'
configure.ac:9: installing 'm4/config/missing'
configure.ac:492: error: required file 'mac/Makefile.in' not found
Makefile.am:45: error: required directory ./mac does not exist
Makefile.am:48: error: required directory ./mac does not exist
asio/Makefile.am: installing 'm4/config/depcomp'
autoreconf: automake failed with exit status: 1


cheers
c



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 






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



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



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