On 03/06/2016 05:46 PM, Jiří Činčura wrote:
> Hi *,
>
> looking at this [1] commit followed by this [2] commit makes me wonder
> why not call security database just security.fdb? I know somebody might
> do in-place upgrade and the database might be incompatible, but I think
> that's least of his/he
On 03/08/2016 07:56 PM, Dmitry Yemanov wrote:
> 08.03.2016 19:50, Dimitry Sibiryakov wrote:
>
>> But you are still sure that "CREATE OR ALTER" must alter attributes that are
>> not
>> explicitly mentioned in query?..
> I believe that both CREATE and ALTER parts should deliver the same
> object sta
delete trigger during deleting (twice deleting and error no current record for
fetch operation.
---
Key: CORE-5142
URL: http://tracker.firebirdsql.org/browse/CORE-5142
Hello, All.
Can someone explain in simple words the purpose of subj?
Meaning of "Encloses a pointer to cascade parent object constness" is
somehow dim for
me: what is "parent object" and how does it differ from plain "const T*"?
--
WBR, SD.
On 09/03/2016 09:30, Dimitry Sibiryakov wrote:
>Hello, All.
>
>Can someone explain in simple words the purpose of subj?
>Meaning of "Encloses a pointer to cascade parent object constness" is
> somehow dim for
> me: what is "parent object" and how does it differ from plain "const T*"?
GBAK restore failed when there is SQL function accessing table and switch
-O(NE_AT_A_TIME) is used
--
Key: CORE-5143
URL: http://tracker.firebirdsql.org/browse/CORE-51
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.
---
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
> "Win3
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.
Acceler
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 a
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
E
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
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 that's
09.03.2016 15:43, 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.
Yep, you are the men who have nothing really useful to do and a lot of free
t
09.03.2016 14:55, Vlad Khorsun wrote:
> Yep, you are the men who have nothing really useful to do and a lot of
> free time to waste.
Yep, I have a lot of spare time while current build system 100500 times
recompile the
same files again and again. 1-mb size header included into almost eve
09.03.2016 16:03, Dimitry Sibiryakov wrote:
> 09.03.2016 14:55, Vlad Khorsun wrote:
>> Yep, you are the men who have nothing really useful to do and a lot of
>> free time to waste.
>
> Yep, I have a lot of spare time while current build system 100500 times
> recompile the
> same files ag
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
ru
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.
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 build system.
>
>2.5
On 03/09/2016 05:42 PM, 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.
>
>> Also, tell to yourself how much faster it could be
>> if you apply patch you are talking about.
> According to VS
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
Is
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
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 have
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
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 beca
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 Opportunity.
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 interface
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
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:
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
prob
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) too
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 functionali
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 system
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
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
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 I
36 matches
Mail list logo
