is applied, and it turns out
that it breaks the IDE, but c'est la vie!
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
the message in the wrong folder!
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde
I'd need to create kernel modules written in fpc, so I started by
testing the Wiki example:
http://wiki.freepascal.org/linux/kernel/module_development but I stuck
in an error message I never met before when dealing with kernel modules:
No rule to make target kernel_module_info.s needed by
Jonas Maebe ha scritto:
See the exaplanation right above the Makefile that your copied from
the wiki page:
http://wiki.freepascal.org/linux/kernel/module_development#Compilation
In order to compile the kernel module, you need an object file called
kernel_module_info.o. This file is
, because the actual available space size is (FSize shl BITSHIFT)
not decreased by one.
However FPC implementation makes inconsistent the values returned from
OpenBit with those obtained reading Size.
Do I miss some point?
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I
and fix TBits implementation, in oder to keep
portability but to provide self-consistency, and submit a patch.
Kind regards,
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
___
fpc-devel maillist
Michael Van Canneyt ha scritto:
Please submit a patch to me. I'll review and apply it.
O.K. Provided I succeed ;-) , I'll do it.
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
___
fpc-devel
and unambiguous error messages are among the advantages of Pascal
over C++. It would be a pity to leave there a misleading error message.
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
___
fpc-devel maillist
Peter Vreman ha scritto:
Please submit a bug report with example code so it will not be forgotten.
Done.
Thank you
Giuliano
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
the best choice.
If Pascal, or another decent language is available, C is *never* the
best choice. :-)
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
___
fpc-devel maillist - fpc-devel
, you're
forced to duplicate a lot of files (de_AT,de_DE,de_CH, or
fr_FR,fr_CA,fr_CH, etc.).
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
of some of the obscurity inherited by the
C language constructs.
This would also help to get rid, of the ambiguities (also inherited for
C) where a variable name sometimes means the value, sometimes means the
pointer, depending on context.
Any opinion?
--
Giuliano Colla
Whenever people agree
Micha Nelissen ha scritto:
Giuliano Colla wrote:
var
Pfoo: pointer;
foo: any valid FPC Type based Pfoo;
or
foo: based Pfoo any valid FPC type;
.
Pfoo: pointer;
PBfoo: PByte absolute Pfoo;
PIfoo: PInteger absolute Pfoo;
I don't see the difference between based and absolute
Micha Nelissen ha scritto:
Giuliano Colla wrote:
With absolute you need a) to declare an extra type (PByte, or
Declaring an extra type is one of those things that make Pascal what
it is; declaring before use.
You mean that declaring twice is smarter than declaring just once?
You need two
Micha Nelissen ha scritto:
Giuliano Colla wrote:
Micha Nelissen ha scritto:
Giuliano Colla wrote:
With absolute you need a) to declare an extra type (PByte, or
Declaring an extra type is one of those things that make Pascal
what it is; declaring before use.
You mean that declaring twice
Thaddy ha scritto:
Giuliano Colla wrote:
I've never found the C++ way (Button-Click) more telling than FPC way
(Button.Click), on the contrary I find it cumbersome, but of course
you're free to think otherwise.
Huh? Button.Click is perfectly legal in C++...
Not if Button is a pointer. C
tree they appear not to be anywhere.
Are they only to be found in svn repository, or it's just stale stuff,
not used anymore?
Many thanks,
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
___
fpc
Jonas Maebe ha scritto:
On 23 Nov 2009, at 12:49, Giuliano Colla wrote:
I think it's indeed stale code that hasn't been maintained since a long
time.
Thanks a lot,
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde
between *m_none* and *m_all*.
Could someone shed some light on this subject?
Thank in advance,
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Jonas Maebe ha scritto:
On 26 Nov 2009, at 12:44, Giuliano Colla wrote:
But I fail to grasp the difference between *m_none* and *m_all*.
These are used in tokens.pas. Tokens marked as m_all are treated as a
keyword in all syntax modes (i.e., you can never use them as identifier
without
I join Ido in wishing you all a very happy new year.
To Ido, shana tova umetukah.
Giuliano
ik ha scritto:
Hello All,
Sorry for the offtopic, but I wish you all happy new year.
I hope that in 2010 we'll see Pascal, FPC and Lazarus become more main
stream.
Have a great new year and
the
situation of fpc in respect of XCB?
It would be frustrating to start from scratch with h2pas, to discover
that someone else has already done all what's required!
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde
Il 05/03/2012 11:36, Graeme Geldenhuys ha scritto:
On 5 March 2012 11:05, Sven Barth wrote:
Wayland is not the same as X11. If one wants the CustomDrawn widgetset (or
fpGUI for that matter) to support Wayland natively and not through a X11
server that runs on top of Wayland then one needs to
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As
Il 01/05/2012 22:05, Sven Barth ha scritto:
On 01.05.2012 22:03, Sven Barth wrote:
On 01.05.2012 20:15, Giuliano Colla wrote:
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live
it, from time to time.
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Il 22/07/2012 10:39, Michael Van Canneyt ha scritto:
On Sat, 21 Jul 2012, Florian Klämpfl wrote:
Am 21.07.2012 23:06, schrieb Ivanko B:
No, just reorder the fields so that they can be properly $IFDEFed as
protected for nonLAZARUS and left (private) as is otherwise.
Why should lazarus
Il 22/07/2012 23:15, Marco van de Voort ha scritto:
In our previous episode, Florian Kl?mpfl said:
Then friend classes as C++ offers and wait for this feature were
implemented before proceeding with the optimization :)
I never saw a C++ class pretending to be somebodies friend. iirc friend
Hi fpc and Lazarus developers.
I just discovered that Lazarus 1.0.x and fpc 2.6 do not install out of
the box on widely used distributions such as RHEL 5.8, CentOs 5.8, and
Suse Enterprise 10.1.
They're the most popular enterprise versions, which should be an
important target for Lazarus and
Il 23/11/2012 00:27, Michel Catudal ha scritto:
On 11/22/2012 05:27 PM, Giuliano Colla wrote:
Hi fpc and Lazarus developers.
I just discovered that Lazarus 1.0.x and fpc 2.6 do not install out
of the box on widely used distributions such as RHEL 5.8, CentOs 5.8,
and Suse Enterprise 10.1
Il 19/03/2013 10:28, Mattias Gaertner ha scritto:
The Lazarus team is glad to announce the release of Lazarus 1.0.8.
This is a bug fix release, built with the current fpc 2.6.2. The
previous release 1.0.6 was built with 2.6.0.
Although with the last updates RHEL5.x and CentOs 5.x do claim to
Il 19/03/2013 10:28, Mattias Gaertner ha scritto:
The Lazarus team is glad to announce the release of Lazarus 1.0.8.
This is a bug fix release, built with the current fpc 2.6.2. The
previous release 1.0.6 was built with 2.6.0.
Although with the last updates RHEL5.x and CentOs 5.x do claim to
I've faced problems similar to yours in the past, and I've successfully
used a simple and quite effective scheme:
1) a list of timer events, ordered by expiration time. Each entry holds
the absolute time, and the action to take (the semaphore to signal,
where a thread is waiting, in my case).
Il 27/06/2014 13:10, Michael Schnell ha scritto:
On 06/27/2014 12:54 PM, Giuliano Colla wrote:
1) a list of timer events, ordered by expiration time.
Thanks for the pointers.
I in fact do something similar.
My TTimer class has a class variable that is a dynamic array of TTimers.
When
Il 27/06/2014 20:01, Hans-Peter Diettrich ha scritto:
Giuliano Colla schrieb:
If you're using relative times and not absolute ones, then you may
avoid the search, without need to resort, using a slightly different
scheme, i.e. entering in a sorted list the times *relatives to the
previous
Il 20/09/2014 19:20, Boian Mitov ha scritto:
Hi Chriss,
Personally I favor reference counted objects. While there are
interfaces as you pointed, and in Delphi you can even use smart
pointers now, there is still a lot of cases when you need to use
objects, and have to manually free them.
In
as with and without ref. canting ;-) . I have
done them all...
With best regards,
Boian Mitov
---
Mitov Software
www.mitov.com
---
*From:* Giuliano Colla mailto:giuliano.co...@fastwebnet.it
*Sent
Il 21/09/2014 05:51, Hans-Peter Diettrich ha scritto:
Giuliano Colla schrieb:
I might, for example, tell you that my company has been successfully
implementing since more than 30 years a class of applications for the
control of industrial processes, with hundreds of threads running
Il 23/09/2014 02:24, John Briggs ha scritto:
Sven
At the risk of starting a flame war I have been pondering this question
since these threads have started:
Why has there been so many messages on this list debating the pros and cons
of reference counting objects?
Because many of us are scared
Il 22/09/2014 23:04, Boian Mitov ha scritto:
If you are experienced in parallel processing, you should know the
answer.
This is a huge topic, and I have done number of sessions on some
aspects of it, but here will give you a small example (again this is
just a small example).
You have a data
Il 23/09/2014 18:00, Boian Mitov ha scritto:
Hi Giuliano,
I was not talking hypothetical example.
All of our products use this technology. Again, what you are telling
me is some suggestion for probable solution, but even when you do it,
you immediately add additional code and containers
Hi honourable fpc developers!
I found a strange error (both with fpc 2.6.4 and fpc 3.0.0, in Linux
environment)
The following snippet of code:
{$MACRO ON}
{$define Positiva:=False;}
{$define Negativa:=True;}
...
if HDCOUNT0 >= COUNT0 then V_PIU0 := Positiva
else V_PIU0 :=
Il 12/04/2017 19:51, Michael Van Canneyt ha scritto:
Try removing the semicolon:
{$define Positiva:=False}
{$define Negativa:=True}
Without semicolon it works!
Thanks a lot.
BTW, do you think that this holds true only for the define of boolean
values?
Il 12/04/2017 19:54, Bernd Oppolzer ha scritto:
I'm no FPC macro language wizard, but in my believe
you are replacing Positiva with False, followed by a semicolon,
and so you get the error from the compiler.
{$define Positiva:=False}
should probably work.
You are right, I was misled by some
Il 14/04/2017 22:08, Werner Pamler ha scritto:
It looks to me that something (the math template?) is missing from the
Lazarus/FPC wiki infrastructure. If this is right, is there anybody I
could contact?
Maybe I'm wrong, but I believe that you can either load the template
from the
Il 14/04/2017 17:21, Werner Pamler ha scritto:
How do I activate this template?
https://en.wikipedia.org/wiki/Wikipedia:Template_namespace
and in particular (to fetch the template text)
https://en.wikipedia.org/wiki/Wikipedia:Template_namespace#Substitution
Hope that it helps.
Giuliano
Il 12/06/2018 02:07, J. Gareth Moreton ha scritto:
Someone pointed out that if you perform "(x shl 8) shr 8", where x is
of type Word, the result is always x, even though logic dictates that
the upper 8 bits should be shifted out and hence the result actually
be equal to "x and $FF".
IMHO
Il 26/12/2017 18:43, Karoly Balogh (Charlie/SGR) ha scritto:
As far as I understand (I did not try) this was once supported, but
explicitly removed by FPC 2.4.0 from Absolute keyword dereferencing is no
longer allowed:
Il 27/12/2017 15:05, Sven Barth via fpc-devel ha scritto:
No matter the syntax that might be chosen for this it will likely be
sufficient to handle that feature by an absolutevarsym with a boolean
flag or something like that. The difference to an ordinary absolute
variable appears to be too
Attn. Sven Bart
Hi,
on jan 14 I had told you that I had to postpone further work on the
https://bugs.freepascal.org/view.php?id=33007 issue, because I was going
to be abroad for a couple af weeks.
Then I came back, I put in practice your suggestions, posted new patches
on the bugtracker,
Hi fpc developers,
I'm playing a bit with the compiler. In order to debug my changes I need
to compile some test programs.
To stay on the safe side, currently when I modify something I rebuild
everything (make all - make install) in order to provide a consistent
compilation environment.
Hi fpc developers,
here enclosed a patch to the compiler (and ppudump) to support
the BASED construct (PL/1 and PL/M style), together with a patch
to Lazarus codetools in order to be able to use it with Lazarus
IDE.
For those unfamiliar with the BASED
Il 26/12/2017 14:27, Mark Morgan Lloyd ha scritto:
What does gdb (and possibly other debuggers) make of this?
What currently gdb tells (and any other debugger would tell) is :
No symbol "Item" in current context.
Once the appropriate entries are implemented in the debugger symbol
table, it
Il 26/12/2017 18:43, Karoly Balogh (Charlie/SGR) ha scritto:
HI,
On Tue, 26 Dec 2017, Thorsten Engler wrote:
Item: BYTE BASED ItemPtr;
Ignoring any other considerations for now, I would have at least used a
logical extension derived from already supported syntax:
Item: Byte absolute
Il 26/12/2017 18:26, Sven Barth via fpc-devel ha scritto:
Am 26.12.2017 13:33 schrieb "Giuliano Colla"
<giuliano.co...@fastwebnet.it <mailto:giuliano.co...@fastwebnet.it>>:
If the idea is not rejected, then a number of refinements (which
I'm ready to implement
Il 25/02/2018 13:15, Sven Barth via fpc-devel ha scritto:
Yes, we definitely feel good about this, because we don't *want*
parameter support in FPC's macro handling.
Maybe I'm obtuse, but I fail to grasp the reason why.
Can you elaborate a bit more?
Thanks
Giuliano
Il 25/02/2018 00:07, Sven Barth ha scritto:
Am 24.02.2018 17:07 schrieb "Giuliano Colla"
mailto:giuliano.co...@fastwebnet.it>>:
Attn. Sven Bart
Hi,
on jan 14 I had told you that I had to postpone further work on
the https://bugs.freepascal.org/view.php?id=
Il 25/02/2018 18:34, Florian Klämpfl ha scritto:
http://www.gnu-pascal.de/gpc/Preprocessor.html, nobody prevents people to run a
preprocessor before
FPC gets the code.
That's a constructive suggestion.
If fpc doesn't implement an actual preprocessor, but macro expansion is
part of the
Il 25/02/2018 13:55, Florian Klämpfl ha scritto:
To limit their use.
Well, just for sake of argument, it appears to me a rather drastic approach.
You may write other similar pages on stackoverflow, telling why
Dereferencing is evil, Typecasting is evil, or why "Absolute" or the
"with"
Il 25/02/2018 21:33, Mark Morgan Lloyd ha scritto:
Easily put in
the makefile
Well I wouldn't say "Easily"!:'(
I can live without parameter macros in Pascal like I did until now,
but just for personal satisfaction I tried to get the Gnu Pascal
Il 20/02/2019 19:11, Nikolai Zhubr ha scritto:
Now it is getting even more curious. Admittedly I don't use C too much
(and C++ even less so, approximately never), maybe that is why I do
not understand your reasoning. Could you maybe give an example of such
problematic inline declaration and
Il 14/03/2019 18:32, Bart ha scritto:
That is not really the issue.
My machine is Win10 on i5 with 8GB memory.
I run Mint in aVirtualBox VM (a bit sluggish, but do-able).
I don't have a Windows installable medium with license that I can
install into a VM.
And I'm not gonna buy it, nor am I gonna
Il 07/07/2019 07:33, J. Gareth Moreton ha scritto:
In the meantime, I'm working on making
"as" and "is" work with ordinal types as
well as enumerations, although currently
some headaches occur if the right-hand
side is larger than the CPU word size
(e.g. Int64 on i386). I'll upload the
patch to
Il 04/10/23 12:19, Karl-Michael Schindler via fpc-devel ha scritto:
With the command line tools of Xcode 14 it runs through without any warning nor
error. Would a patch from this commit
Il 08/06/23 18:40, Martin Frb via fpc-devel ha scritto:
It seems that on Cocoa an exe is by default relocatable.
At least a basic test shows that dumping a stack at runtime for each
run (no new compile) gives new addresses.
Fpc 3.2.2
Is there a way to turn this off? (some flag to pass to
Il 08/06/23 20:33, Martin Frb via fpc-devel ha scritto:
Great... Yes, it is an important security feature. But a show stopper
for people who need to debug.
https://forum.lazarus.freepascal.org/index.php/topic,63571.0.html
1) Afaik, FPC still can't resolve addresses with -gl (the line info
Hi fpc developers.
On my Mac I tested the UTM virtualization, and I stumbled in that
sentence from UTM website:
UTM is and always will be completely free and open source. The Mac App
Store version is identical to the free version and there are no
features left out of the free version. The
67 matches
Mail list logo
