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
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_APPD
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
On Saturday 17 October 2009, Henry Vermaak wrote:
> I think Graeme's point was that if you have a good grasp of software
> design and programming techniques, you can write good software in
> whatever language you choose.
Absolutely. But there's also the catch: With people only knowing C where
sh
On Sunday 04 December 2005 02:19, Kornel Kisielewicz wrote:
> No, I think that the error is in the BSP building algorithm.
The BSP-trees are built beforehand. I don't see how this would affect
game performance unless the built BSP-tree is heavily unoptimized.
> Original
> C-source probably used
On Monday 27 February 2006 08:41, Vincent Snijders wrote:
> BTW, I never would have guessed that the random number generator
> would have used threadvars. I would have thought, that on app start
> you would set one randseed and then call random from all threads.
Considering that the state array f
On Friday 03 March 2006 12:55, Vincent Snijders wrote:
> Jonas Maebe wrote:
> > On 3 mrt 2006, at 13:42, Vinzent Hoefler wrote:
> >>> BTW, I never would have guessed that the random number generator
> >>> would have used threadvars. I would have thought, that on
On Friday 03 March 2006 11:06, Antal wrote:
> Maybe a bit shifting or some aritmetical function can help to
> obtain a more random "looking" number.
No. Don't do that:
|Random numbers should not be generated with a method chosen at random.
| -- Donald E. Knuth
|The generation of random nu
On Monday 06 March 2006 12:37, Antal wrote:
> > The Mersenne Twister Free Pascal uses is one of the best PRNGs
> > known today, it just has to be used the right way. But calling it
> > from several threads and "randomly" overwriting its state array is
> > definitely not the right way to use it.
>
On Wednesday 08 March 2006 14:33, Graeme Geldenhuys wrote:
> I have managed to get a unique / temp filename under Windows and
> Linux using IFDEF's. Does FPC or Lazarus have a crossplatfrom
> function that does this without the need for IFDEF's?
SysUtils.GetTempFileName?
Vinzent.
On Thursday 09 March 2006 04:31, L505 wrote:
> I have also read people stating things like this before:
>
> "you can use array of const but you can't make functions like writeln
> because writeln accepts multiple types".
Usually the statement is about different _numbers_ of arguments, not
differ
On Thursday 09 March 2006 16:23, L505 wrote:
> Well you are nitpicking my email :-).
Maybe. I'm known for doing that sometimes. I also even tend to write
"SizeOf (byte)" instead of "1".
> I'm not confused at all - the docs are.
Are they?
"My" Free Pascal: Reference Guide states:
|10.3.6 Arr
On Thursday 09 March 2006 17:02, L505 wrote:
> > > Isn't this exactly what array of const is for? It allows you to
> > > use anywhere from 1 to unlimited parameters.
> >
> > Yes. Still, it's only one argument. You can't just suddenly pass
> > two "array of const", can you?
>
> Okay but why would yo
On Thursday 09 March 2006 17:47, Jonas Maebe wrote:
> On 9 mrt 2006, at 18:38, Vincent Snijders wrote:
> >
> > Indeed, it isn't a real random number generator and in fact this is
> > a good thing, otherwise you wouldn't be able to reproduce any
> > behaviour with a Pseudo RNG. The fact it is Pseudo
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 archite
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 wor
On Thursday 16 March 2006 23:12, L505 wrote:
> I always harp on this fact - for example perl is written in C, python
> is written in C, php is written in C, but if you want to learn from
> the sources why shouldn't it be python is written in python and php
> is written with a php compiler. And we
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 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 progr
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_Messa
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: P
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 m
On Friday 23 June 2006 08:59, Пётр Косаревский wrote:
> I know, that I can split {$IF} block:
Well, if you do define CHECK_OVERFLW depending on the current compiler's
settings like this:
{$IFOPT Q+} {$DEFINE CHECK_OVRLW} {$ENDIF}
then ...
> {$Q-} e:=f+g; {$IFDEF CHECK_OVRLW} {Q+} {$ENDIF}
...
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 th
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 may
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 su
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
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 newe
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 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 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
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.
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 vot
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?
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 s
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_loc
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.
>
>
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 TT
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 checkin
On Monday 17 July 2006 19:12, Florian Klaempfl wrote:
> I started also a wiki page about it
> http://www.freepascal.org/wiki/index.php/OpenMP_support where ideas
> can be written down and shared.
Well, I just added some stuff there, yesterday. It's far from being
complete yet (it just covers a b
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 throug
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 bloc
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
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
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
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 p
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.
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 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 does
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,
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 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 poi
On Tuesday 19 September 2006 15:21, Пётр Косаревский wrote:
> Do I get it right, that a construction like
> record
> Something: byte;
> case Something of
> 1: (x,y: word);
> 2: (z: longword);
> end;
> Is impossible in FPC?
Yes, you do. :)
Nevertheless
some_type =
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}
>
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
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 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 mai
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
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, yo
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.
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 driver
On Thursday 05 April 2007 08:57, Michael Van Canneyt wrote:
> The solution is rather simple, it seems to me: write a small C driver
> stub which exposes a uniform interface.
Yes. Of course, apart from the fact that this portion of code can get
rather large depending on the structures and functio
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
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 allo
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 exam
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 oc
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 Tuesday 26 June 2007 17:26, Luca Olivetti wrote:
> procedure TButlerPhone.Receive(s: string);
>
> so s is a parameter.
> This procedure is called exclusively from
>
> procedure TStatusThread.Receive;
> begin
>FOwner.Receive(FData)
> end;
>
> (FOwner is a TButlerPhone)
>
> which in turn is c
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, t
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.
___
fpc-
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:
http://w
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 t
On Tuesday 14 August 2007 08:08, Florian Klaempfl wrote:
> Vinzent Hoefler schrieb:
> > 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
On Tuesday 14 August 2007 09:36, Daniël Mantione wrote:
> So, would it be the end of bugs? Not at all. You would prevent
> implementation bugs, not design bugs.
Precisely. Proving that the program behaves according to the
specification doesn't help if the specification is wrong. See Ariane5.
Or
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> gre
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 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
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 mai
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 MyEvent.SetEvent/M
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,T
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" memb
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 Eve
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 surp
On Wednesday 31 October 2007 11:17, Jonas Maebe wrote:
> The regexp library is case 1. A program using that library is case 2.
> Case 1 can be written in C because the original author prefers C.
> Case 2 can be written in Pascal because you prefer Pascal. "Language
> superiority" does not enter th
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 d
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 LIBRAR
On Thursday 06 December 2007 12:22, Bee wrote:
> > Revert the file $(FPCDIR)\packages\paszlib\src\zstream.pp to
> > revision 9290
>
> Sorry if I sound silly, but how to revert to specific rev number? svn
> revert command doesn't expect a number. :(
Easy way to check:
svn up -r 9290 $(FPCDIR)/pack
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/zstr
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 so
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.
> Ho
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
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 ?
> >
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 this is a good time to start becoming a serious
developer now?
Vinzent.
___
On Friday 18 January 2008 11:34, Bee wrote:
> For some reasons, sometimes version control is too bloated,
> especially when the project is not too big.
I used RCS on 2K SLOC projects years ago already and never found it to
be "too bloated". No, I could actually look at the change log and diffs
On Friday 18 January 2008 12:07, Michael Van Canneyt wrote:
>It doesn't take a lot of intelligence to see that if unitname can
>containe one (or more) dots, this mechanism becomes suddenly a lot
> harder because your unitname may, by accident, match
> unitname.identifier1 of a symbol in an
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
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 A
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
1 - 100 of 141 matches
Mail list logo
