Am 03.11.2017 um 15:31 schrieb Michael Van Canneyt:
> In this case, you can probably simply use
> TPasTreeContainer.FinishScope
> to record the end of the method.
Great, this is easy. I have created (and attached) a patch to add a
SourceEndLinenummer for all elements.
Maybe it is useful for others
Hi,
On Mon, 6 Nov 2017, Ryan Joseph wrote:
> I actually got the problem wrong and still haven’t figured it out so
> here’s another go.
>
> I have a number which I need to encode as an RGB value each component
> being 4 bytes (12 bytes total) so I need to extract each digit as a byte
> (and then e
In our previous episode, Karoly Balogh (Charlie/SGR) said:
> >
> > On Google I found a good method to have the compiler convert a word to
> > an array of bytes using variant records such as:
>
> I'm not particularly fond of this method, because this is not endian safe.
> It won't work on bigendian
> On Nov 6, 2017, at 7:36 PM, Karoly Balogh (Charlie/SGR)
> wrote:
>
> But anyway, I guess this is not so useful for you any more. So if you can
> tell what *actually* you want to do, like convert a vec4 of GLSL float to
> Pascal, or convert a 32bit RGBA value to a GLSL vec4, maybe that would
I've noticed that line numbers are sometimes off, sometimes quite a bit when I
receive a run-time error. I had one today, it specified the correct function
that was responsible for generating the error, however the line number was way
off, it reported line 1463 but the entire function in ques
On 2017-11-06 04:04, Flávio Etrusco wrote:
AFAICS it would require quite a few enhancements (and modifications to
the user scripts) to abstract away per-machine vs per-user
declarations in InnoSetup.
I can't see why you think that. I used the unpack tool Michael
suggested, and unpacked the off
On 2017-11-06 21:49, James Richters wrote:
Does anyone know what might cause the line numbers to be incorrect?
I don't know what causes it, but I can confirm I have seen this too on
one of my systems.
Regards,
Graeme
___
fpc-pascal maillist -
2017-11-06 19:49 GMT-02:00 James Richters :
> I've noticed that line numbers are sometimes off, sometimes quite a bit when
> I receive a run-time error. I had one today, it specified the correct
> function that was responsible for generating the error, however the line
> number was way off, i
