Re: [fpc-devel] freepascal.org HTTP and SVN access
Gabor Boros пишет: Hi, I have same problem too. I can access http://www.freepascal.org from home but not from the office. If try ping www.freepascal.org at the office i get response. But the http://62.166.198.202 not working. At home everything works. Sometimes I have the same problem. -- Best Regards, Evgeniy ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Summer of Code 2008
2008/3/7, Ales Katona [EMAIL PROTECTED]: I've got a goole mail I've got google mail too. But I just developed sdlgraph (still in trunc, always want to finish, but lack of time...). -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Summer of Code 2008
2008/3/8, Felipe Monteiro de Carvalho [EMAIL PROTECTED]: On Sat, Mar 8, 2008 at 9:01 AM, Paul Ishenin [EMAIL PROTECTED] wrote: ow... I have not thought to be a mentor :) They'll pay you 500 bucks if approved =) Just kidding (althougth they really pay). I needed to fill some names as mentors just to cause a good impression. If we are approved (unlikely), then we can do a better arrangement on the list of mentors. If they apply me as a student (KDE) I won't be able to be a mentor. But if I'm not succeeded I will be able to maintain any project wich doesn't require any special abilities (as I told I just trunced sdlgraph). Also if I won't be a GSoC student I will read Red Dragon book 2, so will need to practice :) -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Summer of Code 2008
2008/3/8, Felipe Monteiro de Carvalho [EMAIL PROTECTED]: On Sat, Mar 8, 2008 at 1:03 PM, Evgeniy Ivanov [EMAIL PROTECTED] wrote: If they apply me as a student (KDE) I won't be able to be a mentor. I didn't add you as a mentor. Oh, it's good, because I'm not developer. I was scared by previous letters (about mentoring) :) -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Happy New Year!
Happy New Year! Good luck in every of your deals! I wish you a good vocation with fine relaxation to be strong all the year! Write only non-bug code without deadlocks and segfaults! http://drop.io/s70gl7w# P.S. Sorry if it's not the first message. I'm not sure previous were successful (there was an attachment) -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
2007/8/26, Jonas Maebe [EMAIL PROTECTED]: Done. You can see it at http://svn.freepascal.org/svn/fpc/trunk/packages/extra/graph/ Please base your further development on the version of sdlgraph.pas you can find there, as I made some minor changes (added missing InternalDriverName constant, and some Mac OS X changes). Thanks a lot! Nice. I will try to do it stable in September. I think that I know the way to not implement sdlcrt and use the current crt unit. But it needs thread and pipe, I never used them, but it won't be complicated. 2007/8/26, Jonas Maebe [EMAIL PROTECTED]: Also, Michael, could you maybe create an svn login for Evgeniy with write access to the packages/extra/graph/ directory? It would be pretty good. I will be able to commit without troubling anybody. -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
2007/8/22, Jonas Maebe [EMAIL PROTECTED]: On 22 Aug 2007, at 20:59, Evgeniy Ivanov wrote: I guess the problem is that you blit the entire screen after every drawing operation. It will be faster when drawing lines at a time, but still slow. In theory, the flipping could/should be done from a separate thread, which only does the flipping once per vertical refresh of the monitor. I don't know whether SDL provides access to this information though. Thanks a lot! Now I understand how I may speed up it. There're no flipping once per vertical refresh, but there is flipping of needed rect (not entire screen). I will try to use it with separate thread. -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
2007/8/22, Jonas Maebe [EMAIL PROTECTED]: the flipping could/should be done from a separate thread, What should I use: ThreadVar from fpc or SDL_Thread? Both are cross-platform. -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
Hi! I've changed licence (the top of the file) as you've told. And fixed speed of Bar3d and other routines (added timer for flipping - not best, but it works). You may test it if you want :) http://itmo.vingrad.ru/files/sdlgraph/sdlgraph.pas http://itmo.vingrad.ru/files/sdlgraph/test.pas http://itmo.vingrad.ru/files/sdlgraph/build.sh http://itmo.vingrad.ru/files/sdlgraph/sdlgraph.ppu May you add it to your cvs (to the fpc project)? -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
2007/8/22, Jonas Maebe [EMAIL PROTECTED]: Congratulations! Just one note: please do not make it GPL, because that would mean anyone using that unit would have to make their program also GPL. Instead, please change the text at the top to something like this: *** Copyright (c) 2007 Evgeniy Ivanov This file implements the sdl support for the graph unit See the file COPYING.FPC, included in this distribution, for details about the copyright. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. *** You're of course free to also include your email address and a link to your website, like you have done in the version you put on the web. Ok, no problem. I will do it in the way you have told. I'm waiting when they will register the project (there is sdlgraph on sf.net, but it's old and empty, they need to check it). I need to do some hooks to speed up the module (Bar3d). But I have network problems and my dial up doesn't me allow to google much (I don't know how to hook functions/procedures). Bar3D is indeed one of the few routines which cannot be hooked currently. As long as you hook the line drawing it should be plenty fast though. No, I tryed. It is in the test.pas. It works very very slow. I may patch graph.inc, graphh.inc and modes.inc to add ability to hook such routines (Shapes/Lines) like Bar3D. It will not take any effect on currently written modules (Current Bad3d may be Bar3Ddefault and to be added to Bar3D proc if it's not assigned). Of course if you will approve it (I don't see any reason to make it just for my needs). Also readln function need to be hooked too (It works when alt+tab to console from which app was executed). This will indeed be difficult. It's probably best to create a generic wincrt-like unit (sdlcrt?) which can be used together with the sdl graph unit. Full input/output support can also be added to it over time, similarly to how the regular crt unit also takes over all input/ output. Nice idea. I may do it. I think that the best way for this is to use SDL-terminal (I have never used it, but it must be pretty nice). But it isn't in JEDI-SDL (so, it must be wrapped to .pp). But I prefer to use readln to give user a chance to see the screen created by graph (and close after any key was pressed). There are many old programmes with it. The + of SDLgraph is that it may be used with old code and you may add any JEDI-SDL routine (timer or SDL_mixer and so on) using global screen variable. Sorry for my poor English, but I think you will get the idea. If you remember we were talking about it in April (or May). I've created sf.net project, but it is in Processing Queue. So, here are the temp links: Unit: http://itmo.vingrad.ru/files/sdlgraph.pas.txt Example: http://itmo.vingrad.ru/files/test.pas.txt Build script (you need to fix paths): http://itmo.vingrad.ru/files/build.sh.txt Very nice! Thanks a lot! :) P.S. Thanks you for your answers about the graph modules and to authers of graph*.inc and *Go32* module - the code is very nice. Carl will be happy to hear this :) No, it doesn't do the same: the lowNewMode..highNewMode case uses IntcurrentNewDriver, while the else case uses IntcurrentDriver. It's to transparently support both the old and new mode selection logic. TODO: in modes.inc 181: Overloaded procedure initmode(var mode: TModeInfo); isn't used. I've looked only in modes.inc, so it may be my mistake It is used by all platform-specific graph units (also by your sdlgraph unit) to initialise a new mode. Thanks, sorry my inattention. TODO: Go32 mistake 2740: modenumber is m1024x768x32k, but initmode = Init640x480x32k } Fixed, thanks. You're welcome :) -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
2007/8/22, Jonas Maebe [EMAIL PROTECTED]: It is because you do not redirect the line drawing directly to SDL, but instead use the default line drawing routines. Those are indeed very slow, because they call a procedural variable (directputpixel) for each pixel which has to be drawn). And directputpixel then calls through to SDL, which every time must recalculate the pixel position on the screen (instead of just adding 1 to the horizontal or vertical coordinate in case of horizontal/vertical line drawing). Hm... I really forgot to hook Line (but wrote the routine). But HLine and VLine are hooked and the speed problem is in the Bar function, it has such code: for y:=y1 to y2 do Hline(x1,x2,y); HLine is hooked and works quickly. But it locks the screen every time it is executed (but calls DirectPutPixel without locking (that's why it is fast): procedure sdlgraph_HLine(x,x2,y: smallint); var temp:DefPixelProc; begin temp:=DirectPutPixel; DirectPutPixel:[EMAIL PROTECTED]; // It doesn't lock the screen as sdlgraph_DirectPutPixel. It's quick. Slock; HLineDefault(x,x2,y); Sulock; DirectPutPixel:=temp; end; If to do the same (using nonBuf_HLine) with Bar3D it would be very fast. -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
2007/8/22, Jonas Maebe [EMAIL PROTECTED]: On 22 Aug 2007, at 18:24, Evgeniy Ivanov wrote: 2007/8/22, Jonas Maebe [EMAIL PROTECTED]: It is because you do not redirect the line drawing directly to SDL, but instead use the default line drawing routines. Those are indeed very slow, because they call a procedural variable (directputpixel) for each pixel which has to be drawn). And directputpixel then calls through to SDL, which every time must recalculate the pixel position on the screen (instead of just adding 1 to the horizontal or vertical coordinate in case of horizontal/vertical line drawing). Hm... I really forgot to hook Line (but wrote the routine). But HLine and VLine are hooked and the speed problem is in the Bar function, it has such code: for y:=y1 to y2 do Hline(x1,x2,y); HLine is hooked and works quickly. But it locks the screen every time it is executed (but calls DirectPutPixel without locking (that's why it is fast): procedure sdlgraph_HLine(x,x2,y: smallint); var temp:DefPixelProc; begin temp:=DirectPutPixel; DirectPutPixel:[EMAIL PROTECTED]; // It doesn't lock the screen as sdlgraph_DirectPutPixel. It's quick. No, it is still slow. You indeed do not have locking overhead, but you are still calling nonBuf_DirectPutPixel via a procvar for each pixel which has to be drawn (from hlinedefault). That is still very slow. Hm... I've tried such thing: procedure sdlgraph_HLine(x,x2,y: smallint); begin SDL_DrawLine(screen,X,y,x2,y,255); SDL_Flip(screen); end; The same. I will try to find the true way, but I'm not sure that it can be without locking overhead. I reimplement Bar3d with adding locking - very quick. I think it is the fastest HLine implementation Bar3D's speed is fine if you have a fast hline implementation (like for e.g. go32v2 in most modes). It's asm, it should be faster than pascal code. -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] sdlgraph, pre-alpha
Hi! I did it. And working with its implementation.
I need to do some hooks to speed up the module (Bar3d). But I have network
problems and my dial up doesn't me allow to google much (I don't know how to
hook functions/procedures).
Also readln function need to be hooked too (It works when alt+tab to console
from which app was executed).
And I didn't implement color conversion from pascal constants to SDL colors.
It's temporary 1 color (255).
If you remember we were talking about it in April (or May). I've created
sf.net project, but it is in Processing Queue. So, here are the temp links:
Unit: http://itmo.vingrad.ru/files/sdlgraph.pas.txt
Example: http://itmo.vingrad.ru/files/test.pas.txt
Build script (you need to fix paths):
http://itmo.vingrad.ru/files/build.sh.txt
P.S. Thanks you for your answers about the graph modules and to authers of
graph*.inc and *Go32* module - the code is very nice. Also I find some
things I want you to have a look. They're in TODO of the sdlgraph.pas:
{Graph inc and pp notes
TODO: in modes.inc 421-430. Maybe delete lowNewMode..highNewMode case? else
section does the same! But with this section code it is easier to read the
code
TODO: in modes.inc 181: Overloaded procedure initmode(var mode: TModeInfo);
isn't used. I've looked only in modes.inc, so it may be my mistake
TODO: Go32 mistake 2740: modenumber is m1024x768x32k, but initmode =
Init640x480x32k
}
Best Regards, E.I.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] graphh.inc - few questions.
Hi!
I'm doing sdlgraph - so I put my self to packages/base/graph.
I can't understand the method (where are they used?) using routines in
TModeInfo (from graphh.inc).
In custom graph modules it's used in such way:
mode.PutPixel:={$ifdef [EMAIL PROTECTED];
But in windows and go32v2 there are no any routines for PutPixel from
interface.
I mean someting like
PutPixel := @custom_PutPixel; (PutPixel :=
@libvga_PutPixelProc; - in the unix graph.pp).
So, if there are no such assignations (sorry, I don't know the right word)
PutPixelDefault from graph.inc will be used...
And it is:
procedure PutPixelDefault(X,Y: smallint; Color: Word);
begin
Writeln(stderr,'Error: Not in graphics mode (use InitGraph and test
GraphResult afterwards)');
Halt(1);
end;
But windows module works...
I will thankful for answers.
I may rewrite somethings, but as I have undersood - the best way is to use
graph.inc and graphh.inc.
--
E.I.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] sdlgraph
Hi! I have worked a bit with implementation. But just a bit... I'm not able to do anything before middle of June, but then I will do it. So, please, keep it for me. -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] problem with linking C code used SDL in Windows
Hi! I know that it is not a place to ask such things... But I need to
finish programme this morning and it's much better with panel written in C.
When I'm linking pas code links normally, but my c_code.o which is using
the same SDL libs as pascal code don't want to link. I have errors in SDL
calls and also in exit and printf.
fpc -Fu./SDL -Fl./SDL -Fl./lib (here is my gcc lib)
...
{$linklib mingw32} doesn't work (as c and gcc). I don't know what to do.
Without C code everything is allright. In linux C code works with fpc. But
I need to build it for windows.
Thanks.
--
Best regards
E.I.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] uses windows in sdl.pas unit - problems
I use srl.pas unit from JEDI-SDL. When I'm using threads it doesn't work: sdl.pas: . uses windows; const SDLLibName = 'SDL.dll'; Circular unit referencebetween sdl and windows. What's wrong? Is it a bug? -- E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] some bug in parser
Hi! I've found an interesting bug. It makes an error while checking
for errors (found . after end, but ; expected). And it is
difficult to find it in the big part of code.
I decided to post here, becouse I've found it is very interesting.
Here is a simple example:
main.pas:
==
program buggy;
procedure some_act1;
procedure some_act2;
var
variable:Integer;
procedure global_act;
var
global:Integer;
begin
writeln('Global');
some_act1;
some_act2;
end;
procedure some_act1;
begin
writeln('Act1');
end;
procedure some_act2;
begin
writeln('Act2');
end;
var
s:string;
begin
s:='Main!';
writeln(s);
end.
==
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] some bug in parser
2007/4/5, Florian Klaempfl [EMAIL PROTECTED]: Evgeniy Ivanov schrieb: Hi! I've found an interesting bug. It makes an error while checking for errors (found . after end, but ; expected). And it is difficult to find it in the big part of code. I decided to post here, becouse I've found it is very interesting. It's not a bug, the compiler thinks you want to declare nested procedures? Really. Sorry, I forgot about forward. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] logger fpc
Hi! Some time ago I've written about logger. And nobody have answered that there is a log system for fpc. What do you mean about it? For old code... It's difficult to say any thing. But for future... P.S. It's just suggestion for smb's implementation or for my future little fpc task (after sdlgraph). -- Evgeniy Ivanov (aka powerfox). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Is there any logger in fpc?
Hi! How may I do my logging for fpc package? There is not bad logger in the JEDI-SDL, but is there any fpc native logger? Also sdlgraph will be use some headers from JEDI, so I don't see any reasons to not use sdl/logger.pas. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is there any logger in fpc?
On Mon, 26 Mar 2007 19:03:26 +0400, Michael Van Canneyt [EMAIL PROTECTED] wrote: On Mon, 26 Mar 2007, Evgeniy Ivanov wrote: Hi! How may I do my logging for fpc package? There is not bad logger in the JEDI-SDL, but is there any fpc native logger? Also sdlgraph will be use some headers from JEDI, so I don't see any reasons to not use sdl/logger.pas. There is the eventlog component. It's cross-platform. You can install it in lazarus as well. And may I use it to develop fpc module? Lazarus is not in main package as fahr as I know. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is there any logger in fpc?
On Mon, 26 Mar 2007 19:40:24 +0400, Daniël Mantione [EMAIL PROTECTED] wrote: Op Mon, 26 Mar 2007, schreef Michael Van Canneyt: On Mon, 26 Mar 2007, Evgeniy Ivanov wrote: On Mon, 26 Mar 2007 19:03:26 +0400, Michael Van Canneyt [EMAIL PROTECTED] wrote: On Mon, 26 Mar 2007, Evgeniy Ivanov wrote: Hi! How may I do my logging for fpc package? There is not bad logger in the JEDI-SDL, but is there any fpc native logger? Also sdlgraph will be use some headers from JEDI, so I don't see any reasons to not use sdl/logger.pas. There is the eventlog component. It's cross-platform. You can install it in lazarus as well. And may I use it to develop fpc module? Lazarus is not in main package as fahr as I know. You may. It's in the FCL, it needs no GUI. Yes and no, this is about the graph unit, for which an FCL dependency might be less suited. Daniël Thanks. I will use sdl/logger. It's used in JEDI-SDL examples (I never mind that they are buggy, is it only code demonstration? I've found some bugs (in every demo), should I make a bugreport? Or correct code and send to JEDI-SDL (it is not the only bugs, so the situation won't be improved). -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] porting from fpc to tp7
Hi! I'm doing my tasks with fpc in linux, but in the university we have only tp, and there are several problems with bringing binaries. I have such code to have something like dynamic arrays: procedure add_mem(var P: dynamic_array_ptr; var cur_size:Integer); var i:Integer; buff_ptr:dynamic_array_ptr; begin getmem(buff_ptr,cur_size*sizeof(BusStation) ); for i:=1 to cur_size do buff_ptr^[i] := P^[i]; freemem(P); cur_size:=cur_size+buf_count; getmem(P,cur_size*sizeof(BusStation) ); for i:=1 to (cur_size-buf_count) do P^[i] := buff_ptr^[i]; freemem(buff_ptr); cur_size:=cur_size+buf_count; end; In fpc it works. But in tp my programme sometimes starts from last time and have a part of last data and some garbage (not text). Why does it work in fpc, but doesn't in tp? I see the only way to rewrite code, but I want to know why. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] porting from fpc to tp7
On Sat, 24 Mar 2007 13:05:54 +0300, Daniël Mantione [EMAIL PROTECTED] wrote: procedure add_mem(var P: dynamic_array_ptr; var cur_size:Integer); var i:Integer; buff_ptr:dynamic_array_ptr; begin getmem(buff_ptr,cur_size*sizeof(BusStation) ); for i:=1 to cur_size do buff_ptr^[i] := P^[i]; freemem(P); cur_size:=cur_size+buf_count; getmem(P,cur_size*sizeof(BusStation) ); for i:=1 to (cur_size-buf_count) do P^[i] := buff_ptr^[i]; freemem(buff_ptr); cur_size:=cur_size+buf_count; end; Why do you increase cur_size two times? At the end of the procedure cur_size is larger than the buffer is. Ou, surely. But it is new bug. When I used tp there was'n second increase. Also buf_count value is 10 and I have tried to add only 5 elements. After second startup the problems have begun. Further, you want to use move instead of a for loop, since in TP the speed difference is even larger than in FP. Sorry, but I didn't understand what you ment exactly. You ment to use ptr_buf = P and then getmem(P) and for loop? -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] porting from fpc to tp7
On Sat, 24 Mar 2007 13:35:24 +0300, Daniël Mantione [EMAIL PROTECTED] wrote: procedure add_mem(var P: dynamic_array_ptr; var cur_size:Integer); var i:Integer; buff_ptr:dynamic_array_ptr; begin getmem(buff_ptr,cur_size*sizeof(BusStation) ); for i:=1 to cur_size do buff_ptr^[i] := P^[i]; freemem(P); cur_size:=cur_size+buf_count; getmem(P,cur_size*sizeof(BusStation) ); for i:=1 to (cur_size-buf_count) do P^[i] := buff_ptr^[i]; freemem(buff_ptr); cur_size:=cur_size+buf_count; end; Why do you increase cur_size two times? At the end of the procedure cur_size is larger than the buffer is. Ou, surely. But it is new bug. When I used tp there was'n second increase. Also buf_count value is 10 and I have tried to add only 5 elements. After second startup the problems have begun. Well, all I can say is check your code securely. The basic idea is good, so it is likely the implementation. I will try. May be there is some problem with index and memory in tp and dos (dos emulation in NT) is unsecure. Further, you want to use move instead of a for loop, since in TP the speed difference is even larger than in FP. Sorry, but I didn't understand what you ment exactly. You ment to use ptr_buf = P and then getmem(P) and for loop? Instead of: for i:=1 to cur_size do buff_ptr^[i] := P^[i]; ... do: move(p^[1],buff_ptr^[1],(cur_size-1)*sizeof(p^); Thanks, I will try. Also, is your array really 1-based? Hm... I didn't understand. I have such definitions of my array: type dynamic_array = array[1..buf_count] of BusStation; //BusStation is record with 4 strings dynamic_array_ptr = ^dynamic_array; var list:dynamic_array_ptr; // it's my dynamic array with its size counter list_count:Integer; ... // How I use it: for i:=1 to num_of_strings do begin if i list_count then add_mem(list,list_count); I herd that there were problems with dos games: sometimes they started not from the beginning, but from last time ending. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] porting from fpc to tp7
On Sat, 24 Mar 2007 15:52:20 +0300, Daniël Mantione
[EMAIL PROTECTED] wrote:
Note that in Dos, the memory at program start is in random state; in
other
words, if your program contains bugs like uninitialized memory, it can
have different behaviour between runs.
It is the thing that I was talking about (dos games problem). So you
answered on my question. The differences between fpc and tp is in memory
allocation. TP gets random state, and it may be unclean from last time,
and fpc returns mem to OS (and it's clean) and on the next startup I have
clean memory. I have somewhere some extras pointers and in fpc they point
to free mem ('' strings) so I don't see the bad result of printing and in
tp I see them.
Daniël, thank you for help! Now I understood the root of the problem.
This is okay if everything is 1-based. If it is 0-based, you need to be
carefull in getmem to allocate memory for the 0th element too.
I will consider it.
--
Best regards
E.I.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Mon, 12 Mar 2007 11:04:00 +0300, Micha Nelissen [EMAIL PROTECTED] wrote: Evgeniy Ivanov wrote: released under the LGPL. However the relevant LGPL provisions do not address all possible ways in which code released under the MPL and code released under the LGPL could be combined to form a larger work. In particular, when linking Mozilla source files directly into a library released under the LGPL, e.g., to extend the functionality of that This is why we have the exception. Sorry, I don't understand what you mean. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Mon, 12 Mar 2007 19:42:36 +0300, Micha Nelissen [EMAIL PROTECTED] wrote: Evgeniy Ivanov wrote: library released under the LGPL, e.g., to extend the functionality of that This is why we have the exception. Sorry, I don't understand what you mean. For example, look at the RTL license: http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/rtl/COPYING.FPC?rev=1view=markup It specifies the exception. Lazarus' LCL has the same exception in COPYING.modifiedLGPL IIRC. Sorry, but we still don't understand each other. I was talking not about first part of sentence (you mark it red), but about ending: the effect of the LGPL terms, and any potential license incompatibilities that might arise, appear to be similar to those associated with the GPL.) And we were talking about linking MPL code to fpc, but not about fpc to some MPL. Daniël have written to Dominique, so we are waiting the answer. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Sat, 10 Mar 2007 23:12:32 +0300, Jonas Maebe [EMAIL PROTECTED] wrote: Are the licensing issues sorted out for it? If not, there may be a problem since standard MPL is incompatible with GPL (so people can't release GPL programs using those bindings). I don't know about the LGPL (and how our static linking exception affects this). As far as I know if somebody uses MPL the product based on MPL must be only MPL. MPL is incompatible with LGPL too. http://www.mozilla.org/MPL/relicensing-faq.html There is a way to use a triple license. But as I understood we need to make all FPC code licenced as MPL/LGPL because one module uses MPL code. It is not the way. So, if we want to have sdlgraph there are 3 ways: - rewrite needed SDL headers - write SDL initialization and few base function for SDL in C and then make headers for pascal - speak with JEDI-SDL developer. But I don't know if he relized it under MPL has he right to give such permission -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] re: using generated obj files with vs or gcc in fpc?
On Sun, 11 Mar 2007 20:17:49 +0300, Roozbeh GHolizadeh [EMAIL PROTECTED] wrote: The problem is the name mangling. Try to declare it like: function toupper(ch : integer):integer;cdecl;external name 'toupper'; ... if the external name is 'toupper'. It might also be '_toupper'. You = can check this with objdump. Dani=EBl Well actually my problem is c object files use toupper function and i want to declare it in my pascal file. (i know it is very easy to being implemented in c..but now just for curusity.) so declaring external is reverse of what i want to do. I also tried with _toupper.didnt work,although i turned off underscoring of exporting function in c compiler. also tobjdump says unknown file.i cant dump c compiler generated .obj files. I didn't read any mails before this, but I have some experience with C obj. files (.o generated with gcc -- fpc). I don't remember what I've been doing a half year ago (the way is not like today), but smth was with _NAME. I think it is gpc style. About true method you may read in ftp://ftp.freepascal.org/pub/fpc/docs-pdf/CinFreePascal.pdf And I saw some information in fpc docs. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Mon, 12 Mar 2007 00:11:06 +0300, Marco van de Voort [EMAIL PROTECTED] wrote: Are the licensing issues sorted out for it? If not, there may be a problem since standard MPL is incompatible with GPL (so people can't release GPL programs using those bindings). I don't know about the LGPL (and how our static linking exception affects this). As far as I know if somebody uses MPL the product based on MPL must be only MPL. MPL is incompatible with LGPL too. http://www.mozilla.org/MPL/relicensing-faq.html Where exactly? I see perceived incompability in the header, but afaik FSF only names GPL. http://www.mozilla.org/MPL/relicensing-faq.html#why-relicensing === (The LGPL allows code released under LGPL terms to be combined in certain specified ways with code released under non-LGPL terms, as for example when releasing an application using a library consisting of code released under the LGPL. However the relevant LGPL provisions do not address all possible ways in which code released under the MPL and code released under the LGPL could be combined to form a larger work. In particular, when linking Mozilla source files directly into a library released under the LGPL, e.g., to extend the functionality of that library, the effect of the LGPL terms, and any potential license incompatibilities that might arise, appear to be similar to those associated with the GPL.) === -- Best regards E.I.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Sat, 10 Mar 2007 00:09:32 +0300, Jonas Maebe [EMAIL PROTECTED] wrote: Daniel was talking about staticallu linking the interface, not the libraries themselves. Since we do not distribute the libraries, what license they are distributed under is irrelevant. The interface can be used to both link the dynamic and static library versions of SDL. OK, the conclusion is to implement sdlgraph in pascal on top of JEDI-SDL. So, I will work with it. I will finish my study activities (I was ill 2 weeks so this week (after Sunday) I will clear my debts) and then will implement it. Daniël was talking about 2.2 FPC release, what is date in team's plans? -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Sat, 10 Mar 2007 13:40:31 +0300, Aleš Katona [EMAIL PROTECTED] wrote: Just so you know, I just added modified SDL units from JEDI-SDL into packages/extra but only to trunk (2.3.1). I think it's best you use those and not copy your own, but we might need to merge into 2.2 later then (there's a freeze in effect now I think?) Do you mean http://svn.freepascal.org/svn/fpc/trunk/packages/extra/sdl/ ? Yes, I will use this, as team wish. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] graph module
Hello! I tried to use freepascal' graph module based on svgalib but from my point of view it's not comfortable: I need root prevelege or to remember what to do with *ids (uid and so on). Also I have a problems with konsole after starting programm with graph module: there is an error with input and I get much garbage inside it. I realize a test module with a few graph functions (for my needs) via SDLlib. I wrote it on C, but some code may be written on pascal. It's not bad and fully compotable with traditional graph module code. I have some problems, but I will solve them (SDL don't want to return 'keydowns'). If you like it I may realize a full and normal graph module. Test programm need to be started in the terminal (console). You need to push the key only after setting up the terminal window active. I start in in konsole. If you start it from GUI in will run and then the window will close its self. In the tar there is linux binary. Here the test ptogramm and simple graph module: http://itmo.vingrad.ru/testGraph.tar.bz2 -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Fri, 09 Mar 2007 15:46:34 +0300, Tomas Hajny [EMAIL PROTECTED] wrote: Hi Tomas, Hi Evgeniy, I'd say that having Graph built on top of SDL would be quite useful. I agree with Daniel that implementation in Pascal would be much better choice - among others, one could use it on various platforms without having to compile C libraries on those platforms (SDL is available on quite a few of them). I believe that Daniel intended to rewrite Graph to use a driver system (similarly to what we use for threading, keyboard/video/mouse units, heap management etc.), which would allow people to use the same Graph functionalities supported by different back-ends and choose either at compile time or possibly even at run time which back-end should be used (as an example, svgalib could be used as backup option for systems not running X11, etc.). I personally wouldn't necessarily wait for PTCPas based implementation - if Daniel wants to use the driver system, it should be enough to agree on the driver interface, anything else can be done completely independently. As far as I've understood Daniel is working only on driver system, isn't it? He doesn't touch such things like line and circle for example (It should be based on PutPixel as I thing) but he is implementing only the things that using back-end libs (like PTCPas), in my example such thing is PutPixel. Am I right? If you implement Graph as a completely independent implementation, you could add it to contributed units (see our WWW pages), so anybody else can use it. If you do it using the driver system and want to contribute this work to FPC, I can imagine it could even become part of our SVN repository and future official FPC releases under some conditions (however, this last sentence is my personal view, not necessarily shared by the whole FPC core team). Tomas It would be great for me to realize a small small part of FPC. And I find that it is much more useful to build a piece for something than create own little project. I will do it using driver system with pleasure, but you've written that it is only your own opinion. And there are several questions about libraries and programme languages. I agree that the most part must be in pascal, but I think that such things like SDL initialization, loading images need to be implemented in C (if use native SDL headers). From my point of view usage of C parts is less dangerous then usage converters and other wrappers stuff. I have no experience with JEDI_SDL, but the last release was 2 years ago... And it's only the headers, so it uses native SDL libraries. I'm just beginner in software development so, please, be patient. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Fri, 09 Mar 2007 18:08:35 +0300, Jonas Maebe [EMAIL PROTECTED] wrote: The graph unit is pretty generic in this respect. You indeed only need to implement putpixel, getpixel, graphics mode detection, setting a graphic mode, setting and getting colour palette entries for indexed modes, and closing down the graphic system again. But it's perfectly possible to also intercept line, elipse, rectangle etc and to implement them directly in the driver. So, I may implement only putpixel and etc, but then if I wish I may implement line and othe stuff inside my part of code (or somewhere)? It's the way the whole graphics unit is designed to work. Note that driver is just used in the figurative sense here. In practice, you simply write your code and set some procedure variables inside the graph unit so it calls your code. So will be there different ways of using different back-ends directly from graph unit like to have some variables like sdlgraph=1? If you write your code in C, then you need to write Pascal headers for your code. In the end, you will always have to convert some headers. That's true, and it's the case for most libraries out there. Converting all libraries from C to Pascal rather than the headers would be a huge and never-ending duplication of effort. There's nothing wrong with using Pascal interfaces for libraries which are written in another language. So if I will implement it in C with pascal headers it have a chance to be a part of freepascal? -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Fri, 09 Mar 2007 18:36:40 +0300, Jonas Maebe [EMAIL PROTECTED] wrote: See e.g. the graph.pp and ggigraph.pp files at http://svn.freepascal.org/svn/fpc/trunk/packages/base/graph/unix/ The include files are in http://svn.freepascal.org/svn/fpc/trunk/packages/base/graph/inc/ Thanks, I wanted to ask about it but you prevented my question. Very little. We do this to reuse work done and maintained by others, not for new code which we support and maintain (since we ourselves are Pascal programmers, not C programmers). I meant that I want to implement dangerous parts in C (driver core) and other things in pascal. But other developers are right that it is bad idea to write on C for pascal project. On Fri, 09 Mar 2007 18:39:10 +0300, Daniël Mantione [EMAIL PROTECTED] wrote: Well, Graph maintenance is more than welcome. I will try to work in this way. It is interesting. Many people @ Pascal Game Development. Domique Louis (Savage) is also still maintaining it. Writing all the imports yourself seems a bit like reinventing the wheel. Reinventing the wheel is to write all SDL imports, for graph I need only few. So you think that it is not bad to use JEDI SDL instead writing some initialization code on C and make pascal headers for it? I haven't used JEDI SDL before but it is beta. I need your advise. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Fri, 09 Mar 2007 21:07:55 +0300, Daniël Mantione [EMAIL PROTECTED] wrote: This might make sense if we don't have somebody who'd maintain the full headers, whereas maintaining just a highly limited set needed for sdlgraph purposes might be still acceptable (possibly just copied from the existing headers if the licence for those headers allows it). SDL is LGPL, so is JEDI-SDL. We would need ask Dominique for permission of the FPC static linking exception to just JEDI-SDL (we do not distribute SDL itself). I don't think this will be a problem. Sorry, but you are wrong. JEDI-SDL is Mozilla Public License 1.1 (MPL 1.1). I don't know all refinements of licences, but JEDI-SDL is based on SDL libraries and they are LGPL version 2, so if we want to use JEDI-SDL headers they will bring us MPL 1.1 and it's requirements. But linking with SDL library will bring LGPL 2. If you mean static linking (ld job and static libraries) then we need permissions not from Dominique but from Sam Lantinga. As far as I know JEDI-SDL haven't its own libraries. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
