Re: [fpc-pascal] run pascal programs as scripts
On Sun, 27 Mar 2011 19:05:12 +0200 (CEST) Michael Van Canneyt wrote: > > > On Sun, 27 Mar 2011, Mattias Gaertner wrote: > > > I wrote a little tool: > > > > http://wiki.lazarus.freepascal.org/InstantFPC > > Nice job. OK to include in FPC as one of the utils ? Are there any outstanding issues? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Sat, 23 Apr 2011, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: IMHO it is the long term solution. Anything else would be madness, or minor damage control at best. Most of the more "recent" or "new" languages I know do not have generics, What do you mean, C++,C#, Java ? No, they are "old" languages too. I was more thinking in terms of PHP, Ruby, Python, Javascript (and its variations). I haven't come accross generics for these languages. Yet they are widely adopted. Ah, I don't considered those languages. At least not where any discussions about performance or efficiency apply ;_) The topic was the availability of generics. In that field, all languages are viewed. It eases some cases where that strictness hurts. There are multiple solutions for such cases, e.g. in the database world, people went for variants. I have a database with over 7000 fields, another with 3000, for neither variants are used. Maybe I misunderstand your statement. The point was about that not every relaxation of the typed regime is generic based. It is about choosing the right relaxation for the right application. .. or is your database layer entirely strong typed? If so, you might want to talk to Frank H. of GPC, he is afaik also strongly in favour of such approach. (and that is not meant in disrespectful way, though it is a bit a specialty IMHO) I don't know what you mean by 'strongly typed database layer', but the contents and type of each field is known. Elementary RDBMS and some level 3 normalization. No 'no sql' for me. They are as subjective as a one person mandated ban on generics. Even long term. Exactly, which is why the discussion was leading nowhere :-) There never was a discussion. Apparently the result was preset. You asked about my motivations, I gave them. Not the healthies of principles btw. I counted in SVN btw, 20 commits for you, 17 for me in fcl-image, though several of mine will probably mostly touch makefiles and fpmake restructures. Discarding initial design (there is no trace of that in SVN for obvious reasons), here is how I made my count: home: >cd fpc/packages/fcl-image/src/ home: >foreach f ( *.* ) foreach? svn log $f >>log foreach? end home: >grep '^r' log | sort | uniq | wc -l 69 home: >grep '^r' log | sort | uniq | grep michael |wc -l 34 home: >grep '^r' log | sort | uniq | grep marco | wc -l 14 In each case, I think I have an approach which should speed things up, and still sticks to the design principles of fpImage. I checked your code, and it throws overboard much if not all that fpImage was designed for. I'm aware that I'll probably never match what you had in speed terms, but then you made some very limiting design choices which I simply don't want in fpImage. The price of more generality is some speed loss, it is always so. I would appreciate getting the really slow images if possible. If there are still bugs in bottom-up images, I'd like to hear about them too, but they are an issue separate of the loading times issue; Probably a reader problem. As far as I know, bottom-up reading is supported for BMP. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] run pascal programs as scripts
Nice tool. 2 requests: - I would like to select the compiler. I'm typically working with the svn version of compiler but have in my PATH a stable version of the compiler. >From the sources I can see that the compiler is searched for only in the PATH. A simple solution would be to look first for the compiler in the path specified in the shebang and, if not found, then in the PATH. - I was going to ask for the possibility of passing parameters to the program. Scripts without the possiblity to pass parameters are not really usefull. And we do't want to put parameters in the program neither since it would be re-compiled everytime the parameters change. Looking at the source I figured out that the compiler parameters stop at the first parameter not starting with a "-" and passes the rest on to the program. Great,needs to be added to the documentation, but... The cache is compared to the complete script, including the shebang. So if a program parameter is changed, the program is re-compiled... The shebang is commented out but program parameters should be removed before compare. Recompiling if compiler parameters change is OK. Ludo -Message d'origine- De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de Mattias Gaertner Envoyé : samedi 23 avril 2011 19:33 À : fpc-pascal@lists.freepascal.org Objet : Re: [fpc-pascal] run pascal programs as scripts On Sun, 27 Mar 2011 19:05:12 +0200 (CEST) Michael Van Canneyt wrote: > > > On Sun, 27 Mar 2011, Mattias Gaertner wrote: > > > I wrote a little tool: > > > > http://wiki.lazarus.freepascal.org/InstantFPC > > Nice job. OK to include in FPC as one of the utils ? Are there any outstanding issues? Mattias ___ 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] run pascal programs as scripts
On Sat, 23 Apr 2011 20:27:37 +0200 "Ludo Brands" wrote: > Nice tool. > > 2 requests: > - I would like to select the compiler. I'm typically working with the svn > version of compiler but have in my PATH a stable version of the compiler. > >From the sources I can see that the compiler is searched for only in the > PATH. A simple solution would be to look first for the compiler in the path > specified in the shebang and, if not found, then in the PATH. One solution: PATH=YourDirectory:$PATH; script.pas Another solution: A parameter could be added to instantfpc to specify the compiler. > - I was going to ask for the possibility of passing parameters to the > program. Just like a normal script: script.pas param1 > Scripts without the possiblity to pass parameters are not really > usefull. Indeed, that would be total crap. > And we do't want to put parameters in the program neither since it > would be re-compiled everytime the parameters change. Looking at the source > I figured out that the compiler parameters stop at the first parameter not > starting with a "-" Yes, that parameter is the "script.pas". > and passes the rest on to the program. Great,needs to be > added to the documentation, This is is how shebang works internally. I didn't know the internals of shebang until I wrote instantfpc. That's why I think a user does not need that information. > but... The cache is compared to the complete > script, including the shebang. So if a program parameter is changed, the > program is re-compiled... The shebang is commented out but program > parameters should be removed before compare. Recompiling if compiler > parameters change is OK. The shebang contains the parameters for the compiler, not for the script. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] nested macros in C headers
Hi,
I found this:
http://pastebin.com/T4jkeE6F
in a zip file called vfp.tar.bz4 somewhere on the web, it seems not
maintained since ages but obviously it must have compiled at some time
in the past. I am tying to see whether I can hack a quick and dirty
program that is able to open an v4l device and do some simple things
and maybe grab a frame (if I can somehow manage to keep the motivation
level above the frustration level for a long enough time).
_IOR is defined as
#define _IOR(x,y,t) (IOC_OUT|((sizeof(t)&IOCPARM_MASK)<<16)|(x<<8)|y)
and in FPC I have found a *function* in kernelioctl.pp with the same
name that seems to serve the same purpose, except that it is a
function and not a macro.
And here comes the problem:
#define VIDIOCGCAP _IOR('v',1,struct video_capability)
/* Get capabilities */
obviously the following will not compile since the function cannot run
at compile time:
const
VIDIOCGCAP = _IOR(Ord('v'), 1, SizeOf(video_capability));
in the above mentioned ten years old pascal file there is the following:
//define[_IOR(][,#1,#2)][_IOC(2,ord('#0'),#1,sizeof(#2));]
const
VIDIOCGCAP = _IOR(v,1,video_capability);
The first line looks like it is meant to be understood by some kind of
prepocessor but FPC does not seem to understand this. The zip file
also contains a folder with something that looks like it is a macro
processor that is meant to be used to process this file and a makefile
to start the entire thing but there are compile errors and and the
perceived hack-level of this entire thing is quite high.
What would be the most reasonable thing for me to have the handful of
constants defined that I need (I don't need the entire API, only the
most basic things to open my webcam and grab a frame¹). Should I use
variables and initialize them at runtime? Or should I define functions
instead of constants?
How should I now proceed? Should I try to make this entire thing
(including its macro pocessor) compile with a current FPC? I don't
really like this idea because v4l1 is deprecated anyways. And the
separate macro processor and the makefile also somehow does not look
tlike the right approach to me, there must be a better way. And I
don't need the entire full blown thing, only a small subset for a
small quick and dirty program to try a little idea of mine (might
prove to be throw-away code anyways).
_
¹) my current solution is just piping RGB data from streamer through a
named pipe to my application, I just wanted to know if i could get rid
of this external process and communicate directly with the camera and
also be able to control gain and exposure directly and in real time,
therefore I am investigating v4l/v4l2. I haven't found any other v4l
implementation for FPC.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] nested macros in C headers
In our previous episode, Bernd said: > > How should I now proceed? Should I try to make this entire thing > (including its macro pocessor) compile with a current FPC? I don't > really like this idea because v4l1 is deprecated anyways. And the > separate macro processor and the makefile also somehow does not look > tlike the right approach to me, there must be a better way. And I > don't need the entire full blown thing, only a small subset for a > small quick and dirty program to try a little idea of mine (might > prove to be throw-away code anyways). I always used a small program to simply calculate the hex constants. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
