• Welcome to Jose's Read Only Forum 2023.

Edwins Tools (Incl. PBDev)

Started by Theo Gottwald, February 29, 2016, 03:44:59 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Theo Gottwald

Here is a Site with Downloads from Edwin Knoppert.
Also a version of PwrDev for PureBasic can be downloaded.
I did not try if it works.

Edwins Tools

Bob Houle

Still works.  :)

The odd time, you'll have to adjust the generated code.

Still the nicest Visual Designer for ease of use and getting out of the way.


Theo Gottwald

Can you give me a hint what exactly needs to be modified?
Also, IS PwrDev now Free or not?

Bob Houle

I complies most times, with no problems, but a few keywords have changed slightly.
eg... Renamed Frame3DGadget() to FrameGadget() (since ALL frames were now always 3D )

No, PrwDev was never free (as far as I know)

but PBDev is.  ;D


Theo Gottwald

And what is the difference? PBDev and PwrDev ?

Bob Houle

Two completely different programs  :)

PwrDev - PowerBASIC Visual Designer

PBDev - PureBasic Visual Designer

Theo Gottwald

What exactly does need to be changed to make it work with the newest PureBasic version?

Bob Houle

You cannot tell what PBDev needs until you compile your program.

If there's a problem, the PureBasic compiler will point you in the right direction.

Remember PBDev is 7 years old (2009) and PureBasic has improved. Expecting PBDev to
be totally compatible is not going to happen.... but it's still very usable to me.

Because PureBasic is the best programming language out there {grin} and has the most
liberal licensing system (lifetime license)... you can download the version that IS TOTALLY

All you need to do is go to the "museum"and download: Version 4.31 - (June 2009)
Then everything will run fine.  :)

PS - Many users have more than one version of PureBasic installed on their computer.

Simply put different versions in different directories.
C:\PureBasic542, etc.
same as 32-bit and 64-bit

Theo Gottwald

I will not pay for the design flaws of Fred, with the installation of several PureBasic versions.
With the last release they have made some small improvements in teh builtin VD, so it does not generate
such a buggy code like before.
Possibly it can be used for simple Forms.

For the Rest currently i have to stick with Firefly.

Bob Houle

QuoteI will not pay for the design flaws of Fred, with the installation of several PureBasic versions.

Stop being so melodramatic  ;D

If I design a program in with version 1 of my favorite compiler, and it works... fine, it'll work for a long time.
There are no guarantees however (remember all the *.hlp files... they no longer open in Windows 7 or later)
I guess you should insist Microsoft fixes their design flaws.  ;)

In this case, you could blame Edwin for designing a program that doesn't work properly, but somehow I think he may have some choice words for you.

Theo Gottwald

i wrote something about Microsoft in the PureBasic Forum, and here also.
Go and read it. Its about the "design flaws" of Windows 10. And they are numerous.
My conclusion was "Any windows since Windows 2000 was worse then the windows before".
Ok, that my opinion.

Now back to PureBasic. I think that PureBasic developed much better then windows.
I did never regret that i bought it - possibly as one of the first customers.
And i possibly would buy it again because its very cheap for what it offers.

Besides that it has some design flaws. Before i start and you feel insulted - which is NOT my intention,
get this book and read it.
Book on compiler architecture

For me they are openly visible. Because i come from PowerBasic.
But if you come from Visual Studio - it will not be of much difference.

In PowerBasic we have an unbelievable backwards compatibility since at least version 6.

In PureBasic - and i watch this for long time -
with each new version, you have to watch for all user-libraries to be updated.

Problem is that many of them are not beeing updated.

In my opinion:
If the "core compiler/assembler" would have been designed professional,
not from a hobbyist, that Fred was at this time when he started PureBasic -
the compatibility would be much greater over the years.

And we would not have the architecture like it still basically has.

Of corse now he changes here and there with any version a bit to handle the shortcomings.
And exactly these small architectural changes break the compatibility.
Normally a clean cut and a clean redsign - possibly with a new name (and an new licence?)
would be the way out of this.

Instead of doing a clean cut and having a real "compiler core" that does not need to change ever.

Just an example:
The handling of local variables "on the stack" prevents the use of "CALL RET" inside prodcedures.
Go out and search a second compiler using this system.
You will never find one, because this is just not "how things are done".
Nobody will implement it like this.

If you don't believe me get a university course on compiler building. Thats just what he never did.
So besides all the good things (libraries etc.) there are some basic desgin flaws that
he defends like they are for any reason.

But the reason is just historic and its not easy to change.
Because it would need a clean cut and a clean system-design.

And now he changes here and there and as a result these changes prevent a better compatibility betwen the versions.

I think you need to understand that i am coming from a scientific standpoint.
Read in the PureBasic Forum. I am definitely not alone with this opinion.

These things that you learn in university have been proofed to work over the last years.
Did you know that  "compiler building" is already a science?

CPU's are designed in a way to support building of compilers.

In some places - and that includes the handling of local variables. the construction of Loops and conditions, at least there you have to hold the "rules".
Because they are built in the CPU and ANY compiler out there will also do it in the same way.

There are rules you can learn, these are scientific standards.
You can't make a program that does not support floating point number in a FOR .. NEXT Loop and say "this is a compiler".
Your professor will kick you out of the course in that schoool. Its just a Basic design flaw.

Why should it not be allowed to talk about this?

If you say "Ok, its a Macro Assembler" then the same program will be Ok.
But its just not a "state oif the art" compiler - and you will also not find a second one with these design flaws out there.

Other then in hobbyist projects. Thats something you can try yourself.
Go and find one.

PS: I should really write a book on that :-) while there are already some ...

Bob Houle

Well let's agree to disagree  ;)

But you are "really" hung up on For/Next loops and floating point numbers..
QuoteYou can't make a program that does not support floating point number in a FOR .. NEXT Loop and say "this is a compiler".

but I believe floating point numbers can cause problems here...
because they ARE floating point numbers...
but that's just me (and Fred as well)  ;)

Since we are quoting Computer Science....

QuoteFrom the IEEE Standard...

Rounding Errors...

Squeezing infinitely many real numbers into a finite number of bits requires an approximate representation. Although there are infinitely many integers, in most programs the result of integer computations can be stored in 32 bits. In contrast, given any fixed number of bits, most calculations with real numbers will produce quantities that cannot be exactly represented using that many bits. Therefore the result of a floating-point calculation must often be rounded in order to fit back into its finite representation. This rounding error is the characteristic feature of floating-point computation.

Theo Gottwald

Hahaha ... of course there are rounding errors.

What you say here is that you can not construct a FOR .. NEXT Loop (like PowerBasic and any other compiler can) because of possible rounding errors?

Thats why i said "Get the book".
Look others can.  ;D

PS: Now we get to the real topics. Maybe there are missunderstandings somewhere?
"Rounding errors" ? ::)

Bob Houle

From PureBasic forum...

It's a bad policy to use floating point variables for loop counters and loop increments.

Loop counts are, by definition, integral values. So even if floating point values are needed in the loop, the actual counting should always be done using integer values.

This will prevent rounding errors from causing incorrect loop counts.

So instead of trying to use:
    For A.d = 1 To 1.1 Step 0.05

Use the following instead and, if needed, scale the value of the loop counter back to a floating point value.

For X.i = 100 To 110 Step 5
. A = X / 100

No use introducing a potential 'rounding error' bug that would be very hard to trace.  :)

Theo Gottwald

Bob, I know that.
There are multiple such things that you need to do workarounds because "Fred doesn't like it".
While i am religiouse, not so much in programming.

In case i really want to do much FP or String stuff, i will avoid PureBasic.
PureBasic has its strong sides where it has libraries.
And its possibly a great "Game-Basic". ;D

You know my first computrer was an ATARI 400. It had a BASIC language within a 8KB ROM.
And it had 8 KB RAM. When i bought my first 32 KB Memory expansion i felt like the "Computer King".
It was around 1980. Look what was possible even at that time.

In fact it was a 8 bit Computer.

FOR .. NEXT using FP with the ATARI 400

Maybe i never wannted to go behind this one :-)