jazzplusplus-devel — Discussion Forum for Jazz Developers

Re: [jazzplusplus-devel] SF.net SVN: jazzplusplus:[637] trunk/jazz/src

[D.B. M. <db...@ho...>]

Greets,

> From: pstieber
> To: jazzplusplus-updates
> Subject: SF.net SVN: jazzplusplus:[637] trunk/jazz/src
> Date: Mon, 17 Nov 2008 21:52:03 +0000
> 
> Revision: 637
>           http://jazzplusplus.svn.sourceforge.net/jazzplusplus/?rev=637&view=rev
> Author:   pstieber
> Date:     2008-11-17 21:52:03 +0000 (Mon, 17 Nov 2008)
> 
> Log Message:
> -----------
> Changed the HelpFile directory installation on Linux to prefix/share/Jazz++/HelpFiles.
> 
> Modified Paths:
> --------------
>     trunk/jazz/src/HelpFiles/Makefile.am
>     trunk/jazz/src/HelpFiles/images/Makefile.am
>     trunk/jazz/src/JazzPlusPlusApplication.cpp
> 

Confirming this modification works -- starting jazz for the first time (no  ~/.Jazz++),
and both jazz.cfg & jazz.hhp files are located automagically....good stuff! Checked
with both Debs here + my system....

One thing I noted (mostly curiousity factor related to mpu-401), although at 
configure time,  jazz++ configure echoes this ;

checking whether to enable Jazz++ mpu401 driver... no

..at startup (if indeed the emu10k1 mpu-401 module is loaded), jazz still pops
device selection windows listing the mpu-401 ports...(twice, once for input device,
again for output device). It just seems a bit 'silly' that this should happen, given
the fact that jazz itself hasn't got the mpu-401 driver compiled in and thus has 
no way to address/work with this device anyhow. I know it doesn't matter right
now, and realize this will be mooted in the alsa code somewhere....but, testing
is testing and this is probably 'erroneous behavior' ....ie; if the jazz binary has
no mpu-401 driver support, it should exclude this device from the presented
available midi ports on offer....."piffling stuff" , he said.  ;-)

Also, looking at Kevin's latest emails, I note he also is seeing ;

  subscribe: Device or resource busy

Although it doesn't seem to affect anything at the moment, I'd be interested
in knowing exactly where/what is throwing this line....and why...

Regards,

Don




_________________________________________________________________
Net yourself a bargain. Find great deals on eBay.
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Frover%2Eebay%2Ecom%2Frover%2F1%2F705%2D10129%2D5668%2D323%2F4%3Fid%3D10&_t=763807330&_r=hotmailTAGLINES&_m=EXT

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[D.B. M. <db...@ho...>]

> To: jazzplusplus-devel
> Date: Mon, 17 Nov 2008 16:43:49 -0800
> From: kevinc
> Subject: Re: [jazzplusplus-devel] New web build instructions and a better	Linux install
> 
> 
> On 17 November 2008 at 14:02, Pete Stieber <pstieber> wrote:
> 
> > Did you try the "export LD_DEBUG=files" test?
> 
> Got >28k lines of output.  Attached.
> 
> > What to see if you type
> > 
> > $ tex2rtf
> > in a terminal?  Should be...
> 
> I got what's below.
> 
> > <tex2rtf output>
> > Tex2RTF: input or output file is missing.
> > Tex2RTF version 2.88
> > Usage: tex2rtf [input] [output] [switches]
> > 
> > where valid switches are
> >      -bufsize <size in K>
> >      -charset <pc | pca | ansi | mac> (default ansi)
> >      -twice
> >      -sync
> >      -checkcurlybraces
> >      -checksyntax
> >      -version
> >      -macros <filename>
> >      -winhelp
> >      -rtf
> >      -html
> >      -xlp
> > 
> > </tex2rtf output>
> 
> Cheers....
> 
> 
> --
> Kevin
> 

Woke up this morning and saw all recent chatter - throw my 2cents in here as well ;

It does work over ssh - I know, it's how I routinely check builds on the Deb systems
here -- of course, you need set DISPLAY to the local (connecting host) vidport,
and you have to allow the remote host connection on the local machine (xhost +
remote_ip_addr)....works just fine.

Regarding attachment log....it would appear not to be jazz at all, but instead the
interaction between gtk_libs and glib_libs (more particularly here librsvg/pixbuf and
other related libs)....although how this could happen on a mainstream distro is a bit 
peculiar....have  you upgraded any of these related pkgs lately?

FWIW, I -could- recreate this kind of error (I've seen it before) by doing something
like upgrading the version of glib but not rebuilding (or upgrading) gtk, or similarly
not doing the same with librsvg after a glib change (or anything else that is glib
dependent), but usually I see relocation errors, not undefined_ref errors....so maybe
your problem is something different....like runtime linker failing to load something...

Also...and I don't think this is a problem but it gets a mention...on the Deb systems
here (and my construct), the variable LD_LIBRARY_PATH is no longer system
set -- it is deduced from /etc/ld.co.conf in practise, if LD_LIBRARY_PATH is unset.
(actually, it falls through to /etc/ld.so.conf if LD_LIBRARY_PATH is unset, but if
LD_LIBRARY_PATH is set it takes precedence..)

When we add  ;
export LD_LIBRARY_PATH=/usr/local/wx289/lib:$LD_LIBRARY_PATH

..to the user's .bash_profile, the variable set will appear as ;

LD_LIBRARY_PATH="/usr/local/wx289/lib:"

...with the trailing colon. AFAIK, this shouldn't be a problem...it should just delimit
the string and ignore the nothingness thereafter...at least, that is what I observe
in practise here -- it just looks a bit out of place. We probably have to do it as it
stands though, 'just in case' the user already has LD_LIBRARY_PATH set.....


Now I'm off to update my jazz tree and do it all again to check latest changes...


Regards,

Don




_________________________________________________________________
Take a summer road trip with Windows Live Hotmail. Multiple prizes and the ultimate dream beach house!
http://www.ninemsn.com.au/hotmailroadtrip

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Kevin C. <ke...@co...>]

On 17 November 2008 at 14:02, Pete Stieber <pst...@gm...> wrote:

> Did you try the "export LD_DEBUG=files" test?

Got >28k lines of output.  Attached.

> What to see if you type
> 
> $ tex2rtf
> in a terminal?  Should be...

I got what's below.

> <tex2rtf output>
> Tex2RTF: input or output file is missing.
> Tex2RTF version 2.88
> Usage: tex2rtf [input] [output] [switches]
> 
> where valid switches are
>      -bufsize <size in K>
>      -charset <pc | pca | ansi | mac> (default ansi)
>      -twice
>      -sync
>      -checkcurlybraces
>      -checksyntax
>      -version
>      -macros <filename>
>      -winhelp
>      -rtf
>      -html
>      -xlp
> 
> </tex2rtf output>

Cheers....


--
Kevin

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Kevin C. <ke...@co...>]

On 17 November 2008 at 14:02, Pete Stieber <pst...@gm...> wrote:

> Did you try the "export LD_DEBUG=files" test?

Not yet.  I'm at the wrong system.  I tried it from the right
system when I was home at lunch.  I'll try again later, probably
after my kids' go to bed.

> Sorry about all of the problems,

No problem at all.  That's what debugging is all about, right?
Thanks for all of the help!
 
--
Kevin

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Pete S. <pst...@gm...>]

PS>> Have you built tex2rtf recently?

KC> Everything is a fresh build.  I built wxWidgets
KC> first, then tex2rtf, then jazz, all of that after
KC> you advertised your most recent instruction set
KC> on the webpage.

This is the correct order.

PS>> When did you build Jazz++?
PS>>
PS>> I ask because part of the build process runs
PS>> tex2rtf to generate help.  If you built tex2rtf
PS>> recently, it requites the same wxWidgets shared
PS>> objects (well actually release versions) and
PS>> should have had problems too.

KC> I had a PATH issue on the first attempt, but I
KC> fixed that and all the builds finished without
KC> errors.

Did you try the "export LD_DEBUG=files" test?

What to see if you type

$ tex2rtf

in a terminal?  Should be...

<tex2rtf output>
Tex2RTF: input or output file is missing.
Tex2RTF version 2.88
Usage: tex2rtf [input] [output] [switches]

where valid switches are
     -bufsize <size in K>
     -charset <pc | pca | ansi | mac> (default ansi)
     -twice
     -sync
     -checkcurlybraces
     -checksyntax
     -version
     -macros <filename>
     -winhelp
     -rtf
     -html
     -xlp

</tex2rtf output>

Sorry about all of the problems,
Pete

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Pete S. <pst...@gm...>]

DM = D.B. Moore
DM>>> (should this be /usr/local/Jazz++/share/Jazz++/HelpFiles ??)....

PS = Pete Stieber
PS>> Kevin, since you have Linux packaging experience,
PS>> where are help files typically installed?

KC = Kevin Cosgrove
KC> $prefix/share/<appname>/...  Is common, like what's above.

I just made this change to both the automake input files (Makefile.am) 
and the code itself.

You can clean-up, update, rebuild and reinstall Jazz++ to test.

Maybe this will fix Donald's "can't automatically find the help files" 
problem.

Testing always welcome.

Thanks,
Pete

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Kevin C. <ke...@co...>]

On 17 November 2008 at 13:03, Pete Stieber <pst...@gm...> wrote:

> Have you built tex2rtf recently?

Everything is a fresh build.  I built wxWidgets first, then
tex2rtf, then jazz, all of that after you advertised your most
recent instruction set on the webpage.

> When did you build Jazz++?
> 
> I ask because part of the build process runs tex2rtf to generate help. 
> If you built tex2rtf recently, it requites the same wxWidgets shared 
> objects (well actually release versions) and should have had problems too.

I had a PATH issue on the first attempt, but I fixed that and all
the builds finished without errors.

Thanks....
 
--
Kevin

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Pete S. <pst...@gm...>]

KC> Starting program: 
/home/local/src/INCOMING/BUILD/Jazz/JazzBuild/src/jazz
KC> Reading symbols from shared object read from target memory...done.
KC> Loaded system supplied DSO at 0xffffe000
KC> /home/local/src/INCOMING/BUILD/Jazz/JazzBuild/src/jazz:
KC> error while loading shared libraries: libwx_gtk2d_richtext-2.8.so.0:
KC> cannot open shared object file: No such file or directory
KC>
KC> [kevinc@joseph-src #1613] printenv LD_LIBRARY_PATH
KC> /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib
KC>
KC> [kevinc@joseph-src #1617] ll 
$LD_LIBRARY_PATH/libwx_gtk2d_richtext-2.8.so.0
KC> lrwxrwxrwx 1 kevinc kevinc 33 Nov 16 20:32 
/usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_richtext-2.8.so.0 
-> libwx_gtk2d_richtext-2.8.so.0.5.0
KC>
KC> [kevinc@joseph-src #1618] ll 
$LD_LIBRARY_PATH/libwx_gtk2d_richtext-2.8.so.0.5.0
KC> -rwxr-xr-x 1 kevinc kevinc 5154209 Nov 16 20:32 
/usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_richtext-2.8.so.0.5.0
KC>
KC> It looks like the library isn't getting picked up, but I'm not sure
KC> why.  Does Jazz look at LD_LIBRARY_PATH?  Or, do I need some other
KC> environment variable?  Or?

Here's a good description of how shared libraries are found...

http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html

Try

$ export LD_DEBUG=files

and run jazz.  This will turn on a bunch of debug output.  Does it tell 
you anything useful?

Have you built tex2rtf recently?

When did you build Jazz++?

I ask because part of the build process runs tex2rtf to generate help. 
If you built tex2rtf recently, it requites the same wxWidgets shared 
objects (well actually release versions) and should have had problems too.

Pete

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Kevin C. <ke...@co...>]

On 17 November 2008 at 11:55, Pete Stieber <pst...@gm...> wrote:

> Maybe
> 
> $ gdb jazz

GNU gdb 6.3-8mdv2007.0 (Mandriva Linux release 2007.0)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu"...Using host libthread_db library "/lib/i686/libthread_db.so.1".

> (gdb) run

Starting program: /home/local/src/INCOMING/BUILD/Jazz/JazzBuild/src/jazz 
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xffffe000
/home/local/src/INCOMING/BUILD/Jazz/JazzBuild/src/jazz: error while loading shared libraries: libwx_gtk2d_richtext-2.8.so.0: cannot open shared object file: No such file or directory

Program exited with code 0177.
Current language:  auto; currently c



[kevinc@joseph-src #1613] printenv LD_LIBRARY_PATH
/usr/local/src/INCOMING/BUILD/Jazz/wx289/lib

[kevinc@joseph-src #1617] ll $LD_LIBRARY_PATH/libwx_gtk2d_richtext-2.8.so.0
lrwxrwxrwx 1 kevinc kevinc 33 Nov 16 20:32 /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_richtext-2.8.so.0 -> libwx_gtk2d_richtext-2.8.so.0.5.0

[kevinc@joseph-src #1618] ll $LD_LIBRARY_PATH/libwx_gtk2d_richtext-2.8.so.0.5.0  
-rwxr-xr-x 1 kevinc kevinc 5154209 Nov 16 20:32 /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_richtext-2.8.so.0.5.0


It looks like the library isn't getting picked up, but I'm not sure 
why.  Does Jazz look at LD_LIBRARY_PATH?  Or, do I need some other 
environment variable?  Or?

Thanks....


> (gdb) bt
> 
> and send some of the resulting text.  This gets difficult when I can't 
> reproduce the problem.
 
--
Kevin

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Kevin C. <ke...@co...>]

On 17 November 2008 at 11:55, Pete Stieber <pst...@gm...> wrote:

> KC> I was running SSH at the time.
> 
> Did you use
> 
> $ ssh -Y ...
> 
> to connect?  I doubt jazz will work if not running locally.

ssh -f to connect.  Jazz ran like that for me before, with previous 
threads of what the three of us have been playing with on & off for 
the last many months.  I'm sure that problem is on my end, and I can 
point to a config change last Friday (out of my control) which likely
caused the issue.  It's being worked on.

I'll get the backtrace from gdb later.

Thanks....
 
--
Kevin

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Pete S. <pst...@gm...>]

KS = Kevin Cosgrove
KC>>> (jazz:12682): Gdk-WARNING **: Connection to display
KC>>> localhost:12.0 appears to be untrusted. Pointer and
KC>>> keyboard grabs and inter-client communication may not
KC>>> work as expected.

PS = Pete Stieber
PS>> Are you running locally?  I've seen this type of thing
PS>> when running an X application over ssh from another
PS>> machine.
PS>>
PS>> What do you get when you type...
PS>>
PS>> $ set | grep DISPLAY

KC> I was running SSH at the time.

Did you use

$ ssh -Y ...

to connect?  I doubt jazz will work if not running locally.

KC> On my local console, in an xterm I run jazz
KC> and get to select two MIDI ports from a list.
KC> Then I get a core dump.  This is what I get
KC> in the xterm up to that point:
KC>
KC> JZProject::ReadConfiguration() JazzCfgFile:
KC>   "/home/kevinc/.Jazz++/jazz.cfg"
KC> JZConfiguration::LoadConfig:
KC>   "/home/kevinc/.Jazz++/jazz.cfg"
KC> Include synthesizer configuration file "gs.jzi"
KC> FindFile: Immediate hit on file "gs.jzi"
KC> Include file "gsdrmset.jzi"
KC> FindFile: Immediate hit on file "gsdrmset.jzi"
KC> Include file "gmdrmnam.jzi"
KC> FindFile: Immediate hit on file "gmdrmnam.jzi"
KC> Include file "gsvoices.jzi"
KC> FindFile: Immediate hit on file "gsvoices.jzi"
KC> Include file "ctrlnam.jzi"
KC> FindFile: Immediate hit on file "ctrlnam.jzi"
KC> INFO: Created client:port = 128:0
KC> INFO: Input device count: 1
KC> Input Devices
KC> Midi Through Midi Through Port-0 = 14:0
KC> INFO: Output device count: 1
KC> Output Devices
KC> Midi Through Midi Through Port-0 = 14:0
KC> INFO: input device is -1, so selecting one.
KC> INFO: Input device is: 0
KC> INFO: Output device is -1, so selecting one.
KC>
KC> (jazz:14539): Gtk-WARNING **: Theme file for default has no name
KC>
KC>
KC> (jazz:14539): Gtk-WARNING **: Theme file for default has no directories
KC>
KC> Floating exception (core dumped)
KC>
KC> I could trace the core, if you give me
KC> instructions on what you'd want.  I could
KC> also run jazz in gdb or something, and let
KC> you know what happens.

Maybe

$ gdb jazz
(gdb) run
(gdb) bt

and send some of the resulting text.  This gets difficult when I can't 
reproduce the problem.

Pete

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Kevin C. <ke...@co...>]

On 17 November 2008 at 11:04, Pete Stieber <pst...@gm...> wrote:

> KC> (jazz:12682): Gdk-WARNING **: Connection to display
> KC> localhost:12.0 appears to be untrusted. Pointer and
> KC> keyboard grabs and inter-client communication may not
> KC> work as expected.
> 
> Are you running locally?  I've seen this type of thing when running an X 
> application over ssh from another machine.
> 
> What do you get when you type...
> 
> $ set | grep DISPLAY

I was running SSH at the time.

> from a terminal application (if you can get one started ;-) )?

On my local console, in an xterm I run jazz and get to select two 
MIDI ports from a list.  Then I get a core dump.  This is what I get 
in the xterm up to that point:

JZProject::ReadConfiguration() JazzCfgFile:
  "/home/kevinc/.Jazz++/jazz.cfg"
JZConfiguration::LoadConfig:
  "/home/kevinc/.Jazz++/jazz.cfg"
Include synthesizer configuration file "gs.jzi"
FindFile: Immediate hit on file "gs.jzi"
Include file "gsdrmset.jzi"
FindFile: Immediate hit on file "gsdrmset.jzi"
Include file "gmdrmnam.jzi"
FindFile: Immediate hit on file "gmdrmnam.jzi"
Include file "gsvoices.jzi"
FindFile: Immediate hit on file "gsvoices.jzi"
Include file "ctrlnam.jzi"
FindFile: Immediate hit on file "ctrlnam.jzi"
INFO: Created client:port = 128:0
INFO: Input device count: 1
Input Devices
Midi Through Midi Through Port-0 = 14:0
INFO: Output device count: 1
Output Devices
Midi Through Midi Through Port-0 = 14:0
INFO: input device is -1, so selecting one.
INFO: Input device is: 0
INFO: Output device is -1, so selecting one.

(jazz:14539): Gtk-WARNING **: Theme file for default has no name


(jazz:14539): Gtk-WARNING **: Theme file for default has no directories

Floating exception (core dumped) 


I could trace the core, if you give me instructions on what you'd 
want.  I could also run jazz in gdb or something, and let you know 
what happens.

Cheers....
 
--
Kevin

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Pete S. <pst...@gm...>]

KC = Kevin Cosgrove
KC> Trying to run jazz I get X window errors, which
KC> I'm nearly certain are due to my present
KC> environment and have nothing to do with jazz.
KC> I get the same errors this morning with other apps,
KC> which I didn't get last Friday.  Grr.  I'm
KC> dropping the log from starting up jazz below my
KC> sig, just for fun.

<snip>

KC> (jazz:12682): Gdk-WARNING **: Connection to display
KC> localhost:12.0 appears to be untrusted. Pointer and
KC> keyboard grabs and inter-client communication may not
KC> work as expected.

Are you running locally?  I've seen this type of thing when running an X 
application over ssh from another machine.

What do you get when you type...

$ set | grep DISPLAY

from a terminal application (if you can get one started ;-) )?

Pete

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Kevin C. <ke...@co...>]

On 15 November 2008 at 16:56, Pete Stieber <pst...@gm...> wrote:

> After I posted the new build instructions, I attempted to test them by 
> actually trying them.  wxWidgets and tex2rtf went off without a hitch. 
> Jazz++ was another matter on Linux.

I've got a clean build.

> After I installed Jazz++ as root under /usr/local/Jazz++, the fun began, 
> but I think I've worked through most of the issues.  Please attempt this 
> to help me test.  When you do, make sure you erase the .Jazz++ 
> configuration file that is in your home directory.

I don't find a config file there.  Hmmm.  Maybe because that's my
JAZZ environment variable is set to /usr/local/jazz?  This goes
way, way back in time.  I'm unsetting that variable.

> The first time you run the code, a directory with the same name
> should be created, and configuration files will be copied to
> this directory.

Trying to run jazz I get X window errors, which I'm nearly
certain are due to my present environment and have nothing to do
with jazz.  I get the same errors this morning with other apps,
which I didn't get last Friday.  Grr.  I'm dropping the log from
starting up jazz below my sig, just for fun.

I'll try to run jazz again when I'm in a sane environment.

> Maybe someday I'll actually get to work on the inner workings of Jazz++ ;-)
 
I hope so.  That's where the fun is, right?

--
Kevin


(jazz:12682): Gdk-WARNING **: Connection to display localhost:12.0 appears to be untrusted. Pointer and keyboard grabs and inter-client communication may not work as expected.
JZProject::ReadConfiguration() JazzCfgFile:
  "/home/kevinc/.Jazz++/jazz.cfg"
JZConfiguration::LoadConfig:
  "/home/kevinc/.Jazz++/jazz.cfg"
Include synthesizer configuration file "gs.jzi"
FindFile: Immediate hit on file "gs.jzi"
Include file "gsdrmset.jzi"
FindFile: Immediate hit on file "gsdrmset.jzi"
Include file "gmdrmnam.jzi"
FindFile: Immediate hit on file "gmdrmnam.jzi"
Include file "gsvoices.jzi"
FindFile: Immediate hit on file "gsvoices.jzi"
Include file "ctrlnam.jzi"
FindFile: Immediate hit on file "ctrlnam.jzi"
INFO: Created client:port = 128:0
INFO: Input device count: 1
Input Devices
Midi Through Midi Through Port-0 = 14:0
INFO: Output device count: 1
Output Devices
Midi Through Midi Through Port-0 = 14:0
INFO: input device is -1, so selecting one.
The program 'jazz' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAtom (invalid Atom parameter)'.
  (Details: serial 74 error_code 5 request_code 20 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Kevin C. <ke...@co...>]

On 17 November 2008 at 7:16, Pete Stieber <pst...@gm...> wrote:

> DM> (should this be /usr/local/Jazz++/share/Jazz++/HelpFiles ??)....
> 
> Kevin, since you have Linux packaging experience, where are help files 
> typically installed?

$prefix/share/<appname>/...  Is common, like what's above.

BTW, I've got wx built using the web instructions.  I'm still
working on the rest.

Thanks....

--
Kevin

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Pete S. <pst...@gm...>]

DM = D.B. Moore
DM> with the possible caveat that the jazz binary
DM> still fails to locate the jazz.hhp file, which
DM> is installed to /usr/local/Jazz++/bin/HelpFiles

This worked for me on my Mandriva box with a fresh install.  How did you 
start Jazz++?

DM> (should this be /usr/local/Jazz++/share/Jazz++/HelpFiles ??)....

I'll look into changing this, but I'm still curious as to why it worked 
for me, but not you.

Kevin, since you have Linux packaging experience, where are help files 
typically installed?

TIA,
Pete

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Kevin C. <ke...@co...>]

I'll try to get to a test build with the instructions tomorrow or 
Monday.   Thanks!

 
--
Kevin

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[D.B. M. <db...@ho...>]

> Date: Sat, 15 Nov 2008 21:33:03 -0800
> From: pstieber
> To: jazzplusplus-devel
> Subject: Re: [jazzplusplus-devel] New web build instructions and a better Linux	install
> 
> DM = D.B. Moore
> DM> In section 8. of the wxwidgets build instructions, we do ;
> DM>
> DM> wx-config --list
> DM>
> DM> If one didn't remove added path/ldpath from existing
> DM> .bash_profile (from previous jazz instructs) it'll
> DM> work correctly, however first time builders will
> DM> find this command will only return the status of the
> DM> existing (system) wxwidgets installation, because our
> DM> custom wx path/ldpath have not, at this stage, been
> DM> added to user's .bash_profile
> DM>
> DM> Thus, section 8. should appear -after- section 9.
> DM> once these variables have been set?
> 
> I just switched them.
> 
> Thanks,
> Pete

...great, otherwise the build instructions (and code changes) seem fine,
with the possible caveat that the jazz binary still fails to locate the jazz.hhp
file, which is installed to /usr/local/Jazz++/bin/HelpFiles
(should this be /usr/local/Jazz++/share/Jazz++/HelpFiles ??)....

Tested on mine, my housemate's Deb 4.0r3 i386 and the Deb 4.0r5 amd64
machines -- consistent in all 3 cases.

Regards,

Don

_________________________________________________________________
Your dream beach house escape for summer! Sign up for the Hotmail Road Trip today.
http://www.ninemsn.com.au/hotmailroadtrip

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Pete S. <pst...@gm...>]

DM = D.B. Moore
DM> In section 8. of the wxwidgets build instructions, we do ;
DM>
DM> wx-config --list
DM>
DM> If one didn't remove added path/ldpath from existing
DM> .bash_profile (from previous jazz instructs) it'll
DM> work correctly, however first time builders will
DM> find this command will only return the status of the
DM> existing (system) wxwidgets installation, because our
DM> custom wx path/ldpath have not, at this stage, been
DM> added to user's .bash_profile
DM>
DM> Thus, section 8. should appear -after- section 9.
DM> once these variables have been set?

I just switched them.

Thanks,
Pete

Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[D.B. M. <db...@ho...>]

Greets,

> Date: Sat, 15 Nov 2008 16:56:49 -0800
> From: pstieber
> To: jazzplusplus-devel
> Subject: [jazzplusplus-devel] New web build instructions and a better Linux	install
> 
> Don and Kevin,
> 
> After I posted the new build instructions, I attempted to test them by 
> actually trying them.  wxWidgets and tex2rtf went off without a hitch. 
> Jazz++ was another matter on Linux.
>
<<snip>>
> 

>



I'm just checking through this on both my own system & the Deb

4.0r5 amd64 unit.......





In section 8. of the wxwidgets build instructions, we do ;



wx-config --list





If one didn't remove added path/ldpath from existing .bash_profile

(from previous jazz instructs) it'll work correctly, however first time 

builders will find this command will only return the status of the existing 

(system) wxwidgets installation, because our custom wx path/ldpath

have not, at this stage, been added to user's .bash_profile



Thus, section 8. should appear -after- section 9. once these variables

have been set?





Regards,



Don





_________________________________________________________________
Your dream beach house escape for summer! Sign up for the Hotmail Road Trip today.
http://www.ninemsn.com.au/hotmailroadtrip

[jazzplusplus-devel] New web build instructions and a better Linux install

[Pete S. <pst...@gm...>]

Don and Kevin,

After I posted the new build instructions, I attempted to test them by 
actually trying them.  wxWidgets and tex2rtf went off without a hitch. 
Jazz++ was another matter on Linux.

After I installed Jazz++ as root under /usr/local/Jazz++, the fun began, 
but I think I've worked through most of the issues.  Please attempt this 
to help me test.  When you do, make sure you erase the .Jazz++ 
configuration file that is in your home directory.  The first time you 
run the code, a directory with the same name should be created, and 
configuration files will be copied to this directory.

I also need to create a Jazz++ samples directory for the user during the 
first run of the code, but I haven't got around to that.  I also need to 
make a Windows installer.

Maybe someday I'll actually get to work on the inner workings of Jazz++ ;-)

Pete

Re: [jazzplusplus-devel] SF.net SVN: jazzplusplus:[620] web/htdocs/buildingtex2rtf/index.php

[D.B. M. <db...@ho...>]

> Date: Mon, 10 Nov 2008 18:44:01 -0800
> From: pstieber
> To: jazzplusplus-devel
> Subject: Re: [jazzplusplus-devel] SF.net	SVN:	jazzplusplus:[620]	web/htdocs/buildingtex2rtf/index.php
> 
>
<<snip>>
>
>
> Pete said;
> I caused the problem by worrying about a potential user that may not 
> have root access on a machine.  I faced this situation at work when a 
> colleague attempted to install wxWidgets at a user site and didn't have 
> root access.  I copied the instructions from a work web site I generated.
> 
> The autotools and autoconf in particular default to /usr/local as the 
> installation location.  For wxWidgets, I like the idea of specifying 
> /usr/local/wx{version} so that multiple versions can be loaded and I can 
> wipe out the entire install by removing that directory.  Otherwise I 
> would have to remove particular files in /usr/local/bin, /usr/local/lib, 
> /usr/local/include... and this can be a pain if the user has other codes 
> installed in these directories.  I'm not sure in wxWidgets has a "make 
> uninstall" command, but even if it does, I don't want to rely on it as 
> the user may erase their build directory.
>

This is all entirely sane, especially as many distros ship wx standard

> 
> So for now, I think I'll assume everyone that is building Jazz++ is a 
> developer, or helping me debug problems and change the instructions to...
> 
> 1. Assume the developer has root access and if they don't assume they 
> are smart enough to deal with the "--prefix=..." configure option.
> 2. Use --prefix-/usr/local/wx289 for wxWidgets and have the user build 
> and install both release and debug versions of the wxWidgets library.
> 3. Use the default prefix (/usr/local) for tex2rtf.  The only files that 
> get installed are tex2rtf and tex2rtf_gui in the /usr/local/bin 
> directory and this is usually included in the users path.  This code 
> will use the release version of wxWidgets.  I don't want to deal with 
> tex2rtf issues at this point.
> 4. Give instructions for both a debug and release build of Jazz++ and 
> the developer can choose.
> 
> Does this sound OK?
>

Sounds good to me, my only gripe was that the given instructions for
tex2rtf placed the binaries outside $PATH and broke the jazz build
instructions, nothing more. I also presume (as opposed to assume)
that anyone building jazz++ is a developer/tester or helper - what I
assume here is someone will prove that presumption to be wrong ;-)
 

> I'd really prefer to work on the code instead of these instructions.  I 
> still don't have it recording MIDI :-(

Indeed....if you want me to do anything, just aim me...

I haven't checked record functions yet -- I do know the bank/patch 
selection isn't working for me...

Regards,

Don


_________________________________________________________________
Time for change? Find your ideal job with SEEK.
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Atl%3Ask%3Anine%3A0%3Ahottag%3Achange&_t=757263783&_r=SEEK_tagline&_m=EXT

Re: [jazzplusplus-devel] SF.net SVN: jazzplusplus:[620] web/htdocs/buildingtex2rtf/index.php

[Pete S. <pst...@gm...>]

DM = D.B. Moore
DM>>> I know I'm being painful asking this .... this being the case,
DM>>> then why bother invoking su for the wx build to install it
DM>>> in /usr/local ? That is to say, why don't we just install
DM>>> wx in the user's $HOME instead so that all 3 packages don't
DM>>> need root_priv at all? I'm only thinking of users who might
DM>>> not like having to work this out...(I think my mind mumbling
DM>>> 'consistent approach' or such and similar... <grin>)....I just
DM>>> linked tex2rtf into the wx289/bin path because I'm pathetically
DM>>> lazy. Shoot me if I'm getting annoying...

KC = Kevin Cosgrove
KC>> I package a lot of things, and nearly all of them default to
KC>> /usr/local for the default prefix; some default to /usr.
KC>> Installing as root is pretty standard. I'd say that anyone
KC>> who could build jazz++ and the prerequisites would likely
KC>> be able to alter the $PREFIX if they wanted to. I'll
KC>> advocate for /usr/local. --prefix=$HOME isn't too hard to do,
KC>> if desired.

DM> Oh yes, I agree.....all I'm saying is, the user becomes
DM> root to install the wx build anyway, so why not for
DM> tex2rtf as well? The way the tex2rtf build is presented,
DM> the 'unknowledgeable user' will  -need-  to alter their
DM> PATH in ~/.bash_profile anyhow before jazz will actually
DM> build, and again for the aforesaid 'unknowledgeable user',
DM> they made need a pointer to this if they don't actually
DM> know what's going wrong. As it stands now, the door is
DM> left wide open to a swag of 'jazz does not compile'
DM> emails, because, technically speaking, the build
DM> instructions are wrong. I do realize these emails are all
DM> hypothetical, what I'm talking about in reality does not
DM> exist -- the situation exists that so called
DM> 'unknowledgeable users' might happen along here, be willing
DM> to give it a try but in the same moment be totally reliant
DM> on following the instructions to-the-letter (c&p), and
DM> for all I know these people might not speak english as
DM> a first language or at all.
DM>
DM> Remember, I'm the one who wrote up the line in the web-docs
DM> which says that even unknowledgeable users should be able
DM> to build jazz from svn with as little effort as cutting &
DM> pasting the instructions on the web-site straight into their
DM> shells...this issue with tex2rtf actually breaks
DM> that premise.
DM> Right now, what I've cited is a lie...and I know it...I'm
DM> resting uneasy. My primary concern is accuracy of content,
DM> nothing more. Yes, people that are capable of building jazz
DM> presently can alter their path 'if they wanted to' -- the
DM> point really is that they **have** to, or the jazz build will
DM> fail.
DM>
DM> Myself...I really don't care at all - I will see an omission
DM> like this and quick as blink sort it out forthwith. That
DM> said, I will report it in the guise of this hypothetical
DM> 'unknowledgeable user', as an example of foresight. Granted,
DM> there might be less than a dozen people working with the
DM> current jazz++ right now.....right now, anyone who comes
DM> along and follows the online instructions, is headed for
DM> disappointment -- sometimes, you only get one shot at
DM> impressing users....'they can't even get the build
DM> instructions right'.
DM>
DM> That's what I'm saying, looking in my mirror.  Eventually,
DM> {release), tex2rtf has to go somewhere -- putting it in
DM> the same location as the jazz binary for the moment is fine
DM> by me -- this being the case, perhaps the web-docs should
DM> include lines somewhere (before build jazz), to add;
DM>
DM> export PATH=$HOME/Jazz++/TestInstall:$PATH
DM>
DM> to the user's  ~/.bash_profile
DM>
DM> Then this all goes away and the given instructions work
DM> 'out of the box' again. In theory, this should never be
DM> a problem until {release}, at which time this path
DM> addition would conflict with a system installed jazz in
DM> /usr or /usr/local and thus would need be removed. It's
DM> a lot nicer to be able to just type  'jazz'  at the
DM> prompt and get results too....imho.

I caused the problem by worrying about a potential user that may not 
have root access on a machine.  I faced this situation at work when a 
colleague attempted to install wxWidgets at a user site and didn't have 
root access.  I copied the instructions from a work web site I generated.

The autotools and autoconf in particular default to /usr/local as the 
installation location.  For wxWidgets, I like the idea of specifying 
/usr/local/wx{version} so that multiple versions can be loaded and I can 
wipe out the entire install by removing that directory.  Otherwise I 
would have to remove particular files in /usr/local/bin, /usr/local/lib, 
/usr/local/include... and this can be a pain if the user has other codes 
installed in these directories.  I'm not sure in wxWidgets has a "make 
uninstall" command, but even if it does, I don't want to rely on it as 
the user may erase their build directory.

So for now, I think I'll assume everyone that is building Jazz++ is a 
developer, or helping me debug problems and change the instructions to...

1. Assume the developer has root access and if they don't assume they 
are smart enough to deal with the "--prefix=..." configure option.
2. Use --prefix-/usr/local/wx289 for wxWidgets and have the user build 
and install both release and debug versions of the wxWidgets library.
3. Use the default prefix (/usr/local) for tex2rtf.  The only files that 
get installed are tex2rtf and tex2rtf_gui in the /usr/local/bin 
directory and this is usually included in the users path.  This code 
will use the release version of wxWidgets.  I don't want to deal with 
tex2rtf issues at this point.
4. Give instructions for both a debug and release build of Jazz++ and 
the developer can choose.

Does this sound OK?

I'd really prefer to work on the code instead of these instructions.  I 
still don't have it recording MIDI :-(

Pete

Re: [jazzplusplus-devel] SF.net SVN: jazzplusplus:[620] web/htdocs/buildingtex2rtf/index.php

[D.B. M. <db...@ho...>]

> To: jazzplusplus-devel
> Date: Sun, 9 Nov 2008 12:31:23 -0800
> From: kevinc
> Subject: Re: [jazzplusplus-devel] SF.net SVN: jazzplusplus:[620]	web/htdocs/buildingtex2rtf/index.php
> 
> 
> On 9 November 2008 at 18:48, "D.B. Moore" <db...@ho...> wrote:
> 
> > I know I'm being painful asking this .... this being the case,
> > then why bother invoking su for the wx build to install it
> > in /usr/local ? That is to say, why don't we just install
> > wx in the user's $HOME instead so that all 3 packages don't
> > need root_priv at all? I'm only thinking of users who might
> > not like having to work this out...(I think my mind mumbling
> > 'consistent approach' or such and similar... <grin>)....I just
> > linked tex2rtf into the wx289/bin path because I'm pathetically
> > lazy. Shoot me if I'm getting annoying...
> 
> I package a lot of things, and nearly all of them default to /usr/local
> for the default prefix; some default to /usr.  Installing as root is 
> pretty standard.  I'd say that anyone who could build jazz++ and the 
> prerequisites would likely be able to alter the $PREFIX if they 
> wanted to.  I'll advocate for /usr/local.  --prefix=$HOME isn't too 
> hard to do, if desired.
> 
> That's my $0.02.
> 
> Thanks...
> --
> Kevin

Oh yes, I agree.....all I'm saying is, the user becomes root to install the
wx build anyway, so why not for tex2rtf as well? The way the tex2rtf build
is presented, the 'unknowledgeable user' will  -need-  to alter their PATH
in ~/.bash_profile anyhow before jazz will actually build, and again for
the aforesaid 'unknowledgeable user' , they made need a pointer to this
if they don't actually know what's going wrong. As it stands now, the door
is left wide open to a swag of  'jazz does not compile' emails, because,
technically speaking, the build instructions are wrong. I do realize these
emails are all hypothetical, what I'm talking about in reality does not 
exist -- the situation exists that so called 'unknowledgeable users' might
happen along here, be willing to give it a try but in the same moment be
totally reliant on following the instructions to-the-letter (c&p), and for all
I know these people might not speak english as a first language or at all.
 
Remember, I'm the one who wrote up the line in the web-docs which says
that even unknowledgeable users should be able to build jazz from svn
with as little effort as cutting&pasting the instructions on the web-site
straight into their shells...this issue with tex2rtf actually breaks that premise.
Right now, what I've cited is a lie...and I know it...I'm resting uneasy. My
primary concern is accuracy of content, nothing more. Yes, people that
are capable of building jazz presently can alter their path 'if they wanted
to' -- the point really is that they **have** to, or the jazz build will fail. 

Myself...I really don't care at all - I will see an omission like this and quick 
as blink sort it out forthwith. That said, I will report it in the guise of this
hypothetical 'unknowledgeable user', as an example of foresight. Granted,
there might be less than a dozen people working with the current jazz++
right now.....right now, anyone who comes along and follows the online
instructions, is headed for disappointment -- sometimes, you only get one
shot at impressing users....'they can't even get the build instructions right'.

That's what I'm saying, looking in my mirror.  Eventually, {release), tex2rtf
has to go somewhere -- putting it in the same location as the jazz binary
for the moment is fine by me -- this being the case, perhaps the web-docs
should include lines somewhere (before build jazz), to add ;

export PATH=$HOME/Jazz++/TestInstall:$PATH

to the user's  ~/.bash_profile 

Then this all goes away and the given instructions work 'out of the box'
again. In theory, this should never be a problem until {release}, at which
time this path addition would conflict with a system installed jazz in
/usr or /usr/local and thus would need be removed. It's a lot nicer to be
able to just type  'jazz'  at the prompt and get results too....imho.

Regards,

Donald B


PS: Btw, I did hotbot search (yahoo engine) for the word   tex2rtf   and guess 
what came up as the topmost return? Free exposure....






_________________________________________________________________
Time for change? Find your ideal job with SEEK.
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Atl%3Ask%3Anine%3A0%3Ahottag%3Achange&_t=757263783&_r=SEEK_tagline&_m=EXT

Re: [jazzplusplus-devel] SF.net SVN: jazzplusplus:[620] web/htdocs/buildingtex2rtf/index.php

[Kevin C. <ke...@co...>]

On 9 November 2008 at 18:48, "D.B. Moore" <db...@ho...> wrote:

> I know I'm being painful asking this .... this being the case,
> then why bother invoking su for the wx build to install it
> in /usr/local ? That is to say, why don't we just install
> wx in the user's $HOME instead so that all 3 packages don't
> need root_priv at all? I'm only thinking of users who might
> not like having to work this out...(I think my mind mumbling
> 'consistent approach' or such and similar... <grin>)....I just
> linked tex2rtf into the wx289/bin path because I'm pathetically
> lazy. Shoot me if I'm getting annoying...

I package a lot of things, and nearly all of them default to /usr/local
for the default prefix; some default to /usr.  Installing as root is 
pretty standard.  I'd say that anyone who could build jazz++ and the 
prerequisites would likely be able to alter the $PREFIX if they 
wanted to.  I'll advocate for /usr/local.  --prefix=$HOME isn't too 
hard to do, if desired.

That's my $0.02.

Thanks...
--
Kevin