Tomas Hajny:
> There are 3rd party Pascal units supporting work with
> other archive formats (mostly listing and decompression)
> either using shared libraries, or containing direct
> implementation of certain functionality (there has been
> e.g. unrar.pas containing a port of the original C
>
Florian Klampfl to Anton Shepelev:
> > What about the other registers -- does Turbo Pascal take
> > care of them, perhaps enveloping each expansion of an
> > inline procedure into a POPs and PUSHes?
>
> No.
Thank you for the reply, Florian. Does that mean that
Hello, all
I don't know a better place to ask this, and beg your pardon
for an off-topic post.
The Language Guide for Turbo Pascal 7.0 has this to say
about `inline' statements and proceudres:
When a normal procedure or function is called, the com-
piler generates code that pushes the
Marco van de Voort to Anton Shepelev:
> > may return the status multiplied by 256? If my child
> > process terminates with Halt(1), the status is 256, if
> > with Halt(2), the status is 512, etc.
>
> Entirely normal. Status is an opague format in POSIX, and
> t
Bernd Oppolzer:
> The story is documented in more detail here (including the
> Pascal source code of the rounding function):
>
> http://bernd-oppolzer.de/job9i032.htm
Wirth introduced the capitalisation of keywords, and you
have decided to invert his style and capitalise everything
except
Hello, all
Can anybody suggest why the function
function FpWaitPid
( pid: TPid;
var Status: cint;
Options: cint
): TPid;
may return the status multiplied by 256? If my child pro-
cess terminates with Halt(1), the status is 256, if with
Halt(2),
Marco van de Voort to Anton Shepelev:
> > The documentation on the FILE and TEXT types
> > says that "nothing prevents the programmer, from
> > writing a file driver that stores its data for
> > instance in memory." Is there a more detailed
> > in
Hello, all
The documentation on the FILE and TEXT types says
that "nothing prevents the programmer, from writing
a file driver that stores its data for instance in
memory." Is there a more detailed instruction or an
example illustrating how to do it?
--
Please, do not forward replies to
Sven Barth:
> The modes are for the case have code written for
> other compilers (TP, MacPas, Delhi, ISO) work in
> FPC (as good as reasonably possible). We do howev-
> er *not* guarantee that code written in one of
> these modes with FPC compiles or runs with the
> corresponding
Karoly Balogh to Anton Shepelev:
>>But this is from the Language guide -- a document
>>that descrbes the language in a platform-agnostic
>>way...
>
>Then you have a very different TP manual than me.
>Mine is really only for the specific 16-bit case,
>and
Karoly Balogh to Anton Shepelev:
>>According to Borland's official language guide to
>>Turbo Pascal 7.0,
>>
>> To be used as procedural values, procedures and
>> functions must be declared with a 'far' directive
>> or compiled in the '{$F+}' state.
&g
Sven Barth to Anton Shepelev:
>>According to Borland's official language guide to
>>Turbo Pascal 7.0,
>>
>> To be used as procedural values, procedures and
>> functions must be declared with a 'far' direc-
>> tive or compiled in the '{$F+}' state.
&g
Hello, all.
According to Borland's official language guide to
Turbo Pascal 7.0,
To be used as procedural values, procedures and
functions must be declared with a 'far' directive
or compiled in the '{$F+}' state.
whereas Free Pascal in -Mtp seems to accept any non-
system procedure
Marcos Douglas:
It's not difficult, but is boring have always a
parameter or function return to return an error,
and have to verify if error then... if not er-
ror... if error and error then... etc
If you mean having to write nested IFs to check all
the errors, then there are
Timothy Groves:
Can anyone think of a situation in which you would
*have* to use forward declared functions? I'm
trying to come up with an example for such for my
book, and I am drawing a blank.
Pascal User Manual and Report says:
Procecure (function) identifiers may be used be-
Felipe Monteiro de Carvalho:
If FPC Trunk also does not support this, then I'm
sure a patch to improve StringToPPChar would be
welcome.
I have created issue # 0020279.
Anton
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Andrew Haines:
I suspect that the oggenc command is failing
because TProcess behind the scenes is splitting
--output=outputfile.ogg into two params.
Yes, indeed. It is also mentioned on the WIKI:
http://wiki.freepascal.org/Executing_External_Programs
(see section
Marco van de Voort:
It should now be possible to pass the parameters
to tprocess separated. I don't remember if that
change made it to 2.4.4 though, otherwise it will
be in 2.6.0.
Thanks for letting me know.
Is the parameter separation algorithm intentionally
made to split
Hello all,
I have a plain Windows DLL made in Visual Studio C++
and working with other C applications. When I try
to statically import it into an FPC program I get
the following error:
An unexpected error occurred while initializ-
ing an application 0xc034
When using it
Ludo Brands:
Both errors indicate that the dll couldn't be
loaded. Or the dll itself isn't found, or the dll
has dependencies (probably c libraries) that
aren't found.
The DLL does work on another PC, so the problem must
be with some dependencies. Many thanks. But how
can
Ludo Brands:
Both errors indicate that the dll couldn't be
loaded. Or the dll itself isn't found, or the dll
has dependencies (probably c libraries) that
aren't found.
OK, I have found the missing dependency using
the Dependency Walker utility.
Thank you,
Anton
Brian:
What's driving me crazy is that running the two
commands via ExecuteProcess does the first step
OK, but oggenc fails with an exit code of 1, oper-
ation not permitted.
If I replace the ExecuteProcess with a call to
fpSystem, concatenating the CommandString and
Nikolay Nikolov:
[kbd_mode] only works on the linux console. It
doesn't work under xterm, gnome-terminal, konsole,
etc and we still need a way to detect if they are
in UTF-8 mode or not.
But at least that will make the IDE work correctly
in the true console... As for the graphical
Nikolay Nikolov:
Basically, all it does is, it checks if the LANG
variable contains ґUTF-8' as a substring (not sure
if it is the right way to do it, but it works for
Fedora, Ubuntu, OpenSUSE, Mandriva and latest
Debian) and if it does, it writes UTF-8 characters
to the console, by
Graeme Geldenhuys:
You are welcome to add it to the wiki.
I still do not fully understand the problem, so
please, review what I have come up with:
On Linux/Unix the FP-IDE calculates the
addresses of the drawing charactes (also
called pseudagraphics) based on the
Hello all,
I have installed FPC on a Linux machine to find that in the
virtual terminal (true text-mode, not GUI-based emulator)
FP-IDE does not dispaly pseudographics correctly. It turned
out that changes to the SFM (Screen Font Map) doesn't have
any effect inside the IDE, and I count'd
Nikolay Nikolov:
Modern FPC versions should support UTF-8 output for the
IDE. I made a patch for this, that was included in fpc
2.4.2 IIRC. Which FPC version are you using and on which
linux distro/version? What is the value of the LANG envi-
ronment variable?
I am using FPC 2.4.4
Nikolay Nikolov:
Try changing it to LANG=en_US.UTF-8
Thank you very much, it works well now. Maybe this
should be mentioned on the WIKI?
Anton
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Michael Van Canneyt:
The interface of the pipes unit can be changed
with a parameter with a default value, so existing
code continues to work.
Yes, but all the platform-specific pipe.inc files
and pipes.pp will have to be changed anyway because
the CreatePipeHandles will have a
Sorry, I forgot to say the patch is against verstion
2.4.2.
Anton
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
A little update on the subject.
Ludo Brands wrote:
If you run 'more' in a cmd window you'll notice that
'more' echoes the input but only sends to stdout when a
return is entered. I modified the program to send
'Anton'#10 and the program reads back 'Anton'#10 from std-
out.
Ludo Brands:
You can file a bug at http://bugs.freepascal.org/.
This is bug #0019325.
...
I thought about writing a patch, but it seems that it is not
enough to modify the implementation of the Windows-specific
pipes.inc.
The correct way to create pipes for the three channels (out,
in and
) DLL;
PSylPluginInfo plugin_info (void) DLL;
GInt plugin_interface_version (void) DLL;
static SylPluginInfo info =
{ Test Plugin,
0.0.1,
Anton Shepelev,
It had better work
};
void plugin_load(void)
{ printf(Ant: loaded.\n); }
void plugin_unload(void)
{ printf
Jonas Maebe:
One likely potential cause is the fact that released FPC
versions enable all floating point exceptions. Since libc
does not do that, many C programs and frameworks contain
invalid floating point operations.
Wow! Many thanks. I thought that information would be use-
less,
Rainer Stratmann:
Alternatively you can make a class or an object with the
text variable in it.
But if you need to work with only one file, you can get rid
of a global variable in the main module by just extracting
the relevant functions and the file handle into a separate
unit:
In addition to what Mattias has said,
the following works pretty well:
Program StrTest;
Var a:Pchar;
Begin
a:=PChar(nil);
Reallocmem(a,20); //ko
a[0] := 'A';
a[1] := 'n';
a[2] := 't';
a[3] := Chr(0);
WriteLn('Done: ', a);
End.
Anton
___
fpc-pascal
Ludo Brands:
You can file a bug at http://bugs.freepascal.org/
OK.
Dupicating handles isn't apparently the only solution. The
msdn sample creates non-inheritable pipes and hands these
handles simply over to createprocess, without duplicating.
There are two solutions, but only of them
Ludo Brands:
If you need these handles from the child process use:
InHnd:=GetStdHandle(STD_INPUT_HANDLE);
OutHnd:=GetStdHandle(STD_OUTPUT_HANDLE);
ErrHnd:=GetStdHandle(STD_ERROR_HANDLE);
Thank you, that's what I need.
By the way, it does work in a simple single-process applica-
tion:
SteveG:
Anton - I have attached an extract from some work-
ing code (hopefully I didnt remove anything neces-
sary)
It may help you move on a bit further
I turned your piece of code into a complete program,
but it didn't work either. In fact, there is not
much difference between your
SteveG:
This is working on Linux and WinXP
I cut what I was hoping was just the relevant code
from the unit, so it is missing a bit :)
Here's a full program made from this code:
http://pastebin.com/id90J1rY
It doesn't work for me in WinXP. What about you?
Anton
Marco van de Voort:
Why do you execute over the shell? You now pipe
your information into the shell (since that is
what you execute directly), not the program.
Thanks for the note, Marco. Unfortunately, replacing
that line with the direct path to more.com had no
effect.
When
Marco van de Voort:
When executing command-line programs via the
shell, isn't the shell's input redirected to the
program's?
Maybe. I'm pretty sure about batchfiles, but never
tried programs, that's why I thought I'd mention
the observation.
My program captures both the standard
Marco van de Voort:
I played a bit with it, but was unable to make it work. I
added a writeln of outstream.size to the running while,
and it seems output is written.
Many thanks :)
If I understood you correctly, you put
WriteLn(MoreProcess.Output.Size);
inside the waiting loop and it
Ludo Brands:
If you run 'more' in a cmd window you'll notice that
'more' echoes the input but only sends to stdout when a
return is entered. I modified the program to send
'Anton'#10 and the program reads back 'Anton'#10 from
stdout.
Thank you, Ludo, this is great!
Ludo Brands:
If you run 'more' in a cmd window you'll notice that
'more' echoes the input but only sends to stdout when a
return is entered. I modified the program to send
'Anton'#10 and the program reads back 'Anton'#10 from
stdout.
Connected with this remark, is
waldo kitty:
how about sending the ^Z line the CRLF is being sent to
indicate line breaks??
This I had tried even before posting the question :)
Ludo Brands:
I don't see where you close the mProcess.input.
In my original post I call:
MoreProcess.CloseInput();
As for the program
Ludo Brands:
Connected with this remark, is there a way to get the
underlying StdIn handle in a FreePascal program, so as
to read from it per-character, or any other way using
the OS's routines?
The handles are mProcess.Input.Handle and mProcess.Out-
put.Handle
I meant the
I wrote:
I'll try duplicating the handles and report the results.
Yes. It works now. I am creating a non-inheritable handle
using CreatePipe, then duplicating it to an inheritable one
using DuplicateHandle and pass the duplicate to the
CreateProcess funtion.
Does this mean that
Hello all,
I have been experimenting with redirection of stan-
dard I/O of child processes using FreePascal 2.4.2
on Windows. I have succeeded in capturing standard
input and standard output, but failed to feed my own
data to the child's standard input.
The child process doesn't seem to
49 matches
Mail list logo
