[Gambas-devel] To Tobias : about gb.ncurses interface

[Benoît Minisini]

Le 09/06/2012 23:21, tobi a écrit :
> On Mon, 04 Jun 2012, tobi wrote:
>> On Mon, 04 Jun 2012, Benoît Minisini wrote:
>>> Le 04/06/2012 18:14, tobi a écrit :
>>>>
>>>> I cannot disagree to "strong" suggestions ;)
>>>>
>>>> In fact, splitting Color to Color and Pair is a good idea.
>>>>
>>>> I didn't concern much with the Color class yet. I remember to have read something about the
>>>> [0..1000] arguments but I simply didn't recognise it (strange, because I wrote the code :)),
>>>> will be done.
>>>>
>>>> So, the next thing - if I ever finish that NoDelay input mode - would be to implement controls. I
>>>> have only some thoughts and half of a draft about that but it will likely turn the Window class into
>>>> a container-only object, so, in the future, there will be no distinction (and yes, in the meantime,
>>>> we can assume that borders are one character each)
>>>>
>>>> Screen.RepeatDelay is o.k., too.
>>>>
>>>> Regards,
>>>> Tobi
>>>>
>>>
>>> I want to release 3.2 next week. If I can't, it will be at the end of
>>> the month.
>>>
>>> Can you synchronize your development so that Gambas 3.2 has a clear
>>> distinction between the stable part (whose interface should not change)
>>> and the unstable part (controls, and maybe NoDelay) ?
>>>
>>> --
>>> Benoît Minisini
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Gambas-devel mailing list
>>> Gambas-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>>>
>>
>> I don't think so but of couse, I will try.
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Gambas-devel mailing list
>> Gambas-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>>
>
> I saw, you have "changed the version" but not already tagged in svn?

I will tag it in a few days I think. Just fixing some remaining bugs...

>
> Please, don't wait for me with that.

Just ensure that you will be able to keep the Gambas 3.2 gb.ncurses 
interface in the next versions without changing everything.

Gambas 3.X must be able to run Gambas 3.Y code as soon as Y < X

> The differences in the debugger are overwhelming on the new
> machine (migrated from 32 to 64 bits)... I could recently spot some strange debugging output from
> gb.ncurses: on my older, slower machine, the limit is far earlier reached than here but I seriously
> get entire stack frames smashed when *excessively* hitting non-ascii chars on my keyboard - don't
> ask me why because the only stack buffer I am using in this case, if I see correctly, is written to
> by the kernel and only used by ncurses. Since there are no concurrent threads, I'm out of ideas so
> far and consequently must step through the code in greater detail... That's where the new
> environment comes in - and, of course, the period of big tests at the end of the school year.
> 64 bit addresses only are really difficult to read if you're not used to ;) I can even hardly read
> the assembly code here...
>
> Sorry for the still unfinished interface, it must wait until 3.3 ;)
>
> Regards,
> Tobi
>

Have you used valgrind on your code? It may help...

-- 
Benoît Minisini