Recent

Recent Posts

Pages: [1] 2 3 ... 10
1
General / Re: Best way to parse file.
« Last post by VisualLab on Today at 05:01:40 pm »
Thats the unix philosophy, instead of having to have one app with all the functionality, you have multiple specialized programs that do one thing very good and whose output can be reused by other programs.

The operating system is a technical product. Is a car, a plane or even an oven or a stool based on some philosophy? Of course not. The term "xyz philosophy" is vague. It's a ploy that tries to justify the shortcomings of a product. Technical products (even as simple as a stool) are created based on a set (list) of construction guidelines (assumptions) that are made before or during their creation (e.g. when modifying a prototype). Linux is a Unix clone. Unix originated in the 1970s as a commercial, very expensive, and confusing mainframe OS (The UNIX-HATERS Handbook ). Linux originated in the 1990s as nostalgia, a kind of Linus Torvads sentiment for the declining Unix. Today, when Unix is almost extinct, people around Linux are trying to implement some solutions in it that Unix did not have, because then computers had a more archaic construction. These attempts are made on the principle of "let's do it as if it were done in Unix". But it's a utopia because no one knows how it would be implemented. It probably wouldn't have been implemented at all because the Unix corporations weren't interested in providing Unix computers for the common people. Ordinary users would not gain anything from it anyway, because Unix was of little use for the PC. And that's why today there is Microsoft with its Windows and those corporations "gone to hell".

Another example where this is useful is for things like reading out hardware information can be quite annoying. Linux systems usually provide pseudofiles for this, but every distro might choose to put the pseudo files into another directory.

Truth. In Linux, programmatic access to information about hardware and services is a pain. Because Linux is primitive and messy. There is no uniform way to access resources and services in the system. Device files are an archaic solution. The aforementioned brothel in the directory system is just the tip of the iceberg. Another example is configuration files and where they are stored.

And the main advantage of this is, that it is very simple to debug, as all of these programs give the data in both human and machine readable form, you can debug your APIs by simply looking at the program output.

What is readable for the user (administrator) is not necessarily useful for the programmer. Linux still makes a habit of using text files after all these years, even though do is only useful for displaying the output of a program. For data processing, text is a pain (character encoding, content parsing, etc.). This is an ancient solution. Today, such a solution should absolutely not be used as a way of exchanging data: OS-program, program-OS or program-program. But it's used in Linux because of the laziness of Linux programmers (and perhaps moronic Unix sentiment).

So there are a lot of reasons to do this. It's one of the Windows deseases that Microsoft thought that everything must be accissable through code APIs and DLLs whose calls must be implemented in each program that tries to use them.

On the contrary. The existence of APIs and libraries is a blessing for a programmer writing software for a given OS. If it wasn't for the API, the programmer would have to implement every little thing himself. Linux does not have any API. This is one of the main reasons why most companies don't provide drivers or commercial software for Linux.

Besides, since when is there a compulsion to implement library calls in every program? You can not use them and "sculpt" the solution yourself. But the API saves you a lot of work. I guess that's what software development is all about, not reinventing the wheel. That's why there are so many different programs for Windows and it's much easier to write your own program for it (even using Lazarus).

By having different programs provide the data in both human and machine readable form, it is much easier to get access to that data and to learn how to use it.

Again: what is readable by the user (administrator) is not useful to the programmer. It's like inferring the operation of a device just by looking at it from the outside. No engineer or constructor does that (doctors too).
2
General / Re: TryStrToDate - do not read, if you do not believe in miracles
« Last post by Bart on Today at 04:46:50 pm »
... Decimal separator here is comma, but sometimes I need to format numbers from (or to) dot decimal separator. I usually have (global :)) variable, set up early (in .lpr) and then just use when I need specific format.

That can hurt you.
Windows can send a message that local settings have changed, and your application (on Windows) will reset the global DefaultFormatSettings to whatever Windows says it is now.
So, if at start you change DefaultFormatSettings.DecimalSeparator to '.' (dot) and use that (DefaultFormatSetting.Decimalseparator)  throughout your program, at some point it'll be reverted to ',' (comma) and your conversions wil either fail (if you use Val or TryStrToFloat) or raise an exception (if you use StrToFloat).

It's not a theoretical problem. In the past I had an application crash upon a user with a message like "1.23 is not a valid floating point value".
That baffled me for a long time, since at program start I would set DecimalSeparator to '.' (dot).
(Note: this was before the overloads with TFormatSettings were introduced in Delphi, so changing global DecimalSeparator was the only thing one could do.)
(And yes: you can fix that by telling your program to ignore this particular Windows message: Application.UpdateFormatSettings := False)

Bart
3
General / Re: Type checking of units of measurement
« Last post by avra on Today at 04:42:37 pm »
As I continue to experiment, it becomes clear that to reduce the number of operator definitions, I would need either:
- generic operators: similar to generic functions, but with operator, that could be applied to the various types that match the specializations.
- inheritance of class operators that refer to "self" type

You could also take a look at syshelp.inc and how it uses single syshelpo.inc with different macro parameters to avoid code repetition and typing errors:
Code: Pascal  [Select][+][-]
  1. { ---------------------------------------------------------------------
  2.   TByteHelper
  3.   ---------------------------------------------------------------------}
  4.  
  5. {$define TORDINALHELPER:=TByteHelper}
  6. {$define TORDINALTYPE:=Byte}
  7. {$define TORDINALBITINDEX:=TByteBitIndex}
  8. {$define TORDINALNIBBLEINDEX:=TByteNibbleIndex}
  9. {$define TORDINALOVERLAY:=TByteOverlay}
  10. {$define TORDINALTYPESIZE1}
  11. {$i syshelpo.inc}
  12. {$undef TORDINALTYPESIZE1}
  13.  
  14. { ---------------------------------------------------------------------
  15.   TShortintHelper
  16.   ---------------------------------------------------------------------}
  17.  
  18. {$define TORDINALHELPER:=TShortIntHelper}
  19. {$define TORDINALTYPE:=ShortInt}
  20. {$define TORDINALBITINDEX:=TShortIntBitIndex}
  21. {$define TORDINALNIBBLEINDEX:=TShortIntNibbleIndex}
  22. {$define TORDINALOVERLAY:=TShortIntOverlay}
  23. {$define TORDINALTYPESIZE1}
  24. {$i syshelpo.inc}
  25. {$undef TORDINALTYPESIZE1}

I exploited that idea a lot when adding bit helpers functionality.
4
General / Re: Type checking of units of measurement
« Last post by avra on Today at 04:13:34 pm »
I agree that "UUnit" is not very beautiful. I will use "Dimensioned" instead.
I am not English native, but dim or dimensions still sound better to me over dimensioned. I guess si or metrics could be even better names, but since imperial units would probably end up there too - it might not be that great idea. Anyway, it's not that important and your contribution will be most welcome under any name. I already see it useful when publishing measurements with appropriate unit names under some MQTT or OPC server.
5
IMHO, it is less error prone. I use it like Thaddy showed for number formatting. Decimal separator here is comma, but sometimes I need to format numbers from (or to) dot decimal separator. I usually have (global :)) variable, set up early (in .lpr) and then just use when I need specific format.

That's and old trick from Delphi, I use:

Code: [Select]
const
  lCID_Dutch   = 1043; // Belgian 2067
  LCID_French  = 1067; // France
  LCID_English = 2057; // British
  LCID_german  = 1031; // Germany
  LCID_Spanish = 1034; // Spain traditional
  LCID_Spanish_modern = 3082; // Spain modern.
  LCID_American= 1033;

var Englishformatsettings : TFormatSettings;

englishformatsettings:=getlocaleformatsettings(LCID_English,Englishformatsettings); // windows only afaik.

I believe I define my own LCID because etiher Delphi or FPC didn't have a complete list.
6
General / Re: Type checking of units of measurement
« Last post by avra on Today at 04:05:12 pm »
1 m = 1000 mm
Right on the spot!  :D
I had in mind cm but completely failed at the keyboard  :) %) ::)
7
FPvectorial / Re: The problem of drawing lines(fpvectorial)
« Last post by wp on Today at 03:40:23 pm »
fpVectorial supports two types of pages: a graphical page in which lines, graphics shapes and text can be placed arbitrarily (TvVectorialPage), and a textual page for paragraphs, tables etc, more typical of word processing (TvTextPageSequence). I don't know whether it is possible to draw an arbitrary line in a textual page - well, maybe in fpVectorial, but the main question is what Word will be doing with such a document.

I could imagine that it is possible to extend the TvParagraph such that it allows to draw a horizontal line below the paragraph across the page. In the next step it would be required to find the location and the format in the docx and odt files so that the writer will be able to store this information correctly. All this requires some work... I am not intending to spend this time at the moment. But maybe somebody submits a patch which I'd be happy to commit.
8
Packages and Libraries / Re: Generics.Collections TDictionary issue
« Last post by dseligo on Today at 03:38:43 pm »
... and in which case the result differ (e.g. with 3.2.2 it seem to work as expected).

Yes, with 3.2.2 and constref it works:
Code: Text  [Select][+][-]
  1. Ok, added
  2. Ok, contains
  3.  
  4. Ok, added
  5. Ok, contains
9
Anyway, I still think my code is the better solution in the long term and more concise.
It is "better" in the sense that it is Delphi-compatible - Delphi only supports the formatsettings argument, but not the format string allowed in FPC. It is "worse" in the sense that it requires more code lines: variable declaration + assignment of format string to local formatsettings + assignment of date separator.

IMHO, it is less error prone. I use it like Thaddy showed for number formatting. Decimal separator here is comma, but sometimes I need to format numbers from (or to) dot decimal separator. I usually have (global :)) variable, set up early (in .lpr) and then just use when I need specific format.
10
Packages and Libraries / Re: Generics.Collections TDictionary issue
« Last post by marcov on Today at 03:34:40 pm »
If I change to Delphi mode. it works. ( remove 2 times specialize and two @'s.

And then const is no problem either. It might be some problem with objfpc  64-bit mode signature mismatching a mode delphi const (which is a constref) somehow rather than generics.collections
 
It might be worth a bug report.
Pages: [1] 2 3 ... 10

TinyPortal © 2005-2018