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

@ Lars: The library used for op_memory_open and op_seek is libopusfile.so: https://github.com/xiph/opusfile Translation into fpc-Pascal of the header: https://github.com/fredvs/uos/blob/master/src/uos_opusfile.pas And Opusfile.so depends on libopus.so : https://github.com/xiph/opus

Re: [fpc-pascal] TProcess vs RunProcess()

In our previous episode, Santi said: > and people nowadays love to name directories and files with strings that > instead of titles look like abstracts. > > In delphi and other languages I've hit may times the 260 character limit > in windows running a Shell or using ShellApi (I supposed the

Re: [fpc-pascal] TProcess vs RunProcess()

El 27/01/17 a las 18:24, Graeme Geldenhuys escribió: If you have a huge list of parameters, RunProcess() - at least under Windows - will most likely hit a 260 character limit, and then fail to actually execute. I don't actually know where that 260 limit originates from (Windows API, Command

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

On Sun, January 29, 2017 4:45 am, fredvs wrote: > Hello Lars. > > > Thanks for your brilliant light. > > >> (and can you look into the actual source code of opus or is this closed >> source?) > > ==> https://github.com/xiph/opus > Well the function you were using with a buffer is here:

Re: [fpc-pascal] TProcess vs RunProcess()

On Sun, January 29, 2017 2:41 pm, Marco van de Voort wrote: > Some likely scenarios (e.g. run and capture stdout) have been prepared in > RunCommand, also in unit Process. > > > The main motivation for adding these is that 90+% of the TProcess and > CreateProcess usage in the forums was faulty

Re: [fpc-pascal] TProcess vs RunProcess()

On Sun, January 29, 2017 3:18 am, Marco van de Voort wrote: > In our previous episode, Lars said: > >> Assign(StdErr, 'somefile.txt') >> Rewrite(StdErr) >> >> >> And didn't seem to work >> >> >> So if you run a process and nothing prints to stdout, and there is some >> data printed to stderr, I

Re: [fpc-pascal] Something like TProcess.Environment for libraries ?

Hello. After googling, I found that it is possible to use a parameter for the linker: http://stackoverflow.com/questions/2726993/how-to-specify-preference-of-library-path For a c program: "Use the rpath option via gcc to linker - runtime library search path, will be used instead of looking in

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

On Sun, January 29, 2017 6:04 am, José Mejuto wrote: > 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 :=

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

Am 29.01.2017 23:33 schrieb "Lars" : > > On Sun, January 29, 2017 6:04 am, José Mejuto wrote: > > 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:

Re: [fpc-pascal] TProcess vs RunProcess()

On Sun, January 29, 2017 1:36 pm, Santi wrote: > Maybe ExecuteProcess is calling some kind of shell, > Freepascal developers will tell. > To call the shell you send in cmd /C FpSystem does this, but it's on unix Calling the shell is useful for not requiring absolute paths to commands...

Re: [fpc-pascal] TProcess vs RunProcess()

On Sun, January 29, 2017 10:46 am, Graeme Geldenhuys wrote: > On 2017-01-29 07:59, Lars wrote: > >> So if you run a process and nothing prints to stdout, and there is some >> data printed to stderr, I do not know how to capture it. Which makes >> me want to try TProcess instead > > > Indeed, that

Re: [fpc-pascal] TProcess vs RunProcess()

On 2017-01-29 07:59, Lars wrote: > So if you run a process and nothing prints to stdout, and there is some > data printed to stderr, I do not know how to capture it. Which makes me > want to try TProcess instead Indeed, that is one of the big differences between TProcess and ExecuteProcess. I

Re: [fpc-pascal] Pointer hashing

In our previous episode, Ryan Joseph said: > > unsigned int hash(unsigned int x) { > x = ((x >> 16) ^ x) * 0x45d9f3b; > x = ((x >> 16) ^ x) * 0x45d9f3b; > x = (x >> 16) ^ x; > return x; > } > > function Hash (x: PtrUInt): PtrUInt; > begin > x := (Power((x shr 16), x)) *

Re: [fpc-pascal] Pointer hashing

Hi, On Mon, 30 Jan 2017, Ryan Joseph wrote: > 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. > > 1) Should I cast ?pointer? as PtrUInt to get an integer from a pointer? > I?m looking for the memory address

Re: [fpc-pascal] Something like TProcess.Environment for libraries ?

fredvs wrote: > After googling, I found that it is possible to use a parameter for the > linker: > http://stackoverflow.com/questions/2726993/how-to-specify-preference-of-library-path > > For a c program: > > "Use the rpath option via gcc to linker - runtime library search path, will > be used

Re: [fpc-pascal] TProcess vs RunProcess()

Lars wrote: > But doesn't all processes report to stderr? > Ones that are created in a program do not report to stderr? > > The OS makes it optional if you want to report to stderr? Interesting.. Every process (on Windows: every non-GUI process) on maintstream OSes (and on many non-mainstream

[fpc-pascal] Pointer hashing

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. 1) Should I cast “pointer” as PtrUInt to get an integer from a pointer? I’m looking for the memory address I guess and casting seems to return a unique value.

Re: [fpc-pascal] Pointer hashing

On Sun, January 29, 2017 7:37 pm, Ryan Joseph wrote: > 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. ... > x := (Power((x shr 16), x)) * $45d9f3b; x := Power((x shr 16), x); result := The math unit, is

Re: [fpc-pascal] TProcess vs RunProcess()

Lars wrote: > Calling the shell is useful for not requiring absolute paths to > commands... which is why I like fpSystem... Never ship a program that uses fpSystem for that purpose, because it's one of the most basic security holes you can have:

[fpc-pascal] Operator overloading with Text labels or words

It's not possible to define an operator like: Operator AbcXyz(r : real; z1 : complex) z : complex; begin end; Is it? Has to be a symbol? If one could use words or text as operators this might be very interesting, although, probably a double edged sword like Lisp where you could embed

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

Hello Lars. Thanks for your brilliant light. > (and can you look into the actual source code of opus or is this closed > source?) ==> https://github.com/xiph/opus And translation into fpc-Pascal: ==> https://github.com/fredvs/uos/blob/master/src/uos_opusfile.pas Fre;D - Many thanks

Re: [fpc-pascal] ppcjvm issues

On Sun, Jan 29, 2017 at 6:04 AM, Lars wrote: > Another interesting idea, from all this discussion, is whether a mixed > Garbage Collected/Manually Collected language could exist. Object Pascal has this. Well, a kind of this idea, but works (almost) perfectly. For "garbage

Re: [fpc-pascal] DBLib was updated, rev 35345, where I can found the new dblib.dll?

On Sun, Jan 29, 2017 at 8:56 AM, Michael Van Canneyt wrote: > > > On Sat, 28 Jan 2017, Marcos Douglas B. Santos wrote: > >> Hi, >> >> I'm using FPC 3.0.1. >> I've updated my sources and saw that dblib was updated, specifically >> in revision 35345. >> >> My doubts are: >>

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

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);

Re: [fpc-pascal] TProcess vs RunProcess()

In our previous episode, Lars said: > Assign(StdErr, 'somefile.txt') > Rewrite(StdErr) > > And didn't seem to work > > So if you run a process and nothing prints to stdout, and there is some > data printed to stderr, I do not know how to capture it. Which makes me > want to try TProcess instead,

Re: [fpc-pascal] TProcess vs RunProcess()

On Fri, January 27, 2017 10:24 am, Graeme Geldenhuys wrote: > On 2017-01-26 14:28, Michael Van Canneyt wrote: > >> TProcess gives you full access to the process. You can kill it, >> pause it, write to stdin, read from stdout. >> >> These things cannot be done with RunProcess. >> That's one-shot

Re: [fpc-pascal] ppcjvm issues

On Fri, January 27, 2017 11:37 am, Dmitry Boyarintsev wrote: > On Fri, Jan 27, 2017 at 12:52 PM, Jon Foster > > wrote: > > >> Correct me if I'm wrong: It would seem like that your free >> implementation >>> doesn't actually do anything, other than fulfilling the

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

On Fri, January 27, 2017 7:54 am, fredvs wrote: > > I am not sure that a array of byte is what op_test_memory want. > It is not a pipe (like lot of other audio lib use), if it is not a array > of byte, what does he want...? > C doesn't even really have arrays since it is so low level (well this

Re: [fpc-pascal] ppcjvm issues

On Fri, January 27, 2017 10:52 am, Jon Foster wrote: > > On 01/27/2017 06:36 AM, Dmitry Boyarintsev wrote: > >> On Tue, Jan 10, 2017 at 6:14 AM, Michael Schnell > > wrote: >> >> >> >> If destroying an object is not necessary, the class should

Re: [fpc-pascal] DBLib was updated, rev 35345, where I can found the new dblib.dll?

On Sat, 28 Jan 2017, Marcos Douglas B. Santos wrote: Hi, I'm using FPC 3.0.1. I've updated my sources and saw that dblib was updated, specifically in revision 35345. My doubts are: 1. I need to update my dblib.dll too? 2. If so, I could get this new version compiled in some FTP? I checked

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

> you should specify {$PACKRECORDS C} Nice tip ! Added in each unit that deal with c libraries. Many hanks. Fre;D PS: But this did not help ;-( - Many thanks ;-) -- View this message in context: