On 05/16/11 23:47, Vlad Khorsun wrote:
>> On 16/05/2011 14:12, Vlad Khorsun wrote:
On 16/05/2011 13:33, Vlad Khorsun wrote:
> So, if code calls attach\release - this is bug, as for me, and i see
> no reasons
> to write code in this way intentionally. I consider at as very bad
>>>
On 05/17/11 08:11, Damyan Ivanov wrote:
>
> The build fails with the following error:
>
> g++ -ggdb -O3 -DNDEBUG -DLINUX -pipe -MMD -fPIC -DFB_SEND_FLAGS=MSG_NOSIGNAL
> -I.
> ./src/include/gen -I../src/include -I../src/vulcan -DNAMESPACE=Vulcan
> -pthread -
> g -O2 -DBOOT_BUILD -fno-rtti -c .
> On 05/16/11 21:00, Vlad Khorsun wrote:
>>
>> We can introduce some special mode to report such errors using
>> exceptions,
>> or write message into log, or even provide callback for debugging purposes.
>>
>> But Adriano's question was about *semantics*. So, do you agree with me
>> that
> On 05/16/11 23:47, Vlad Khorsun wrote:
>>> On 16/05/2011 14:12, Vlad Khorsun wrote:
> On 16/05/2011 13:33, Vlad Khorsun wrote:
>> So, if code calls attach\release - this is bug, as for me, and i see
>> no reasons
>> to write code in this way intentionally. I consider at as very ba
On 05/17/11 11:41, Vlad Khorsun wrote:
>> On 05/16/11 23:47, Vlad Khorsun wrote:
On 16/05/2011 14:12, Vlad Khorsun wrote:
>> On 16/05/2011 13:33, Vlad Khorsun wrote:
>>> So, if code calls attach\release - this is bug, as for me, and i see
>>> no reasons
>>> to write code in th
On Tue, May 17, 2011 at 10:27 AM, Alex Peshkoff wrote:
> On 05/17/11 08:11, Damyan Ivanov wrote:
>>
>> The build fails with the following error:
>>
>> g++ -ggdb -O3 -DNDEBUG -DLINUX -pipe -MMD -fPIC -DFB_SEND_FLAGS=MSG_NOSIGNAL
>> -I.
>> ./src/include/gen -I../src/include -I../src/vulcan -DNAMES
nbackup segfaults and leaves db locked when not enough free disk space
--
Key: CORE-3481
URL: http://tracker.firebirdsql.org/browse/CORE-3481
Project: Firebird Core
Issue Ty
nbackup ctrl-c segfaults and leaves db locked (delta file continues to grow)
Key: CORE-3482
URL: http://tracker.firebirdsql.org/browse/CORE-3482
Project: Firebird Core
On 05/17/11 12:19, marius adrian popa wrote:
> On Tue, May 17, 2011 at 10:27 AM, Alex Peshkoff wrote:
>> On 05/17/11 08:11, Damyan Ivanov wrote:
>>> The build fails with the following error:
>>>
>>> g++ -ggdb -O3 -DNDEBUG -DLINUX -pipe -MMD -fPIC
>>> -DFB_SEND_FLAGS=MSG_NOSIGNAL -I.
Sorry - I h
> What about the following - we always pass status vector to release().
I'm sorry but i against it. addRef\release is and well known pair and its
usage also well known. I see no good reason to change it. More, if we
need to change it, then we use it in a wrong way.
> It's not a problem techni
On 17/05/2011 08:27, Vlad Khorsun wrote:
>> What about the following - we always pass status vector to release().
> I'm sorry but i against it. addRef\release is and well known pair and its
> usage also well known. I see no good reason to change it. More, if we
> need to change it, then we use
>>> the following way - if refCounter> 1, no error happened (later it
>>> always means that nothing like system call failed took place). If
>>> refCounter == 1 and object has no special dtor, again no error happened.
>> If object have no explicit destructor then release must be called, no
>>
> Speaking about documentation i'd said we must document usage of every
> public
> interface and specify explicitly how instance is constructed and destroyed.
>
Well - with this adjustment I can agree with every style.
(Though must say that addRef/release pair in our interfaces is already
f
On 05/17/11 16:07, Vlad Khorsun wrote:
>> To support wrong code and solve nothing. With the cost of all this mess,
>> all this otherwise unneeded discussion, all the global/local pool mess.
> ...only emotions and offence...
>
Agreed - nothing except emotions ...
On 17/05/2011 09:13, Alex Peshkoff wrote:
> On 05/17/11 16:07, Vlad Khorsun wrote:
>>> To support wrong code and solve nothing. With the cost of all this mess,
>>> all this otherwise unneeded discussion, all the global/local pool mess.
>> ...only emotions and offence...
>>
Hey Vlad, you alre
> Hey Vlad, you already made your excellent job of misrepresent a
> technical discussion into personal one. Congratulations.
Thanks. Do you have something else to say ? From technical side, please.
...
> See, providers was committed a lot of time ago. The implementation of
> (only) *refere
On 17/05/2011 04:05, Alex Peshkoff wrote:
> In FB2.5 yValve did not need any more MT-safeness except provided by
> atomic counters and some helper locks like hanlers' map RwLock.
> Initially I've planned to keep same approach for FB3. But I did not
> review latest Adriano's changes from this POV.
>
On Tue, May 17, 2011 at 7:11 AM, Damyan Ivanov wrote:
> [Full CC for debiandevel]
>
> -=| Damyan Ivanov, Mon, May 16, 2011 at 09:12:27PM +0300 |=-
>> -=| Ondřej Surý, Mon, May 16, 2011 at 05:27:53PM +0200 |=-
>> > Hi Marius,
>> >
>> > On Mon, May 16, 2011 at 16:39, marius adrian popa wrote:
>> >
> PS: There is a paper
> (http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott
> Meyers and Andrei Alexandrescu showing even or volatile usage in base
> classes are wrong. Unfortunately it's down.
With MSVC we are safe as we use "volatile" and compiler used read\write
me
On 17-05-2011 19:58, Vlad Khorsun wrote:
>> PS: There is a paper
>> (http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott
>> Meyers and Andrei Alexandrescu showing even or volatile usage in base
>> classes are wrong. Unfortunately it's down.
>
> With MSVC we are safe as w
> On 17-05-2011 19:58, Vlad Khorsun wrote:
>>> PS: There is a paper
>>> (http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott
>>> Meyers and Andrei Alexandrescu showing even or volatile usage in base
>>> classes are wrong. Unfortunately it's down.
>>
>> With MSVC we are s
On 05/16/11 21:00, Vlad Khorsun wrote:
> We can introduce some special mode to report such errors using exceptions,
> or write message into log, or even provide callback for debugging purposes.
>
> But Adriano's question was about *semantics*. So, do you agree with me
> that
> explicit d
Hi, Marius!
> We need a new define for hurd
Do you need help in creating prefix.hurd_i386 file?
> afther we undefine LINUX that part compiles but i hit another issues
> that i found it to be in haikuos too
>
> g++ -I../src/include/gen -I../src/include -I../src/vulcan -DNAMESPACE=Vulcan
> -gg
>
On 05/17/11 19:34, Adriano dos Santos Fernandes wrote:
> On 17/05/2011 04:05, Alex Peshkoff wrote:
>> In FB2.5 yValve did not need any more MT-safeness except provided by
>> atomic counters and some helper locks like hanlers' map RwLock.
>> Initially I've planned to keep same approach for FB3. But
24 matches
Mail list logo
