Re: [Firebird-devel] System Start Up

Em 09/03/2016 17:09, Jim Starkey escreveu: > If any serious thought is going to be given to internalizing SQL to > support SQL rather than GDML in MET, you might think about changing how > system tables are handled during start up with an eye to both > flexibility and simplicity. > > Here is how

[Firebird-devel] System Start Up

If any serious thought is going to be given to internalizing SQL to support SQL rather than GDML in MET, you might think about changing how system tables are handled during start up with an eye to both flexibility and simplicity. Here is how I've done system startup on post-Interbase database

Re: [Firebird-devel] Phasing out BLR

On 3/9/2016 2:02 PM, Vlad Khorsun wrote: > We don't have SQL/GDML sources for many system triggers, just the byte-code. > They > could be reverse engineered, but I'd rather throw away system triggers > at all and embed their functionality directly into the engine. >> I wrote a (not complete) tool

Re: [Firebird-devel] Phasing out BLR

On 09/03/2016 16:02, Vlad Khorsun wrote: > 09.03.2016 20:41, Adriano dos Santos Fernandes wrote: >> On 09/03/2016 14:54, Dmitry Yemanov wrote: >>> We don't have SQL/GDML sources for many system triggers, just the >>> byte-code. They >>> could be reverse engineered, but I'd rather throw away

Re: [Firebird-devel] Phasing out BLR

09.03.2016 20:41, Adriano dos Santos Fernandes wrote: > On 09/03/2016 14:54, Dmitry Yemanov wrote: >> We don't have SQL/GDML sources for many system triggers, just the byte-code. >> They >> could be reverse engineered, but I'd rather throw away system triggers >> at all and embed their

Re: [Firebird-devel] Phasing out BLR

On 09/03/2016 14:54, Dmitry Yemanov wrote: > We don't have SQL/GDML sources for many system triggers, just the byte-code. > They > could be reverse engineered, but I'd rather throw away system triggers > at all and embed their functionality directly into the engine. I wrote a (not complete)

Re: [Firebird-devel] Phasing out BLR

09.03.2016 19:34, Jim Starkey wrote: > Is there a plan to phase out BLR? Nothing specific yet. > Given that the next version of Firebird is likely to take a decade > anyway, why not start the discussion and planning now? We hope to have it released much sooner, sorry. That said, I have no

Re: [Firebird-devel] byacc bitness

09.03.2016 17:36, Jim Starkey wrote: > I haven't been following this closely, but how could anyone object to a > Visual Studio custom build step? It was designed for exactly this type > of problem. 09.03.2016 15:33, Vlad Khorsun wrote: > I have ZERO problems with current build system. PS:

Re: [Firebird-devel] byacc bitness

On 3/9/2016 11:29 AM, Dimitry Sibiryakov wrote: > 09.03.2016 17:25, Jim Starkey wrote: >> Am I missing something, or will a custom build step in Visual Studio >> handle the problem? > You're missing Vlad's disagreement. > I haven't been following this closely, but how could anyone object to a

[Firebird-devel] BLR, GPRE, and All That

Is there a plan to phase out BLR? Full support of SQL in the engine would allow MET to switch to SQL, eliminate the build dependency of GPRE (which seems to be getting long in tooth), simplify startup, and eliminate the 256 context problem. BLR was created to allow a language neutral

Re: [Firebird-devel] byacc bitness

09.03.2016 17:25, Jim Starkey wrote: > Am I missing something, or will a custom build step in Visual Studio > handle the problem? You're missing Vlad's disagreement. -- WBR, SD. -- Transform Data into

Re: [Firebird-devel] byacc bitness

On 3/9/2016 10:22 AM, Adriano dos Santos Fernandes wrote: > On 09/03/2016 12:09, Dimitry Sibiryakov wrote: >> 09.03.2016 15:54, Alex Peshkoff wrote: >>> Dmitry - I'm surprised much with that time. What 386 box are you >>> building on? :) >> AMD A4-1250, but I can't use both cores for build

Re: [Firebird-devel] byacc bitness

09.03.2016 16:22, Adriano dos Santos Fernandes wrote: > preprocess.bat does write epp->cpp files only when changed AFAIR. > > Do the same things for the other generated files. > > This will be the correct fix for the problem. No, it just an ugly workaround. Correct fix is not to do unnecessary

Re: [Firebird-devel] byacc bitness

On 09/03/2016 12:09, Dimitry Sibiryakov wrote: > 09.03.2016 15:54, Alex Peshkoff wrote: >> Dmitry - I'm surprised much with that time. What 386 box are you >> building on? :) >AMD A4-1250, but I can't use both cores for build because Windows 8 become > unstable at > 100% CPU load. > >> I

Re: [Firebird-devel] byacc bitness

09.03.2016 15:54, Alex Peshkoff wrote: > Dmitry - I'm surprised much with that time. What 386 box are you > building on? :) AMD A4-1250, but I can't use both cores for build because Windows 8 become unstable at 100% CPU load. > I have 3 or 4 years old Amd 8120 and full build of btyacc takes

[Firebird-devel] [FB-Tracker] Created: (CORE-5144) Deadlock when database is encrypted or decrypted under high parallel load

Deadlock when database is encrypted or decrypted under high parallel load - Key: CORE-5144 URL: http://tracker.firebirdsql.org/browse/CORE-5144 Project: Firebird Core

Re: [Firebird-devel] byacc bitness

Hi, You can run 'parse' step from cmake-generated solution (for every VS you'd like). Also you can build whole firebird with one click: build solution. On 9 March 2016 at 17:42, Dimitry Sibiryakov wrote: > 09.03.2016 15:33, Vlad Khorsun wrote: >> Compare it with v2.5

Re: [Firebird-devel] byacc bitness

09.03.2016 16:42, Dimitry Sibiryakov wrote: > 09.03.2016 15:33, Vlad Khorsun wrote: >> Compare it with v2.5 build system. > > 2.5 build is about two times faster. Let me not believe you >> Also, tell to yourself how much faster it could be >> if you apply patch you are talking about.

Re: [Firebird-devel] byacc bitness

09.03.2016 15:33, Vlad Khorsun wrote: > Compare it with v2.5 build system. 2.5 build is about two times faster. > Also, tell to yourself how much faster it could be > if you apply patch you are talking about. According to VS build timing, it should save me about 10 minutes on every

Re: [Firebird-devel] byacc bitness

09.03.2016 14:50, Alex Peshkoff wrote: > Dimitry, it's partial (too partial!) fix. There is one more great > candidate to be a custom build tool - gpre. When I sometimes need to > work with windows build need to manually run all that batches (instead > running make once) drives me crazy. But

Re: [Firebird-devel] byacc bitness

On 03/09/2016 04:43 PM, Dimitry Sibiryakov wrote: > 09.03.2016 14:38, Vlad Khorsun wrote: >> Waste of time - it is current thread. > If you forgot, I wasn't the man who insisted on discussing of every > change. > >> Run "parse.bat" directly from IDE and relax > So, you agree with

Re: [Firebird-devel] byacc bitness

09.03.2016 14:38, Vlad Khorsun wrote: > Waste of time - it is current thread. If you forgot, I wasn't the man who insisted on discussing of every change. >Run "parse.bat" directly from IDE and relax So, you agree with setting up "parse.bat" as a custom build tool for parse.y in

Re: [Firebird-devel] byacc bitness

09.03.2016 15:27, Dimitry Sibiryakov wrote: > 09.03.2016 14:21, Vlad Khorsun wrote: >> What exact problem do you see ? > > Waste of time in batch build. Waste of time - it is current thread. > Impossible to build parse.cpp directly from IDE. Run "parse.bat" directly from IDE

Re: [Firebird-devel] byacc bitness

09.03.2016 14:21, Vlad Khorsun wrote: > What exact problem do you see ? Waste of time in batch build. Impossible to build parse.cpp directly from IDE. -- WBR, SD. -- Transform Data into Opportunity.

Re: [Firebird-devel] byacc bitness

09.03.2016 15:12, Dimitry Sibiryakov wrote: > Hello, All. > > Do result of btyacc's work depend on its bitness? > I wonder why Windows build generate separate btyacc executable for each > platform-build > combination. Is there something that prevent the build from using single >

[Firebird-devel] byacc bitness

Hello, All. Do result of btyacc's work depend on its bitness? I wonder why Windows build generate separate btyacc executable for each platform-build combination. Is there something that prevent the build from using single "Win32 Release" btyacc?.. -- WBR, SD.

[Firebird-devel] [FB-Tracker] Created: (CORE-5143) GBAK restore failed when there is SQL function accessing table and switch -O(NE_AT_A_TIME) is used

GBAK restore failed when there is SQL function accessing table and switch -O(NE_AT_A_TIME) is used -- Key: CORE-5143 URL: