[Lazarus] Fw: new important message

2016-02-16 Thread Sascha.Hestermann
Hello!

 

New message, please read 

 

sascha.hesterm...@gmx.de

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Replacing LRT format with RSJ

2016-02-16 Thread JuuS


On 02/16/2016 05:29 PM, Maxim Ganetsky wrote:
> Hello.
> 
> Currently we use .lrt file to store translatable strings extracted from
> forms.
> 
> This format is broken, because it cannot handle multiline
> resource strings (e.g. multiline hints).

Hi,

I've already submitted a patch, in October, at

http://bugs.freepascal.org/view.php?id=28740

Note that there will be issues from older versions to newer versions.
Read the notes there at the page.

Currently I simply update the laz files after I upgrade because I too
use multiLine hints. This fix will also fix multi-line edits, etc.

Julius

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Replacing LRT format with RSJ

2016-02-16 Thread Maxim Ganetsky


16.02.2016 20:31, Giuliano Colla пишет:
> Il 16/02/2016 17:29, Maxim Ganetsky ha scritto:
>> As a result people using this feature will need to remove their .lrt
>> files and save all affected forms again in order to generate .lrj files.
>> No other changes should be needed.
>>
>> Any comments?
> 
> To actually provide the benefit to users, it would be nice if the
> transition process would be made automatic in Lazarus IDE.
> I.e.: If in Project Options "Enable i18n" and "Create/update .po file
> when saving" are both ticked,  a "Compile" should check for the presence
> of  .lrt files and behave accordingly, i.e. remove .lrt files and
> generate again what required.
> 
> Is that possible?

Not without forcibly saving all affected forms. I don't think it is
good, because LFMs can change (e.g. when form created in Linux and saved
in Windows).

-- 
Best regards,
 Maxim Ganetsky  mailto:gan...@narod.ru

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Replacing LRT format with RSJ

2016-02-16 Thread Giuliano Colla

Il 16/02/2016 17:29, Maxim Ganetsky ha scritto:

As a result people using this feature will need to remove their .lrt
files and save all affected forms again in order to generate .lrj files.
No other changes should be needed.

Any comments?


To actually provide the benefit to users, it would be nice if the 
transition process would be made automatic in Lazarus IDE.
I.e.: If in Project Options "Enable i18n" and "Create/update .po file 
when saving" are both ticked,  a "Compile" should check for the presence 
of  .lrt files and behave accordingly, i.e. remove .lrt files and 
generate again what required.


Is that possible?

Giuliano


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


[Lazarus] Replacing LRT format with RSJ

2016-02-16 Thread Maxim Ganetsky
Hello.

Currently we use .lrt file to store translatable strings extracted from
forms.

This format is broken, because it cannot handle multiline
resource strings (e.g. multiline hints).

See the following bug report for details:

http://bugs.freepascal.org/view.php?id=26553

I propose to generate this file in RSJ format (also used by FPC 3.0.0
and up).

Therefore the plan is:

1) Remove LRT support completely, replacing it with RSJ.

2) Although generated file would be in RSJ format its extension will
be .lrj in order to avoid possible filename clashes, e.g.
when output directory is the same as project directory.

As a result people using this feature will need to remove their .lrt
files and save all affected forms again in order to generate .lrj files.
No other changes should be needed.

Any comments?

-- 
Best regards,
 Maxim Ganetsky  mailto:gan...@narod.ru

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Lazarus application crash. Is PostMessage thread safe?

2016-02-16 Thread Giuliano Colla

Il 16/02/2016 10:04, Michael Schnell ha scritto:

a (potential) bug (in "Glib2" whatever this exactly means)


Glib2 means version 2 of GTK Glib, which is used by Qt (and by GTK) to 
implement the main event loop.

libglib-2.0.so.0

The full picture (from stack trace) is as follows:

1. The main loop of Lazarus (under Qt WS) calls AppWaitMessage in
   qtobject.inc
2. qtobject calls QCoreApplication::processEvents in qcoreapplication_c.cpp
3. qcoreapplication_c.cpp calls QEventDispatcherGlib in libQtGui.so.4
4. QEventDispatcherGlib calls g_main_context_iteration in
   libglib-2.0.s0.0 (the Glib2)
5. if g_main_context_iteration has pending messages, it calls
   g_main_context_dispatch
6. g_main_context_dispatch calls QCoreApplicationPrivate::sendPostedEvents

When the user code calls Application.ProcessMessages the same sequence 
occurs:
AppProcessMessages in QtObjects.inc is called, which then calls 
QCoreApplication::processEvents, and all the steps from 2 on are identical.


My feeling is that the bug is sort of this: if the call to 
Application.ProcessMessages causes a recursion, and a new different 
message has arrived in the meantime, g_main_context_iteration() 
understands rightly that there is a pending message to dispatch, but it 
decides wrongly to dispatch again the old one, instead of the new one.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Lazarus application crash. Is PostMessage thread safe?

2016-02-16 Thread Giuliano Colla

Il 16/02/2016 10:04, Michael Schnell ha scritto:
Anyway, IMHO it's not a good idea to fight a (potential) bug (in 
"Glib2" whatever this exactly means) by implementing a completely 
queer behavior in Application.ProcessMessage. 


I fully agree with you. Seeing a unexpected recursion, I had started 
believing that somehow Application.ProcessMessages could be the 
responsible. But if the problem is elsewhere, it should be fixed 
elsewhere, by someone knowing what he's doing.


Giuliano


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Lazarus application crash. Is PostMessage thread safe?

2016-02-16 Thread Michael Schnell

On 02/15/2016 07:23 PM, Giuliano Colla wrote:






The result is to make Application.ProcessMessage not 100% reentrant, 
because of a Glib2 bug.
Would you suggest not to handle "the same" event ? How should you 
detect that its the event already in the works or the next occurrence  ?


In the case I've stumbled into, when next message eventually comes 
(after 1722 iterations over the previous one) the program crashes for 
a  SEGFAULT, most likely generated by a stack overflow.
Anyway, IMHO it's not a good idea to fight a (potential) bug (in "Glib2" 
whatever this exactly means) by implementing a completely queer behavior 
in Application.ProcessMessage.


-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus