On Thursday 16 July 2009, Jürgen Hestermann wrote:
I am not sure having a 100 MB lazarus *roaming* profile by default
would be a good idea.
That's true (although my settings are only 130 kB but they may grow).
Therefore it would be the best of all worlds to save the Lazarus
settings to the
On Thursday 16 July 2009, Luca Olivetti wrote:
En/na Vinzent Hoefler ha escrit:
But you would lose your settings when changing the machine, because
then the settings aren't part of your profile anymore.
Well, this is happening now, since CSIDL_LOCAL_APPDATA isn't roamed.
Yes. So what's
On Thursday 16 July 2009, Jürgen Hestermann wrote:
Well, this is happening now, since CSIDL_LOCAL_APPDATA isn't
roamed.
Yes. So what's the advantage in using the Lazarus directory
instead? ;)
I wouldn't lose my settings on logoff. ;-)
Then don't. ;) Usually I just locked the machine
On Sunday 20 April 2008 19:21, Andreas Berger wrote:
About break. I would like to see an implementation of Break(x) where
x is the number of loops to break out of.
Correction: I would not like this, I would LOVE it.
Oh, another Adaism trying to creep into Pascal...? :D
But let me revisit
On Monday 10 March 2008 21:02, Skybuck Flying wrote:
Also when I set it to release, something strange happens and it only
take 7 ticks or so... while normally it takes 5 million ticks ?
It's called optimizing. Obviously it calculates the final result at
compile time already.
Vinzent.
On Friday 25 January 2008 12:30, Peter Vreman wrote:
Regarding class constants: I missed them, too, already, although
not too much. ;)
Maybe you should read the documentation. Static fields are supported
already for 10 years:
~/fpc/compiler cat p.pp
{$mode objfpc}
{$static on}
type
On Thursday 24 January 2008 20:27, Marco van de Voort wrote:
On 24 Jan 2008, at 19:45, Marco van de Voort wrote:
constants.
A constant is already in a scope, the unit.
So are constants local to a function. Being able to restrict the
scope to a certain function or group of
On Tuesday 22 January 2008 09:48, Marco van de Voort wrote:
Maybe. Keep in mind that opague is roughly comparable with
type tmyopaguetype = type pointer;
Since the interface must 100% define the interface so that it can be
used, which is a hard rule with Pascal and Modula2.
Hmm, what if
On Tuesday 22 January 2008 15:18, mm wrote:
Vinzent Hoefler a écrit :
2) If I put the tabstop typographically correct as it should be
(that means: right before the parentheses)[1],
[...]
[1] In normal text( you don't write parentheses like that ), do
you?
And what about math
On Tuesday 22 January 2008 21:36, Marco van de Voort wrote:
type tmyopaguetype = type pointer;
Since the interface must 100% define the interface so that it can
be used, which is a hard rule with Pascal and Modula2.
Hmm, what if
--- 8 ---
interface
type
On Monday 21 January 2008 11:59, Marco van de Voort wrote:
I personally would spend my time improving source beautifiers like
our own ptop (and you could make them to automatically find these
tabstops).
Waste of time. Automated tools have never worked so far.
Sure, they can turn totally
On Monday 21 January 2008 12:40, Graeme Geldenhuys wrote:
alignment as pretty as can be. But once you save, it inserts the
correct amount of spaces to keep that same alignment on file or
(preferred) inserts the minimum spaces for standard indentation
(Object Pascal uses two spaces for
On Monday 21 January 2008 13:01, Graeme Geldenhuys wrote:
On 21/01/2008, Vinzent Hoefler [EMAIL PROTECTED] wrote:
As an example where most tools just put out nonsense, consider this:
|type
| CPU_Ins = (Add, Sub, Mul, Div,
| Jnz, Jz, Jnc, Jc,
| Call, Ret
On Monday 21 January 2008 13:27, Graeme Geldenhuys wrote:
On 21/01/2008, Vinzent Hoefler [EMAIL PROTECTED] wrote:
But how would it solve
|type
| FooBar = (Foo,
| Bar);
Look at the flash demo on the website for an example of this!
Lets say gEdit (linux editor) has
On Monday 21 January 2008 13:54, Marco van de Voort wrote:
On Monday 21 January 2008 11:59, Marco van de Voort wrote:
Nor does an editor. It can only help. I also think being to focussed
on coding standards (to the point of enforcing) is counterproductive.
As an example where most tools
On Monday 21 January 2008 14:23, Graeme Geldenhuys wrote:
On 21/01/2008, Vinzent Hoefler [EMAIL PROTECTED] wrote:
Yes, that's what I figured. But that's wrong. Only legasthenic
retards[1] put spaces at the inside of parentheses.
Padding can be adjusted in the editor supports ET
On Monday 21 January 2008 14:31, Marco van de Voort wrote:
On Monday 21 January 2008 13:54, Marco van de Voort wrote:
| Push, Pop,
| ...);
Now, as you can see, the instructions are laid out tabular (a
lot of tools [yes, including elastic tabstops]
On Monday 21 January 2008 15:59, Marco van de Voort wrote:
On Monday 21 January 2008 14:31, Marco van de Voort wrote:
Oh, come on. What if you encounter an enum that does *not*
require such tabbing inside the same source file.
Well, require or not is relative to begin with.
Let
On Monday 21 January 2008 18:45, Marco van de Voort wrote:
I think it would be fantastic if Free Pascal could add child units
as a language extension (of course this would reduce portability --
although on the other hand it might make porting Ada programs
easier). It's difficult trying to
On Friday 18 January 2008 20:12, John Stoneham wrote:
[Ada package system]
However, you can also do:
with Unit_1; use Unit_1;
This imports the namespace of Unit_1 into the current file so that
now you *can* refernce foo without a qualifier. It's as if all the
identifiers in Unit_1 were
On Friday 18 January 2008 12:35, Bee wrote:
Well, the statements so far went like this sub.sub.unit stuff is
just .NET crap, we won't implement any of those. ;)
I don't like that kind of attitude either. .Net is not crap as a
whole, it does have some good features and ability.
Yeah, right.
On Friday 18 January 2008 12:16, Michael Fuchs wrote:
Vinzent Hoefler schrieb:
I think more interesting are dots in unit name for making better
namespaces.
Actually, I'm thinking child units.
You mean like in Ada? Yes, this would be great.
Are there any plans to implement
On Friday 18 January 2008 12:17, Matt Emson wrote:
Vinzent Hoefler wrote:
But even so, it still wouldn't help Bee, because he's not using it
for namespaces, he's using it as special names for version control.
This was the part I was attacking, if anyone else wondered.
No problem, I just
On Friday 18 January 2008 11:44, ik wrote:
Personally I do not want to see this feature in Pascal, because it
will just complicate things, because there is a use for dot in the
Pascal language...
Think records.
If you can have unit.identifier.record_field ad infinitum (any record
may
On Friday 18 January 2008 11:48, Michael Fuchs wrote:
Bee schrieb:
Why cant FPC use unit that has (some) dot(s) within the file name?
Can FPC support it in the next release (2.2.2)?
I think more interesting are dots in unit name for making better
namespaces.
Actually, I'm thinking child
On Friday 18 January 2008 12:01, Matt Emson wrote:
Vinzent Hoefler wrote:
On Friday 18 January 2008 11:39, Bee wrote:
I used to use this feature on Turbo Delphi Explorer. But since I
totally switch to FPC/Laz and Ubuntu, I really missed this feature
on FPC. :(
No offense, but maybe
On Friday 18 January 2008 11:16, Bee wrote:
Why cant FPC use unit that has (some) dot(s) within the file name?
Can FPC support it in the next release (2.2.2)?
Probably not. And if at all, it wouldn't accomplish what you want to do.
Sometimes I need to have some units for example:
On Friday 18 January 2008 14:06, Bee wrote:
The more features it has, the better for the users.
No. It's more like:
The nice thing about standards is that you have so many to choose from.
-- Andrew S. Tanenbaum
(And yes, that was meant ironically.)
Vinzent.
On Friday 18 January 2008 14:56, Matt Emson wrote:
I would say, remove unit replace with Namespace and all would be
fine.
And the same as before, just with a different syntax.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
On Friday 18 January 2008 13:22, Matt Emson wrote:
Vinzent Hoefler wrote:
On Friday 18 January 2008 12:35, Bee wrote:
Namespaces are too flat and simply not powerful enough to justify
the implementation and maintenance effort.
And units are better because...?
*Child* units are better
On Thursday 17 January 2008 01:27, [EMAIL PROTECTED] wrote:
The question. Is this font accessible from linux; do I have
to be root ?
Yes. Yes.
/dev/mem should be the raw memory device (where even the BIOS image
can be read from), but this device which is only accessible to root.
How do I
On Thursday 17 January 2008 11:54, Jonas Maebe wrote:
On 17 Jan 2008, at 08:02, Vinzent Hoefler wrote:
On Wednesday 16 January 2008 17:49, Roberto Padovani wrote:
Given that I don't have Delphi, suppose that company X ask me to
make a software for them. I might give them the software
On Thursday 17 January 2008 11:47, Michael Van Canneyt wrote:
On Thu, 17 Jan 2008, Vinzent Hoefler wrote:
On Thursday 17 January 2008 01:27, [EMAIL PROTECTED] wrote:
The question. Is this font accessible from linux; do I have
to be root ?
Yes. Yes.
/dev/mem should be the raw
On Wednesday 16 January 2008 17:49, Roberto Padovani wrote:
Given that I don't have Delphi, suppose that company X ask me to make
a software for them. I might give them the software, with full source
code and a GPL licence note every here and there, and ask money for
the _design_ of the
On Thursday 06 December 2007 13:00, Bee wrote:
Easy way to check:
svn up -r 9290 $(FPCDIR)/packages/paszlib/src/zstream.pp
Next 'svn up' updates zstream.pp back to HEAD revision.
Here's what I got...
[EMAIL PROTECTED]:/svn/fpc-2.2.1$ svn update -r9290
packages/paszlib/src/zstream.pp D
On Tuesday 30 October 2007 17:31, Inga Petuhhov wrote:
A copy-paste from Python Shell:
a = 1
a
1
a = a + 0.4
a
1.3999
a = a - 0.4
a
0.99989
a == 1
False
Or a bit more simple (and for some maybe even more surprising):
1.0 == 0.4 - 0.4 + 1.0
True
On Wednesday 31 October 2007 12:35, Daniël Mantione wrote:
Further, it is unknown how well the GCC backend optimizes Ada
language constructs as it is primarily designed for the C language.
Well enough. In other words, optimization is about the same - given
fairly equivalent code.
The main
On Wednesday 31 October 2007 14:19, Bee wrote:
Sure, but as Jonas pointed out it is better to use a good library
than the write a bad library yourself.
And someone would claim that the speed comes from the library (c?),
not
from pascal. :P It's a LANGUAGE shootout btw, not LIBRARY
On Friday 19 October 2007 15:10, [EMAIL PROTECTED] wrote:
I'm studing RTL Events and TEvent class under Unix. RTL Event don't
keep the state of event after an RTLEventWaitFor or
RTLEventWaitForTimeout (after this the event is reseted).
This reset after an RTLWaitFor is a rule for RTL Events?
On Friday 24 August 2007 07:55, Michael Van Canneyt wrote:
On Fri, 24 Aug 2007, Vinzent Hoefler wrote:
On Thursday 23 August 2007 19:47, Jonas Maebe wrote:
On 23 Aug 2007, at 21:29, Luca Olivetti wrote:
How are these different to the TEventObject,TSimpleEvent
classes in syncobjs
On Friday 24 August 2007 08:53, Jonas Maebe wrote:
tbasicrtlevent for Unix is still not based on condition variables,
because Windows events are persistent and condition variables are
not.
Call me stupid, but I was under the impression that this has been fixed
by inserting the IsSet member
On Thursday 23 August 2007 17:02, ik wrote:
Hi,
Is there an equivalent for Java's sleep and notify/notifyAll in FPC's
rtl ?
The SetEvent methods of RtlWaitEvent (notify) and
RTLSimpleEvent (notify all), IIRC.
Vinzent.
___
fpc-pascal maillist -
On Thursday 23 August 2007 19:47, Jonas Maebe wrote:
On 23 Aug 2007, at 21:29, Luca Olivetti wrote:
How are these different to the TEventObject,TSimpleEvent classes in
syncobjs? Just curious, since I usually do with syncobjs, and I
don't see a big difference between
On Wednesday 22 August 2007 06:30, Skybuck Flying wrote:
project1.lpr(21,5) Hint: Local variable b does not seem to be
initialized
[...]
However when looking at the source code this hint message seems
inaccurate.
B is initialized by the procedure test.
No, it's not. It says var, so
On Wednesday 15 August 2007 00:40, mm wrote:
there would not be much places where I could set {$R+} without having
to reset {$R-} almost immediately.
[EMAIL PROTECTED]:/opt/mdc/dtg/src grep \$R *.pas
mdc0lzw.pas: {$IFOPT R+} {$DEFINE OPT_R} {$R-} {$ENDIF}
mdc0lzw.pas: {$IFDEF OPT_R}
On Tuesday 14 August 2007 06:14, Daniël Mantione wrote:
Lastly, pre and post conditions are just another runtime check.
No. If you can prove that the conditions always hold, you don't even
need to compile to the program to prove its correctness.
There's a company already doing that:
On Tuesday 14 August 2007 06:49, Daniël Mantione wrote:
Op Tue, 14 Aug 2007, schreef Vinzent Hoefler:
On Tuesday 14 August 2007 06:14, Daniël Mantione wrote:
Lastly, pre and post conditions are just another runtime check.
No. If you can prove that the conditions always hold, you don't
On Tuesday 14 August 2007 21:26, Daniël Mantione wrote:
You almost never ship a binary with range checking, since a range
check crash is for a end user generally as usefull as the protection
fault that can happen when you disable range checking.
Hmm.
[EMAIL PROTECTED]:/opt/mdc/dtg/src grep
On Thursday 12 July 2007 07:30, Michael Van Canneyt wrote:
Can you, BTW, explain the reference to Knuth ? I know who Donald
Knuth is, but fail to see the link... ?
http://www.brainyquote.com/quotes/quotes/d/donaldknut181625.html
Vinzent.
___
On Wednesday 27 June 2007 07:55, Jonas Maebe wrote:
On 27 jun 2007, at 08:13, Vinzent Hoefler wrote:
There also seemed to be some issues with the reference
counting: if I passed a local AnsiString to a thread constructor as
argument and left the routine then, this seemed to confuse
On Friday 22 June 2007 06:27, Carsten Bager wrote:
In the small threads program below I force a runtime error in a
thread. How do I get access to the output from the thread when it
stops? This program does not write anything to the terminal when the
thread stops.
In case a runtime error
On Friday 22 June 2007 07:28, Michael Van Canneyt wrote:
- Don't use synchronize to fire the timer, because that limits
the use of timers to the main thread.
This one is harder, and I must confess I don't have a clue
on how to implement this in a platform independent manner...
Well,
On Wednesday 20 June 2007 06:55, Mark Wood wrote:
[iterator functions with yield()]
It strikes me that whilst it may not be the best programming form,
the same thing could be done readily with a global variable?
Not if you call such an iterator several times at once (in nested loops
for
On Tuesday 19 June 2007 11:48, memsom wrote:
'?' indeed! I am fascinated! What does yield do exactly...
presumably it returns a result from the function without closing
down that instance of the function? Amazing concept.
I suspect - given the word DOS in some of the code, it allows a DOS
On Thursday 05 April 2007 07:36, Michael Van Canneyt wrote:
On Thu, 5 Apr 2007, Bisma Jayadi wrote:
Writing device driver for windows using Delphi is almost impossible
since Delphi can't produce .sys files. Is it the same case for FPC?
Can FPC produce .sys file and write device drivers for
On Thursday 05 April 2007 08:14, Felipe Monteiro de Carvalho wrote:
On 4/5/07, Vinzent Hoefler [EMAIL PROTECTED] wrote:
And it would mean writing a C to Pascal conversion of an ever
changing kernel interface.
All interfaces change when a new version is released,
Well, I was not talking
On Friday 02 March 2007 08:19, Jonas Maebe wrote:
On 02 Mar 2007, at 09:03, m utku wrote:
Hello again :), I just forgot to ask; Delphi has an option to
generate a so called map file that contains the function
addresses matched with the function names when an executable
compiled. What
On Monday 26 February 2007 10:13, Matt Emson wrote:
I had a fairly quick glance through; I think you missed the point.
Most of your arguments point to something like VB3, not Pascal, ADA
or C. You mention the syntax of the Java class - Pacal and ADA are
both more complicated.
Well, let's do
On Monday 26 February 2007 12:07, Matt Emson wrote:
Well, let's do the standard:
Pascal:
program
Hello_World;
begin
WriteLn ('Hello world.');
end.
Class: What does program mean?
That this unit is supposed to be a program. (Still, you can leave it
out in
On Wednesday 01 November 2006 15:55, Marc PERTRON wrote:
dictionary attacks';
pwd := md5('My Secret Password' + salt);
end;
And where do you think the phrase 'My Secret Password' would be stored
other than memory?
Vinzent.
___
fpc-pascal
On Sunday 08 October 2006 12:08, Pianoman wrote:
Hello, I'd like to ask if someone has experiences with low
level disk operations in windows with FPC.
The program should be able to copy entire diskete to one single image
file and for example extract a single file from that image or
On Wednesday 20 September 2006 08:26, Пётр Косаревский wrote:
I use
{$A-}
abc= record
something: byte;
case byte of
1: (a,b: byte);
2: (c: word);
end;
{$A+} // or even a: byte; rsrvd1: array[1..3] of byte; b: word; ...
{$IF sizeof(abc)1234}
{$FATAL
On Wednesday 20 September 2006 11:25, Jonas Maebe wrote:
On 20 sep 2006, at 13:20, Пётр Косаревский wrote:
I'm vague: for the first time I hoped that when you access the
variant part, if the case variable was named, program checks it
run-time. Hoping that it was implemented this way, I
On Thursday 14 September 2006 09:20, Jerry wrote:
however. Beware of 2D arrays in C because there seems to be no
requirement in C that all of the data be allocated in contiguous
memory;
Most probably yes. This applies to all mutidimensional arrays in C. The
reason is simple, arrays and
On Wednesday 26 July 2006 10:05, Andreas Berger wrote:
Steve Williams wrote:
Michael Van Canneyt wrote:
Which is why I think that it's better to have them as local
functions, instead of having to introduce a lot of new functions.
Local functions are very pascal-ish. C doesn't have it,
On Thursday 27 July 2006 12:05, Wolfram Kläger wrote:
Vinzent wrote:
.. According to the documentation, the size of the
local variables (allocated on the stack) should not exceed 32
KiBytes for portability reasons.
Thanks a lot. And I thought, I did RTFM often enough ...
BTW, do you
On Thursday 27 July 2006 12:53, Alexandre Leclerc wrote:
Then we could very simply have:
parallel procedure ParallelBlock;
parallel function ParallelFunction; //if this can happen...
Yes. I thought of something like that, because it could quite easily
match with a parallel for construct.
On Wednesday 26 July 2006 08:17, Micha Nelissen wrote:
Vinzent Hoefler wrote:
Well, I just added some stuff there, yesterday. It's far from being
complete yet (it just covers a basic parallel construct), nor is
it really thought through yet, but well, it might be a start;
something
On Wednesday 26 July 2006 09:07, Micha Nelissen wrote:
Vinzent Hoefler wrote:
On Wednesday 26 July 2006 08:17, Micha Nelissen wrote:
Does parallel mean all the statements in the block can be executed
in parallel, or that multiple copies of the block of statements
can be started
On Wednesday 26 July 2006 09:00, Michael Van Canneyt wrote:
On Wed, 26 Jul 2006, Vinzent Hoefler wrote:
On Wednesday 26 July 2006 08:17, Micha Nelissen wrote:
Vinzent Hoefler wrote:
Well, I just added some stuff there, yesterday. It's far from
being complete yet (it just covers
On Wednesday 26 July 2006 09:25, Micha Nelissen wrote:
Vinzent Hoefler wrote:
On Wednesday 26 July 2006 09:07, Micha Nelissen wrote:
How many copies ?
Omp.Get_Num_Threads(), AFAICS.
Ah the number of threads is determined by the RTL, and any parallel
block must be written flexible, so
On Wednesday 26 July 2006 09:28, Steve Williams wrote:
Steve Williams wrote:
*begin*
SubTask(x);
*end* /{Sub}/;
*var*
arr = *array*[0 .. ] *of* Float;
*begin* / // Main program/
Sub (arr);
*end*.
Damn Thunderbird.
Well, it tried to mimic my syntax
On Wednesday 26 July 2006 09:46, Michael Van Canneyt wrote:
It seems obvious to me that a global function can be called in
parallel at any time. The compiler can perfectly detect whether a
global function writes to variables outside it's own scope, in which
case it's probably a no-no to
On Wednesday 26 July 2006 10:00, Michael Van Canneyt wrote:
On Wed, 26 Jul 2006, Vinzent Hoefler wrote:
On Wednesday 26 July 2006 09:46, Michael Van Canneyt wrote:
It seems obvious to me that a global function can be called in
parallel at any time. The compiler can perfectly detect
On Wednesday 26 July 2006 12:49, Graeme Geldenhuys wrote:
MyVariable:=MyVariable; // this is a workaround in rare cases.
Can anybody that knowns the internals of FPC confirm if this will
create extra work/code for the compiler?
It does create an assignment. At least with the fpc2.0.2
On Tuesday 25 July 2006 06:40, Micha Nelissen wrote:
Vinzent Höfler wrote:
because we assume it's non-recursive, that was the whole point. So
we should *first* check the count and then may lock/unlock the
mutex accordingly.
Note that these two actions must be atomic.
Oh, really?
This
On Tuesday 25 July 2006 07:46, Micha Nelissen wrote:
Vinzent Hoefler wrote:
On Tuesday 25 July 2006 06:40, Micha Nelissen wrote:
Vinzent Höfler wrote:
because we assume it's non-recursive, that was the whole point.
So we should *first* check the count and then may lock/unlock the
mutex
On Tuesday 25 July 2006 09:04, Burkhard Carstens wrote:
Am Dienstag, 25. Juli 2006 10:46 schrieb Micha Nelissen:
function Recursive_Mutex.Lock:...;
begin
// Owned by current thread?
if CurrentThreadId self.ThreadId then
begin
result := pthread_mutex_lock (self...);
On Tuesday 25 July 2006 08:46, Micha Nelissen wrote:
Vinzent Hoefler wrote:
Ehm, no.
Ehm, yes. I was being ironic here. Of course, the action of
checking the counter and locking/unlocking the associated mutex
must be atomic.
But here they are not associated, they're protected
On Tuesday 25 July 2006 14:18, Andreas Berger wrote:
In order to initialize threading under DOS I must create a separate
unit since I need the initialization and finalization clause. I
thought of using a cthreads.pp unit like in unix. However, the
TThread
implementation resides in the
On Tuesday 25 July 2006 14:51, Micha Nelissen wrote:
Vinzent Hoefler wrote:
Ok, there's a glitch: The read and write of self.ThreadId is
required to be atomic, so that a thread entering may either see 0
or the owner's thread id when checking, otherwise it could be
possible, it sees its
On Monday 24 July 2006 10:21, Graeme Geldenhuys wrote:
procedure TtiPool.CreatePoolSemaphore;
begin
{$IFDEF MSWINDOWS}
if FSemaphore 0 then
CloseHandle( FSemaphore ) ;
FSemaphore := CreateSemaphore( nil, FiMaxPoolSize, FiMaxPoolSize,
nil ); {$ENDIF MSWINDOWS}
{$IFDEF LINUX}
On Monday 24 July 2006 13:34, Marco van de Voort wrote:
When I run the Unit Tests and create a single Lock and the Unlock
it, all works fine. If I then iterrate that test by creating 10
locks and then call unlock 10 times, the Unit Tests freeze on the
following line with the second
On Monday 24 July 2006 14:09, Michael Van Canneyt wrote:
On Mon, 24 Jul 2006, Vinzent Hoefler wrote:
On Monday 24 July 2006 13:34, Marco van de Voort wrote:
When I run the Unit Tests and create a single Lock and the Unlock
it, all works fine. If I then iterrate that test by creating 10
On Monday 24 July 2006 14:57, Burkhard Carstens wrote:
I vote for more pascal based versions of TMutex, TSemaphore and
TEvent, that behaves just like the ones in Delphi and use the system
specific functions (like pthread stuff) only internally in their
simplest/most portable form.
I'd vote
On Thursday 13 July 2006 14:49, Alexandre Leclerc wrote:
Now when I execute, I get a problem:
make clean
makefile:1341: *** missing separator. Stop.
This is GNUmake. You need TAB chars instead of spaces in your
rule-commands:
clean: clean
$(MAKE) -C bin clean
^ about here
Vinzent.
On Thursday 13 July 2006 14:58, Alexandre Leclerc wrote:
You won a piece of robot!
Oh man. And I was just two minutes late. ;)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On Wednesday 12 July 2006 09:15, Tomas Hajny wrote:
Well, multitasking multithreading. I'm not sure if DV or Win 3.x
provide special multithreading support for DOS applications...
Nope, not really (at least for Win3.x). There are some services to aid
multi-tasking-aware applications at the
On Wednesday 12 July 2006 09:58, Marco van de Voort wrote:
On 12 jul 2006, at 11:25, Marco van de Voort wrote:
sleep(0) is quite bad, because it may not necessarily give up any
timeslice. At least very short nanosleeps seem to be implemented as
spinning loops on Mac OS X, so maybe
On Wednesday 12 July 2006 10:57, Tomas Hajny wrote:
I certainly don't know a general solution for *nix. However, even old
single-task DOS provides such a function and it's a great help that
can be provided by programmer to scheduler in the underlying OS, so
*nix systems should provide such
On Wednesday 12 July 2006 11:10, Marco van de Voort wrote:
spinning loops on Mac OS X, so maybe sleep(0) is the same.
Do you know a correct way of doing this on *nix?
sched_yield()? Seems to be POSIX, so I suppose it's available on
most Unices.
Yes, and not so recent ('93) that
On Wednesday 12 July 2006 11:34, Andreas Berger wrote:
save and restore the floating point unit. I will need to do this for
FPC, so if someone knows how to save and restore the FPU, I would
apreciate the help.
F(X)SAVE/F(X)RSTOR
The X-Versions are more efficient, but only available on newer
On Wednesday 31 May 2006 01:04, Felipe Monteiro de Carvalho wrote:
0.1 miliseconds is a lot of time for a modern computer.
Depends. Here[tm] it's still just about 100 I/O-cycles.
My experience
is that even running on a graphical environment with other processes
running, you can get 0.1
On Tuesday 16 May 2006 16:18, Alain Michaud wrote:
Do I need open a file deccriptor in order to communicate using
IOCTL?
Yes, you have to open the device before talking to it. Or what the hell
do you think, the Handle parameter of
|Function FpIOCtl (Handle:cint;Ndx: culong;Data:
Just found a bug of mine I was wondering about since about three days,
and wanted to share the fun with you:
-- 8 --
// How to raise the wrong exception or
// Why automatic type conversion really sucks
{$MODE OBJFPC}
program
Exception_Fun;
uses
SysUtils;
function Exception_Message :
On Wednesday 19 April 2006 16:32, L505 wrote:
I didn't say pure pascal programmers with no other skills.
Of course you didn't say *that*. But it still sounds like you are very
focused on language skills. Language skills are much less important
than people usually think.
most
pascal
On Tuesday 18 April 2006 17:24, L505 wrote:
sense to me.). Or maybe you mean a foundation, like a non-profit
organization? Obviously FPC is not out for profit, but out to help
the developer. So I can see a non-profit organization working - but
this would mean that FPC team would spend more
On Thursday 16 March 2006 04:17, Bisma Jayadi wrote:
IMO, .Net is just a bussiness buzz from M$ to attract their customers
and prevent them from switching to Un*x systems. Speaking
technically, I saw nothing new in the .Net technology. It's just a
combination of Java (on the system
On Thursday 16 March 2006 08:24, Marco van de Voort wrote:
While I'm not a .NET lover (I wrote the FPC section on .NET), but
while we all know that .NET is at best M$'s copy of Java,
Well, it may be a copy, but if you take a closer look at it, it's
actually better than Java, at least on the
On Thursday 16 March 2006 16:35, memsom wrote:
Pascal on Linux etc is niche.
Yeah, that has always been my problem. Programming for environments and
in languages that are usually both considered niche.
Nonetheless I do it. And I even get fucking paid for it. And most
important: It really
1 - 100 of 117 matches
Mail list logo
