Recent

Recent Posts

Pages: [1] 2 3 ... 10
1
Suggestions / Re: Laz
« Last post by kupferstecher on Today at 10:50:25 am »
And here goes yet another promise. Countless times before have we been told, if we were to do X, it would bring a huge amount of new users in a given time T. Never has it yet happened. That is the few times were the action X had been taken. (Like when we went version 1.0, which we were promised would bring countless new users).
The "huge amount" probably is not correct, but its hard to say if a certein action actually had a positive result or not.
When I started with Lazarus the first WTF-moment was when the undocked windows of Lazarus popped up. By now I actually prefer it compared to a docked design, but it took time to learn the benefits. For others this may have been a show stopper already. Choosing a new tool, programming language and environment is a huge time investment, people tend to mainstream. In the end its an emotional decision. So I'd say yes, such small things do play a roll. But in total and not as a single "improvement".

Note: i don't advocate for the name "Laz".
2
General / Re: Exceptions
« Last post by SymbolicFrank on Today at 10:37:08 am »
About the OOP / non-OOP:

The reason why many C libraries are such a mess isn't because header files exist (although that certainly isn't helping), but because the contents aren't grouped in a usable way. Like, they often start with multiple files simply containing all the constants used, followed with multiple files containing all the globals. Lots of clutter.

OOP is all about that logical grouping. The specifics for device A go into the object that handles that device. And because only that object is using them, we can encapsulate them: hide them from the rest of the program.

The result is, that each object has its own API / interface and contains everything you need to know about the device it encapsulates.  8-)

The code reuse is just a bonus.
3
Quote
Would it seem useful, especially at the install phase- that the "Package info" would include mention of any dependancies and where to get them from?
It would be useful in my opinion. What message do you have in mind?
4
General / Re: fpflock vs tcritical
« Last post by SymbolicFrank on Today at 10:11:39 am »
At this moment, there are 3460 separate threads running on my computer. Almost all of them are threads waiting on a device or other input. It's what threads do best.

The 1MB of memory mentioned is the size of the stack, you can configure that.
5
General / Re: Redeclared constant as variable
« Last post by PascalDragon on Today at 09:24:33 am »
True and false are not constants or "reserved" words in FPC. They're just magic intrinsic keywords that the compiler registers internally as being equal to 1 and 0.

You can see where it does this here.
The location is right, but your assumption is not: they are indeed simply ordinary constants that are inserted by the compiler into the System unit upon compiling that unit.
6
General / Re: fpflock vs tcritical
« Last post by lucamar on Today at 09:24:25 am »
Some kind of synchronization is necessary as otherwise you'll have garbled log output. However file locking is indeed not the best approach compared to a queue based mechanism with a separate logging thread as mentioned by SymbolicFrank.

The problem is that this is a CGI. An instance is run by the server for each request, that is, they are all basically independent programs that need to synchronize with one another. Threads are not the solution here: IIPC is. And the simplest form of IPC is using file locks, which is what the OP is doing.

It would be different if the logger where a separate process to which the CGIs could pass the strings and forget about it. But then you run into other problems, not the less of which is that now is the logger who needs to hog time to serve all those requests as quick as posible, so the "time" problem doesn't go away; it just get shifted.

All in all, and for what the OP is doing, I think he has taken a good approach. Not the best, maybe, but a good one.
7
Thanks very much for that,

When I read https://wiki.lazarus.freepascal.org/SQLite
I knew that I would need a DLL for distributed projects,
but neither there,

Quote
SQLite is an embedded (non-server) single-user database that can be used in FPC and Lazarus applications. Various drivers can be used to access SQLite from FPC/Lazarus programs. All drivers do need the SQLite library/dll in the executable directory (which can be your project directory or e.g. (projectdir)/lib/architecture/ depending on your Lazarus project settings) (and distributed with your executable) in order to work ...

nor in the component "Package Info" is anything said about a DLL being needed for the Lazarus IDE.

From the Install/Uninstall Packahes Dialogue:

Quote
Author: Luiz Américo Pereira Câmara
Description / Abstract: TSqlite3Dataset class package

License: Modified LGPL

Filename:  E:\lazarus\components\sqlite\sqlite3laz.lpk
Current state: not installed, RunAndDesignTime

I even looked in \lazarus\components\sqlite there is only a README.txt file in a subdirectory... lib/README.txt  which says...

Quote
Output directory of package SQLiteLaz

Would it seem useful, especially at the install phase- that the "Package info" would include mention of any dependancies and where to get them from?

Thanks again,
Paul
8
Suggestions / Re: Laz
« Last post by PascalDragon on Today at 09:21:37 am »
...should be a big plus from LGBT community as well!
Why do you think that? (honest question)
9
I was wondering if we really have to stick with the backtick, or we can keep the "old school" single quote instead?
This was a requirement from the core team to even remotely consider this for inclusion. The normal strings stay untouched. Period.
10
General / Re: fpflock vs tcritical
« Last post by PascalDragon on Today at 09:07:10 am »
This might be off topic again, but web servers usually handle each client in a separate thread in order to serve multiple clients as quick as possible. If each request has to be logged into the same file which is effectively protected by a mutex-type mechanism then the benefit of multi-threading is kinda lost. If there are 50 requests to be served simultaneously then the last request may have to wait for 49 other clients to finish writing to the log. Is that really what you want? :o
Some kind of synchronization is necessary as otherwise you'll have garbled log output. However file locking is indeed not the best approach compared to a queue based mechanism with a separate logging thread as mentioned by SymbolicFrank.
Pages: [1] 2 3 ... 10