mORMot Open Source

Thanks, i will use suitable temp fix.
Would be cool if mORMot v2 will be fully Unicode aware (for FPC, including file paths and file operations).

Code below works, but require to load entire file.

{$mode delphi}

var
  FilePathStr: RawUtf8;           // 'C:\Program Files (x86)\'#208#161#208#181#209#128#208#178#208#181#209#128'\test.txt'
  FileData:    RawByteString;
  Result:      RawUtf8;
begin
  FileData := ReadFileToString(FilePathStr);
  Result := MD5(FileData);
end;

Same with Utf8ToWinAnsi, cyrillic symbols become "?".
UTF8ToString(SrcPath) works only when system encoding is russian.

mORMot 2 looks so pretty, and seems, SM engine will be included as well.
In mORMot 1.18, in order to get working SyNode, we must use separate branch.
How it will be implemented in mORMot2 - will the SyNode code appear on the master branch?

Ping unitybase.info reports same ip 91.214.182.35
I believe this is some sort of cross country restrictions.
But i have no idea how it affects tor browser as well.

I tested from 4 separate ISPs and 3 different devices from different networks (and from mobile phone as well).

It seems, links are broken

Currently, I'm not familiar with new mORMot2 module naming
But, I can share thoughts.

In order to compile zeos with mormot, zeos require some files, for example, SynCommons (which require SynLZ as well).
With those modules, zeos should compile.
So, you may create mormot2.common.lpk and include modules, that does not require much of your modules, just common part like SynCommon, SynLZ (and definitely, mormot.common.lpk should not rely on zeos).
In that case, zeos team can add custom package option (like you did) if checked, user should add mormot.common.lpk dependency to zcomponent package manually in order to compile zeos.

Next, your module, that rely on zeos, should be extracted to separate package, mormot2.zeos.lpk this one should require mormot2.common.lpk and appropriate zeos packages (zdbc, zcore).
Should be another main package, something like mormot.base.lpk (or mormot.core.lpk, sounds better) this one will require mormot2.common.lpk (and mormot.cross.lpk if this one exists in mORMot2 and is mandatory for mormot.base.lpk, otherwise mormot.cross.lpk may be standalone package).
When user compile mormot.base.lpk with enabled option "NOSYNDBZEOS" (it's better to change it to USESYNDBZEOS) then, mORMot should compile fine without any relations to zeos.
When user compile mormot.base.lpk with disabled option "NOSYNDBZEOS", he also must add mormot2.zeos.lpk dependency (mormot2.zeos.lpk will automatically require appropriate zeos packages, and Lazarus will try to find it).
Would be good to add mormot2.synode.lpk as well (that will require mormot2.common.lpk).

And last, but not least.
Every package should be properly versioned (with version data from SynopseCommit.inc).
Zeos team may also put package build number from commit code. SVN generates numerical codes. For example, latest is 7366, so, full package version may be 8.0.7366.

---
Later, when Lazarus 2.2 will be released, for zeos package dependencies, you can specify min and max versions that should work with mORMot2 (for example >= 8.0.xxxx).

---
By the way, conditional defines in zeos.inc allows to turn off some drivers and doing so, reduces resulting exe file (package must be recompiled).
Such switches are good and should present in package "custom options defines" as well. So, package will be more user friendly for tuning.

About multiple versions of package. I created ticket here 38587.
It turns out that this issue is a bug, and may be fixed in Lazarus 2.2 (or with minor update later).

And there is a workaround available.

Lazarus package system is not as good as NPM, for sure.

I found strange behaviour, that looks like a lazarus bug.
We can put our dependencies in project subfolder:

dependencies
dependencies\readme.md
dependencies\mormot

In readme file we can store all deps details, like path to github repo, revision (commit ID), etc.

Now if I open mormot_base.lpk from this subfolder and click "use" - "add to project", then package appears in project inspector as dependency.
lpi file indeed does not contain any information about place where package lives:

      <Item1>
        <PackageName Value="mormot_base"/>
      </Item1>

But, from project inspector, we can right click on mormot_base, select option "store file name as default for this dependency".
Save changes. now, lpi file contain proper relative path:

      <Item1>
        <PackageName Value="mormot_base"/>
        <DefaultFilename Value="..\dependencies\mormot\Packages\mormot_base.lpk"/>
      </Item1>

But for some reason, this path will not be used as default.
So if we have another package and repeat all steps, mormot_base package will be used from last opened path.
This is really looks like a bug or wrong behavior.

I've checked second way.
Created global dependencies folder, for multiple versions of each one:
lazarus-packages
lazarus-packages\mormot\master\            // <- only this one connected to git repo
lazarus-packages\mormot\1.18.6247\
lazarus-packages\mormot\1.18.6248\

Copied src files to proper folders and opened lpk from each one, configured lpk version to match SynopseCommit.inc.
Each time when we open lpk package, lazarus will remember package name + version + path (see menu - package - package links).

Removed dependencies from project and re-added it from from project inspector - right click on dependencies, find mormot_base and specify "minimum" and "maximum" version.
Now, each project request exact mormot_base version and lazarus know where it is (checked menu - packages - package links).
But for some stupid reason, Lazarus can't properly load requested package for second project.

I don't know how is it possible to make such strange logic.
Is there any chance that they can fix it?
https://bugs.freepascal.org/my_view_page.php

Hi.

I use zeos 8, there were some issues that recently was fixed.
With latest zeos and mormot 1.18 I don't have any package compile errors with disabled {$DEFINE USE_SYNCOMMONS} from zeos.inc.

If {$DEFINE USE_SYNCOMMONS} is enabled in zeos.inc, clean mORMot package compilation ("recompile clean") will fail.
SynDBZeos.pas(343,26) Error: Identifier not found "TZJSONComposeOptions"
---
At some point it compiled. What I've done:
1. mormot_base. Compile without any changes, to get compiled SynCommons.
2. zcomponent. compile without {$DEFINE USE_SYNCOMMONS}, then with it.
3. mormot_base. add zcomponent dep and compile.
4. mormot_base. remove NOSYNDBZEOS from package options and compile twice!

Issue comes because of circular dependencies.
For example, zcomponent require SynCommons from mormot_base that require zcomponent.
With clean package installation, how it should be resolved?) Maybe I don't get something about lazarus packages.

Hi!

SynCrtSock.pas

6608 ctxt.Prepare(URL,Method,HeaderGetText(fRemoteIP),Content,ContentType,'',ClientSock.fTLS);

Why aRemoteIP is empty string here?

6608 ctxt.Prepare(URL,Method,HeaderGetText(fRemoteIP),Content,ContentType,fRemoteIP,ClientSock.fTLS);

With that change, Ctxt.RemoteIP from THttpServer.OnRequest handler will be filled.

Thanks! Exactly what i looking for

I found that with TCurlHTTP Basic Authentication does not work.
Server does not receive Authorization header.

{$IFDEF WINDOWS}
  THTTPClient = TWinHTTP;
{$ELSE IF UNIX}
  THTTPClient = TCurlHTTP;
{$ENDIF}

// ...

function TCTR.GetConnector(): THTTPClient;
begin
  Result := THTTPClient.Create(Settings.BackendUrl, Settings.ProxyServer, '', 60 {sec} * 1000, 60 {sec} * 1000, 60 {sec} * 1000, False);
  Result.AuthScheme := THttpRequestAuthentication.wraBasic;
  Result.AuthUserName := 'AuthUserName ';
  Result.AuthPassword := 'AuthPassword ';
end;

iso8601 datetime string may include timezone.
For example: 2020-08-28T15:55:56+05:00
Datetime in UTC timezone: 2020-08-28T15:55:56Z

Iso8601ToDateTime() method converts "2020-08-28T15:55:56+05:00" to 2020-08-28 15:55:56. It ignores timezone part.
Theoretically, Iso8601ToDateTime may respect timezone part and return date converted to local timezone with proper timezone offset.
If you live in France (GMT+2), then for "2020-08-28T15:55:56+05:00" correct date will be: 2020-08-28T12:55:56.
When value contain "Z" (which mean utc+0) value may be converted like now (2020-08-28T15:55:56Z = 2020-08-28 15:55:56).

Second part is DateTimeToIso8601() method.
Currently it does not allow to specify timezone for the TDateTime value.
For example, method signature may be changed to support timezones:

// - Use UTC to specify that D in UTC timezone (will add Z at the end of string). When true, TimeZoneOffset will be ignored.
// - Use TimeZoneOffset to specify timezone offset in minutes, for example for +03:30 set 210
function DateTimeToIso8601(D: TDateTime; Expanded: boolean; FirstChar: AnsiChar='T'; WithMS: boolean=false; QuotedChar: AnsiChar=#0; UTC: boolean = false; TimeZoneOffset: integer = 0): RawUTF8; overload;

And maybe also would be usefull to add GetTimezoneOffset():integer method.
Similar to javascript.

It's same as UTF8String, not simple string.

And table "Assign string literals to different string types" says that by default, we can't assign constant string directly to UTF8String (or to RawUTF8).
Instead of converting, you can add {$codepage utf8} at module begin which will tell the compiler that all constant strings in module should be interpreted as utf8.
If you would like to aplly this mode to entire project, it's possible by adding compilation flag "-FcUTF8" (project options -> custom options -> Add -FcUTF8).

I found a table that describes which assignments are allowed.
In that table, they have UTF8String, which is the same thing as RawUTF8. Both = type AnsiString(CP_UTF8).

Based on that table, direct value assignments from source code to RawUTF8 are not allowed.
{$codepage utf8} directive may help here.

PS: i use UTF-8 for file encoding.

aProxyName seems a string, that must contain proxy server address and i guess a port.
Is it possible to set proxy login and password somehow?
---
Basic authentication on proxy, probably, can be implemented via request headers.

Based on description, yes
Thanks!

So far so good)

Can't find how to send stream data using THttpServerRequest object.
For example, to send image or font file...

I use TSQLHttpServer, with SQLHttpServer.HttpServer.OnRequest event.

Thanks, will try.

Does TSQLHttpServer work on windows and linux as well?
And supports described above features, both for win and linux?

Well, this message says that new compiler even better and produce smaller code.
Second point, while fpcupdeluxe works, which is awesome, it has "specific look" and does a lot operations that make some caution feeling, especially when use it first time.
I decided to try it in my DEV machine when found, that AB recommended this tool.
You may say, fpcupdeluxe is open source, 100% safe. It downloads sources on the fly and compile it.
So, it's just some portion of caution

About difference, 2kb is nothing.
Especially if compare sizes of .net applications (with all required deps).

program test;

{$mode objfpc}
{$H+}

begin
  // don't show empty heaptrc output
  {$IF DECLARED(GlobalSkipIfNoLeaks)}
  GlobalSkipIfNoLeaks := True;
  {$ENDIF}
  WriteLn('Hello, from lazarus!');
  ReadLn;
end.

Release build, disabled debug.
Stock Lazarus 2.0.8 + FPC 3.0.4; cross to win32 = 31,0 KB (exe size)
Lazarus: "fixes2.0" + FPC "fixes3.2" (fpcupdeluxe); cross to win32 = 33,0 KB (exe size)

2 kb diff. What it could be?

Nice, now demo project pass build. 

By the way, 2020-04 lazarus-2.0.8-fpc-3.2.0_fixes-44680 not works.
I can't run empty form project due error (don't work if Application.DoubleBuffered).
If i disable it, error appear in another module. I have many problems with empty project.
Suppose that issue comes from compiler itself.

Will test another version.
---
https://synopse.info/forum/viewtopic.ph … 695#p31695
FPC: "fixes3.2" and Lazarus: "fixes2.0" works.