Hi list,
(Had posted this earlier on the forum)
I'm looking at some day replacing some of my own utilities written using
.net code with FPC code.
One tool extracts birthdays from a database, slaps a reminder time on it
and exports it as ical/.ics
Some searching turned up
http://sourceforge.net/
El 06/03/2013 13:47, Jonas Maebe escribió:
2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but
with this one 2.6.0, and 2.7.1 trunk does not generate it (I do not
have 2.6.2 to test):
That's because you are passing an uninitialized value to a
var-parameter. That only generates
If you execute with TProcess, it's in... err... StdErr property. Otherwise, I
have no idea. It would be dependant on how you execute...
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Get-error-information-tp5713366p5713399.html
Sent from the Free Pascal - Gene
Graeme Geldenhuys wrote:
On 2013-03-01 14:03, Ebeling wrote:
When I start a new program by clicking the button "new", the cursor
stands in the upper left corner, but its position is displayed as
"1:976".
Just to confirm, I see the exact same thing under 64-bit FreeBSD using
FPC 2.6.0
no p
In our previous episode, Darius Blaszyk said:
> What
> preprocessor do you use then, M4?
Nearly always custom. With "general" I mean anything not part or integrated
with the compiler, not necessarily a known product.
The usage is now deceased and replaced by generics for the most.
> I'm curious
In our previous episode, Mark Morgan Lloyd said:
> I meant that in the context of FPC, which works out dependencies etc. on
> the fly, one can't arbitrarily hook in an external preprocessor. I meant
> that it wasn't another stage in a makefile because FPC doesn't (can't)
> use makefiles- for rea
On 2013-03-01 14:03, Ebeling wrote:
> When I start a new program by clicking the button "new", the cursor
> stands in the upper left corner, but its position is displayed as
> "1:976".
Just to confirm, I see the exact same thing under 64-bit FreeBSD using
FPC 2.6.0
>
> When the cursor stays i
Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
Unfortunately pascal macro's are rather limited compared to C. I know I know,
you could potentially open up a can of worms, but sometimes more control is
required.
There is nothing restraining anybody using an external
On Wed, 6 Mar 2013, Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
Unfortunately pascal macro's are rather limited compared to C. I know I know,
you could potentially open up a can of worms, but sometimes more control is
required.
There is nothing restraining a
Just found this project. Seems to be abandoned but might be
interesting in the light of Marco's
reply;
http://code.google.com/p/metapascal/ [1]
Links:
--
[1]
http://code.google.com/p/metapascal/
___
fpc-pascal maillist - fpc-pascal@lists.freep
mar...@stack.nl schreef op 6 mrt '13:
> In our previous episode,
Mark Morgan Lloyd said:
>
Unfortunately pascal macro's are rather
limited compared to C. I know I know, you could potentially open up a
can of worms, but sometimes more control is required.
>>> There is
nothing restraining
In our previous episode, Mark Morgan Lloyd said:
> >> Unfortunately pascal macro's are rather limited compared to C. I know I
> >> know, you could potentially open up a can of worms, but sometimes more
> >> control is required.
> >
> > There is nothing restraining anybody using an external macro
In our previous episode, John Lee said:
> So, why can't we have a get_name() type routine, so everyone can use it,
> not just those who can write pascal macros? J
The proposed Get_name only makes sense for logging purposes. Since if you
can't resolve the gotten string back to an address, it is pre
So, why can't we have a get_name() type routine, so everyone can use it,
not just those who can write pascal macros? J
> Unfortunately pascal macro's are rather limited compared to C. I know I
> know, you could potentially open up a can of worms, but sometimes more
> control is required.
>
> There
El 06/03/2013 13:47, Jonas Maebe escribió:
2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but
with this one 2.6.0, and 2.7.1 trunk does not generate it (I do not
have 2.6.2 to test):
That's because you are passing an uninitialized value to a
var-parameter. That only generates
On 06 Mar 2013, at 13:37, José Mejuto wrote:
2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but
with this one 2.6.0, and 2.7.1 trunk does not generate it (I do not
have 2.6.2 to test):
That's because you are passing an uninitialized value to a var-
parameter. That only ge
Marco van de Voort wrote:
In our previous episode, Darius Blaszyk said:
Here's why :)
Unfortunately pascal macro's are rather limited compared to C. I know I know,
you could potentially open up a can of worms, but sometimes more control is
required.
There is nothing restraining anybody usin
El 06/03/2013 10:40, Jonas Maebe escribió:
FPC 2.6.2 does give a warning (code is from
http://bugs.freepascal.org/view.php?id=20907#c55064 ):
[...]
It could also fail in 2.6.x, just less often.
Hello,
2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but with
this one 2.6.0,
In our previous episode, Darius Blaszyk said:
> Here's why :)
>
> Unfortunately pascal macro's are rather limited compared to C. I know I know,
> you could potentially open up a can of worms, but sometimes more control is
> required.
There is nothing restraining anybody using an external macro
Am 05.03.2013 22:36, schrieb Dimitri Smits:
- Oorspronkelijk e-mail -
Van: "Florian Klämpfl" Aan: "FPC-Pascal
users discussions" Verzonden:
Maandag 4 maart 2013 21:00:10
And how does this change the fact that it is an external cg not
written in pascal?
the front-end would still
On 05 Mar 2013, at 12:34, José Mejuto wrote:
El 05/03/2013 11:23, Howard Page-Clark escribió:
The code that makes me wonder something is wrong is this one:
[...]
For me (win32, FPC 2.6.2) the output is identical (= "A") whether
or not
Result in TheA() is initialised manually or not. P
On 25 Feb 2013, at 11:10, LacaK wrote:
on documentation
http://www.freepascal.org/docs-html/prog/progap7.html#x316-331000G
there is : Classic Macintosh MAC
but in sources is used: MACOS
So may be, that documentation should be updated ?
Fixed in svn, thanks.
Jonas
_
22 matches
Mail list logo
