moin Daniel, moin list
... cc'ing this message to pd-dev, as discussed ...
for those of you listers who may have missed the beginning of this
discussion (e.g. pretty much all of you), we're trying to get [ratts]
built on a windoof box, without much success. not being a windoof user
myself, i'd appreciate any tips anyone could offer regarding external
compilation on such machines; in particular CFLAGS, LDFLAGS, LIBS, etc
etc... some relevant snippets of the discussion to date follow...
On 2008-06-29 01:00:15, "daniel c. howe" <dhowe(a)mrl.nyu.edu> appears to
have written:
> Bryan Jurish wrote:
>> moin Daniel,
>>
>> it just occurred to me that pd builds on cygwin are notoriously
>> difficult: did you actually get pd to build and run? Quoting from
>> http://puredata.info/docs/developer/WindowsXPI386 :
>>> Pd doesn't build in Cygwin. You have to use MSYS.
> nope, wasnt able to get it to build via cygwin... so just running a
> binary so far
hmm, where did you get the binary? are you sure it wasn't built e.g.
with MSYS (or worse yet with MSVC) and not with cygwin at all?
for msys builds i could potentially try out some of these hacks myself
on the pd build farm machine: are you maybe running a pd-extended build?
>> at any rate, assuming you got pd built on cygwin, it would help to know
>> how the "standard" externals got built (a make log from pd/src and
>> especially pd/extra would be helpful here): this should give us a good
>> idea of the flags used.
... again, for msys builds, we could probably lift the relevant flags
from the pd-extended build system.
> same error after running autogen:
> ==================================
> ratts.c:1: warning: -fPIC ignored for target (all code is position
> independent)
ok, we can leave out -fPIC, but it shouldn't hurt to leave it in...
> gcc -O2 -fno-strict-aliasing -fPIC -Wall -Winline -o ratts.dll
> -export_dynam
> ic -shared parwave.o klatt_frame.o elements.o squeue.o dsqueue.o
> rholmes.o phfea
> t.o pd_holmes.o alhash.o phtoelm.o pd_phtoelm.o darray.o phoneutils.o
> trie.o tex
> t.o english.o saynum.o ratts_keyval.o suspect.o ASCII.o klatt~.o
> holmes.o holmes
> -feat.o holmes-mask.o phones2holmes.o guessphones.o number2text.o
> rattshash.o ra
> ttstok.o toupper.o spellout.o ratts.o
> klatt_frame.o:klatt_frame.c:(.text+0x19): undefined reference to `_gensym'
> klatt_frame.o:klatt_frame.c:(.text+0x2a): undefined reference to `_gensym'
> klatt_frame.o:klatt_frame.c:(.text+0x3b): undefined reference to `_gensym'
> klatt_frame.o:klatt_frame.c:(.text+0x4c): undefined reference to `_gensym'
> klatt_frame.o:klatt_frame.c:(.text+0x5d): undefined reference to `_gensym'
> klatt_frame.o:klatt_frame.c:(.text+0x6e): more undefined references to
> `_gensym'
> follow
> klatt_frame.o:klatt_frame.c:(.text+0x304): undefined reference to `_error'
same ol' linker error, likely due to missing linker flags (e.g.
"-export_dynamic -shared" for linux externals)
>>>> ... whatever cygwin builds call pd externals (what's
>>>> the extension of e.g. $PD_ROOT/extra/expr.* ?).
>>> ====================================
>>> dhowe@wonderdog /cygdrive/c/pd
>>> $ ls extra/expr*
>>> extra/expr-help.pd extra/expr.dll extra/expr~.dll
>>>
>>> extra/expr~:
>>> LICENSE.txt makefile vexp.lib vexp_fun.obj
>>> vexp_if.pd_linux_o
>>> README.txt vexp.c vexp.obj vexp_fun.pd_linux_o
>>> expr.dll vexp.exp vexp.pd_linux_o vexp_if.c
>>> fts_to_pd.h vexp.h vexp_fun.c vexp_if.obj
>>
>> odd... looks like you've got both .dll and .lib. afaik, .lib is a static
>> library and .dll a dynamic one. pd externals are (at least on linux and
>> osx) dynamic libraries: i'm guessing .dll is the way to go...
anyone on the list know why both .lib and .dll get built on windoof?
also, what the heck are the .pd_linux_o files we're seeing here?
>>>> afaik, pd (vanilla) doesn't build or require any libraries (except maybe
>>>> "-lm"). i don't use pd-extended, so i can't tell you there... if there
>>>> are any global pd libraries, you'll probably need to link them in.
>>> these are the libs I find in pd:
>>> ===============================
>>> dhowe@wonderdog /cygdrive/c/pd
>>> $ find . -name *.lib -print
>>> ./bin/asiolib.lib
>>> ./bin/pd.lib
>>> ./bin/pdtcl.lib
>>> ./bin/pthreadVC.lib
>>> ./bin/tcl84.lib
>>> ./bin/tclstub84.lib
>>> ./bin/tk84.lib
>>> ./bin/tkstub84.lib
>>> ./extra/bonk~/bonk~.lib
>>> ./extra/choice/choice.lib
>>> ./extra/expr~/vexp.lib
>>> ./extra/fiddle~/fiddle~.lib
>>> ./extra/loop~/loop~.lib
>>> ./extra/lrshift~/lrshift~.lib
>>> ./extra/pique/pique.lib
>>> ./extra/sigmund~/sigmund~.lib
>>> ./lib/asio/asiolib.lib
>>> ./src/pthreadVC.lib
>>
>> ... so you might need to link in any or all of the libs in bin/ ...
>> getting the order right could be tricky though. in general, gcc likes
>> "highest-level" libraries left-most in the list. my guess would be
>> something like "-lpd -lpdtcl -ltk84 -ltkstub84 -ltcl84 -ltclstub84
>> -lasiolib -lpthreadVC" ... but I might be wrong.
>>
> I seem to get that same error no matter what order I use... though if I
> add a non-existent library,
> it chokes on that... also if I add pd.lib as the last argument, I get a
> different msg, but adding the
> others doesn't help:
addendum: it's probably best to add "-l" flags (aka $LIBS) at the *end*
of the linker command line: "gcc $LDFLAGS -o $OUTFILE $OBJS $LIBS".
also, i see no reason why we ought to need to link in both the .lib and
the .dll : linking in the .dll ought to be enough, if I'm not mistaken.
> $gcc -L/cygdrive/c/pd/bin -lpd -lpdtcl -ltk84 -ltkstub84 -ltcl84
> -ltclstub84 -la
> siolib -lpthreadVC -Wall -Winline -o ratts.dll parwave.o klatt_frame.o
> elements
> .o squeue.o dsqueue.o rholmes.o phfeat.o pd_holmes.o alhash.o phtoelm.o
> pd_phtoe
> lm.o darray.o phoneutils.o trie.o text.o english.o saynum.o
> ratts_keyval.o suspe
> ct.o ASCII.o klatt~.o holmes.o holmes-feat.o holmes-mask.o
> phones2holmes.o gues
> sphones.o number2text.o rattshash.o rattstok.o toupper.o spellout.o
> ratts.o /cyg
> drive/c/pd/bin/pd.lib /cygdrive/c/pd/bin/pdtcl.lib
> /cygdrive/c/pd/bin/tk84.lib
> /cygdrive/c/pd/bin/tkstub84.lib /cygdrive/c/pd/bin/tcl84.lib
> /cygdrive/c/pd/bin/
> asiolib.lib /cygdrive/c/pd/bin/pthreadVC.lib
>
> klatt~.o:klatt~.c:(.text+0x357): undefined reference to `_s_signal'
> klatt~.o:klatt~.c:(.text+0x35f): undefined reference to `_s_bang'
> klatt~.o:klatt~.c:(.text+0x713): undefined reference to `_s_list'
> holmes.o:holmes.c:(.text+0x5c): undefined reference to `_s_list'
> holmes.o:holmes.c:(.text+0x70): undefined reference to `_s_bang'
> holmes.o:holmes.c:(.text+0x283): undefined reference to `_s_list'
> holmes.o:holmes.c:(.text+0x3df): undefined reference to `_s_list'
> holmes-feat.o:holmes-feat.c:(.text+0x3b): undefined reference to `_s_list'
> holmes-feat.o:holmes-feat.c:(.text+0xd9): undefined reference to `_s_list'
> holmes-mask.o:holmes-mask.c:(.text+0x7a): undefined reference to `_s_list'
> holmes-mask.o:holmes-mask.c:(.text+0x3c2): more undefined references to
> `_s_list
> ' follow
> ...
ok, so it looks like we're getting at least the functions resolved by
the linker (no more complaints about gensym()), but the constant symbols
still aren't getting resolved... ideas, anyone?
marmosets,
Bryan
--
Bryan Jurish "There is *always* one more bug."
jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
Bugs item #2005761, was opened at 2008-06-29 09:31
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&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: pd-extended
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: frey (freynz)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: ui performance bad on 0.40.3-extended
Initial Comment:
In the UI on MacOSX/Intel (and probably other platforms), opening a patch, and dragging objects around in a patch, is significantly slower in Pd-0.40.3-extended than in 0.40.2-vanilla.
This problem exists back to at least the 2008-01-08 autobuild.
Attached patches demonstrate the problem. Open up ui-slowness-test.pd. On 0.40.2-vanilla, this loads quickly. on 0.40.3-extended, there's a noticeable delay on load.
Now select all objects and drag. On 0.40.2-vanilla the performance is bad but not atrocious. on 0.40.3-extended, the performance is atrocious.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2008-06-30 16:04
Message:
Logged In: NO
This problem is also on Windows XP sp2
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 13:56
Message:
Logged In: YES
user_id=27104
Originator: NO
which hardware? be as specific as possible please. Also, how much of a
delay is there for opening?
----------------------------------------------------------------------
Comment By: frey (freynz)
Date: 2008-06-29 12:32
Message:
Logged In: YES
user_id=1772500
Originator: YES
i'm on OSX 10.4.11/Intel
----------------------------------------------------------------------
Comment By: frey (freynz)
Date: 2008-06-29 12:32
Message:
Logged In: YES
user_id=1772500
Originator: YES
i just tried it without preferences or .pdrc file, and got the same thing.
.. and on 0.41.4-vanilla the performance is exactly the same as
0.40.2-vanilla.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 12:15
Message:
Logged In: YES
user_id=27104
Originator: NO
Here is more from an old G4:
http://lists.puredata.info/pipermail/pd-list/2007-11/056368.htmlhttp://lists.puredata.info/pipermail/pd-list/2007-11/056380.html
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 12:12
Message:
Logged In: YES
user_id=27104
Originator: NO
It seems there was a similar report a while back, but with no example
patch:
https://sourceforge.net/tracker/index.php?func=detail&aid=1839447&group_id=…
"when opening a patch, the screen takes a little while to show--first all
the objects show up, then after almost 1/2 second the connections show.
after doing something--eg hitting cmd-s, it takes some time for the
system
to be ready for the next action: hitting eg cmd-1 or cmd-e directly
doesn't
do anything. wait a second, and it works again.
this was not the case in earlier autobuilds (march this year).
pd ext-40-03 recent autobuilds on osx 10.4.x (both on .8 and on recently
upgraded .10)"
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 12:07
Message:
Logged In: YES
user_id=27104
Originator: NO
Using this example patch with Pd-extended 0.40.3-extended-20080627 on my
3rd gen MacBook Pro running Mac OS X 10.4.11/Intel, there is no noticable
difference in load time when compared to Pd 0.41-4. It is slower for
dragging, so I'll look into that. But it is far from atrocious on my
machine it is quite usable, just a bit of a lag makes it feel somewhat
heavy.
I am using the default preferences. Have you tried removing your
prefereneces? Also what version of Mac OS X are you on?
I'll test on older G4 today.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&group_…
Bugs item #2005973, was opened at 2008-06-29 17:36
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005973&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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: MacOSX bugs
Initial Comment:
1. In big patches sometimes if the screen doesn't fit the whole patch then the titlebar of the opened window is under the mac-top-menu and this gives you only the option to press cmd-w to close this window. You can not move it to see the sections that are out of the screen(in the bottom of the screen in most cases)
2. When you open properties for gui objects then the opened window is placed in a random position and in many cases is placed almost out of the screen(not the titlebar of the properties-window).
3. with you double-click in an object,message,etc the context menu that appears sometimes is appeared in some distance from that object.
4. a wish! ::: a shortcut to connect two objects(their 1st inlet/outlet) and segment cords plz!!
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-06-30 09:50
Message:
Logged In: YES
user_id=564396
Originator: NO
please do not mix bug-reports and wishlists in this tracker.
please report one bug (wishlist, patch,...) per tracker item.
else you risk that some minor bug in your list is fixed and the entire
ticket is closed...
please use a more descriptive title ("bugs" in a "bugtracker" is really
generic...)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005973&group_…
Bugs item #2005973, was opened at 2008-06-29 15:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005973&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: MacOSX bugs
Initial Comment:
1. In big patches sometimes if the screen doesn't fit the whole patch then the titlebar of the opened window is under the mac-top-menu and this gives you only the option to press cmd-w to close this window. You can not move it to see the sections that are out of the screen(in the bottom of the screen in most cases)
2. When you open properties for gui objects then the opened window is placed in a random position and in many cases is placed almost out of the screen(not the titlebar of the properties-window).
3. with you double-click in an object,message,etc the context menu that appears sometimes is appeared in some distance from that object.
4. a wish! ::: a shortcut to connect two objects(their 1st inlet/outlet) and segment cords plz!!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005973&group_…
Bugs item #2005761, was opened at 2008-06-29 05:31
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&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: pd-extended
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: frey (freynz)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: ui performance bad on 0.40.3-extended
Initial Comment:
In the UI on MacOSX/Intel (and probably other platforms), opening a patch, and dragging objects around in a patch, is significantly slower in Pd-0.40.3-extended than in 0.40.2-vanilla.
This problem exists back to at least the 2008-01-08 autobuild.
Attached patches demonstrate the problem. Open up ui-slowness-test.pd. On 0.40.2-vanilla, this loads quickly. on 0.40.3-extended, there's a noticeable delay on load.
Now select all objects and drag. On 0.40.2-vanilla the performance is bad but not atrocious. on 0.40.3-extended, the performance is atrocious.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 09:56
Message:
Logged In: YES
user_id=27104
Originator: NO
which hardware? be as specific as possible please. Also, how much of a
delay is there for opening?
----------------------------------------------------------------------
Comment By: frey (freynz)
Date: 2008-06-29 08:32
Message:
Logged In: YES
user_id=1772500
Originator: YES
i'm on OSX 10.4.11/Intel
----------------------------------------------------------------------
Comment By: frey (freynz)
Date: 2008-06-29 08:32
Message:
Logged In: YES
user_id=1772500
Originator: YES
i just tried it without preferences or .pdrc file, and got the same thing.
.. and on 0.41.4-vanilla the performance is exactly the same as
0.40.2-vanilla.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 08:15
Message:
Logged In: YES
user_id=27104
Originator: NO
Here is more from an old G4:
http://lists.puredata.info/pipermail/pd-list/2007-11/056368.htmlhttp://lists.puredata.info/pipermail/pd-list/2007-11/056380.html
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 08:12
Message:
Logged In: YES
user_id=27104
Originator: NO
It seems there was a similar report a while back, but with no example
patch:
https://sourceforge.net/tracker/index.php?func=detail&aid=1839447&group_id=…
"when opening a patch, the screen takes a little while to show--first all
the objects show up, then after almost 1/2 second the connections show.
after doing something--eg hitting cmd-s, it takes some time for the
system
to be ready for the next action: hitting eg cmd-1 or cmd-e directly
doesn't
do anything. wait a second, and it works again.
this was not the case in earlier autobuilds (march this year).
pd ext-40-03 recent autobuilds on osx 10.4.x (both on .8 and on recently
upgraded .10)"
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 08:07
Message:
Logged In: YES
user_id=27104
Originator: NO
Using this example patch with Pd-extended 0.40.3-extended-20080627 on my
3rd gen MacBook Pro running Mac OS X 10.4.11/Intel, there is no noticable
difference in load time when compared to Pd 0.41-4. It is slower for
dragging, so I'll look into that. But it is far from atrocious on my
machine it is quite usable, just a bit of a lag makes it feel somewhat
heavy.
I am using the default preferences. Have you tried removing your
prefereneces? Also what version of Mac OS X are you on?
I'll test on older G4 today.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&group_…
Bugs item #2005761, was opened at 2008-06-29 09:31
Message generated for change (Comment added) made by freynz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&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: pd-extended
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: frey (freynz)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: ui performance bad on 0.40.3-extended
Initial Comment:
In the UI on MacOSX/Intel (and probably other platforms), opening a patch, and dragging objects around in a patch, is significantly slower in Pd-0.40.3-extended than in 0.40.2-vanilla.
This problem exists back to at least the 2008-01-08 autobuild.
Attached patches demonstrate the problem. Open up ui-slowness-test.pd. On 0.40.2-vanilla, this loads quickly. on 0.40.3-extended, there's a noticeable delay on load.
Now select all objects and drag. On 0.40.2-vanilla the performance is bad but not atrocious. on 0.40.3-extended, the performance is atrocious.
----------------------------------------------------------------------
>Comment By: frey (freynz)
Date: 2008-06-29 12:32
Message:
Logged In: YES
user_id=1772500
Originator: YES
i'm on OSX 10.4.11/Intel
----------------------------------------------------------------------
Comment By: frey (freynz)
Date: 2008-06-29 12:32
Message:
Logged In: YES
user_id=1772500
Originator: YES
i just tried it without preferences or .pdrc file, and got the same thing.
.. and on 0.41.4-vanilla the performance is exactly the same as
0.40.2-vanilla.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 12:15
Message:
Logged In: YES
user_id=27104
Originator: NO
Here is more from an old G4:
http://lists.puredata.info/pipermail/pd-list/2007-11/056368.htmlhttp://lists.puredata.info/pipermail/pd-list/2007-11/056380.html
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 12:12
Message:
Logged In: YES
user_id=27104
Originator: NO
It seems there was a similar report a while back, but with no example
patch:
https://sourceforge.net/tracker/index.php?func=detail&aid=1839447&group_id=…
"when opening a patch, the screen takes a little while to show--first all
the objects show up, then after almost 1/2 second the connections show.
after doing something--eg hitting cmd-s, it takes some time for the
system
to be ready for the next action: hitting eg cmd-1 or cmd-e directly
doesn't
do anything. wait a second, and it works again.
this was not the case in earlier autobuilds (march this year).
pd ext-40-03 recent autobuilds on osx 10.4.x (both on .8 and on recently
upgraded .10)"
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 12:07
Message:
Logged In: YES
user_id=27104
Originator: NO
Using this example patch with Pd-extended 0.40.3-extended-20080627 on my
3rd gen MacBook Pro running Mac OS X 10.4.11/Intel, there is no noticable
difference in load time when compared to Pd 0.41-4. It is slower for
dragging, so I'll look into that. But it is far from atrocious on my
machine it is quite usable, just a bit of a lag makes it feel somewhat
heavy.
I am using the default preferences. Have you tried removing your
prefereneces? Also what version of Mac OS X are you on?
I'll test on older G4 today.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&group_…
Bugs item #2005761, was opened at 2008-06-29 09:31
Message generated for change (Comment added) made by freynz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&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: pd-extended
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: frey (freynz)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: ui performance bad on 0.40.3-extended
Initial Comment:
In the UI on MacOSX/Intel (and probably other platforms), opening a patch, and dragging objects around in a patch, is significantly slower in Pd-0.40.3-extended than in 0.40.2-vanilla.
This problem exists back to at least the 2008-01-08 autobuild.
Attached patches demonstrate the problem. Open up ui-slowness-test.pd. On 0.40.2-vanilla, this loads quickly. on 0.40.3-extended, there's a noticeable delay on load.
Now select all objects and drag. On 0.40.2-vanilla the performance is bad but not atrocious. on 0.40.3-extended, the performance is atrocious.
----------------------------------------------------------------------
>Comment By: frey (freynz)
Date: 2008-06-29 12:32
Message:
Logged In: YES
user_id=1772500
Originator: YES
i just tried it without preferences or .pdrc file, and got the same thing.
.. and on 0.41.4-vanilla the performance is exactly the same as
0.40.2-vanilla.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 12:15
Message:
Logged In: YES
user_id=27104
Originator: NO
Here is more from an old G4:
http://lists.puredata.info/pipermail/pd-list/2007-11/056368.htmlhttp://lists.puredata.info/pipermail/pd-list/2007-11/056380.html
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 12:12
Message:
Logged In: YES
user_id=27104
Originator: NO
It seems there was a similar report a while back, but with no example
patch:
https://sourceforge.net/tracker/index.php?func=detail&aid=1839447&group_id=…
"when opening a patch, the screen takes a little while to show--first all
the objects show up, then after almost 1/2 second the connections show.
after doing something--eg hitting cmd-s, it takes some time for the
system
to be ready for the next action: hitting eg cmd-1 or cmd-e directly
doesn't
do anything. wait a second, and it works again.
this was not the case in earlier autobuilds (march this year).
pd ext-40-03 recent autobuilds on osx 10.4.x (both on .8 and on recently
upgraded .10)"
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 12:07
Message:
Logged In: YES
user_id=27104
Originator: NO
Using this example patch with Pd-extended 0.40.3-extended-20080627 on my
3rd gen MacBook Pro running Mac OS X 10.4.11/Intel, there is no noticable
difference in load time when compared to Pd 0.41-4. It is slower for
dragging, so I'll look into that. But it is far from atrocious on my
machine it is quite usable, just a bit of a lag makes it feel somewhat
heavy.
I am using the default preferences. Have you tried removing your
prefereneces? Also what version of Mac OS X are you on?
I'll test on older G4 today.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&group_…
Bugs item #2005761, was opened at 2008-06-29 05:31
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&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: pd-extended
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: frey (freynz)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: ui performance bad on 0.40.3-extended
Initial Comment:
In the UI on MacOSX/Intel (and probably other platforms), opening a patch, and dragging objects around in a patch, is significantly slower in Pd-0.40.3-extended than in 0.40.2-vanilla.
This problem exists back to at least the 2008-01-08 autobuild.
Attached patches demonstrate the problem. Open up ui-slowness-test.pd. On 0.40.2-vanilla, this loads quickly. on 0.40.3-extended, there's a noticeable delay on load.
Now select all objects and drag. On 0.40.2-vanilla the performance is bad but not atrocious. on 0.40.3-extended, the performance is atrocious.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 08:15
Message:
Logged In: YES
user_id=27104
Originator: NO
Here is more from an old G4:
http://lists.puredata.info/pipermail/pd-list/2007-11/056368.htmlhttp://lists.puredata.info/pipermail/pd-list/2007-11/056380.html
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 08:12
Message:
Logged In: YES
user_id=27104
Originator: NO
It seems there was a similar report a while back, but with no example
patch:
https://sourceforge.net/tracker/index.php?func=detail&aid=1839447&group_id=…
"when opening a patch, the screen takes a little while to show--first all
the objects show up, then after almost 1/2 second the connections show.
after doing something--eg hitting cmd-s, it takes some time for the
system
to be ready for the next action: hitting eg cmd-1 or cmd-e directly
doesn't
do anything. wait a second, and it works again.
this was not the case in earlier autobuilds (march this year).
pd ext-40-03 recent autobuilds on osx 10.4.x (both on .8 and on recently
upgraded .10)"
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 08:07
Message:
Logged In: YES
user_id=27104
Originator: NO
Using this example patch with Pd-extended 0.40.3-extended-20080627 on my
3rd gen MacBook Pro running Mac OS X 10.4.11/Intel, there is no noticable
difference in load time when compared to Pd 0.41-4. It is slower for
dragging, so I'll look into that. But it is far from atrocious on my
machine it is quite usable, just a bit of a lag makes it feel somewhat
heavy.
I am using the default preferences. Have you tried removing your
prefereneces? Also what version of Mac OS X are you on?
I'll test on older G4 today.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&group_…
Bugs item #2005761, was opened at 2008-06-29 05:31
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&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: pd-extended
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: frey (freynz)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: ui performance bad on 0.40.3-extended
Initial Comment:
In the UI on MacOSX/Intel (and probably other platforms), opening a patch, and dragging objects around in a patch, is significantly slower in Pd-0.40.3-extended than in 0.40.2-vanilla.
This problem exists back to at least the 2008-01-08 autobuild.
Attached patches demonstrate the problem. Open up ui-slowness-test.pd. On 0.40.2-vanilla, this loads quickly. on 0.40.3-extended, there's a noticeable delay on load.
Now select all objects and drag. On 0.40.2-vanilla the performance is bad but not atrocious. on 0.40.3-extended, the performance is atrocious.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 08:12
Message:
Logged In: YES
user_id=27104
Originator: NO
It seems there was a similar report a while back, but with no example
patch:
https://sourceforge.net/tracker/index.php?func=detail&aid=1839447&group_id=…
"when opening a patch, the screen takes a little while to show--first all
the objects show up, then after almost 1/2 second the connections show.
after doing something--eg hitting cmd-s, it takes some time for the
system
to be ready for the next action: hitting eg cmd-1 or cmd-e directly
doesn't
do anything. wait a second, and it works again.
this was not the case in earlier autobuilds (march this year).
pd ext-40-03 recent autobuilds on osx 10.4.x (both on .8 and on recently
upgraded .10)"
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 08:07
Message:
Logged In: YES
user_id=27104
Originator: NO
Using this example patch with Pd-extended 0.40.3-extended-20080627 on my
3rd gen MacBook Pro running Mac OS X 10.4.11/Intel, there is no noticable
difference in load time when compared to Pd 0.41-4. It is slower for
dragging, so I'll look into that. But it is far from atrocious on my
machine it is quite usable, just a bit of a lag makes it feel somewhat
heavy.
I am using the default preferences. Have you tried removing your
prefereneces? Also what version of Mac OS X are you on?
I'll test on older G4 today.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&group_…
Bugs item #2005761, was opened at 2008-06-29 05:31
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&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: pd-extended
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: frey (freynz)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: ui performance bad on 0.40.3-extended
Initial Comment:
In the UI on MacOSX/Intel (and probably other platforms), opening a patch, and dragging objects around in a patch, is significantly slower in Pd-0.40.3-extended than in 0.40.2-vanilla.
This problem exists back to at least the 2008-01-08 autobuild.
Attached patches demonstrate the problem. Open up ui-slowness-test.pd. On 0.40.2-vanilla, this loads quickly. on 0.40.3-extended, there's a noticeable delay on load.
Now select all objects and drag. On 0.40.2-vanilla the performance is bad but not atrocious. on 0.40.3-extended, the performance is atrocious.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-29 08:07
Message:
Logged In: YES
user_id=27104
Originator: NO
Using this example patch with Pd-extended 0.40.3-extended-20080627 on my
3rd gen MacBook Pro running Mac OS X 10.4.11/Intel, there is no noticable
difference in load time when compared to Pd 0.41-4. It is slower for
dragging, so I'll look into that. But it is far from atrocious on my
machine it is quite usable, just a bit of a lag makes it feel somewhat
heavy.
I am using the default preferences. Have you tried removing your
prefereneces? Also what version of Mac OS X are you on?
I'll test on older G4 today.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005761&group_…