Re: [fpc-devel] New feature discussion: for-in loop

2009-10-31 Thread Vinzent Hoefler
On Monday 26 October 2009, Micha Nelissen wrote: Vinzent Höfler wrote: At first, const function would tell us that the function does not change the object in any way, right? What is the object? In that case, the list, of course. Usually there are 2 objects: the list (TList e.g.) and

Re: [fpc-devel] Want to remove AVL_Tree from DOM

2009-10-31 Thread Vinzent Hoefler
On Saturday 24 October 2009, Sergei Gorelkin wrote: I want to remove the avl_tree-related stuff from DOM unit. The reasons are: If that's a CfV, I vote yes. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] class abstract, class sealed implementation. please review.

2009-10-17 Thread Vinzent Hoefler
On Saturday 17 October 2009, Florian Klaempfl wrote: Vinzent Höfler schrieb: Florian Klaempfl flor...@freepascal.org: From a compiler developers point of view, it makes optimization easier under certain cases (e.g. virtual method calls). It's the same as with inline: inline has no

Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.

2008-02-28 Thread Vinzent Hoefler
On Tuesday 26 February 2008 17:27, Luiz Americo Pereira Camara wrote: Yury Sidorov wrote: The patch removes packed record for some platforms. IMO packed can be removed for all platforms. It will gain some speed. I'd like to understand more this issue. Why are non packed records faster?

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-28 Thread Vinzent Hoefler
On Thursday 28 February 2008 09:51, Micha Nelissen wrote: Well we have procedures to do byte swapping, but none to do bit swapping. It's also very inefficient AFAIK; while changing the compiler's definition of which bit to use is free. {$BITORDER LOW_ORDER_FIRST} {$BITORDER HIGH_ORDER_FIRST}

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-28 Thread Vinzent Hoefler
On Thursday 28 February 2008 10:01, Michael Schnell wrote: {$BITORDER LOW_ORDER_FIRST} {$BITORDER HIGH_ORDER_FIRST} Where can this be used ? What exactly does it mean ? Well, call it proposal (of course, the names are strongly influenced by personal language preferences). AFAICS, it would

Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.

2008-02-28 Thread Vinzent Hoefler
On Thursday 28 February 2008 11:25, Daniël Mantione wrote: Op Thu, 28 Feb 2008, schreef Vinzent Hoefler: On Thursday 28 February 2008 09:16, Daniël Mantione wrote: Memory access. What happens is that the non-packed version causes more cache misses. OMG. I'm s confused. ;) I read

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-28 Thread Vinzent Hoefler
On Thursday 28 February 2008 11:28, Michael Schnell wrote: AFAICS, it would be useful for bitpacked records only, so it could appear anywhere where a {PACKRECORDS} directive or similar can appear currently. IMHO it would only be useful (allowed with, regarded by) bitpacked record, as any

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-28 Thread Vinzent Hoefler
On Thursday 28 February 2008 12:17, Michael Schnell wrote: Enable_Mode : Enable_Set; // bit 14 .. 15/leftmost bits With an x86 the leftmost bits will be in the rightmost (second) of the two bytes, with an 68K the leftmost bits will be in the leftmost (first) of the two bytes,

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-28 Thread Vinzent Hoefler
On Thursday 28 February 2008 13:09, Michael Schnell wrote: Yes. That's what {$BIT_ORDER} would stand for (still, it would not change *byte* order). I don't understand this. I don't think the bit order within a byte is to be considered changing. Well, the question is, if the first bit in a

Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.

2008-02-28 Thread Vinzent Hoefler
Are enumeration types 1 or 4 bytes in Delphi? If they are one byte, it looks quite different (and I'm not sure about all the types used here, some seem to be sets, some enumerations). But at the first glance it seems, they used both packed records to either ensure minimum size or known record

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
On Wednesday 27 February 2008 09:44, Michael Schnell wrote: You can avoid cryptic language constructs in the main source code. Or you can avoid cryptic languages altogether. :D I did not yet use the preprocessor in Pascal but a standard way to access memory mapped ports in C is something

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
On Wednesday 27 February 2008 11:16, Micha Nelissen wrote: Vinzent Hoefler wrote: On Wednesday 27 February 2008 09:44, Michael Schnell wrote: You can avoid cryptic language constructs in the main source code. Or you can avoid cryptic languages altogether. :D You mean like ADA? Indeed, I

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
On Wednesday 27 February 2008 11:47, Daniël Mantione wrote: Then use bitpacked records: If you'd document them properly? -- 8 -- type TX = 1 .. 4; TY = 0 .. 3; type Foo = bitpacked record A : TX; B : TY; end {record}; var X : Foo; begin X.A := 1; X.B := 2;

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
On Wednesday 27 February 2008 11:45, Florian Klaempfl wrote: Vinzent Hoefler schrieb: On Wednesday 27 February 2008 11:16, Micha Nelissen wrote: Vinzent Hoefler wrote: If I mean to set the write buffer water mark of the SDRAM controller register, I'd rather write

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
On Wednesday 27 February 2008 12:33, Daniël Mantione wrote: Too many Ada-features have crept into Pascal over the years. ;) You can look at it that way, but Ada wasn't the blueprint for Pascal extensions. Well, in the early days, it was quite the other way around, yes. Ada is derived

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
On Wednesday 27 February 2008 12:56, Jonas Maebe wrote: On 27 Feb 2008, at 12:17, Vinzent Hoefler wrote: Free Pascal Compiler version 2.0.0 [2005/09/09] for i386 Copyright (c) 1993-2005 by Florian Klaempfl Target OS: Linux for i386 Compiling test.pas test.pas(6,10) Error: Identifier

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
On Wednesday 27 February 2008 12:21, Daniël Mantione wrote: Op Wed, 27 Feb 2008, schreef Vinzent Hoefler: Well, TP didn't, and until now I found no real documentation on it (it sure wasn't mentioned in *my* copy of the programmer's manual). That is correct, but the last version of TP

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
On Wednesday 27 February 2008 13:55, Jonas Maebe wrote: And no, I'm not saying it's your fault if something you use breaks in a newer release, I'm merely saying it's nobody else's fault in particular either (at least not most of the time). Hey, I wasn't trying to blame anybody here. I was

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
On Wednesday 27 February 2008 14:15, Florian Klaempfl wrote: Vinzent Hoefler schrieb: And that's why I'd rather go with Ada's representation clauses. If the hardware platform is unsuitable for the thing I want it to do, it simply doesn't compile. Which is justified, because in 99

Re: [fpc-devel] Freepascal in microcontrollers

2008-02-27 Thread Vinzent Hoefler
On Wednesday 27 February 2008 15:56, Michael Schnell wrote: In the Linux source code preprocessor macros are used if data structures are accessed that require a certain endianess (usually net- data that are defined high byte first by TCP/IP). Here clever tweaking provides that no additional

Re: [fpc-devel] New download location for the ebook--sorry for the messup!

2008-02-20 Thread Vinzent Hoefler
On Wednesday 20 February 2008 17:01, Jeff Duntemann wrote: Good luck and thanks for the reports. I'll have to look into why Lulu downloads don't work. Well, JFTR, the download at the original site worked for me just like any other. No problems. And for the content: It was a pleasure reading

Re: [fpc-devel] Light weight threads for FPC

2007-12-14 Thread Vinzent Hoefler
On Thursday 13 December 2007 19:55, Mattias Gaertner wrote: Has someone already created a unit for light weight threads? Something like: Create a group of 4 threads named 0,1,2,3 and execute a procedure/method? for i := 0 to 3 do Handle[i] := tThreadId(BeginThread (Func {tThreadFunc},

Re: [fpc-devel] Light weight threads for FPC

2007-12-14 Thread Vinzent Hoefler
On Friday 14 December 2007 09:37, Felipe Monteiro de Carvalho wrote: On Dec 13, 2007 7:55 PM, Mattias Gaertner [EMAIL PROTECTED] wrote: Has someone already created a unit for light weight threads? I don't know much on the subject, but Is TThread heavy? What are the disadvantages of using

Re: [fpc-devel] Light weight threads for FPC

2007-12-14 Thread Vinzent Hoefler
On Friday 14 December 2007 10:20, Florian Klaempfl wrote: I think some thread pool class is more important, it would be basically the same as above for i := 0 to 3 do Handle[i] := TTask(ThreadPool.QueueTask(Func {tThreadFunc}, @FuncArg[i])); for i

Re: [fpc-devel] Light weight threads for FPC

2007-12-14 Thread Vinzent Hoefler
On Friday 14 December 2007 11:46, Mattias Gaertner wrote: For many parallel algorithms you don't need events, priority or synchronize. But you need to easily and fast start a set of threads with IDs 0..N. Ok, so you're mostly caring about the thread creation overhead, it seems. So yes,

Re: [fpc-devel] weird syntax

2007-12-11 Thread Vinzent Hoefler
On Tuesday 11 December 2007 10:04, Michael Schnell wrote: Andrew Haines wrote: Hi, Is it possible to make this work: if X 3 or 10 then ... of course it would be shorthand for: if (X3) or (X10) then The or operator is stronger than the operator by definition. This can't

Re: [fpc-devel] Parallel Computing

2007-12-10 Thread Vinzent Hoefler
On Monday 10 December 2007 12:54, Michael Schnell wrote: IMHO the parallel idea is hard to implement, as the compiler needs to heavily support it. Nonetheless, this was what this wiki page was about: Proposals for parallel *language* constructs (especially WRT to the C-centric OMP spec).

Re: [fpc-devel] Parallel Computing

2007-12-03 Thread Vinzent Hoefler
On Monday 03 December 2007 09:20, Graeme Geldenhuys wrote: On 03/12/2007, Marco van de Voort [EMAIL PROTECTED] wrote: That is an open door that has been kicked in by all vendors. The problem is I kind-of understand that... Borland tried to encapsulate the whole threading thing in a

[fpc-devel] SysUtils exception translation issues

2007-10-22 Thread Vinzent Hoefler
Hi all, after we had that quite heated discussion in core, I decided to take matters into my own hand and come up with some useful proposal. But now I am looking at fpc2.2.0 sources for SysUtils and feel quite desperate. The thing is that I don't know if those are actual bugs, design

Re: [fpc-devel] property syntax extension

2007-10-18 Thread Vinzent Hoefler
On Thursday 18 October 2007 12:55, Michael Schnell wrote: I think it is better to send a RTF document than a ODT document: * it is smaller * more programs can read it * no need to download and install plug-ins for a seizable minority of people without open office or ODT-plug-in

Re: [fpc-devel] sdlgraph, pre-alpha

2007-08-22 Thread Vinzent Hoefler
On Wednesday 22 August 2007 19:18, Micha Nelissen wrote: Michael Van Canneyt wrote: Why is calling via a procvar very much slower than a normal call ? It's just an extra memory fetch (hopefully in cache) ? Jonas meant that each pixel is drawn separately. The procvar is not the issue.

Re: [fpc-devel] win32 debugging broken in fixes_2_2?

2007-07-10 Thread Vinzent Hoefler
On Tuesday 10 July 2007 12:40, Yury Sidorov wrote: Maybe other way to detect SSE support exists... CPUID? Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] win32 debugging broken in fixes_2_2?

2007-07-10 Thread Vinzent Hoefler
On Tuesday 10 July 2007 09:58, Vinzent Hoefler wrote: On Tuesday 10 July 2007 12:40, Yury Sidorov wrote: Maybe other way to detect SSE support exists... CPUID? To be more precise, the way recommended by Intel: To make this check, execute the CPUID instruction with an argument of 1

Re: [fpc-devel] language extensions

2007-06-14 Thread Vinzent Hoefler
On Thursday 14 June 2007 06:42, Florian Klaempfl wrote: Why do you need a plug in mechanism? You've the sources? When you have the sources, 90 per cent of the use of a plugin are gone. Well, we'd call that non-intrusive change. ;) You'd just need to compile the plug-in, and not a changed

Re: [fpc-devel] Issue with Critical sections

2007-04-05 Thread Vinzent Hoefler
On Wednesday 04 April 2007 15:29, Sergei Gorelkin wrote: That is exactly what I'm speaking about. Removing 'Windows' from uses clause is essentially stopping using it :) And if the code continues to compile and work after that, it is just fine. Sorry, I always forget that most people are not

Re: [fpc-devel] Issue with Critical sections

2007-04-05 Thread Vinzent Hoefler
On Thursday 05 April 2007 09:16, Sergei Gorelkin wrote: It appears that my way of thinking has been severely affected by using IDEs. When putting mouse over identifier shows where it comes from, prefixing seems redundant :) Prefixing *is* redundant, that's the whole point of it, but it also

Re: [fpc-devel] Issue with Critical sections

2007-04-04 Thread Vinzent Hoefler
On Wednesday 04 April 2007 10:33, Sergei Gorelkin wrote: I was porting to Linux some Windows code which uses critical sections API, and got 'Identifier not found' error on InitializeCriticalSection and DeleteCriticalSection symbols. If I had to guess, I'd say this is probably because those

Re: [fpc-devel] Issue with Critical sections

2007-04-04 Thread Vinzent Hoefler
On Wednesday 04 April 2007 12:59, Sergei Gorelkin wrote: But EnterCriticalSection/LeaveCriticalSection also exist in Windows API. And they are implemented in System unit without changing names. Therefore, to make my code cross-platform, I have only to remove Windows from uses clause - then

Re: [fpc-devel] Issue with Critical sections

2007-04-04 Thread Vinzent Hoefler
On Wednesday 04 April 2007 13:13, Micha Nelissen wrote: Sergei Gorelkin wrote: But EnterCriticalSection/LeaveCriticalSection also exist in Windows API. And they are implemented in System unit without changing names. Therefore, to They shouldn't be exposed publicly in the system unit.

Re: [fpc-devel] Re: Inter Process Communication

2007-02-28 Thread Vinzent Hoefler
On Thursday 01 March 2007 00:11, Jason P Sage wrote: I've just performed more tests using the stock simpleipc - and the SendMessage and GetMessage - though defined as STRING (Which I thought had a max length) seems to be able to support huge ansistrings. Well, RTFS: |unit simpleipc; |

Re: [fpc-devel] case with range stupidities

2007-02-15 Thread Vinzent Hoefler
On Thursday 15 February 2007 13:06, Daniël Mantione wrote: Op Thu, 15 Feb 2007, schreef Vinzent Hoefler: program Case_Test; type My_Range = 2000 .. 3000; var X : Integer; begin X := 2500; case X of Low (My_Range) .. High (My_Range) : WriteLn

Re: [fpc-devel] case with range stupidities

2007-02-15 Thread Vinzent Hoefler
On Thursday 15 February 2007 13:36, Daniël Mantione wrote: Op Thu, 15 Feb 2007, schreef Vinzent Hoefler: Well, fair enough, but why is that I can declare a type Foo = array[byte] of Something; where the type name byte also indicates the range? Considering that type

Re: [fpc-devel] Error: Unable to create reg.xml file

2007-01-19 Thread Vinzent Hoefler
On Friday 19 January 2007 13:12, Marco van de Voort wrote: There is one dangerous caution against overzealous inifile use: with lessened privileges (a situation that is going to become more frequent under Vista, iow, user has no admin rights), apps can't write to program files/ with the

Re: [fpc-devel] Error: Unable to create reg.xml file

2007-01-19 Thread Vinzent Hoefler
On Friday 19 January 2007 13:23, Michael Van Canneyt wrote: HKEY_USER keys is not desirable or feasible (roaming profiles etc). A config directory can be made read/write for all users. A registry key can be made that, too. Vinzent. ___ fpc-devel

Re: [fpc-devel] Threads and alot of crap continued

2006-11-09 Thread Vinzent Hoefler
On Thursday 09 November 2006 08:22, Michael Schnell wrote: Yes, of course, this still *is* nothing more than an event loop, ... A decent event loop should use an OS API to free the processor until the next event is scheduled: That's why I wrote the example in Esterel. Give me that API and

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 09:27, Ales Katona wrote: On st , 2006-11-08 at 07:35 +, Vinzent Hoefler wrote: On Tuesday 07 November 2006 16:10, Ales Katona wrote: As for general use, you can't do a Timer this way. Believe me, I can. :) You can't just put a TTimer in which

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 09:42, Michael Van Canneyt wrote: On Wed, 8 Nov 2006, Vinzent Hoefler wrote: On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote: On Wed, 8 Nov 2006, Michael Schnell wrote: As for general use, you can't do a Timer this way. Right

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 10:01, Michael Schnell wrote: But doing a function call (or hence using a callback) does not change the thread context you are running in and thus you are still the same thread. IOW: code lines are not _dedicated_ to a thread context. Oh that, of course. Seems

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 10:14, Michael Schnell wrote: If you take a look the start of this thread, I mentioned that after implementing Delphi/Lazarus like behavior for the main thread without the need for a GUI, I'd like to enhance the concept by optionally having an TApplication object

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 10:26, Ales Katona wrote: This is an old problem, and not fixable by wishing it. If you want a good async. timer, sure make one, but don't expect it to work safely by magic. I'm sure I won't, I'm paranoid. :) That's what I ment, it won't simply just work

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 10:53, Micha Nelissen wrote: Sorry for all the confusion, I'm trying to clarify what I actually mean (or what I would *expect* from such a timer object): I don't see how async timers can be useful for software (maybe to control hardware perhaps, but only the

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 12:44, Micha Nelissen wrote: Vinzent Hoefler wrote: So, the semantics would be about the same as in a signal (apart from the softer timing), but you would have much less restrictions in the handler's implementation compared to a real OS signal, which acts

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 13:21, Micha Nelissen wrote: Vinzent Hoefler wrote: repeat SysUtils.Sleep (self.Interval); self.Logger.Flush; until self.Terminated; is totally impossible to work? To implement something less crude you It works, Oh wonder. A couple

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 14:43, Micha Nelissen wrote: Vinzent Hoefler wrote: but it's not realtime by any definition. First, I never said real-time in that context and second: it sure can I concluded that from your quote: meta-quote Timing events allow for a handler

Re: [fpc-devel] Threads and alot of crap continued

2006-11-08 Thread Vinzent Hoefler
On Wednesday 08 November 2006 16:08, Micha Nelissen wrote: Vinzent Hoefler wrote: The answer to my I always thought a timer is more comparable to an interrupt or signal than a polling loop. was That is a very common misconception. which I still refuse as being a correct answer

Re: [fpc-devel] TStringList.CustomSort

2006-11-07 Thread Vinzent Hoefler
On Tuesday 07 November 2006 09:17, Micha Nelissen wrote: Chris Cheney wrote: Of course, the efficient way to build a sorted list is to set Sorted to False and to sort the list after all the items have been added. It doesn't matter in O-time: both are O(n log n). Nevertheless, you

Re: [fpc-devel] Threads and alot of crap continued

2006-11-07 Thread Vinzent Hoefler
On Tuesday 07 November 2006 12:42, Ales Katona wrote: If you want a Timer a polling mechanism has to take place which looks if something happened on some timer for example, Is that so? OnTimer is ready to be fired (you can't call callbacks in threads, I can't call callbacks in threads?

Re: [fpc-devel] Threads and alot of crap continued

2006-11-07 Thread Vinzent Hoefler
On Tuesday 07 November 2006 14:47, Michael Schnell wrote: Well, for me it would have saved me some time which I wasted in creating threads that implement timing events by simply sleeping for a particular time. IMHO this should be done following the Delphi paradigms to be nice to Delphi

Re: [fpc-devel] Threads and alot of crap continued

2006-11-07 Thread Vinzent Hoefler
On Tuesday 07 November 2006 15:02, Michael Schnell wrote: I always thought a timer is more comparable to an interrupt or signal than a polling loop. That is a very common misconception. Indeed. Even a paper in Embedded Computing Design about Ada 2005 follows that very common

Re: [fpc-devel] Threads and alot of crap continued

2006-11-07 Thread Vinzent Hoefler
On Tuesday 07 November 2006 15:17, Ales Katona wrote: So eg: if you want to do something every 1000ms, you could put a TThread based timer in, and make it Sleep(1000) and then call the code, but you must be sure that your main thread cannot have conflicts if this code is called at any time

Re: [fpc-devel] Threads and alot of crap continued

2006-11-07 Thread Vinzent Hoefler
On Tuesday 07 November 2006 16:10, Ales Katona wrote: As for general use, you can't do a Timer this way. Believe me, I can. :) You can't just put a TTimer in which works in it's own thread and then calls some callback in it's own thread, I even call the callback of another thread. :P

Re: [fpc-devel] Threads and alot of crap continued

2006-11-07 Thread Vinzent Hoefler
On Tuesday 07 November 2006 17:10, Michael Schnell wrote: Of course, because the common concept of a timer is as asynchronous as in multi-threaded or even interrupt. That is not true ! (See my other post.) Well, a timer is, even though the Delphi implementation of a so-called TTimer object

Re: [fpc-devel] CmdLine

2006-10-19 Thread Vinzent Hoefler
On Thursday 19 October 2006 08:31, Marc Weustink wrote: The case shows that users can do this. There is no language construct that forbids it. So optimizing this with a smart linker may break such code. Yes, it may. So what? There's hell a lot of code that is generally possible within the

Re: [fpc-devel] CmdLine

2006-10-19 Thread Vinzent Hoefler
On Thursday 19 October 2006 09:39, Marc Weustink wrote: The only thing guaranteed by the language is that if you follow its definitions, it will compile. No. That's syntax. I'm talking about semantics. Vinzent. ___ fpc-devel maillist -

Re: [fpc-devel] Threads and alot of crap

2006-10-17 Thread Vinzent Hoefler
On Tuesday 17 October 2006 09:03, Jonas Maebe wrote: On 17 okt 2006, at 10:44, Daniël Mantione wrote: procedure intRTLEventSetEvent(AEvent: PRTLEvent); var p:pintrtlevent; begin p:=pintrtlevent(aevent); pthread_mutex_lock(@p^.mutex); pthread_cond_signal(@p^.condvar);

Re: [fpc-devel] Threads and alot of crap

2006-10-17 Thread Vinzent Hoefler
On Tuesday 17 October 2006 09:46, Jonas Maebe wrote: On 17 okt 2006, at 11:22, Vinzent Hoefler wrote: The pthread_cond_wait() function atomically unlocks the mutex argument and waits on the cond argument. So the mutex should already be unlocked afterwards. If you would

Re: [fpc-devel] Threads and alot of crap

2006-10-17 Thread Vinzent Hoefler
On Tuesday 17 October 2006 10:03, Micha Nelissen wrote: Windows events do not have this problem since they are stateful. To be more precise: Windows signals are persistent, not transient like Unix signals are. Vinzent. ___ fpc-devel maillist -

Re: [fpc-devel] format function

2006-10-12 Thread Vinzent Hoefler
On Thursday 12 October 2006 12:16, Andrea Mauri wrote: Dear all, this is my first mail to this mailing list, I'm not sure this is the correct one to post this topic. I noticed a strange behavior of the format function. I'm not sure it can be considered as a bug. If I use format('%.3f',

Re: [fpc-devel] format function

2006-10-12 Thread Vinzent Hoefler
On Thursday 12 October 2006 13:46, Micha Nelissen wrote: Jonas Maebe wrote: can still be one (meaning that it's a negative zero). And for some fpu calculations this even matters. Like ? Divide by signed zero. That decides if the result is positive or negative infinity. :D Vinzent.

Re: [fpc-devel] Tail recursion optimization

2006-10-10 Thread Vinzent Hoefler
On Tuesday 10 October 2006 08:29, Florian Klaempfl wrote: Daniël Mantione wrote: Op Tue, 10 Oct 2006, schreef Florian Klaempfl: Yesterday, I've implemented tail recursion optimization (http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas resulting in

Re: [fpc-devel] Adding a unidirectional dataset to sqldb

2006-10-05 Thread Vinzent Hoefler
On Thursday 05 October 2006 08:13, Michael Van Canneyt wrote: On Thu, 5 Oct 2006, Joost van der Sluis wrote: Now I'm thinking about using an interface, to avoid double code. But I don't know what effect that has on run-time performance. I mean, the idea was to make if faster ... An

Re: [fpc-devel] Suggestion for change: Overly strict check

2006-10-04 Thread Vinzent Hoefler
On Tuesday 03 October 2006 16:26, Flávio Etrusco wrote: At my workplace we've standardized on using three scope prefixes: p_ for function parameter, m_ for members/fields, and g_ for global. I know that discussion, I lost it at work already, but apart from C where every identifier is sort of

Re: [fpc-devel] Suggestion for change: Overly strict check

2006-09-28 Thread Vinzent Hoefler
On Wednesday 27 September 2006 20:50, ik wrote: Let me give you an example of a real bug that allow attackers to gain root access using X-server, and I hope you will understand why such checking can be a good thing. It *can*. But as usual the pros and cons should be weighted properly.

[fpc-devel] Inlining functions...

2006-07-25 Thread Vinzent Hoefler
Hi, some questions: 1) Is there some good reason why the support for the inline keyword can be turned on and off explicitely by the {$INLINE} directive? 2) Can I check somehow if inlining is enabled during compilation? {$IFOPT INLINE} didn't work. ;) 2a) If the answer to 2) is no, can we

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

2006-07-18 Thread Vinzent Hoefler
On Monday 17 July 2006 15:33, Micha Nelissen wrote: Vinzent Hoefler wrote: Of course they don't. Unlike some other languages where such things are standardized quite clearly, (most) consistency, dependency and linking issues are beyond the scope of the official C-standard. I'm not talking

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

2006-07-17 Thread Vinzent Hoefler
On Monday 17 July 2006 15:03, Micha Nelissen wrote: No these are separate things. The C compiler vendors do not provide a common platform resulting in a differing mess that has to be held together with scripts. Of course they don't. Unlike some other languages where such things are

Re: [fpc-devel] Problem loading 2 dlls created on Free Pascal

2006-07-13 Thread Vinzent Hoefler
On Thursday 13 July 2006 12:31, Jose Manuel wrote: The error code is: 193 0x00C1 N/A %1 is not a valid Win32 application. But that doesn't make sense. [...] I guess FPC is creating the DLL with no relocation section in it. Another issue is that meaningless error. It should be

Re: [fpc-devel] Format with zero padding

2006-06-20 Thread Vinzent Hoefler
On Tuesday 20 June 2006 10:44, Micha Nelissen wrote: How can I zero-pad using Format ? RTFM. :-) SysUtils.Format ('%.4D', Some_Int); Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Format with zero padding

2006-06-20 Thread Vinzent Hoefler
On Tuesday 20 June 2006 11:39, Micha Nelissen wrote: Vinzent Hoefler wrote: On Tuesday 20 June 2006 10:44, Micha Nelissen wrote: How can I zero-pad using Format ? RTFM. :-) SysUtils.Format ('%.4D', Some_Int); Sounds like I found a case where 'C' is more intuitive than pascal

Re: [fpc-devel] dominant short strings in compiler source

2006-05-18 Thread Vinzent Hoefler
On Wednesday 17 May 2006 20:50, Marco van de Voort wrote: Having to check and guard each and every string operation is also not really productive. KR tried that :-) And I thought they did it the other way around. Leaving the check as an exercise to the coder. ;-) Vinzent.

Re: [fpc-devel] Math.DivMod results should be signed

2006-03-21 Thread Vinzent Hoefler
On Tuesday 21 March 2006 04:37, Michalis Kamburelis wrote: I'm concerned with using DivMod in cases when Dividend is 0. DivMod declaration is procedure DivMod(Dividend: Integer; Divisor: Word; var Result, Remainder: Word); which means that it doesn't allow for Result and Remainder to

Re: [fpc-devel] about realtime tasks

2006-01-18 Thread Vinzent Hoefler
On Wednesday 18 January 2006 10:30, Stefan Kisdaroczi wrote: Its working so far, but using multiple tasks, there are some strange effects (exceptions,hangs). From the freepascal documentation: Although it is not forbidden to do so, it is not recommended to use system-specific threading

Re: [fpc-devel] Templates / Generics

2005-11-04 Thread Vinzent Hoefler
On Friday 04 November 2005 09:25, Micha Nelissen wrote: Marc Weustink wrote: If the generic is precompiled (which is maybe necesary if you need access to privates) then I fear some runtime logic has to be added to call the correct procedure. IE. something like case TypeInfo(Data) of

Re: [fpc-devel] Templates / Generics Syntax

2005-11-04 Thread Vinzent Hoefler
On Friday 04 November 2005 13:00, Micha Nelissen wrote: Combining some of the wiki ideas, and has no evil characters :-). I don't understand the fuzz about using . It's not even close to being C(++)-ish, because it was used for describing discrete range types _at least_ in Ada's generics

Re: [fpc-devel] Templates / Generics Syntax

2005-11-04 Thread Vinzent Hoefler
On Friday 04 November 2005 13:27, Marco van de Voort wrote: [] The evil is in - using characters instead of modifiers. - worse, recycling already used characters. Alright, I completely understand at least the first part, so perhaps they should simply not be overused. :-) Just for the fun

Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)

2005-07-08 Thread Vinzent Hoefler
On Thursday 07 July 2005 21:27, Marcel Martin wrote: Vinzent Hoefler a écrit : Personal note: Maybe there was a reason why Borland Pascal didn't do range checks on Inc/Dec. Yes, there is always a good reason for a bug :-) Any sufficiently advanced bug cannot be distinguished from

Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)

2005-07-08 Thread Vinzent Hoefler
On Friday 08 July 2005 10:49, Gerhard Scholz wrote: Beside, v is word or byte, depending on a compiler-$if elsewhere, so I would have to write: inc ( {$ifdef big} smallint {$else} shortint {$endif }v, delta ) ; Not very clear readable. Agreed. It's not readable at all. So don't do that,

Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)

2005-07-08 Thread Vinzent Hoefler
On Friday 08 July 2005 12:24, Gerhard Scholz wrote: - Original Message - From: Vinzent Hoefler [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Friday, July 08, 2005 1:24 PM Subject: Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i) OTOH, ... new abbreviation

Re: [fpc-devel] Advantages of/alternatives for Inc (was: bug: Inc(v, i)/Dec(v, i))

2005-07-08 Thread Vinzent Hoefler
On Friday 08 July 2005 12:39, Tom Verhoeff wrote: On Thu, Jul 07, 2005 at 07:47:03AM +, Vinzent Hoefler wrote: operators. So especially with the added overflow check I think, Inc and Dec are pretty useless functions, because the don't do anything you can't accomplish by using

Re: [fpc-devel] {$DEFINE x := something}

2005-07-01 Thread Vinzent Hoefler
On Friday 01 July 2005 00:12, L505 wrote: As I have indicated, I am very happy to have 83-88 lines of Pascal code on my screen versus even 70 or 55. Doesn't matter. One function at a time is enough to see. ;-) I have 72x30 (yes, that's width height in chars). All function not fitting into

Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-03 Thread Vinzent Hoefler
On Friday 03 June 2005 10:47, Jamie McCracken wrote: It makes it more clear IMO not less. having all that interface code and having to jump between it and the implementation does not aid legibility. It encourages reading code instead of interface specifications. Often there is a big

Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-03 Thread Vinzent Hoefler
On Thursday 02 June 2005 16:12, Marco van de Voort wrote: Begin..End is redundant - you have to indent them to make em readable anyways. No. This makes the code more readable like normal english text. It states much more clearly what it intents, at least much more than just indenting

Re: [fpc-devel] type discussion

2005-06-02 Thread Vinzent Hoefler
On Thursday 02 June 2005 13:04, Jamie McCracken wrote: However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. In terms of _written_ or in terms of _working_ lines of code? :- Vinzent. -- public key:

Re: [fpc-devel] type discussion

2005-06-02 Thread Vinzent Hoefler
On Thursday 02 June 2005 13:22, Jamie McCracken wrote: Vinzent Hoefler wrote: On Thursday 02 June 2005 13:04, Jamie McCracken wrote: However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. In terms of _written_ or in terms

Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread Vinzent Hoefler
On Thursday 02 June 2005 13:38, Jamie McCracken wrote: Florian Klaempfl wrote: I'am a poor delphi programmer, didn't use it for years, but I bet with any python programmer that I create any application faster than him :) You must be a damn fast typer then :) No, that's a common

Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread Vinzent Hoefler
On Thursday 02 June 2005 14:01, Jamie McCracken wrote: Vinzent Hoefler wrote: What matters is designing und understanding the code, not writing it. I spend less than 10% of my time at work in actually _writing_ code, so even if someone can type in his/her code twice as fast, the maximum

Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread Vinzent Hoefler
On Thursday 02 June 2005 14:24, Jamie McCracken wrote: Well I will typically spend about 25% of my development time with forward declarations, doing loads of try finaly blocks to free memory and other things instead of implementing my application. I typically spend 80% of my development time

Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread Vinzent Hoefler
On Thursday 02 June 2005 14:44, Jamie McCracken wrote: My point is to to reduce or remove *redundant* syntax that serves no useful or productive purpose (to the programmer). Well applied redundancy is a good thing. Forward declarations are redundant - they exist purely for the benefit of

Re: [fpc-devel] type discussion

2005-06-02 Thread Vinzent Hoefler
On Thursday 02 June 2005 15:16, Uberto Barbini wrote: If the goal is this, I'd prefear a way to declare objects autocreated: varauto: strlist: TStringList; begin //some stuff end; [...] It could be a problem to pass parameters to the constructor. Yes, exactly. So why bother the

  1   2   >