Re: [fpc-pascal] Parse unicode scalar

2023-07-03 Thread José Mejuto via fpc-pascal

El 03/07/2023 a las 10:27, Hairy Pixels via fpc-pascal escribió:


Right now I've just read the file into an AnsiString and indexing assuming a 
fixed character size, which breaks of course if non-1 byte characters exist

  I also need to know if I come across something like \u1F496 I need to convert 
that to a unicode character.



Hello,

You are intermixing a lot of concepts, ASCII, Unicode, grapheme, 
representation, content, etc...


Talking about Unicode you must forget ASCII, the text is a sequence of 
bytes which are encoded in a special format (UTF-8, UTF-16, UTF-32,...) 
and that must be represented in screen using Unicode representation 
rules, which are not the same as ASCII.


Just to keep this message quite short, think in a text with only one 
"letter":


"á"

This text (text, not one letter, Unicode is about texts) can be 
transmitted or stored using Unicode encoding rules which are a sequence 
of bytes with its own rules to encode the information. Each byte is 
hexadecimal:


UTF8: C3 A1
UTF16LE: 00 E1
UTF32: 00 00 00 E1

You must know in advance the encoding format to get the text from the 
bytes sequence. There is also a BOM (Byte Order Mark) which is sometimes 
used in files as a header to indicate the encoding, but in general it is 
not used.


Now decoding that sequence of bytes, using the right decoding format you 
get a text which represent the letter "a" with an acute accent, but 
Unicode is *not* so *simple* and the same text could be represented in 
screen using letter "a" + "combining acute accent" and bytes sequence is 
totally different, different at encoding level but identical at 
renderization level. So this two UTF8 sequences:


"C3 A1" and "61 CC 81"

are different at grapheme level and encoding level but identical at 
representation level.


Just as final note, this is the UTF-8 sequence of bytes for one single 
"character" in screen:


F0 9F 8F B4 F3 A0 81 A7 F3 A0 81 A2 F3 A0 81 B3 F3 A0 81 A3 F3 A0 81 B4 
F3 A0 81 BF


Unicode is far, far from easy.

Have a nice day.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] SetFileTime

2023-05-03 Thread José Mejuto via fpc-pascal

El 03/05/2023 a las 8:48, Carsten Bager via fpc-pascal escribió:
> I am trying to change the file date on a SYMLINK (not the file that  the
> link points to).
> Does anyone know if there is a method for this under Windows.
> Carsten


Hello,

Attached is a dirty implementation of "touch" for junctions that I need 
in the past. I think it can help you to do the same over other kind of 
links.


Have a nice day.
program touchjunction;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes, SysUtils, windows, CustApp
  { you can add units after this };

const
   FILE_FLAG_OPEN_REPARSE_POINT=DWORD($0020);
   FileTimeBase  = -109205.0;
   FileTimeStep: Extended = 24.0 * 60.0 * 60.0 * 1000.0 * 1000.0 * 10.0; // 100 
nSek per Day

type

  { TTouchJunction }

  TTouchJunction = class(TCustomApplication)
  protected
procedure DoRun; override;
function DateTimeToFileTime(DateTime: TDateTime): TFileTime;
  public
constructor Create(TheOwner: TComponent); override;
destructor Destroy; override;
procedure WriteHelp; virtual;
  end;

{ TTouchJunction }

function TTouchJunction.DateTimeToFileTime(DateTime: TDateTime): TFileTime;
var sysTime: TSYSTEMTIME;
temp: TFILETIME;
begin
  DateTimeToSystemTime(DateTime,sysTime);
  SystemTimeToFileTime(@sysTime,@temp);
  LocalFileTimeToFileTime(@temp,@result);
end;
procedure TTouchJunction.DoRun;
var
  ErrorMsg: String;
  TheDate,TheTime: string;
  TheFile: UTF8String;
  TheFileW: WideString;
  ParamList: TStringList=nil;
  TheHandle: THandle=INVALID_HANDLE_VALUE;
  FT: TFormatSettings;
  TheFileModify: TDateTime;
  lCreationTime, lAccessTime, lModificationTime: FILETIME;
  Arroba: Boolean=false;
  F: TFileStream;
  B: String;
  U: UnicodeString;
begin
  // quick check parameters
  ErrorMsg:=CheckOptions('h', 'help');
  if ErrorMsg<>'' then begin
ShowException(Exception.Create(ErrorMsg));
Terminate;
Exit;
  end;

  // parse parameters
  if HasOption('h', 'help') then begin
WriteHelp;
Terminate;
Exit;
  end;

  if ParamCount=0 then begin
WriteHelp;
Terminate;
Exit;
  end;

  { add your program here }

  TheFile:=ParamStr(1);
  TheDate:=ParamStr(2);
  TheTime:=ParamStr(3);

  if TheFile<>'' then begin
if TheFile[1]='"' then begin
  TheFile:=copy(TheFile,2);
end;
if TheFile[1]='@' then begin
  TheFile:=copy(TheFile,2);
  Arroba:=true;
end;
if TheFile[1]='"' then begin
  TheFile:=copy(TheFile,2);
end;
if TheFile[length(TheFile)]='"' then begin
  TheFile:=copy(TheFile,1,Length(TheFile)-1);
end;

if Arroba then begin
  if not FileExists(TheFile) then begin
writeln('File "',TheFile,'" does not exists.');
Terminate(1);
exit;
  end;

  //Each line is a parameter
  //so

  //Junction Name
  //2020-01-01
  //19:23:00

  ParamList:=TStringList.Create;
  try
F:=TFileStream.Create(TheFile,fmOpenRead or fmShareDenyNone);
SetLength(B,F.Size);
F.Read(B[1],F.Size);
FreeAndNil(F);
ParamList.Text:=B;
TheFile:=Utf8String(Utf8decode(ParamList[0]));
TheDate:=ParamList[1];
TheTime:=ParamList[2];
  finally
FreeAndNil(ParamList);
  end;
end;
  end;


  FT:=DefaultFormatSettings;

  FT.DateSeparator:='-';
  FT.LongDateFormat:='-MM-DD';
  FT.ShortDateFormat:='-MM-DD HH:mm:SS';

  TheFileModify:=StrToDateTime(TheDate+' '+TheTime,FT);

  TheFileW:=WideString(TheFile);

  TheHandle:=CreateFileW(@TheFileW[1], GENERIC_READ or GENERIC_WRITE,
 FILE_SHARE_READ or FILE_SHARE_WRITE,
 Nil, OPEN_EXISTING,
 FILE_FLAG_BACKUP_SEMANTICS or 
FILE_FLAG_OPEN_REPARSE_POINT or FILE_ATTRIBUTE_REPARSE_POINT, 
INVALID_HANDLE_VALUE);
  if TheHandle<>INVALID_HANDLE_VALUE then begin
if GetFileTime(TheHandle,@lCreationTime,@lAccessTime,@lModificationTime) 
then begin
  lModificationTime:=DateTimeToFileTime(TheFileModify);
  if not SetFileTime(TheHandle,lCreationTime,lAccessTime,lModificationTime) 
then begin
writeln('SetFileTime Last Error: ',GetLastError());
CloseHandle(TheHandle);
Terminate(3);
exit;
  end else begin
CloseHandle(TheHandle);
writeln ('Touched "'+TheFile+'" with '+DateTimeToStr(TheFileModify));
Terminate(0);
exit;
  end;
end else begin
  writeln('GetFileTime Last Error: ',GetLastError());
  Terminate(2);
  exit;
end;
  end else begin
writeln('CreateFileW Last Error: ',GetLastError());
Terminate(5);
exit;
  end;

  // stop program loop
  Terminate(0);
end;

constructor TTouchJunction.Create(TheOwner: TComponent);
begin
  inherited Create(TheOwner);
  StopOnException:=True;
end;

destructor TTouchJunction.Destroy;
begin
  inherited Destroy;
end;

procedure TTouchJunction.WriteHelp;
begin
  { 

Re: [fpc-pascal] RTLEventWaitFor

2022-04-05 Thread José Mejuto via fpc-pascal

El 05/04/2022 a las 1:03, Mattias Gaertner via fpc-pascal escribió:

Hi Michael,

Under Linux a RTLEventWaitFor(e,1) usually waits at most 1ms. But under
Windows it usually waits at least 15ms. It seems to round to nearest
1/64 of a second.

Googling this lead me to question the sanity of some bloggers.

Has anyone an idea if this is normal on Windows and if there is an
alternative?

Mattias


Hello,

On Windows the timer resolution is 1/64, that's 15,6 ms. You can change 
it by using "NtSetTimerResolution" but it is system wide and other 
programs can fail or have strange behaviour. MS recommends to not change 
it, but some programs like Chrome do it for some chuncks of time.


You can check the 15.6 ms using a tight loop of GetTickCount.

Have a nice day.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Reading Serial Hex Data

2020-12-28 Thread José Mejuto via fpc-pascal

El 28/12/2020 a las 2:02, James Richters via fpc-pascal escribió:

I think I figured out why my writeln's are causing an issue.. they are 
introducing a delay between the SerWrite and SerRead...
and the device I am reading is timing out and sending it's response a second 
time.


Hello,

None of the serial devices I have seen do something like that, in fact 
usually they do exactly the opposite, fire and forget, or in other words 
send a message and do not check for errors unless they wait for an 
answer from the host.


Your problem seems to be or a documentation misinterpretation or the 
connection or the device is not using any kind of flow control.



I was under the impression that there was a hardware buffer on the serial 
ports, my packets are very small,
some only a few bytes, but even those are not going into any kind of a hardware 
buffer.


Hardware buffers in serial device is 16 bytes (In fact 14 for receive) 
at most and it is managed by the Windows serial driver to garantee no 
byte is lost. The operation scheme is something like:


1- Serial byte received
2- IRQ signal issued
3- Windows serial driver read serial port and copy byte(s) to driver buffer.
4- Signal IRQ as handled.

The 16 bytes hardware (FIFO) buffer is present to garantee that if steps 
between 2 and 4 takes too much time (this is time scaled in 1990's CPU 
power) no byte is lost. If an Intel 8088 can read 115200bps without any 
byte lost think what a today computer can read.


In order to perform tests there are programs where you create an hex 
string to be sent and inspect the answer from the device. Read 
documentation about how to open the port, specially about the flow 
control sync. XOn/XOff, RTS/CTS. In example some need that you raise the 
RTS line and wait for CTS line to be high before write, if you do not 
wait the device can misinterpret your request and hang or answer 
something stupid, this is automatically done by the Windows serial 
driver if you select the RTS/CTS flow control when open the port.



Have a nice 2021!

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] FPC 3.2fixes UTF8Decode strange place

2020-11-02 Thread José Mejuto via fpc-pascal

El 01/11/2020 a las 20:36, AlexeyT via fpc-pascal escribió:

@/José Mejuto, can you pls simplify this place, ie remove "if /IBYTE = 
10" + then/else.


Hello,

I don't have write access, so no, I can not.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] FPC 3.2fixes UTF8Decode strange place

2020-10-28 Thread José Mejuto via fpc-pascal

El 27/10/2020 a las 21:25, AlexeyT via fpc-pascal escribió:

rtl/inc/ustrings.inc

function UTF8ToUnicode(Dest: PUnicodeChar; MaxDestChars: SizeUInt; 
Source: PChar; SourceBytes: SizeUInt): SizeUInt;



a) it has "If (PreChar<>13) and FALSE then" and later some big block. 
with a comment which tells that "and FALSE" is on purpose and block is 
ignored. ?


b) after I removed "that block" I got such trimmed src


Hello,

As the author of that piece of code, UTF8 recommends expanding LF line 
endings to CR+LF but this will generate some troubles and to try to 100% 
conform the spec. the conversion has been added, but disabled so code 
maintainers can easily remove them if needed. If you remove the piece of 
code about #13 you can safely remove the check about #10 which is now 
nonsense so you end with:


---
while (OutputUnicodehttps://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] USB Human Interface Devices

2019-08-16 Thread José Mejuto

El 16/08/2019 a las 20:45, James Richters escribió:

Jose,

Can you tell me which relays work with your project at:
https://github.com/JoshyFun/VUSBRelayPascal  ?


"spam" sent by private.



I have inputs from my device working but not outputs, I think it would be 
helpful for me to learn how to output to anything as a stepping stone... and 
actually USB relays sound like fun.


Hello,

In the case of USB relays you must invoke a "GetReport" with ReportID = 
0 and you get a bitmasked state in 8 bytes of data. To activate and 
deactivate the code invoke a "SetReport" in the same way.


Without a proper API description it could be really hard to implement 
you hardware :-(


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] where to find materials about MP3 file format

2019-08-16 Thread José Mejuto

El 15/08/2019 a las 11:04, George Bakhtadze escribió:

mp3 is a loosy audio format. It means that some part of information is 
lost while encoding.
So doing a decoding/encoding cycle just to remove some piece of file is 
a bad idea.
I'd try to find a way to remove piece of audio data without 
decompressing the file similar to lossless operations on JPEG files.


Hello,

As JPEG only have limited operations without decompressing (limited 
rotation and limited cropping), mp3 also have limited operations without 
decompressing, in this case only frame volume change.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] USB Human Interface Devices

2019-08-15 Thread José Mejuto

El 15/08/2019 a las 15:11, James Richters escribió:

Yes, in device manager I see it listed as "HID-compliant vendor-defined device"  also 
Zadig identifies it as "USB Input Device" and it shows Driver: HidUsb (v10.1.17763.1)

Is there a way to use the windows system HID interface with FPC already in 
place as there is for other windows APIs?



Hello,

You can find a HID interface for windows at:

https://libstock.mikroe.com/projects/view/528/usb-hid-dll-for-delphi-and-perhaps-other-languages

In the "Basic" package.

Anyway, if possible, the use of libusb-1.0 is recommended as it will 
give you crossplatform support.


You can check my project to see how devices are enumerated, based in the 
libusb-1.0 function calls.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] where to find materials about MP3 file format

2019-08-15 Thread José Mejuto

El 14/08/2019 a las 22:23, Mgr. Janusz Chmiel escribió:


I have A very big and non easy dream.
Making similar MP3 editor like MP3 direct cut for Windows is. But sure! 

[...]
operations to assign beginning of block and its end. And mainly, I want 
to use remove block command, which will hae immediate effect. So MP3 

[...]
Who of us would have some tip how to find MP3 file format technical 
specifications?


Hello,

There are several documents about the MP3 format, but you only need for 
sure ID3V1, ID3V2 and MP3 frame format. You need ID3V1 and ID3V2 in 
order to skip this information (if you will not use it, as it is 
metadata only) and the MP3 frame format if you want to fast scan MP3 
time duration and scan for stream errors.


https://www.mp3-tech.org/programmer/frame_header.html

All other operations should be done with decompressed audio and in this 
situation nothing is different from MP3, WAV, AAC, OGG, etc.


There are only a few operations that you can apply to a MP3 stream 
without decompressing it, mainly volume change, as you can not, in 
example, remove a block directly from the MP3 stream even if the block 
is an MP3 frame because each frame is dependent of previous frames and 
if you remove one an audible "bleep" can happen (high chance).


So you only need something to decompress MP3 (and maybe other formats).

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] USB Human Interface Devices

2019-08-15 Thread José Mejuto

El 14/08/2019 a las 16:29, James Richters escribió:


I'll have a look at your project.. maybe it will give me some clues.
Can you tell me how to get hid.dll?  I  find it all very confusing, can I just 
download the dll somewhere or do I have to get this huge confusing package and 
built it myself?  The sample code that is able to access my device with python 
on Linux uses hid.dll  I would like to at least be able to try the hid.dll... 
if I can get hid.dll somewhere.


Hello,

hid.dll is the windows system HID interface, the API provided by Windows.


In the other hand, the hardware you are trying to manage is 10CE:EB93 ?

Yes, I got a listing of all devices, then I plugged in the new one, and that is 
the ID that was not there before.

If the answer is yes, that device is *not* HID compatible so you can not use 
hid.dll for native access, you must use WinUSB API set, or the
libusb-1.0 abstraction layer.

I'm curious how you can tell that by looking at the number of it?


No, I just look for the product and try to find its drivers, no one name 
the HID interface. Do you see the device in windows device manager under 
the HID section "Human Interface Devices (HID)" ?



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] USB Human Interface Devices

2019-08-14 Thread José Mejuto

El 14/08/2019 a las 1:41, James Richters escribió:

I wonder if HID devices will work at all on Windows the same as they do on Linux.   I have not been able to get the HID part of the python code to work on windows yet either because the instructions given to install the packages needed 


Hello,

HID devices works in the same way, you need a device driver for the 
hardware that exposes a HID interface and you can manage that HID 
interface using native hid.dll or use an abstraction layer like libusb-1.0.


https://github.com/JoshyFun/VUSBRelayPascal

My code to manage HID USB relays uses hid.dll (32 & 64 bits) or 
libusb-1.0 (32 bits only tested) on Windows, and libusb-1.0 or 
libusb-0.1 in Linux.


Of course, functions on hid.dll and libusb are no the same, they work in 
different way, but the libusb-1.0 works the same way in both platforms.


Implementation of hid.dll, libusb, etc, in my code only have relevant 
functions used in USB relays, so they can not used as a complete 
implementation.


In the other hand, the hardware you are trying to manage is 10CE:EB93 ? 
If the answer is yes, that device is *not* HID compatible so you can not 
use hid.dll for native access, you must use WinUSB API set, or the 
libusb-1.0 abstraction layer.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] USB Human Interface Devices

2019-07-26 Thread José Mejuto

El 26/07/2019 a las 12:39, James Richters escribió:


Anyone have any suggestions for an FPC only console application method or demo 
I could use to access this USB HID device?


Hello,

This is not a complete HID interface but it can help you to start 
working with them. It has been designed to handle USB Relays which are 
managed using HID interface. Demos with and without GUI.


https://github.com/JoshyFun/VUSBRelayPascal

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] MD5 Hash of StringList

2019-07-04 Thread José Mejuto

El 04/07/2019 a las 18:13, James Richters escribió:

Thanks you!

That got me on the right path.
Here's the working sample:

Hash  := Md5Print(MD5String(MyStringlist.Text));



Warning! That's platform dependent code due the new line sequences.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Public key algo pascal only

2019-04-08 Thread José Mejuto

El 08/04/2019 a las 11:49, Santiago A. escribió:


There is no simple solution for a complex problem.
RSA implies a lot of backend: several symmetric ciphers (AES, 
Blowfish..., that are complex by their own. You don't want to use Caesar 
cypher), acceptable random generator, big integer arithmetic,  prime 
numbers,  several hash algorithms.
And the library is leaving aside all PKI stuff: certificates, 
authorities  etc. And forget about memory protection etc
I think it is a minimal RSA lib. In fact, maybe it's too simple. As far 
as I've seen it only has MD5 and SHA1 hash algorithms, many environments 
require at least sha256. But if it is only for internal use (you are in 
charge of both ends of communication) and not for critical top secret, 
it could be enough. I don't think you will find anything much more simpler.


Hello,

For serious stuff complex libraries are needed, I know, but in this case 
a simple algo like a XOR (if it was a public/private key one) would be 
enough. The only requirement is that the "client" can not generate 
easily commands so the generation key must not be compiled in the code. 
It is not a security algo, it's more like make it difficult and nothing 
more, no real security is broken if the choose code is broken.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Public key algo pascal only

2019-04-07 Thread José Mejuto

El 07/04/2019 a las 8:22, Jy V escribió:
Give a look at Crypto.pas in Ultibo project at github, from memory it 
requires very few other pascal unit (and of course no external library 
or obscure binary code)


I also know that XMLRAD is sharing similar feature in unit XCrypto.pas, 
the project is hosted at SourceForge (and still of course no external 
library or obscure binary code).


Hello,

Thank you, I'll put an eye on both of them.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Public key algo pascal only

2019-04-06 Thread José Mejuto

El 05/04/2019 a las 19:08, Виктор Матузенко escribió:

Hi,

try this https://github.com/delphi-pascal-archive/Pascal-RSA



Hello,

Thank you. It is a bit "monster" but maybe I can split the necessary 
code. Thank you again.


--
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Public key algo pascal only

2019-04-05 Thread José Mejuto

El 05/04/2019 a las 13:01, Michael Van Canneyt escribió:


Maybe DCrypt has the necessary routines, Graeme Geldenhuys maintains a
version that works with FPC.


Hello,

Thank you, I have code from DCrypt but I was looking for something much 
more simple which can generate the keys/certificates and handle all 
operations or at least sign/check-sign, even a 32 bits algo would be 
valid :-)


Anyway thank you, your answer confirms my suspects.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Public key algo pascal only

2019-04-05 Thread José Mejuto

Hello,

Is there any public/private key algorithm, pascal only, implemented in 
the distribution of fpc ? Degree of security is not important, also a 
3rd party unit which does not depends on a DLL or depends on another 
software to generate key pairs, or other tasks, would be valid too.


Thank you.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpPDF and support of Latin2 charset

2019-03-20 Thread José Mejuto

El 19/03/2019 a las 15:00, LacaK escribió:



It seems that there is problem specific to CourierNew font (cour.ttf).
With Arial (arial.ttf) it works as expected.

Attached program which demonstrates problem.


Hello,

Can you send me by direct mail the pdf result for that program ? I´ll 
try to spot the differences.


The name "CourierNew" while the TTF name is "Courier New" may force a 
typographic fallback to a standard font. PDF font handling is a mess, 
design patch over patch, several ways to render the same glyphs, ... 
It's almost incredible that a program can render successfully any 
document :-)



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Embedding DLL into EXE for Windows 32 bit?

2018-07-07 Thread José Mejuto

El 07/07/2018 a las 11:01, Bo Berglund escribió:


1) Include the DLL as a resource and extract it to a temp location
before loading it


I have seen these suggestions but the comments indicated that writing
a binary file to the filesystem on startup and then calling stuff
inside likely will trigger antivirus detection...
See: http://www.delphipages.com/forum/showthread.php?t=216147


Hello,

This behavior raises a warning in the antivirus for sure. Not a good choice.


This I don't understand, it does not look like they have embedded the
dll into the application at all...

In the example both tests use the same code to load the dll from the
file system:
   ms := TMemoryStream.Create;
   ms.LoadFromFile(ParamStr(1));
(Paramstr(1) is the required DLL path)


It uses a memory stream, no disk is touched, but in the example, for 
simplicity, it reads the DLL from disk instead a resource in the EXE.



I found another MemoryModule at GitHub named BTMemoryModule:
https://github.com/nedich/memorymodule
But it too looks rather involved, and is pretty old...


In my Delphi times I was using it with good results. I was trying to 
port it to FPC but drop the attempt.


Anyway, using a DLL only complicates the distribution. Security is the 
same as an OBJ file, a hacker can not simply replace the DLL with an 
empty stub as some operations must be performed in the dongle which are 
verified in the main code, the DLL is just a tunnel between application 
and dongle.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to list USB devices on Windows?

2018-06-28 Thread José Mejuto

El 28/06/2018 a las 13:44, Marco van de Voort escribió:


I hesitate calling it public domain, but the code snippets I collect are
exactly that, visible for everyone, from postings on forums and the like.


JVCL also has such code. I use it to get descriptive names for usb serials.


Hello,

Maybe this code may help browsing USB HIDs across platforms:

https://github.com/JoshyFun/VUSBRelayPascal


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpsockets

2017-10-31 Thread José Mejuto

El 30/10/2017 a las 15:40, Victor Campillo escribió:

You have the function "FpIOCtl" with the option FIONREAD, I use it to 
read the amount of data of the reception buffer before call "fprecv" but 
if I remember correctly this only work when you configure the socket as 
asynchronous.


Hello,

fpioctl seems to not be implemented in Windows, but anyway your help 
give me a clue about a possible solution to my problem. Thank you.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] fpsockets

2017-10-30 Thread José Mejuto

Hello,

Do exists any way using the fpsockets family to know if a "fprecv" will 
block ? In other words do exists a call that return the amount of bytes 
that are ready to be read/received ?


In the case the answer is no, does fpc has another family of socket 
functions ? I know synapse, lNet, ... but I wish to use only fpc packages.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] {$DEFINE DEVEL}

2017-10-11 Thread José Mejuto

El 11/10/2017 a las 11:00, pasc...@piments.com escribió:


{$DEFINE DEVEL}
Can anyone suggest a similar one key trick ?

Hello,

I'm using {.$DEFINE DEVEL}

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Using Serial in a TCP/RS232 gateway, how to set buffer sizes?

2017-09-06 Thread José Mejuto

El 06/09/2017 a las 21:22, Bo Berglund escribió:

   Inc(RxTcp, Length(Buf));
   SerWrite(FComH, Buf[0], Length(Buf));
   Inc(TxSer, Length(Buf));
Where could I be losing incoming serial data?


Hello,

Where do you check that "Length(Buf)" has been sent ?

if SerWrite(FComH, Buf[0], Length(Buf))<>Length(Buf) then Raise 
Exception.Create("KBOOM");


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] SVN RSS

2017-07-26 Thread José Mejuto

El 26/07/2017 a las 0:37, Andrew Haines via fpc-pascal escribió:

If you only want to see commits in a feed you can use this link to the 
unofficial github mirror:

https://github.com/graemeg/freepascal/commits/master.atom
It's synced every 15 minutes.


Thank you :-)


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] SVN RSS

2017-07-25 Thread José Mejuto

El 25/07/2017 a las 8:33, Michael Van Canneyt escribió:

Is it possible that the SVN RSS is stuck at day 21 ?
https://svn.freepascal.org/feeds/fpcsvn.rss


Yes. The post-commit script that creates the feed has been disabled due 
to time-out problems.




Hello,

Will it be re-enabled ?

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] SVN RSS

2017-07-24 Thread José Mejuto

Hello,

Is it possible that the SVN RSS is stuck at day 21 ?

https://svn.freepascal.org/feeds/fpcsvn.rss

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] for loops performance problems?

2017-07-04 Thread José Mejuto

El 04/07/2017 a las 11:09, Anthony Walter escribió:

I can convert to static buffers and get good performance (if I know the 
text isn't changing), but I'm now curious if this specific performance 
issue is related to fpc's for loop code generation.

What do you think?


Hello,

AFAIK the problem was/is some floating point maths not loops, and the 
partial/full SSA missing in fpc.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Serial to TCP gateway in FPC?

2017-06-29 Thread José Mejuto

El 29/06/2017 a las 10:39, Bo Berglund escribió:


3) I also noted in the comments in TurSeriale.pas:
   "The Windows port driver does receive callbacks in chunks that
are typically 8 bytes long.
With ReceiveMode = rmRAW, TSeriale will simply pass this chunks
on to the application without any processing."
Does this mean that if a single character is received it is not passed
along? My protocol is exchanging single bytes for state changes and


Hello,

I'm quite sure no, it means that the driver will try to queue 8 bytes 
before sending back data, but the tricky word is "try", probably after a 
context switch or similar the available data will be reported by the 
driver whichever the amount of bytes are.


Kernel to userland data pass is very expensive so drivers usually try to 
queue a data amount limit or a data time limit whichever it happens first.


Also forget the usual 15 bytes buffering in serial comms, it is expected 
that the kernel driver can buffer much more data before overflow, 
probably around 8 Kbs.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

2017-06-28 Thread José Mejuto

El 28/06/2017 a las 23:50, James Richters escribió:

The two color schemes are nothing alike.  16bit is using this RGB565 format, 
but 8bit colors (at least the version I was using) the colors have no real 
relation to their bits (see thishttps://pasteboard.co/2K38l6Gk1.png)  I can't 
figure out any pattern to this at all and while some colors I can figure out, 
others would be quite difficult.


Hello,

Your palette looks like standard Int Mode 13h VGA palette (yes, I'm 
older). This are the RGB values (I'm quite sure):


palette[  0] = rgb(  0,  0,  0)
palette[  1] = rgb(  0,  0,170)
palette[  2] = rgb(  0,170,  0)
palette[  3] = rgb(  0,170,170)
palette[  4] = rgb(170,  0,  0)
palette[  5] = rgb(170,  0,170)
palette[  6] = rgb(170, 85,  0)
palette[  7] = rgb(170,170,170)
palette[  8] = rgb( 85, 85, 85)
palette[  9] = rgb( 85, 85,255)
palette[ 10] = rgb( 85,255, 85)
palette[ 11] = rgb( 85,255,255)
palette[ 12] = rgb(255, 85, 85)
palette[ 13] = rgb(255, 85,255)
palette[ 14] = rgb(255,255, 85)
palette[ 15] = rgb(255,255,255)
palette[ 16] = rgb(  0,  0,  0)
palette[ 17] = rgb( 20, 20, 20)
palette[ 18] = rgb( 32, 32, 32)
palette[ 19] = rgb( 44, 44, 44)
palette[ 20] = rgb( 56, 56, 56)
palette[ 21] = rgb( 68, 68, 68)
palette[ 22] = rgb( 80, 80, 80)
palette[ 23] = rgb( 97, 97, 97)
palette[ 24] = rgb(113,113,113)
palette[ 25] = rgb(129,129,129)
palette[ 26] = rgb(145,145,145)
palette[ 27] = rgb(161,161,161)
palette[ 28] = rgb(182,182,182)
palette[ 29] = rgb(202,202,202)
palette[ 30] = rgb(226,226,226)
palette[ 31] = rgb(255,255,255)
palette[ 32] = rgb(  0,  0,255)
palette[ 33] = rgb( 64,  0,255)
palette[ 34] = rgb(125,  0,255)
palette[ 35] = rgb(190,  0,255)
palette[ 36] = rgb(255,  0,255)
palette[ 37] = rgb(255,  0,190)
palette[ 38] = rgb(255,  0,125)
palette[ 39] = rgb(255,  0, 64)
palette[ 40] = rgb(255,  0,  0)
palette[ 41] = rgb(255, 64,  0)
palette[ 42] = rgb(255,125,  0)
palette[ 43] = rgb(255,190,  0)
palette[ 44] = rgb(255,255,  0)
palette[ 45] = rgb(190,255,  0)
palette[ 46] = rgb(125,255,  0)
palette[ 47] = rgb( 64,255,  0)
palette[ 48] = rgb(  0,255,  0)
palette[ 49] = rgb(  0,255, 64)
palette[ 50] = rgb(  0,255,125)
palette[ 51] = rgb(  0,255,190)
palette[ 52] = rgb(  0,255,255)
palette[ 53] = rgb(  0,190,255)
palette[ 54] = rgb(  0,125,255)
palette[ 55] = rgb(  0, 64,255)
palette[ 56] = rgb(125,125,255)
palette[ 57] = rgb(157,125,255)
palette[ 58] = rgb(190,125,255)
palette[ 59] = rgb(222,125,255)
palette[ 60] = rgb(255,125,255)
palette[ 61] = rgb(255,125,222)
palette[ 62] = rgb(255,125,190)
palette[ 63] = rgb(255,125,157)
palette[ 64] = rgb(255,125,125)
palette[ 65] = rgb(255,157,125)
palette[ 66] = rgb(255,190,125)
palette[ 67] = rgb(255,222,125)
palette[ 68] = rgb(255,255,125)
palette[ 69] = rgb(222,255,125)
palette[ 70] = rgb(190,255,125)
palette[ 71] = rgb(157,255,125)
palette[ 72] = rgb(125,255,125)
palette[ 73] = rgb(125,255,157)
palette[ 74] = rgb(125,255,190)
palette[ 75] = rgb(125,255,222)
palette[ 76] = rgb(125,255,255)
palette[ 77] = rgb(125,222,255)
palette[ 78] = rgb(125,190,255)
palette[ 79] = rgb(125,157,255)
palette[ 80] = rgb(182,182,255)
palette[ 81] = rgb(198,182,255)
palette[ 82] = rgb(218,182,255)
palette[ 83] = rgb(234,182,255)
palette[ 84] = rgb(255,182,255)
palette[ 85] = rgb(255,182,234)
palette[ 86] = rgb(255,182,218)
palette[ 87] = rgb(255,182,198)
palette[ 88] = rgb(255,182,182)
palette[ 89] = rgb(255,198,182)
palette[ 90] = rgb(255,218,182)
palette[ 91] = rgb(255,234,182)
palette[ 92] = rgb(255,255,182)
palette[ 93] = rgb(234,255,182)
palette[ 94] = rgb(218,255,182)
palette[ 95] = rgb(198,255,182)
palette[ 96] = rgb(182,255,182)
palette[ 97] = rgb(182,255,198)
palette[ 98] = rgb(182,255,218)
palette[ 99] = rgb(182,255,234)
palette[100] = rgb(182,255,255)
palette[101] = rgb(182,234,255)
palette[102] = rgb(182,218,255)
palette[103] = rgb(182,198,255)
palette[104] = rgb(  0,  0,113)
palette[105] = rgb( 28,  0,113)
palette[106] = rgb( 56,  0,113)
palette[107] = rgb( 85,  0,113)
palette[108] = rgb(113,  0,113)
palette[109] = rgb(113,  0, 85)
palette[110] = rgb(113,  0, 56)
palette[111] = rgb(113,  0, 28)
palette[112] = rgb(113,  0,  0)
palette[113] = rgb(113, 28,  0)
palette[114] = rgb(113, 56,  0)
palette[115] = rgb(113, 85,  0)
palette[116] = rgb(113,113,  0)
palette[117] = rgb( 85,113,  0)
palette[118] = rgb( 56,113,  0)
palette[119] = rgb( 28,113,  0)
palette[120] = rgb(  0,113,  0)
palette[121] = rgb(  0,113, 28)
palette[122] = rgb(  0,113, 56)
palette[123] = rgb(  0,113, 85)
palette[124] = rgb(  0,113,113)
palette[125] = rgb(  0, 85,113)
palette[126] = rgb(  0, 56,113)
palette[127] = rgb(  0, 28,113)
palette[128] = rgb( 56, 56,113)
palette[129] = rgb( 68, 56,113)
palette[130] = rgb( 85, 56,113)
palette[131] = rgb( 97, 56,113)
palette[132] = rgb(113, 56,113)
palette[133] = rgb(113, 56, 97)
palette[134] = rgb(113, 56, 85)
palette[135] = rgb(113, 56, 68)
palette[136] = rgb(113, 56, 56)
palette[137] = rgb(113, 68, 56)
palette[138] = rgb(113, 85, 56)
palette[139] = 

Re: [fpc-pascal] Serial to TCP gateway in FPC?

2017-06-20 Thread José Mejuto

El 21/06/2017 a las 1:37, Bo Berglund escribió:


The problem I have is that it seems only to work for COM1 or COM3, as
soon as I use a higher numbered port like COM33 then it fails.
What have I missed here?
Is serial only able to work with the low numbered ports (single
digit)?


Hello,

COM ports in windows can only be 1-9, to open high numbered COM ports 
you must use the extended name syntax (without quotes) "\\.\COM99" you 
can also use "\\.\COM1" for COM1-9.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] SIGSEGV in fpc_check_object

2017-06-14 Thread José Mejuto

El 13/06/2017 a las 21:04, Gabor Boros escribió:


Cannot have a simple test case just a dumb example.

procedure TForm1.FormCreate(Sender: TObject);
var
   x:TPanel;

begin
   x.Free;
end;

With Linux no error (x is Nil before the Free call), with Windows got 
SIGSEGV (x is not Nil before the Free call). Is it a Lazarus thing or 
come from FPC?


Hello,

That's wrong for sure, x is not initialized to nil, not in Linux nor in 
Windows. Procedure variables must be always initialized by hand. With 
that code you will get a warning from the compiler about uninitialized 
variable use.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

2017-03-22 Thread José Mejuto

El 22/03/2017 a las 19:17, James Richters escribió:


Copy the file to the hard drive with a temporary name
Flush all writes to above file
Delete previous backup file
Rename the original file to backup file name
Rename the new recently copied file to the original name


Hello,

Your problem seems to be that you are using an SSD without a big 
capacitor (or partially damaged one) to preserve writes on power loss. 
This fact combined with how TRIM works could create that effect.


You can try this steps:

1) Copy file content to .bak
2) Create new file with data (.datnew)
3) Close file (This forces SSD to write to an spare block)
4) Delete old file (This forces a TRIM sent to the SSD)
5) Rename file to original name.

In step 4, the delete should send a TRIM which could force a SSD-RAM to 
NAND-SSD write to handle the TRIM. You must not delete 0 bytes (no TRIM) 
nor files with a size less than 1024 (no TRIM in NTFS as most of them 
are stored as resident data in MFT).


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] WebAssembly Target

2017-03-16 Thread José Mejuto

El 16/03/2017 a las 16:27, Graeme Geldenhuys escribió:

On 2017-03-16 14:45, Karoly Balogh (Charlie/SGR) wrote:

I think there's still a master switch to disable this in the browsers.


So far Firefox 52 has none. Not in the Preferences, and not in
about:config either.


Hello,

about:config

javascript.options.wasm;true/false


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Adding a array of float in ressource and use it ?

2017-03-08 Thread José Mejuto

El 08/03/2017 a las 0:03, Vojtěch Čihák escribió:


there are different informations about *.wav, so maybe there are
different impementations too.
http://soundfile.sapp.org/doc/WaveFormat/
https://blogs.msdn.microsoft.com/dawate/2009/06/23/intro-to-audio-programming-part-2-demystifying-the-wav-format/


Hello,

Wav (AKA RIFF WAVE) is a container (RIFF), not an audio format, inside a 
wav you can put many audio formats and other informations like author, 
copyright, cues, some of them standard (defined by Microsoft) and others 
proprietary.


Usual wav files that most people use are PCM (Pulse Code Modulation) or 
in more programmer words int16 per channel. This is the usual format, 
but you can put inside floats, mp3, GSM, ADPCM, and many more.


@Fredvs: If your wav is noise in audacity the reason is quite sure 
because you are writing float audio buffer with a wav PCM header. Wav 
PCM is 4 bytes per sample in stereo while float is 8 bytes and almost 
never used for wav. Header and audio data (format, channels, bit depth) 
must match.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpc and voip ?

2017-02-02 Thread José Mejuto

El 02/02/2017 a las 18:25, fredvs escribió:


- Opus: only one sample-rate: 48k (easier for mixing + DSP)


AbbreviationAudio bandwidth Effective sample rate
NB (narrowband)   4 kHz 8 kHz
MB (medium-band)  6 kHz12 kHz
WB (wideband) 8 kHz16 kHz
SWB (super-wideband) 12 kHz24 kHz
FB (fullband)20 kHz48 kHz

And please move opus related to fpc-other.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fpc and voip ?

2017-02-02 Thread José Mejuto

El 02/02/2017 a las 16:32, Santiago A. escribió:

El 17/01/2017 a las 16:48, José Mejuto escribió:


Maybe you may think in Opus http://opus-codec.org/ as it is open,
royalty free (mp3 is not free, you must pay royalties for the encoder
side) and source code is C89 so it must be compilable (libopus) in
almost any platform without a titanic effort.

mp3 is not free?

According with

https://en.wikipedia.org/wiki/MP3#Licensing.2C_ownership_and_legislation

It's royalty free in European Union. And, in USA, still valid patents
will expire along 2017. After 31 December 2017 will be completely
royalty free in USA also.

Don't know rest of the world. Can it be worse than in USA?



Hello,

You are right, my working with MP3 technology was in 1999 so my 
"standards" are very old :-)


Anyway Fraunhofer Institute which holds most known patents about MPEG 
Layer III does not say "Patents expired" so maybe they can have a later 
patent over technology trying to enforce it in a future and keep control 
of the royalties.


Releasing a mp3 codec now could be safe in Europe (and 2018 in EEUU) but 
a hardware piece could be a problem if a later patent appears in the 
game. In the other hand as all known patents has expired I think no 
court will be against you, maybe a "cease and desists" at most.


Anyway mp3 technology is surpassed a lot by others.
--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to use pipes ?

2017-02-01 Thread José Mejuto

El 01/02/2017 a las 19:55, fredvs escribió:


Outframes := op_read_float(HandleOP,  @Buffer[0], FramesWanted , nil);
if Outframes = 0 then exit;


Hello,

if OutFrames < 0 then exit;

The fact that op_read_float is zero is not an error, simply the amount 
of samples read by opus engine is zero, maybe because internal buffer is 
full and do not need more data by now.


Reading from internet is usually faster than playing bitrate. Maybe you 
should sleep for a bit and retry.


From docs:

Returns:
The number of samples read per channel on success, or a negative value 
on failure.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Pointer hashing

2017-01-30 Thread José Mejuto

El 30/01/2017 a las 3:37, Ryan Joseph escribió:

I’m trying to hash a pointer value and found some example of hash function but 
not sure about translations and the process in general.



Hello,

After addressing the ^ conversion showed by other people I have a 
question. Why you need to hash a pointer ? Hashing a value is 
interesting to reduce its compare time (taking collisions into account) 
and/or verify message integrity, and hashing a pointer does not meet 
none of this goals as it is process wide unique (no collisions) and its 
size is the fastest compare operation (most architectures).


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pipe vs Memory buffer.

2017-01-29 Thread José Mejuto

El 28/01/2017 a las 13:32, fredvs escribió:


TOpusFileCallbacks = record
read: op_read_func;
seek: op_seek_func;
tell: op_tell_func;
close: op_close_func;
  end;

This does not work:

HandleOP := op_test_callbacks(pointer(InPipe),op_callbacks, BufferURL[0],
PipeBufferSize, err);



Hello,

As you need to use records you should specify {$PACKRECORDS C} or you 
could get a different record layout than C expects.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Pipe vs Memory buffer.

2017-01-27 Thread José Mejuto

El 27/01/2017 a las 3:52, fredvs escribió:

Hello Silvio:

Yes, we are on the good way.
Following your advice, here from https-url-opus the result of :



Hello,

The first thing to debug this problems is to determine the expected data 
for opus_test_memory. Usually streams (audio, video, etc...) are 
composed by two pieces the raw data and the transport envelope. In this 
case opus usually uses Ogg as transport envelope but it could be 
streamed in another container like MP4, MKV, etc.


Opus library should provide a play engine that decodes raw streams, 
extracted from its transport layer and maybe another series of APIs for 
the default transport layer, Ogg in this case. This last job seems to be 
done by the OpusFile API.


So to resume, you file is a raw opus audio or an Ogg file ?

Before using pipes with http try pipes with a local file. If your pipes 
on local file works but http does not maybe you are receiving the http 
headers, or any other unexpected situation, so dump the piped data to a 
local file and match it against the remote one.


Said that, I had never touched opus in my life :) so take my comments 
with care.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpc and voip ?

2017-01-17 Thread José Mejuto

El 17/01/2017 a las 16:28, fredvs escribió:


What do you think about the flac format ?
It seams to have all the feature needed on...
(and flac is already integrated in uos).


Hello,

FLAC is basically a compressed WAV (advanced compression), so high 
quality sound but low compression ratio, also it is not resilient to 
dropouts, it was not designed for streaming.


If you can not find a suitable codec for your application just use a 
streaming one like mp3, is not the best for the task, but can do it, 
FLAC can not.


Maybe you may think in Opus http://opus-codec.org/ as it is open, 
royalty free (mp3 is not free, you must pay royalties for the encoder 
side) and source code is C89 so it must be compilable (libopus) in 
almost any platform without a titanic effort.


Of course a RTP or alike transport is desirable, but it will introduce 
much more complex tasks.


I think that if you like to continue this discussion we should move it 
to fpc-other.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fpc and voip ?

2017-01-17 Thread José Mejuto

El 17/01/2017 a las 12:56, fredvs escribió:

@ Jose => many thanks I will deeply study your advices.


In the other side, mp3 is not a suitable format for voIP, as it have a big
latency.


Huh, what format would be better for voice over ip ?


Hello,

For conversation:

G.7* (G.711 - G.7229)
Speex
Opus
And maybe some others.

https://en.wikipedia.org/wiki/Comparison_of_audio_coding_formats

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fpc and voip ?

2017-01-17 Thread José Mejuto

El 16/01/2017 a las 23:10, fredvs escribió:

Hello,


What must be done to make:
- a url-mp3-file like 1) on server


That's just a file, you send it like a file with the proper MIME type, 
is the client that reads information from the stream as needed.



- a url-mp3-chunk like 2) on server


This is a chuncked send, you start to send information, in the header 
you do not express the length, so the client will read the file up to to 
the socket close (and play it).


From the send side you must write to the socket instead to a file as 
you are sampling from the media input. MP3 is not a stateless 
compression format, this means that each audio frame may need several 
previous frames to be able to play the current one. This need is the 
reason that you sometimes ears a "bleep" sound at broadcast start (non 
professional). Also this dependency means that you can not compress each 
source audio chunck in an mp3 and broadcast it, you must compress audio 
portion in chuncks as part of a single stream.


Pseudocode:

AcceptRemoteSocket(SocketID);
mp3compress:=TMP3Compressor.Create;
mp3compress.Open;
while SocketID.Active do begin
XBytes:=AudioGrabber.Grab(RawAudio,MaxRawAudio,250 millisec);
CompressedSize:=mp3Compress(RawAudio,XBytes,Mp3Output,Mp3OutBufferSize);
SocketID.Send(Mp3Output,CompressedSize);
end;
mp3compress.Close;
mp3compress.Free;
SocketID.Close;

This is a very basic guide as this code will need checks to avoid remote 
contention and audiograbber overflow (usually handled by the audio 
grabber library).


In the other side, mp3 is not a suitable format for voIP, as it have a 
big latency.



This usable for uos_AddFromURL()?


I do not know, you need a chuncked send data, something that let you 
send an amount of data unknown while sending, and usually you will need 
at least one thread plus the main one if you need to handle more 
requests at the same time.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] C# translatation

2017-01-08 Thread José Mejuto

El 08/01/2017 a las 17:31, Bernd Oppolzer escribió:


Please keep in mind that & is a bitwise and in C
whereas && is a logical and;
this makes much difference and has to be implemented or converted
differently
with Pascal, IMO.
the closest equivalence to bitwise and in Pascal are set intersections,
IMO.
If I had to implement that on integers using standard pascal, this would
cause me some headache ...


Both bitwise operations (vars are integers).

C / C++:

a = b & c;

Pascal:

a := b and c;

Both work the same way but pascal does not have the assignment and 
testing mess that can be written in C like:


C / C++:

a = b && c;

Pascal:

a := (b<>0) and (c<>0);

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] file identification using libmagic

2016-12-14 Thread José Mejuto

El 14/12/2016 a las 19:53, Marc Santhoff escribió:

Hi,

I have made a header port of libmagic which is used by the file(1)
command to identify the type of files. Usage examples are availble, too.


Hello,

Just a note, I was using magic.dll for Windows a few years ago and I was 
being forced to use dynamic loading as my code must process thousands of 
streams/files and in magic_close the dll left an allocated memory block 
and the only way to remove it was unloading the DLL.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] TFileStream.WriteBuffer() and RAM used ?

2016-12-13 Thread José Mejuto

El 13/12/2016 a las 0:48, fredvs escribió:


IMO, the problem does not come from PortAudio but from
TFileStream.WriteBuffer that does not have enough RAM for writing.
But maybe I do not catch something :-(


Hello,

In your code you were writing from uos to TMemoryStream (RAM) and when 
finished copy everything to TFileStream (Disk), so instead the 
TMemoryStream use a TFileStream and skip the last copy. Of course you 
may need to rewrite file header when the process is finished.


Currently (pseudo code):

TMemoryStream.Create;
while Recording do begin
  TMemoryStream.Write(AudioBuffer);
end;
TFileStream.Create;
TFileStream.CopyFrom(TMemoryStream);
TFileStream.Free;
TMemoryStream.Free;

So change it by:

TFileStream.Create;
while Recording do begin
  TFileStream.Write(AudioBuffer);
end;
// Here you may need to rewrite file header (if any).
TFileStream.Free;


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TFileStream.WriteBuffer() and RAM used ?

2016-12-11 Thread José Mejuto

El 11/12/2016 a las 14:39, fredvs escribió:


@ Jose : uos uses PortAudio library to grap input from devices. I will
deeply study your propositions.


Hello,

After a fast view of PortAudio API you can produce a code like:

procedure WriteStreamToFile;
var
  F: TFileStream;
  lAvailableFrames: integer;
  lAvailableBytes: integer;
  lLocalBuffer: array [0..16383] of Byte;
begin
  F:=TFileStream.Create('YourFile.Extension',fmCreate);
  F.write(SomeHeaderData,SizeOf(SomeHeaderData));
  while NotUserBreak_OrLimitReached do
  begin
lAvailableFrames:=Pa_GetStreamReadAvailable(YourAudioStream);
lAvailableBytes:=lAvailableFrames * (YourStream_BYTES_PER_FRAME);
if lAvailableBytes<16384 then
begin
  // Don't read, just wait a bit.
  Sleep(1);
end
else
begin
  Pa_ReadStream(
YourAudioStream,
@lLocalBuffer[0],
16384 div (YourStream_BYTES_PER_FRAME
  );
  F.WriteBuffer(lLocalBuffer[0],16384);
end;
  end;
  F.WriteBuffer((SomeTailData,Sizeof(SomeTailData));
  F.Position:=;
  F.WriteBuffer(SomeDataWithStreamSize,Sizeof(SomeDataWithStreamSize));
  F.Free;
end;

This code should work because PortAudio (and almost 100% APIs of this 
kind) has an internal buffer which is large enough to hold new data 
while you are writing to disk and performing other tasks. Some even use 
a dynamic buffer which can hold audio for several seconds before you 
extract them using the API.


Note: Of course the maths are the expected ones, you must know the 
BYTES_PER_FRAME size and the format of that frames, maybe int16, maybe 
float, maybe 


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] TFileStream.WriteBuffer() and RAM used ?

2016-12-10 Thread José Mejuto

El 09/12/2016 a las 12:15, fredvs escribió:

Hello.

Thanks Michael for answer.


What happens with the buffer in which you had data, this we do not know.


Here is the schema of recording:



Hello,

You working schema for recording is memory related, you must transform 
it in a static approach based in expected requirements. In other words, 
you are about to write a WAVE, in a regular PC you can grab it directly 
to the TFileStream from InputBuffer, if you are in a very low power 
device you can use a doble buffer and if your requirements are a low 
power PC with very high bitrate spike you must swap to threading model 
(but it is overkill for almost anything nowadays).


It you don't want to directly write to TFileStream use the double 
buffer, let the audio grabber write in a block of memory while you dump 
the other one to TFileStream. It is quite difficult to show an example 
because I do not known the API you are using to grab the audio, most of 
them work with callbacks, some blocks execution, and others uses Windows 
events. If execution in API is blocking your thread I'm quite sure there 
is another one that do not block it.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


[fpc-pascal] Missing messages

2016-10-30 Thread José Mejuto

Hello,

Today I had detected that some emails does not reach me in this mailing 
list, in fact the last ones from "leledumbo" about JSON parsing, but 
Graeme and Michael ones arrive successfully


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] C translation question

2016-10-25 Thread José Mejuto

El 25/10/2016 a las 3:56, Lars escribió:


If you want to test it I can provide .exe or source code, but do not
expect it to translate anything far than some trivial functions.

Do you have github account... or sourceforge, I think a few other people
may find it useful...


Hello,

No sorry, no github, sourceforge (maybe yes, I can not recall).

Anyway I had sent you off the list a link to download my current 
implementation, test it and if you think it could be useful for anybody 
you can publish it or maybe I should open a github account :-)


Let me know if you was able to compile it. Thank you.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] C translation question

2016-10-24 Thread José Mejuto

El 24/10/2016 a las 1:40, Lars escribió:


Hi, what is the status of automated conversion tools? Last I remember
reading about them was when I read a delphi page on how to convert header
files. Are you saying that nowadways you can actually convert plain C code
to fpc, not just header files but all C code? Just certain types of C
code?  Are there any competing tools or everyone uses just one main tool?


Hello,

I don't know, wrote this tool to help me in the past to translate Zint 
barcode source from C to pascal, in special the maths involving "++", 
"--" and other funny "C" expressions.


It is far away from a real code translator, and it is dummy as it does 
not analyze the type of each variable, instead it uses them as a 
variable of any type and it simply try to put it in the same context as 
the "C" one. When it finds things like:


if (a) { ...

It will convert it to

if IsTrue(a) then ...

So you must provide an IsTrue function for that case (integer, char, 
byte...) and many times you need to manually adjust some lines.


Or if it finds:

a++;

It will output:

PostInc(a);

Where PostInc is:

function PostInc(var aValue: integer): integer;
begin
  Result:=aValue;
  aValue:=aValue + 1;
end;

It uses GoldParser so maybe it only works in Windows :-?, only very 
basic "C" is handled and is mostly function by function oriented.


If you want to test it I can provide .exe or source code, but do not 
expect it to translate anything far than some trivial functions.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] importtl tool

2016-10-24 Thread José Mejuto

El 24/10/2016 a las 8:17, LacaK escribió:


I'm not "sure" because if the flag does not tell us nothing (no IN, no
OUT) I do not know if there is a "default behavior" except the "ByRef"
flag and both "constref" and "var" are "ByRef".

I have found:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367051(v=vs.85).aspx
"The*[in]*attribute is applied to a parameter by default when no
directional parameter attribute is specified."


Hello,

I was not aware about that "default" so, yes you are right.


Take a look in you TLB looking for a widestring that should return
information, if with this code is marked as "var" everything should be
ok, if it will be marked as "constref" something in the logic is wrong.

? I do not understand what do you mean
When I use Microsofts OLEView to look at TLB I see only:
  long ScGetStringValue(long Type, BSTR* Value);
There is no attribute [in],[out],... specified


I'm quite sure that using "var" in both cases is safe in 99.9% of the cases.

OLEView will not show you the "attributes", only in the IDL source.


According to:
https://msdn.microsoft.com/en-us/library/cc237804.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms221019(v=vs.85).aspx

*"PARAMFLAG_NONE: *The behavior of the parameter is not specified."
I guess, that my case is PARAMFLAG_NONE so patch should look like:
  case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN
or PARAMFLAG_FOUT) of
  PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
  PARAMFLAG_FOUT:sPar:='out ';
  *PARAMFLAG_NONE,*
  PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
end;
I leave 'var ' for Delphi compatibility ...


Yes.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] C translation question

2016-10-22 Thread José Mejuto

El 22/10/2016 a las 11:59, Ryan Joseph escribió:


j := i + 1;

might want this at the end of the loop.

Doing that defiantly broke it. I think “j” is being set inside the for() 
construct and before each pass of the loop. The author explains the for loop 
even but the fact it requires an explanation makes my worry about how easy it 
is to mess up. :)


Hello,

It is at the end of the loop for sure, it points to the "previous" point 
in the polygon and in the case of the first testing point the "previous" 
one is the last one.


So the correct code is:

  j := i;

This is my automated C code conversion for that function:

function pnpoly(nvert: Integer; vertx: PointerTo_Single; verty: 
PointerTo_Single; testx: Single; testy: Single): Integer;

var
  c: Integer = 0;
  j: Integer = 0;
  i: Integer = 0;
begin
  {INITCODE} c := 0;
  {INITCODE} j := 0;
  {INITCODE} i := 0;
  i := 0;
  j := nvert - 1;
  while i < nvert do
  begin
if IsTrue(IsTrue(((verty[i] > testy) <> (verty[j] > testy)))
  AND
  IsTrue((testx < (vertx[j] - vertx[i]) * (testy - verty[i])
 div  (verty[j] - verty[i]) + vertx[i]))) then
begin
  c := BooleanNot (c);
end;
j := PostInc(i);
  end;
  exit (c);
end;


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] importtl tool

2016-10-21 Thread José Mejuto

El 21/10/2016 a las 13:57, LacaK escribió:


To note that both "constref" are intentional.

Ok I can create patch if we (you ;-)) are sure that it is okay ?
-Laco.


Hello,

I'm not "sure" because if the flag does not tell us nothing (no IN, no 
OUT) I do not know if there is a "default behavior" except the "ByRef" 
flag and both "constref" and "var" are "ByRef".


Take a look in you TLB looking for a widestring that should return 
information, if with this code is marked as "var" everything should be 
ok, if it will be marked as "constref" something in the logic is wrong.


In the other hand I do not have information about how TLBs are defined, 
my fixes were based in experience with some TLBs that I had and that 
should use, and in my case fortunately I had an equivalent C API to 
match against.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] importtl tool

2016-10-21 Thread José Mejuto

El 21/10/2016 a las 12:32, LacaK escribió:


So result should be:
case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and
(PARAMFLAG_FIN or PARAMFLAG_FOUT) of
  PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
  PARAMFLAG_FOUT:sPar:='out ';
 else sPar:='constref ';
end;


Hello,

Maybe a big note should be added if it is fixed in that way. Or even better


  PARAMFLAG_FOUT:sPar:='out ';
  PARAMFLAG_FIN:sPar:='constref ';
 else sPar:='constref ';

To note that both "constref" are intentional.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] importtl tool

2016-10-21 Thread José Mejuto

El 21/10/2016 a las 12:05, LacaK escribió:


- in typelib.pas is on line 631 vt=VT_PTR and sl='PWideString' ('P' is
deleted on line 635) wParamFlags=0
When I add "else" part:
case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and
(PARAMFLAG_FIN or PARAMFLAG_FOUT) of
  PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
  PARAMFLAG_FOUT:sPar:='out ';
  PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
/*added*/  else sPar:='var ';
end;
it works for me.
But I have no idea if it can negative impact other cases ?


Hello,

Looking again to the code I think you are right and is the third case 
"PARAMFLAG_FIN" which may be wrong, it should be "constref" (IN only). 
Have you tried to use constref in the else case ?


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] importtl tool

2016-10-20 Thread José Mejuto

El 20/10/2016 a las 15:20, LacaK escribió:


There is:
  if bParamByRef then
case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and
(PARAMFLAG_FIN or PARAMFLAG_FOUT) of
PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
PARAMFLAG_FOUT:sPar:='out ';
PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
end;
In my case bParamByRef = True, but wParamFlags=0 so no "var" nor "out"
is added ...
(as I do no known about type libraries I fear, that any modification
which fixes my case can cause problems in another cases)
So I have posted bug report:
http://bugs.freepascal.org/view.php?id=30764 may be somebody experienced
can fix it ...


Hello,

If wParaFlags is 0 then no "var" or "out" must be added (unless bug in 
filling wParamFlags with value) as it should be something like 
"constref" as "const" is not valid because it will try to perform a 
copy. Maybe "var" could be used :-? but it could be a problem if the 
called function changes the param expecting it to be discarded on return.


For native types like int and so on a const will work, but for 
interfaces, widestring, ... inclusion of var can crash some functions 
and not adding it could crash another ones.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] importtl tool

2016-10-20 Thread José Mejuto

El 20/10/2016 a las 11:09, LacaK escribió:

Hi,

I have noticed, that tool for importing type library into pas
incorrectly imports interface methods, which should have "var" parameter.

For example in my case imported:
   function
ScGetStringValue(Type_:Integer;Value:WideString):Integer;dispid 33;
but it should be:
   function ScGetStringValue(Type_:Integer;var
Value:WideString):Integer;dispid 33;

I think, that it is bug as far as delphi imports same type library with
"var".

Has somebody similar experience?


Hello,

I had fixed some of this bugs in:

http://bugs.freepascal.org/view.php?id=27486

And my patch was applied with small modification (as noted by Michael 
Van Canneyt) and I'm not sure if this modification alters the "var" 
inclusion in some fields.


Unfortunatly I'm not working with the TLBs anymore so I can not perform 
more tests. Maybe you can try to look at my patch and replace the last 
lines in your typelib.pas and recompile fpc tool.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] teventobject.create fails with error 161

2016-10-14 Thread José Mejuto

El 14/10/2016 a las 20:11, Snorkl e escribió:


Since I solved it by giving the name param a giud, the next thing to ask
is why does teventobject fail kind of silently when the name parm is
blank over time?


Hello,

To me it looks like a memory corruption, in your program or in the 
library. Have you checked the code with heaptrc activated ?



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Asci85

2016-09-16 Thread José Mejuto

El 16/09/2016 a las 10:16, Santiago A. escribió:

Hello,


 StrmEnc85:=TAscii85EncoderStream.Create(StrmOut,72,True);
 try
   StrmEnc85.CopyFrom(StrmIn,0);
   Result:=StrmOut.DataString;
 finally
   StrmEnc85.Free;


Maybe there is something wrong in ASCII85 encoder, but this code is 
wrong, it should be something like:


  try
StrmEnc85.CopyFrom(StrmIn,0);
StrmEnc85.Free;
Result:=StrmOut.DataString;
  finally

Because stream must be flushed before extracting result and the flush is 
performed in the destroy.


Saludos!.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] GZip - Stream decompress only in memory

2016-09-04 Thread José Mejuto

El 04/09/2016 a las 19:17, Marcos Douglas escribió:


  try
Buf.LoadFromFile('data.txt');
showmessage(inttostr(ExtractStream(Buf, Buf2))); //<< result is 0, ie, OK
Buf2.SaveToFile('result.txt');



There is no error, but Buf2 is empty.


Hello,

I'm not sure but I think that code at least should look like:

  try
Buf.LoadFromFile('data.txt');
---  Buf.Position:=0;
showmessage(inttostr(ExtractStream(Buf, Buf2)));
Buf2.SaveToFile('result.txt');

Because I think the stream position is just at the end after LoadFromFile.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] TTestSuite

2016-09-02 Thread José Mejuto

El 02/09/2016 a las 15:24, Graeme Geldenhuys escribió:


information will pollute the generated XML to stdout.

Why not specify a output file for the generated XML, instead of letting
it go to stdout. Run the FPCUnit console test application with the -h
parameter to see what options are available. Maybe that will help.


Hello,

With file output there is no problem as only the XML data is stored 
there, so writeln could be valid as a progress indicator because I think 
that stdout will not be used by automated tools.


Best regards and thanks.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TTestSuite

2016-09-02 Thread José Mejuto

El 02/09/2016 a las 14:39, Graeme Geldenhuys escribió:


If the tests may show some kind of progress information

I'm assuming you are talking about FPCUnit?

If so, there is already a test progress listener implemented in the form
of the TProgressWriter class (see the consoletestrunner.pas unit).

Simply run your test suite from the command line and specify the -p (or
--progress) command line parameter.


Hello,

Yes, but I'm writing the test so in code I can write something like:

if a=0 then FAIL('Value must not be 0');

And I wish to write something like:

if a>1 then MESSAGE('Value 2 or bigger is OK');
if a=1 then MESSAGE('Value 1 is quite dangerous');
if a=0 then FAIL('Value 0 is KBOOM!');

Because some test are slw and I like to have a screen feedback when 
running manually in the console, but if I use the writeln this 
information will pollute the generated XML to stdout. Maybe using stderr 
for progress messages will be valid and that's my question, will stderr 
cause pollution when the test is added to an automated test set ?


PS: I need to contact you out of the list about a project I'm finishing 
and that would be of your interest. My last try looking for your email 
(not mailinglists@...) was unsuccessful and never get an answer. Could 
you please contact me to this email address ? Thank you.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] TTestSuite

2016-09-01 Thread José Mejuto

Hello,

In the TTestSuite class when process is finished a XML is written to 
stdout. If the tests may show some kind of progress information, for 
manually run tests, this information must be in stdout, stderr, is there 
a specific method available for progress output ?


Cheers,

José Mejuto

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String concatenation failure (again)

2016-08-02 Thread José Mejuto

El 02/08/2016 a las 16:51, Jürgen Hestermann escribió:


I would expect that with the new string encoding handling
widestring will be converted automatically to "MyStringType"
(which is string in my case). This assumption is  encouraged
by the fact that "Liste" is shown with the correct list of all strings
in the evaluate window when debugging.

The interesting thing is, that *one* (the first) string
from "Liste" is added to "S" (but all others are missing).


Hello,

Check the length of the string I think you have a NULL char at the end 
of every string, so only the first one (up to #00 char) is displayed.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Single threaded application on multicore CPU

2016-06-22 Thread José Mejuto

El 22/06/2016 a las 15:01, Mattias Gaertner escribió:

I don't doubt that it is swapping. I would like to know why it is
swapping. Is it avoiding hotspots, or for longevity, or turbo boost, or
system processes, or security, or 
Related: What is the downside of pinning the process to a cpu?


Hello,

AFAIK it's more related to heat and whole system response, a heat core 
can enter in speed throttling thus lowering performance loosing the 
computing power in the other core(s). Also there are more threads than 
cores, when a thread finish its time slice if there are more threads 
scheduled for this core, current process will be directly remapped to 
another already free cpu core, or if there is not other free cpu core it 
is queued to the less loaded core given a better opportunity to be 
executed before.


After all this is a statistical game, in average you get better system 
performance (all threads) if you swap and mix the threads across all 
cores, better system performance is the gain, and less per given thread 
performance is the pay ;)



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Need help with a backtrace from fpc 2.6.4

2016-06-17 Thread José Mejuto

El 17/06/2016 a las 13:18, Dimitrios Chr. Ioannidis escribió:

Hello,

This looks completly wrong:


#3  0x0053bf1f in TIDENTITYHEADERINFO__PROCESSHEADERS (
this=)
at C:/Users/dimitris/Programming/Projects/R_1.2.4/3rdparty/indy/Pro
tocols/IdHTTPHeaderInfo.pas:452
LSECS = 546620041212591096


Such amount of seconds (or milliseconds) is more than one million years. 
So looks like the HTTP headers are not correctly parsed, maybe an 
unexpected format or a not initialized variable in the Indy code.


Start by dumping the headers.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Incompatible types: got "SYSTEM.PChar" expected "SYSTEM.PChar"

2016-06-09 Thread José Mejuto

El 09/06/2016 a las 8:04, Sven Barth escribió:


{$DEFINE THISDONTCOMPILE}
  TConstRecord: TFirstRecord = (
  {$IFDEF THISDONTCOMPILE}
Ident: TSomePcharArray[1]
  {$ELSE}
Ident: @TSomePcharArray[1]
  {$ENDIF}
  );



One can only use untyped constants to initialize other constants or
variables in their declarations. The TsomePCharArray is a typed
constant, thus not suitable for assignments (a pointer to it's element
is however legal as you noticed).


Hello,

The strange thing is that if I use a pointer, an integer or any other 
type instead a Pchar the error message is completely different "Error: 
Can't read or write variables of this type" which is a bit more informative.


I understand that untyped is the only source for assign a constant to so 
using @ I get an untyped pointer and the assign is performed, but is 
there a way to convert a pointer (typed) to untyped one ?


I think that the solution is to pollute the symbol table with a lot of 
consts, one of each text string.


Thank you for your help and enlightenment.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


[fpc-pascal] Incompatible types: got "SYSTEM.PChar" expected "SYSTEM.PChar"

2016-06-08 Thread José Mejuto

Hello,

I have a lot of constant strings and some array of records that should 
be initialized in one field with one of this entries, so I found two 
solutions, one is create a symbol for each string, something like:


const
  TMyStringSymbol='String one';

But also I need to be able to enumerate all of them at runtime, so I 
wrote an array and initialize it at compile time (this also produces 
less symbol pollution for the compiler):


const
  TMyStrings: array [0..1] of pchar = (
'String One','String Two');

As I need this names in other places I try to create a record and 
initialize it at runtime using the pchar of the previous array, and here 
is the problem:


---
program testpossiblebug;

type
  TFirstRecord=record
Ident: pchar;
  end;

const
  TSomePcharArray: array [0..1] of pchar = ( 'pcharONE','pcharTWO');

{$DEFINE THISDONTCOMPILE}

  TConstRecord: TFirstRecord = (
  {$IFDEF THISDONTCOMPILE}
Ident: TSomePcharArray[1]
  {$ELSE}
Ident: @TSomePcharArray[1]
  {$ENDIF}
  );

var
  R: TFirstRecord;

begin
  R:=TConstRecord;
  {$IFDEF THISDONTCOMPILE}
  writeln(R.Ident);
  {$ELSE}
  writeln(PPchar(R.Ident)^);
  {$ENDIF}
end.


This does not compile and outputs the funny error in the subject. I 
think it should compile as information is static and previously defined, 
but if it is indeed an error by my side maybe the error message should 
be a bit different :-?


To test the example, define or undefine the "THISDONTCOMPILE", with it 
defined it does not compile, without it it compiles and the modified 
writeln shows the expected pchar string.


Should I report it ?

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fcl-pdf: Extracting a page...

2016-04-11 Thread José Mejuto

El 11/04/2016 a las 22:52, Marcos Douglas escribió:

On Mon, Apr 11, 2016 at 5:45 PM, Graeme Geldenhuys
 wrote:

I'm sure it is possible - there are PDF-to-Text tools around. Is it
possible with the current fcl-pdf code? No. The fcl-pdf was designed to
work the other way take content (code, JSON etc) and create PDF's.


Right.
PDF-to-text is not an option because I need to extract the page with
the same appearance as the
original so I can't rewrite the page.


Hello,

Use qpdf:

http://qpdf.sourceforge.net/files/qpdf-manual.html
http://qpdf.sourceforge.net/files/qpdf-manual.html#ref.page-selection


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] How to compile Lazarus program using only FPC?

2015-10-03 Thread José Mejuto

El 03/10/2015 a las 20:24, Bo Berglund escribió:


Is there some way one can reset all unused sectors on the disk to only
contain 0xFF or Ox00?
That would make the image file compressible to a few GB and possible
to share.


Hello,

Just two links:

http://manpages.ubuntu.com/manpages/natty/man8/zerofree.8.html
https://www.raspberrypi.org/forums/viewtopic.php?t=97832=678959

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Assembler output

2015-09-12 Thread José Mejuto

El 12/09/2015 a las 14:10, Karoly Balogh (Charlie/SGR) escribió:


There are two motivations, the first one is to learn how to do it manually,
take a .pas, get the .s and assemble them (and link) to geta final executable.

IIRC it was arguments:
-a -st
This won't assemble or link the executable, but generate a script to
compile and link on the target OS. I used this often during early days of
the Amiga and MorphOS ports. :)
You can even use the resulting script as a base for your own compile/link
experiments.



Hello,

Great, sure it would be a great start/base point.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Assembler output

2015-09-11 Thread José Mejuto

El 11/09/2015 a las 20:18, Florian Klämpfl escribió:


FPC dependents on a lot of tools like cross binutils which are not provided by 
FPC itself. So
install nasm separately.


Hello,

Thank you, so the presence of nasm should make the compiler finish the 
compilation ? I was thinking that to generate .s output no assembler is 
needed at all as I do not need the final .exe produced by fpc.


Anyway I'll try to install nasm (or other) and see what happends. Thank 
you again.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Assembler output

2015-09-11 Thread José Mejuto

El 11/09/2015 a las 21:18, Sven Barth escribió:


What is the reason you're trying to do this? Maybe we can help you a bit
more if we know your motivation to pursue this.



Hello,

There are two motivations, the first one is to learn how to do it 
manually, take a .pas, get the .s and assemble them (and link) to geta 
final executable.


The second one is to perform some manual changes in the asm code (I know 
that is very easy to trash it) in order to try to catch some possible 
optimizations and apply/test them before reach a conclusion about them.


I currently had written a small SQL parser (very limited options,  just 
for the simple purpose of extract some fields from a large dump) and I 
think the code (tokenizer) should run faster (currently 28 Megabytes / 
sec in my i7-3770). It has been written with speed in mind, so no 
ansistrings, not realloc data, fixed and large read buffers, minimized 
conditionals as much as possible, inline critical functions, etc... 
There is still a bit of possible optimizations like replacing indirect 
access (pointer[n]) by running pointers but it will degrade too much the 
"easy reading" so I thought maybe I can gain some cycles here and there 
and find a small set of rules (asm sequences) which can be rewritten, 
something like WPO. But as noted it is more a training in the "how to" 
than a need to achieve an objective.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


[fpc-pascal] Assembler output

2015-09-11 Thread José Mejuto

Hello,

Can anybody enlight me in how to:

- Compile a program outputting assembler in intel format.
- Assemble the .s files in a final .exe

I can get assembler in AT format using "-a" but if I add "-Anasmwin32" 
the program is not compiled as "nasm is not found", only main.lpr is 
compiled, none of the included units (no RTL ones).


It would be great if I only need tools provided by fpc but I think that 
"as.exe" can not read Intel asm format.


In the case that "as.exe" can not be used for intel format, is there any 
option out there in order to get the final .exe from the .s files ?


Thank you.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] [Windows] FileGetAttr reports faHidden on e.g. C:\

2015-03-05 Thread José Mejuto

El 04/03/2015 a las 16:01, Bart escribió:

Hi,
Kind of off-topic.
While working on Lazarus' TShellTreeView component, it was brought to
my attention that FileGetAttr('C:\') returns an attribute that has
faHidden in it.
This is kind of unexpected.
Well actually it reports $16: faDirectory + faHidden + faSysFile on
Win7-64 (32-bit fpc)
On Win98SE it reports $10: faDirectory.
On Win7 FileGteAttr reports $16 on any path that is the root of a
drive, unless it is a 'substituted drive (subst X: path/to/folder).
Does anybody know when this behaviour of Windows changed, and why?

Hello,

That difference is between FAT and NTFS. In NTFS C:\ is not a 
directory, it is a drive and it also holds data references about the 
media it contents. Of course it could be considered a folder but it can 
not be used as a reparse point (like folders), you can not RMDIR it and 
other differences. Also the path C:\ refers to folder C: which 
enters in conflict because C: is the notation for current process 
folder not C:\.


Resume, in Windows [OneLetter]:\ is a drive which mostly works at 99% 
as a folder, but it is not, and its attributes does not have the same 
meaning as a regular folder and it should be operated as a drive concept 
(no attributes).


Side note: Programming of FileExists and DirectoryExists should be 
changed (rethink, retest,...) in 32 bits Windows programs in a 64 bit 
platform as GetFileAttributes does not perform the virtual aliasing like 
Program Files - Program Files (x86) and a call to FileExists (32 
bits) could report that a file exists that could not be opened because 
it exists in the one that FileExists can see but not in the one that 
would FileCreate try to use.


Jose Mejuto
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] 512bit (or higher) file encryption

2014-10-11 Thread José Mejuto

El 11/10/2014 a las #4, Krzysztof escribió:

Hi,

Need to encrypt file with 512bit (or higher) key. Looking at DCPCrypt
but seems that none of them can do that. Any advice?



Hello,

Which is the reason for such a big symmetric key size ?


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Is TFPList thread safe?

2014-10-03 Thread José Mejuto

El 03/10/2014 a las #4, Xiangrong Fang escribió:


I don't intend to do any optimization. I just think that I need to enter
a critical section, add item to the list, then leave the critical section.



Hello,

You must protect with a CriticalSection, Add and any other kind of 
access, like indexed access. As you must protect indexed access you are 
in the same penalty as using TThreadList.


Threading example to a crash (numbers are execution steps):

Thread 1

1-Resolve TList data access to $0001
2-calculate item 23 is at $00010023
3-Read $00010023
4-Crash or read from unalocated memory (content undefined).

Thread 2

1-Enter Add function and resolve Tlist data to $0001
2-Lock thread and find that it need to relocate data to $0002. Move data
3-Unlock
4-Continue

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes

2014-09-29 Thread José Mejuto

El 29/09/2014 a las #4, Reinier Olislagers escribió:


What I would like to know what is the cause of this problem - dlls being
loaded before some kind - what kind? - of initialization is complete?

Anyway, I'll keep digging; probably first looking at geting postgresql
support in anyway.
___


Hello,

You must not initialize dbengine in the Initialization section and must 
not finalize it in that place (maybe only as last chance) because 
initialization order and finalization order is undefined by fpc and 
finalization of your code could happen after the whole DB structure has 
been finished, so the call to DBLayer.Free could try to free an object 
controlled by an engine which is not loaded yet.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Imagemagick: magickwand doesn't convert to TIFF 1 bit

2014-09-14 Thread José Mejuto

El 13/09/2014 17:34, Reinier Olislagers escribió:

(Earlier posted on forum)

See subject - I've posted this on stackoverflow
http://stackoverflow.com/questions/25719495/magickwand-conversion-to-tiffccitt-group-4-compression-gives-uncompressed-image

Link to example program + demo image is included in that question.

Hope some of you guys can help solve this for me - and earn a
StackOverflow bounty in the process (if that helps ;) )



Hello,

For some reason the bindings in Pascal, and/or the wand bindings (maybe 
internally to imagemagick) are broken.


Use this enumeration to get the expected result in the TIFF module:

-
  UndefinedCompression,
  NoCompression,
  BZipCompression,
  DXT1Compression,
  DXT3Compression,
  DXT5Compression,
  FaxCompression,
  Group4Compression,
  JPEGCompression,
  JPEG2000Compression,  /* ISO/IEC std 15444-1 */
  LosslessJPEGCompression,
  LZWCompression,
  RLECompression,
  ZipCompression,
  ZipSCompression,
  PizCompression,
  Pxr24Compression,
  B44Compression,
  B44ACompression,
  LZMACompression,/* Lempel-Ziv-Markov chain algorithm */
  JBIG1Compression,   /* ISO/IEC std 11544 / ITU-T rec T.82 */
  JBIG2Compression/* ISO/IEC std 14492 / ITU-T rec T.88 */
--

So in your code use:

status := MagickSetImageCompression(wand,CompressionType(7));
if (status = MagickFalse) then HandleError;


I had downloaded the imagemagick sources in order to reach this fact.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] JS: \u00C1 = Á; Pascal: $00C1 = ?

2014-07-23 Thread José Mejuto

El 24/07/2014 2:12, silvioprog escribió:

In JavaScript, if I code:

alert('\u00C1');

It shows:

Á

Is \u00C1 of JS same to $00C1 in Pascal?



Hello,

\u means Unicode char, so \u00c1 = #$00C1 (widestring)

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


[fpc-pascal] typelib.pas

2014-06-26 Thread José Mejuto

Hello,

A few days ago I was trying to convert a COM DLL into a *_TLB.pas file 
using the importtl.exe and the result does not compile at all due some 
missing parameter names in some functions/procedures.


After note that typelib.pas is the heart of the importtl.exe file I was 
looking for the reason and fixes the bug and proposed a patch in this 
bug report


http://bugs.freepascal.org/view.php?id=26352

After this patch the code is compilable but some functions fails with a 
SIGSEGV. Looking at code again I found that some function names 
AddRef, Invoke and others that are present in base interface 
(IUnknown and IDispatch) are removed from the generated output.
After comment out this lines the code generated works mostly as expected 
(except another bug explained later) and a function AddRef appears in 
the middle of some interface definitions.


So my question is. Is fpc binding interface functions based in its index 
? I think the answer is yes so removing that reserved names crash the 
binding when a custom function with that name appears in the middle of 
an interface.


To solve this problem there are 2 solutions from my point of view, one 
is add it as is as (what my internal patch does now) or rename the 
function so it does not clash with inherited AddRef in example.


The other bug is that I had found intefaces which export a property_put 
with ByRef parameter, so it can not be mapped to a pascal property, so I 
had changed this conflictive functions to no emit a property read code.


Currently tipelib.pas generated code like this interface:

procedure Set_Value(var Param1: Widestring);
function  Get_Value: WideString;
property Value read Get_Value write Set_Value;

Which can not be compiled due the var in the Set_* procedure.

I hope that one devel can review and apply the patch in the bug report 
noted above.


Best regards,
José Mejuto
--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] paszlib problem: integer overflow

2013-11-14 Thread José Mejuto

El 14/11/2013 18:15, Dennis Poon escribió:


I'd love to just use the paszlib in Lazarus/fpc but I also need the same
unit for Delphi 5 (Dephi 5 program will compress data and send to linux
/lazarus/fpc program ) so both sides need to understand the same
compress/decompress protocol.
I tried using the lazarus/fpc paszlib unit in Dephi 5 but it does not
compile. Too many errors.
The paszlib-sg is the only pascal unit that produces compressed data
readable by FPC's zstream and zipper units.



Hello,

Both paszlib implementation are very, very similar, so try to spot the 
differences. Also are you trying to compress the 70 MB in one shot ? 
Post a piece of code that works by itself (just compiles) but that fail 
with 70 MB files.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] math round vs banker's round

2013-08-13 Thread José Mejuto

El 13/08/2013 23:47, David Emerson escribió:

Hi all,

I have just discovered that the system.round function has this very odd
behavior of rounding towards an even number when the fractional part is
.5 -- in the system.round documentation this is described as banker's
rounding

I do not like this behavior. How can I use a more
mathematically-traditional round function, which always rounds .5 up,
and everything below .5 down?

Do I need to write this function myself?


Hello,

SimpleRoundTo I think.

Maybe documentation should be changed to add SimpleRoundTo in cross 
referenced functions and note that SimpleRoundTo uses classic round 
system instead bankers one.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?

2013-05-09 Thread José Mejuto

El 09/05/2013 5:19, Bruce Tulloch escribió:


If there is no other explanation, then it means I need to find out how
the string variable referred to by (%eax) could have been been accessed
(or even known to exist) by any other thread in the same address space.-- 


Hello,

In the past I had suffered a problem like yours and the culprit was 
another different function that passes result (string) as a parameter 
when calling a function without initialization, something like this:


function foo(var para: string): string;
begin
  //Something with para
end;

function bar(): string;
begin
  result:=foo(result);
end;

I hope this helps...
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Same code from LCL project throw error in console application

2013-04-17 Thread José Mejuto

El 16/04/2013 22:46, Krzysztof escribió:

Thanks! exInvalidOp exception mask solved problem. But I don't
understand. Same error I had in fpGUI project. fpGUI interface doesn't
use GTK, QT etc, it drawing over pure X11 so how it is possible that
application catch GTK errors?



Hello,

Almost any 'C' library mask that errors, so the programmers do not take 
them in account and anyone, like the X11, can raise that exceptions.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Same code from LCL project throw error in console application

2013-04-16 Thread José Mejuto

El 16/04/2013 21:23, Krzysztof escribió:

Hi,

I have strange issue. Simple mpg123 player which work fine on LCL
project, on console application throw floating error in line mh_e :=
mpg123_read(mh, @outbuf[0], buffer_size, done);


Hello,

I'm not sure but I think that the GTK2 Widgetset disables some exception 
masks because GTK2 code here and there raises some float exceptions 
(division by cero, and others).


Try to do it in your console code before the mpg123 calls.

Unit math

SetExceptionMask (if my memory serves me).


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream

2013-03-28 Thread José Mejuto

El 28/03/2013 1:06, Ewald escribió:


Google found an old thread on lazarus mailing list about this (FPC,
gzip and stream) but without any solution, everything mentioned there
has either the limitations of TCompressionStream/TDecompressionStream
(no gzip format) or TGZFileStream (not able to work wit ObjectPascal
streams).


Hello,

.gz is a quite simple format, but it can not be implemented as a TStream (only) 
descendant because in a single .gz file many files could be added so something 
like the class to handle .zip files should be used.


Sorry to just drop in on this quite late, but isn't gzip  a compression algorithm and not a 
file format as such? gzip (the command line utility) only compresses one file and *doesn't* 
put this in a multi-file container. To get `multi-file gzips`, you will first want to 
bundle the files and compress this bundle (files - tar - gzip) or compress the 
files separately and then bundle them together (files - multiple separate gzipped files 
- tar). Or are we talking about a different gzip here?



Hello,

Just quoting the RFC1952 about .gz format:

--- http://tools.ietf.org/html/rfc1952 

2.2. File format

  A gzip file consists of a series of members (compressed data
  sets).  The format of each member is specified in the following
  section.  The members simply appear one after another in the file,
  with no additional information before, between, or after them.

---

So I think it is legal to concatenate several .gz files and get a final 
.gz with several files inside.


In the other hand, yes, the usual behavior in .gz is to store only one file.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream

2013-03-27 Thread José Mejuto

El 27/03/2013 19:22, Michalis Kamburelis escribió:


Google found an old thread on lazarus mailing list about this (FPC,
gzip and stream) but without any solution, everything mentioned there
has either the limitations of TCompressionStream/TDecompressionStream
(no gzip format) or TGZFileStream (not able to work wit ObjectPascal
streams).



Hello,

.gz is a quite simple format, but it can not be implemented as a TStream 
(only) descendant because in a single .gz file many files could be added 
so something like the class to handle .zip files should be used.


Parsing the .gz header is easy, and calling TCompressionStream and 
TDecompressionstream over the payload should be easy, but only for the 
first file in the .gz


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Sigsegv with refcounting interface

2013-03-07 Thread José Mejuto

El 07/03/2013 12:29, Joao Morais escribió:

Hello list, what's the problem with RoundThree procedure (below)?
Here it raises a sigsegv trying to read an internal field. The
difference from RoundTwo is that I create an implementation of the
interface within the first param of tinterfacedlist.add method.



 writeln('typecasting to v1...');
 v1 := iintf(vintf[0]);


Hello,

AFAIK you are casting a IUnknown to iintf instead requesting the iintf 
interface. I think the right procedure should be:


v1 := vintf[0] as iintf;

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Result: string

2013-03-06 Thread José Mejuto

El 06/03/2013 10:40, Jonas Maebe escribió:


FPC 2.6.2 does give a warning (code is from
http://bugs.freepascal.org/view.php?id=20907#c55064 ):

[...]

It could also fail in 2.6.x, just less often.


Hello,

2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but with 
this one 2.6.0, and 2.7.1 trunk does not generate it (I do not have 
2.6.2 to test):


\fpc\svn\bin\i386-win32\fpc test.pp
Free Pascal Compiler version 2.7.1 [2013/03/03] for i386
Copyright (c) 1993-2013 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pp
Linking test.exe
26 lines compiled, 0.1 sec, 29680 bytes code, 1236 bytes data

\fpc\fpc\2.6.0\bin\i386-win32\fpc.exe test.pp
Free Pascal Compiler version 2.6.0 [2011/12/25] for i386
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pp
Linking test.exe
26 lines compiled, 0.0 sec , 27264 bytes code, 1692 bytes data

--
program test;

{$mode objfpc}
{$h+}

procedure TheB(var aTheA: string);

begin
  aTheA:=aTheA+'A';
end;

function TheA(): string;

begin
  TheB(Result);
end;

Var
  C : String;

begin
  C:='B';
  C:=TheA;
  C:=TheA;
  Writeln('= ',C,'');
end.
---

And the effect is the same as using a non initialized variable, so it 
must generate a warning AFAIK. So passing Result as var does not 
generate a warning.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Result: string

2013-03-06 Thread José Mejuto

El 06/03/2013 13:47, Jonas Maebe escribió:


2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but
with this one 2.6.0, and 2.7.1 trunk does not generate it (I do not
have 2.6.2 to test):


That's because you are passing an uninitialized value to a
var-parameter. That only generates a hint, because a lot of code uses
var-parameters also for parameters that do not yet have to be
initialized (because the code predates the existence of the out
keyword, or simply out of habit).

This is unrelated to string results specifically.


OK, I see now. I had changed the code to perform the same with integers 
and yes, it also does not report a warning only a hint which is enought 
to me.


I'm quite sure that the library that starts this thread does not show a 
hint, so maybe in some situations it could fail. I'll try to reproduce 
it in a small code (if there is a problem, of course), meanwhile 
everything seems to work as expected.


Thank you for your help.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Result: string

2013-03-06 Thread José Mejuto

El 06/03/2013 13:47, Jonas Maebe escribió:


2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but
with this one 2.6.0, and 2.7.1 trunk does not generate it (I do not
have 2.6.2 to test):


That's because you are passing an uninitialized value to a
var-parameter. That only generates a hint, because a lot of code uses
var-parameters also for parameters that do not yet have to be
initialized (because the code predates the existence of the out
keyword, or simply out of habit).

This is unrelated to string results specifically.


Hello,

I had found why I was unable to see the hint, because it is not shown 
due the special contruction of the function.


This code produces a hint for the Result: String not initialized, but 
not for the Result: integer one:


--
program test;

{$mode objfpc}
{$h+}

procedure TheB(var aTheA: string);

begin
  aTheA:=aTheA+'A';
end;

function TheA(): string;

begin
  TheB(Result);
end;

procedure TheNumberB(var aTheB: integer);

begin
  aTheB:=aTheB*2;
end;

function TheNumberA: integer;

  procedure HideTheHint;

  begin
//As it is a procedure the Result var is taken
//from the function scope.
TheNumberB(Result);
  end;

begin
  HideTheHint;
end;

Var
  C : String;
  N : integer;

begin
  C:='B';
  C:=TheA;
  C:=TheA;
  Writeln('= ',C,'');

  N:=1;
  N:=TheNumberA;
  N:=TheNumberA;
  Writeln('= ',N,'');
end.
---

Yes, it is a bit obfuscated. I do not known if this is a bug in the hint.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Result: string

2013-03-05 Thread José Mejuto

El 05/03/2013 11:23, Howard Page-Clark escribió:



The code that makes me wonder something is wrong is this one:


[...]


For me (win32, FPC 2.6.2) the output is identical (= A) whether or not
Result in TheA() is initialised manually or not. Perhaps 2.7.1 has a
regression here if it differs for you?



Hello,

The problem is not the different behavior as it is or will be noted in 
documentation, the problem is the lack of warning of using a not 
initialized variable, so it is hard to fix code that works fine in 2.6.x 
and that could fail with Trunk.


Should I report a bug in Mantis about the warning ?

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


[fpc-pascal] Result: string

2013-03-04 Thread José Mejuto

Hello,

What's the expected output of this code ?

function TheA(): string;
begin
  Result:=Result+'A';
end;

writeln(TheA());

I thought that when the result type is an automated one its value gets 
initialized... Maybe I'm wrong...


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Result: string

2013-03-04 Thread José Mejuto

El 04/03/2013 22:16, Michael Van Canneyt escribió:


That report says the issue was assigned to Jonas and fixed in revision
20427 (ver 2.6.1).
I find the current release (2.6.2) initialises a string function
result to EmptyStr as you would hope.

[...]

Prints AA


Hello,

I'm asking because today I has updated my old 2.7.1 SVN since 8-9 months 
and a library starts to fail and the bug was the Result string which 
enters the function with a value while it does not happend in the old one.


If Result as string is not initialized a warning should be issued do not 
? This happends in your simple test, but I was unable to find it in the 
library that I'm using.


The code that makes me wonder something is wrong is this one:

---
{$mode objfpc}
{$h+}

procedure TheB(var aTheA: string);

begin
  aTheA:=aTheA+'A';
end;

function TheA(): string;

begin
  //Result:='';
  TheB(Result);
end;

Var
  C : String;

begin
  C:='B';
  C:=TheA;
  C:=TheA;
  Writeln('= ',C,'');
end.
---

In this situation no warning happends and result is different if I 
uncomment the Result:=''; line.


I think the missing warning is a bug, the missing warning or the non 
initialization.


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.

2013-02-12 Thread José Mejuto

El 12/02/2013 13:29, Giuliano Colla escribió:


My conclusion is that one can't properly handle INI files with just a
try..finally construct, as all examples show, because a possible error
will propagate outside the construct, with unpredictable effects (in
this case the FormClose procedure doesn't properly complete).


Hello,

Finally always propagate the exception bubbling up looking for other 
exception handler, and that's its job, in comparation to except handler 
which eat the exception and if you need to propagate it again you must 
Raise in the exception handler.



--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


  1   2   3   >