@ChrisH

Sounds good.
When I get back home from this trip, I will have a look at the links.

Thanks.

_________________
AmigaOne X1000

@ddni

You can try coding in PortablE - Chris always support you so you have big chance finish your projects... Start from Chris examples or examples on PortablE forum. I'm still beginner even after some program released.

@ChrisH
Thanks for new version. Many improvements are tested by me and work. Some improvements are big pain for example my ami-lineapolis menu is totally destroyed because some changes in MUI are implemented, but it is fixable, I think. But implementing new features are important so I accept changes and program growing.

Now I have little break-up in my coding, I search good and easy games to implement but it no easy select something (some my project was good type but not appear as catchable as I think after release, so I must carefully think what I want coding...)

I have uploaded a new PortablE beta archive with a very small fix (almost cosmetic):

* When the installer deletes obsolete modules, it will no-longer fail to delete a couple of folders (which was harmless but might have worried some people).
* A small 'bonus' is that the installer will now delete a few obsolete modules that I had previously overlooked.

Users who have already installed the latest release of PortablE do NOT need to download it again!

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@mrdarek Quote:

Some improvements are big pain for example my ami-lineapolis menu is totally destroyed because some changes in MUI are implemented, but it is fixable, I think.

It should cause you NO problems, apart from you needing to search/replace "addTextBox" with "addText" & "cGuiTextBox" with "cGuiText".

If you still have problems, then it may be there is a bug in my new (much more complex) automatic GUI layout code. In that case please send me example code.

P.S. Are you sure that you can still be classified as a beginner? You appear to have written/ported Lineapolis for quite a few old mobiles/PDAs.

Last edited by ChrisH on 10-Oct-2012 at 07:55 PM.
Last edited by ChrisH on 10-Oct-2012 at 07:46 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

OK - I will try soon do some fixes in code.
My Lineapolis is not updated because I not learned coding for Android system, Amiga is more fun and PortablE is more speed. I'm beginner in PortablE. But I have big sentiment for my first release Lineapolis - that version was only drawing lines and was very simple...

@ChrisH

When typing "pegcc workspace:myprog.e" in Shell I get an error:

"strip: unable to rename 'workspace:myprog' reason: Cross-device link
Successfully compiled program"

... and no executable will appear. I get around this by adding nostrip to the original command, but this will cause the executable to bloat, right? How can I avoid this?

@Androxyn
What filing system are you using for your "workspace" partition? And which OS?

And are you using the most recent release of PortablE?

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Workspace is just a folder on DH2: where I have my projects. The filesystem is SFS/02.

I downloaded PortablE.lha from OS4Depot not so long ago, the archive is dated 8/8-12.

@Androxyn
I use SFS/02 without problems.

Quote:

I downloaded PortablE.lha from OS4Depot not so long ago

The version on OS4Depot is VERY old (from 2009). Most likely you are seeing a bug that I fixed a long time ago. Please download and install the latest *beta* from http://cshandley.co.uk/portable/

You probably only need the PEGCC program that comes with the beta (I guess it will work with your old installation), but it would probably be OK to just install the whole thing. I fixed loads of bugs, added loads of new features, and by now hopefully fixed most of the bugs introduced by those new features!

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Thanks, updating to latest version fixed it (I did a full re-install).

Today (14th July 2013) I have released a new PortablE beta of my modernised AmigaE programming language. The highlights are:
* Added dynamic lists to the GUI module.
* Added three programs demonstrating dynamic lists: Stacker, SimpleGameLauncher, and DirList.
* Added support for embedding native GUI elements (e.g. MUI objects), so people can work-around any cases where PortablE's GUI system is lacking something they need.
* Added support for dropping files on GUI windows.
* Added support for GUI windows saving/loading their size & position.
* The GUI now auto-activates the first text input item, so you can start typing straight away.
* It now tells the user when the NList or TextEditor MUI classes are required but missing.
* AmigaOS4: Fixed non-drawable bitmaps being moved to video memory by Picasso96, thus potentially saving a LOT of video memory. (A new beta release of PictureAlbum with be forthcoming.)
* AmigaOS4: Fixed a mistake that would have caused non-bitmap drawing with the Graphics module to not work after a planned update to OS4.
* Windows: Fixed installation failing to create the required Assignments.txt file.
* Removed source< >destination restriction for StrCopy(), RightStr() & MidStr(). (I think Chris Y once requested this!)
* Fixed stereo sounds being silent for their second half.
* Fixed various other bugs, and worked-around some AROS bugs.

Also note that I have updated & recompiled all the examples.

The full list of changes:
* Added the parameter "startPos=0" to the procedure Val(). This removes the need for pointer arithmetic.
* Added the 'std/pBox' module, to provide a simple but very flexible way of storing various types of data, without needing separate getter/setter methods for all of them.
* In 'std/cPath', added the RenamePath() procedure, so you don't need to open a file anymore to just rename it.
* In 'std/cPath', added the ReadLink() procedure, so it is now possible to get the target of a soft link when the target doesn't exist.
* In 'std/cGui', added support for dynamic lists (see cGuiWindow.beginList(), cGuiList, etc), plus three example programs.
* In 'std/cGui', added support for embedding native GUI elements (e.g. MUI objects), so people can work-around any cases where PortablE's GUI system is lacking something they need.
* In 'std/cGui', added initAllowDropFiles()/etc & getFileDropped()/etc methods to the cGuiWindow class, so GUIs now allow files to be dropped on them.
* In 'std/cGui', added initSaveID()/etc methods to the cGuiWindow class, so GUIs can now automatically save/load their position & size.
* In 'std/cGui', cGuiButton now listens to initUseLeastSpace().
* In 'std/cGui', now activates the first text input item (e.g. cGuiString), so you can start typing straight away.
* In 'std/cGui', now generates an event when you leave a text input item without pressing Enter.
* In 'std/cGui', now tells the user that the NList or TextEditor classes are missing.
* In 'std/cGui', added the queryExtra() method to the cGuiItem class, and made it do something useful for the cGuiList class.
* In 'std/cGui', added the "doNotClear" parameter to the methods getCloseRequest() & getQuitRequest(). And calling those methods will now cause their info to be forgotten unless you supply TRUE for doNotClear.
* In 'std/cGui', window close requests are now queued, so there is no-longer any chance of them being lost in a race condition.
* In 'std/cPath', renamed Exists() to ExistsPath(), Delete() to DeletePath(), and DeleteDir() to DeleteDirPath(). But the old procedures still work for the moment...
* In 'std/cGfxSprites', the setDataBox() & getDataBox() methods of cGfxSprite REPLACE the old set/getDataPtr() methods, and their usage is slightly different. This should be completely future-proof, so no more changes will be needed.
* BUG: Windows: Fixed installation failing to create the required Assignments.txt file.
* BUG: C++: The 'CSH/pAmiga_fakeNewProcess' module (and thus cGfx/cMusic/cSnd) would not work in some situations. Now properly fixed by adding special support to PortablE.
* BUG: C++: For FOR & some other statements, got rid of the (possibly harmless) GCC warning 'comparison is always true/false due to limited range of data type'.
* BUG: Fixed obfuscation of FUNCtions randomly marking it's call() method as being an ORPHAN.
* BUG: Removed source< >destination restriction for StrCopy(), RightStr() & MidStr(). Fixed the type of RightStr()'s eString2 parameter (should have been STRING but was ARRAY OF CHAR for some reason).
* BUG: In 'std/cGfx', fixed the timer continuously generating bogus events, if stopTimer() was called without the last timer event being handled.
* BUG: In 'std/cGfx', AmigaOS4; stopped non-drawable bitmaps being moved to video memory by Picasso96.
* BUG: In 'std/cGfx', AmigaOS4; fixed a mistake that would have caused non-bitmap drawing to not work after a planned update to OS4.
* BUG: In 'std/cGfx', AmigaOS4; worked-around composited scaling not working on 16-bit screens.
* BUG: In 'std/cGfx', AROS; worked-around a strange 24-bit colour bug when drawing filled circles (and also filled circles not being completely filled).
* BUG: In 'std/cGfxSprites', the findSpriteAt() method of cGfxStack could wrongly still return the (undocumented) background sprite.
* BUG: In 'std/cSnd', fixed stereo sounds being silent for their second half.
* BUG: In 'std/cGui', fixed string objects (like cGuiString) not generating an event when setState() was used on them.
* BUG: In 'std/cGui', fixed string & number objects generating events despite their contents not changing (in several different circumstances).
* BUG: In 'std/cGui', fixed cGuiStringBox.getState() not returning anything after the GUI is built.
* BUG: In 'std/cGui', fixed getState() returning NILS instead of an empty string for cGuiString/etc, if setState() had never been called.
* BUG: In 'std/cGui', fixed crash if program exited before App was built.
* BUG: In 'std/cGui', AROS; fixed string objects (like cGuiString) generating (potentially recursive) events when setState() did not change their contents.
* BUG: In 'std/cGui', AROS; worked-around Zune wrongly reporting the window's size.
* BUG: In 'std/pShell', Amiga; fixed ShellArgs() to return the exact supplied program parameters, rather than stripping quotes & extra spaces. (Unfortunately still has the old behaviour on Windows.)

For the full list of changes & additional details, please see the documentation's History chapter.

Last edited by ChrisH on 14-Jul-2013 at 07:28 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Yay! E forever!

I have not ever switched to E simply because of no way to run a serious debugger on the Amiga version.

So after coding C and Basic and other languages for a zillion years I am currently in the process of learning C++ in the hopes that learning the OOPy stuff will help me learn your PortablE.

I read your whole entire instruction manual a few weeks back. Very nice work. But if I do ever switch to E I will have to send you a pile of feature requests right off the bat as I would want E to become the best language in the world for programming.

p.s. I hate C way more than you do.

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA

@ChaosLord
If you want to learn OOP for PortablE, then I advise against using C++, as it's really one of the worst implementations of OOP you will come across (*), and requires you to learn a lot of irrelevant concepts.

Instead, you can learn the BASICS of OOP in PortablE from using Jason Hulance's guide. Since it came-up in discussions on the official forum a few days ago, I wrote a quick guide:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=8341&forum=28

* = it defaults to the fastest rather than the safest or least error-prone way, and in general simple stuff is just way too complex.

P.S. Thanks for your kind words about the manual(s). I hope your suggestions overlap with my PortablE wishlist, because my wishlist is already very large!

P.P.S. I merely *dislike* C, where-as I really do *hate* C++.

Last edited by ChrisH on 15-Jul-2013 at 02:58 PM.
Last edited by ChrisH on 15-Jul-2013 at 02:55 PM.
Last edited by ChrisH on 15-Jul-2013 at 02:54 PM.
Last edited by ChrisH on 15-Jul-2013 at 02:53 PM.
Last edited by ChrisH on 15-Jul-2013 at 02:52 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChaosLord

Quote:

I have not ever switched to E simply because of no way to run a serious debugger on the Amiga version.

I found EDBG quite met my needs. Before that I was MonAm all the way except whan AssemPro was used EDBG was the first source level devugger I'd ever used and I liked it!

Hard to go back.

@ChrisH

Wow this looks like a big update. Thanks for your continuing work. BTW what chance is there to compile a PortabE module into an .o file for use with linking to other .o files compiled from C?

@Hypex

Every big update has some new features allowed my current game work. But some my older games need recompilation to be compatible. :(
Now I must recompiling some older games or they can soon start work not properly, but this is not easy - I need change some code.
@Chris
Anyway thanks for new update.

@ChaosLord Quote:

I have not ever switched to E simply because of no way to run a serious debugger on the Amiga version.

FWIW, debugging PortablE programs is easier on AmigaOS4 than other OSes, because the GrimReaper will report the exact line number where the crash occurred in the (intermediate) C++ code. You can then examine that code (which includes any comments), and it is usually pretty obvious what the corresponding line in your PortablE code is. (It may also be possible to do something similar with some versions of AROS.) Just make sure you compile PortablE code with the DEBUG switch.

It's only just occurred to me, but it ought to be possible to have an automatic (C++ to PortablE) line number converter, so that you never even need to examine the intermediate C++ code. If there was demand, then I should be able to add this pretty easily...

@mrdarek Quote:

Every big update has some new features allowed my current game work. But some my older games need recompilation to be compatible. :(

Please note that new "r6" features are still in beta, which means things CAN change... but I try my best to avoid that. If you have some big issue with a change, then please let me know.

Last edited by ChrisH on 15-Jul-2013 at 06:33 PM.
Last edited by ChrisH on 15-Jul-2013 at 06:33 PM.
Last edited by ChrisH on 15-Jul-2013 at 06:26 PM.
Last edited by ChrisH on 15-Jul-2013 at 06:26 PM.
Last edited by ChrisH on 15-Jul-2013 at 06:24 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

ChrisH wrote: @ChaosLord If you want to learn OOP

I didn't start out wanting to learn OOP. All I ever wanted since 1970s was a language that let me say:
A$+=B$
or
A$=A$+B$
or z$=E$+F$+G$

A few weeks ago I accidentally found out that C++ allows that if you code in some appropriate complicated looking code to "overload" the + and += operators!

All I care about is a language that lets me write beautiful code.


Quote:

for PortablE, then I advise against using C++, as it's really one of the worst implementations of OOP you will come across (*), and requires you to learn a lot of irrelevant concepts. * = it defaults to the fastest rather than the safest or least error-prone way, and in general simple stuff is just way too complex.

C stands for Complicated.
C stands for Complex.
C stands for Confusing.
C stands for Convoluted.
C stands for Crap.

I am all to aware of all the dumb crap the C language does.

But as a C++ Newbling I am not (yet) aware off any new dumb crap that C++ added.

Has anyone written an article to explain all the dumb C++ OOP stuff that was added into C++ and how it makes more sense in PortablE or AmigaE or #?E ?


I have not learned the OOPy parts of C++ yet.
But I did find some freeware C++ OOPy code that I want to cut & paste into my softwarez. (This is what motivated me to start the process of murdering millions of innocent braincells to learn C++)



Quote:

P.S. Thanks for your kind words about the manual(s). I hope your suggestions overlap with my PortablE wishlist, because my wishlist is already very large!

I may someday join forces with you in your battle for logic and sanity in an illogical and insane programming world.


Quote:

P.P.S. I merely *dislike* C,

This just means you forgot how completely stupid C is because you have been "working around it" for so many years.

Quote:

where-as I really do *hate* C++.

All I can say is when I look at example code that shows how to setup the fancy new features that C++ has over C it usually looks ugly and not very logical. But I haven't learned how it all works yet so I donno if it is the language or just my ignorance.

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA

@Hypex

Quote:

Hypex wrote: @ChaosLord Quote: I have not ever switched to E simply because of no way to run a serious debugger on the Amiga version. I found EDBG quite met my needs.

Datz cause ur cheating and using one o dem dere newfangled OS4 thingamajig machines

I need source level debugging for Classic Amigas. Either Amiga Real Machines or Amiga Virtual Machines or both.

I have worked out that I can use a C++ Transpiler to transpile C++ code down into SASC C code and that way I can use the best debugger ever made for Classic Amigas.



Quote:

Before that I was MonAm all the way except whan AssemPro was used EDBG was the first source level devugger I'd ever used and I liked it! Hard to go back.

Now u understand why I love CPR debugger so much. CPR has been kicking ass since the early-mid 90s.

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA

@Hypex

Quote:

Hypex wrote: @ChrisH Wow this looks like a big update. Thanks for your continuing work. BTW what chance is there to compile a PortabE module into an .o file for use with linking to other .o files compiled from C?

+9 this would be a great feature.

Also to allow linking to C++ compiled code.

Since PortablE is a transpiler shouldn't it be able to actually compile C sources and C++ sources?

As long as the C code is contained in its own separate files I think PortablE should pass it on to the underlying compiler.

As long as the C++ code is contained in its own separate files I think PortablE should pass it on to the underlying compiler.

This would allow me to use 200,000 lines of code I already wrote, instantly, without having to laboriously rewrite it all into E in one big gulp before seeing any results.

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA