You are not logged in.
Enjoy and see you in Düsseldorf in two weeks :-)
Hi Arnaud,
the Delphi compiler interprets ShortString as open array. And open arrays must not be used on inlined methods. Therefore it breaks on
procedure SidToTextShort(sid: PSid; var result: ShortString);
{$ifdef HASINLINE}inline;{$endif}
Tested on Delphi 12.1 and 12.2
Regards,
Daniel
Thank you very much :-)
Hi Arnaud,
while we understand your thoughts behind making GetRttiVarData private, we run into a serious problem with that breaking change. We have written our own optimized data mappers, which heavily rely on that function. Using GetValueVariant would be possible, but we take a bad performance hit when using GetValueVariant. Would you mind, making it public again?
Regards,
Daniel
Nope, I still sometimes get the following error:
0000000000B012CF " EXC EInvalidPointer {Message:"Invalid pointer operation"} [TRestHttpSrv 443psyprax THttp] at 7c0784 System.pas @DynArrayClear (37156)
- usually when the browser tries to prefetch a petch, while the server is just starting. I'll keep trying to localize the problem for more information, but for now, I'm at a lost as to exactly why/when that happens.
Randomly, some connections instances may be freed twice, so GPF occurred after a successful run.
I have seen that sometimes, I believe. Will check it out and watch it. Could never reproduce it in any sensible way. Let you know, if it seems better.
Thanks!
Thanks :-)
Hi arnaud,
VariantToText shall, according to doc, return false, if the variant ist empty or null false, otherwise it shall return true.
Following snippet returns false, though.
uses mormot.core.text;
var
T: UTF8String;
begin
Writeln(VariantToText(true, T));
Writeln(T);
end.
In TRttiProp.SetValue this leads to not assigning a true-boolean value to a property.
Regards,
Daniel
In commit "168a0e54" you've removed TRestServerUriContext.Create and introduced the Prepare method.
We've relied an the create being able for an early analysis intercept. The prepare would work just as fine, as long as it is virtual.
Regards,
Daniel
Hi ab,
how is that work coming along?
:-D
Hi!
I've asked that before, but in mORMot1 - now, a few years on, I'd like to repeat that question :-D
Is there already a way to grant access to registered factories to QuickJS scripts?
--Daniel
Thanks for reconsidering that change. It works perfectly.
Thanks, works!
GetValueByPath can easily handle a path such as 'Item.0,Name', where the second part is an array index.
However, when starting of an array with, 0.Name would work, if it were not for the check
if (cardinal(VType) <> DocVariantVType) or
(not IsObject) then
Changing that to
if (cardinal(VType) <> DocVariantVType) or
(not (IsObject or IsArray)) then
it works perfectly.
Regards,
Daniel
But it does work perfectly, when woDontStoreVoid is not part of the set. So, why do you write, that it is not possible? Even that part "from JSON". Have used it in other places before - without the woDontStoreVoid Attribute, never had a problem...
P.S.: I use it for places, where I cannot predetermine the type of object, that is going to be encountered. So a T*ObjArray wouldn't work, just a TCollections don't work, as all are tied to a single collection type.
When streaming an object to Json, using
ObjectToJson(C, [woDontStoreDefault,woRawBlobAsBase64,woDontStoreVoid])
I ran into a problem, when a property is of type TObjectList.
Result: (Contained is published r/w property of type TObjectList:
// [woDontStoreDefault,woRawBlobAsBase64,woDontStoreVoid]
{"One":{"Name":"G"},"ID":42}
// [woDontStoreDefault,woRawBlobAsBase64]
{"One":{"Name":"G"},"ID":42,"Contained":[{"ClassName":"TOne","Name":"W"}]}
As soon as I omit woDontStoreVoid, it'll work just fine.
However, as I am trying to go through TInterfacedObjectFakeRaw.FakeCall -> TInterfacedObjectFake.FakeCallInternalProcess -> TInterfacedObjectFake.FakeCallGetJsonFromStack -> TInterfaceMethodArgument.AddJson (mocking in tests), Icannot control those parameters...
Regards,
Daniel
P.S.: A simple test project for this: https://filetransfer.io/data-package/C20KDkoc#link
In mormot.core.json we can pass the parameter var Valid: boolean, which is not set upon returning. It should be set as Valid := ctxt.Valid; at the end of the method.
Regards,
Daniel
Sure, but I am needing and using the mormot rtti in that place and simply try to get that attribute list for special cases.
You have access to the TypeInfo() pointer as in the Value^.Info: PRttiInfo field.
Tried it again, but this gives me the TypeInfo of the property value type.For: Sample writing
Ctxt.GetType(Entry.Value.Info)
for
[MyAttribute]
property XYZ: Integer read FXYZ write FXYZ
it would return the type info for "Integer", which doesn't help. If I would
Ctxt.GetType(Entry.Prop)
, I do get back the correct Delphi Rtti object (of class TRttiInstancePropertyClassic), however, something is off, as I do not get the list of attributes attached to that property.
Strange...
Daniel
That's what I thought, but for some reason I could not get a valid return on my attributes. However, I just had a thought about that - will check tomorrow.
When I use mormot.core.rtti and retrieve the properties of a class, each of them is represented by a "TRttiCustomProp" record. Is there a way to access the original Delphi rtti context information?
Reason: I want to check attributes assigned to that specific property. Another way to retrieve them would be appreciated as well ;-)
Regards,
Daniel
Sorry, couldn't check earlier, but it works as before again. Thanks.
Thanks, will check asap.
Hi,
this change leads to an IPO in Delphi 12:
https://github.com/synopse/mORMot2/comm … e4356bc106
If I followed correctly, this leads Delphi to release the same memory twice.
I assign the text generated by GetAsText to a specific entry of a string array, and when that array is freed later on, I get the following error:
"EInvalidPointer": {
"ClassName": "EInvalidPointer",
"Address": "7f0972d0",
"Message": "Invalid pointer operation"
}
Reverting that code into the previous version, everything works fine.
Regards,
Daniel
Good morning,
just pulled the latest changes, and found a little group of compiler hints.
[dcc32 Hint] mormot.net.async.pas(4727): H2077 Value assigned to 'forced' never used
[dcc32 Hint] mormot.net.async.pas(4730): H2077 Value assigned to 'forced' never used
[dcc32 Hint] mormot.net.async.pas(4733): H2077 Value assigned to 'ignored' never used
[dcc32 Hint] mormot.net.async.pas(4736): H2077 Value assigned to 'ignored' never used
[dcc32 Hint] mormot.net.async.pas(4724): H2077 Value assigned to 'ignored' never used
[dcc32 Hint] mormot.net.async.pas(4723): H2077 Value assigned to 'forced' never used
And the hints are correct ;-)
Regards,
Daniel
Thanks, you've been quick :-)
Hi arnaud,
I have created a pull request for RFC 9239 changes to e considered.
https://github.com/synopse/mORMot2/pull/242
Two changes according to RFC 9239
"text/javascript" as mime content type for JS-files, "application/javascript" is defined as obsolete
MJS-filetype to be handled like JS-filetype
https://datatracker.ietf.org/doc/html/rfc9239
https://www.rfc-editor.org/rfc/rfc9239
Regards,
Daniel
I've checked through, there are not to many instances. I could create a pull request of the relevant places I've found, however, more may exist.
Hi,
in mormot.core.os is a method ObjArrayAdd with different params, than in mormot.core.base.
When both units are referenced, Delphi cannot find the correct version to call.
For example in mormot.core.unicode and mormot.core.rtti the compiler stops, only when prefixing them with mormot.core.base the compiler will find the correct one.
I am sure more instances would occur, when I look further.
Regards,
Daniel
PS: Current commit on github
Thanks :-)
Hi Arnaud,
it's been a while that I had a chance to update my local mORMot2 rep, as another project attacked my (not so) well laid out time table.
Anyway, one change, that grabbed my be surprise, is the use of records with methods, rather than the previous object approach. In mormot.core.json defines the TJsonSaveContext. In our project, I have created my own version of the (previously) object, and could, through a helper object, easily access the fields
W: TJsonWriter;
Options: TTextWriterWriteObjectOptions;
Info: TRttiCustom;
Prop: PRttiCustomProp;
to implement very specific sub cases. I do propose making those fields public, please :-)
Regards,
Daniel
Well deserved. Enjoy and relax and refill!
I can't reproduce that problem either, do it almost daily with "just the normal problems" of the Delphi debugger.
Just checked, definitely not and I have not used the TUriRouter either.
Regards,
Daniel
Hi,
only came once at this point, at startup. No calls to the server at this point. And sadly, I cannot reproduce it al atm.
Regards,
Daniel
Today I got the following AV:
20230209 05111254 00000000AD4F394E & EXCOS EAccessViolation (c0000005) [] at cc2926
mORMot.Net.Server.pas TUriTreeNode.RewriteUri (1729)
mormot.core.os.windows.inc GetModuleHandle (394)
mormot.core.os.windows.inc GetModuleHandle (394)
System.pas TMonitor.RemoveWaiter (20266)
System.Classes.pas ResetSyncEvent (15692)
System.pas @InitResStringImports (24792)
It happened only once with yesterdays mORMot2 sources. I cannot reproduce or give any hints as to when or why that happend. I simply started a mORMot-server and the AV happened. Restarting the server was without any problems.
I'll keep my eyes peeled, but wanted to put it out here in case anyone sees somethings similar or has any idea.
Sorry for being vague, but I can't tell more at this time :-(
Regards,
Daniel
Pointing out request in #20 again :-)
https://synopse.info/forum/viewtopic.ph … 842#p38842
It would help in many cases to have the simple declaration of
TSynAutoCreateFieldsClass = class of TSynAutoCreateFields
in mormot.core.json, thus freeing us from declaring it elsewhere :-)
Thanks,
Daniel
P.S.: lines 10566, 10582, 10725
I have the same error message, you mark value as Pointer, but SortFind expects TOrmCacheEntryValueDynArray, which value is already.
Thanks for the "silent fix" :-)
Hi,
in the current drop in mormot.core.data -> IniToObject
at line 4421 you reference rkGetIntegerPropTypes
Delphi 11 does not know this one.
Regards,
Daniel
Hi Arnaud,
in mormot.db.core, you define _ENDCLAUSE (line 2410) with different options, suche as left, right, ..., how about adding WHERE itself? Would make it easier, when we build a where clause, that could be used in different contexts.
Regards,
Daniel
It is, thanks!
Leads to a compiler error atm.
When using {$ifdef USE_WINIOCP}, in mormot.core.thread, line 3216 you call fSafe.Init, which is not defined for USE_WINIOCP.
Oh yeah! Please :-)
No one else wondering what the last error has been? How do you retrieve it, when using IRestOrm interface?
no comments?
Well, happens. Would be nice to see it someday :-)
Hi!
Is there already a way to grant access to registered factories to QuickJS scripts?
--Daniel