I can't imagine there being such an incompatibility between x86
processors - otherwise the internet would have been flooded by such
messages
Sure :) Most probably software problems or misconfiguration - kernel,
LIBC, XOrg drivers...
--
Hallo Graeme,
Du schriebst am Tue, 21 Aug 2012 07:56:03 +0100:
> > There might be slight discrepancies between intel and AMD processors -
...
> I can't imagine there being such an incompatibility between x86
There are some - most don't matter for applications, like small timing
deviations or dif
Hi,
On 20 August 2012 21:24, Sieghard wrote:
>
> There might be slight discrepancies between intel and AMD processors - this
> might also cause problems.
I can't imagine there being such an incompatibility between x86
processors - otherwise the internet would have been flooded by such
messages.
Hallo Graeme,
Du schriebst am Mon, 20 Aug 2012 15:47:18 +0100:
> I never have "effects" enabled - I don't see the need for them.
> 'top' shows things as they are (well, so I believe).
At least, it's comparable if used on different setups. And as it's kind of
a left-over from text console times,
Hallo Ivanko,
Du schriebst am Mon, 20 Aug 2012 03:17:25 +0500:
> Fortunately, I could locate some patches, and one of them did work,
> although it was quite difficult to apply.
> ===
> The base thing me've got from this story is that You are just happy of
> getting whichever stable pictu
Hallo Graeme,
Du schriebst am Mon, 20 Aug 2012 16:08:04 +0100:
> Hi Martin,
...
> on my two quad core systems. My first quad core system was a early
> generation Intel Quad Core Q something. I now have a Intel i7 3770K.
There might be slight discrepancies between intel and AMD processors - t
On Monday 20 August 2012 17:08:04 Graeme Geldenhuys wrote:
>
> Debugging definitely works.
>
Thanks.
> > BTW, KDE 3.5 works well for me on OpenSUSE 12.1 on different machines.
>
> Yeah, KDE 3.x was way better than KDE4. It just seemed like more
> effort to install than JWM, so I went with the latt
Hi,
On 19 August 2012 00:20, Sieghard wrote:
> Possible if you had none of those "effects" running, but still depends
> upon how the load display defines the "idle" state - it might just ignore
> that "residual" load the desktop itself produces.
I never have "effects" enabled - I don't see the n
Fortunately, I could locate some patches, and one of them did work,
although it was quite difficult to apply.
===
The base thing me've got from this story is that You are just happy of
getting whichever stable picture on the screen :)
And MSEgui uses Xrender intensively as long as Xrender
Hallo Ivanko,
Du schriebst am Sun, 19 Aug 2012 03:18:48 +0500:
> >> BTW, You should make sure You kernel does NOT use the PAT (MTRR
...
> > Did so, didn't help, at least not much, if at all.
> > (Cost me a reboot, since not switchable at run time, only kernel
> > parameter.)
...
> ? In this advic
On Saturday 18 August 2012 22:18:56 Graeme Geldenhuys wrote:
>
> Anyway, I have ditched those rubbish DE's and moved to JWM (Joe's
> Window Manage) which consumes something like 7MB max (compared to
> KDE4's hundreds of MB's). CPU sits at idle when I do nothing.
Graeme, can you confirm that debugg
Hallo Graeme,
Du schriebst am Sat, 18 Aug 2012 21:18:56 +0100:
> From early 2010 until 2 months ago I ran Ubuntu 10.04 - Gnome 2.x
> desktop. CPU load was mostly at idle too if I did nothing.
Possible if you had none of those "effects" running, but still depends
upon how the load display defines
Hallo Ivanko,
Du schriebst am Sun, 19 Aug 2012 03:01:15 +0500:
> Did You read about CPU context switching - [re]storing registers,
> thread vars, memory maps, pipelines to GPU etc things bound to CPU etc
> ? A lot of work for CPU...
A lot of work for a single context switch, on the order of a co
Hallo Ivanko,
Du schriebst am Sun, 19 Aug 2012 03:11:12 +0500:
> Switching heat production from one part to another
> in seconds will constantly stress them thermally,
>
> Not be a problem for devices dissipating 95..130W - these issues are
Especially then it _will_ be
> Hallo Ivanko,
>
>> BTW, You should make sure You kernel does NOT use the PAT (MTRR
>> replacement) kernel options. This feature is very problematic if
>> activates.
>
> Did so, didn't help, at least not much, if at all.
> (Cost me a reboot, since not switchable at run time, only kernel
> paramete
Switching heat production from one part to another
in seconds will constantly stress them thermally,
Not be a problem for devices dissipating 95..130W - these issues are
definitely taken when designing. Have You often encountered a damaged
CPU but static electricity or imp
I.e. the overhead should be on the order of a few parts per a thousand.
Did You read about CPU context switching - [re]storing registers,
thread vars, memory maps, pipelines to GPU etc things bound to CPU etc
? A lot of work for CPU...
-
so much processor time that they
might easily consume all the power of three of your cores (and more),
These monsters sleep most of the time (once run & ate a plenty of RAM)
--
Live Security Virtual Conferenc
On 08/18/2012 04:18 PM, Graeme Geldenhuys wrote:
>
> For the last 2 months I have been running OpenSUSE 12.1 - simply
> because (K)Ubuntu 12.04 both kept freezing up my system. So much so
> that the mouse doesn't even move. I searched the internet, and I was
> not alone. Apparently some bug Cano
Hi,
On 18 August 2012 19:13, Sieghard wrote:
>
> What system setup? As you're using SuSE, I guess you also run KDE?
>From early 2010 until 2 months ago I ran Ubuntu 10.04 - Gnome 2.x
desktop. CPU load was mostly at idle too if I did nothing.
For the last 2 months I have been running OpenSUSE 12
Hallo Ivanko,
Du schriebst am Fri, 17 Aug 2012 23:45:04 +0500:
> BTW, You should make sure You kernel does NOT use the PAT (MTRR
> replacement) kernel options. This feature is very problematic if
> activates.
Did so, didn't help, at least not much, if at all.
(Cost me a reboot, since not switcha
Hallo Martin,
Du schriebst am Sat, 18 Aug 2012 07:58:58 +0200:
> > might be dependent on the hardware setup. T've got a 4 core processor
> > now, as I told already, and AMD with integrated graphics at that, and
...
> > this can relieve the problem. Do you think this could contribute to the
> > pr
Hallo Ivanko,
Du schriebst am Sat, 18 Aug 2012 10:21:47 +0500:
> interval _that_ long! Milliseconds would be a far better fit,
> ==
> Then CPUs would be used less efficient because of higher relative
> losses on context switching. Me even think that the current switch of
That's righ
Hallo Graeme,
Du schriebst am Fri, 17 Aug 2012 20:00:23 +0100:
> As for the comment about GDB and Multi CPU or Multi-core systems. I have
> been using quad core systems since early 2010 for all my development work,
> using Linux. No problems here. I now use OpenSUSE 12.1, again with no
> problems
On Friday 17 August 2012 21:00:23 Graeme Geldenhuys wrote:
> On Friday, 17 August 2012, Ivanko B wrote:
> > By default LINUX tries to load all CPUs evenly by switching to
> > different one each 5..10 seconds, even for a single use rapplication.
>
> Correct, and that can easily be obversed in Gnome
On Friday 17 August 2012 19:52:42 Sieghard wrote:
>
> But I still experience these effects, so they have to be real, and they
> might be dependent on the hardware setup. T've got a 4 core processor now,
> as I told already, and AMD with integrated graphics at that, and normally,
> all seems to run
Me even think that the current switch of
few seconds is mainly designed to equalize temperatures of CPUs
(different zones of their crystal).
==
And to equalize work hours of all CPUs (workout on failure).
---
Really? 5 to 10 _seconds_? Didn't you mean to write _milliseconds_? After
all, the load display looks much too smooth to comply to a switching
interval _that_ long! Milliseconds would be a far better fit,
==
Then CPUs would be used less efficient because of higher relative
losses on c
Hallo Ivanko,
Du schriebst am Fri, 17 Aug 2012 23:43:00 +0500:
> IIRC there should be a means to restrict programs to specific processors;
> if I can find out how,
>
> By default LINUX tries to load all CPUs evenly by switching to
Well, yes, that's nicely observable on any load dis
On Friday, 17 August 2012, Ivanko B wrote:
>
> By default LINUX tries to load all CPUs evenly by switching to
> different one each 5..10 seconds, even for a single use rapplication.
Correct, and that can easily be obversed in Gnome System Monitor, while
doing something like compiling FPC.
As fo
BTW, You should make sure You kernel does NOT use the PAT (MTRR
replacement) kernel options. This feature is very problematic if
activates.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways t
IIRC there should be a means to restrict programs to specific processors;
if I can find out how,
By default LINUX tries to load all CPUs evenly by switching to
different one each 5..10 seconds, even for a single use rapplication.
--
Hallo Martin,
Du schriebst am Fri, 17 Aug 2012 14:57:49 +0200:
> > Oh yes, and I installed the latest gdb I got right after the first few
> > "hangers", now it is version 7.4.1.
> >
> MSEide with gdb 7.4.50 works fine for me on OpenSUSE 12.1.
Thaz's good to know, although it doesn't help here. I
On Monday 13 August 2012 17:33:39 Sieghard wrote:
> And, BTW, the latest IDE is _very_ unstable. The editor works ok, and it
> seems to do compilation right, too. But testing a program is a pain - after
> a couple program starts, especially when breakpointas are set or perhaps
> even more so when
Hallo Ivanko,
Du schriebst am Wed, 15 Aug 2012 22:42:11 +0500:
> area anyway... gdb isn't very smart at getting at property values, nor
> can it access an object's field structure at all.
> =
> Then You're a programmer genius :). As contrary, me have to
> allocate/assign variable
. I use watches _extremely_ seldom, mainly because most of
what's of interest for me gets flagged as "not available" in the result
area anyway... gdb isn't very smart at getting at property values, nor can
it access an object's field structure at all.
=
Then You're a programmer g
Hallo Martin,
Du schriebst am Tue, 14 Aug 2012 08:01:47 +0200:
> "Save as" can be used to store the *.trp and *.trd in another directory.
Yes, but not under another name - not as delivered originally, at least.
If you change the name, only the .trp gets stored by that.
> The stored values in th
Hallo Martin,
Du schriebst am Tue, 14 Aug 2012 06:31:03 +0200:
> On Monday 13 August 2012 17:33:39 Sieghard wrote:
> [bugs]
Possibly - do you think so?
> Can you please report the bugs one for one with steps how to reproduce in
> order they can be fixed?
If I'm sure these effect _are_ bugs, I
On Tuesday 14 August 2012 08:01:47 Martin Schreiber wrote:
>
> > (And another BTW I just stumbled over: In the source editor, when the
> > caret hit the last line and you try to go still further down, the editor
> > leaves the text window and activates the line/column display. Looks weird
> > and w
On Monday 13 August 2012 17:33:39 Sieghard wrote:
[...]
> Or did you mean to save _all_ files under the new name (as is attempted
> with "new")? If so, this doesn't work out that way. I've included a patch
> against that in the modified version also.
>
"Save as" can be used to store the *.trp and
On Monday 13 August 2012 18:22:29 Алексей Логинов wrote:
> >And, BTW, the latest IDE is very unstable. The editor works ok, and it
> >seems to do compilation right, too. But testing a program is a pain -
> > after a couple program starts, especially when breakpointas are set or
> > perhaps even mor
On Monday 13 August 2012 18:22:29 Алексей Логинов wrote:
> >And, BTW, the latest IDE is very unstable. The editor works ok, and it
> >seems to do compilation right, too. But testing a program is a pain -
> > after a couple program starts, especially when breakpointas are set or
> > perhaps even mor
On Monday 13 August 2012 17:33:39 Sieghard wrote:
[bugs]
Can you please report the bugs one for one with steps how to reproduce in
order they can be fixed?
Thanks, Martin
--
Live Security Virtual Conference
Exclusive l
Hallo Ivanko,
Du schriebst am Tue, 14 Aug 2012 01:43:02 +0500:
> But I'm working under Linux, and even without a
> constantly open internet connection
> =
> Then another issues me encountered earlier - discontinuing fixing bugs
> for obsoleting graphic chips by vendors (free drivers
That's LINUX GUI is very sensitive to combined quality of VGAcard &
its drivers
===
Easily isolated by switching to framebuffer console&X-driver&X-mode.
Me mean exactly KERNEL MODE framebuffer activated for X by "Option
UseFBDev true" in X-config- VESAFB, IntelDRIFB, SISFB,.. These
ed
That's LINUX GUI is very sensitive to combined quality of VGAcard &
its drivers. Also kernel has to be properly configured & build - with
activated DRI & MTRR, proper DMA, deactivated PAT [very-very evil
feature],... Also, there can be [on systems with non-locked cooler
RPMs - PWM, SmartFan,..] is
But I'm working under Linux, and even without a
constantly open internet connection
=
Then another issues me encountered earlier - discontinuing fixing bugs
for obsoleting graphic chips by vendors (free drivers are usually bad
[or not properly tested for double buffering, XRendering,.
Hallo Ivanko,
Du schriebst am Mon, 13 Aug 2012 22:44:43 +0500:
> _You_ want to replace a file that's in use by some program, even by _that
> very programm itself_, which is an inherently dangerous operation,
> because of very many possibilities for loss of data, inconsistency,
> inoperability. =
Hallo Ivanko,
Du schriebst am Mon, 13 Aug 2012 23:11:45 +0500:
> But testing a program is a pain - after
> a couple program starts, especially when breakpointas are set or perhaps
...
>
> For me, these are GDB & antiviral tool & DDOS from a malwared machine
> issues in most cases. T
If any
>appreciable load from other processes is present (and I have a 4 core
>processor wit 4 GB of memory now! ), thsi sluggishness is much increased
>and there are even "GDB timeout" occurrances.
I confirm.
=
Hmm...may be caused by a kind of recursion - then Martin definitely
need
But testing a program is a pain - after
a couple program starts, especially when breakpointas are set or perhaps
even more so when changed, the IDE becomes unresponsive, at least invokes
the program only after a huge delay, if at all (often not), and has to be
terminated and restarted to let me
But there's some other issue mentioned here: There seem to be some serious
problems with the file handling mechaism in your i18n utility.
Definitely there're should be a lot of bugs here - since MSEi18n has
been barely used up to now :)
---
_You_ want to replace a file that's in use by some program, even by _that
very programm itself_, which is an inherently dangerous operation, because
of very many possibilities for loss of data, inconsistency, inoperability.
=
No so much if finalized by (Rename/Move)* command - which d
>And, BTW, the latest IDE is very unstable. The editor works ok, and it
>seems to do compilation right, too. But testing a program is a pain - after
>a couple program starts, especially when breakpointas are set or perhaps
>even more so when changed, the IDE becomes unresponsive, at least invokes
>
Hallo Martin,
Du schriebst am Mon, 13 Aug 2012 11:13:08 +0200:
> On Monday 13 August 2012 11:01:53 Алексей Логинов wrote:
> > Why no updates? New rpm package is updater.
> > I'll include in any case my patch in rpm package without upstream,
> > because without this patch we breaks updater and don
In this context file must be deleted and after deleting must be copying.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT manage
Hallo Алексей,
Du schriebst am Mon, 13 Aug 2012 13:20:47 +0400:
> think about problem in CopyFile also, I'm sure that this problem may
> be not only in this fragment of code and can occur anywhere else.
I'm sure you deeply misunderstand the purpose of the _copy_file function -
it is meant to _co
I use it, and, of cause, no problem if to use 'After make'. But I must
think about problem in CopyFile also, I'm sure that this problem may
be not only in this fragment of code and can occur anywhere else.
--
Live Security
On Monday 13 August 2012 11:01:53 Алексей Логинов wrote:
> Why no updates? New rpm package is updater.
> I'll include in any case my patch in rpm package without upstream,
> because without this patch we breaks updater and don't allow to change
> libraries which is in use.
> I wrote, that without p
Why no updates? New rpm package is updater.
I'll include in any case my patch in rpm package without upstream,
because without this patch we breaks updater and don't allow to change
libraries which is in use.
I wrote, that without patch copy of library is damaged, broken and
have size 0b or big siz
On Monday 13 August 2012 10:04:25 Ivanko B wrote:
> I don't think they change libraries of a *running* process *by* the
> *running* process.
> =
> It works both in LINUX & Win-32 (in win-32 - via the trick with
> renaming files). For instance, without this feature it would be
> impo
I don't think they change libraries of a *running* process *by* the *running*
process.
=
It works both in LINUX & Win-32 (in win-32 - via the trick with
renaming files). For instance, without this feature it would be
impossible ( w/o inserting auto-run keys into registry & rebootin
On Monday 13 August 2012 09:26:52 Алексей Логинов wrote:
> In Linux when rpm package updates or system updates, libraries (which
> is in used) modifies - it's usual practic. Now, function "copyfile"
> don't work, is no guarantee that "copyfile" works under all
> circumstances, and I proved it.
>
I
In Linux when rpm package updates or system updates, libraries (which
is in used) modifies - it's usual practic. Now, function "copyfile"
don't work, is no guarantee that "copyfile" works under all
circumstances, and I proved it.
On Sunday 12 August 2012 22:37:46 Алексей Логинов wrote:
> After restart application, of cause, new file .so will be use. If
> don't restart application, then old version continues to use.
>
You should *not* modify the used libraries of an application by the
application. Basta! :-)
Your trick with
After restart application, of cause, new file .so will be use. If
don't restart application, then old version continues to use.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's secur
No, no, no. I tested: my patch works good if file is used. Old version
of file was changed on new version.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat lands
"renamefile" - is moving of library, but here it is copying.
that's why I use "deletefile" before "copyfile".
I did not speak: "renamefile(mstr1,'../'+mstr1);" does not work, it
works also, but it is not suited to the fragment of code.
--
Hallo Ivanko,
Du schriebst am Sun, 12 Aug 2012 19:52:42 +0500:
> copyfile(mstr1,'../'+mstr1,true);
> ==
> Strange behavior - "true" here means overwriting "../mstr1".
Rather not - if the file exists, and if it is in use exclusively or
without write permission, then you _cannot_ overwrit
In this fragment of code needed copy, not remove! Please, look code.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers c
Hallo Алексей,
Du schriebst am Sun, 12 Aug 2012 20:33:41 +0400:
> No, code:
> renamefile(mstr1,'../'+mstr1);
> can not be use, because we lose first compiled library - first
> compiled library moves (function rename moves library).
It _can_ be used. You should really make yoursaelf familiar wit
No, code:
renamefile(mstr1,'../'+mstr1);
can not be use, because we lose first compiled library - first
compiled library moves (function rename moves library).
We need copy, but correct copy.
--
Live Security Virtual Conf
Then how about "renamefile" doing the things with a single command ?
(works within same disk)
It even works in win-32 allowing to replace DLLs used by running
process (useful for software auto update ).
--
Live Security Vi
But it does not work correctly, better to use deletefile before copyfile.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT manag
copyfile(mstr1,'../'+mstr1,true);
==
Strange behavior - "true" here means overwriting "../mstr1".
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat lands
patch for tools/i18n/main.pas:
...
else begin
mstr1:= macroar[1].value;
{$ifdef mswindows}
mstr1:= mstr1+'.dll';
{$else}
mstr1:= 'lib'+mstr1+'.so';
{$endif}
deletefile('../'+mstr1);
copyfile(mstr1,'../'+mstr1,true);
For linux I use instead
copyfile(mstr1,'../'+mstr1,true);
this code (I use script after make):
'rm -f '+'../'+mstr1;
'cp -f '+mstr1+'../'+mstr1;
And no crashes If to modify a library file, which is in use.
--
Live Security
If to use scripts "before make", "after make" in msei18n, then no
crashes when to modify a library file which is in use. It means that
problem was in:
copyfile(mstr1,'../'+mstr1,true);
(tools/i18n/main.pas)
--
Live Securit
I reproduced bug:
1) run Russian mseide,
2) run msei18n and to translated working mseide.
3) mseide crashes when Project->Make.
It means:
- must ban to modify library which is in use - to show message instead
modifying,
- must not copy library from directory ru to working directory of msei18n -
to
I think analogically, I tested.
This bug If to modify a library file which is in use.
2012/8/10 Martin Schreiber
> On Friday 10 August 2012 11:24:47 Martin Schreiber wrote:
> > On Friday 10 August 2012 10:54:26 Алексей Логинов wrote:
> > > Well, If to call loadlangunit() *before* loading the for
On Friday 10 August 2012 11:24:47 Martin Schreiber wrote:
> On Friday 10 August 2012 10:54:26 Алексей Логинов wrote:
> > Well, If to call loadlangunit() *before* loading the forms msei18n works,
> > but:
> > I)
> > After Make and after close msei18n:
> > Ошибка сегментирования
> > Error segmentatio
Sometimes size of libi18n_ru.so very big after Error segmentation.
2012/8/10 Алексей Логинов
> close - run - make must be to repeat several times.
>
>
> 2012/8/10 Алексей Логинов
>
>> How to reproduce:
>> 1) when English interface to run msei18n,
>> 2) make,
>> 3) close msei18n,
>> 4) run msei1
On Friday 10 August 2012 10:54:26 Алексей Логинов wrote:
> Well, If to call loadlangunit() *before* loading the forms msei18n works,
> but:
> I)
> After Make and after close msei18n:
> Ошибка сегментирования
> Error segmentation
> It' s not critical error.
> II)
> I used call of loadlangunit() afte
close - run - make must be to repeat several times.
2012/8/10 Алексей Логинов
> How to reproduce:
> 1) when English interface to run msei18n,
> 2) make,
> 3) close msei18n,
> 4) run msei18n - now Russian interface,
> 5) make,
> 6) close msei18n,
> 7) run msei18n,
> 8) make.
> Error segmentation
How to reproduce:
1) when English interface to run msei18n,
2) make,
3) close msei18n,
4) run msei18n - now Russian interface,
5) make,
6) close msei18n,
7) run msei18n,
8) make.
Error segmentation
2012/8/10 Алексей Логинов
> Error segmentation is critical error:
> 1) Size of libi18n_ru.so = 0 b
Error segmentation is critical error:
1) Size of libi18n_ru.so = 0 b.
2) lost information in *.trp
2012/8/10 Алексей Логинов
> Well, If to call loadlangunit() *before* loading the forms msei18n works,
> but:
> I)
> After Make and after close msei18n:
> Ошибка сегментирования
> Error segmentation
Well, If to call loadlangunit() *before* loading the forms msei18n works,
but:
I)
After Make and after close msei18n:
Ошибка сегментирования
Error segmentation
It' s not critical error.
II)
I used call of loadlangunit() after loading the forms, because I wrote
about bug:
If .so is old version, then
On Thursday 09 August 2012 21:56:30 you wrote:
> Please, reproduce the problem:
> 1) run msei18n,
> 2) "make",
> 3) run msei18n.
> Now interface is Russian, but in project *.trp no directories and empty of
> items in msei18n - project is unworked.
> Problem is saved.
> I tested make - no problem.
>
88 matches
Mail list logo
