all projects halted

Kuron · **Joined:** Sat Oct 17, 2009 10:51 pm **Posts:** 919

J. Baker wrote:

You could be right.

As could you :mrgreen:

freak · **Posted:** Mon Oct 03, 2011 1:03 pm

This whole "we only want bugfixes ever" argument is nonsense. We already do a bugfix-only version on every second release, precisely for people who say they do not want any new features. If you don't want new features, don't use versions like 4.60, its that simple. Just wait for the 4.61 version which is the bugfix-release of 4.60. But the truth is that very few people seem to do that, because guess what, people actually want to use the new features. What a shock.

Ramihyn_ wrote:

This problem isnt new, the discussion happened years ago already. A simple solution that other projects do, is to handle two versions. One rock-solid branch where _all_ confirmed bugs will be fixed, but no new features will be done and one branch as it is now. So the developers can still have fun introducing new stuff and the users have a version they can actually use to produce software.

The best example for this is probably Debian, and it shows my point exactly. Why do you think the (rather solid, but very old) stable branches are only used for servers and the like? Projects like Ubuntu pretty much only use the up to date unstable or even testing branches, because people want the latest features. And even those stable branches that have seen bugfixes only for an eternity are not 100% bugfree. The though of a software with "_all_" bugs fixed is an illusion.

Btw, yes this discussion happened years ago, and we reacted to it. The fact that we have a release cycle where every second release is for bugfixes only is the result of that. We actually have the exact model you describe: Development on 4.60 started right after 4.50 was released, while we still fixed bugs for the 4.51 version in a separate branch. It didn't use to be that way. But some people seem to never be satisfied no matter what we do. Oh, and some of you make it sound like there has never been a usable PB version so far. If that was really the case, why are you using it?

Now, it is true that Linux and OSX lag behind the Windows version in bugfixes. We have limited resources and we have to spend them where they have the greatest effect, and quite frankly, the participation and feedback on the Linux and OSX side is not that great. The usage of the OSX version seems to climb only very slowly, and the amount of feedback we get on the Linux side seems to be decreasing even. If you want these versions to become better, you have to do your part: Actively use them and report the bugs you find. Just sitting back and waiting for it to magically become perfect won't change anything.

Btw, in case you didn't notice: We are delaying the 4.60 release because we want to fix more bugs on the Linux and OSX side. We are not abandoning these platforms, but they cannot be the sole focus either for obvious reasons.

J. Baker · **Posted:** Mon Oct 03, 2011 1:25 pm

@freak

I've been posting bugs that I have come across all year long for Mac so far and I'm not using 4.60 for development. Why do you sound so angry in your above post? I'm kind of surprised by your response.

Polo · **Posted:** Mon Oct 03, 2011 3:37 pm

I totally agree with Freak and PB development model.

The biggest problem here is that some bugs on OSX are still not fixed and kinda show stoppers - for instance the Drawtext bug (which cuts the word vertically when the font size is too big, and doesn't draw it properly for any font size). And those bugs have been reported.

I know it can be hard to fix all bugs, especially hard to fix ones, but it does explain why the OSX version is still not used a lot.

Guimauve · **Posted:** Mon Oct 03, 2011 3:39 pm

PMV wrote:

And where can we see that in action? Have i overseen something?

I have completed the University by April and I don't have access to many reference books anymore. So for the moment, this project is halted because I don't have any money to purchase the needed reference books.

In a meanwhile I work on few other project, "Thothbox" to learn how to manage Network data transfer and my utility formally know as "Dev-Type" to help me by generating a lot of code automatically. Example Simple mesh structure holding information about geometry specifically design for OpenGL vertex array :

Code:

; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; AUTOMATICALLY GENERATED CODE, DO NOT MODIFY
; UNLESS YOU REALLY, REALLY, REALLY MEAN IT !!
; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; Code generated by : Dev-Type V3.56.188
; Project name : the project name here
; File name : File name here
; File Version : 0.0.0
; Programmation : In progress
; Programmed by : Guimauve
; Creation Date : 03-10-2011
; Last update : 03-10-2011
; Coded for PureBasic V4.60
; Platform : Windows, Linux, MacOS X
; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< Structure declaration <<<<<

Structure Mesh

  VertexCount.l
  IndiceCount.l
  Vertex.i ; Data, VertexCount, Vector3
  Normal.i ; Data, VertexCount, Vector3
  UVMap.i ; Data, VertexCount, Vector2
  Indice.i ; Data, IndiceCount, Indice3

EndStructure

; <<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< The observators <<<<<

Macro GetMeshVertexCount(MeshA)

  MeshA\VertexCount

EndMacro

Macro GetMeshIndiceCount(MeshA)

  MeshA\IndiceCount

EndMacro

Macro GetMeshVertex(MeshA)

  MeshA\Vertex

EndMacro

Macro GetMeshNormal(MeshA)

  MeshA\Normal

EndMacro

Macro GetMeshUVMap(MeshA)

  MeshA\UVMap

EndMacro

Macro GetMeshIndice(MeshA)

  MeshA\Indice

EndMacro

; <<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< The mutators <<<<<

Macro SetMeshVertexCount(MeshA, P_VertexCount)

  GetMeshVertexCount(MeshA) = P_VertexCount

EndMacro

Macro SetMeshIndiceCount(MeshA, P_IndiceCount)

  GetMeshIndiceCount(MeshA) = P_IndiceCount

EndMacro

Macro SetMeshVertex(MeshA, P_Vertex)

  GetMeshVertex(MeshA) = P_Vertex

EndMacro

Macro SetMeshNormal(MeshA, P_Normal)

  GetMeshNormal(MeshA) = P_Normal

EndMacro

Macro SetMeshUVMap(MeshA, P_UVMap)

  GetMeshUVMap(MeshA) = P_UVMap

EndMacro

Macro SetMeshIndice(MeshA, P_Indice)

  GetMeshIndice(MeshA) = P_Indice

EndMacro

; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< Complentemary Macros for Datas <<<<<

Macro ReachMeshVertex(MeshA, OffsetID)

  (GetMeshVertex(MeshA) + (OffsetID) * SizeOf(Vector3))

EndMacro

Macro AllocateMeshVertexMemory(MeshA)

  SetMeshVertex(MeshA, AllocateMemory(GetMeshVertexCount(MeshA) * SizeOf(Vector3)))

EndMacro

Macro MemoryMeshVertexSize(MeshA)

  MemorySize(GetMeshVertex(MeshA))

EndMacro

Macro LastMeshVertex(MeshA)

  ((MemorySize(GetMeshVertex(MeshA)) / SizeOf(Vector3)) - 1)

EndMacro

; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< Complentemary Macros for Datas <<<<<

Macro ReachMeshNormal(MeshA, OffsetID)

  (GetMeshNormal(MeshA) + (OffsetID) * SizeOf(Vector3))

EndMacro

Macro AllocateMeshNormalMemory(MeshA)

  SetMeshNormal(MeshA, AllocateMemory(GetMeshVertexCount(MeshA) * SizeOf(Vector3)))

EndMacro

Macro MemoryMeshNormalSize(MeshA)

  MemorySize(GetMeshNormal(MeshA))

EndMacro

Macro LastMeshNormal(MeshA)

  ((MemorySize(GetMeshNormal(MeshA)) / SizeOf(Vector3)) - 1)

EndMacro

; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< Complentemary Macros for Datas <<<<<

Macro ReachMeshUVMap(MeshA, OffsetID)

  (GetMeshUVMap(MeshA) + (OffsetID) * SizeOf(Vector2))

EndMacro

Macro AllocateMeshUVMapMemory(MeshA)

  SetMeshUVMap(MeshA, AllocateMemory(GetMeshVertexCount(MeshA) * SizeOf(Vector2)))

EndMacro

Macro MemoryMeshUVMapSize(MeshA)

  MemorySize(GetMeshUVMap(MeshA))

EndMacro

Macro LastMeshUVMap(MeshA)

  ((MemorySize(GetMeshUVMap(MeshA)) / SizeOf(Vector2)) - 1)

EndMacro

; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< Complentemary Macros for Datas <<<<<

Macro ReachMeshIndice(MeshA, OffsetID)

  (GetMeshIndice(MeshA) + (OffsetID) * SizeOf(Indice3))

EndMacro

Macro AllocateMeshIndiceMemory(MeshA)

  SetMeshIndice(MeshA, AllocateMemory(GetMeshIndiceCount(MeshA) * SizeOf(Indice3)))

EndMacro

Macro MemoryMeshIndiceSize(MeshA)

  MemorySize(GetMeshIndice(MeshA))

EndMacro

Macro LastMeshIndice(MeshA)

  ((MemorySize(GetMeshIndice(MeshA)) / SizeOf(Indice3)) - 1)

EndMacro

; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< The Reset operator <<<<<

Macro ResetMesh(MeshA)
  
  SetMeshVertexCount(MeshA, 0)
  SetMeshIndiceCount(MeshA, 0)
  
  If GetMeshVertex(MeshA) <> #Null
    
    For OffsetID = 0 To GetMeshVertexCount(MeshA) - 1
      *VertexA.Vector3 = ReachMeshVertex(MeshA, OffsetID)
      ResetVector3(*VertexA)
    Next
    
    FreeMemory(GetMeshVertex(MeshA))
    SetMeshVertex(MeshA, 0)
    
  EndIf
  
  If GetMeshNormal(MeshA) <> #Null
    
    For OffsetID = 0 To GetMeshVertexCount(MeshA) - 1
      *NormalA.Vector3 = ReachMeshNormal(MeshA, OffsetID)
      ResetVector3(*NormalA)
    Next
    
    FreeMemory(GetMeshNormal(MeshA))
    SetMeshNormal(MeshA, 0)
    
  EndIf
  
  If GetMeshUVMap(MeshA) <> #Null
    
    For OffsetID = 0 To GetMeshVertexCount(MeshA) - 1
      *UVMapA.Vector2 = ReachMeshUVMap(MeshA, OffsetID)
      ResetVector2(*UVMapA)
    Next
    
    FreeMemory(GetMeshUVMap(MeshA))
    SetMeshUVMap(MeshA, 0)
    
  EndIf
  
  If GetMeshIndice(MeshA) <> #Null
    
    For OffsetID = 0 To GetMeshIndiceCount(MeshA) - 1
      *IndiceA.Indice3 = ReachMeshIndice(MeshA, OffsetID)
      ResetIndice3(*IndiceA)
    Next
    
    FreeMemory(GetMeshIndice(MeshA))
    SetMeshIndice(MeshA, 0)
    
  EndIf
  
  ; ClearStructure(MeshA, Mesh)

EndMacro

; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< Create Binary File <<<<<

Procedure CreateMeshBinaryFile(FileID.l, FileName.s, *MeshA.Mesh)

  If CreateFile(FileID, FileName)
  
    WriteLong(FileID, GetMeshVertexCount(*MeshA))
    WriteLong(FileID, GetMeshIndiceCount(*MeshA))
  
    If GetMeshVertex(*MeshA) <> #Null
      
      For OffsetID = 0 To GetMeshVertexCount(*MeshA) - 1
        WriteVector3(FileID, ReachMeshVertex(*MeshA, OffsetID))
      Next
      
      ; WriteData(FileID, GetMeshVertex(*MeshA), MemorySize(GetMeshVertex(*MeshA)))
      
    EndIf
  
    If GetMeshNormal(*MeshA) <> #Null
      
      For OffsetID = 0 To GetMeshVertexCount(*MeshA) - 1
        WriteVector3(FileID, ReachMeshNormal(*MeshA, OffsetID))
      Next
      
      ; WriteData(FileID, GetMeshNormal(*MeshA), MemorySize(GetMeshNormal(*MeshA)))
      
    EndIf
  
    If GetMeshUVMap(*MeshA) <> #Null
      
      For OffsetID = 0 To GetMeshVertexCount(*MeshA) - 1
        WriteVector2(FileID, ReachMeshUVMap(*MeshA, OffsetID))
      Next
      
      ; WriteData(FileID, GetMeshUVMap(*MeshA), MemorySize(GetMeshUVMap(*MeshA)))
      
    EndIf
  
    If GetMeshIndice(*MeshA) <> #Null
      
      For OffsetID = 0 To GetMeshIndiceCount(*MeshA) - 1
        WriteIndice3(FileID, ReachMeshIndice(*MeshA, OffsetID))
      Next
      
      ; WriteData(FileID, GetMeshIndice(*MeshA), MemorySize(GetMeshIndice(*MeshA)))
      
    EndIf
  
    CloseFile(FileID)

  EndIf

EndProcedure

; <<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< Read Binary File <<<<<

Procedure ReadMeshBinaryFile(FileID.l, FileName.s, *MeshA.Mesh)

  If ReadFile(FileID, FileName)
  
    SetMeshVertexCount(*MeshA, ReadLong(FileID))
    SetMeshIndiceCount(*MeshA, ReadLong(FileID))
  
    AllocateMeshVertexMemory(*MeshA)
    
    If GetMeshVertex(*MeshA) <> #Null
      
      For OffsetID = 0 To GetMeshVertexCount(*MeshA) - 1
        ReadVector3(FileID, ReachMeshVertex(*MeshA, OffsetID))
      Next
      
      ; ReadData(FileID, GetMeshVertex(*MeshA), MemorySize(GetMeshVertex(*MeshA)))
      
    EndIf
  
    AllocateMeshNormalMemory(*MeshA)
    
    If GetMeshNormal(*MeshA) <> #Null
      
      For OffsetID = 0 To GetMeshVertexCount(*MeshA) - 1
        ReadVector3(FileID, ReachMeshNormal(*MeshA, OffsetID))
      Next
      
      ; ReadData(FileID, GetMeshNormal(*MeshA), MemorySize(GetMeshNormal(*MeshA)))
      
    EndIf
  
    AllocateMeshUVMapMemory(*MeshA)
    
    If GetMeshUVMap(*MeshA) <> #Null
      
      For OffsetID = 0 To GetMeshVertexCount(*MeshA) - 1
        ReadVector2(FileID, ReachMeshUVMap(*MeshA, OffsetID))
      Next
      
      ; ReadData(FileID, GetMeshUVMap(*MeshA), MemorySize(GetMeshUVMap(*MeshA)))
      
    EndIf
  
    AllocateMeshIndiceMemory(*MeshA)
    
    If GetMeshIndice(*MeshA) <> #Null
      
      For OffsetID = 0 To GetMeshIndiceCount(*MeshA) - 1
        ReadIndice3(FileID, ReachMeshIndice(*MeshA, OffsetID))
      Next
      
      ; ReadData(FileID, GetMeshIndice(*MeshA), MemorySize(GetMeshIndice(*MeshA)))
      
    EndIf
  
    CloseFile(FileID)

  EndIf

EndProcedure

; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< Code generated in : 00.006 seconds (66333.33 lines/second) <<<<<
; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

; <<<<<<<<<<<<<<<<<<<<<<<
; <<<<< END OF FILE <<<<<
; <<<<<<<<<<<<<<<<<<<<<<<

And pay attention to this comment in the code :

Code:

; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< Code generated in : 00.006 seconds (66333.33 lines/second) <<<<<
; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

It's fast, isn't it ....

So I'm working very hard as you can see !

Best regards
Guimauve

Ramihyn_ · **Joined:** Fri Feb 24, 2006 9:40 am **Posts:** 290

freak wrote:

This whole "we only want bugfixes ever" argument is nonsense. We already do a bugfix-only version on every second release, precisely for people who say they do not want any new features. If you don't want new features, don't use versions like 4.60, its that simple. Just wait for the 4.61 version which is the bugfix-release of 4.60. But the truth is that very few people seem to do that, because guess what, people actually want to use the new features. What a shock.

Ramihyn_ wrote:

This problem isnt new, the discussion happened years ago already. A simple solution that other projects do, is to handle two versions. One rock-solid branch where _all_ confirmed bugs will be fixed, but no new features will be done and one branch as it is now. So the developers can still have fun introducing new stuff and the users have a version they can actually use to produce software.

The best example for this is probably Debian, and it shows my point exactly. Why do you think the (rather solid, but very old) stable branches are only used for servers and the like? Projects like Ubuntu pretty much only use the up to date unstable or even testing branches, because people want the latest features.

Debian and Ubuntu are two very different target audiences. You picked Debian as an example because it "shows your point exactly".

Ok lets have a look and compare PureBasic and Debian cycles.

PureBasic since 4.5:

*.x versions are introducing new functions and major updates to existing stuff (maps, 3d engine). 4.50, 4.60 for example
*.x1 versions are the bugfix version for the *.x release and are released within a timeframe of 2 to 4 months after *.x. Bugfix only. 4.51 and the coming 4.61 are examples.

4.50 release announced on 7th June 2010
4.5.1 release was announced on 9th september 2010

Debian stable branch(es):

Version 5 (Lenny)

firs release on february 2009
so far there have been another 8 releases, the last fix was 5.0.9 released on 1st october 2011 just 2 days ago!

Version 6 (squeeze)

first released on 6th feb 2011

Lenny is "oldstable" and Squeeze is the new stable branch. Currently version 7 is developed while 5 and 6 are still maintained.

5, 6 and 7 are actively supported. Version 4 was introduced April 2007 and supported till february 2010.

When PB 4.51 was released and i reported a bug, i was told that it was fixed and will be "in the next release". I mentioned back then, that due to the version scheme and release timeframes (4.4 -> 4.51) it was likely that i would have to wait a year or more for that fix. The most constructive reply i got, was that the release times will be quicker in the future. Now it is october 2011 and i test version 4.6 and find lot of bugs in the linux version. The obvious reply is "wait for the stable release".

If i look at the support timeframe for PB 4.5, it is roughly 3 months. Support timeframe for Debian is ~3 years!

See http://en.wikipedia.org/wiki/Debian#Release_history

The bugs i found for the linux version, are all in old existing elements of the PB language. The memory library, standard gadgets, systray/icontray, threads, image/graphics functions and debugger have all bugs in 4.60 in old existing language elements. I only needed to start 4.6B3 and load a project, to instantly notice at least 3 bugs including a crash in the IDE. Look at some of the bug reports, none of them are esoteric.

freak wrote:

Btw, yes this discussion happened years ago, and we reacted to it. The fact that we have a release cycle where every second release is for bugfixes only is the result of that. We actually have the exact model you describe: Development on 4.60 started right after 4.50 was released, while we still fixed bugs for the 4.51 version in a separate branch. It didn't use to be that way.

The change in release cycle was a step in the right direction and honestly it was appreciated. But sadly, it was not the best solution. As you see in the comparison with Debian, the "support timeframe" for Purebasic is very small (4.50 -> 4.51).

So i also think that Debian proves my point exactly

freak wrote:

But some people seem to never be satisfied no matter what we do. Oh, and some of you make it sound like there has never been a usable PB version so far.

4.51 for windows was usable to me and a big step from 4.50. The bugs i found in 4.51 could be worked around (pausethread/createthread, thread debugging - i wrote my own PB debugging tools and rarely use the PB debugger anymore). I can't say if the linux 4.51 version is (as) stable, because i spend all time i have for PB on 4.60 (see below).

freak wrote:

If that was really the case, why are you using it?

I stopped using PB for any new commercial project over a year ago, currently i am just trying to port an existing project to linux.

freak wrote:

Now, it is true that Linux and OSX lag behind the Windows version in bugfixes. We have limited resources and we have to spend them where they have the greatest effect, and quite frankly, the participation and feedback on the Linux and OSX side is not that great. The usage of the OSX version seems to climb only very slowly, and the amount of feedback we get on the Linux side seems to be decreasing even. If you want these versions to become better, you have to do your part: Actively use them and report the bugs you find. Just sitting back and waiting for it to magically become perfect won't change anything.

I invested a lot work and time in testing 4.6 for linux to make it better for everybody, spending many hours trying to hunt down the problems and create small easily reproducible examples to show them, finding clean and easy solutions for the webgadget, compiler switches and others, wrote an updated linux installation howto and helped in the forums when/where i could.

Thats why i use 4.60 beta, to hopefully get a stable 4.61 linux version by actively reporting problems and helping out.

freak wrote:

Btw, in case you didn't notice: We are delaying the 4.60 release because we want to fix more bugs on the Linux and OSX side. We are not abandoning these platforms, but they cannot be the sole focus either for obvious reasons.

I did read that and i honestly feel with you guys. PureBasic is an enormous project and you have a lot of respect from me for that.

Iconically the introduction of the canvas gadget looks like a very promising change for Purebasic, because for the first time the linux and Mac OS users will profit from some of the windows users gadgets. Also "maps" seem to be a really usefull addition and i havent seen problems with them so far (though i havent given them indepth testing yet).

If only the QA and bugfix problem could be improved

edit: fixing quoting mistake

freak · **Posted:** Mon Oct 03, 2011 5:33 pm

See, you are making my point: You claim you only want bugfixes ever, but you do like the new features as well. Maybe it is time to check how realistic your expectations really are.

@J.Baker:
Sorry, my post was not aimed at you specifically.

skywalk · **Posted:** Mon Oct 03, 2011 5:53 pm

@freak
I wish you would reconsider the PB IDE as a separate application on its own schedule.
I also assume it is written in PB?

It just seems silly to request/wait for IDE enhancements when the core language is under so much scrutiny.

Divide and conquer is well represented in history. :wink:

Ramihyn_ · **Joined:** Fri Feb 24, 2006 9:40 am **Posts:** 290

freak wrote:

See, you are making my point: You claim you only want bugfixes ever, but you do like the new features as well.

I need to make this more precise, in my previous reply to you i had a remark that i do not use any of the new functionality since 4.5 (likely since 4.4). It seems due to shortening the reply, this was lost.

The project i port, was written with the language elements of PB 4.31 and reworked a bit for PB 4.4. I dont think i use any new functions of 4.5/4.51 or even 4.6 in the program. I was merely stating that canvas gadgets and maps look like usefull new additions which might have a positive effect on the cross-platform functionality of purebasic in the future. But that has nothing to do with the older project i try to port to linux.

The bugs and problems with the release cycle do not have anything to do with new functionality. Same goes for the problems of J.Baker, as it seems. Nobody of us is talking about problems with any new fancy 4.6 features.

freak wrote:

Maybe it is time to check how realistic your expectations really are.

My expectation is that core functionality of purebasic which was introduced years ago (4.4), actually "mostly" works on the supported platforms (windows, linux, MAC OS X).

J. Baker · **Posted:** Mon Oct 03, 2011 6:49 pm

freak wrote:

@J.Baker:
Sorry, my post was not aimed at you specifically.

Thanks freak.

PMV · **Posted:** Mon Oct 03, 2011 6:53 pm

Guimauve wrote:

I have completed the University by April and I don't have access to many reference books anymore. So for the moment, this project is halted because I don't have any money to purchase the needed reference books.

I know that problem. :lol:

Guimauve wrote:

And pay attention to this comment in the code :

Code:

; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; <<<<< Code generated in : 00.006 seconds (66333.33 lines/second) <<<<<
; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

It's fast, isn't it ....

It looks great. But code generation isn't important for me

And waiting for PB-OGRE3D to be stable and usefull is the
same as waiting for your 3D-Engine. So no finished results
yet. As you can see, it is a lot of work and an end is far away.
Thats the problem for such things and thats why i hope i can
avoid it. "Do it at your own" is not the true solution

@freak
You are always mean when it comes to an every-year discussion. :lol:

I agree with all your points, but you must also agree, that there are
some bugs still for years. I know, that if you could fix that stuff easily,
you would have done it for ages. And i know, you make your best.
So please don't be mad with me ... but the 3D library is still very pure.
And that is not because of missing functions. It is because of bugs.
The normal pb cycle is: new functions are needed 2 major version to work
stable. That is what i have observed since all the years i'm here. Thats
not a reproach, thats ok. But after the whole 3d engine is now new ...
i doesn't want to wait a full year till i can use it again. I know, i'm only
one little man. But thats what i expect. So i do what i can to speed this up.
But as you doesn't have the time to fix all bugs ... i doesn't have the time
to look for a workaround for all found bugs to continue the bug-search.

So when it comes to claim a second bug-fix-version ... i will do it.

Just to get a even better 4.6x version earlier then the 4.7x, so i can
release my game with that. :wink:

If it does not happen, i can say i
have done what i can, stay with the 4.51, wait for the 4.7x

And to be on linux/mac ... i doesn't target this platforms yet, but it is
never bad to have such an option. That means, a full year of bug-fixes
for all platforms to get a very very stable PureBasic Version is one dream.
Realistic or not is not up to me. :wink:

Remember, i know what you are doing for/ with/ in PureBasic.

And with "you" i mean of course anyone involved in it.

MFG PMV

J. Baker · **Posted:** Mon Oct 03, 2011 7:26 pm

I do want to make one more post as I feel I have to clear things up and I do feel like the fire starter here as this was my post.

I do have respect for the PB Team and everything they have done. My post was just me waiving the flag saying I'm at a loss this year with PB. Not that I was pointing a blame at anyone or anything like that. Development has just seemed slow this year due to bugs on the Mac version. And I know you guys are working normal jobs and still working on PB. Along with your personal lives. All is understood.

I look forward to Fred's return and I'm thankful that there will be fixes before 4.60 is released.

freak · **Posted:** Mon Oct 03, 2011 11:29 pm

Sorry if i sounded a bit harsh. I had a bad day, and as PMV noted this discussion is a regular occurrence.

spacebuddy · **Joined:** Thu Jul 02, 2009 5:42 am **Posts:** 170

I have put PB Mac version aside until all the bugs are fixed. I just started using Lazarus on OS/X
and it is amazing and my productivity is much higher. Lazarus is free and comes with a full IDE
and tons of resources since it is based on Delphi.

Kuron · **Joined:** Sat Oct 17, 2009 10:51 pm **Posts:** 919

freak wrote:

This whole "we only want bugfixes ever" argument is nonsense.

I agree. Nobody in this thread said "we only want bugfixes ever". People only said they wanted bugs fixed and concentrated on more than adding new features until the bugs are caught up.

freak wrote:

If you don't want new features, don't use versions like 4.60, its that simple. Just wait for the 4.61 version which is the bugfix-release of 4.60. But the truth is that very few people seem to do that, because guess what, people actually want to use the new features. What a shock.

People have to download the 4.60 version as it contains the bug fixes that have been made since 4.51. How many times have we been told "we won't release another bug fix, this is being applied to the next release version"? Fred has told me that twice via PM since the update model changed years ago. The same thing has been said publicly on the forums several times since the update model changed years ago.

freak wrote:

The fact that we have a release cycle where every second release is for bugfixes only is the result of that. We actually have the exact model you describe: Development on 4.60 started right after 4.50 was released, while we still fixed bugs for the 4.51 version in a separate branch. It didn't use to be that way.

Indeed it didn't used to be that way. We used to see several bug fix releases before a new version with new features was released. 3.94 was so stable because it was 3.94 and not 3.91.

Ever since the update model changed, we get one bug fix release. Bugs that still exist with that release are fixed, but the fixes aren't released until the next new feature version. The new feature version will introduce new bugs of its own, which will be addressed in the next bug fix release, and bugs still existing after the bug fix release will be fixed and we will have to wait until the next new feature version to get those bug fixes. Of course, the new features in this release will introduce new bugs and we have an endless cycle of waiting for bugs to be fixed.

It didn't used to be this way. We used to get several bug fix versions before the next new feature version was released. We also used to be able to download the fixes immediately after they were fixed and not even have to wait for the bug fix version to hit.

freak wrote:

Now, it is true that Linux and OSX lag behind the Windows version in bugfixes.

To me, it makes sense that the OSX version is the buggier of the three because OSX support is relatively new in the overall scheme of things. Linux has been pretty stable by comparison until recently. But Linux itself tends to break things between major OS releases. Unfortunately, it seems the Linux issues are a little more severe (for those experiencing them) than usual.

If you want to develop for Linux, PureBasic is one of the few choices for a compiled BASIC and the same could be said for OSX development. I am just glad Fred and Freak are still plugging away on PureBasic. Their hard work is greatly appreciated.

PureBasic Forum

all projects halted

Who is online