Re: [fpc-pascal] Where does Write(Ln) actually write to?
Jonas Maebe-2 wrote: > > It writes to whatever the text file variable called "stdout" in rtl/ > inc/systemh.inc is assigned to. Standard I/O is indeed buffered, see > the routines in rtl/inc/text.inc. The actual writing from the buffer > to the associated file/device is done by FileWriteFunc(), which calls > Do_Write() (the latter is an OS-specific function that you have to > implement). > > Also note that if textrec.FlushFunc is nil, then write(ln) will not > automatically flush after each operation. As you can see in > FileOpenFunc(), it is only assigned in case Do_Isdevice() returns true > for the handle of the opened "file". > Roger that, implementation begins... -- View this message in context: http://www.nabble.com/Where-does-Write%28Ln%29-actually-write-to--tp23380791p23495593.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: MacMode More Info
The results of your email command are provided below. Attached is your original message. - Results: Invalid confirmation string. Note that confirmation strings expire approximately 3 days after the initial subscription request. If your confirmation has expired, please try to re-submit your original request or message. - Unprocessed: confirm -- - Done. Darn. Still not member. Not problem since this is my last post. I found my answer. It's been a month , I hadn't had the time to follow up on my original question which was What kind of object is used under Macpas compatibility mode ? "Object Pascal, Mac style." didn't say much. (http://wiki.freepascal.org/Mode_MacPas ) Any way I did some trial runs. Here what I found : in Macpas compatibilty mode Objects can not be use as a record , objectvariable.field := value ; objectvariable.init ;compile but cause runtime exception AccessViolation Objects need to be dynamicaly created first ObjectVariable := new (TObjectType,Init) does not compile , compile error : type identifier expected NEW(ObjectVariable) ; ObjectVariable.init ; ObjectVariable := TObjectType.Init ; works They are NOT compatible with (inheritable from) object types from the Objects unit : TMyCollection = object (TCollection) end ; cause compile error error 31 mix of different kind (class, object, interface, etc isn't allowed error 37: internal error 200611081 but you can use them TMyCollection = TCollection ; They are compatible with class types from Classes unit TMyCollection = object (TCollection) end ; works In conclusion it seems that objects in Macpas mode are references, pointers and not just records represent the Delphi class sementic instead of the Delphi object sementic but use "object" keyword instead of "class" class methods are not allowed does not need "virtual" keyword but use "override" keyword. Is that right ? Who can I send this post to and ask to add the information to the Macpas mode Web page (http://wiki.freepascal.org/Mode_MacPas) and the User's manual (7.1 Free Pascal compiler modes) and the Programmer's manual (Appendix D.6 MAC mode) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problems with Debian and FP IDE
What was the error message? What was the version of FPC and Debian? cheers, Paul - Original Message - From: Andres Linares To: Free Pascal Mail List Sent: Tuesday, May 12, 2009 4:48 AM Subject: [fpc-pascal] Problems with Debian and FP IDE Hi,When I run FP IDE on Debian I get an error message. Also I cannot use F8 to debug my program. How can I fix this?thanks -- Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it! -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] heap size growing
En/na Micha Nelissen ha escrit: Luca Olivetti wrote: Seeing this thread, I used GetFPCHeapStatus and, effectively, CurrHeapSize is growing but CurrHeapUsed isn't, so apparently TJpegImage.LoadFromStream (that's what I'm using) causes heap fragmentation. Can you reproduce this in a small test program? Perhaps there is a simple fix for TJpegImage's allocation pattern. No, and I tried very hard (mainly to isolate the problem). It must be the interaction between everything that's causing the problem, not TJPegImage alone (though just removing the LoadFromStream made the memory usage stay constant). It also depends on the image (not all images caused the heap to grow). Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] heap size growing
Luca Olivetti wrote: Seeing this thread, I used GetFPCHeapStatus and, effectively, CurrHeapSize is growing but CurrHeapUsed isn't, so apparently TJpegImage.LoadFromStream (that's what I'm using) causes heap fragmentation. Can you reproduce this in a small test program? Perhaps there is a simple fix for TJpegImage's allocation pattern. Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Problems with Debian and FP IDE
Hi, When I run FP IDE on Debian I get an error message. Also I cannot use F8 to debug my program. How can I fix this? thanks _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to use OpenGL 2.0 features
On Mon, 11 May 2009 10:12:11 +0400 dmitry boyarintsev wrote: > Only new version function are loaded on demand. This makes the binding > very *flexible*. > Because some obsolete functions might be removed in future OpenGL versions. OpenGL 3.x also deprecates many OpenGL 1.1 functions (for example immediate mode). OpenGL 1.1 is not loaded (as there is no need even on windows) so how does the 'flexibility' help us there? I also fail to see how loading of OpenGL 1.5 for example helps, if only two of 1.5s functions are deprecated. The bindings have to be changed nonetheless. The bindings where not created with flexibility in mind. It looks more like somebody just ported the Delphi bindings without really knowing what he is doing. No offense meant here just an observation. S. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to use OpenGL 2.0 features
On Mon, 11 May 2009 03:09:40 +0200 Michalis Kamburelis wrote: > Change this e.g. to follow each > Result := Load_GL_version_1_5; > by > if not Result then Exit; > Result := FALSE; Instead I moved the Load_GL_version_x_x calls to the end of the functions. Replacing Result:=TRUE; > ... to make sure that Load_GL_version_2_0 returns true *only* if both > Load_GL_version_1_5 succeeded *and* all functions on level 2.0 succeeded. You are absolutely correct. S. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to use OpenGL 2.0 features
On Mon, 11 May 2009 10:12:11 +0400 dmitry boyarintsev wrote: > The binding treats OpenGL versions in the same way as any other extension. Which isn't a good thing IMHO. The artificial limitation that you have to load higher version functions like extensions is just because M$ did and does not want to support OpenGL properly. As stated neither Linux nor OS X need this. So the bindings actually cripple the functionality of not M$ users. In C/C++ you can just include gl.h and glext.h and are done with it (as long as you don't work under Windoze). > Only new version function are loaded on demand. > This makes the binding very *flexible*. > Because some obsolete functions might be removed in future OpenGL versions. OpenGL up to 2.1 is fully backward compatible. Although there does not seem to be a requirement to do so, I don't know of any extension that ever got removed from the driver. Doing so would break older programs relying on the functionality, which no vendor likes to do. It is just not good when old games don't work anymore just because you updated your driver from 1.5 to 2.0. > Instead of changing the binding, why don't you just declare a single > utility function for your needs? > I don't want any workarounds. I want a clean and sane set of bindings that is not a major PITA to use. I don't have any need to switch to FPCs bindings. I don't support Windows and I have my own bindings where I don't even have to load extensions. I just check the string if the functionality is there and if so use it. I was just thinking that it would be a better idea to not do double work and therefor I am in the process of testing the FPC bindings. Unfortunately FPCs bindings are based on Delphi ones and all the limitations and annoyances I talk about originate from this fact. If you are a Windows user you will not notice much trouble as under Windows it is the normal way of using OpenGL (in any programming language). If you are not a windows user it is a major PITA. > Chaning the binding might also break some existing code written with using it. May be. If this is a problem and nothing shall be changed then I am just wasting my time here. Tell me and I am back to my own stuff. S. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] heap size growing
On 11 May 2009, at 12:00, Luca Olivetti wrote: Is there any undesirable side effect due to the use of cmem? It's usually slower if you perform many allocations and deallocations of small blocks. Other than that, no. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] heap size growing
En/na Jonas Maebe ha escrit:
[sorry to revive an old thread, but I'm having a similar problem and I
prefer to follow-up than to start a new thread. Since it's old, I'm
quoting it without trimming]
On 14 Jan 2009, at 13:02, Burkhard Carstens wrote:
Am Mittwoch, 14. Januar 2009 04:50 schrieb Seth Grover:
I had the same problem. You could try to enable "BESTMATCH" in the heap
manager by either compiling the rtl with "-dBESTMATCH" or changing
"{ define BESTMATCH}" to "{$define BESTMATCH}" in rtl/inc/heap.inc and
see if the situation improves. For me, it improved but didn't solve the
problem completely. I had to create my own mem pool for some frequently
allocated/freed structures.
In the general/average case, "best fit" produces slightly worse results
than "first fit" (which is the default). The reason is that's you're
more likely to end up with a bunch of unusably small blocks over time
than with first fit (there are of course usage patterns in which this
does not hold).
IIRC this was caused by usage pattern like this:
* free a huge chunk (a) of mem -> chunk is returned to heap manager
* allocate small chunk -> this results in heap manager splitting chunk
(a) to return the small piece (b)
* now allocating again a huge chunk (same size as (a)) results in heap
manager requesting a new chunk of mem from OS because the remainder of
(a)-(b) is not sufficient.
.. well, in short: memory fragmentation
With BESTMATCH enabled, the heap manager tries harder to find a small
free block for (b) before splitting (a) ..
However, I am not completely sure if this is the same problem ..
It probably is.
it
could also be caused by the reworked heap manager, which now handles
mem allocation per thread (if that's allready in 2.2.2 ??) ..
No, it is not. It will only be released in 2.4.0. And it will not solve
the problem, unless the differently-sized memory blocks are only
allocated in different threads.
You can also try using your platform's libc memory manager to see
whether it deals better with this usage pattern (add "uses cmem" to the
uses clause of your main program). Or, as mentioned above, use your own
memory pool (like the default memory manager already does for small
allocations).
I'm having a similar problem with the heap: I'm capturing an mjpeg
stream from an ip camera (well, actually I'm capturing 50 streams from
50 cameras) using TJpegImage (from the LCL).
The problem is that memory usage grows, slowly but steadily, and after a
while (1 day, 1 week, it depends) the program starts failing (with "No
buffer space available").
Seeing this thread, I used GetFPCHeapStatus and, effectively,
CurrHeapSize is growing but CurrHeapUsed isn't, so apparently
TJpegImage.LoadFromStream (that's what I'm using) causes heap fragmentation.
FYI, using cmem (this program is running under windows xp) overall
memory usage stays constant (though I haven't tried it yet in the field).
Is there any undesirable side effect due to the use of cmem?
Bye
--
Luca
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
