RE: [fpc-devel] Problem loading 2 dlls created on Free Pascal

2006-07-13 Thread Jose Manuel
 The error code is: 1930x00C1  N/A %1 is not a 
 valid Win32 application.
 But that doesn´t make sense.

Can you try indicating another address space to be loaded in the 2nd lib?

fpc-devel maillist  -

RE: [fpc-devel] Problem loading 2 dlls created on Free Pascal

2006-07-13 Thread Jose Manuel

  The error code is: 193  0x00C1  N/A %1 is not a 
 valid Win32 application.
  But that doesn?t make sense.
 See if FPC has some directive for setting the DLL baseaddress 
 and set it,
 and see if that matters.

I guess FPC is creating the DLL with no relocation section in it.
Another issue is that meaningless error. It should be Abnormal process 
termination or the like.. :-?

fpc-devel maillist  -

RE: [fpc-devel] FPC 2.0.0 vs FPC 2.0.2 (div by zero)

2006-03-16 Thread Jose Manuel



  stand for it). Anyway using Set8087CW (which is indeed CPU  
  dependant) does work under my equipment, SetExceptionMask doesn't.
 SetExceptionMask calls Set8087CW on x86, so if it doesn't work it's  
 because you either use it wrongly, or because it translates its  
 parameters wrongly to the input Set8087CW expects.

Maybe both :-)
I just was calling SetExceptionMask([exZeroDivide]), without qualifying.
OK, thanks. I'll check it, and if I find anything odd in parameter translating 
I will tell.
Anyway, don't pay me too much attention, I gotta review it all this weekend, 
but AFAICR I think I was using the DOS version under Windows XP (not a proper 
way of doing things ;-(). Sorry for the incoveniences and the loss of time. 
Anyhow I'll check it up.


fpc-devel maillist  -

RE: [fpc-devel] FPC 2.0.0 vs FPC 2.0.2 (div by zero)

2006-03-15 Thread Jose Manuel

  Set8087CW() in system unit
  SetExceptionMask() in unit math
 It was for MacOsX we needed to get rid of libc,
 I guess Set8087CW($133F) is not CPU independant (PowerPC,x86_64),

AFAIK, x86_32 will do too!!

 so I will use

I do agree it's much polite and cross platform, but doesn't seem to work in 
Windows XP Pro (only tested in WinXP Pro SP2) with GL 3.2 and FPC 2.0.2 (I've 
looked everywhere down my PC for a version number, but not found :-), I guess 
it oughtta be 4.1 but I can't stand for it). Anyway using Set8087CW (which is 
indeed CPU dependant) does work under my equipment, SetExceptionMask doesn't.

 I hope MacOsX is happier now (don't have one, so don't know)

Just to make it know (as a primarily Win NT user). I really don't know whether 
it is as it should be or it should be fixed :-?. A plain Win user as me 
normally use syscalls to the API, but I'm afraid it's comprimising 
compatability issues. Masters will tell, I hope :-)
 kind regards,

fpc-devel maillist  -

RE: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread Jose Manuel

 Well I will typically spend about 25% of my development time with
 forward declarations, doing loads of try finaly blocks to free memory
 and other things instead of implementing my application.


Well, you are quite a machine. If you say so, sure it's so, but that's not
the problem. Anyhow there are tools, editors, etc. that can easy that fact
if you feel confortable with then.
I usually spend under 5% typing my code, I spend a lot longer thinking what
I have to type, and I DO spend quite longer debugging and improving my code.
And herebye I challenge any C Coder to maintain a program faster and neater
than in Pascal (I say C, 'cause your comments about Python and other script
language I assume it's a joke).

Anyway as Michael would say, a can of worms has been opened and we are not
going anywhere. If you want to stick to Python, stick to it, but Pascal is
another thing.


BTW: Never heard of anybody doing serious programming in GNU Pascal (and I
know many a programmer doing serious programming in FPC and even VP)

fpc-devel maillist  -

RE: [fpc-devel] Modernising Pascal

2005-02-22 Thread Jose Manuel

 (note I did not use a T in front of StringList so as to distinguish it 
 from non-base types and also to maintain backwards compatibility with 
 existing code that uses TStringList conventionally)

Are you always drunk?

fpc-devel maillist  -

RE: [fpc-devel] TShiftState as enum

2005-02-17 Thread Jose Manuel

 Can somebody enlighten me, what code exactly fails in D6?
 What extension does FPC have, that Delphi doesn't have?

 And what iteration is desired? I'd use: For Low(x) To High(x)...

 Let me add some more notes, regarding Delphi compatibility:

 Older Delphi (and TP?) versions implemented sets of subranges (e.g. set
 of 510..515)

i don't want to become heavy, but a subrange it's a subrange and a set is a
If you'd use Low() and High(), your treating a set as if it were an array,
that can be handy sometimes, but strictly speaking, a set has no lower or
higher elements.
As far as I can remember, in TP, sets were represented with a single byte,
that is, the 255 bits were on or off (1 or 0) and represented the existance
or the lack of it in the set.
AFAICK, you can check for a determinate value in a set, but you can't
navigate through it as if it were an array. OK, you can use Boolean
operators (Union, Intersection, Rest...) and the Include, Exclude functions,
etc..., if you feel more comfortable. But there's no firt element, there are
no repeated elements, etc... It's a set

 AFAIR D6 introduced open enums, with arbitrary (discontinuous...)
 values for the members. IMO this only is an attempt to closer reflect C
 enums, but sets of such enumerated types are not allowed.

That's right. Enumerated open types (C-alike), such as (GREY=14, RED,
BLUE=21, ...) were introduced in D6, but anyway don?t have nothing to do
with sets.

 I do not ask for any compatibility in these cases, in detail when the
 Delphi implementation differs amongst compiler versions.

I really don't know, but I guess you are right, it must be a compiler


fpc-devel maillist  -

RE: [fpc-devel] compiler bug?

2005-01-02 Thread Jose Manuel

 I think it's slightly subtler. I guess that this code:

   if not b then
   else if b then

 ...could throw a different result.

 IIRC, any non-zero value is evaluated as True for a Boolean
 variable. The

No, and no. There your assuming some implementation of the type Boolean.
I Peter stated, bitwise logic and Boolean logic are neatly separated in
Pacal. You say you're not counting on how it's implemented and still insists
in expressions as True  0. No way.

 problem with the case statement is that Jesús is asking the
 compiler which
 specific value it chooses for assignements... and getting
 surprised because
 it's not what he expected. I guess the compiler uses 1 instead of
 255. But

Dodi told you, Peter told you and I tell you now. Don't guess anything about
how a compiler internally implementens a type. Peter could have said so
louder but not clearer: if you cast a type into another type that can result
in an overflow, it's programmer's fault, 'cause at least in Pascal
(exceptions apart) those cast have to be done explicitly. And you can't
trust wheter True is 255, 1, -1 or use simply another bit pattern or
whathever, which is perfectly legal, Don't ya say you agree with everyone
when you are clearly on the contrary.

I think this is goin' far behind this list is intended to. All I can say is
that there should be some kind of compatibility for those who, as me (:-(
guilty), sometimes recurre to Fix'n Dirty, I mean: FPC (at least in FPCOBJ
or DELPHI compatibilty mode), Kilyx and Delphy should behave the same, but
as long as Kylix and Delphi don't keep the same (sane?) behaviour, it's up
to you, FPC developers to choose what you find more (efficient?, accurate to
reality, compatible? I dunno, but surely you do)
Anyway, I think it's pointless to go on with this

 it's surely documented anyway.

The internal implementation of a Boolean type, I guess it ain't? Surely for
every compiler it is, but there's no standard way and I'm quite sure there's
no standard how it should behave when typecasting.


 Nico Aragón

Bye, Nico and everyone.


BTW: I don't wish everyone Happy Christmas 'cause there are a lot of
religions, and to too many of them, Christmas has no sense. Anyhow my best
wishes to everyone

For Dodi's Sake (What he asked Nico about his 'rudimentary spanish'), and to
anyone who might be interested:

a) ¡Hola, Torpedo!
That's slang. You could translate it into 'Hi, Dork!'

b) Feliz Año:
In effect, it's the same as in English: It means merely: 'Happy new year!'

fpc-devel maillist  -

RE: [fpc-devel] compiler bug?

2005-01-01 Thread Jose Manuel

 3: the PASCAL way
   boolean is a totally seperate type from integer types so the compiler
 knows whether you mean logial or bitwise operations. I don't know if false

That's the point. :-)

 and true having ordinal values of 0 and 1 is part of a standard or a
 borlandism but im pretty sure its what all pascal compilers anyone cares
 about do.

So i think. I think Ord(TRUE), Succ(FALSE), etc. are valid Standard and
Extended Pascal expressions, as well as the behaviour of a declarion of type
TBoolArray = array[boolean] of ... is neatly defined in the very language.
(At least in Modula-2, that enumeration is part of the standard, so it's a
language feature and not compiler implementation dependant).


fpc-devel maillist  -

RE: [fpc-devel] compiler bug?

2004-12-31 Thread Jose Manuel

  This better should read:
  WriteLn('corrupt data space!!!'); Panic;

 Much more useful :-

(AFAIK) you do.
You're programing, the C way.

You can't expect that -1 equals True, and any other value equals false, (I
really dunno, but I think I  could remember that) in Visual Basic is 1
instead of -1). As far as I can know Boolean type is in Pascal, that, a
type. I think there's no specifation how the compiler (ANSI PASCAL, ANSI
PASCAL 2) should implement that. (IMHO bad programming pratice)

If anyone goes on wild (and explicity) casting integer, enumerated, etc..
types into booleans, of course, many things may happen. But I reiterate, as
far as I can know, that is compiler implementation dependent, and one can't
depend on it.

Hower, should my opinion serve to anybody, I think that Kylix, Borland anf
FPC (according to contionals Delphi, ObjFpc, etc) should share the same
behoviour. As long as compatibility is broken between Delphy and Kylix, it's
up to you.

But, and I beg everyone's pardon if I' too dork, This is Pacal, Not C. I
can't really find out why I would need ro cast Boolean(Integer(255)= into a
boolean, and I guess that if I knew, I would surely programming in C.

fpc-devel maillist  -

RE: [fpc-devel] compiler bug?

2004-12-31 Thread Jose Manuel
  You're programing, the C way.

  You can't expect that -1 equals True, and any other value
 equals false, (I

 You can expect whatever it's documented equals true and
 sometimes you must

That's right. I can expect whatever is documented. In C there's no boolean
type. In Pascal (as in C++), boolean type is on its own.
If you typecast an integer to a boolean you are on you own, Maybe I'm wrong
but AFAIK there's no documented way how a Pascal Compiler ought to implement
Boolean Types. (Not to say Windows 1,2,4 bytes Booleans)

 know what's the internal representation of the data, i.e. when
 you're linking
 with code written in different languages or writing inline assembler.

You can't depend on the internal representation of any data. Maybe a quick
and dirty fix, but no further
Pascal is Pascal. Clearity and type safe. Anyway Pascal allows that
(explicit, it's gotta be explicit) conversion, try it in ADA.
I'm afraid your a C(ecer).
And assembler ... Well! We all have to resort to assembler some time or
later. But I see no relation.

 ¡Feliz año, torpedo! :-)
Posdepué d'aberhablaó contigo estoy un pelín disgustaó
Recuerdo2 patiytuhijo


 Nico Aragón

 fpc-devel maillist  -

fpc-devel maillist  -