* * *

Recent Posts

Pages: [1] 2 3 ... 10
General / Re: Lazarus 2.1 in the trunk!
« Last post by mangakissa on Today at 08:22:54 am »
1.10 looks reasonable for me. If you're going to big changes like a whole new IDE, better debugtool, using commerial third party tools without the source, (amost) compatible with importing delphi applications, much easier approch of creating mobile apps, then you can talk about version 2.0.
General / Re: Too many cycles
« Last post by Thaddy on Today at 07:57:34 am »
Indeed. FWIW this seems close to the other solutions:
Code: Pascal  [Select]
  1. program untitled;
  2. {$mode delphi}
  3. uses
  4.   sysutils, classes, bufstream;
  5. var
  6.   i, j, k, count : Integer;
  7.   T0, T1, Diff: TDateTime;
  8.   SS,SB:TStream;
  9. begin
  10.   T0 := Now;
  11.   if FileExists('test.txt') then Deletefile('test.txt');
  12.   SS:=TFilestream.Create('test.txt', fmCreate or fmOpenWrite or fmShareExclusive);
  13.   SB:=TWriteBufStream.Create(SS,16384);
  14.   count := 0;
  15.   for i := 1 to   20 do
  16.   try
  17.     for j := 1 to 8765 do
  18.       if (j <> i) then
  19.         for k := 1 to 5673 do        
  20.           if (k <> i) and (k <> j) then
  21.           begin
  22.             Inc(count);
  23.             if ((Count mod 100000)=0) then writeln(count);
  24.             SB.WriteAnsiString(
  25.                     (i / 3).ToString(ffNumber,4,2)+' '+
  26.                     (j / 4).ToString(ffNumber,4,2)+' '+
  27.                     (k / 2).ToString(ffNumber,4,2));
  28.           end;        
  29.   finally
  30.     SB.Free;
  31.     SS.Free;
  32.   end;
  33.   T1 := Now;
  34.   Diff := T1-T0;
  35.   writeln(count,' items: ',timetostr(Diff));
  36. end.
General / Re: Lazarus 2.1 in the trunk!
« Last post by valdir.marcos on Today at 07:36:22 am »
... and the planned Laz 1.10 (http://wiki.freepascal.org/Lazarus_1.10.0_release_notes#TAChart) ...
Just curious.
Lazarus next version will be 1.10 or 2.0?

what i mean is that you could have done 1.10 and not 2.0, so i'm trying to understand why.

what i mean is that you could have done 1.10 and not 2.0, so i'm trying to understand why.
Flip a coin?
More or less yes. This version has new and improved features but so had the earlier versions. I personally prefer 2.0 because:
1. The major number jump can be seen as cumulative from earlier minor number versions. If the substantial new features did not justify a major number change then nothing will and we would have 1.xxx forever.
2. Version 1.10 looks confusing. Is it bigger than 1.2.0?

BTW, at least the revamped publish project / package dialog feature is missing from release notes. Must add it later.

2. Version 1.10 looks confusing. Is it bigger than 1.2.0?

Not so much confusing for people as for machines, bad programming (comparing versions string based) will fail.

Well to me (I'm not a machine, at least I wasn't programmed to think so) it looks confusing as well  O:-)
Once I saw "Lazarus 1.10.0 release notes" wiki topic on last June, I questioned that and no one noted or cared until now.:)
Beginners / Re: Hints about fpc.cfg and debugger that does not stop
« Last post by Thaddy on Today at 05:19:19 am »
Yes, but additionally:
Old tp programs under Windows need to have {$apptype console} added on top of the program file,like so:
Code: Pascal  [Select]
  1. program myoldtpcode;
  2. {$apptype console}
  3. begin
  4. end.
Otherwise the console code is not set up.
This has been introduced in Delphi 1 and is not Freepascal specific.

Note that you may have to use {$mode TP} too.
LCL / Re: MaskEdit is jumpy
« Last post by Middlecope on Today at 04:00:53 am »
Yes Bart,
I will (can) do. For me it is a problem that needs to be resolved.
I will continue in this threat. (topic)
Teunis on monday I will give it a try
Actually, the browser component is not destroyed, but it seems to be hidden from container and inaccessible, so in order to workaround I followed this steps to kinda keep it.

Before changing BorderStyle, first set ActiveXContainer.Active to False, then change BorderStyle, afterwards restore ActiveXContainer.Active to True, but it will be shown a blank content, so Navigate2 is called again (the page will be loaded again), which is not what is expected. But at least is better than having browser lost.

Hope someone shows the correct way to fix this issue.
Just to make 100% sure: You are talking about the call to HackLoad in the above code where you are passing empty array []?


If yes, this is the code of HackLoad:
There is no code in HackLoad outside the loop... So if it is passed empty array then nothing happens? But I am tired, so if I missing something then...

No, you didn't missed anything.  It was indeed a logic bug in Indy's code, I didn't see it before.  The *INTENT* was to specify an empty array to skip the versioned files, but it was not actually doing that correctly.  I have now fixed it.
Hello, I'm following http://wiki.lazarus.freepascal.org/LazActiveX TEvsWebBrowser demo snippet, and it works fine. I'm trying to turn it into a full screen application, so I change BorderStyle to bsNone and perform maximize messages (F11 hotkey, also using a menu), it works but TEvsWebBrowser disappears and it seems it is destroyed somehow. I also tried to create using a TPanel as parent, but it doesn't matter where I create the webbrowser, changing BorderStyle (to a different one) deletes it.

Hope you can help me. Regards! :)
Sigh. Yes, I now the theory. But let's examine what there is now: it seems the default lazarus package distributed by Debian/unbuntu can't build itself after 15 years of package work (20+ in the case of FPC on Debian).

Which is why most people use Lazarus generated debs, downloaded from the site.

This means by the most majorly used distros (Ubuntu,Debian) this will already horribly fail due to two different lazarus builds in roulation (per distro-version).

Does it then really make sense to dream of the next step, and implement gigantic major features like binary packages?

When do you expect the distros to have it working ? By 2100?


yes, binary packages are worked on (though probably not in the next major version, so this is years away), but I think the main goal is plug-in architectures in your own applications.

For lazarus IDE, it is more mixed, it will of course speed up installing packages, but at the same time it will significantly delay IDE startup (most of the splash screen time of Delphi is packages initialization, and their implementation is probably faster than ours).

I wouldn't be surprised if whole swaths of more advanced users will avoid a package based IDE because of that.

It also won't make anything easier, since both contrary to delphi, there will be version mismatches due to independent building. That remains the same for source and binary. (except that with source you get a hint what is wrong with an error in a line. With binary packages you get either a message that doesn't say much ('package incompatlbe, crc doesn't match") or a fat GPF.

I do share your pain and making a single Linux binary running on all versions of Linux distros would be awesome.

For simple (C) programs, I was able to produce statically linked binaries that has better portability, but on some platforms, it remains failed with the incompatible GLIBC_xx flags or GOMP_xx flags, despite that I've statically linked these libraries. in those occasions, I felt extremely frustrated and even angry, like you felt.

I think the major issue is that the core system libraries (like glibc) does not have a standardized core, or has a modular design that aims for high portability. the developers often make least scrutinized decisions that often lead to breakage of backward compatibility. The pursing of latest features (like the c++17 standards) often outweigh the compatibility of existing and legacy features in their decision-making. If the gcc team were run by a company, breaking backward compatibility equals to losing existing customers, that's a penalty that is big enough for them to pay attention to it, but this does not seem to apply to the open-source developer teams.
First, and generally, it will not work, only if your build system has more recent libraries then those on distribution target. I'm building binaries on Debian which are working on OpenSuse and of course on Ubuntu, without any special efforts. You simply need to be sure your let' say libglxxx.so.xxx on build system is not newer than suggested target. In case target machine has outdated system, you could fix it with package dependencies (don't know about others, but it works with .deb/apt environment).

You don't need `to compile glscene`. You (compiler) need some particular units (with respective dependencies) from there.

Lazbuild just needs a Lazarus project. Paths for sources are stored (by default) in relative format there.
All you have to do is to maintain the same (as on development workstation) directory structure on a build machine.
Not to mention you could use Build modes (Debug/Release/Whatever) and redefine paths there, individually for each mode.

thanks for the comment. I opened the .lpi file and from the section named "Units", I found a number of GLScene Units that was referred using its absolute path, and I copied those in a subfolder in my project's folder, and changed the lpi Units section and replaced the path with the relative local path


I was able to compile my project on a system with a freshly installed lazarus 1.8.3, but I do not see any of the GLScene units (*.pas) were compiled in the command line output, lazbuild also emit the following warning:

Code: Pascal  [Select]
  1. .../mcxstudio.lpr(10,10) Hint: (5023) Unit "GLScene_RunTime" not used in mcxstudio

I did not copy the GLScene_RunTime.lpk file to my project.

after compilation, the binary can be launched, but when I click on the menu to show the GLscene window, it gave me an access violation error.  This does not happen in my lazarus-ide compiled binary.

any thing I missed?

to reproduce this issue, you may use the below commands:

Code: Pascal  [Select]
  1. git clone https://github.com/fangq/mcx.git
  2. cd mcx
  3. git checkout etherdome
  4. cd mcxstudio
  5. lazbuild --build-mode=release mcxstudio.lpi

then run the GUI at debug/mcxstudio. The access violation error happens when one select the toolbar Plot\Preview.
Pages: [1] 2 3 ... 10


Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus