mORMot Open Source

You cannot expect from trunk any stability. Only "patches/fixes" branch and "stable" releases are stable.

Probably you should add to Synopse.inc the new directive:

{$modeswitch prefixedattributes-}

the problem is related to initial support of attributes in latest FPC trunk.

AFAIK usage of ZEOS 7.3 is risky (in one of my bugreport (ZEOS bugtracker at sourceforge) some time ago I was warned that I should use 7.2). The recommended version is https://sourceforge.net/p/zeoslib/code- … .2-patches

Anyway whatever was said I was using selected 7.3 with important fixes for me ( PostgreSQL ). You can try to isolate minimal test case and use ZEOS bugtracker at sourceforge to report the problem.

the only what is possible is usage of current/latest signature to logout user ^^!

We have plan to support this in NewPascal

This was some time ago, when I was part of FPC core team and NewPascal was almost integrated with official FPC page... Now I have ban in FPC core mailing list and I don't have access to trunk anymore - there is no rational reason for my banishment... I am not able to provide any updates, bug fixes nor new features into FPC trunk. Political decision and revenge of one person in core team...

Anyway still nothing wrong with using FPC trunk instead of NewPascal - individual decision .

Probably you need latest Zeos (I am not sure here), you can download proper/newest version of Zeos here : https://github.com/newpascal-ccr/zeos

Zeos will be part of next release of NewPascal like mORMot .

Probably good idea You can do update in 2 ways :

1. http://newpascal.org/download.html / https://github.com/newpascal/newpascal/ … np-v1.0.55
2. via fpcupdelux

Rather no. InitCSV don't decode, encoded string by ToTextPairs with twJSONEscape option (there is no way to use in proper way InitCSV when twJSONEscape was used in ToTextPairs).

the reality is not perfect and usage of JSON is not always possible. Personally I like the idea of :

https://www.npmjs.com/package/xml-js

some ideas from xml-js may be used in mORMot.

Thanks, for improved/faster implementation. I think that TObjectVariant is better name . The description "lazy-loading to object properties from Variant" is perfect description of my intention.

thanks TObjProxyVariant can be optimized a lot : by caching TSQLPropInfoRTTI and by TSynDictionary for fast lookup for property names. Anyway current implementation is fast enough for me.

@ab seems that open array behave in different way than dynamic array

procedure TestMe(const Key: TArray<Byte>);

works as expected.

IMO mORMot for github should use "releases" (like fpcupdeluxe and newpascal does - https://github.com/newpascal/fpcupdeluxe/tags, https://github.com/newpascal/newpascal/releases ). 

also is possible to use different categories for releases (by tags) for example sqlite_object_files, js_libraries.

Releases - very good way to keep all binary files around git repository:

https://help.github.com/articles/creating-releases/

Generally ORM systems are known as slow solutions but mORMot is fast so... maybe new namespace FastORM for ORM related stuff? I like dotted namespaces. So for me for example FastORM.Commons would be best . Anyway most important for me is separation to packages whatever the name is.

After many months of tracking logs from production server (~ 2 millions of http calls to server with SynLZ compression's per month from around ~10 devices), probably I discovered the reason of bug. Since in production environment I have less count of Samsung Galaxy Tab (IIRC Galaxy Tab 3 which has Exynos chipset) the bug occurs less often. All detected anomalies comes only from Samsung devices. From other device like "MyPhone hammer" (which has for sure different ARM processor model) I don't have problems with compression. The most important info about "impossible bug":

http://www.mono-project.com/news/2016/0 … 64-icache/
https://www.theregister.co.uk/2016/09/1 … e_gcc_bug/

ab, did you think that above problem could have influence on SynLZ compression for ARM?

Nice trick with /json, thanks . I think that we have problem in framework. "AuthorRights" works correctly only for FPC, Delphi (in my case XE2) shows

"AuthorRights":15,

instead of

"AuthorRights": {
	"Comment": true,
	"Post": true,
	"Delete": true,
	"Administrate": true
}

ArticleView is still buggy in Delphi.

as AOG said: NewPascal is a very recent trunk without the dangers of trunk (for mORMot)

NewPascal is compatible with FPC trunk, but not vice versa (for some time).

Many things has changed. We have unexpected and positive effect of NewPascal - I've started close cooperation with FPC core team and finally many areas (critical for mORMot) are improved. Current list of differences between NewPascal and FPC: http://newpascal.org/compass.html

Very short list in section "NewPascal individual changes" may be expanded in the future. Each item in "NewPascal individual changes" should be merged with FPC trunk (sooner or later). Some time ago "NewPascal individual changes" list was much, much longer.

Please note that http://wiki.freepascal.org/User_Changes_Trunk is not yet updated (no info about newest RTTI changes and management operators - http://free-pascal-general.1045716.n5.n … 7716.html)

It's simple: we have some DEFINE's (for example "HASINTERFACERTTI" for interfaces RTTI) which are available only in trunk/NewPascal. AFAIK when you run tests and HASINTERFACERTTI is missing mORMot has nice workarounds for missing features (some pre-generated data - see TestSQL3FPCInterfaces) but this is not the same (!). Remember that not all is covered by test (for example trunk/NewPascal has improved properties behaviors, more Delphi compatible RTTI (not in binary format, I mean here functionality), RTL, syntax and much more).

Thanks but this is only thanks to mORMot (mORMot is great inspiration and motivation for my work). That would be impossible without ab, AOG and mORMot.