99 replies to this topic

[Yevano]

SEE - An object oriented alternative to traditional CC programming.

Introduction

SEE is a convenient Lua runtime whose goal is to allow programmers to more easily write readable and reusable object-oriented code. The project is open source and has been in development since August, 2013.

Features

• Automatic setup of classes and object instances.
  
  • All OOP code works the same, no obscure differences with peoples' code.
• Standard library written to speed up development.
  
  • Custom string and array implementations.
    
  • Custom IO wrapper objects for binary and plaintext.
    
  • More convenient string matching with the Matcher class.
    
  • Use the standard library in most cases, or use native imports to get close to the metal!
• Preprocessor.
  
  • Import classes and native functions before runtime.
    
  • Set class parameters, such as class inheritance.
• Multi-file programming. 1 class per file.
  
  • Each class file has its own global scope.
    
  • Better organization of code. (No more 2000 line files for large programs.)
• Managed threading system!
  
  • Spawn threads arbitrarily throughout your program and they'll just work.
    
  • Thread interruption.
• Object-oriented event system.
  
  • Capture events and call on their methods or get their data.
    
  • Create your own event classes and register them.
• Libraries are dead simple to make.
  
  • No difference between runnable code and a library.
    
  • Need to reuse your code in another project? Just add the classpath.
• Exception handling.
  
  • Makes error handling much easier.
    
  • No parsing of error strings to figure out what happened.
    
  • No returning error codes or having to check if an error occurred in a return value.
    
  • Print error tracebacks.

Tutorials

sci4me http://www.computerc...524-see-basics/

Get SEE

Simply download the installer to your CC computer using pastebin get 4RgrdVgE installer.
or
Access the entire repo at https://github.com/Yevano/see.

If anyone wants to talk about the project, or anything else, I frequent the #computercraft channel and I'm usually connected to my TeamSpeak3 server at yevano.me.

Edited by Yevano, 09 April 2014 - 10:20 PM.

[Parmacoy]

I dont really have much idea what this is, why should we use this over the generic api's. Yes I did have a look at the links, and its still not making sense.

[Yevano]

Parmacoy, on 05 August 2013 - 06:36 AM, said:

I dont really have much idea what this is, why should we use this over the generic api's. Yes I did have a look at the links, and its still not making sense.

The reason to use SEE is not necessarily for the standard library, but for the automatic OOP (Object Oriented Programming), the non-polluted global namespace, and the multi-file importing system. I realize that most people here won't know what to do with an object oriented environment, but I'll be making a few simple tutorials once I get more of the standard library done.

The main goal of SEE is to be convenient for the programmer. Lua programs which may have been thousands of lines previously can be distributed to multiple classes for much better organization.

[Yevano]

Update https://github.com/Y...792d6d94bd4e893

• Added exception handling. An example can be found here.
  
• Fixed some problems with casting. I suspect there are still some bugs, but at least string conversion works fine now.
  
• Added new global function STR. Just a more convenient way to convert a Lua string to a see.base.String. Example:
  
  • System.print(STR"A string!":length())

Now that some more of the low-level stuff is out of the way, expect to see more in the standard library. The library will hopefully wrap over most of the native Lua libraries by the next couple of updates. After that, I'll probably go and fill in documentation holes and add error throwing to the library functions.

[Yevano]

Update

• f90064667914056fc06aa23b1c79d992283851e4
  
• d0b7f988f9750c084b333ce8bfea06eff5e1f24f
  
• e724673f0b287970b32849b5de7410c7314f5431
  
• 37f4a5e39f41190e94dcc51e864d54ba298e0e22

There's still much work to be done, but here's some new updates. Still not too much progress on the library, mostly runtime stuff.

• Added argument checking utility (see.util.ArgumentUtils).
  
• Added Math class.
  
• More casting fixes.
  
• Changed class importing to happen after a class has been loaded.
  
  • Added __static invocation to support this behaviour.
• Added an installer. Find it here.
  
• Added standard library argument to SEE executor program.
  
• Added tracebacks for exceptions and Lua errors, making program debugging much easier.
  
  • Planning to add Exception:printStackTrace in the next update. Tracebacks are currently only printed for uncaught exceptions.
• Added see.rt.IndexOutOfBoundsException.

[Yevano]

Update

• de68e1f6161f2f2d6acd0020accd0d404e97bffe
  
• 4c3582949fb041d59cfa90292f5c8b5bf3973f9c
  
• 2a947148fbffcb790b509069bd1476c258b29da5
  
• f1224cfad4b6542ffdb62178a126e28dfc70b5c0
  
• fece31c0a1cb328ee71938bb095688fc5d5f8a75
  
• e9607d7a976af2ca5a34076b503d8a3aca226e64

I won't put these into word form, at least not now, so if anyone is really interested just look at the commit page.

So, most of the important API wrapping has been done. The runtime is fully functional, and at this point I'm confident people could write full-blown programs with this thing. For this reason, I'm going to make some simple usage tutorials. I'm pretty sure nobody is using this yet, so once I get the tutorials up, I'm hoping to see some feedback. I'll make an update here once I've written some tutorials.

EDIT: I decided to go ahead and write a setup tutorial. Should help people at least get started.

[TorakTu]

Parmacoy, on 05 August 2013 - 06:36 AM, said:

I dont really have much idea what this is, why should we use this over the generic api's. Yes I did have a look at the links, and its still not making sense.

It actually does make sense what he is "trying" to do, and its a nice attempt. Problem with all this is that most all of us will not use it. Microcrap does the same thing with their "DotNetFrameWork" and a lot of us programmers hate it. Plus, I personally won't convert to this for computercraft because that would mean that I would have to rely once again on someone else to update their code / runtimes. No thanks. This doesn't make it easier as the OP is trying to suggest. It only makes it that much harder since people would have to understand what this is in the first place, not to mention, install it. Which most people will not. If this was for regular LUA, this actually could be useful. But not for LuaCC do to the limits of CC. Not to mention it could potentially add to the lag in minecraft.

[Yevano]

TorakTu, on 16 August 2013 - 04:31 PM, said:

It actually does make sense what he is "trying" to do, and its a nice attempt. Problem with all this is that most all of us will not use it. Microcrap does the same thing with their "DotNetFrameWork" and a lot of us programmers hate it. Plus, I personally won't convert to this for computercraft because that would mean that I would have to rely once again on someone else to update their code / runtimes. No thanks. This doesn't make it easier as the OP is trying to suggest. It only makes it that much harder since people would have to understand what this is in the first place, not to mention, install it. Which most people will not. If this was for regular LUA, this actually could be useful. But not for LuaCC do to the limits of CC. Not to mention it could potentially add to the lag in minecraft.

I just want to make a few points here since you've got so many negative things to say about this project.

• Do not tell me that nobody will use this. This is first and foremost for MY usage. The reason I made this is because I got tired of the OOP boilerplate code I would have to write for every CC project I did. It just made any new project that much more daunting and less fun to write for me. So what you say is untrue. Even if nobody else in the world uses this thing, I will be using it. But rather than just keep it to myself, I've decided to share it and make it open source for anyone else to use.
  
• .NET framework is the farthest thing you could think of from this. It is a closed source library and runtime produced by a huge company. It is of little relevance.
  
• Nobody is forcing anyone to use this or "convert" to it.
  
• If I were to stop working on this, which I'm sure will happen eventually, the code is still out there, and anyone is allowed to create their own branch.
  
• Having to learn new concepts is a part of being a programmer.
  
• The runtime can be easily ported to non-embedded Lua. Many classes in the standard library are already mostly compatible with non-embedded Lua.
  
• Since class loading is done only at the beginning of runtime, there is very little overhead. OOP is handled by metatables, a standard part of Lua.

[TorakTu]

Yevano, on 16 August 2013 - 05:18 PM, said:

• .NET framework is the farthest thing you could think of from this. It is a closed source library and runtime produced by a huge company. It is of little relevance.

Your making Runtime files that is Object Oriented in it's very design. This is EXACTLY like DotNetFrameWork.

Yevano, on 16 August 2013 - 05:18 PM, said:

• Do not tell me that nobody will use this. This is first and foremost for MY usage.
  
• If I were to stop working on this, which I'm sure will happen eventually, the code is still out there, and anyone is allowed to create their own branch.

And that is cool and all. But all I said is that very few, if any, would actually understand how to use this, much less install it. So your reply shows your taking this personally. If your not likeing the opinions of others, maybe you shouldn't have put this out there. Welcome to being a programmer.

Yevano, on 16 August 2013 - 05:18 PM, said:

• Having to learn new concepts is a part of being a programmer.

I couldn't agree more. However this is not new. Do a search on this and other forums of others whom have spoke about OOP with LuaCC. You will see that this idea hasn't gotten too far with people. And based on what a lot of us know about CC and LuaCC and the comments on this and other forums, in many opinions, OOP in CC is not a good idea.

And if your taking this as an attack on you personally, you shouldn't. I don't know you. People have opinions and we are all allowed to state what we think on a project.. as many of us do here. Heck even my own projects suck for some folks here. So you shouldn't take this personally.

[lifewcody]

So if i use SEE i have to go through your API, then CC's API to execute the code. No thanks . I see your idea and it has a lot of potential. If you made it an OS for CC it would be better.

[theoriginalbit]

jubba890, on 16 August 2013 - 06:44 PM, said:

I see your idea and it has a lot of potential.

haha I See what you did there! xD

[lifewcody]

theoriginalbit, on 16 August 2013 - 06:45 PM, said:

jubba890, on 16 August 2013 - 06:44 PM, said:

I see your idea and it has a lot of potential.

haha I See what you did there! xD

It does. He is on the right track, but not the right type of program

[TorakTu]

jubba890, on 16 August 2013 - 06:49 PM, said:

theoriginalbit, on 16 August 2013 - 06:45 PM, said:

jubba890, on 16 August 2013 - 06:44 PM, said:

I see your idea and it has a lot of potential.

haha I See what you did there! xD

It does. He is on the right track, but not the right type of program

I agree. It's a cool idea if it is integrated as part of an OS.

[Yevano]

TorakTu, on 16 August 2013 - 06:30 PM, said:

This is EXACTLY like DotNetFrameWork.

You're comparing apples to oranges.

Also, I don't take your comment as an attack on me personally. I just wanted to correct the incorrect assumptions and false claims you made about what my goals are here.

TorakTu, on 16 August 2013 - 06:53 PM, said:

I agree. It's a cool idea if it is integrated as part of an OS.

Because the runtime is implemented as an API, you can actually do just that for almost any environment. Have a look at https://github.com/Y...er/see/apis/see.

Anyways, this a good time for me to mention that I haven't had much time to make tutorials, and school is coming soon. But I will get to it hopefully this weekend.

[lifewcody]

Yevano, on 16 August 2013 - 07:04 PM, said:

TorakTu, on 16 August 2013 - 06:30 PM, said:

This is EXACTLY like DotNetFrameWork.

You're comparing apples to oranges.

Also, I don't take your comment as an attack on me personally. I just wanted to correct the incorrect assumptions and false claims you made about what my goals are here.

TorakTu, on 16 August 2013 - 06:53 PM, said:

I agree. It's a cool idea if it is integrated as part of an OS.

Because the runtime is implemented as an API, you can actually do just that for almost any environment. Have a look at https://github.com/Y...er/see/apis/see.

Anyways, this a good time for me to mention that I haven't had much time to make tutorials, and school is coming soon. But I will get to it hopefully this weekend.

I mean instead of CraftOS with its code. Make your own. Then it wouldn't be as resource consuming.
Also what TorakTu is trying to say is that .NETFramework is an extension to windows to convert the whatever.NET to work. This is about the same. You would use SEE to convert FOR EXAMPLE see.redright to rs.setOutput("Right") just an extension. Good idea for new programmers for possible easier understanding, but as a viable programming structure. I do not think its going to get as many programs as CraftOS.

[Yevano]

jubba890, on 16 August 2013 - 07:14 PM, said:

I mean instead of CraftOS with its code. Make your own. Then it wouldn't be as resource consuming.

What do you mean by that? Even a custom OS uses the libraries and events provided by bios.lua. As far as function call overhead goes, I'm pretty sure it's negligible. If it really was a problem, you can still do native importing to talk directly to the CC libraries. But really, most of the time a CC program is waiting for new events, and not doing any processing.

[theoriginalbit]

Yevano, on 16 August 2013 - 07:20 PM, said:

What do you mean by that? Even a custom OS uses the libraries and events provided by bios.lua.

I would assume he means make a real OS, one that replaces the bios.lua

[lifewcody]

theoriginalbit, on 16 August 2013 - 07:22 PM, said:

Yevano, on 16 August 2013 - 07:20 PM, said:

What do you mean by that? Even a custom OS uses the libraries and events provided by bios.lua.

I would assume he means make a real OS, one that replaces the bios.lua

yes

[Yevano]

Update (latest commit 17f3e6e4cdf3c0fc8f644e82ddc050d9071e958a)

Since last update, mostly small fixes. The important feature just added is runnable code archives. Archives can now be added to the class path in just the same way folders were. Archives can be created using see -p <src> <dest> and they can be unpacked using see -u <src> <dest>. This will make program distribution much easier, since you can just pack your programs and upload them to pastebin, or whatever other file host you choose.

In future updates, expect to see archive run configs, an installer generator which automatically packs class paths into one natively run file, and a hidden installation file which lists info about a computer's SEE installation.

[lifewcody]

A cool feature would be have a list of programs you can download. That would be cool