El 28/03/2013 1:06, Ewald escribió:
Google found an old thread on lazarus mailing list about this (FPC,
gzip and stream) but without any solution, everything mentioned there
has either the limitations of TCompressionStream/TDecompressionStream
(no gzip format) or TGZFileStream (not able to work
On Thu, Mar 28, 2013 at 8:51 AM, José Mejuto joshy...@gmail.com wrote:
El 28/03/2013 1:06, Ewald escribió:
Google found an old thread on lazarus mailing list about this (FPC,
gzip and stream) but without any solution, everything mentioned there
has either the limitations of
What is causing warnings for crti.o and crtn.o as described below?
I just got the latest fpc and lazarus from svn, and after build everything
I wrote a Hello World Gtk2 test project on Ubuntu 12.04 (32 bit) with the
following messages ...
Options changed, recompiling clean with -B
Hi,
quite often you need to change a value relatively to another value.
For example:
array1[array2[i]] := array1[array2[i]] + 42;
Luckily this can be written as
array1[array2[i]] += 42;
Which is nice.
However, sometimes you do not need addition, but the minimum.
For example:
On Thu, March 28, 2013 15:30, Anthony Walter wrote:
What is causing warnings for crti.o and crtn.o as described below?
I just got the latest fpc and lazarus from svn, and after build everything
I wrote a Hello World Gtk2 test project on Ubuntu 12.04 (32 bit) with
the
following messages ...
Hmm... Haskell? Or Nimrod? Or something else? What's the benefit? How will it
affect existing code? Last but not least, will you implement it?
--
View this message in context:
https://blogs.oracle.com/ahl/entry/the_mysteries_of_init
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Warning-crti-o-and-crtn-o-not-found-tp5713867p5713871.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
In our previous episode, Anthony Walter said:
What is causing warnings for crti.o and crtn.o as described below?
The fact that they don't exist :-)
Which in turn is probably due to the fact that the system hasn't been
prepared for C development, and you are linking to C libs.
Probably you need
Benito van der Zander wrote:
Hi,
quite often you need to change a value relatively to another value.
For example:
array1[array2[i]] := array1[array2[i]] + 42;
Luckily this can be written as
array1[array2[i]] += 42;
Which is nice.
However, sometimes you do not need addition, but the
Flávio Etrusco wrote:
Members refer to each available section according to the flags.
Re-read this whole paragraph you posted and a few following you'll
realize only one file is allowed in a gzip file/blob.
I think this confusion comes from the fact that
What's the benefit?
Same benefit as += to := ... +
You do not need to rewrite/compute the left side
How will it affect existing code?
Not at all, since old code using this, would not compile
Last but not least, will you implement it?
I can try
On 03/28/2013 04:20 PM, leledumbo wrote:
Am 28.03.2013 16:23, schrieb Benito van der Zander:
Hi,
quite often you need to change a value relatively to another value.
For example:
array1[array2[i]] := array1[array2[i]] + 42;
Luckily this can be written as
array1[array2[i]] += 42;
Which is nice.
However, sometimes you do not need
On 28 Mar 2013, at 17:50, Benito van der Zander wrote:
What's the benefit?
Same benefit as += to := ... +
You do not need to rewrite/compute the left side
+= does *not* prevent re-evaluating the left side. It is internally translated
to x:=x+y and then evaluated like normal. So if x
Same benefit as += to := ... +
You do not need to rewrite/compute the left side
Save typing only then, the same mistake the C style operator support have
done.
--
View this message in context:
Once upon a time, José Mejuto said:
El 28/03/2013 1:06, Ewald escribió:
Sorry to just drop in on this quite late, but isn't gzip a
compression algorithm and not a file format as such? gzip (the
command line utility) only compresses one file and *doesn't* put this
in a multi-file container.
There was already a discussion some time ago whether we should allow
operators like or= and such as well and the result was simple: no. I
consider this the same here.
But it would be more consistent with +=
You can achieve a similar effect through type helpers in 2.7.1 though:
looks
Declare a custom function and mark it inline for efficiency. That also
allows you to document it properly, have different implementations
depending on the parameter types and so on.
that's overkill if it is only an internal datastructure
our time would be better spent trying to persuade
Once upon a time, Flávio Etrusco said:
On Thu, Mar 28, 2013 at 8:51 AM, José Mejuto joshy...@gmail.com wrote:
Hello,
Just quoting the RFC1952 about .gz format:
--- http://tools.ietf.org/html/rfc1952
2.2. File format
A gzip file consists of a series of members (compressed
Benito van der Zander wrote:
Luckily this can be written as
array1[array2[i]] += 42;
I would use Pascal (not C) and write
inc(array1[array2[i]],42);
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
I would use Pascal (not C) and write
inc(array1[array2[i]],42);
well, that won't help with min
On 03/28/2013 06:14 PM, Jürgen Hestermann wrote:
Benito van der Zander wrote:
Luckily this can be written as
array1[array2[i]] += 42;
I would use Pascal (not C) and write
Benito van der Zander wrote:
array1[array2[i]] := min(array1[array2[i]], 42);
Now, you need to repeat all the array indices.
Which is very ugly.
So there should be an alternative syntax, similar to += :
I.e.:
array1[array2[i]] min= 42;
Now *that* is ugly. It would take me quite a while to
Now *that* is ugly. It would take me quite a while to find out what
happens here.
Perhaps :min= was better?
Why making Pascal look like C instead of using C?
C also does not support this :(
And it does not have arbitrary array index ranges
In the example case I would prefer the original
Sven Barth wrote:
type
TLongIntHelper = type helper for LongInt
procedure Min(aValue: LongInt);
end;
procedure TLongIntHelper.Min(aValue: LongInt);
begin
Self := Math.Min(Self, aValue);
end;
arr[15].Min(10); // arr[15] is passed as Self to Min
I thought there was something
Am 28.03.2013 18:02 schrieb Benito van der Zander ben...@benibela.de:
There was already a discussion some time ago whether we should allow
operators like or= and such as well and the result was simple: no. I
consider this the same here.
But it would be more consistent with +=
Consistency
In our previous episode, Benito van der Zander said:
There was already a discussion some time ago whether we should allow
operators like or= and such as well and the result was simple: no. I
consider this the same here.
But it would be more consistent with +=
Good point. So to be
Good point. So to be consistent, don't turn it on :-)
NEVER turn it on for me :-)
If only I'm the core dev, I would mark the C operator feature as deprecated
and remove it in the next major version.
--
View this message in context:
Same here.
M
On Mar 28, 2013, at 6:21 PM, leledumbo wrote:
Good point. So to be consistent, don't turn it on :-)
NEVER turn it on for me :-)
If only I'm the core dev, I would mark the C operator feature as
deprecated
and remove it in the next major version.
--
View this message in
2013/3/29 Sven Barth pascaldra...@googlemail.com
There was already a discussion some time ago whether we should allow
operators like or= and such as well and the result was simple: no. I
consider this the same here.
You can achieve a similar effect through type helpers in 2.7.1 though:
As to the C-style += operator, I have one question, will it makes code
slightly faster? because if you use Inc() or Dec() there will be a function
call? or, the compiler will always try to inline Inc or Dec?
No, as been explained, it's internally translated to the equivalent non-C
style by the
29 matches
Mail list logo
