thanks anyway for your time 
maybe someone else knows the answher to my problem

cheers
Thomas
On Monday 06 October 2003 18:37, Mattijs Janssens wrote:
> Sorry.
>
> Right, is warning and does not matter. Linux uses first two bytes of
> network buffer by itself so reports a different (useable) length from
> the one you specify.
>
> geenen wrote:
> > nope that does not do the trick
> > now I have this doubling of the buffer problem that was reported before
> > output of dx.log now is
> >  0:  WARNING:  SOCKET bufsize mismatch: send buffer (262144 524288)
> >  0:  WARNING:  SOCKET bufsize mismatch: rvc buffer (262144 524288)
> >  0:  worker here [28662]
> >  0:  Planning [09eac2e0] 1::/Executive:0
> >  0:  graph 1 completed
> >  0:  Planning [09eac8e0] 2::/Trace:0
> >  0:  graph 2 completed
> >  0:  Planning [09ee31a0] 3::/Executive:0
> >  0:  graph 3 completed
> >  0:  Planning [09ee37a0] 4::/Executive:0
> >  0:  graph 4 completed
> > but since it is just a warning it should not matter right??
> >
> > cheers
> > Thomas
> >
> > On Monday 06 October 2003 16:23, Mattijs Janssens wrote:
> >>What I remember is that a lot of stuff from the .cfg file gets
> >>transferred (even when no data is transferred). On my Linux system I
> >>extend the network buffer size to 256Kb
> >>
> >>echo 262144 > /proc/sys/net/core/rmem_max
> >>echo 262144 > /proc/sys/net/core/wmem_max
> >>
> >>and setenv the DX_SOCKET_BUFSIZE variable to use this space
> >>
> >>setenv DX_SOCKET_BUFSIZE 262144
> >>
> >>Again, have no idea whether this has anything to do with your problem
> >>but elimination of possible problems can never harm.
> >>
> >>Mattijd
> >>
> >>geenen wrote:
> >>>yep
> >>>the window is no longer responding and I am unable to close the VPE
> >>> other than kill it.
> >>>I do not actually load any data so there is no need for large amounts of
> >>>data to be transfered between the ui and the exec. anyway I have set
> >>>DXMEMORY=20000 to prevent any memory problems...
> >>>I do not get any warning/error messages even when running dx -log on
> >>>-trace on by the way I am running dx version
> >>>Executive, version 04.2.0000 (20:08:49, Feb 26 2003)
> >>>User Interface, version 04.02.0000 (20:09:51, Feb 26 2003)
> >>>Script, 04.2.0000
> >>>
> >>>Thomas
> >>>
> >>>
> >>>
> >>>Thomas
> >>>
> >>>On Monday 06 October 2003 12:28, Mattijs Janssens wrote:
> >>>>Does it actually hang?
> >>>>
> >>>>This is not a network buffer size issue? The $DX_SOCKET_BUFSIZE should
> >>>>be set to a large number and the network buffer size in the kernel
> >>>>should be increased. See some older discussions in this list.
> >>>>
> >>>>geenen wrote:
> >>>>>hi
> >>>>>my VPE hangs when i try to open it after a simple import and
> >>>>>visualization of spreadsheet data.
> >>>>>So i tried to save the program first and then open it(edit visual
> >>>>>program). This resulted in the same behaviour. So i looked at the .net
> >>>>>file and tried to open each of the macros that are include manually.
> >>>>>This worked fine. next i looked at my environment vars and startup
> >>>>>script. sh -x dx
> >>>>>++ echo ''
> >>>>>++ grep dxroot
> >>>>>+ x=
> >>>>>+ ARGS=
> >>>>>+ '[' '!' -z '' ']'
> >>>>>+ '[' -z '' ']'
> >>>>>+ prefix=/usr/local
> >>>>>+ DXROOT=/usr/local/dx
> >>>>>+ export DXROOT
> >>>>>+ '[' -z '' ']'
> >>>>>+ DXDATA=/usr/local/dx/samples/data
> >>>>>+ '[' -d /usr/local/dx/samples/data ']'
> >>>>>+ export DXDATA
> >>>>>+ '[' -z
> >>>>>/usr/local/dx/samples/macros/:/mara2/geenen/NCF/test/traccoor/rotatie_
> >>>>>no s tokes/9 ']'
> >>>>>+ '[' -z '' ']'
> >>>>>+ JXMACROS=/usr/local/dx/java/server/dxmacros
> >>>>>+ '[' -d /usr/local/dx/java/server/dxmacros ']'
> >>>>>+ '[' -z '' ']'
> >>>>>+ JXUSERMACROS=/usr/local/dx/java/server/usermacros
> >>>>>+ '[' -d /usr/local/dx/java/server/usermacros ']'
> >>>>>+ '[' -z
> >>>>>/usr/local/dx/samples/macros/:/mara2/geenen/NCF/test/traccoor/rotatie_
> >>>>>no s tokes/9 ']'
> >>>>>+
> >>>>>DXMACROS=/usr/local/dx/samples/macros/:/mara2/geenen/NCF/test/traccoor
> >>>>>/r o tatie_nostokes/9:/usr/local/dx/java/server/usermacros + '[' '!'
> >>>>> -z
> >>>>> /usr/local/dx/samples/macros/:/mara2/geenen/NCF/test/traccoor/rotatie
> >>>>>_n os tokes/9:/usr/local/dx/java/server/usermacros ']'
> >>>>>+ export DXMACROS
> >>>>>+ '[' -f /usr/local/dx/bin/dxworker ']'
> >>>>>+ exec /usr/local/dx/bin/dxworker
> >>>>>
> >>>>>that looks just fine since the macros that are used are in
> >>>>>/usr/local/dx/samples/macros/ I even include my working dir and copied
> >>>>>the included macros to this dir.
> >>>>>All with no effect. Next I tried to install dx on a different system.
> >>>>>mandrake 9.1 opendx rpm 4.2
> >>>>>I had the same behaviour there.
> >>>>>The first lines of the .net file I try to open in the VPE
> >>>>>
> >>>>>// macro reference (direct): Make3DField
> >>>>>/usr/local/dx/samples/macros//Make3DFieldMacro.net
> >>>>>include "Make3DFieldMacro.net"
> >>>>>//
> >>>>>// macro reference (direct): AutoScale
> >>>>>/usr/local/dx/samples/macros//AutoScaleMacro.net
> >>>>>include "AutoScaleMacro.net"
> >>>>>//
> >>>>>// macro reference (direct): UnsquishGlyph
> >>>>>/usr/local/dx/samples/macros//UnsquishGlyphMacro.net
> >>>>>include "UnsquishGlyphMacro.net"
> >>>>>//
> >>>>>// MODULE main
> >>>>>//
> >>>>>
> >>>>>It looks like dx knows where the macros are since it is able to run
> >>>>> the .net file but VPE does not know where the macros are do they use
> >>>>> different env settings??? any help would be highly appreciated
> >>>>>
> >>>>>Thomas Geenen

Reply via email to