Re: FvwmScript - WriteToFile seems not working

2013-12-18 Thread Thomas Funk
2013/12/14 Dominique Michel dominique.mic...@vtxnet.ch:
 Le Sat, 14 Dec 2013 00:34:38 +0100,
 Thomas Funk t.f...@web.de a écrit :

 Dan Espen wrote:
  Thomas Funk t.f...@web.de writes:
 
  Hi!
 
  I'm working on a composite configurator with FvwmScript and
  getting an issue with WriteToFile command. It only writes '#end'
  into the file.
 
  First I thought I've done something wrong but I do the same as in
  FvwmScript-BaseConfig. So I started a test with
  FvwmScript-BaseConfig and the same happens. Used FVWM is 2.6.5.
  This happens under Fedora 19, too.
 
  My next thought was something has changed in WriteToFile source
  since creation of FvwmScript-BaseConfig - 2007-08-07. So I
  compared the code from 2.5.22 and CVS but nothing has changed.
 
  So, what could be the problem?
 
  We'd probably have to see the script but you could always resort to
  adding printfs in Instructions.c.
 
  Start with determining if it gets NbArg right.
  Just seeing #end is an indication that it doesn't
  see the args after the filename.

 I have checked different VMs with different FVWM versions with
 FvwmScript-BaseConfig:

 Debian 4.x (2007) with FVWM 2.5.22 - ok, creates full config
 Debian 6.x (2011) with FVWM 2.6.0 - ok, creates full config
 Debian 7.1 (2013) with FVWM 2.6.6 - ok, creates full config
 Debian 7.1 (2013) with FVWM 2.6.5 - ok, creates full config
 Debian 8 (testing, 2013) with FVWM 2.6.5 - nok, creates '#end'
 Fedora 19 (2013) with FVWM 2.6.5 - nok, creates '#end'

 Dominique Michel wrote:
  I get the same issue yesterday.
  This is with fvwm-2.6.6 from cvs and gentoo.

 So, it seems it's not a script problem.

 Therefore I've starting your suggestion with 'printfs' in
 instructions.c under my Fedora VM. I used this FvwmScript with one
 WriteToFile:

 #WindowTitle   {Test WriteToFile}
 #WindowSize  470 415# Taille
 #
 #Init
 #Begin
 #Set $userDir = (GetOutput {echo $FVWM_USERDIR} 1 -1)
 #Set $configPath = $userDir{/bla}
 #
 #WriteToFile $configPath {This is a test}
 #Quit
 #End

 As I didn't knew what you meant with 'printfs' I used printf first
 and hoped that output went into .xsession-errors. No output appeared
 but WriteToFile worked. So I removed printf and compiled code
 suddenly worked!

 Same code, different behaviors...

 Therefore I did the same on my Debian 8 system and the compiled
 version of FvwmScript works also.

 Under Debian 8 and Fedora 19 I have distribution packages installed.
 All others are self compiled.

 Could it be a problem of code optimization? Because the FvwmScript
 executables has huge different sizes:
 package:   380K
 compiled:  1,5M

 The only thing that not fit in this to theory is Dominiques issue
 because his code is self compiled, too ...

 My ebuild is the same than the one in gentoo. I modified it to use the
 cvs and to be able some patches, but I don't apply them, so the code is
 the one from the cvs.

 The cflags are a little bit extensive, that was to be able to cross
 compile in my tower and be sure to get a consistent result, but the
 tower is dead now. The only ones that doesn't are for the processor are
 -O2 -pipe and they should be sure:

 CFLAGS=-march=amdfam10 -mcx16 -msahf -mpopcnt -mabm --param
 l1-cache-size=32 --param l1-cache-line-size=64 --param
 l2-cache-size=512 -mtune=amdfam10 -O2 -pipe
 CFLAGS_amd64=-m64

 CXXFLAGS=-march=amdfam10 -mcx16 -msahf -mpopcnt -mabm --param
 l1-cache-size=32 --param l1-cache-line-size=64 --param
 l2-cache-size=512 -mtune=amdfam10 -O2 -pipe

 LDFLAGS=-Wl,-O1 -Wl,--as-needed
 LDFLAGS_amd64=-m elf_x86_64

 The ebuild append -fno-strict-aliasing to the cflags.

 The result with my configure USE flags is:
 fvwm --version
 fvwm 2.6.6 (from cvs) compiled on Oct 27 2013 at 16:48:42
 with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm,
 SM, Bidi text, XRender, XCursor, XFT, NLS

 The size of FvwmScript executable is around 400.6k here.

Is it possible, that you compile FVWM normally with configure  make, copy
the FvwmScript executable to /usr/lib/fvwm/2.6.6/ and test it with the script
snippet above or yours?

Please deactivate the debugging while configure:
./configure --cflags=-O2 (or --CFLAGS? I don't know cause I am at work ...)

@Dan:  As '-g' is part of the default cflags this is the reason why my
executable
has 1,5M. Without it has around 450k. with '-O3' the size has increased and no
change of the behaviour - works as with '-O2'. So, it's not the optimize
parameter ...

- Thomas -



Re: FvwmScript - WriteToFile seems not working

2013-12-13 Thread Thomas Funk
Dan Espen wrote:
 Thomas Funk t.f...@web.de writes:
 
 Hi!

 I'm working on a composite configurator with FvwmScript and getting an
 issue with WriteToFile command. It only writes '#end' into the file.

 First I thought I've done something wrong but I do the same as in
 FvwmScript-BaseConfig. So I started a test with FvwmScript-BaseConfig
 and the same happens. Used FVWM is 2.6.5. This happens under Fedora 19,
 too.

 My next thought was something has changed in WriteToFile source since 
 creation of FvwmScript-BaseConfig - 2007-08-07. So I compared the code 
 from 2.5.22 and CVS but nothing has changed.

 So, what could be the problem?
 
 We'd probably have to see the script but you could always resort to
 adding printfs in Instructions.c.
 
 Start with determining if it gets NbArg right.
 Just seeing #end is an indication that it doesn't
 see the args after the filename.

I have checked different VMs with different FVWM versions with 
FvwmScript-BaseConfig:

Debian 4.x (2007) with FVWM 2.5.22 - ok, creates full config
Debian 6.x (2011) with FVWM 2.6.0 - ok, creates full config
Debian 7.1 (2013) with FVWM 2.6.6 - ok, creates full config
Debian 7.1 (2013) with FVWM 2.6.5 - ok, creates full config
Debian 8 (testing, 2013) with FVWM 2.6.5 - nok, creates '#end'
Fedora 19 (2013) with FVWM 2.6.5 - nok, creates '#end'

Dominique Michel wrote:
 I get the same issue yesterday.
 This is with fvwm-2.6.6 from cvs and gentoo.

So, it seems it's not a script problem.

Therefore I've starting your suggestion with 'printfs' in instructions.c
under my Fedora VM. I used this FvwmScript with one WriteToFile:

#WindowTitle   {Test WriteToFile}
#WindowSize  470 415# Taille
#
#Init
#Begin
#Set $userDir = (GetOutput {echo $FVWM_USERDIR} 1 -1)
#Set $configPath = $userDir{/bla}
#
#WriteToFile $configPath {This is a test}
#Quit
#End

As I didn't knew what you meant with 'printfs' I used printf first and 
hoped that output went into .xsession-errors. No output appeared but
WriteToFile worked. So I removed printf and compiled code suddenly 
worked!

Same code, different behaviors...

Therefore I did the same on my Debian 8 system and the compiled version
of FvwmScript works also.

Under Debian 8 and Fedora 19 I have distribution packages installed. 
All others are self compiled.

Could it be a problem of code optimization? Because the FvwmScript 
executables has huge different sizes:
package:   380K
compiled:  1,5M

The only thing that not fit in this theory is Dominiques issue because
his code is self compiled, too ...

- Thomas -



Re: FvwmScript - WriteToFile seems not working

2013-12-13 Thread Dan Espen
Thomas Funk t.f...@web.de writes:

 Dan Espen wrote:
 Thomas Funk t.f...@web.de writes:
 
 Hi!

 I'm working on a composite configurator with FvwmScript and getting an
 issue with WriteToFile command. It only writes '#end' into the file.

 First I thought I've done something wrong but I do the same as in
 FvwmScript-BaseConfig. So I started a test with FvwmScript-BaseConfig
 and the same happens. Used FVWM is 2.6.5. This happens under Fedora 19,
 too.

 My next thought was something has changed in WriteToFile source since 
 creation of FvwmScript-BaseConfig - 2007-08-07. So I compared the code 
 from 2.5.22 and CVS but nothing has changed.

 So, what could be the problem?
 
 We'd probably have to see the script but you could always resort to
 adding printfs in Instructions.c.
 
 Start with determining if it gets NbArg right.
 Just seeing #end is an indication that it doesn't
 see the args after the filename.

 I have checked different VMs with different FVWM versions with 
 FvwmScript-BaseConfig:

 Debian 4.x (2007) with FVWM 2.5.22 - ok, creates full config
 Debian 6.x (2011) with FVWM 2.6.0 - ok, creates full config
 Debian 7.1 (2013) with FVWM 2.6.6 - ok, creates full config
 Debian 7.1 (2013) with FVWM 2.6.5 - ok, creates full config
 Debian 8 (testing, 2013) with FVWM 2.6.5 - nok, creates '#end'
 Fedora 19 (2013) with FVWM 2.6.5 - nok, creates '#end'

Good stuff!

 Dominique Michel wrote:
 I get the same issue yesterday.
 This is with fvwm-2.6.6 from cvs and gentoo.

 So, it seems it's not a script problem.

 Therefore I've starting your suggestion with 'printfs' in instructions.c
 under my Fedora VM. I used this FvwmScript with one WriteToFile:

 #WindowTitle   {Test WriteToFile}
 #WindowSize  470 415# Taille
 #
 #Init
 #Begin
 #Set $userDir = (GetOutput {echo $FVWM_USERDIR} 1 -1)
 #Set $configPath = $userDir{/bla}
 #
 #WriteToFile $configPath {This is a test}
 #Quit
 #End

 As I didn't knew what you meant with 'printfs' I used printf first and 
 hoped that output went into .xsession-errors. No output appeared but
 WriteToFile worked. So I removed printf and compiled code suddenly 
 worked!

 Same code, different behaviors...

 Therefore I did the same on my Debian 8 system and the compiled version
 of FvwmScript works also.

 Under Debian 8 and Fedora 19 I have distribution packages installed. 
 All others are self compiled.

 Could it be a problem of code optimization? Because the FvwmScript 
 executables has huge different sizes:
 package:   380K
 compiled:  1,5M

Hmm, I wonder what flags we need to use to get near that size?

 The only thing that not fit in this theory is Dominiques issue because
 his code is self compiled, too ...

I should have said fprintf(stderr);
I put a few in and observed expected behavior.

One near the end of CalcArg:

  fprintf(stderr,calc arg value of %s\n,TmpStr);

One right at the start of WriteToFile:

  fprintf(stderr,number of args %d\n,NbArg);

What you say above sounds like a very possible optimizer/compiler
problem.  Probably the distro flags haven't changed so we might
need to know the flags and the specific compiler version.

BTW, I'm FC19 but I always build my own executables.

-- 
Dan Espen



Re: FvwmScript - WriteToFile seems not working

2013-12-13 Thread Dominique Michel
Le Sat, 14 Dec 2013 00:34:38 +0100,
Thomas Funk t.f...@web.de a écrit :

 Dan Espen wrote:
  Thomas Funk t.f...@web.de writes:
  
  Hi!
 
  I'm working on a composite configurator with FvwmScript and
  getting an issue with WriteToFile command. It only writes '#end'
  into the file.
 
  First I thought I've done something wrong but I do the same as in
  FvwmScript-BaseConfig. So I started a test with
  FvwmScript-BaseConfig and the same happens. Used FVWM is 2.6.5.
  This happens under Fedora 19, too.
 
  My next thought was something has changed in WriteToFile source
  since creation of FvwmScript-BaseConfig - 2007-08-07. So I
  compared the code from 2.5.22 and CVS but nothing has changed.
 
  So, what could be the problem?
  
  We'd probably have to see the script but you could always resort to
  adding printfs in Instructions.c.
  
  Start with determining if it gets NbArg right.
  Just seeing #end is an indication that it doesn't
  see the args after the filename.
 
 I have checked different VMs with different FVWM versions with 
 FvwmScript-BaseConfig:
 
 Debian 4.x (2007) with FVWM 2.5.22 - ok, creates full config
 Debian 6.x (2011) with FVWM 2.6.0 - ok, creates full config
 Debian 7.1 (2013) with FVWM 2.6.6 - ok, creates full config
 Debian 7.1 (2013) with FVWM 2.6.5 - ok, creates full config
 Debian 8 (testing, 2013) with FVWM 2.6.5 - nok, creates '#end'
 Fedora 19 (2013) with FVWM 2.6.5 - nok, creates '#end'
 
 Dominique Michel wrote:
  I get the same issue yesterday.
  This is with fvwm-2.6.6 from cvs and gentoo.
 
 So, it seems it's not a script problem.
 
 Therefore I've starting your suggestion with 'printfs' in
 instructions.c under my Fedora VM. I used this FvwmScript with one
 WriteToFile:
 
 #WindowTitle   {Test WriteToFile}
 #WindowSize  470 415# Taille
 #
 #Init
 #Begin
 #Set $userDir = (GetOutput {echo $FVWM_USERDIR} 1 -1)
 #Set $configPath = $userDir{/bla}
 #
 #WriteToFile $configPath {This is a test}
 #Quit
 #End
 
 As I didn't knew what you meant with 'printfs' I used printf first
 and hoped that output went into .xsession-errors. No output appeared
 but WriteToFile worked. So I removed printf and compiled code
 suddenly worked!
 
 Same code, different behaviors...
 
 Therefore I did the same on my Debian 8 system and the compiled
 version of FvwmScript works also.
 
 Under Debian 8 and Fedora 19 I have distribution packages installed. 
 All others are self compiled.
 
 Could it be a problem of code optimization? Because the FvwmScript 
 executables has huge different sizes:
 package:   380K
 compiled:  1,5M
 
 The only thing that not fit in this to theory is Dominiques issue
 because his code is self compiled, too ...

My ebuild is the same than the one in gentoo. I modified it to use the
cvs and to be able some patches, but I don't apply them, so the code is
the one from the cvs.

The cflags are a little bit extensive, that was to be able to cross
compile in my tower and be sure to get a consistent result, but the
tower is dead now. The only ones that doesn't are for the processor are
-O2 -pipe and they should be sure:

CFLAGS=-march=amdfam10 -mcx16 -msahf -mpopcnt -mabm --param
l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=512 -mtune=amdfam10 -O2 -pipe 
CFLAGS_amd64=-m64

CXXFLAGS=-march=amdfam10 -mcx16 -msahf -mpopcnt -mabm --param
l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=512 -mtune=amdfam10 -O2 -pipe

LDFLAGS=-Wl,-O1 -Wl,--as-needed
LDFLAGS_amd64=-m elf_x86_64

The ebuild append -fno-strict-aliasing to the cflags.

The result with my configure USE flags is:
fvwm --version
fvwm 2.6.6 (from cvs) compiled on Oct 27 2013 at 16:48:42
with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm,
SM, Bidi text, XRender, XCursor, XFT, NLS

The size of FvwmScript executable is around 400.6k here.

Dominque

 
 - Thomas -
 



Re: FvwmScript - WriteToFile seems not working

2013-12-11 Thread Dan Espen
Thomas Funk t.f...@web.de writes:

 Hi!

 I'm working on a composite configurator with FvwmScript and getting an
 issue with WriteToFile command. It only writes '#end' into the file.

 First I thought I've done something wrong but I do the same as in
 FvwmScript-BaseConfig. So I started a test with FvwmScript-BaseConfig
 and the same happens. Used FVWM is 2.6.5. This happens under Fedora 19,
 too.

 My next thought was something has changed in WriteToFile source since 
 creation of FvwmScript-BaseConfig - 2007-08-07. So I compared the code 
 from 2.5.22 and CVS but nothing has changed.

 So, what could be the problem?

We'd probably have to see the script but you could always resort to
adding printfs in Instructions.c.

Start with determining if it gets NbArg right.
Just seeing #end is an indication that it doesn't
see the args after the filename.


-- 
Dan Espen



Re: FvwmScript - WriteToFile seems not working

2013-12-11 Thread Dominique Michel
Le Wed, 11 Dec 2013 20:29:22 +0100,
Thomas Funk t.f...@web.de a écrit :

 Hi!
 
 I'm working on a composite configurator with FvwmScript and getting an
 issue with WriteToFile command. It only writes '#end' into the file.

I get the same issue yesterday. I use a Piperead for now. The script is
here:
http://sourceforge.net/p/fvwm-crystal/code/HEAD/tree/fvwm/scripts/PrefVars/PrefVars

The commented out WriteToFile is into Widget 23.

This is with fvwm-2.6.6 from cvs and gentoo.

Dominique

 
 First I thought I've done something wrong but I do the same as in
 FvwmScript-BaseConfig. So I started a test with FvwmScript-BaseConfig
 and the same happens. Used FVWM is 2.6.5. This happens under Fedora
 19, too.
 
 My next thought was something has changed in WriteToFile source since 
 creation of FvwmScript-BaseConfig - 2007-08-07. So I compared the
 code from 2.5.22 and CVS but nothing has changed.
 
 So, what could be the problem?
 
 - Thomas -