hbomb79 / dynacode

DynaCode is a Graphics Framework for ComputerCraft. This directory contains its source code and builders. Built editions are also available on milestone releases.

Hello world 👋

My name is Harry and I'm a BInfSc graduate currently working on Geneious Prime/Biologics with a brilliant team of people at Biomatters, Auckland, New Zealand.

Most of my experience lies in Lua, Java, C/C++, Ruby, Python, PHP, Go, JavaScript, and TypeScript (including various web stacks/frameworks such as Ruby on Rails, Svelte, AngularJS and RxJS).

In my free time, I'm working on TPA, a concurrent importer for a home movie server, implemented in Go.

Oh... I run arch btw

dynacode's Issues

Scrollbars

The NodeScrollContainer provides an easy, buggy way for developers to create scrollable nodes.

Lets make it a little less buggy shall we; Bugs include:

• Scrollbars scrolling out of view (by 1 or more pixels)
• Scrollbars not reaching the end of the track even after content has been fully scrolled
• Scrollbars have no click detection
• There is no exclusive way to scroll horizontally (meaning if the vertical scrollbar is present its impossible)

To fix this issue I will be re-doing the scroll system. To be honest it was a large fail and I hold that to the fact I copied some of the important code without understanding what it did.

Seeing as though I will not be doing that this time, expect this to be fixed in a short while.

Stage Reorder

If 3 stages are created one will notice unusual behaviour when trying to switch from one to another.

For example, let's say all three windows are overlapping. Stage1 overlaps Stage2 which overlaps Stage3. If Stage1 is currently focused and you click Stage2 to switch to that stage you will notice that Stage3 is actually focused even though it was not clicked and was in the background of the application.

I am at a loss as to why this is occurring but it will be fixed soon, it is an issue I faced in an older version of DynaCode.

Class inheritance issue

Hello class bug my old friend! Yet another class issue has presented itself. This one maybe a little harder to track down but I think I know whats wrong.

Heres an example

class "ScrollContainer" abstract() {
    autoDraw = true
}
ScrollContainer:seal()

class "MultiLine" extends "ScrollContainer" abstract() {
    autoDraw = false
}
MultiLine:seal()

class "Child" extends "MultiLine"
Child:seal()

error( tostring( Child().autoDraw ) )

This will error 'true' even though the MultiLine class is setting it to false.

If this situation is swapped around so its false in ScrollContainer and true in MultiLine it works. The same applies if instead of trying to override true to false, another value like a string is used.

So, I believe that a check is doing if x then instead of if x ~= nil then. I will begin looking for the culprit now.

Stage mapping

If a stage is dragged off to the right of the stage then the mapping system still registers the stage present on the other side of the screen (there is no if x > width kinda thing). Therefore stages on the other side of the screen which are not being obscured act as if they are and disappear because the map data tells it a stage is over it. In reality this is not true.

This issue should be fixed in the next commit.

Class Issues

The DynaCode class system has been harbouring many bugs which must be removed A.S.A.P

The issues:

• Mixins to classes are not inherited via inheritance (if a super uses a mixin the child doesn't)
• Aliases are not inherited as they were supposed to
• Super functions do not always call the correct super directory

This issue is of up most importance and is being worked on right now. All other work as halted until the class system is working as intended.

Class Inheritance

Well, there is another one.

class "Main"
function Main:handleEvent()
    self:onAnyEvent()
end
Main:seal()

class "Parent" extends "Main"
function Parent:onAnyEvent()
    print("Hey from Parent")
end
Parent:seal()

class "Child" extends "Parent"
function Child:onAnyEvent()
    print("Hey from Child")
    print( tostring( self.super ) )
end
Child:seal()

c = Child()
c:handleEvent()

You would expect that when c:handleEvent() is executed "Super Parent blah blah" would be output to the screen... in-fact 'nil' is output. What?

To further confuse things the Parent event is never called, this is not some back and forth action. It is simply skipping over Parent:onAnyEvent().

This one... might take a while.

Threading

More complicated programs (e.g chat program) may benefit from being able to run code in separate threads to the main (UI) thread.

With this system the user could add threads to the Application instance which will have even passed to them before the UI thread so that changes made to the UI are used by any node calculations.

The main thread will likely not be stored in the same way as user created ones. It is most likely that the UI thread will sit outside of the coroutine manager so that after all user threads have been resumed and paused/finished the UI thread gets its turn.

Input, Label and Panel DCML

DCML tags aren't registered for the above nodes. These will be added soon.

Class system malfunction

The DynaCode class system doesn't inherit functions as it should.

Take this example:

class "Parent"
function Parent:test()
  print("hello from parent")
end

class "Child" extends "Parent"
function Child:test()
  print("Hello from child")
  self.super:test()
end

The above code snippet will print:

Hello from child
Hello from child
hello from parent

As you can see, the child function is called twice. This is because the super methods are being copied to the child instance and because of this the call is not being caught by the super proxy until the second call resulting in the instances super not being advanced and therefore self.super refers to itself.

This issue is currently being worked on.

MultiLineTextDisplay Segment Bug

The parseSegmentInformation function is giving off weird results when spaces are not either side of the identifier.

Anchors

Anchors are ways of directing child elements to resize when the parent does allowing for stages to be dynamically filled.

For example, you could set the anchor to 'right-1' and the anchor would keep the right side of the child (X + width) 1 pixel away from the parents edge. It would do this first by trying to reduce the X. If the X has an anchor and its rule already applies then the width will be reduced

Possible settings:

• left
• right
• top
• bottom

TextInput

If a line of text is entered that wraps down to the next new lines are bugged until more text is entered.

Application uses local running tracker

The Application class uses a local variable to keep track of instance running status. This is bad for obvious reasons, mainly because all Application instances will share the same running variable causing unwanted behaviour.

Class problems (again)

It seems as though I missed something as the following code produces a ArrayIndexOutOfBoundsException and many repetitive prints.

class "Node"
function Node:initialise()
    error("initialised")
end
Node:seal()

class "NodeContainer" extends "Node"
function NodeContainer:initialise()
    print("Class NodeContainer super: "..tostring( self.super ))
    self.super()
end
NodeContainer:seal()

class "NodeScrollContainer" extends "NodeContainer"
function NodeScrollContainer:initialise()
    print("Class NodeScrollContainer super: "..tostring( self.super ))
    self.super()
end
NodeScrollContainer:seal()

class "NodeScroller" extends "NodeScrollContainer"
function NodeScroller:initialise()
    print("Class NodeScroller super: "..tostring( self.super ))
    self.super()
end
NodeScroller:seal()

class "Text" extends "NodeScroller"
function Text:initialise()
    print("Class Text super: "..tostring( self.super ))
    self.super()
end
Text:seal()

t = Text()

This is occurring because the Text class isn't advancing its super when it calls NodeScroller.

Class Supers

Another issue has risen from the depths of class hell. This one is fairly easy to duplicate and is pretty obvious when you look at the code. However fixing it will be very difficult.

First, I will explain the problem at hand and then give my idea of how to fix (not the implementation however).

So, let this code serve as our demonstration:

class "Parent"
function Parent:initialise()
    self.test = "hey"
end
function Parent:setTest( t )
    self.test = t
end
Parent:seal()

class "Child" extends "Parent"
function Child:setTest( t )
    self.super:setTest( t )
end
Child:seal()

t = Child()

The problem here is that when we make an instance of Child it looks for an initialise function. Well, it find one on our super because Child did not define its own.

In the super initialise function it sets a variable called test which we have a setter for in the Child class (Child:setTest). Because the initialise function is on the super the class system advances the super of the instance (subsequently to nil) to prevent infinite loops when using multiple supers.

Now, because the instances super is nil when the setTest function tries to use its super via self.super it throws an attempt to index ? (a nil value) just as expected.

Events

Problems with event management has resulted in lots of event code being removed. Before the 0.2 milestone can be achieved this must be re-done correctly.

This one will... take a while. Ugh.