[fpc-pascal] MSEide+MSEgui 4.6.2
Hi, MSEide+MSEgui version 4.6.2 has been released: https://sourceforge.net/projects/mseide-msegui/files/mseide-msegui/4.6.2/ Have a lot of fun! Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] "Not initialized" warnings in 3.2
I don't see this mail in archive so I send it again:
Hi
MSEide+MSEgui must compile without warnings and notes with Free Pascal
default settings. In 3.2 there now are many new warnings because of
setlength().
"
procedure test();
var
s1: string;
ar1: array of integer;
begin
setlength(s1,10);
setlength(ar1,11);
end;
"
compiled with -O- or -O2 produces the warnings
"
main.pas(48,14) Warning: Local variable "s1" of a managed type does not
seem to be initialized
main.pas(49,15) Warning: Local variable "ar1" of a managed type does not
seem to be initialized
"
compiled with -O- produces the code
"
MAIN_$$_TEST:
.Lc1:
.Ll1:
leaq-120(%rsp),%rsp
.Lc3:
.Ll2:
movq$0,(%rsp)
movq$0,8(%rsp)
leaq16(%rsp),%rdx
leaq40(%rsp),%rsi
movl$1,%edi
callfpc_pushexceptaddr
movq%rax,%rdi
callfpc_setjmp
movslq %eax,%rdx
movq%rdx,104(%rsp)
testl %eax,%eax
jne .Lj6
.Ll3:
movq%rsp,%rdi
xorl%edx,%edx
movl$10,%esi
callfpc_ansistr_setlength
.Ll4:
movq$11,112(%rsp)
movq$RTTI_$MSETYPES_$$_INTEGERARTY,%rsi
leaq112(%rsp),%rcx
leaq8(%rsp),%rdi
movl$1,%edx
callfpc_dynarray_setlength
"
-O3 has no warnings but but doesn't work well for debugging and is not
the Free Pascal default.
"
procedure test();
var
s1: string = '';
ar1: array of integer = nil;
begin
setlength(s1,10);
setlength(ar1,11);
end;
"
with -O3 (or -O-) produces redundant code:
"
MAIN_$$_TEST:
.Lc1:
.Ll1:
leaq-120(%rsp),%rsp
.Lc3:
.Ll2:
movq$0,(%rsp)
movq$0,8(%rsp)
leaq16(%rsp),%rdx
leaq40(%rsp),%rsi
movl$1,%edi
callfpc_pushexceptaddr
movq%rax,%rdi
callfpc_setjmp
movslq %eax,%rdx
movq%rdx,104(%rsp)
testl %eax,%eax
jne .Lj6
.Ll3:
movq$RTTI_$MSETYPES_$$_INTEGERARTY,%rdx redundant
movqTC_$MAIN$_$TEST_$$_defaultar1,%rsi
leaq8(%rsp),%rdi
callfpc_dynarray_assign
movqTC_$MAIN$_$TEST_$$_defaults1,%rsi
movq%rsp,%rdi
callfpc_ansistr_assign redundant
.Ll4:
movq%rsp,%rdi
xorl%edx,%edx
movl$10,%esi
callfpc_ansistr_setlength
.Ll5:
movq$11,112(%rsp)
movq$RTTI_$MSETYPES_$$_INTEGERARTY,%rsi
leaq112(%rsp),%rcx
leaq8(%rsp),%rdi
movl$1,%edx
callfpc_dynarray_setlength
"
I don't like to initialize the variables in user code anyway because it
misleadingly implies that the initial values of the variables will be used.
In order to suppress the unwanted messages I added
"
{$ifndef mse_allwarnings}
{$if fpc_fullversion >= 030100}
{$warn 5089 off}
{$warn 5090 off}
{$warn 5093 off}
{$warn 6058 off}
{$endif}
{$endif}
"
on top of the units but that does not work for compiling with -B. I was
not able to make a simple testcase, compiling MSEide with -B shows
the suppressed warnings. The code is here:
https://gitlab.com/mseide-msegui/mseide-msegui/tree/fpc_3_2
I do not dare to open a bug report with such a testcase.
Suggestions?
Thanks, Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unbuffering I/O
On Wednesday 29 August 2018 17:01:54 Mark Morgan Lloyd wrote: > I think I've seen this question asked before, my apologies if this was > recently. > > I've got two programs intended to be functionally identical, one in Perl > and the other in FPC. They read a unix-domain datagram, decode the > message, and emit output; if this goes to a file then it's reasonable to > monitor it using tail -f > > Perl has a variable that you can set to force output to be unbuffered, > with the result that as soon as a message is output it's in the file in > its entirety. > > Is there an equivalent for Pascal, or should I be using something like > fpSync(stdout) at opportune times? In order to flush textfiles automatically I use " ttextrec().flushfunc:= ttextrec().inoutfunc; " after it is opened. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reading AM2302 temp/humid sensor on RaspberryPi?
On Thursday 23 August 2018 11:54:14 Martin Schreiber wrote: > > I don't think that can be done reliably in user space. > As Alexander writes, the right way to do such a task is to use a hardware timer in capture mode. I don't know how difficult this is on RPi. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reading AM2302 temp/humid sensor on RaspberryPi?
On Thursday 23 August 2018 11:11:34 Bo Berglund wrote: > On Thu, 23 Aug 2018 09:00:07 +0200, Bo Berglund > > wrote: > >I will need a higher resolution GetTickCount for this... > > Is there in fact a way (on Linux - Raspbian) to get a tickcount with > higher resolution than 1 ms? MSEgui has "timestamp()" (lib/common/kernel/msesysutils.pas) which returns microseconds. MSEgui "ttimer" also has 1 us resolution. > I need us so I can time between two events (pulse rise and pulse fall) > which are 20 to 90 us apart... > I don't think that can be done reliably in user space. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
On Wednesday 18 July 2018 23:30:19 Ben Grasset wrote: > > For example, does *anyone *actually think the strange "lowercase > everything" capitalization style the compiler uses is "readable" nowadays? Yes. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Daemon using TTimer on Windows
On Saturday 30 June 2018 22:57:47 Marcos Douglas B. Santos wrote: >If not, which could be a possible > solution? > You could use a MSEgui application, instead of " uses msegui; " write " uses msenogui; " in "program" source file. It will have an event queue and the usual event driven programming paradigm including the use of datamodules and graphically placed non visual components. Examples are here: https://gitlab.com/mseide-msegui/mseuniverse/tree/master/attic/msedocumenting/mse/trunk/help/tutorials/nogui Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wednesday 20 June 2018 16:38:10 Ryan Joseph wrote: > > On Jun 20, 2018, at 9:21 PM, Martin Schreiber wrote: > > > > Macros are the worst code obfuscating feature ever. > > Ironically everyone agrees but back to my original point that’s just dogma > (sorry I said it!). If I was doing C I wouldn’t refuse to use the macros to > solve simple problems because “there the worst code obfuscating feature > ever”. > > At the end of the day I just want to be happy and productive programming. > If a macro helps me do that then so be it. Life’s too short. > I daily read code from many people. Beleave me, “there the worst code obfuscating feature ever” is one of the most proven in use dogma ever. ;-) That you will not misuse it does not mean nobody will misuse it. The C-example which has been provided looks like a misuse for me. Macros replace text in code with something other which can be anything. Isn't this obfuscation by definition? Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Proper preprocessor?
On Wednesday 20 June 2018 16:06:13 Michael Van Canneyt wrote: > > Please stop calling it 'dogma'. > > As with all features, it is a trade-off between the burden this places on > the compiler (and the people maintaining it) and the expected gain. > And the damage it causes on readability of code. Every new language feature will be used, every new language feature forces all programmers which have to read code from others to learn the new features. This is especially important for languages which are established in open source world. Macros are the worst code obfuscating feature ever. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Dynamic arrays using management operators
On Monday 04 June 2018 16:12:27 Michael Van Canneyt wrote: > > They make life easier by reducing the need for manual memory > management. No more, no less. Other than that they behave like normal > arrays on the heap. > It seems that the inclocked()/declocked() operations completely destroy the performance of the OP's application (which I find strange) so he never want to touch dynamic arrays anymore as he wrote. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Stack alias for ARC like memory management?
On 04/25/2018 03:52 PM, Ryan Joseph wrote: > > The team has done a good job keeping up with the best (or at least popular) > new ideas in programming (like Generics, records with methods, interfaces) > and that’s why I like to share what ever ideas I have in case they’re useful. Do you know MSElang objects? https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Managed record questions
On 03/08/2018 10:16 AM, Ryan Joseph wrote: > > > > I know this is how it is and not likely to change I’m just pointing it out. In MSElang objects and classes have been unified, they can be allocated on stack or on heap. They also have hooks for initialization and finalization which can be used to implement "ARC". https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MSEide+MSEgui 4.6 for FPC 3.0.4
On Sunday 26 November 2017 15:19:22 Andreas wrote: > > The architecture of MSEgui would allow to make widgets for Android in RAD > > style development, either ownerdrawn or wrapper for native widgets > > with 'ifi'-data- and event-connections to the business logic in the > > application. > > Today much of the maintenance at the client is done using netbooks. We > wish to use cell phone exclusively. We have a large program base with > many programs all written in FPC and/or Delphi. The company is migrating > all FPC to Rad Studio 10.2 so that the same code base can be used when > we migrate some of these programs to android. What Delphi technologies do you use on Android? Firemonkey? What is missing in Free Pascal? Can you be more specific? I doubt that the codebase of a desktop application can be used unchanged on a cellphone. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MSEide+MSEgui 4.6 for FPC 3.0.4
On Saturday 25 November 2017 15:04:05 Andreas Berger wrote: > On the Android side I actually only need a graphical app with access to > the Bluetooth and possibly be a TCP client. > And why Free Pascal to develop the android application? What would be the advantages instead to use the tools of the platform? The architecture of MSEgui would allow to make widgets for Android in RAD style development, either ownerdrawn or wrapper for native widgets with 'ifi'-data- and event-connections to the business logic in the application. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MSEide+MSEgui 4.6 for FPC 3.0.4
On Saturday 25 November 2017 11:52:39 Andreas Berger wrote: > I went back to Delphi because our company is converting all programs > that the maintenance uses to work on cell phones. Rad Studio 10.2 was > bought and even our desktop programs are being converted form > FPS/Delphi7 to Delphi 10. If FPC for Android worked off the shelf I > probably could convince the company to go back to FPC since all our > current projects work with it. Can you elaborate a bit what you actually need? Do you need a Firemonkey equivalent? Something other? Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MSEide+MSEgui 4.6 for FPC 3.0.4
On Friday 24 November 2017 18:38:39 Andreas wrote: > Hi Martin, do you have any plans to cross compile to android? > Maybe if there is enough interrest or a sponsor. What do you need? Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] MSEide+MSEgui 4.6 for FPC 3.0.4
Hi, MSEide+MSEgui version 4.6 has been released: https://sourceforge.net/projects/mseide-msegui/files/mseide-msegui/4.6/ There are also new versions of MSEgit, MSErun, MSEspice and MSEkicadBOM: https://sourceforge.net/projects/mseuniverse the cross environment for Raspberry Pi: https://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/ and FPC for Raspberry Pi: https://sourceforge.net/projects/mseide-msegui/files/fpcarm/ Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Defining sonames?
On Friday 18 August 2017 12:45:26 Graeme Geldenhuys wrote: > On 2017-08-18 10:27, Martin Schreiber wrote: > > If one manually changes in link.res > > hahaha... You read my mind, I was going to try that today in my lunch > time. :-) > > So now all that FPC needs is a new compiler parameter to tell it how to > generate the linker parameters, and when the alternative is specified, > not to strip the version info from the library name. That sounds doable > with no immediate harm to existing projects (after all, it will be a new > command line parameter). > Or simply treat a leading colon as start of a filename as ld does. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Defining sonames?
On Friday 18 August 2017 10:56:47 Graeme Geldenhuys wrote: > On 2017-08-18 08:16, Martin Schreiber wrote: > > I checked with a simple library file, it seems that FPC strips the ".so*" > > part from "external" names. > > Exactly what I discovered too. :-/ > If one manually changes in link.res " INPUT( -lX11 ) " to " INPUT( -l:libX11.so.6 ) " the application links without errors despite there is no libX11.so -> libX11.so.6 link. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Defining sonames?
On Friday 18 August 2017 07:28:01 Martin Schreiber wrote:
> On Thursday 17 August 2017 22:20:44 Graeme Geldenhuys wrote:
> > On 2017-08-17 16:52, Martin Schreiber wrote:
> > > Exactly. So why not use the SONAME in the Pascal binding unit instead
> > > to use the base name as Free Pascal currently does in xlib.pp for
> > > example?
> >
> > I forked the xlib, xutils and x units from FPC and tried just that. It
> > made no difference.
>
> Did you remove the various {$linklib} statements too?
> Did you check all units which where included by "uses" statements?
> BTW I tried to fork xlib.pp too but gave up because of the too many files
> which hat do be forked and it was too dangerous for existing projects.
>
I checked with a simple library file, it seems that FPC strips the ".so*" part
from "external" names. So the only way to make version-safe binding units in
Free Pascal seems to be to use dlopen()/dlsym().
Is this intended?
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Defining sonames?
On Thursday 17 August 2017 22:20:44 Graeme Geldenhuys wrote:
> On 2017-08-17 16:52, Martin Schreiber wrote:
> > Exactly. So why not use the SONAME in the Pascal binding unit instead to
> > use the base name as Free Pascal currently does in xlib.pp for example?
>
> I forked the xlib, xutils and x units from FPC and tried just that. It
> made no difference.
Did you remove the various {$linklib} statements too?
Did you check all units which where included by "uses" statements?
BTW I tried to fork xlib.pp too but gave up because of the too many files
which hat do be forked and it was too dangerous for existing projects.
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Defining sonames?
On Thursday 17 August 2017 17:31:46 Sven Barth via fpc-pascal wrote: > Am 17.08.2017 15:49 schrieb "Graeme Geldenhuys" < > > mailingli...@geldenhuys.co.uk>: > > On 2017-08-16 18:14, Sven Barth via fpc-pascal wrote: > >> As you can see the program will work correctly as long as the > >> libX11.so.6 file exists (even though that is a symlink itself, but the > >> X11 project guarantees that different libX11.so.6.x.y are compatible to > >> eachother), because the linker picks the SONAME that is set inside the > >> binary. And the libX11.so.6 symlink is part of the non-devel package. > > > > Sven, now here is an interesting problem regarding the way FPC (or Object > > Pascal in general) works with C based libraries. Martin pointed this out in > another mailing list, and he gave me permission to forward it here. What is > your answer or recommendation to this problem? > > Write in your application's readme which versions it requires. It might be > true that the devel packages contain the C-headers, but there might > nevertheless be failures if the applications > is programmed against the interface of the older v1 library (maybe they > changed the memory management for v2 and the problem will only manifest at > runtime). > Exactly. So why not use the SONAME in the Pascal binding unit instead to use the base name as Free Pascal currently does in xlib.pp for example? Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Defining sonames?
Hi, MSEgui uses xlib by the units in packages/x11. The linker searches for libX11.so which is not installed on most systems by default so one has to install the libx11 devel package or manually create a symlink libX11.so -> libX11.so.6 in order to compile MSEgui applications. Some users are unable to cope with this or give up with the comment "MSEide+MSEgui does not work on my system". Is it possible to add libX11.so.6 to the list of searched files for "X11" externals without using dlopen/dlsym? Thanks, Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Subclassing generic records?
On Friday 21 July 2017 23:04:20 Ryan Joseph wrote: > Thanks Sven, that’s one way around it. > > So is it by design that records don’t have inheritance or is this planned? > MSElang has a concept of unified record, object and class constructs. There a record is a simplified object which never has a VMT and has no methods. An object has a VMT only if the attribute [virtual] is given. An object can be instantiated in global or stack memory or on heap if it has a constructor() and destructor(). A class is an object which always is instantiated on heap and which provides implicit dereferencing. Classes can inherit from objects. https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects https://gitlab.com/mseide-msegui/mselang/wikis/home (under construction). Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing AggPas with PtcGraph
On Thursday 22 June 2017 18:47:40 James Richters wrote:
> I squeezed a little more out of putimage by doing as little math as
> possible with a couple of variables to store j*ptcwidth and i+j*ptcwidth I
> got my 1000x test loop down to 1.013 seconds. Here is what it looks like
> at the moment, any ideas on how to optimize it further?
>
"
var
pixels:Pword;
k: longint;
i, j, y1, x1, deltaX, deltaX1, deltaY: smallint;
JxW, I_JxW: Longword;
sourcepo,destpo,endpo: pcard16;
[...]
XORPut:
Begin
for j:=Y to Y1 do
Begin
JxW:=j*PTCWidth;
inc(k,deltaX);
sourcepo:= @pt(bitmap)[k];
destpo:= @pixels[jxw+x];
endpo:= destpo+x1-x;
inc(k,x1-x+1);
while destpo <= endpo do begin
destpo^:= destpo^ xor sourcepo^ and colormask;
inc(sourcepo);
inc(destpo);
end;
{
for i:=X to X1 do
begin
I_JxW:=i+JxW;
pixels[I_JxW] := pixels[I_JxW] xor (pt(bitmap)[k] and
ColorMask);
inc(k);
end;
}
inc(k,deltaX1);
End;
End;
"
On 32 bit Linux with 1024x768 screen and bitmap:
FPC 3.0.3 -O-:
1001 runs
origin 2.2167833261452355E+000 ms per put
mse 2.0649356462366574E+000 ms per put
FPC 3.0.3 -O3:
1001 runs
origin 2.2787212782151454E+000 ms per put
mse 6.0739260367848180E-001 ms per put
MSElang with LLVM 3.8.0 backend no optimisation:
1001 runs
origin 1.97338 ms per put
mse 2.03776 ms per put
MSElang with LLVM 3.8.0 backend -O3:
1001 runs
origin 0.406554 ms per put
mse 0.454978 ms per put
The project is here:
https://gitlab.com/mseide-msegui/mselang/tree/master/mselang/benchmark/putimage
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing AggPas with PtcGraph
On Friday 23 June 2017 06:38:18 Martin Schreiber wrote: > On Thursday 22 June 2017 18:47:40 James Richters wrote: > > I squeezed a little more out of putimage by doing as little math as > > possible with a couple of variables to store j*ptcwidth and i+j*ptcwidth > > I got my 1000x test loop down to 1.013 seconds. Here is what it looks > > like at the moment, any ideas on how to optimize it further? > > Please push your changes so we can work with the real code. > Sorry, I found it, it is in branch Avoid_ReChecking_Bitblt. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing AggPas with PtcGraph
On Thursday 22 June 2017 18:47:40 James Richters wrote: > I squeezed a little more out of putimage by doing as little math as > possible with a couple of variables to store j*ptcwidth and i+j*ptcwidth I > got my 1000x test loop down to 1.013 seconds. Here is what it looks like > at the moment, any ideas on how to optimize it further? > Please push your changes so we can work with the real code. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] named parameter
On Saturday 27 May 2017 11:30:38 Ryan Joseph wrote: > > can you show an example of this? Just curious. > In MSEgui most of the public widget methods an method properties use this approach. " type keyeventinfoty = record eventkind: eventkindty; key,keynomod: keyty; chars: msestring; shiftstate: shiftstatesty; eventstate: eventstatesty; timestamp: longword; //usec end; [...] twidget = class(tactcomponent,iscrollframe,iface,iassistiveclient) [...] procedure dokeydown(var info: keyeventinfoty); virtual; " " type tactionwidget = class(twidget) [...] property onkeydown: keyeventty read fonkeydown write fonkeydown; " https://gitlab.com/mseide-msegui/mseide-msegui/blob/master/lib/common/kernel/msegui.pas https://gitlab.com/mseide-msegui/mseide-msegui/blob/master/lib/common/widgets/msewidgets.pas Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
On Saturday 27 May 2017 03:37:59 Ryan Joseph wrote: > > Is MSElang another Pascal compiler? I’ve never heard of it. I know LLVM is > being used by Apple for Objective-C/Swift (I think) but for Pascal? > https://gitlab.com/mseide-msegui/mselang/wikis/home Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
On Saturday 20 May 2017 21:34:34 Jonas Maebe wrote: > > Also in summary, very little was learned from this. We have known for a > long time that FPC needs SSA for better code generation for loops (and > Florian has been working on it for a long time too). > Here for comparison the results of FPC / MSElang - LLVM 3.8.0: Linux 32 bit Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz With round() operations https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/benchmark/mctest/mctest.pas FPC 3.0.2 -O- -> 8 FPS -O4 -CfSSE3 -CpCOREI -> access violation -O3 -CfSSE3 -CpCOREI -> access violation -O2 -CfSSE3 -CpCOREI -> access violation -O1 -CpCOREI -CfSSE3 -> 12.5 FPS -O4 -CpCOREI -> 8.2 FPS MSElang, LLVM 3.8.0 No options -> 4.2 FPS -O3 -> 5.9 FPS -O3 -mcpu=corei7 -mattr=+sse3,+ssse3 -> 33.5 FPS With trunci32() operations https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/benchmark/mctest/mctest_trunc.pas -O3 -> 8.1 -O3 -mcpu=corei7 -mattr=+sse3,+ssse3 -> 41.5 FPS Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Good FFT example anywhere?
On Sunday 09 April 2017 10:06:41 Bo Berglund wrote: > I am looking for some good example of FFT functions in pascal but it > seems like what Google serves up is rather old and refers to > Turbo-pascal and the like... > So maybe someone here knows about some open-source example of FFT > using FreePascal (or Delphi)? > MSEgui has tfft which uses the FFTW library. https://gitlab.com/mseide-msegui/mseide-msegui/blob/master/lib/common/math/msefft.pas Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLQuery and buffering.
On Monday 27 March 2017 10:20:20 Gary Doades wrote: > >> It may be that UniDirectional is meant to not buffer all rows, but at > >> the moment it certainly seems to. > > > > Strange, looking at source code it seems to me, that buffering should not > > happen. As far as TUniDirectionalBufIndex should be used and his > > AddRecord method does not allocate new memory. > > Indeed, that's why I can't currently see where the problem lies. It > shouldn't buffer the rows/records, but it does... or at least something > does and I'm pretty sure it's not my program. The DB-client library maybe? Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLQuery and buffering.
On Sunday 26 March 2017 18:37:36 Michael Van Canneyt wrote: > > > Looking at the above unit, I can only presume you load the field directly > from the cursor returned by the native library. > Correct. > > As far as I can make out, TSQLResult is usable only for scanning a result > set. TDataset has a lot more functions, hence has a lot more overhead. > Correct. Therefore MSEgui has TmseBufdataset/TmseSQLQuery when the whole shebang is needed and TSQLResult when it is not. There is also the descendant TifiSQLResult which can be used as source for TConnectedifiDatasource in order to feed ifi-datapoints with DB-data. TSQLResult also can be used as source for TSQLLookupBuffer. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLQuery and buffering.
On Saturday 25 March 2017 10:28:37 Michael Van Canneyt wrote: > On Sat, 25 Mar 2017, Martin Schreiber wrote: > > On Saturday 25 March 2017 09:32:33 Gary Doades wrote: > >> I Understand about the "normal" use of TSQLQuery and data sets and I > >> also use this for small result set that need the data changing some way > >> and writing back to the DB. What I need now is an equally convenient and > >> powerful way of processing "big data". > > > > MSEgui has TSQLResult for that purpose without the TDataset overhead. > > https://gitlab.com/mseide-msegui/mseide-msegui/blob/master/lib/common/db/ > >msesqlresult.pas > > Can you explain in 2 words how this differs from TDataset ? > At first sight it is not fundamentally different. > The structure looks almost exactly the same, just the names are different. > Please follow the datatransfer from database to the destination in application in T*Dataset and compare it with TSQLResult and you probably will see the difference. > And while you're at it, please explain what the 'overhead' is of TDataset. > That TBufDataset introduces overhead is a design decision. But TDataset > itself introduces no "overhead". > TDataset/TDataSource/TDatalink/TField is a complex machine, don't you think? Follow the code of a TDataset.Next() call step by step and you will see what I mean. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLQuery and buffering.
On Saturday 25 March 2017 09:32:33 Gary Doades wrote: > > I Understand about the "normal" use of TSQLQuery and data sets and I also > use this for small result set that need the data changing some way and > writing back to the DB. What I need now is an equally convenient and > powerful way of processing "big data". > MSEgui has TSQLResult for that purpose without the TDataset overhead. https://gitlab.com/mseide-msegui/mseide-msegui/blob/master/lib/common/db/msesqlresult.pas Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MSEide+MSEgui 4.4 for Free Pascal 3.0.2
On Wednesday 01 March 2017 02:40:44 nore...@z505.com wrote: > On 2017-02-14 08:51, Martin Schreiber wrote: > > Hi, > > MSEide+MSEgui 4.4 for Free Pascal 3.0.2 has been released: > > https://sourceforge.net/projects/mseide-msegui/ > > > > There are also new versions of the ARM (Raspberry Pi) cross and native > > environments for Free Pascal: > > https://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/ > > https://sourceforge.net/projects/mseide-msegui/files/fpcarm/ > > > > and new versions of MSEgit, MSEspice and MSErun: > > https://sourceforge.net/projects/mseuniverse/ > > Is there a wiki or information page explaining what mserun is, along > with others mentioned above.. I could not find it on google. > MSErun is a tool which can be used to run command groups which are defined in a GUI in a hierarchical manner and which has the same flexible macro facility as MSEide. I use it as build tool for the MSE* projects and in order to run test cases. Please ask questions about the MSE* projects on the mailinglist: https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk Archive: http://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/ Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] MSEide+MSEgui 4.4 for Free Pascal 3.0.2
Hi, MSEide+MSEgui 4.4 for Free Pascal 3.0.2 has been released: https://sourceforge.net/projects/mseide-msegui/ There are also new versions of the ARM (Raspberry Pi) cross and native environments for Free Pascal: https://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/ https://sourceforge.net/projects/mseide-msegui/files/fpcarm/ and new versions of MSEgit, MSEspice and MSErun: https://sourceforge.net/projects/mseuniverse/ Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array as result in function.
On Thursday 19 January 2017 22:50:36 fredvs wrote: > function array_in_out(arrayin: TArFloat): TArFloat; > begin > result := arrayin; > end; > Do you change items of "arrayin" later? If so the items of the result array will be changed too, dynamic array assignment copies the data pointer only. http://www.freepascal.org/docs-html/current/ref/refsu15.html#x39-520003.3.1 Use " function array_in_out(arrayin: TArFloat): TArFloat; begin result:= copy(arrayin); end; " if the result array must be independent. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] performance when resizing a dynamic array
On 12/05/2016 10:52 AM, Jürgen Hestermann wrote: > > I love dynamic arrays and I never found that performance was an issue. > Agreed. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] performance when resizing a dynamic array
On 12/04/2016 11:39 AM, Martin Schreiber wrote: > On 12/04/2016 11:28 AM, Graeme Geldenhuys wrote: >> Hi, >> >> If I use an array to hold a list of say Integers. Is there any serious >> performance penalty for resizing (growing) the dynamic array as I add >> items. My point being, I don't know the number of elements I'll need >> beforehand. >> > The problem with enlarging big dynamic arrays is that AFAIK there always > is a move operation of the whole existing data. That happens with every reallocmem() with FPC memory manager so using a getmem() block instead of a dynamic array has no advantage in this regard. Dynamic arrays additionally call fillchar(). If fillchar() is not necessary for unmanaged items the MSEgui functions AllocUnInitedArray()/ReAllocUnInitedArray() can be used instead. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] performance when resizing a dynamic array
On 12/04/2016 11:28 AM, Graeme Geldenhuys wrote: > Hi, > > If I use an array to hold a list of say Integers. Is there any serious > performance penalty for resizing (growing) the dynamic array as I add > items. My point being, I don't know the number of elements I'll need > beforehand. > The problem with enlarging big dynamic arrays is that AFAIK there always is a move operation of the whole existing data. Libc realloc() on the other hand only relocates the pointer of a virtual memory block if possible. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] List of integers? Any class available in RTL or FCL to help?
On 12/04/2016 10:43 AM, Graeme Geldenhuys wrote: > The code I'm working on often needs a list of integers (actually uint16, > int16 etc, but Integer should do). I would normally use an array, but I > have no idea how many items I'll need beforehand. As an alternative to the FPC lists MSEgui provides the TDatalist hierarchy in lib/common/kernel/msedatalist.pas. For simple cases there is also lib/common/kernel/msearrayutils.pas with functions for dynamic arrays with an optional "count" parameter. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Using the LCL without Lazarus
On 12/03/2016 05:44 AM, BobJ wrote: > > I will be gllad to follow your lead to the MSE forum for future > discussion An archive of the thread is here: https://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/msg10682.html Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Using the LCL without Lazarus
On 12/01/2016 04:58 AM, BobJ wrote: > > Hello, > > Sent by: "fredvs" > Sent: Wednesday, November 30, 2016 9:12 AM > >> PS: MSEgui has a perfectly working assisted interface. > > Thanks, I will take a "look" at that, bearing in mind that sighted folks > often over estimate how usable anything will be for non-sighted folks. > That was my concern too when Fred started with the accessibility options for MSEgui. I suggested to use and extend the "iassistiveclient" and "iassistiveserver" interfaces of MSEgui in order to connect to standard screen readers instead to implement own reader functionality. Maybe continue the discussion on the MSEide+MSEgui mailinglist: mseide-msegui-t...@lists.sourceforge.net Registering page: https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Underscores in numerical literals - grouping
On 11/21/2016 03:46 PM, Graeme Geldenhuys wrote: >The age old rule > of programmer source code always being in a mono-spaced font is > ridiculous for this day and age. > I think you are wrong. A programmer scans code most the time vertically or block by block and not horizontally and word by word as normal text. And for that a monospace font is much better suited because of the straight vertical character columns. I know that this theme is off topic here but I thought somebody should express a different meaning. I also don't like elastic tabstops much BTW... Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface performance
On Friday 11 November 2016 12:08:26 Graeme Geldenhuys wrote: > On 2016-11-11 09:46, Ryan Joseph wrote: > > The string lookup absolutely murders performance (I was using “cobra” > > interfaces) so it can’t be used in some situations. > > If you are talking about the GUID, I'm not sure if you know, but when > using FPC's CORBA interfaces, you can use a MUCH shorter string which > gives better performance. MSEide even has built-in support to do just > that (generate smaller GUID values of about 6 characters long). > The minimum are 2 characters. Seeing that, actually the minimum could be 1, there is room for improvement. ;-) GUID is a little bit excessive, I call them UID. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)
On Friday 11 November 2016 07:48:54 Lars wrote: > On Thu, November 10, 2016 11:04 pm, Martin Schreiber wrote: > > On Friday 11 November 2016 04:21:31 Lars wrote: > >> Replying to an old thread in my inbox. Apologies if it's obsolete as it > >> is a month old. > > > > I don't think such themes are allowed in fpc-pascal. > > If an oberon like garbage collector, instead of reference counting, could > be somehow implemented into fpc, then it's still on topic. > > However, oberon garbage collector is likely to alien to apply to fpc. > I just wonder, since fpc is based on Wirth's work, if any fpc developers > have looked into how oberon does garbage collection, and applied this > knowledge to fpc. I tried to keep it as much on topic, in that sense - but > I understand it's not 100 percent fpc (as it currently stands) related. True, but my possible answers probably are below the tolerated level. ;-) Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)
On Friday 11 November 2016 04:21:31 Lars wrote: > > Replying to an old thread in my inbox. Apologies if it's obsolete as it is > a month old. > I don't think such themes are allowed in fpc-pascal. Please continue the discussion on MSEide+MSEgui mailinglist: https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk Archive: https://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/ Thanks, Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Smart link in FreeBSD multi-arch ?
On Monday 17 October 2016 15:30:36 Graeme Geldenhuys wrote: > On 2016-10-17 13:55, fredvs wrote: > > So it seems that garbage collection must be enabled to do a smartlink. > > I'm not sure I follow you. From what I understand from the FPC > documentation, is that FPC (when smartlinking is enabled) generates > multiple object files per unit, trying to make a object file per procedure. > Doesn't it use function-sections nowadays? Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)
On Thursday 06 October 2016 00:16:22 Tony Whyman wrote: > On 05/10/16 23:03, Graeme Geldenhuys wrote: > > Martin Schreiber recently mentioned in another Interface discussion that > > there is a very good reason he doesn’t use COM style interfaces… > > Reference Counting! > > Used properly reference counted interfaces are very powerful and allow > for some very elegant programming. Do you complain about AnsiStrings? > They are reference counted. Would you really want to have to free every > string explicitly? Dynamic arrays are similarly reference counted. > Reference counting is great for simple types like strings and dynamic arrays but is a nightmare with the venturesome mixture of COM-interface and classes from Delphi. Even reference counting for complex classes is no good idea IMO, I fear the times when FPC will implement ARC. I don't think that a programming language should hide more and more of the internal working of the code he writes from the programmer. Take a look at the modern C++ programs; the LLVM-compiler is a good example. It is horrific slow. Stepping through the code shows that there are complex multi-level dynamic type conversion and dataaccess routines at almost every statement. The typical C++ programmer does not need to care about because the programming language takes care for the boring tasks. The typical C++ programmer actually *does* not care about performance because competing programs are not faster; they are written in a modern programming language too... Recently I had to revive my stone old AMD-K6 PC with Windows 95. What marvel, that relict with its age-old applications provides a better user experience, is snappier, more convenient and more productive than my newest Linux machine with the modern desktops and applications. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] corba interfaces - is/as not working properly
On Thursday 29 September 2016 23:50:04 David Emerson wrote: > On 09/28/2016 10:42 PM, Martin Schreiber wrote: > > Corba-style interfaces can use any string as ID so for local interfaces > > it is possible to use shorter ID-strings for better performance. > > Is this described anywhere in the documentation? > http://www.freepascal.org/docs-html/current/ref/refse46.html#x100-1220007.6 Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] corba interfaces - is/as not working properly
On Thursday 29 September 2016 10:49:03 Graeme Geldenhuys wrote: > On 2016-09-29 06:42, Martin Schreiber wrote: > > abcintf:= iabc(abc); > > " > > which has the best performance. > > But you must still remember to check if abcintf has been successfully > assigned. > There will be a compiler error if "abc" does not implement "iabc". > [personal opinion] > Hence I still prefer the Supports(..) call as it can be used directly in > a boolean expression, the name itself makes it very clear what you are > asking from the code, and it just reads better. > Step through the code with F7 and you will see what overhead it means. AFAIK the compiler does not optimise for compiletime known case. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] corba interfaces - is/as not working properly
On Thursday 29 September 2016 01:14:44 David Emerson wrote:
> On 09/28/2016 03:31 PM, Graeme Geldenhuys wrote:
> > On 2016-09-28 22:59, David Emerson wrote:
> >> Alternately, if I give a GUID does an interface not automatically become
> >> COM + managed?
> >
> > No definitely not! The GUID just helps the compiler or RTL identify an
> > Interface.
>
> Oh fabulous! Thanks much. I definitely got a wrong impression on that one.
>
> > Ctrl+Shift+G in Lazarus IDE should generate a GUID for you.
>
> thanks, very handy :)
>
Corba-style interfaces can use any string as ID so for local interfaces it is
possible to use shorter ID-strings for better performance.
MSEide constructs such ID's by RightClick-'Insert UID'. Example: "['jA']{49}".
If the interface is listed in header of the queried class it is also possible
to get the interface by compile time type conversion:
"
type
{$interfaces corba}
iabc = interface
procedure a();
procedure b();
procedure c();
end;
tabc = class(tobject,iabc)
protected
procedure a();
procedure b();
procedure c();
end;
var
abc: tabc;
abcintf: iabc;
[...]
abcintf:= iabc(abc);
"
which has the best performace.
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] corba interfaces - is/as not working properly
On Wednesday 28 September 2016 21:40:39 Lars wrote:
> On Wed, September 28, 2016 2:24 am, Graeme Geldenhuys wrote:
> > On 2016-09-28 08:38, David Emerson wrote:
> >> I'm testing out CORBA interfaces before changing all my code to use
> >> them (I would prefer not to have managed types for interfaces).
> >
> > I've been using CORBA style interfaces for years,
>
> Curious, where do corba interfaces come in handy ?
Assume there is a support-function or -class, for example TStatFiler from
MSEgui, which stores and reads values to/from streams. It must call the
appropriate read and write functions in the client classes. It is possible to
define the functions in a common ancestor of the clients as "virtual
abstract" which enforces a single client-class hierarchy which often is
impossible to achieve.
The solution are interfaces but not the default COM-interfaces with their
reference counting nightmare but the not reference counted CORBA-interfaces -
which is a wrong name BTW because they have nothing to do with CORBA.
Clients of TStatReader/TStatWriter must implement the interface:
"
istatfile = interface(iobjectlink)[miid_istatfile]
procedure dostatread(const reader: tstatreader);
procedure dostatwrite(const writer: tstatwriter);
procedure statreading;
procedure statread;
function getstatvarname: msestring;
function getstatpriority: integer;
end;
"
iobjectlink provides basic object communication functionality:
"
iobjectlink = interface(inullinterface)
procedure link(const source,dest: iobjectlink; valuepo: pointer = nil;
ainterfacetype: pointer = nil; once: boolean = false);
procedure unlink(const source,dest: iobjectlink; valuepo: pointer = nil);
//source = 1 -> dest destroyed
procedure objevent(const sender: iobjectlink; const event: objecteventty);
function getinstance: tobject;
end;
"
inullinterface is an empty CORBA-style interface:
"
{$interfaces corba}
inullinterface = interface
//no referencecount
end;
"
If a client registers at TStatFiler it provides its "istatfile" pointer which
will be stored in a list in TStatFiler. TStatfiler will use this list in
order to call the necessary functions and procedures of the clients if
reading/writing has been triggered.
MSEgui extensively uses CORBA-interfaces.
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is there a reactive framework for Free Pascal?
On Thursday 07 July 2016 18:05:51 Dennis Poon wrote: > > I hope someone has done some work in this area which I can learn from. > MSEgui has teventthread: https://gitlab.com/mseide-msegui/mseide-msegui/raw/master/lib/common/kernel/msethread.pas and tthreadcomp: https://gitlab.com/mseide-msegui/mseide-msegui/raw/master/lib/common/kernel/msethreadcomp.pas Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .RSJ files vs .RST files
On Monday 04 July 2016 11:47:09 Graeme Geldenhuys wrote: > On 2016-07-04 10:31, Jonas Maebe wrote: > > Since we don't generate .rst files anymore, .rsj files are > > (codepage-safe) a replacement. > > Oh, no deprecation period - that's harsh. > > OK, I guess I'll have to start modifying my localisation utilities then. > Thanks for the information. > MSEgui has code for parsing *.rsj files. Please see lib/common/designutils/mseresourcetools.pas. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] reference-counted function results not initialized to nil
On Sunday 26 June 2016 12:09:58 Jc3bcrgen Hestermann wrote: > > The only exception (at least since FPC 3) is the function result > which is totally unexpected. > Why such an exception? > I don't think one could treat a function result as a normal local variable. The reason why not to initialise the result variable is because in many cases it is not necessary and reduces performance. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] UnicodeString and surrogate pairs
On Saturday 30 April 2016 12:12:35 Graeme Geldenhuys wrote: > > Anyway, I was refering to surrogate pairs (applies to UTF-16 only) > One could say that utf-8 has surrogate pairs, surrogate triplets and surrogate quads. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unit path search order
On Saturday 23 April 2016 11:18:48 Martin Schreiber wrote: > On Saturday 23 April 2016 10:40:58 Jonas Maebe wrote: > > Martin Schreiber wrote: > > > http://www.freepascal.org/docs-html/current/user/usersu7.html#x21-28000 > > >3. 1.2 states: > > > " > > > You can add a directory to the unit search path with the (-Fu (see page > > > 100)) option. Every occurrence of one of these options will insert a > > > directory to the unit search path. i.e. the last path on the command > > > line will be searched first. > > > " > > > Does this still apply? > > > > From looking at the compiler code: yes. > > I made a test. > [...] Bugreport is here: http://bugs.freepascal.org/view.php?id=30053 Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unit path search order
On Saturday 23 April 2016 10:40:58 Jonas Maebe wrote: > Martin Schreiber wrote: > > http://www.freepascal.org/docs-html/current/user/usersu7.html#x21-280003. > >1.2 states: > > " > > You can add a directory to the unit search path with the (-Fu (see page > > 100)) option. Every occurrence of one of these options will insert a > > directory to the unit search path. i.e. the last path on the command line > > will be searched first. > > " > > Does this still apply? > > From looking at the compiler code: yes. > I made a test. in ./: " program conssoletest; uses testunit; begin testunit0(); end. " in ./test: " unit testunit; interface procedure testunit0(); implementation procedure testunit0(); begin end; end. " in ./test1: " unit testunit; interface procedure testunit1(); implementation procedure testunit1(); begin end; end. " " mse@linuxmse:~/proj/consoletest> fpc -oconssoletest -Fu./test -Fu./test1 conssoletest.pas Free Pascal Compiler version 3.0.0rc2 [2015/10/14] for i386 Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for i386 Compiling conssoletest.pas Compiling ./test/testunit.pas Linking conssoletest /usr/bin/ld: warning: link.res contains output sections; did you forget -T? 14 lines compiled, 0.2 sec " " mse@linuxmse:~/proj/consoletest> fpc -oconssoletest -Fu./test1 -Fu./test conssoletest.pas Free Pascal Compiler version 3.0.0rc2 [2015/10/14] for i386 Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for i386 Compiling conssoletest.pas Compiling ./test1/testunit.pas conssoletest.pas(5,2) Error: Identifier not found "testunit0" conssoletest.pas(7) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: /usr/bin/ppc386 returned an error exitcode " Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Unit path search order
Hi, http://www.freepascal.org/docs-html/current/user/usersu7.html#x21-280003.1.2 states: " You can add a directory to the unit search path with the (-Fu (see page 100)) option. Every occurrence of one of these options will insert a directory to the unit search path. i.e. the last path on the command line will be searched first. " Does this still apply? My experiments seem to indicate that the first path on commandline is searched first. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus vs MSEgui
On Friday 08 April 2016 17:08:08 Anthony Tekatch wrote: > > Can MSEgui/MSEide be used to make programs for Mac OSX ? > Currently not. In case of OSX-X11 compatibility layer the effort probably is manageable. I would prefer a Quartz backend. Sponsors wanted! ;-) Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus vs MSEgui
On Friday 08 April 2016 13:33:35 Krzysztof wrote: > > I'm using MSEide only for design forms. For coding I'm still use > Lazarus (with paths to MSEgui source) so I still can enjoy with > Lazarus code completition, build modes etc. Just a little hint: MSEide has "build modes". IIRC it had it even before Lazarus introduced them. Please ask on the MSEide+MSEgui mailinglist if you like to know how it works. http://news.gmane.org/gmane.comp.ide.mseide.user https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Create dynamic SQL according to available params
On Thursday 07 April 2016 16:20:16 Santiago A. wrote:
> El 07/04/2016 a las 14:00, Luiz Americo Pereira Camara escribió:
> > I enconter the following pattern frequently (simplified):
> >
> > SQL:
> > Select * From Customers Where FieldX = 1
> >
> > Later i need a similar query that uses a different filter like
> >
> > Select * From Customers Where FieldX = 1 and FieldY = :paramy
>
> I remember a component of RxLib named TRxQuery. It had a published
> property "macros" of type TParams, so you could write this sql
>
> Select * From Customers Where FieldX = 1 and (%extrafilter).
In MSEgui SQL properties are of type TSQLStringList. TSQLStringList has a
property "Macros" which is an array of TSQLMacroItem. TSQLMacroItem.Value
inherits from TSQLStringList, so it is possible to build a macro tree which
items can be accessed by a name path (TMacroProperty.ItemByNames()).
"
select ${fields} from ${table} where ${filter}
"
in example
http://mseide-msegui.sourceforge.net/pics/sqlmacros.png
expands to
"
select FIELD1 from TABLE1 where FIELD1 = 'abc'
"
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] History of the Cardinal data type?
On Tuesday 29 March 2016 21:54:22 Graeme Geldenhuys wrote: > > > I'm inclined to use the (U)IntX (with X being a element of [8, > > 16, 32, 64]) types to avoid any confusion and surprises. > > That's not a bad idea either... I'll look into that for future code. > In MSElang the base types in unit "systypes" are named "int8", "int16", "int32", "int64", "card8", "card16", "card32", "card64". Floats are "flo32" and "flo64". For strings MSElang has "string8" (utf-8), "string16" (utf-16), "string32" (UCS4) and "string" (any 8 bit encoding or binary data). The variable size types (integer, cardinal, real) can be defined in "system". https://gitlab.com/mseide-msegui/mselang/wikis/home Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cwstrings unit and UTF8Decode()
On Friday 25 March 2016 15:37:36 Graeme Geldenhuys wrote: > On 2016-03-25 14:06, Martin Schreiber wrote: > > You can use the MSEgui functions in lib/common/msestrings.pas > > Thanks, but doesn't MSEgui also use cwstrings? > Not for utf-8 <-> utf-16 conversion. The MSEgui version of cwstring also maps unicodemanager conversion functions with cp_utf8 to the internal MSEgui functions instead to call iconv. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cwstrings unit and UTF8Decode()
On Friday 25 March 2016 14:48:18 Graeme Geldenhuys wrote: > On 2016-03-25 12:20, Bart wrote: > > If you're using LazUtf8 (or use LCL) then cwstring will be used in your > > app. > > I don't use LCL at all, pure RTL & FCL code only. Based on the fact that > LCL's code also requires "cwstrings" I assume my original assumptions is > correct, that if I want to do any UTF8-to-UTF16 conversions, use > UTF8Decode etc, my applications (or frameworks) require "cwstrings" for > now. > You can use the MSEgui functions in lib/common/msestrings.pas (stringtoutf8(), stringtoutf8ansi(), utf8tostring(), utf8tostringansi(). AFAIK both LCL and Free Pascal RTL also have such functions. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] MSEide+MSEgui 4.2
Hi, MSEide+MSEgui 4.2 has been released: https://sourceforge.net/projects/mseide-msegui/files/mseide-msegui/4.2/ There are also new versions of MSEgit, MSEspice and MSErun: https://sourceforge.net/projects/mseuniverse/files/ New target: Windows 64 bit. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Happy tickets benchmark
On Saturday 13 February 2016 11:44:27 Serguei TARASSOV wrote:
> Hello,
>
> Here is my little brute-force test for FPC, C and C# compilers.
> http://arbinada.com/main/en/node/1532
>
A slightely modified testcase because MSElang has no RTL yet:
"
program test;
var
n1, n2, n3, n4, n5, n6, n7, n8: 0..9;
TicketsCount: int32;
i1: int32;
begin
for i1:= 0 to 9 do begin
TicketsCount := 0;
for n1 := 0 to 9 do
for n2 := 0 to 9 do
for n3 := 0 to 9 do
for n4 := 0 to 9 do
for n5 := 0 to 9 do
for n6 := 0 to 9 do
for n7 := 0 to 9 do
for n8 := 0 to 9 do
if n1 + n2 + n3 + n4 = n5 + n6 + n7 + n8 then
inc(TicketsCount);
end;
writeln('Found ', TicketsCount, ' tickets.');
end.
"
"
#include
#include
int main()
{
unsigned char n1, n2, n3, n4, n5, n6, n7, n8;
int i1;
int tickets_count;
for (i1 = 0; i1 < 10; i1++){
tickets_count = 0;
for (n1 = 0; n1 < 10; n1++)
for (n2 = 0; n2 < 10; n2++)
for (n3 = 0; n3 < 10; n3++)
for (n4 = 0; n4 < 10; n4++)
for (n5 = 0; n5 < 10; n5++)
for (n6 = 0; n6 < 10; n6++)
for (n7 = 0; n7 < 10; n7++)
for (n8 = 0; n8 < 10; n8++)
if (n1 + n2 + n3 + n4 == n5 + n6 + n7 + n8)
tickets_count++;
}
printf("Found %i tickets.",tickets_count);
return 0;
}
"
MSElang with LLVM 3.7.0 backend -O3:
"
time ./test.bin
Found 4816030 tickets.
real0m0.997s
user0m0.993s
sys 0m0.003s
"
FPC 3.0 -O3:
"
time ./testfpc.bin
Found 4816030 tickets.
real0m5.576s
user0m5.572s
sys 0m0.002s
"
gcc 4.8.1 -O3:
"
time ./testgcc.bin
Found 4816030 tickets.
real0m1.649s
user0m1.645s
sys 0m0.002s
"
Stripped binary size:
MSElang5.5KB
FPC 3.0 21.6KB
gcc 4.8.1 5.5KB
Linux x86, AMD Athlon 4000+ 1GHz
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assign() vs AssignTo()
On Friday 12 February 2016 03:17:57 Dennis wrote: > > Is there any sample codes to copy published properties (via RTTI) ? > e.g. psuedo code below > >for i := 0 to properties.count -1 do begin > case properties[i].type of > vtInteger : properties[i].AsInteger := > Source.PropertiesByName(Properties[i].Name).AsInteger; > vtdouble : > vtString : ... > end; >end; > MSEgui has such code for "trttistat" component, please see https://gitlab.com/mseide-msegui/mseide-msegui/raw/master/lib/common/kernel/mserttistat.pas although it is specialised for saving and editing options. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assign() vs AssignTo()
On Thursday 11 February 2016 17:17:32 Graeme Geldenhuys wrote: > > Now the other thing that surprised be, I thought TPersistent.Assign() > automatically handles protected properties (via RTTI) - thinking that > descendants automatically get such functionality for free. But reviewing > the RTL code, I see Assign() and AssignTo() really has no functionality > implemented by default. > Correct, it depends much on the actual classes what should happen by calling "assign()". So "tpersistent" does nothing by default. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assign() vs AssignTo()
On Thursday 11 February 2016 16:13:22 Graeme Geldenhuys wrote: > Hi, > > In TPersistent, we have two virtual methods. Assign() which calls > AssignTo(). > > 1) Why are they both virtual? It seems like Assign() is what I call a > template method, farming its work out to other helper methods - in this > case, AssignTo(). Normally template methods are not virtual, but their > helper methods (the ones doing the actual work) are. So again, why is > Assign() virtual? > If one wants to transfer property values from "source" to "dest" one calls "dest.assign(source)". If "dest" does not know how to handle "source" it calls "source.assignto(self)". > 2) Now seeing that both are virtual, and that is probably not going to > change in the RTL, which method is the preferred method to override so > you have the ability to do MyObject.Assign(MySource)? I've been > overriding Assign(), but thinking that maybe I should have overridden > AssignTo() instead. > It depends on what knows to handle what. Sometimes both have to be overridden. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New feature: IfThen() intrinsic
On Tuesday 02 February 2016 13:22:01 Jonas Maebe wrote: > Michael Van Canneyt wrote on Tue, 02 Feb 2016: > > [evaluating all arguments to a function/intrinsic] > > > I'm just trying to to put any foaming-at-the-mouth argumentation > > using this particular argument in perspective. > > I think this is rather disingenuous after your own > foaming-at-the-mouth hyperbole (?) of reverting all changes and > temporarily shutting down the svn server if someone else did something > that you considered to be fundamentally wrong. > > > For a correct understanding: The compiler must behave predictable at all > > times, no arguing there. But I don't think that iif() having different > > semantics than all other functions, is a problem. > > Including all other functions called iif(). > > > It just needs to be > > documented properly. It is a non-issue for me. > > It is a deal breaker for me. > Agreed. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New feature: IfThen() intrinsic
On Tuesday 02 February 2016 13:39:17 Michael Van Canneyt wrote: > On Tue, 2 Feb 2016, Martin Schreiber wrote: > > On Tuesday 02 February 2016 13:22:01 Jonas Maebe wrote: > >>> It just needs to be > >>> documented properly. It is a non-issue for me. > >> > >> It is a deal breaker for me. > > > > Agreed. > > Quick ! > We should call the New York Times or Frankfurter Allgemeiner Zeitung, > Martin just agreed with someone of the core team !!! > There are not many occasions where I have fundamental other opinions than Jonas regarding FPC. Currently I can't remember a single instance. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New feature: IfThen() intrinsic
On Tuesday 02 February 2016 10:41:39 Serguei TARASSOV wrote: > On 02/02/2016 10:29, fpc-pascal-requ...@lists.freepascal.org wrote: > > 2016-02-01 10:59 GMT+01:00 Michael Schnell: > > Same here. I see no reason to differ from it. Introducing new > > incompatibility is bad idea. For me is good to have booth (Oxygene > > compatible): > > > > x := iif (a < 3, 1, 2); > > V := If a < 3 then 1 else 2; > > > > sometimes is better to use first option and sometimes is better to use > > second option. Both Oxygen compatible and very "pascalish". > > No, the second is always better because safer. > And it could be extended to " V:= case i1 of 1: 'one'; 2: 'two'; else 'none'; end; " In my opinion there should be as less intrinsics as possible. In MSElang I even try to get rid of "writeln()" as compiler intrinsic. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RTL with debug info on win64
On 28.01.2016 07:27, Martin Schreiber wrote: Hi, I am not able to build a fixes_3_0 RTL with debug info on win64 with a fixes_3_0 ppcx64.exe. How should it be done? I'll probably found the problem, sorry for the noise. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] RTL with debug info on win64
Hi, I am not able to build a fixes_3_0 RTL with debug info on win64 with a fixes_3_0 ppcx64.exe. How should it be done? Thanks, Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ideU version 1.0.0.
On Saturday 26 December 2015 10:55:02 fredvs wrote: > > And why complain so late, after all the contacts that we had ? > Ouh, you are sensitive. ;-) Nobody complains! Its only if I read that MSEide is difficult to install or something similar I like to knew why because I always try to make things as easy as possible. But we should not talk about MSEide here. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ideU version 1.0.0.
On Thursday 24 December 2015 16:58:16 Paul Breneman wrote:
> On 12/24/2015 11:06 AM, Martin Schreiber wrote:
> >
> > Maybe you should list the original too? ;-)
> >
> > Martin
>
> Yes I should, but the original is not as simple for a beginner to
> install.
???
Frome MSEide README.TXT:
"
1. Download and install FPC 3.0.0, you can get it from
http://www.freepascal.org/download.var
2. Download mseide_msegui_src_4_0.zip and the mseide_* archive
for your system.
http://sourceforge.net/projects/mseide-msegui/files/mseide-msegui/4.0/
3. Extract them to a directory of your choice ('yourdirectory') .
4. Run 'yourdirectory/bin/mseide' on linux and freebsed or
'yourdirectory\bin\mseide.exe' on windows.
5. In 'Settings'-'Configure MSEide'-'${MSEDIR}' select 'yourdirectory/msegui'.
6. In 'Project'-'Open' select 'yourdirectory/msegui/apps/demo/demo.prj'.
7. 'Target'-'Continue'.
"
where 6. and 7. already are steps to compile and run the demo application. Is
this really too difficult for people who like to develop software? ;-)
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ideU version 1.0.0.
On Thursday 24 December 2015 15:24:29 Paul Breneman wrote: > Thanks for a simple IDE that a beginner can install. I've already > posted a few links on my pages. > > At the bottom of this page: >http://www.controlpascal.com/tutorial.htm > it now leads here: >http://turbocontrol.com/devoptions.htm > which has a link to ideU at the bottom. > > The bottom of two pages doesn't sound very good but hopefully this will > improve. Thanks again! :) > Maybe you should list the original too? ;-) Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Unicode / CodePage aware strings
On Thursday 10 December 2015 12:01:49 Graeme Geldenhuys wrote:
>
> ===
> program project1;
>
> {$mode delphiunicode}{$H+}
>
Try {$codepage utf8}.
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Updated FPC from svn but make does not work..
On Monday 23 November 2015 06:13:43 Martin Schreiber wrote: > > It is probably possible to use git locally by an import of the CSV history > https://git-scm.com/docs/gitcvs-migration > and to fetch/push the changed files from/to the CSV server. http://www.oak.homeunix.org/~marcel/blog/2009/06/03/tracking-cvs-with-git-using-cvs2git Please continue the thread on mseide-msegui-task if you like: https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk http://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net http://dir.gmane.org/gmane.comp.ide.mseide.user It is less strict regarding subject matter than fpc-pascal. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Updated FPC from svn but make does not work..
On Sunday 22 November 2015 20:32:47 Bo Berglund wrote: > On Sun, 22 Nov 2015 05:56:55 +0100, Martin Schreiber > > wrote: > >And I strongly suggest to drop CVS and to use git > >instead. ;-) > >There is even a git client GUI written in Free Pascal: > >http://sourceforge.net/projects/mseuniverse/ > > Not so easy, since the company version control uses CVS since many > years. Switching to something else is a major engagement... > Of course I could use something newer myself locally, but the idea is > to have everything in the company version control system. It is probably possible to use git locally by an import of the CSV history https://git-scm.com/docs/gitcvs-migration and to fetch/push the changed files from/to the CSV server. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Updated FPC from svn but make does not work..
On Saturday 21 November 2015 19:25:27 Bo Berglund wrote: > >> On that we'll have to disagree. The RPi, particularly the 2, is an > >> entirely adequate computer in its own right. > > > >Sure but the accustomed development environment (tools, documentation, > > version control, useful links, mail and mailinglists...) must first be > > installed and maintained separately. > >I find it much more convenient to use a single "every day" development > >environment for all tasks. > [...] > > So I think I will re-visit the Linux on x86 with cross-compilation > again. This I think was my path when I asked here first... > But I thought the cross-compile looked difficult to set up. > Maybe not now any longer. > > If one goes Linux Mint, what version is the one I should choose to get > FPC/Lazarus working in the easiest way with cross compilation for > ARMHF? I use 32 bit OpenSUSE 13.1. And I strongly suggest to drop CVS and to use git instead. ;-) There is even a git client GUI written in Free Pascal: http://sourceforge.net/projects/mseuniverse/ Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] MSEide+MSEgui version 4.0 for FPC 3.0.0
Hi, MSEide+MSEgui 4.0 for FPC 3.0.0 has been released! https://sourceforge.net/projects/mseide-msegui/ There are also new versions for MSEgit, MSEspice and MSErun: https://sourceforge.net/projects/mseuniverse/ Have a lot of fun! Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Updated FPC from svn but make does not work..
On Tuesday 10 November 2015 09:48:23 Mark Morgan Lloyd wrote: > > > > Yes. And I recommend to use cross compiling and debugging from a X86 > > Linux PC: > > http://www.mail-archive.com/lazarus%40lists.lazarus.freepascal.org/msg504 > >06.html > > On that we'll have to disagree. The RPi, particularly the 2, is an > entirely adequate computer in its own right. Sure but the accustomed development environment (tools, documentation, version control, useful links, mail and mailinglists...) must first be installed and maintained separately. I find it much more convenient to use a single "every day" development environment for all tasks. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Updated FPC from svn but make does not work..
On Monday 09 November 2015 23:57:30 Bo Berglund wrote: > On Mon, 9 Nov 2015 15:19:12 +0100, Martin Schreiber > > wrote: > >On Monday 09 November 2015 11:35:05 Mark Morgan Lloyd wrote: > >> So. I'd suggest that you start off with Martin's binary, build the > >> matching 2.6.4, > > > >FPC 2.6.4 has no support for EABIHF AFAIK. I have a patched 2.6.4 version > > with EABIHF support but I suggest to use FPC 3.0 or fixes_3_0 instead. I > > am sure Bo knows where to get it. ;-) > > Sources yes, I have checked out something like 4 different source > trees by now. > But the binaries are another deal... I fear you do not read my mails. http://sourceforge.net/projects/mseide-msegui/files/fpcarm/ > What is EABIHF? The application binary interface of RaspberryPi. > So you think that fixes_3_0 would be a better fpc on my RPi2? Yes. And I recommend to use cross compiling and debugging from a X86 Linux PC: http://www.mail-archive.com/lazarus%40lists.lazarus.freepascal.org/msg50406.html Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Updated FPC from svn but make does not work..
On Monday 09 November 2015 11:35:05 Mark Morgan Lloyd wrote: > > So. I'd suggest that you start off with Martin's binary, build the > matching 2.6.4, FPC 2.6.4 has no support for EABIHF AFAIK. I have a patched 2.6.4 version with EABIHF support but I suggest to use FPC 3.0 or fixes_3_0 instead. I am sure Bo knows where to get it. ;-) Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MSEide+MSEgui 4.0beta1 for FPC 3.0
On Friday 02 October 2015 11:14:26 Rainer Stratmann wrote: > Is it possible now to go behind the last character with the cursor? > > code abcdefg[c] > > [c] = cursor > No. :-) Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] MSEide+MSEgui 4.0beta1 for FPC 3.0
Hi, MSEide+MSEgui 4.0beta1 for FPC 3.0 is ready for testing: http://mseide-msegui.sourceforge.net/pics/mseide_4_0.png http://sourceforge.net/projects/mseide-msegui/files/mseide-msegui/4.0beta1/ There are also new versions for MSEgit, MSEspice and MSErun: http://sourceforge.net/projects/mseuniverse/files/ Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FileIO in FPC 3.0
On Friday 25 September 2015 10:26:44 Michael Van Canneyt wrote: > So if you use widestring for all your filename strings, there will be no For better performance probably UnicodeString not WideString. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to compile Lazarus program using only FPC?
On Friday 25 September 2015 03:52:25 Bo Berglund wrote: > On Thu, 24 Sep 2015 09:48:32 -0400, Bo Berglund > > wrote: > >I want to check my options regarding Lazarus and FPC. > > > >If I develop a program on Windows Lazarus, move it to Debian Lazarus > >(x86) and then finally want to compile on ARM on for example Raspberry > >Pi but outside of Lazarus, how is that done? > >Does FPC recognize the Lazarus project file such that paths etc are > >observed? > >Or is thare a separate file for FPC I have to prepare in order to set > >the unit paths? > > I see from some replies that I was not complete in my formulations... > What I wanted to ask was what steps I need to take in order to do the > final compilation on a *headless* ARM platform such as RaspBerry Pi2 > where FPC has been installed but nothing else. > The development itself would be done in Lazarus (on Windows and > LinuxMint x86) in order to get the IDE help. Please remember my recommendation of cross development and debugging Linux X86 PC -> Raspberry Pi with MSEide and cross FPC. http://www.mail-archive.com/lazarus%40lists.lazarus.freepascal.org/msg50406.html Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resourcestrings in FPC 3.0
On Thursday 24 September 2015 09:52:34 Jonas Maebe wrote:
> Martin Schreiber wrote:
>
> >>> Another question, it looks to me that -Fcutf8 does not work like
> >>> {$codepage utf8} for string constants. Is this intend?
> >>
> >> I think they should have the same effect.
> >
> > Another bug?
>
> If they don't have the same effect, it's a bug, yes.
>
http://bugs.freepascal.org/view.php?id=28718
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resourcestrings in FPC 3.0
On 24.09.2015 09:22, Graeme Geldenhuys wrote:
> On 2015-09-24 09:09, Martin Schreiber wrote:
>> It is an advantage to have pure ASCII files for such data.
>
>
> Escaped text seems optional, but the UTF-8 encoding seem recommended.
> Using non-escaped Unicode text is faster to parse and easier to read [by
> a human] - and from my understanding of the RFC specs, less error prone.
>
> See also the important point about escaped text and UTF-16.
>
> “JSON documents can be encoded in UTF-8, UTF-16 or UTF-32, the default
> encoding being UTF-8.[14] These encodings support the full Unicode
> character set, including those characters outside the Basic Multilingual
> Plane (U+1 to U+10). However, if escaped those characters must
> be written using UTF-16 surrogate pairs, a detail missed by some JSON
> parsers. For example, to include the Emoji character U+1F602 😂 face
> with tears of joy in JSON:
>
> { "face": "😂" }
> // or
> { "face": "\uD83D\uDE02" }
> ”
I did not miss it. ;-)
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resourcestrings in FPC 3.0
On Thursday 24 September 2015 09:46:06 Michael Van Canneyt wrote: > On Thu, 24 Sep 2015, Martin Schreiber wrote: > > On Thursday 24 September 2015 09:28:28 Jonas Maebe wrote: > >>> Should I make a bug report? > >> > >> There is already a (very old) bug report for that. > > > > I meant a bug report for the unusual json format. > > Please do. > http://bugs.freepascal.org/view.php?id=28717 Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resourcestrings in FPC 3.0
On Thursday 24 September 2015 09:59:49 Graeme Geldenhuys wrote:
> On 2015-09-24 08:14, Martin Schreiber wrote:
> >> > What did you expect to see ?
> >
> > "
> > {"version":1,"strings":[
> > {"hash":7200948,"name":"json.a","value":"a\u00E4\u00C4"}
> > ]}
> > "
>
> I would have expected the same as the original.
>
> "
> {"version":1,"strings":[
> {"hash":7200948,"name":"json.a","value":"aäÄ"}
> ]}
> "
>
It is an advantage to have pure ASCII files for such data.
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resourcestrings in FPC 3.0
On Thursday 24 September 2015 09:28:28 Jonas Maebe wrote: > > > > Should I make a bug report? > > There is already a (very old) bug report for that. > I meant a bug report for the unusual json format. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resourcestrings in FPC 3.0
On Thursday 24 September 2015 09:28:28 Jonas Maebe wrote:
>
> There are several more, including lack of support for non-ansi encoded
> file names and most classes that (still) exist only in ansistring form.
> You can of course create replacements for all of that, but then again,
> you could also implement a replacement for resourcestrings in that case.
>
Do you think it is possible without compiler magic other than parsing the
sources?
> I'm not suggesting that this is what you should do, nor that FPC
> shouldn't support resourcestrings in arbitrary encodings or at least
> with a deducible encoding for external tools (since apparently external
> tools are supposed to be able to work with these generated files), but I
> don't think there's a fundamental difference between these cases.
> Standard Pascal IO routines are as much part of the language as
> resourcestrings are.
>
> > Should I make a bug report?
>
> There is already a (very old) bug report for that.
>
Can you give a link please?
> > Another question, it looks to me that -Fcutf8 does not work like
> > {$codepage utf8} for string constants. Is this intend?
>
> I think they should have the same effect.
>
Another bug?
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resourcestrings in FPC 3.0
On Thursday 24 September 2015 09:21:01 Mattias Gaertner wrote:
> On Thu, 24 Sep 2015 09:10:06 +0200
>
> Martin Schreiber wrote:
> >[...]
> > Another question, it looks to me that -Fcutf8 does not work like
> > {$codepage utf8} for string constants.
>
> What do you mean?
>
If I looked right, {$codepage utf8} sets cp_utf8 in resource strings,
compiling a unit with -Fcutf8 does not.
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resourcestrings in FPC 3.0
On Thursday 24 September 2015 09:00:47 Michael Van Canneyt wrote:
> > produces the file json.rsj
> > "
> > {"version":1,"strings":[
> > {"hash":7200948,"name":"json.a","value":"a\u00C3\u00A4\u00C3\u0084"}
> > ]}
> > "
> > Is this intended? How can translation tools know that the Unicode points
> > must be interpreted as utf-8 code units in this case?
>
> What did you expect to see ?
>
"
{"version":1,"strings":[
{"hash":7200948,"name":"json.a","value":"a\u00E4\u00C4"}
]}
"
> Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
