Op Sun, 12 Aug 2007, schreef ik:
> > Ok, one more: 4) I miss array slice syntax (str:= s[2..7];) from the Stony
> > Brook M2 days. So much more concise than Copy().;
>
> Let me please quote Marco and say "this is a synthetic sugar", or at
> least sort of.. it's not like there is no way (without
JK Smith at Grid-Sky wrote:
Ok, one more: 4) I miss array slice syntax (str:= s[2..7];) from the Stony
Brook M2 days. So much more concise than Copy().;
One thing I *really* love about Python. No, really!
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the exp
Vincent Snijders wrote:
I would say just replace the macros with {$I %FPCTARGETOS%} and {$I
%FPCTARGETCPU%} but how do others feel?
I think that won't work for cross compilation. It returns the
targetos where fpmake s running, not the targetos you want to
compile too.
Are you shure? I mean
On 12/08/07, ik <[EMAIL PROTECTED]> wrote:
> source conference, and when I mentioned the word "Pascal" people
> wanted to move along to a new subject... there is no problem with the
> language... only with the way it feels for some people.
I can't agree more. It is actually funny seeing peoples e
On 12 Aug 2007, at 09:51, Darius Blaszijk wrote:
If Host = i386-linux and Target = i386-win32 then {$I %FPCTARGETOS
%} = linux?
Instead of the expected {$I %FPCTARGETOS%} = win. Which is ok
because the target IS i386-win32.
Not the target for which you compile fpmake, because fpmake has to
Jonas Maebe wrote:
On 12 Aug 2007, at 09:51, Darius Blaszijk wrote:
If Host = i386-linux and Target = i386-win32 then {$I %FPCTARGETOS%}
= linux?
Instead of the expected {$I %FPCTARGETOS%} = win. Which is ok because
the target IS i386-win32.
Not the target for which you compile fpmake, beca
On 12 Aug 2007, at 08:00, JK Smith at Grid-Sky wrote:
1) Garbage collection. Anybody who's worked on apps with objects of
objects
of objects of objects will see the value in this. If CMEM is used,
can the
Boehm garbage collector be used?
I don't know if anyone has tried this, nor what the
On 12 Aug 2007, at 10:43, Darius Blaszijk wrote:
Jonas Maebe wrote:
On 12 Aug 2007, at 09:51, Darius Blaszijk wrote:
If Host = i386-linux and Target = i386-win32 then {$I %FPCTARGETOS
%} = linux?
Instead of the expected {$I %FPCTARGETOS%} = win. Which is ok
because the target IS i386-win3
I believe I found a better solution to the problem. In fprepos.pp two
function OSToString and CPUToString are defined.
So a string ./units/$(CPU_TARGET)-$(OS_TARGET)
would be represented as './units/' + CPUToString(Defaults.CPU) + '-' +
OSToString(Defaults.OS)
Darius
Jonas Maebe wrote:
On
On 8/12/07, Jonas Maebe <[EMAIL PROTECTED]> wrote:
>
> On 12 Aug 2007, at 08:00, JK Smith at Grid-Sky wrote:
>
> > 1) Garbage collection. Anybody who's worked on apps with objects of
> > objects
> > of objects of objects will see the value in this. If CMEM is used,
> > can the
> > Boehm garbage col
On 8/12/07, Krishna <[EMAIL PROTECTED]> wrote:
> On 8/12/07, Jonas Maebe <[EMAIL PROTECTED]> wrote:
> >
> > On 12 Aug 2007, at 08:00, JK Smith at Grid-Sky wrote:
> >
> > > 1) Garbage collection. Anybody who's worked on apps with objects of
> > > objects
> > > of objects of objects will see the valu
On Sun, Aug 12, 2007 at 01:00:44AM -0500, JK Smith at Grid-Sky wrote:
> Three things needed in FPC:
>
> 2) Contract programming. We have to be able to show proof of correctness in
> code to prove the business value of FPC. This will be a major theme for the
> business side of software development
I was doing some tests with fpmake and came across what appears to be an
inconsistency.
When fpmaking a program a units/cpu-os is created but the commandline
parameters for FPC are "-FE." which causes the tool and possible other
units to be placed in the directory where the program is located.
> So I don't really see the relation. Even though it may seem at first
> sight that you do not have to bother with individual objects in case
> of split heaps, in practice you do because you have to make sure that
> no pointer to any of those objects can escape beyond where you free
> the split hea
Daniel had mentioned your work in a community post. Thanks for the effort,
and I'd love to try it out. And thanks for that detailed post.
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fp
>It is supported in FPC 2.2.
Sweet!
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Hi,
I wonder how can we make Pascal and FPC more attractive to people, and
I believe in what Donal Knuth have said:
"The most important thing in the programming language is the name. A
language will not succeed without a good name. I have recently
invented a very good name and now I am looking fo
On 12 Aug 2007, at 19:30, ik wrote:
So I believe that if we will change the name, it might help. What do
you think ?
I think it will have very little effect. Just look at D: it's a lot
like C (so the C crowd isn't immediately put off by it), it has a
"non-offensive" name, it's quite powe
On 12 Aug 2007, at 19:13, JK Smith at Grid-Sky wrote:
Note that extremely unlikely that things will happen just because you
say/think they are important. In most commercial project it depends
on whether you represent a lot of money which threatens to disappear
if your requirements are not met,
Here is a suggestion:
Called it puma ! :)
Like the animal on the website.
Puma's are fast.
And that's a big adventage of Pascal/Delphi it compiles lightning fast
compared to C/C++ crap.
Bye,
Skybuck.
___
fpc-pascal maillist - fpc-pascal@list
Before assuming FPC isn't atracting users, why don't we start tracking new
users and compare it's
evolution month by month, year by year. With the help of this method, we can
figure out some ways
to market FreePascal and Lazarus.
We can start by extracting the subscription date of each user of
Hi,
Sorry if I sound a bit harsh, I'm not attacking you personally :)
On 8/12/07, Leonardo M. Ramé <[EMAIL PROTECTED]> wrote:
> Before assuming FPC isn't attracting users, why don't we start tracking new
> users and compare it's
> evolution month by month, year by year. With the help of this me
Op Sun, 12 Aug 2007, schreef Leonardo M. Ramé:
> Before assuming FPC isn't atracting users, why don't we start tracking new
> users and compare it's
> evolution month by month, year by year. With the help of this method, we can
> figure out some ways
> to market FreePascal and Lazarus.
>
>
> I joined this malling list not that long ago, however I use FPC for
> several years now, and I also used Delphi for more then 7 years... So
> how can you know who is new ?
>
Well, we can't get really accurate dates, but some aproximations based on
mailing lists
subscription could show us some
-- Dani�l Mantione <[EMAIL PROTECTED]> wrote:
> Overall, I don't think we are doing bad.
I totally agree with you.
Be a better Globetrotter. Get better travel answers from someone who knows.
Y
Well there are some things ofcourse wrong with Free Pascal:
1. First the name:
"Free"
Bussiness people don't believe in "Free".
2. Free Pascal Quality itself:
When I see simple things not working like:
Read or Readln or whatever, I run away screaming from Free Pascal ;) :)
3. It doesn't hav
Well this won't work:
1. People on free pascal mailing list does not mean they use free pascal,
they just interested in reading about it, and maybe not even that ;)
2. People downloading free pascal does not mean they use free pascal, maybe
they tried it out and decided it was not for them.
So I believe that if we will change the name, it might help.
This kind of topic had been arised a few times. Basically I agree with this
idea if it means we should change the name of the compiler, not the name of
the language itself.
We just can't change the language name, just like what Jon
Sory for top posting, I am using a phone...
1. There is nothing wrong with "Free" in the name. Many open-source apps have
that. Business people trust their wallets. And here, a lot more trust Linux and
Open apps. If you know how to present that.
2. I don't know what is wrong on your side, but my
> I was doing some tests with fpmake and came across what appears to be an
> inconsistency.
>
> When fpmaking a program a units/cpu-os is created but the commandline
> parameters for FPC are "-FE." which causes the tool and possible other
> units to be placed in the directory where the program is l
30 matches
Mail list logo
