Wishlist
BlitzMax Forums/BlitzMax Programming/Wishlist
| ||
| 1. Get rid of garbage collection. I have been using it for a year. I understand it, but I don't like it. It doesn't play well with other languages. I store everything in lists automatically, so all this does is make my life harder and eat CPU cycles. 2. Multithreading support See #1. With multicore processing becoming more important, this one makes a lot of sense. I actually have practical applications I would like to use this for, like streaming textures from the hard drive. 3. Official support for dll and static lib compilations. I do a lot of interfacing with other languages. This would help a lot. 4. Better debugger This is something that would improve the overall experience for all users, not jsut a few. Everything else, I could not be happier with. I love BlitzMax, and everything it allows me to do. |
| ||
| 5. Offical ICON Support |
| ||
| Interfaces with multiple inheritance Improved conditional complation |
| ||
| 1. I would prefer if GCwas fully implemented. Right now it does not have root references which in the end means that cyclic refernce structures are not collected. 2. Or at least multi threading safe MemoryManagement / GC |
| ||
| 6. A bugfree IDE that works on all OS'es without additional heavy libs one needs to install, basically as lightweight as the default one, but with code folding! I've BMax/gui for almost 2 years now, but I haven't had the impression I ever did something big. Whereas I *did* big stuff with B+ and the VisualBlitz IDE. Sometimes you just need to 'zoom out' to see the whole picture, so folding is important. Spreading code among various files decentralizes things, and for larger types it's not practical in the first place. Iirc some BRL person was working on folding, any updates about that? |
| ||
| 1. Multithreading 2. A MaxGUI'd version of wxWidgets :) |
| ||
| 1 OverLoading (Which could be done at pre-complation) 2 I reserve judgement on the GC, I also either have everything in lists or its Local, I dont tend to be at the "Power" end, so dont really notice if it does eat CPU cycles. But it does make life easier 3 Multithreading or PreEmptive hooks |
| ||
| On the PC side: Upgade 2DMax to "officially" support DX8 or DX9. |
| ||
| -Printer Support -Official Icon Support -Better Audio Handling -Video Handling |
| ||
| Wishes are for dreamers. I have lost that ability a while a ago. |
| ||
| - Multithreading - Code-folding in the default IDE - Icon Support |
| ||
| C# and Java both have garbage collectors and they're two of the fastest growing languages, so I don't buy that having a GC is bad. Having a better GC, on the other hand, very handy. Weak references, for example. The debugger could certainly stand some improving. Quite a lot of it, in fact. The main problem I have when dealing with other languages is the lack of C-compatible structs. Unions would be handy for this too. Operator and Function Overloading would be very useful. Anything which can be done already has a lower priority for me. I can use another IDE, I can use other tools, I can use libraries for graphics, audio, XML. Things like C-Structs, better debugging, and threading ( I have little to no interest in threading, but that's not the point, it is not sensible to do it third party ) you can't ( properly ) do any other way, so they're the things I want most. I can live with hassle for other things that are still possible. |
| ||
| I would love to get rid of the GC, or at least have the option to turn it off. Structs. |
| ||
| Max3D. |
| ||
| Isn't it possible to turn off the GC anyway? And a Type is basically a struct. |
| ||
| Types are different to C structs, in blitz Type fields seem to always be padded and arrays are treated as pointers. |
| ||
| @Czar - Structs - what Azazoth said. The main issue is the loops you have to jump through when talking to external code that expect C style structures. Before anyone says 'just go use C', that's not the issue. I love Max but it could be a whole lot more user friendly with regards to calling external APIs. GC - I have heard this said before, but no-one gave an example when I asked. Can you give me a small example that creates and destroys a type without GC? I had all sorts of problems with the GC when trying to implement FMOD callbacks. In the end I had to remove all type creation and destruction code from the callback to avoid errors, which was far from an ideal solution. |
| ||
| You have to clearly seperate the code. Stuff returned from C that is meant to be used in callbacks in C / C++ code should always be byte ptr and only assigned to your objects. Nothing you actually extern typed. If you need a block of memory not managed, there is memalloc() which will generate a gc free memory block you have to free through memfree(byte ptr) again. normally you use gcsuspend() and gcresume() to perform external calculations, you are aware that they can callback or interfer, to prevent suicide of the GC. |
| ||
| This reminds me of that gif where you have a matchstick figure using bigger and bigger weapons to try to blow down the door. Futility. I second all halo's requests all the same. A modern language without threads is like a woman without boobs. It's just not the same... |
| ||
| Hi, 1. Get rid of garbage collection. No. Never. In fact, it will be a cold day in hell when I I have to write anything 'production quality' again in a non-GC language - and I plan to write lots of stuff in Max. So many things in Max rely on GC that the system would become pretty much non-functional without it - no more strings, 99% of the modules would crap out, even TLists! I would never sacrifice the ability to do this.... Local p:TVec3=plane.Intersect( camera.Inverse().TimesPoint( modelMatrix.Times( mouseVec ) ) ) ...for the equivalent half page of carefully monitored deletes and crap it would involve without GC - never mind if you actually wanted to store the result somewhere! 2. Multithreading support I would love this too - but it's *hard*! Language-wise, the Max GC system needs to be synced - but that is just the tip of the iceberg. *Every* global in the module system would need some kind of synchronization. Even non-globals like TList's would require some 'higher level' sync algorithm to prevent scrambling data structures. Different OS's have different 'per thread' requirements and so on. The GC thing is the least of the problems... I am basically looking for a better solution than 'ref counts are synced - go nuts'. Multi threading is, by default, extremely unsafe. 3. Official support for dll and static lib compilations. This I can do! Coming soon... 4. Better debugger Will happen... |
| ||
| Cool.. it's nice to get some news from you again, Mark. :) It's good to know that things are progressing.. Are you still working on the new IDE you mentioned a while back? |
| ||
| Mark, would it be possible to at least fix the Garbage Collector to free all unreachable (from an application's point of view) unreferenced objects, i.e. the cyclic references problem? GC is only half as useful as possible if you still have to manage your references manually to not keep unreachable objects alive. |
| ||
| Mark, would it be possible to at least fix the Garbage Collector to free all unreachable (from an application's point of view) unreferenced objects, i.e. the cyclic references problem? That would be breaking it, not fixing. Neither object is unreachable, and a GC which disposes of objects you can still reach is worse than useless. GC is only half as useful as possible if you still have to manage your references manually to not keep unreachable objects alive. You don't have to manage your references manually, just don't use cyclic references. It's entirely your choice. |
| ||
| Elvis has left the building... ;) |
| ||
| Gabriel: I think what he means is: could you add root reference counters which prevents cyclic but no where used structures from beeing uncollected until the end of the GC. Cyclic stuff that is not referenced by your currently in scope variables i clearly not reachable and therefor surely nothing near worse if cleared :) |
| ||
| That seems worse than ever to me. At least now there's a clear line on what's picked up and what isn't. That way you either have a grey area or you have the GC doing too much work and slowing everything down to a crawl. This is supposed to be a language which can be used for games, among other things, after all. |
| ||
| Who told you that untruth? A java programmer? :-) C# and Eiffel are GC based as well with root reference checking to prevent cyclic memory leaks and as far as I can remember, both are used for realtime entertainment as well and to make it even better: they are not really slower than C++, just a massive amount more bugfree and easier to maintain on a stable level. Checking for root references isn't like searching a a white dot in a black surface of 1 km^2, it can be done without many many useless checkings. It adds a little overhead, correct. But it isn't as worse as "check for each object on its own if it is referenced anywhere in the program". Just save and keep alive a root reference for each object instead of only the ref count. |
| ||
| No. Never. In fact, it will be a cold day in hell... Hahaha, thank you for your bluntness. I can live with this, and am starting to design things to work a little more with the GC in mind. That whole list sounds pretty good. I'm getting some flak from my other programmer over the multithread thing, and need to find a solution, probably via a C lib. I like to point out to him that using BlitzMax means we can rip our whole renderer apart and rebuild it in a day, but we do need to find some way to run another thread to stream textures. |
| ||
| Any object not reachable from an applications point of view is garbage, not collecting those is simply a bug in the collector. Documenting it isn't solving it, it's just a workaround - and I hope a temporary one. |
| ||
| Ah and a simple example for an unreachable object ... pseudocode ... Instance1 = new Obj Instance2 = new Obj Instance1.other = Instance2 Instance2.other = Instance1 Instance1 = new Obj Instance2 = new Obj Now you have a sweet dangling couple hanging in the air - forever. It's a simple and easy to fix example but if you write more complex systems it'll get harder and harder to not fall into those traps. |
| ||
| What -should- happen in your pseudocode is that the original objects Instance1 and Instance2 are processed by the garbage collector since they are no longer referenced. I never played with this before... Does BlitzMax really have a bug like this that prevents the GC from collecting unreferenced objects? |
| ||
| Can you give me a small example that creates and destroys a type without GC? Something like this maybe? |
| ||
| Winni: It is no bug. The GC is just only ref count based without root references, that means it does not check if a structure of objects can even be reached from the current variable scope or not. Its a known restriction to the GC that some fall into if they use TList and TLink and use TLink.remove without null-ifying the tlink on the object (best known reason for the gc caused memory leak I know) |
| ||
| Thanks for the example, Perturbatio. |
| ||
| If streaming textures or other files is one of the prominent desired possibilities resulting from having threads, couldn't Mark implement a `special feature` which at some low level creates a Blitz-managed thread which is only used for reading/writing file data? I remember on the Amiga you could do `io` (input/output) in a couple of ways - either go get the information and wait until it comes back or set it running and then poll to check to see if it is finished. Is there any reason why Blitz couldn't manage a stream-processing thread (or several) in a very closed non-user-editable way that would be sure of being safe enough not to crash stuff? It wouldn't be like giving the user access to threads `in general`, it would be a very specific case and could be kept concealed and controlled? That said, what OTHER uses do people intend on having for the use of threads? |
| ||
| My Wish is for MaxGUI. A Multicolumnlistbox, i hope a official function comes out. Sry for my bad english^^ |
| ||
| I'm getting some flak from my other programmer over the multithread thing, and need to find a solution, probably via a C lib. The following technical article in the directx sdk docs makes good reading: Lockless Programming Considerations for Xbox 360 and Microsoft Windows Mark mentioned making globals and gc threadsafe in BlitzMax. From the numbers in the article this approach would be quite a performance penalty (significantly greater for multiprocessor machines): MemoryBarrier was measured as taking 20-90 cycles. InterlockedIncrement was measured as taking 36-90 cycles. Acquiring or releasing a critical section was measured as taking 40-100 cycles. Acquiring or releasing a mutex was measured as taking about 750-2500 cycles. The xbox360 numbers (power pc) are worse. So it's hard to argue a generic solution for threading in Blitzmax will not introduce performance penalties. However asynchronous file communications is something that can be done without waiting for a better language solution to arrive. A simple module that begins a load from file to bank and can be polled for completion status could be used by a polled wad loader to read a catalog of images to the bank buffers and as they arrive load / decompress them to your textures while the game continues to display an attractive loading screen. For async file io in windows lookup ReadFile in msdn and check out the overlapped details. |
| ||
| The async file stuff would be perfect if there is a Linux and Mac equivalent. |
| ||
| On the PC side, I would like to use the latest version of MinGW. May be good to have ARM support (could then write for the GP32X then) Aside from that, as DLL and static libraries will be support, I'm happy :) |
| ||
| 4. Better debugger For example test.bmx: SuperStrict
Framework BRL.Blitz
Type TTest
Global X : Int
Function SetX(Value:Int)
TTest.X = Value
DebugLog("X = " + TTest.X)
End Function
End Type
Function Foo()
Global Bar : Int
Bar = 123
DebugLog("Bar = " + Bar)
End Function
DebugStop()
TTest.SetX(321)
Foo()will result the follow debuging: C:\Dokumente und Einstellungen\Oliver\Desktop\test.debug.exe
~>DebugStop:
~>
t
~>StackTrace{
~>@C:/Dokumente und Einstellungen/Oliver/Desktop/test.bmx<21,1>
~>Function test
~>}
~>
s
~>Debug:
~>
e
~>Debug:
~>
t
~>StackTrace{
~>@C:/Dokumente und Einstellungen/Oliver/Desktop/test.bmx<22,1>
~>Function test
~>@C:/Dokumente und Einstellungen/Oliver/Desktop/test.bmx<9,3>
~>Function SetX
~>Local Value:Int=321
~>}
~>
s
~>Debug:
~>
t
~>StackTrace{
~>@C:/Dokumente und Einstellungen/Oliver/Desktop/test.bmx<22,1>
~>Function test
~>@C:/Dokumente und Einstellungen/Oliver/Desktop/test.bmx<10,3>
~>Function SetX
~>Local Value:Int=321
~>}
~>
s
~>Debug:
~>
e
~>Debug:
~>
t
~>StackTrace{
~>@C:/Dokumente und Einstellungen/Oliver/Desktop/test.bmx<23,1>
~>Function test
~>@C:/Dokumente und Einstellungen/Oliver/Desktop/test.bmx<15,2>
~>Function Foo
~>Global Bar:Int=0
~>}
~>
s
~>Debug:
~>
s
~>Debug:
~>
t
~>StackTrace{
~>@C:/Dokumente und Einstellungen/Oliver/Desktop/test.bmx<23,1>
~>Function test
~>@C:/Dokumente und Einstellungen/Oliver/Desktop/test.bmx<18,2>
~>Function Foo
~>Global Bar:Int=123
~>}
~>
sYou can see, that static variables in functions like "Bar" in function "Foo" will tracet but static variables in classes like "X" in "TTest" not. I working many times with static variables in classes like TConfig where I don't need an instance of this class. I would be good, when these variables tracet too :) cu olli |
| ||
| Mark mentioned making globals and gc threadsafe in BlitzMax. You don't necessarily need to make Globals thread safe. Only Globals used in critical sections need to be thread safe.An excellent book that covers this issue (and others) is the "Dinosaur book", aka "Operating Systems Concepts with Java" by Abraham Silberschatz. Aside from explaining the concepts involved it provides Java source code examples illustrating the possible solution, focusing in particular on the solution Java uses, namely the monitor. |
| ||
| Processors are becoming multi-core... multi-threading simply is not an option for a modern language IMHO. Even limited support would suffice Read-Only Globals for threads that dont 'own' a global. |
| ||
| My 2 simple wishes: working linux-ide & 64-bit support. |
| ||
| .... 3D official module :D |
| ||
| Enumerations. |
| ||
| 64bit support is the only wish thats definitely not simple due to the "little" problem with different sizes of core datatypes between 32 and 64bit :) see the vast amount of applications simply failing to run on 64bit OS |
| ||
| I have 0 windows threading experience... but wouldn't just basic process forking (copy all threads) be safe and "relatively" easy? having to do IPC certainly wouldn't be as nice but it would be better than nothing.... but then you could add shared memory though "shared" banks. that would allow for higher performace than just IPC |
| ||
| I'd like a compile time version control stamp/Build number eg: print "Test application build " + appRevision() |
| ||
| Enumerations. Seconded. |
| ||
| I think either threads or a really easy mechanism for processes to share memory/data and communicate between them would be really useful, considering we're all moving towards multiple core cpu's now. |
| ||
Enumerations: I use this:
Type MyEnum Abstract
Const Enum1:int = 1
Const Enum2:Int = 2
Const Enum3:int = 4
Const Enum4:int = 8
End Type
This is more or less a enumerator list in BlitzMax... |
| ||
| How does it work? |
| ||
| My Wish ============================================== change it ============================================== Type TEntity Field link:TLink Method remove() link.remove End Method Method AddLast( list:TList ) link=list.AddLast( Self ) End Method Method Update() Abstract End Type 'serious cool :-) , Multithreading Update List Function UpdateEntities( list:TList ) For Local entity:TEntity=EachIn list entity.Update Next End Function ============================================== for it ============================================== 'serious cool :-) , Multithreading Update List Auto_Multithreading_UpdateList( list:TList , threading_number ) |
| ||
| I don't know even if it is possible - it's just a 'imaginative-software' but a possibile solution could be to add other 'Objects' to BlitzMax standard command set, and use them if and when multithreading is required. For example: LIST for 'standard' blitz SHAREDLIST for 'multithreaded' blitzMax type TSharedList Extends TData ... field locked:int=0' or 1..n where n is the thread that 'uses' the object field user_list:int[] ' the ID_Process array of thread currently using the 'object' ... method New() locked:+1 user_list[locked]=Current_ID_Process 'I don't know how to create 'on the fly' a new thread... 'but it could be a global CURRENT_ID_PROCESS somewhere end method ... method Remove() if locked>0 return ... end method end type and so on for the rest OBJECT SHAREDOBJECT ARRAY SHAREDOBJECT... of course somewhere in the main loop it will be needed a 'sync' command to keep all the thing correct. The downside is that the existing module should be rewritten (in the case that multithreading is a BETTER solution). For me it seems a very complicated overhead... I really don't know how (and IF...) something like this could be done and works... |
   |