[fpc-pascal] Re: [OT] GPL Lisence help
On 28-7-2012 1:03, Daniel Gaspary wrote: > On Fri, Jul 27, 2012 at 5:39 PM, Dimitrios Chr. Ioannidis > wrote: >> Hi all, >> >> first let me express my apologies for the off topic question. >> >> I'm having trouble to choose the correct gpl lisence for a new open >> source project that i'm starting. I want the project to be open source >> gpl'ed so it can be accepted in distro's like Debian. But, at the same >> time, because the structure is modular, i want the possibility, to be >> used by anyone in commercial applications. >> >> Can anyone give a hint and/or a suggestion ? > > How about Dual licensed ? > > Let people choose the license: GPL or MIT +1 for GPL+MIT dual license. Simple, clear and works. Less need for lawyers - ask 2 and you get 3 opinions anyway :) The only thing is that looking at the OP's way of asking the question, I think he should read those licenses a couple of times (as well as some summaries) in order to understand them well. Mailing list discussions, lawyer advice etc can't fix things for you if you don't know what the license means... you'll have to find out yourself, perhaps not to a very detailed level, but certainly the general idea of the license. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] File Enumeration speed
I am enumerating thru large numbers of files on my disk, and find I cant come close with findfirst / findnext to matching the speed of cmd line apps available in linux :eg ls / du I have a fairly tight file search function, and dont see how to gain more speed Would anybody know what the limiting factors would be ? does the operating system keep an index somewhere ? Thanks - SteveG ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] File Enumeration speed
On Sat, 28 Jul 2012, SteveG wrote:
I am enumerating thru large numbers of files on my disk, and find I cant come
close with findfirst / findnext to matching the speed of cmd line apps
available in linux :eg ls / du
A regular ls only does a getdents() call.
FindFirst/FindNext does a getdents, but then additionally, per file in the
result, a stat() call.
I have a fairly tight file search function, and dont see how to gain more
speed
Would anybody know what the limiting factors would be ?
The number of calls to stat() to get extended file information.
I suspect that if you do a ls -l, it will be as slow as findfirst/findnext,
because it does then 3 calls per file:
from strace ls -l /etc I get:
lstat("/etc/odbc.ini", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lgetxattr("/etc/odbc.ini", "security.selinux", 0x14de920, 255) = -1 ENODATA (No
data available)
getxattr("/etc/odbc.ini", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP
(Operation not supported)
If you want speedier operation, and have enough file information with the name,
you can simply do a getdents().
does the operating system keep an index somewhere ?
Normally not (at least other than the regular disc cache).
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] File Enumeration speed
On 28/07/12 19:58, Michael Van Canneyt wrote:
On Sat, 28 Jul 2012, SteveG wrote:
I am enumerating thru large numbers of files on my disk, and find I
cant come close with findfirst / findnext to matching the speed of
cmd line apps available in linux :eg ls / du
A regular ls only does a getdents() call.
FindFirst/FindNext does a getdents, but then additionally, per file in
the result, a stat() call.
I have a fairly tight file search function, and dont see how to gain
more speed
Would anybody know what the limiting factors would be ?
The number of calls to stat() to get extended file information.
I suspect that if you do a ls -l, it will be as slow as
findfirst/findnext, because it does then 3 calls per file:
from strace ls -l /etc I get:
lstat("/etc/odbc.ini", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lgetxattr("/etc/odbc.ini", "security.selinux", 0x14de920, 255) = -1
ENODATA (No data available)
getxattr("/etc/odbc.ini", "system.posix_acl_access", 0x0, 0) = -1
EOPNOTSUPP (Operation not supported)
If you want speedier operation, and have enough file information with
the name, you can simply do a getdents().
does the operating system keep an index somewhere ?
Normally not (at least other than the regular disc cache).
Thanks Michael - I will do some study (ie find out what getdents() does)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: File Enumeration speed
> does the operating system keep an index somewhere ? ls doesn't, find does AFAIK. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/File-Enumeration-speed-tp5710462p5710465.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
Re: [fpc-pascal] Re: File Enumeration speed
On Sat, Jul 28, 2012 at 9:07 AM, leledumbo wrote: >> does the operating system keep an index somewhere ? > > ls doesn't, find does AFAIK. > "find" doesn't have any index over "ls". You may be thinking of "locate" (actually "located") that keeps a textfile with the list of files. Best regards, Flávio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Getting UTC time etc.
Mark Morgan Lloyd wrote: I know that this was discussed a couple of months ago, but I had difficulty working out what the consensus was. i)Is there an FPC function which will get the raw time from the RTC, which on unix systems will usually be UTC (specifically, without a DST correction)? Discussion was in March. How time flies. Reinier et al. suggested PascalTZ, but in the end I went for a simple function since I'm trying to avoid installing anything special and timezone info will be available from the backend database. (* This from FPC-Pascal mailing list, 13/02/07. Thanks, Marco. *) // function utc_now : TDateTime; var timeval: TTimeVal; timezone: PTimeZone; a: Double; begin TimeZone := nil; fpGetTimeOfDay (@TimeVal, TimeZone); // Convert to milliseconds a := (TimeVal.tv_sec * 1000.0) + (TimeVal.tv_usec / 1000.0); Result := (a / MSecsPerDay) + UnixDateDelta; end; ii)Are there functions to get "Unix seconds", "Borland seconds" and so on? Preferably without DST correction, or with the correction being extractable? DateTimeToUnix() from DateUtils. Anything else I can do without. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] File Enumeration speed
In our previous episode, Michael Van Canneyt said:
> lgetxattr("/etc/odbc.ini", "security.selinux", 0x14de920, 255) = -1 ENODATA
> (No data available)
> getxattr("/etc/odbc.ini", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP
> (Operation not supported)
>
> If you want speedier operation, and have enough file information with the
> name, you can simply do a getdents().
I wouldn't do that for two reasons:
1) getdents is not portable at the syscall level (unix systems either implement
getdirentries or getdents, not both). This is why getdents is not available
via portable calls.
2) it is very sensitive.
Basically findfirst is a opendir/readdir/closedir loop where opendir and/or
readdir
call getdents, with a stat per file.
IOW one can avoid getdents by doing opendir/readdir/closedir, and be as
fast, AND be portable.
> > does the operating system keep an index somewhere ?
>
> Normally not (at least other than the regular disc cache).
The getdents calls afaik simply returns blocks from the directory file. The
basic block level cache of the filesystem driver therefore works perfectly
for it.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
