On 18 Nov 2002 14:54:13 -0800, Nadim Shaikli wrote: > > --- Mikhael Goikhman wrote: > > On 18 Nov 2002 13:20:54 -0800, Nadim Shaikli wrote: > > > Luckily fribidi (fribidi.sf.net) is rather easy to download and > > > compile :-) BTW, the patch was against 0.10.4 (current release > > > version). > > > > You underestimate the problem. User1 may have fribidi-0.9.0, User2 may > > have fribidi-0.10.1 and User3 may have fribidi-0.10.4. fvwm should be > > built successfully for all of them. It is only that User1 should get no > > Bidi support while 2 others should get this support. So we can't start to > > use any new fribidi features without also changing configure.in to work > > correctly for User2 and UserN. In theory "make" should never fail. > > You are absolutely correct; I wasn't thinking of that - my bad. As a > workaround we/fvwm could require 0.10.4+ (akin to xpm's minimum library > requirements, etc). Chances are whomever wants Bidi support, he/she > would be more than willing to install a newer version of the library. > I'm sure there are issues with that over simplification, but its a > thought :-) Mucking with autotools is never fun.
It is possible to think here in functions/types, not in versions. I ported the code to at least fribidi-0.10.1 by replacing fribidi_boolean. Otherwise I would need to add fribidi_boolean to the test program in configure.in (instead of requiring 0.10.4, or is it 0.10.3 or 0.10.5?), Of course when fribidi will provide the shaping support internally, we will add this new function to the test program. But currently I see no reason to require 0.10.4. > > > As was noted - I've tried the same exact code outside of fvwm and it > > > worked flawlessly on thousands of examples (entire directories worth > > > of files) without any issues. I will certainly stare at it again > > > but without the ability to generate a controlled failure (ie. not > > > having my entire session disappear on me :-) and without me knowing > > > or having Xnest (or equivalent), I'm more likely to keep asking for > > > help (ouch). > > > > I launched another X (this is safe with XFree86-4.2) from another virtual > > console with fvwm running no config or a minimal config. I don't think you > > need the exact commands to do this, but I may send you. > > I primarily have access to a Sun running solaris, thus I'm afraid its > not much of an option. If you don't want your windows to go down, just verify that X does not go down. This may be achieved if you start fvwm in the background using "&" and xterm in the foreground in ~/.xinitrc, so that you may recompile and launch another fvwm from this (or another) xterm. > > > Could something within fvwm's own code be getting rubbed the wrong way ? > > > > Maybe. But I would try to narrow the "#if 0" code even more so that there > > is still no problem. > > That would be interesting to see. Ideally it would be wonderful to > simply run fvwm and this code under a debugger and single step around > for a better feel for what is causing it to go into the weeds. In any > regard, I'm all ears :-) > > Thanks a heap for the help and attention to this issue. Regards, Mikhael. -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
