Re: [fpc-pascal] replacement of MemAvail and MaxAvail
On 30/05/2014 11:00, mokashe.ram wrote: Thanks For Your This Prompt Reply... but in promgram these functions are already used in my applcation developed in TP7, sonow i am migration this applcation to free pascal. how can i replace using free pascal? Don't. In the larger scale of things, people started to realise in the 1970s that application programs which had handled their own memory management and possibly timesharing (e.g. APL on an IBM S/370) had to be rewritten as soon as operating systems started to provide virtual memory. The only reason this wasn't really seen on PCs was that the advent of virtual memory was accompanied by a gross change in the overall programming model, so very few people had to deal with unmodified DOS programs suddenly behaving unpredictably when run on OS/2 or Windows. So it's entirely in order to report e.g. the amount of heap currently allocated for debugging purposes, but don't assume that there's a useful fixed maximum. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Typinfo incompatibilities between FPC and Delphi
On 31.05.2014 05:53, Kenneth Cochran wrote: I'm attempting to port GExperts from Delphi to Lazaurus and noticed the definition of TPropInfo differs from Delphi's. In FPC's TPropInfo the PropType field is PTypeInfo whereas in Delphi it is PPTypeInfo. I'm not sure what is actually gained by this extra level of indirection but it exists none the less. Are there any plans to update TPropInfo to be compatible with Delphi or do I need to wrap dependent code with compiler conditionals? There are no plans as we have to stay compatible with our own old codebases as well. You'll need to use compiler conditionals. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Typinfo incompatibilities between FPC and Delphi
2014-05-31 11:48 GMT+02:00 Sven Barth pascaldra...@googlemail.com: On 31.05.2014 05:53, Kenneth Cochran wrote: I'm attempting to port GExperts from Delphi to Lazaurus and noticed the definition of TPropInfo differs from Delphi's. In FPC's TPropInfo the PropType field is PTypeInfo whereas in Delphi it is PPTypeInfo. I'm not sure what is actually gained by this extra level of indirection but it exists none the less. Are there any plans to update TPropInfo to be compatible with Delphi or do I need to wrap dependent code with compiler conditionals? There are no plans as we have to stay compatible with our own old codebases as well. You'll need to use compiler conditionals. I think it is possible to write code without $ifdef (valid for Delphi and FPC) if you use the typeinfo unit to extract the information. http://www.freepascal.org/docs-html/rtl/typinfo/ Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Typinfo incompatibilities between FPC and Delphi
On 31.05.2014 11:57, Vincent Snijders wrote: 2014-05-31 11:48 GMT+02:00 Sven Barth pascaldra...@googlemail.com mailto:pascaldra...@googlemail.com: On 31.05.2014 05 tel:31.05.2014%2005:53, Kenneth Cochran wrote: I'm attempting to port GExperts from Delphi to Lazaurus and noticed the definition of TPropInfo differs from Delphi's. In FPC's TPropInfo the PropType field is PTypeInfo whereas in Delphi it is PPTypeInfo. I'm not sure what is actually gained by this extra level of indirection but it exists none the less. Are there any plans to update TPropInfo to be compatible with Delphi or do I need to wrap dependent code with compiler conditionals? There are no plans as we have to stay compatible with our own old codebases as well. You'll need to use compiler conditionals. I think it is possible to write code without $ifdef (valid for Delphi and FPC) if you use the typeinfo unit to extract the information. http://www.freepascal.org/docs-html/rtl/typinfo/ No, that is exactly the point. Compare the declaration of TPropInfo in Delphi and FPC: http://docwiki.embarcadero.com/Libraries/XE3/en/System.TypInfo.TPropInfo http://www.freepascal.org/docs-html/rtl/typinfo/tpropinfo.html In Delphi you have PropType as PPTypeInfo while in FPC you have PTypeInfo. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Java crash when fpc library CallVoidMethod in a thread.
The question here is: where did you type it? Inside the loop in thread, after each queue()... and also just before end of thread. the next thing to go for, is probably be to try to get this `CheckSynchronize;` integrated into java in a decent manner (applicable to most use cases, that is). Good luck with that :-) Yep, but using a java-timer is not the best way to use the library. One of the great feature of uos-unit (for fpc users), is all the queue(procedure) at begin of thread, begin/end of the loop inside the thread and at end of the thread. But for the uos-library I could use a java-timer who do a fpc-checksynchronize() at x interval, but it is not perfect because it will always loose the x interval for synchronization... So, every idea is welcome. Many thanks. Fred. - Many thanks ;-) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Java-crash-when-fpc-library-CallVoidMethod-in-a-thread-tp5719098p5719459.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Java crash when fpc library CallVoidMethod in a thread.
On 31.05.2014 12:10, fredvs wrote: The question here is: where did you type it? Inside the loop in thread, after each queue()... and also just before end of thread. *That* does not help. Queue put's the method pointer you provide into a queue that needs to be read by the *main thread*. It *will* fail if you use it from within a different thread especially the one which calls Queue (much worse with Synchronize, because Synchronize will *block* until CheckSynchronize was called). the next thing to go for, is probably be to try to get this `CheckSynchronize;` integrated into java in a decent manner (applicable to most use cases, that is). Good luck with that :-) Yep, but using a java-timer is not the best way to use the library. One of the great feature of uos-unit (for fpc users), is all the queue(procedure) at begin of thread, begin/end of the loop inside the thread and at end of the thread. But for the uos-library I could use a java-timer who do a fpc-checksynchronize() at x interval, but it is not perfect because it will always loose the x interval for synchronization... There's no way around it. The only way to call CheckSynchronize is to call it from the main thread and that main thread is the one which invokes loading the library on the Java side. So the way you currently do it *is* the way. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Java crash when fpc library CallVoidMethod in a thread.
On 05/31/2014 12:38 PM, Sven Barth wrote: On 31.05.2014 12:10, fredvs wrote: The question here is: where did you type it? Inside the loop in thread, after each queue()... and also just before end of thread. *That* does not help. Queue put's the method pointer you provide into a queue that needs to be read by the *main thread*. It *will* fail if you use it from within a different thread especially the one which calls Queue (much worse with Synchronize, because Synchronize will *block* until CheckSynchronize was called). Couldn't have said it better ;-) the next thing to go for, is probably be to try to get this `CheckSynchronize;` integrated into java in a decent manner (applicable to most use cases, that is). Good luck with that :-) Yep, but using a java-timer is not the best way to use the library. One of the great feature of uos-unit (for fpc users), is all the queue(procedure) at begin of thread, begin/end of the loop inside the thread and at end of the thread. But for the uos-library I could use a java-timer who do a fpc-checksynchronize() at x interval, but it is not perfect because it will always loose the x interval for synchronization... There's no way around it. The only way to call CheckSynchronize is to call it from the main thread and that main thread is the one which invokes loading the library on the Java side. So the way you currently do it *is* the way. Indeed, but it is not `itegrated` into the main loop (if there is one?), the way I understand it is that he currently calls CheckSynchronize manually. This is of course a good way to test things, and it is the way to go if you're writing your own main loop; but I think most users don't write their own main loop (save for embedded developers, people writing GUI toolkits and the like). The ideal thing would be to find some java mechanism that allows him to `append` this checksynchronize to `the` main loop, some main-loop hook of sorts. That is IMHO the way to go for, but as my knowledge of java is rather limited, I cannot comment on the feasibility or practical details of this approach. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Typinfo incompatibilities between FPC and Delphi
In FPC's TPropInfo the PropType field is PTypeInfo whereas in Delphi it is PPTypeInfo. I'm not sure what is actually gained by this extra level of indirection but it exists none the less. By Barry Kelly in comment :) : http://stackoverflow.com/questions/3443097/what-is-the-identity-pointer-before-a-ttypeinfo-there-for all typeinfo fixups - pointers from one blob of typeinfo to another - are of type PPTypeInfo, not PTypeInfo, to handle the dynamic linking case. In the case of static linkage, there needs to be an intermediate pointer for the convention to work, and part of the typeinfo itself makes as much sense as any. That is to say, it's not there for the linker; it's there because of the convention, and the convention is there because of dynamic linking, which is done the way it is to maximize potential for page sharing. Regards, Maciej Izak (hnb) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Typinfo incompatibilities between FPC and Delphi
In our previous episode, Maciej Izak said: By Barry Kelly in comment :) : http://stackoverflow.com/questions/3443097/what-is-the-identity-pointer-before-a-ttypeinfo-there-for all typeinfo fixups - pointers from one blob of typeinfo to another - are of type PPTypeInfo, not PTypeInfo, to handle the dynamic linking case. In the case of static linkage, there needs to be an intermediate pointer for the convention to work, and part of the typeinfo itself makes as much sense as any. That is to say, it's not there for the linker; it's there because of the convention, and the convention is there because of dynamic linking, which is done the way it is to maximize potential for page sharing. Thanks, I added it to the wiki: http://wiki.freepascal.org/packages#Details ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Database Metadata proposal
Hi.
In December 2012, this[1] thread has brought some ideas about
Database metadata, in special the retrieving of Schema names.
This[2] wiki page summarizes what was discussed. Some further
conclusion after that thread?
I agree that using Information schema, wherever is supported, is
the best solution.
I propose the following types and methods:
TSqlObjectIdenfier = class
public
property SchemaName: String;
property ObjectName: String;
//Optional / Reuse TSchemaType?
property SqlObjectType: TSqlObjectType;
end;
TSqlObjectList = specialize TFPGListTSqlObjectIdenfier;
On TSQLConnection the new (virtual) methods bellow (similar to
GetDBInfo, but public) could be added:
function GetObjectNames(ObjectType: TSchemaType):
TSqlObjectIdenfier; overload;
function GetObjectNames(ObjectTypes: TSchemaTypes {A new Type
Set of TSchemaType}): TSqlObjectIdenfier; overload;
These changes would not affect Delphi compatibility, as I am
proposing to add, not replace what exists today.
Ideas, Pros, cons.. ?
Thank you,
Daniel
[1] http://lists.freepascal.org/pipermail/fpc-pascal/2012-December/035844.html
[2]
http://wiki.lazarus.freepascal.org/Database_metadata#Proposal_for_extension.2Funiformization
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
