Re: [Firebird-devel] Pure C methods for IBatch
> I suspect you didn't understand well how easy it is. I'm all ears. Or actually eyes - I'll be glad to learn some new C#/.NET interop tricks. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Pure C methods for IBatch
On Mon, Jan 17, 2022 at 4:49 PM Jiří Činčura wrote: > > Similar thing could be done for C#. > > Again, I'm not saying it couldn't be done. > > It's just with simple export I can call it right here, right now (i.e. > https://github.com/FirebirdSQL/NETProvider/blob/master/src/FirebirdSql.Data.FirebirdClient/Client/Native/IFbClient.cs#L83-L85). > It's there, platform supports it, done. :) > > I suspect you didn't understand well how easy it is. Or maybe I didn't understand what you wanted, but... > I don't think we need to talk about it more. > Ok then. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Pure C methods for IBatch
> Similar thing could be done for C#. Again, I'm not saying it couldn't be done. It's just with simple export I can call it right here, right now (i.e. https://github.com/FirebirdSQL/NETProvider/blob/master/src/FirebirdSql.Data.FirebirdClient/Client/Native/IFbClient.cs#L83-L85). It's there, platform supports it, done. :) I don't think we need to talk about it more. Pure C export is not there and will not be added. Hence I'll have to eventually work around it and implement "C++ calling". -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Pure C methods for IBatch
On 17/01/2022 15:36, Jiří Činčura wrote: >> The "C library" is just another way to call things. >> >> It's binary compatible with the C++ interface. In fact the C++ interface >> is a wrapper around C objects to be multi compiler compatible. > > Sure, I'm not saying it isn't. > > It's just way way harder to do this type of interop from C# compared to > simply calling exported function from fbclient. Something like 11 out of 10 > people will tell you to get/create a wrapper. Which is fine if you own the > code. Not the case here. > >> I don't know how you call fbclient in the .NET code. >> >> But I remember C# can map C DLL with attributes. >> >> So I believe it's possible to map the current fbclient functions >> directly in C# code. > > That expects exports with `extern "C"`. > There is fb_get_master_interface. It's an "extern C" function. And it's the only exported function of the new API. Everything else is in function pointers of structs similar to vtable of C++ classes. For FB/Java I have created Java generator in cloop. Most of this file is auto generated: https://github.com/FirebirdSQL/fbjava/blob/master/src/fbjava-impl/src/main/java/org/firebirdsql/fbjava/impl/FbClientLibrary.java Similar thing could be done for C#. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Pure C methods for IBatch
> The "C library" is just another way to call things. > > It's binary compatible with the C++ interface. In fact the C++ interface > is a wrapper around C objects to be multi compiler compatible. Sure, I'm not saying it isn't. It's just way way harder to do this type of interop from C# compared to simply calling exported function from fbclient. Something like 11 out of 10 people will tell you to get/create a wrapper. Which is fine if you own the code. Not the case here. > I don't know how you call fbclient in the .NET code. > > But I remember C# can map C DLL with attributes. > > So I believe it's possible to map the current fbclient functions > directly in C# code. That expects exports with `extern "C"`. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ExprNode::FLAG_VALUE
On 17/01/2022 12:19, Dmitry Yemanov wrote: > > Why is it done this way? AFAIU, impureCount is known during the compile > time, so the whole impure area could be preallocated during the prepare > stage. > There are others similar patterns, see irsb_message for example. The size is know at compile time. To allocate directly, it would need a rpt structure or different impure offsets. This pattern is used with irsb_mrg_rpt. It's a bit uglier and it looks like it waste a bit (sizeof(Impure::irsb_mrg_repeat)) of memory here since it's already present one time in the struct: const size_t size = sizeof(struct Impure) + count * sizeof(Impure::irsb_mrg_repeat); Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ExprNode::FLAG_VALUE
06.01.2022 17:13, Adriano dos Santos Fernandes wrote:
See also:
https://github.com/FirebirdSQL/firebird/issues/1355
https://github.com/FirebirdSQL/firebird/commit/626ab18c426fd32d482e02093e72e57330596174
Worth testing GROUP BY , ?
Since v3 we must be safe. Aggregate stream allocates impure space for
the expressions in its own region.
Correct, although I find it weird that the impure space is allocated
dynamically rather than statically (in the request's impure area):
unsigned impureCount = m_group ? m_group->getCount() : 0;
if (!impure->groupValues && impureCount > 0)
{
impure->groupValues = FB_NEW_POOL(*tdbb->getDefaultPool())
impure_value[impureCount];
memset(impure->groupValues, 0, sizeof(impure_value) * impureCount);
}
Why is it done this way? AFAIU, impureCount is known during the compile
time, so the whole impure area could be preallocated during the prepare
stage.
I'd say the flag exists because things were different before. Aggregate
were using expressions' impure regions.
Then FLAG_VALUE may be safely removed.
Dmitry
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Remove blr_parameter3
14.01.2022 16:52, Adriano dos Santos Fernandes wrote: Our code does not generate blr_parameter3. I propose to remove this code, commenting this verb for not immediate reuse. It looks like as it tries to put in the third parameter slot the maximum string length moved to the parameter. Do anyone has some background about this? I have no clue about its purpose, so I don't mind removing it. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Pure C methods for IBatch
On 17/01/2022 11:00, Jiří Činčura wrote: >> Yes - because we can generate pure C OO API in a form I've attached here >> for illustration. > > That would work for me. :) > >> No - we never included it into distribution because currently it's not >> ready for use, some tuning will be needed. Next, you will have to use >> shared library based on .c generated file and serving as a proxy between >> tour program and fbclient. > > I was hoping to have this in fbclient directly. Now it looks like I need to > do basically the same to be able to use batching in Embedded in .NET provider. > The "C library" is just another way to call things. It's binary compatible with the C++ interface. In fact the C++ interface is a wrapper around C objects to be multi compiler compatible. I don't know how you call fbclient in the .NET code. But I remember C# can map C DLL with attributes. So I believe it's possible to map the current fbclient functions directly in C# code. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Pure C methods for IBatch
> Yes - because we can generate pure C OO API in a form I've attached here > for illustration. That would work for me. :) > No - we never included it into distribution because currently it's not > ready for use, some tuning will be needed. Next, you will have to use > shared library based on .c generated file and serving as a proxy between > tour program and fbclient. I was hoping to have this in fbclient directly. Now it looks like I need to do basically the same to be able to use batching in Embedded in .NET provider. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Pure C methods for IBatch
On 1/17/22 15:02, Jiří Činčura wrote: Hi *, I'm looking at 12.batch_isc.cpp and wondering whether there's a way to do batching using pure C methods [1]. Something like simply calling isc_dsql_prepare instead of IAttachment::prepare. I know I can handle the "this" manually, but that's PIA. :) Yes and no. Yes - because we can generate pure C OO API in a form I've attached here for illustration. No - we never included it into distribution because currently it's not ready for use, some tuning will be needed. Next, you will have to use shared library based on .c generated file and serving as a proxy between tour program and fbclient. FirebirdInterface.7z Description: application/7z-compressed Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Pure C methods for IBatch
Hi *, I'm looking at 12.batch_isc.cpp and wondering whether there's a way to do batching using pure C methods [1]. Something like simply calling isc_dsql_prepare instead of IAttachment::prepare. I know I can handle the "this" manually, but that's PIA. :) -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Are isc_sql_interprete and isc_sqlcode deprecated calls?
to be precise - after code review I do not see isc_sqlcode() to be maked as deprecated but I remember well that it was mentioned somewhere as not recommended in new development, sqlstate is preferred The Firebird 4 language reference states: |"SQLCODE| has been used for many years and should be considered as deprecated now. Support for |SQLCODE| is likely to be dropped in a future version." This probably should be reflected in the code. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Are isc_sql_interprete and isc_sqlcode deprecated calls?
On 1/17/22 13:17, Tony Whyman wrote: Aren't you confusing isc_interprete with isc_sql_interprete? definitely yes sorry isc_sql_interprete interpets the SQLCode, so it does make sense to drop it if you are getting rid of SQLCode. absolutely right to be precise - after code review I do not see isc_sqlcode() to be maked as deprecated but I remember well that it was mentioned somewhere as not recommended in new development, sqlstate is preferred Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Are isc_sql_interprete and isc_sqlcode deprecated calls?
Aren't you confusing isc_interprete with isc_sql_interprete? isc_sql_interprete interpets the SQLCode, so it does make sense to drop it if you are getting rid of SQLCode. On 17/01/2022 09:54, Alex Peshkoff via Firebird-devel wrote: On 1/17/22 12:24, Tony Whyman wrote: In the legacy Firebird API, there are three functions that support error message formatting: isc_sqlcode, isc_sql_interprete, and fb_interpret. In the OO API, fb_interpret becomes IUtil->formatStatus*. *However, I can find no OO API equivalent for the other two. Is this because they are deprecated for future use? Yes. Whole sqlcode feature is deprecated, sqlstate should be used instead. What about isc_sql_interprete that's just old, unsafe variant of fb_interpret. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Are isc_sql_interprete and isc_sqlcode deprecated calls?
On 1/17/22 12:24, Tony Whyman wrote: In the legacy Firebird API, there are three functions that support error message formatting: isc_sqlcode, isc_sql_interprete, and fb_interpret. In the OO API, fb_interpret becomes IUtil->formatStatus*. *However, I can find no OO API equivalent for the other two. Is this because they are deprecated for future use? Yes. Whole sqlcode feature is deprecated, sqlstate should be used instead. What about isc_sql_interprete that's just old, unsafe variant of fb_interpret. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Are isc_sql_interprete and isc_sqlcode deprecated calls?
In the legacy Firebird API, there are three functions that support error message formatting: isc_sqlcode, isc_sql_interprete, and fb_interpret. In the OO API, fb_interpret becomes IUtil->formatStatus*. *However, I can find no OO API equivalent for the other two. Is this because they are deprecated for future use? If not, then shouldn't they also be available via IUtil? Tony Whyman MWA Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
