Hi,
On Fri, 4 Jan 2019, Olivier Coursière via fpc-devel wrote:
> > There seems to be something wrong with the signal setup so strace is
> > used to hide a fatal error... Also file handling doesn't really work
> > now. But even to get to this level in a few hours was nice.
> For signal handling,
Hi,
On 02/01/2019 18:42, Karoly Balogh (Charlie/SGR) wrote:
Hi,
On Wed, 2 Jan 2019, Olivier Coursière wrote:
(Which actually leads us to the question of BeOS port, I'm not sure if
there's interest to bring it up to speed again in any way.)
Only for fun or retro-computing/historical
Hi Fpc Developers',
Nobody is talking about the string content.
But when they are stored together, that is the same. You can't get one
without the other.
When core A creates a string to pass to core B, core A writes three
things: ref count 1, the string content and the incremented ref
On Fri, Jan 4, 2019 at 12:03 AM Tomas Hajny wrote:
> In any case, _if_ doing it, I would do it by adding -Fu and -Fi pointing
> to the upper (i.e. compiler) directory to the Makefile rule for building
> the fpc executable, adding a possibility to pass the version information
> from fpc to the
Hi,
On 03/01/2019 15:08, Karoly Balogh (Charlie/SGR) wrote:
Hi,
On Wed, 2 Jan 2019, Karoly Balogh (Charlie/SGR) wrote:
- port/fix to 64bit
With the already proposed changes to simplify the initialization part,
it is probably "just" a matter of :
(...)
Yup, that list sums it up. Also I'm
On Thu, January 3, 2019 23:01, Bart wrote:
> On Thu, Jan 3, 2019 at 7:06 PM Tomas Hajny wrote:
.
.
>> Obviously, it might be changed if needed. The question is if people
>> really want such a warning.
>
> Probably not, since I'm the first one to raise this ;-)
That was indeed my thought as
On Thu, Jan 3, 2019 at 7:06 PM Tomas Hajny wrote:
> By design or not, the fpc executable holds no version information as of
> now, IIRC.
OK.
> Obviously, it might be changed if needed. The question is if people really
> want such a warning.
Probably not, since I'm the first one to raise this
On Thu, January 3, 2019 18:46, Bart wrote:
> On Thu, Jan 3, 2019 at 6:36 PM Florian Klämpfl
> wrote:
>
>> The fpc executable has not to match with the real compiler executable.
>
> By design?
> I find that a bit odd.
By design or not, the fpc executable holds no version information as of
now,
On Thu, Jan 3, 2019 at 6:36 PM Florian Klämpfl wrote:
> The fpc executable has not to match with the real compiler executable.
By design?
I find that a bit odd.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 03.01.19 um 18:22 schrieb Bart:
Hi,
All of this is of course of my own doing but is it expected?
I built and installed fpc trunk, just the 32-bit version.
I have 3.0.4 32-bit, and for that release I also have the win32-win64
cross-compiler installed.
Having forgotten that I did not build
Hi,
All of this is of course of my own doing but is it expected?
I built and installed fpc trunk, just the 32-bit version.
I have 3.0.4 32-bit, and for that release I also have the win32-win64
cross-compiler installed.
Having forgotten that I did not build the win32-win64 cross-compiler
from
Hi,
On Wed, 2 Jan 2019, Karoly Balogh (Charlie/SGR) wrote:
> > - port/fix to 64bit
> >
> > With the already proposed changes to simplify the initialization part,
> > it is probably "just" a matter of :
> > (...)
>
> Yup, that list sums it up. Also I'm not sure the do_syscall code is still
> used
Hi,
03.01.2019 15:25, Benito van der Zander:
The ref count is stored in the same memory block as the string itself.
If core 2 could not see the new ref count, it could not see what is in
the string and thus not use the string for anything .
If string content modification is supposed to be
Hi,
The issue I was talking about is the fact that atomic operations do
function as global memory synchronisation operations across all cores
(at least not on all architectures). If core 1 atomatically increases
refcount to two and you "then" load the same refcount normally
(without an
14 matches
Mail list logo
