99 replies to this topic

[Yevano]

distantcam, on 15 October 2013 - 01:52 AM, said:

The pastebin no longer installs correctly.

Yeah, I usually forget to update it. I should really just have it download the install program from the repo and run that, but for now I'll just edit in the newest installer into it. Today, I think I'll be cleaning up OP and working on making see.concurrent a bit more full fledged (tasks, future objects, thread joining, etc.).

Edit: Updated OP with relevant new feature set and my teamspeak. Later I'll add example code to the OP to show off the features a bit better.

Edit: Aaand this is awesome.

In addition to tasks, I also added a convenience function for running process-heavy code. When Thread.work is first called, it saves the time it was run inside the thread. Once it gets called 1/20 seconds after it was first called, it sleeps and resets the time. As a rule of thumb, you should use this function whenever your thread needs to do busy calculations.

[email protected] see.concurrent.Thread
[email protected] see.concurrent.Task

function Test.main()
    local piTask = Task.new(calculatePi, 1000000):setCallback(function(result)
        System.print(result)
    end)

    repeat
        System.print("Waiting...")
        Thread.sleep(1)
    until piTask:isFinished()
end

function calculatePi(iter)
    local pi = 4
    for i = 1, iter * 2, 2 do
        Thread.work()
        pi = pi - (4/(1 + i * 2))
        pi = pi + (4/(3 + i * 2))
    end
    return pi
end

[Yevano]

So apparently class inheritance hasn't been working. Surprised that I never realized it. Anyways, it's working now. I also added .__super to class tables. This weekend I want to work on fixing more issues and on my super special GUI library (I'll give it a repo once I have all basics in place and working).

[Engineer]

This really reminds me of Java. Of course just the way how you have your packages and your love for OOP made you do this.
I can see how this just combines 2 languages in one. At least, for the logic part. I mean, we can create easily objects with this, but we still can have our love for the scoping in Lua.

I really would use this if I wrrent the guy that never uses other API's and stuff. For example, my friend LBPHacker is explaining me how base64 works, he wrote an API for it but I still want it to be done my way. Not because his code is bad or anything, but just for the challenge. And that way I'm learning a lot of binary manipulation etc.

But to get back to SEE, I'm still that picky guy who would write his own framework to suit his needs. I mean, you're things are not bad at all, but I wouldn't use certain things or I want something to do extra stuff.

I really appreciate that you took chance to even publish it, and seeing this getting very underrated in the beginning I just want to say you did a good job on this. Even someone who just started programming deserves positive feedback, just to keep them motivated. I'm doing that with you, the only difference is that you didnt just start programming, but you just started writing this very promising framework.

[Yevano]

Engineer, on 17 October 2013 - 04:51 PM, said:

This really reminds me of Java. Of course just the way how you have your packages and your love for OOP made you do this.
I can see how this just combines 2 languages in one. At least, for the logic part. I mean, we can create easily objects with this, but we still can have our love for the scoping in Lua.

I used to do quite a bit of programming in Java. I really did enjoy the way they did their libraries and almost everything about how the pieces just fit together in general. Java has a huge impact on the project.

Engineer, on 17 October 2013 - 04:51 PM, said:

I really would use this if I wrrent the guy that never uses other API's and stuff. For example, my friend LBPHacker is explaining me how base64 works, he wrote an API for it but I still want it to be done my way. Not because his code is bad or anything, but just for the challenge. And that way I'm learning a lot of binary manipulation etc.

But to get back to SEE, I'm still that picky guy who would write his own framework to suit his needs. I mean, you're things are not bad at all, but I wouldn't use certain things or I want something to do extra stuff.

I get where you're coming from. There have been a few implementations of OOP on the forums which I thought were pretty cool, but never used because none of them were very feature-filled, or they were implemented in a way I felt I would do differently. I would like to note that at least with this project you can change those features to add in your own spice, since the project is open-source.

Engineer, on 17 October 2013 - 04:51 PM, said:

I really appreciate that you took chance to even publish it, and seeing this getting very underrated in the beginning I just want to say you did a good job on this. Even someone who just started programming deserves positive feedback, just to keep them motivated. I'm doing that with you, the only difference is that you didnt just start programming, but you just started writing this very promising framework.

Thanks, and the positive feedback definitely helps.

[Yevano]

My GUI library is coming along. Once it's done, I think it will be a great example of SEE's power.

[email protected] weegui.element.Panel
[email protected] weegui.element.Label

[email protected] see.concurrent.Thread
[email protected] see.util.Color

function WeeGuiDemo.main()
    local labelPanel = Panel.new(nil, 2, 2, 20, 10, Color.BLUE, Color.BLUE)
    local label1 = Label.new(labelPanel, 2, 2, "Hello!", Color.BLUE, Color.BLACK)
    local label2 = Label.new(labelPanel, 2, 3, "4", Color.BLUE, Color.BLACK)

    local pi = 4
    local i = 1
    while true do
        Thread.work()
        pi = pi - (4/(1 + i * 2))
        pi = pi + (4/(3 + i * 2))
        label2.text = STR(pi)
        i = i + 2
    end
end

[Yevano]

Just a few updates:

Threads were being run as soon as Thread:start was invoked. Now, they just get scheduled without being run. This is to prevent multiple threads from running on top of each other. I added a new event called SignalEvent. It's not all that useful now, but once I make events passable to specific threads, it will be useful for waking up threads or sending messages across threads. Something like Events.send(thread1, thread2, ...) perhaps.

Also, I've been working hard on the gui lib (It's called WeeGui by the way). Since the last post I implemented element draw buffers, element event listening, and a window implementation.

[email protected] weegui.concurrent.GuiManager
[email protected] weegui.element.Button
[email protected] weegui.element.Element
[email protected] weegui.element.Label
[email protected] weegui.element.Window

[email protected] see.concurrent.Thread
[email protected] see.util.Color

function WeeGuiDemo.main()
    local testWindow = Window.new(nil, 2, 2, 30, 16, "Test")
    local contentPanel = testWindow.contentPanel
    local label1 = Label.new(contentPanel, 2, 2, "Hello!", Color.BLACK, Color.WHITE)
    local label2 = Label.new(contentPanel, 2, 3, "4", Color.BLACK, Color.WHITE)
    local button1 = Button.new(contentPanel, 2, 5, 10, 5, "STOP", Color.GRAY, Color.WHITE)

    local running = true
    button1:addListener(Element.CLICK, function(button, x, y)
        GuiManager.stop()
        running = false
    end)

    local pi = 4
    local i = 1
    while running do
        Thread.work()
        pi = pi - (4/(1 + i * 2))
        pi = pi + (4/(3 + i * 2))
        label2:setText(STR(pi))
        i = i + 2
    end
end

[brett122798]

This is looking quite pleasing so far. Such a shame that there's hardly any people looking at this project. But, of course, all those Lua'ers(Is that a word?) don't know the wonders of Object-Oriented Programming over functional.

For the past inactive months on these forums(since May), I have dedicated myself to Java, and nothing else. I have made way bigger and more complex applications (and Bukkit plugins) than I would have sticking to Lua. The golden key was OOP. Java also has a nicer API and syntax as well.

Lua is still nice 'n all, it just doesn't cut it for me, though.

[sci4me]

Yevano, on 21 October 2013 - 08:34 PM, said:

Just a few updates:

Threads were being run as soon as Thread:start was invoked. Now, they just get scheduled without being run. This is to prevent multiple threads from running on top of each other. I added a new event called SignalEvent. It's not all that useful now, but once I make events passable to specific threads, it will be useful for waking up threads or sending messages across threads. Something like Events.send(thread1, thread2, ...) perhaps.

Also, I've been working hard on the gui lib (It's called WeeGui by the way). Since the last post I implemented element draw buffers, element event listening, and a window implementation.

[email protected] weegui.concurrent.GuiManager
[email protected] weegui.element.Button
[email protected] weegui.element.Element
[email protected] weegui.element.Label
[email protected] weegui.element.Window

[email protected] see.concurrent.Thread
[email protected] see.util.Color

function WeeGuiDemo.main()
	local testWindow = Window.new(nil, 2, 2, 30, 16, "Test")
	local contentPanel = testWindow.contentPanel
	local label1 = Label.new(contentPanel, 2, 2, "Hello!", Color.BLACK, Color.WHITE)
	local label2 = Label.new(contentPanel, 2, 3, "4", Color.BLACK, Color.WHITE)
	local button1 = Button.new(contentPanel, 2, 5, 10, 5, "STOP", Color.GRAY, Color.WHITE)

	local running = true
	button1:addListener(Element.CLICK, function(button, x, y)
		GuiManager.stop()
		running = false
	end)

	local pi = 4
	local i = 1
	while running do
		Thread.work()
		pi = pi - (4/(1 + i * 2))
		pi = pi + (4/(3 + i * 2))
		label2:setText(STR(pi))
		i = i + 2
	end
end

man, that is reallly cool.

[Yevano]

Well, it's been months since I've last posted here. The project isn't dead. I just recently started working on this again, and I've fixed a couple things. Exception handling now works with the new threading system, and anonymous classes have been implemented. The anonymous classes are pretty neat, so I'll show an example of how they work here.

function AnonTest.main()
    local A = class("A", { },
    function()
        function A:init(x)
            self.x = x * 2
        end
    end)
    local B = class("B", {
        import = {
            "see.util.Math";
        };
        native = {
            "print";
        };
        extends = ExTest;
    }, function()
        function B:init(x)
            A.init(self, x)
        end

        function B:y(z)
            print(Math.pow(self.x, z))
        end
    end)
    B.new(3):y(4) --> prints 1296
end

Next up, Thread:interrupt(). This will make it possible to tell a thread to stop waiting on an event by throwing an exception.

[surferpup]

Very impressive. I just finished reading through all of your posts -- you are in high school? Dude. This is amazing work. Kudos. I will have to dig into it and see if I can get it to do something.

[Yevano]

surferpup, on 10 February 2014 - 11:25 PM, said:

Very impressive. I just finished reading through all of your posts -- you are in high school? Dude. This is amazing work. Kudos. I will have to dig into it and see if I can get it to do something.

Thanks for the kind words! Your best bet right now is to clone right from the repository and create the .see configuration file in the root directory of whatever CC computer you copy everything to. It should contain install_dir = "see install dir here". There's also an automatic installer but (Edit: Installer works just fine, simply use the one mentioned in the OP.) I'll need a moment to make sure it still works and add the new files to it (I really need to automate that part some day).

When you start writing applications, the standard library is a good reference for how to setup your code. If you want to do something more advanced, like plugging the SEE runtime into your own application, take a look here for reference.

Edit: Oh and Thread:interrupt() was committed. Yay.
Edit2: The application runner (see/programs/see) throws better errors now.

Edited by Yevano, 11 February 2014 - 10:33 AM.

[sci4me]

man... keep this up! this really is impressive! now to start coding with it! you should consider working on an eclipse plugin that (maybe could extend the lua plugins..) would add SEE projects and a build system... would be useful.

Edit:

I am using this to build my projects:

local tArgs = { ... }
if #tArgs ~= 3 then
error("Usage: build <src> <mainClass> <target>")
end

shell.run("see", "-p", tArgs[1], tArgs[1] .. "_p")
shell.run("rgen", tArgs[1] .. "_p", tArgs[2], tArgs[3])
fs.delete(tArgs[1] .. "_p")

Edit:

I keep getting this weird error trying to execute a program:

bios:339: [string "DB-r"]:4: escape sequence too large

I've had that multiple times.. and IDK how I fixed it the first few times... but, every time, the code has been correct... this is a bug in SEE :/

Edit:

Ok, currently the code causing that error is this:

if query[1] == "get" then

end

Actually, the specific piece that breaks it is this:

[1]

WTF did you do lol, fix ???

I put this:

local one = 1
query[one]

And that fixed it (lol)....

Edit:

OK this one is by far the most confusing so far:

function Modem:broadcast(msg)
    if msg == nil then
         error("nil")
    end
    self:send(CHANNEL_BROADCAST, msg)
end

I call it like this:

modem.broadcast("getDNSID")

and get this:

Error: nil

WTF? WTF????? WHAT?!?

Edited by sci4me, 14 February 2014 - 07:36 PM.

[Yevano]

I'm not sure about the escape sequence error. Since it's a bios error that doesn't really tell me very much. I think that error may be produced by the generated runnable itself and not the code within it. It's definitely weird.

Edit: According to http://www.lua.org/s...5.1/llex.c.html, there seems to be a hard limit on escape sequences, UCHAR_MAX (255). It'd be good if you could send me a runnable file which reproduces the problem. I believe it can be fixed if I have the runnable concatenate multiple strings at runtime so that the lexer won't complain Ok, new idea. After rereading the code, it looks like it just sets a limit on the escape number where in the escape \xxx, xxx cannot be greater than 255. This would explain why the error only occurs when you add the number back in. In the runnable, the escaped archive string must have an escape code in it right before the 1, causing it to produce something like \xxx1. The 1 contributes to the escape code, and the error gets thrown because the number is perhaps in the thousands. I'm not sure why the character in front of the 1 would be escaped though. I'll look into it.

More Edit: Alright, so starting at line 68 of rgen Cameron wrote some code to deal with unprintable characters more elegantly than before, reducing archive and runnable sizes. However, it still has a few holes in it. The reason your code broke was because of the number right after the left-bracket. Currently the converter escapes brackets for some reason, most likely because they are used in commenting, but this isn't actually necessary since they are inside of a string anyways. Taking out the unnecessary things will fix the problem, but I'll need a special case for the situation where there are escaped chars right before numbers.

Until the above is fixed, (Hopefully tomorrow if the power comes back) you can test your programs using the -r switch to run programs from directories without any building necessary.

To your second problem, you need to call instance methods like this:

modem:broadcast("getDNSID")

Otherwise, the method won't get the object value for self. (Basically you're giving it "getDNSID" for self and nil for msg.)

I don't recall ever making a Modem class, so I'm guessing it's your own wrapper. If you post the code I can help you further.

Edited by Yevano, 14 February 2014 - 09:40 PM.

[sci4me]

Okay, thank you! As for the modem, wow I feel dumb. Its just a little wrapper for rednet: https://github.com/sci4me/CC

Awwww, symlinks dont work with CC? :'(

Edited by sci4me, 15 February 2014 - 11:23 AM.

[Yevano]

With the help of sci4me, (you were a great tester ) rgen is fully working. After I fixed the character escape problem, we realized there was something else wrong. Trivial hello world programs would work, but I was unable to generate a working runnable for Omegle-CC. The problem was that rgen was still running the main code as the main coroutine, which was the way things were before I wrote the new threading system. The inner event loop and thread manager was not being started, causing all sorts of weird things to happen when trying to pull events. Anyways, now that it works, I'm going to fix up igen (which works, it creates an installer) and write a ton of error handling code.

After that, maybe I'll finish up weegui and make an IDE.

[sci4me]

I have submitted a pull request

• https://github.com/Y...afb10c8035279cb

Fixes SEE support for OpenPeripherals
- Native Events - events that are handled like normal (not using the SEE event system)

Edited by sci4me, 16 February 2014 - 10:43 PM.

[Yevano]

sci4me, on 16 February 2014 - 09:40 PM, said:

I have submitted a pull request

• https://github.com/Y...afb10c8035279cb

Fixes SEE support for OpenPeripherals
- Native Events - events that are handled like normal (not using the SEE event system)

To expand:

There was a problem where peripheral.call would always fail on OpenPeripheral methods. After taking a look at the OpenPeripheral code, we found that the methods would yield to pull an event, which it was doing in a way incompatible with SEE's event system. The easy solution was to register events which are allowed to be caught up into the system as native events. You can do this with any event by the way, so this could be used for other custom peripherals as well.

[TechMasterGeneral]

Awesome!!

[Symmetryc]

Wait...so this supports both CC and OC?

[sci4me]

Symmetryc, on 17 February 2014 - 09:30 PM, said:

Wait...so this supports both CC and OC?

It could be adapted to work with OC but at the moment the standard library and (i think, maybe..) some of the actual see api is CC dependent.. but, it would be fairly easy to make it work with OC. Whether we will make an OC version or not.. idk. It would be a lot of work to maintain both branches of it.