Original-Nachricht
> Datum: Wed, 13 Aug 2008 22:03:23 +0100
> Von: Jonas Maebe <[EMAIL PROTECTED]>
> An: FPC-Pascal users discussions
> Betreff: Re: [fpc-pascal] Converting C\'s bit field struct
>
> On 13 Aug 2008, at 11:59, Vinzent Höfler wrote:
>
> > Should be something like
On 13 Aug 2008, at 11:59, Vinzent Höfler wrote:
leledumbo wrote:
Since no one answers on message board, I'll post it here.
C struct:
typedef unsigned int u32int;
typedef struct page
{
u32int present: 1; // Page present in memory
u32int rw : 1; // Read-only if clear, readwrite
In our previous episode, SirStorm25 said:
>
> Nooo!
> What are these functions meant to do?
> This seems way more harder than it looks!
Well that is not that hard:
do_read - read bytes from file
do_write - write bytes to file
do_close - close file
do_erase - open file
do_rename - rename
Nooo!
What are these functions meant to do?
This seems way more harder than it looks!
Regards
SirStorm25.
--
View this message in context:
http://www.nabble.com/FPC_HAS_FEATURE_TEXTIO---Strange-behaviour%21-tp18968260p18970979.html
Sent from the Free Pascal - General mailing list archive at
In our previous episode, SirStorm25 said:
>
> Would the OS still compile if I removed the
> syscopytodos and syscopyfromdos functions from
> the do_ procedures?
Yes of course. It wouldn't work though.
___
fpc-pascal maillist - fpc-pascal@lists.freepas
Would the OS still compile if I removed the
syscopytodos and syscopyfromdos functions from
the do_ procedures?
--
View this message in context:
http://www.nabble.com/FPC_HAS_FEATURE_TEXTIO---Strange-behaviour%21-tp18968260p18970901.html
Sent from the Free Pascal - General mailing list archive at
In our previous episode, SirStorm25 said:
>
> The only problem I've found, is that the do_ procedures contain a line of
> code:
> syscopytodos, which seems to be specific to dos, any ideas as to where
> this function is stored?
In go32v2, but they are very dos specific. Remember, this is the dos
The only problem I've found, is that the do_ procedures contain a line of
code:
syscopytodos, which seems to be specific to dos, any ideas as to where
this function is stored?
Regards
SirStorm25.
--
View this message in context:
http://www.nabble.com/FPC_HAS_FEATURE_TEXTIO---Strange-behaviour%2
> |if not SomeFunction <> Constant_Of_Sometype then {null};
Of course, usually it's without the "not"... ;) And with Boolean functions it's
a bit easier.
And I should have added that I never put in comments what I can easily put in
code. At first, comments don't get compiled, and second, nobod
Original-Nachricht
> Datum: Wed, 13 Aug 2008 16:02:10 -0400
> Von: Jeff Wormsley <[EMAIL PROTECTED]>
> An: FPC-Pascal users discussions
> Betreff: Re: [fpc-pascal] Compiler option to check return value ignorance
>
> Vinzent Höfler wrote:
> > I just grep'ped the actual sources o
In our previous episode, SirStorm25 said:
>
> Found em!
> The finaly question is: where do I put these?
> do I create my own sysfile.inc with just these functions, or do they rely on
> other functions located within the same file?
Yes, usually per OS the porter maintains a rtl/ dir for general OS
Vinzent Höfler wrote:
I just grep'ped the actual sources of the project (about 70K LOC) and
I found exactly four occurences of my "if Ignore_Result() then
{null};" pattern with FPC runtime routines. There are others, but
those routines access hardware and on some occasions I really need to
ig
Found em!
The finaly question is: where do I put these?
do I create my own sysfile.inc with just these functions, or do they rely on
other functions located within the same file?
Regards
SirStorm25.
--
View this message in context:
http://www.nabble.com/FPC_HAS_FEATURE_TEXTIO---Strange-behavio
On 13 Aug 08, at 11:47, SirStorm25 wrote:
> Marco van de Voort wrote:
> >
> > In our previous episode, SirStorm25 said:
> >> Im trying to develop reading capabilities for an OS im helping to
> >> develop.
> >> When enabling the FPC_HAS_FEATURE_TEXTIO from the RTL, I get a few errors
> >> involving
In our previous episode, SirStorm25 said:
> Any ideas where to find the source to a version of DOS with those functions
> implemented, linux source code always gets me confused %-|
They are not implemented in dos but FOR dos, in the Free Pascal RTL, dos
version, dir rtl/go32v2
Marco van de Voort wrote:
>
> In our previous episode, SirStorm25 said:
>> Im trying to develop reading capabilities for an OS im helping to
>> develop.
>> When enabling the FPC_HAS_FEATURE_TEXTIO from the RTL, I get a few errors
>> involving
>> the file: Text.inc.
>> All of the errors returned
Hi!
> Does anyone have the specification for the .bin (binary) file type?
No. Because there is no such ".bin format".
File name extensions (e.g. ".bin") are NOT the file format[1] (e.g. JPEG
image)!
Unfortunately Windows strives to let people assume that, but it is
wrong. The extension is an ar
Vinzent Höfler schreef:
Vincent Snijders wrote:
Vinzent Höfler schreef:
Joost van der Sluis wrote:
Ok, so I misunderstood you. You want that the compiler complains if you
don't assign the result of a function. While that can be done, I don't
think you want that.
Well, don't decide for other
In our previous episode, SirStorm25 said:
> Does anyone have the specification for the .bin (binary) file type?
Depends. If you mean in an executable format, then it is usually already
relocated code, to be loaded on some OS dependant address.
Some variants also have hints for load address and/or
In our previous episode, SirStorm25 said:
> Im trying to develop reading capabilities for an OS im helping to develop.
> When enabling the FPC_HAS_FEATURE_TEXTIO from the RTL, I get a few errors
> involving
> the file: Text.inc.
> All of the errors returned are mainly "do_" functions.
> E.g:
> do_r
Vincent Snijders wrote:
Vinzent Höfler schreef:
Joost van der Sluis wrote:
Ok, so I misunderstood you. You want that the compiler complains if you
don't assign the result of a function. While that can be done, I don't
think you want that.
Well, don't decide for others, please. I am a stupid
Hi All!!!
Im trying to develop reading capabilities for an OS im helping to develop.
When enabling the FPC_HAS_FEATURE_TEXTIO from the RTL, I get a few errors
involving
the file: Text.inc.
All of the errors returned are mainly "do_" functions.
E.g:
do_read
do_write
do_close
do_erase
dp_rename
etc
Hi all!
Does anyone have the specification for the .bin (binary) file type?
Regards
SirStorm25.
--
View this message in context:
http://www.nabble.com/Understanding-the-.bin-format-tp18968139p18968139.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
__
Vinzent Höfler schreef:
Joost van der Sluis wrote:
Ok, so I misunderstood you. You want that the compiler complains if you
don't assign the result of a function. While that can be done, I don't
think you want that.
Well, don't decide for others, please. I am a stupid programmmer, I am
making
Joost van der Sluis wrote:
Ok, so I misunderstood you. You want that the compiler complains if you
don't assign the result of a function. While that can be done, I don't
think you want that.
Well, don't decide for others, please. I am a stupid programmmer, I am
making mistakes all the time, a
> Yes, that was it =)
>
> Excellent. I assumed it wasn't merged because no answer was given to my
> e-mail.
>
> This is pretty good for that part of the book =)
Well, that fix, and the win32/win64 can use more than 2GB fix (peflags
directive) should be the only differences between rc2 and the f
Yes, that was it =)
Excellent. I assumed it wasn't merged because no answer was given to my e-mail.
This is pretty good for that part of the book =)
thank you,
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Felipe Monteiro de Carvalho schreef:
Umm ... so can I assume that it wasn't merged?
Maybe it could at least be merged to 2.2.3
What revision do you want to be merged. I thought r11434, but that has made it all
the way into fpc 2.2.2, as far as I can see:
http://svn.freepascal.org/cgi-bin/vie
Umm ... so can I assume that it wasn't merged?
Maybe it could at least be merged to 2.2.3
thanks,
On Tue, Jul 22, 2008 at 12:58 PM, Felipe Monteiro de Carvalho
<[EMAIL PROTECTED]> wrote:
> On Tue, Jul 22, 2008 at 10:59 AM, Marco van de Voort <[EMAIL PROTECTED]>
> wrote:
>> Fixed, added some mor
Op woensdag 13-08-2008 om 02:52 uur [tijdzone -0700], schreef leledumbo:
>
> Joost van der Sluis wrote:
> >
> > And there's no way the compiler can detect this.
> >
> I don't think so. The compiler understand that a procedure doesn't return a
> value while a function does (i.e. trying to return
Felipe Monteiro de Carvalho wrote:
On Tue, Aug 12, 2008 at 2:34 PM, Jeff Wormsley <[EMAIL PROTECTED]> wrote:
Does this support MIPS based CE devices, or only ARM?
Most people are using ARM, and that's what the pre-compiled compiler is for.
Some people experiment with x8
Richard Ward schreef:
I can't seem get through to the Laz snapshot page which is provided from
the Wiki page.
http://www.de.freepascal.org/lazarus/
That is an old link. IT should be http://www.hu.freepascal.org/lazarus/
Where did you find that link?
Vincent
I can't seem get through to the Laz snapshot page which is provided
from the Wiki page.
http://www.de.freepascal.org/lazarus/
Thank you for posting links to all the Laz info. That makes things
much easier :)
-R Ward
___
fpc-pascal maillist -
Zitat von Vinzent Höfler <[EMAIL PROTECTED]>:
> Mattias Gärtner wrote:
> > Zitat von Vinzent Höfler <[EMAIL PROTECTED]>:
> >
> >> [...]
> > a: record end;
> >>> Thanks. I will use that.
> >> What for? The C statement is empty, it's not a variable and not even a
> >> type. So before tran
Hello,
Am 13.08.2008 um 13:23 schrieb Vincent Snijders:
Michael Van Canneyt schreef:
On Wed, 13 Aug 2008, leledumbo wrote:
Found on the net that Pascal doesn't provide it :-((
What if FPC creates it as an extension =)?
FPC has it, but only in MacPas mode.
I copied the example program from
Mattias Gärtner wrote:
Zitat von Vinzent Höfler <[EMAIL PROTECTED]>:
[...]
a: record end;
Thanks. I will use that.
What for? The C statement is empty, it's not a variable and not even a
type. So before translating that into an empty Pascal-record, you should
rather look at what the actual
Michael Van Canneyt schreef:
On Wed, 13 Aug 2008, leledumbo wrote:
Found on the net that Pascal doesn't provide it :-((
What if FPC creates it as an extension =)?
FPC has it, but only in MacPas mode.
I copied the example program from: http://qc.codegear.com/wc/qcmain.aspx?d=56480
Added
On Wed, 13 Aug 2008, leledumbo wrote:
>
> Found on the net that Pascal doesn't provide it :-((
> What if FPC creates it as an extension =)?
FPC has it, but only in MacPas mode.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
ht
Zitat von Vinzent Höfler <[EMAIL PROTECTED]>:
>[...]
> >>> a: record end;
> >
> > Thanks. I will use that.
>
> What for? The C statement is empty, it's not a variable and not even a
> type. So before translating that into an empty Pascal-record, you should
> rather look at what the actually use
Vincent Snijders wrote:
>
> FPC supports bitpacked records. I cannot find it in the docs right now.
>
Oh... didn't know if such a thing exists.
Vinzent Höfler wrote:
>
> type
> Unsigned_7 = 0 .. (1 shl 7) - 1;
> Unsigned_20 = 0 .. (1 shl 20) - 1;
>
> type
> page_t = bitpacked r
leledumbo wrote:
>
> Well, for the iso... I guess it's possible to read files stored in it.
> Grub can read menu.cfg, so why can't we? The problem is... how?
>
If we could get those functions working it might be possible, but text.inc
doesn't like to be compiled in this case :-( . If we coul
leledumbo wrote:
Vinzent Höfler wrote:
Yes. Turn Extended Syntax off {$X-}, then a function result must be
assigned to a variable. At least it used to be that way.
...
so "inherited Create" did not compile anymore (and I remember that any
attempt to assign this "result" to a dummy variable ev
Vinzent Höfler wrote:
>
> Yes. Turn Extended Syntax off {$X-}, then a function result must be
> assigned to a variable. At least it used to be that way.
> ...
> so "inherited Create" did not compile anymore (and I remember that any
> attempt to assign this "result" to a dummy variable even fai
leledumbo wrote:
Since no one answers on message board, I'll post it here.
C struct:
typedef unsigned int u32int;
typedef struct page
{
u32int present: 1; // Page present in memory
u32int rw : 1; // Read-only if clear, readwrite if set
u32int user : 1; // Super
leledumbo schreef:
Found on the net that Pascal doesn't provide it :-((
What if FPC creates it as an extension =)?
FPC supports bitpacked records. I cannot find it in the docs right now.
Vincent
___
fpc-pascal maillist - fpc-pascal@lists.freepasca
Felipe Monteiro de Carvalho wrote:
On Wed, Aug 13, 2008 at 7:38 AM, Vinzent Höfler
<[EMAIL PROTECTED]> wrote:
What for? The C statement is empty, it's not a variable and not even a type.
So before translating that into an empty Pascal-record, you should rather
look at what the actually used stru
Found on the net that Pascal doesn't provide it :-((
What if FPC creates it as an extension =)?
--
View this message in context:
http://www.nabble.com/Converting-C%27s-bit-field-struct-tp18959002p18960630.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
On Wed, Aug 13, 2008 at 7:38 AM, Vinzent Höfler
<[EMAIL PROTECTED]> wrote:
> What for? The C statement is empty, it's not a variable and not even a type.
> So before translating that into an empty Pascal-record, you should rather
> look at what the actually used structur in the C-code is.
It is us
Since no one answers on message board, I'll post it here.
C struct:
typedef unsigned int u32int;
typedef struct page
{
u32int present: 1; // Page present in memory
u32int rw : 1; // Read-only if clear, readwrite if set
u32int user : 1; // Supervisor level only i
Mattias Gaertner wrote:
On Tue, 12 Aug 2008 09:39:36 +0200
Jilani Khaldi <[EMAIL PROTECTED]> wrote:
Marc Weustink wrote:
Micha Nelissen wrote:
Mattias Gärtner wrote:
How to translate this:
struct a;
Isn't this a forward declaration? So sometime later it needs to
declare 'struct a { ... };'
leledumbo wrote:
Joost van der Sluis wrote:
And there's no way the compiler can detect this.
I don't think so. The compiler understand that a procedure doesn't return a
value while a function does (i.e. trying to return a value from a procedure
causes compile error). I haven't checked how com
Well, for the iso... I guess it's possible to read files stored in it. Grub
can read menu.cfg, so why can't we? The problem is... how?
--
View this message in context:
http://www.nabble.com/Help-with-Free-Pascal---RTL%21%21-tp18952131p18960532.html
Sent from the Free Pascal - General mailing lis
leledumbo wrote:
>
>
> SirStorm25 wrote:
>>
>> so, I have to change {$undef FPC_HAS_FEATURE_TEXTIO} in system.pas to
>> {$define FPC_HAS_FEATURE_TEXTIO} ?
>>
> Well... just try it =^D
> How can you use file related functions without any file system support
> (don't worry, I'm working on it B
SirStorm25 wrote:
>
> so, I have to change {$undef FPC_HAS_FEATURE_TEXTIO} in system.pas to
> {$define FPC_HAS_FEATURE_TEXTIO} ?
>
Well... just try it =^D
How can you use file related functions without any file system support
(don't worry, I'm working on it B-))?
--
View this message in contex
leledumbo wrote:
>
> Hello SirStorm25
>
> Didn't expect to see you here. Check the top of system unit and
> systemh.inc and you'll find out why.
>
Neither did I!!!
I think I get it now :) , so, I have to change {$undef
FPC_HAS_FEATURE_TEXTIO} in system.pas to {$define FPC_HAS_FEATURE_TEXTIO
Joost van der Sluis wrote:
>
> And there's no way the compiler can detect this.
>
I don't think so. The compiler understand that a procedure doesn't return a
value while a function does (i.e. trying to return a value from a procedure
causes compile error). I haven't checked how compiler formats
Op woensdag 13-08-2008 om 01:27 uur [tijdzone -0700], schreef leledumbo:
>
> Sometimes we forgot whether a function argument is passed by reference
> or by
> value. What if the result is actually important? For instance,
> consider the
> following (WARNING: True story):
That's not so strange sto
Sometimes we forgot whether a function argument is passed by reference or by
value. What if the result is actually important? For instance, consider the
following (WARNING: True story):
function Align(Addr: Pointer; Alignment: PtrUInt): Pointer;
then we forgot that Addr is passed by value, so in
Hello SirStorm25
Didn't expect to see you here. Check the top of system unit and systemh.inc
and you'll find out why.
--
View this message in context:
http://www.nabble.com/Help-with-Free-Pascal---RTL%21%21-tp18952131p18958772.html
Sent from the Free Pascal - General mailing list archive at Nab
yeah...I've read all the PDFs under the folder.They are quite useful.
thanks.
2008/8/13, Francisco Reyes <[EMAIL PROTECTED]>:
>
> On 10:29 pm 08/11/08 "Galloplus Chang" <[EMAIL PROTECTED]> wrote:
> > Would you please recommand some useful reference books for Free
> > Pascal or other Pascal-relate
60 matches
Mail list logo
