better with TortoiseGit for me.
>
> Oh yeah, conflict resolution is the thing nobody really gets right, but TGit
> is
> a bit less wrong.
> I've pretty much resigned myself to Ctrl-F ">>>>>"...
Have you tried meld? Works for me in combination with
y FPC's and Delphi's rounding mechanism. So if you want
normal mathematical rounding then you'll need to write your own function."
Since you state that there is an ISO standard that demands regular
rounding (not bankers rounding), and FPC has an ISO mode, I would
suggest you fil
e revision which
started failing by eg. going back a month or so and bisect from there on.
Just my 2c...
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
of a managed type does
> not seem to be initialized
> 17 lines compiled, 0.1 sec, 34672 bytes code, 1316 bytes data
IIRC that was exactly the example with which the original thread started (`Data
flow analysis (dfa) and "case ... of"`).
--
Ewald
nt(C) of
0: ;
1: ;
End;
Case ptruint(C) of
0: ;
1: ;
ptruint(D): ;
End;
End.
=== example end ===
The first case will compile, the second will not, failing with a
"Constant Expression expected". So, if you would somehow know the
instance pointers at compile time, you might get away with it ;-)
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ke precedence over the other. Judging from your other
messages, you are interested in the iso mode, so try leaving out the
-Mmacpas?
Just a suggestion, I'm no expert on the compiler.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
mAlf/Reiniero-fpcup/blob/master/bin/x86_64-linux/fpcup_linux_x64?raw=true
--no-check-certificate -O fpcup
Then chmod'ing fpcup and subsequently executing it works as expected.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
htt
pipermail/fpc-devel/2013-January/031142.html
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
sults
are obtained (and that is the /same/ platform :-) ).
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
tional seperators are to be fetched from the system,
just as keyboard layout, to make an analogy.
Note that by stating the above I in no way mean to say that this
`fetching` should be done automatically.
--
Ewald
___
fpc-devel maillist - fpc-deve
nce, use object.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
something that works for refcounting in the same way as $M does for
RTTI).
Just my 5 cents.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
n TA is allocated on the stack, whereas TB will be allocated on the
heap once you call TB.Create;
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
n concerning TObject.
It's the boilerplate of TObject that does the magic. (at least at
runtime, I don't know about compile time optimizations concerning the
`as` and `is` operators)
Also, to get a better idea of the size of a TObject in memory,
SizeOf(TVmt) will get you started?
--
On 05/26/2014 01:04 PM, Michael Schnell wrote:
> On 05/26/2014 12:52 PM, Ewald wrote:
>> A `Class Procedure/Function XXX;` has a hidden parameter that points
>> to the classtype. A `Class Procedure/Function XXX; static;` doesn't
>> have this hidden parameter.
>>
&g
dditional "static" is necessary. I was
> of the op pinion that class procedures are static, anyway.
>
> Can somebody clarify ?
>
A `Class Procedure/Function XXX;` has a hidden parameter that points to the
classtype. A `Class
On 03 Mar 2014, at 21:44, Hans-Peter Diettrich wrote:
> Ewald schrieb:
>> On 03 Mar 2014, at 12:49, Hans-Peter Diettrich wrote:
>
>>> How (which data type) does *your* parser store untyped numerical
>>> constants?
>> Roughly like this (syntax may
On Mon, 3 Mar 2014 18:02:35 +0100, Jonas Maebe
wrote:
> On 03 Mar 2014, at 17:43, Ewald wrote:
>>
>> Alright, that I did not know. Thanks for the info. I always assumed
>> there was an instruction FULD, but it isn't there apparently.
>
> Nevertheless, Hans-Pet
On 03 Mar 2014, at 12:49, Hans-Peter Diettrich wrote:
> Ewald schrieb:
>> On 03 Mar 2014, at 00:29, Hans-Peter Diettrich wrote:
>
>>>> `-1` would then be $1 , whereas $
>>>> would be $0 . It really is q
On 03 Mar 2014, at 00:29, Hans-Peter Diettrich wrote:
> Ewald schrieb:
>
>> It seems like sticking to one principle (signed integer as much as
>> possible) actually breaks another principle (bitpattern).
>
> Wirth and his Pascal language are well designed with signed
On 01 Mar 2014, at 18:17, Jonas Maebe wrote:
>
> On 01 Mar 2014, at 01:19, Ewald wrote:
>>
>> That is perfectly true. But shouldn't the most basic behaviour of a language
>> be at the very least intuitive?
>
> It should be well-defined and consistent.
bytes long whereas Extended is 10 bytes long on this machine.
Then again it doesn't matter here. Replace `Extended` in the entire thread with
`Double` and you still get the same bahaviour.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepa
On 28 Feb 2014, at 23:43, Jonas Maebe wrote:
>
> On 28 Feb 2014, at 21:07, Ewald wrote:
>
>>
>> On 28 Feb 2014, at 20:39, Jonas Maebe wrote:
>>
>>> All hexadecimal constants are (conceptually) parsed as int64, so this is by
>>> design. int6
On 28 Feb 2014, at 20:39, Jonas Maebe wrote:
> On 28 Feb 2014, at 20:21, Ewald wrote:
>
>> Since I was curious as to the intended-ness of this behaviour I wrote the
>> second set of tests which show me that this is not true for longwords: both
>> 3 & 4 give the
&
4 give the same result. This lead me to the conclusion that this is a bug.
Shall I file it?
Some important note, I think: the first sizeof's of the example return 10, 8, 4
on this machine.
--
Ewald
___
fpc-devel maillist -
On 17 Feb 2014, at 10:34, Mattias Gaertner wrote:
> On Mon, 17 Feb 2014 00:02:11 +0100
> Ewald wrote:
>
>> [...]
>>
>> I'm not sure if that is really what you need, but I think this is the most
>> flexible/straightforward method of `running one fpc.cfg
26651, obviously):
= fpc-26651 =
#!/bin/sh
PATH="/compilers/fpc/26651/bin":$PATH" fpc -n
@/compilers/fpc/26651/etc/fpc.cfg "$@"
= = =
I'm not sure if that is really what you need, but I think this is the most
flexible/straightfo
On 02 Feb 2014, at 00:05, Jonas Maebe wrote:
>
> On 01 Feb 2014, at 23:15, Ewald wrote:
>
>> Anyway, if I can provide anything else, just ask.
>
> FWIW, until this is fixed you can still get a working x86-64 compiler by
> building it like this:
>
> make
On 01 Feb 2014, at 23:25, Florian Klämpfl wrote:
>
> Just to be sure: your working copy is clean?
It is clean. To be shure I first removed the entire svn tree and then checked
out r26221.
--
Ewald
___
fpc-devel maillist - fpc
On 01 Feb 2014, at 23:11, Jonas Maebe wrote:
>
> On 01 Feb 2014, at 23:01, Ewald wrote:
>
>> Here you go: r26221 with the changes from r26223 compiles and runs fine.
>>
>> So it appears that r26222 is the culprit.
>
> The code changed in that revision only ge
On 01 Feb 2014, at 22:47, Sven Barth wrote:
> On 01.02.2014 22:37, Ewald wrote:
>>>
>>>> It indeed looks unproblematic. That is basically the reason I ask.
>>>
>>> The only recent problem I know of with darwin/x86-64 was introduced in
>>> r
26519
> and was fixed in 26618.
Hmmm. Then the possibilities are:
- Something wrong with certain utilities? (like ar, ?)
- Wrong starting compiler? (although unlikely, since the makefile would
complain. I use 2.6.2)
--
Ewald
On 01 Feb 2014, at 22:18, Florian Klämpfl wrote:
> Am 01.02.2014 21:55, schrieb Ewald:
>> [snip]
>> This only happens for revisions >= 26223 (revisions 26220 -> 26222 don't
>> compile).
>
> Do you really mean 26223? It looks quiet unproblematic?
That is
to
make? Some way to track the issue down to something concrete?
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
for exception handling
etc is not yet initialized.
I suggest that you have a look at
http://wiki.freepascal.org/Multithreaded_Application_Tutorial#External_threads
Hope it helps...
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
h
Once upon a time, Marco van de Voort said:
> In our previous episode, Ewald said:
>> Apparently the StrToInt function interprets strings starting with an `x`
>> as hexadecimal numbers? This behaviour seems rather strange to me
>> (strings starting with 0x would be a bit mor
Once upon a time, Sven Barth said:
> On 21.02.2013 21:01, Ewald wrote:
>>
>> Apparently the StrToInt function interprets strings starting with an `x`
>> as hexadecimal numbers? This behaviour seems rather strange to me
>> (strings starting with 0x would be a bit mo
A- File a bug concerning incomplete documentation?
B- File a bug concerning incorrect behaviour of StrToInt()?
C- Do nothing and live with it.
D- ?
Additional information
Compiler Version: 2.6.0
--
Ewald
___
fpc-devel maillist -
Once upon a time, on 02/08/2013 04:02 PM to be precise, Jonas Maebe said:
>
> On 07 Feb 2013, at 16:52, Ewald wrote:
>
>> Altough I still
>> don't see how you can make these calls atomic then (without the
>> barrier)?
>
> On x86, it is impossible to perform
ory barrier.`). Altough I still
don't see how you can make these calls atomic then (without the
barrier)? I guess I'll have to take a peek at the source code for these
calls on different platforms/architectures...
--
Ewald
___
Once upon a time, on 02/07/2013 01:46 PM to be precise, Jonas Maebe said:
>
> On 07 Feb 2013, at 13:39, Ewald wrote:
>
>> Well, I always thought that the InterLoackedCompareExchange boiles down
>> to [**]
>> .Lock CMPXCHG
>>
>> Or something quite like that.
Once upon a time, on 02/07/2013 11:57 AM to be precise, Jonas Maebe said:
>
> On 06 Feb 2013, at 23:16, Ewald wrote:
>
>> Concerning the locking mechanism, you can uses mutex(en/es/ii) or you
>> can do this by a busy waiting loop with an integer (of course there are
>&g
code - saving
> me some time in developing, unit testing and debugging my own Object
> Pascal based semaphore.
>
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
it come from" was what I was wondering
about, but as you and Marco say, I shouldn't worry too much about it.
And, since the program works flawlessly, it would be useless to go out
on a witchhunt chasing errors which most probably aren't errors at all.
Anyway, thanks for the explan
such cases it is impossible to tell what of these cases happened from
> the result of somelibccall and errno.
I understand, so there probably is no issue in preceding code then,
which means that I can hereby cross out this issue on my todo-list :-)
Thanks for the help!
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 30 Jan 2013, at 21:52, Marco van de Voort wrote:
> In our previous episode, Ewald said:
>> fpgetcerrno from initc gives me the correct results as well; and by
>> looking at the code I see it implements it by using `__errno_location`
>> under linux, so no surprise
Once upon a time, on 01/30/2013 08:17 PM to be precise, Marco van de
Voort said:
> In our previous episode, Ewald said:
>> I was just writing a little mmapped (that's two `m`'s -- no typo ;-) )
>> file stream and thought to do it properly just in case I might fork().
>
the expected results (Out of memory, Success, ...).
So, did I discover a bug or do I miss something?
Just for the record: `daBuffer` is just mmapped in the line preceding
this one, there is no error there, it contains the right data,
`Filesize` is obtained through stat(),
in the 16-bit integer. Fixed. Same goes for our strings: if
you know one is UTF-8 and you want to convert it to UTF-16 it can be
done without error, but without this extra knowledge it can't give you
decisive results.
Just a few points I think bear some potential to contemplate o
as there is no ambiguity with this interpretation.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
by a character that matches $BE in the lookuptable of the
encoding of the terminal. Look at it this way: the byte sequence ($C7,
$BE) has got no meaning to the compiler whatsoever, it is a byte
sequence. That's what matters to the compiler, what is in this sequence
is
for.
For giving the program(mer) an idea? As a default value for use in
configfiles (e.g. `-1 cores` = autodetect)?
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Once upon a time, on 12/28/2012 08:27 PM to be precise, Ludo Brands said:
> On 28/12/2012 20:01, Ewald wrote:
>> Well, it is as you say, the `max cores per packge` just doesn't make any
>> sense at all. How can a processor hav e a maximum of one core per
>> physical pa
Once upon a time, on 12/28/2012 05:59 PM to be precise, Marco van de
Voort said:
> In our previous episode, Ewald said:
>>> cores' (no hyperthreading), and 0.5 if 'siblings' = 2 x 'cpu cores'
>>> (hyperthreading enabled).
>> Yeah, that could wo
Once upon a time, on 12/28/2012 04:46 PM to be precise, patspiper said:
> Try lscpu -p
At first sights that would be a worthy alternative to /proc/cpuinfo
indeed. Thanks for the hint.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.
Once upon a time, on 12/28/2012 04:25 PM to be precise, Ludo Brands said:
> On 28/12/2012 15:46, Ewald wrote:
>> Hmmm, that's weird. The results of the Xeon are what I was expecting.
>>
>> Quite frankly I don't know how to fix it. Maybe getting the maximum
>>
just break your application.
> True. A better bet would be to look for the code that produces the
> cpuinfo, and use that code directly.
Agreed.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Once upon a time, on 12/28/2012 06:46 AM to be precise,
microc...@zoho.com said:
> On Thu, Dec 27, 2012 at 07:01:08PM +, Mark Morgan Lloyd wrote:
>> Ewald wrote:
>>
>>> Now, for the implementation of ProcessorCount I've got code here that
>>> reads the
Once upon a time, on 12/28/2012 11:01 AM to be precise, patspiper said:
> On 27/12/12 22:38, Ewald wrote:
>> Hmmm, that;s indeed quite some different output you've got there.
>> Mine looks like this:
>>
>> processor : 0
>> vendor_id : G
Once upon a time, on 12/28/2012 09:29 AM to be precise, Mark Morgan
Lloyd said:
> Ludo Brands wrote:
>> On 27/12/2012 23:06, Ewald wrote:
>>> Oh, and the important part: The function has been tested on a Core 2
>>> Duo
>>> and an Intel i7, and works corre
t; stepping: 2
> cpu MHz: 1599.570
> cache size: 512 KB
> physical id: 0
> siblings: 2
> core id: 0
> cpu cores: 1
>
>
>
> AMD Athlon X2 5600+ reports #CPU cores: 2. /proc/cpuinfo reports 2
> processors and 2 cores.
&g
//Return #logical CPU's
MOV $1, %eax
MOV $0, %ecx
CPUID
SHR $16, %ebx
AND $0xFF, %ebx
MOV %ebx, __RESULT
.LReturn:
End ['eax', 'ebx', 'ecx', 'edx&#
e upon a time, on 12/27/2012 08:01 PM to be precise, Mark Morgan
Lloyd said:
> Ewald wrote:
>
>> Now, for the implementation of ProcessorCount I've got code here that
>> reads the amount of processor cores from `/proc/cpuinfo` (linux only I
>> think) and some assembl
nce upon a time, on 12/27/2012 05:23 PM to be precise, Sven Barth said:
> Hello Free Pascal community!
>
> I'm pleased to announce the extension of TThread's interface to bring
> it more on par with current Delphi versions.
>
> [snip]
--
Ewald
_
re that uses this,
>> and this is an incompatible change.
> 1) The change in code can be tedious but is simple. from Attach(MyObj)
> to Attach(MyObj as IFPObserver)
To fix incompatibility wouldn't a simple operator overload do the trick?
Operator := (a: TObject): I
Once upon a time, on 11/19/2012 02:51 PM to be precise, Jonas Maebe said:
>
> On 18 Nov 2012, at 23:46, Jonas Maebe wrote:
>
>>
>> On 18 Nov 2012, at 14:24, Ewald wrote:
>>
>>> Right, I fixed this issue by adding a very simple type declaration at
>
Once upon a time, on 11/18/2012 01:23 PM to be precise, Ewald said:
> Once upon a time, on 11/18/2012 11:43 AM to be precise, Jonas Maebe said:
>> On 16 Nov 2012, at 19:42, Ewald wrote:
>>
>>> {$mode ObjFPC}, which is the same as cthreads.pp. Removal of the `@`
>>&g
Once upon a time, on 11/18/2012 11:43 AM to be precise, Jonas Maebe said:
> On 16 Nov 2012, at 19:42, Ewald wrote:
>
>> {$mode ObjFPC}, which is the same as cthreads.pp. Removal of the `@`
>> doesn't solve the problem. The thing that is weird about this is that
>> the
Once upon a time, on 11/16/2012 07:21 PM to be precise, Jonas Maebe said:
> On 16 Nov 2012, at 19:15, Ewald wrote:
>
>> Well, the compiler gives this error:
>> `Incompatible types: got
>> "> Pointer):^untyped;Register>" expected
>> "&g
ng for it? Or are you perhaps
> confusing it with sem_init, which indeed does not exist on Mac OS X?
>
No, it's definetly sem_open, the litteral error is:
`Error: Identifier not found "sem_open"`
My uses list contains the exact same units as in CThreads.pp, in the
same order, so I don't see why the symbol isn't found. Also, the entire
load of $idfdef's are also copied into my source code.
Undeffing `has_sem_open` makes the code compile.
Same goes for `SEM_FAILED`, but this is related to the very same issue I
believe.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
with the same problem?
Congratulations and thank you for reading this far ;-)
If anyone could grant me some insights on one of these points it would
be greatly appreciated.
Long days and pleasant nights to you all.
BTW: I only program unix OS'es nowadays, so don't shoot me if I missed
There were 1 errors compiling module, stopping
> Fatal: Compilation aborted
> make[4]: *** [gdbver] Error 1
> make[4]: Leaving directory
> `/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/packages/gdbint'
> make[3]: *** [fpc_smart] Error 2
> make[2]: *** [gdbint_smart] Error 2
>
Thanks, I just filed the bug: id 23165.
--
Ewald
On 10/19/12 16:11, Jonas Maebe wrote:
>> I see... On the other hand, documentation
>> (http://www.freepascal.org/docs-html/prog/progsu160.html) says that
>> MemSize() should return the total amount of memory available for
>
() should return the size
of a previous allocated memory chunk. Which is what I always thought that
MemSize() did. This functionality is however not mentioned in the
documentation on the memory manager (see the above link)...
Am I missing something here?
Thanks in advance,
Ewald
On Fri, 19 Oct
other debugging functionality), I do
not see why this extra memory is needed always since the calls in the C
library (malloc, free, realloc, calloc) do not need this kind of
information.
Am I missing something here is this a bit of left-over code?
--
Ewald
75 matches
Mail list logo
