RE: [fpc-devel] Problem loading 2 dlls created on Free Pascal
> > 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 - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Problem loading 2 dlls created on Free Pascal
> 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 - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] FPC 2.0.0 vs FPC 2.0.2 (div by zero)
> >> Math.SetExceptionMask([exDenormalized,exInvalidOp,exOverflow,e > >> xPrecision,exUnderflow,exZeroDivide]); [...] > > 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. Thanx, JMR ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] FPC 2.0.0 vs FPC 2.0.2 (div by zero)
> > 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 > Math.SetExceptionMask([exDenormalized,exInvalidOp,exOverflow,e > xPrecision,exUnderflow,exZeroDivide]); 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, > Regards, JMR ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Re: [fpc-l] type discussion
> > 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. > > jamie. 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. JMR P.S.: 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 - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Modernising Pascal
> (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) > > > jamie. Are you always drunk? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] TShiftState as enum
> > 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 set. 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 dependence. JMR ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] TShiftState as enum
> Jose Manuel wrote: > > >I think sets are sets and enumerated types are enumerated types, > and Pascal > >is Pascal- > > > > > Ok, but in pascal the elements in a set can only be of ordered > type anyway. Yes, of course. Maybe I haven't explained myself. Indeed, and you are quite right you'got to define a set of ... (an scalar or enumerated type you've previously defined), but once you're created the set is a "set", there are no order established. I think this is no place nor time to talk about Cantor or whether a subset is part of itself, etc. I just keep on my opinion (until you refuse me with arguments, and I will accept them gratefully, don't doubt on that), that casting that way is against Pascal's spirit (and against Boolean Algebra, I think). Anyway, it's only my opinion. As Michael would say, there are more (and more neccessary) things to do than to speak in this list about angels' sex. JMR ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] TShiftState as enum
> > > > > > > TShiftStateEnum = (...) > > > > TShiftState = set of TShiftStateEnum; > > > > > > > > ? > > > > > > Of course that is possible. It requires some imagination though (and > > > a feel for obfuscated Pascal) > > > > > > The example fails in Delphi 6 btw, but works in FPC :-) > > Interesting :) > > But in this case: why not simply add one line to classes.pp? > > > > Delphi does not allow low/high on sets > > > > (I vote to keep this FPC extension btw) > > Yes. Well, sets are by definition a kind of bag. No enumeration or any kind of order are suited to sets. Can be handy, I agree, under certain situations, but then we are getting back to C. I think sets are sets and enumerated types are enumerated types, and Pascal is Pascal- > Mattias Only IMHO, of course JMR ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
> I think it's slightly subtler. I guess that this code:
>
> if not b then
> WriteLn('False')
> else if b then
> WriteLn('True')
> else
> WriteLn('Other');
>
> ...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.
>
> --
> saludos,
>
> Nico Aragón
Bye, Nico and everyone.
--
JMR
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 - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
> 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). JMR ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
[] > > 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. ¡Chapuzas! 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 > > -- > saludos, > > Nico Aragón > http://espira.net/nico/ > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
>
> > > else
> > > WriteLn('Other');
> >
> > 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 - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
