Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - iconmaster

Pages: 1 [2] 3 4 ... 6
16
Wait, so basically if I want to make a game for both the HP Prime and the computer at once then I now can if the computer language is available for Source? O.O

Yes.

Of course, Source still needs a library for drawing...

17
I still plan on buying  a Prime one day. This will be one of the first programs to run on it.

Once I buy it. <_<

I'll definitively have to try Source at one point too, although since I prefer to not learn multiple languages at once I'll most likely stick to PPL at first, but if I keep running into roadblocks or can't stand it, I might attempt a switch to Source.

Anyway keep the good work on this. If this do come to fruition this is definitively front page material I'll be suggesting to staff.

I'm flattered. Thanks for all your support!

Speaking of support, Source now allows you to write your own custom compiling targets! Source can compile into any language you write a Java plugin for. To show off this system, I made SourceBox, a Source interpreter. Get all 3 needed jars at:

https://drone.io/github.com/iconmaster5326/Source/files
https://drone.io/github.com/iconmaster5326/SourceBench/files
https://drone.io/github.com/iconmaster5326/SourceBox/files

Put Source and SourceBench in the same directory, as usual. Run Bench once, and close it. There is now a folder called BenchData, and a subfolder called libs. Put SourceBox in there, and restart Bench.

Now, try to use that 'Platform' drop-down box.

With SourceBox, you should be able to run this directly on your computer:

Code: [Select]
@export
function powers() {
@inline
local end = 10
print("The first "~end~" powers of 2 are:")
local i,a,b = 0,0,1
while i<end {
a = a + b
b = a
print(b)
i+=1
}
print("Done!")
}

18

Some news!

First of all, I gave a presentation on my language to my peers this week! My presentation included all presently implemented features of Source. Get the slides here!


Second of all, here's an example of how the type system works:


Code: [Select]

function types() {
local a as real //a is of type real
local b as string //b is of type string


//a = "" //real!=string, ERROR!
b = "" //string==string, fine

a = 1 //fine
//b = 1 //ERROR!


local c //c is ??, which is the base type (?) weakly typed


c = 1 //fine, c is now of type real?, again weakly typed
c = "" //fine, c is now type string?


local d = 44 //d is of type real?
a = d //real==real?, fine
//b = d //string!=real?, ERROR!
d = "" //real?==string?, fine


local e as ? //e is ?, the base type, but strongly typed


e = "" //you can set anything to e
//... But the reverse is not true.
//b = e //string!=?, ERROR!
d = e //??==?, fine
}

19
Data types are (mostly) working. I'll talk more about how they work in Source, but for now, have an example of how data type methods work:


Code: [Select]

function list.test(a as list) {
local i = a.size()
print("The list is "~i~" elements long.")
while i>0 {
print("Element "~i~" contains "~a[i]~".")
i-=1
}
print("Interesting!")
}


@export
function main() {
local l as list = range(1,10)
l.test()
}

20
Now you can inline variables, too!

Code: [Select]
@export
function hello() {
   @inline
   local x="Source"
   print("Hello, "+x)
}

Compiles to:

Code: [Select]
#pragma mode( separator(.,;) integer(h32) )
hello();

EXPORT hello()
BEGIN
 print("Hello, "+"Source");
END;

You can make inlined stuff equal to non-constant pieces of code, so they're a little like a macro. You can even redefine constants!

Here's a program showing off everything I've implemented recently:

Code: [Select]
@export
function test() {
 @inline
 local end=10
 local a,i=range(1,end),1
 while i<=end {
  print(a[i])
  a[i]*=2
  i+=1
 }
 print(a)
}

21
A Java exception has occured D:
It was compiled in Java 8. Do you have Java 8 installed?

22
As for Gotos I'm not a big fan of them anymore since they often cause memory leaks in certain languages or are slower, but they can be handy in some cases if you use and name them properly.

I'm not usually the best fan of them, myself; however, I would believe using nothing but GOTOs would be faster than most loop constructs currently available. If I was programming directly in HPPL, that would be a pain. However, I'm writing in Source. :)

Anyways, I whipped up a little interactive Source application to let you guys see how Source is coming along. You'll need the following 2 files:

https://drone.io/github.com/iconmaster5326/Source/files
https://drone.io/github.com/iconmaster5326/SourceBench/files

Put them both in the same directory, and then run SourceBench.

Here's what SourceBench looks like:
Spoiler For Spoiler:


You put Source code in the input box, hit compile, and see your HPPL output. I suggest trying examples from earlier in the thread!

23
Oh yeah I meant if somebody made the stuff required to run native code. It's possible but the question is if anybody will ever bother, considering how powerful HP PPL already is. You can already have SNES-like graphics without much slowdowns and even 3D polygons now, so if somebody decides to make a game in native code then it will most likely be a port of Doom or emulators.


And yeah glad you added If/while lol, but again I once made a game on a calculator that lacks While/For/Repeat so I guess they're not that essential, after all. :P (I had to use Lbl, Goto, IS>() and DS<())

Yeah, I don't suppose native execution will come soon; I mean, there's like 3 or 4 willing Prime fans total :P

Well, if only we had GOTOs. I would actually like a GOTO; Source could really take advantage of GOTO-based optimizations.

I'm trying to make for loops now. Speaking of that, Source probably won't optimize FORs to MAKELISTs right off the bat; I'm still implementing anonymous functions, which that would depend on internally.

24
Glad to see more optimizing being done :) . Now if only ASM/C was possible on the Prime so that such program could be compiled directly on-calc or even in actual ASM code. In its current form it's still promising, though, especially considering how fast HP PPL is.
Well, do DO have a way to run native code, it's just that we would have to write a LOT to get a basic framework for anything going. Actually getting reliable ASM execution is far beyond my ability, I believe.


About on-calc execution: In retrospect, perhaps I should have made the Source compiler in C and not Java. :P

But trust me, the minute we have a framework for native code, Source will be able to compile to it. Source is designed so it can compile to multiple platforms.

In other Source news, Source now has ifs and while loops. They're kind of important, I've heard.

25
Vectors?

Matrices (and thus, vectors) will have thier own instantiation syntax.

While vectors are used in math a lot, [] are list deliminators in some programming languages; this is a more programmer-oriented language rather than HPPL, which is more math-oriented. Don't wory, though, in due time there will be an interface for all of HPPL's math functions.

26
Good news! I fixed the optimization routines.


Now, this:


Code: [Select]

@export
function hello() {
local a,b = 1,2
a,b = b,a
print(a+" "+b)
}


compiles into this:


Code: [Select]

#pragma mode( separator(.,;) integer(h32) )


hello();


EXPORT hello()
BEGIN
 LOCAL a:=1;
 LOCAL b:=2;
 LOCAL %TMP2:=b;
 LOCAL %TMP3:=a;
 a:=%TMP2;
 b:=%TMP3;
 print(a+" "+b);
END;


Which is both optimized and correctly prints out 2,1. However, it still could be more efficient.

27
So how do you plan to distinguish lists from block braces? The primary reason we decided to go with the begin/end instead of { } was due to confusion and potential conflicts.

In Source, lists use [] instead. A deviance from the HPPL, sure, but one that works.

Even if I make {} the list delimiters, I believe my parsing system could handle it given some slight changes.

28
Nice so far. By the way at one point you should try to make an example program, such as a port of the "famed" Wacky Fun Random Numbar Generator v1.000069. Perhaps a graphical demo too to showcase the speed and size.

That's a good idea. Right now, the language is about 90% stable; some things might change before final release, but not many. The big thing that's in the air right now is the functions I'll be providing. Even if these two things are true, I probably should work on making actual programs in Source.

Nice. Would you mind pull requests in the future? :)

I would love some collaboration!

29
Some more progress. This time, we have inlining!


Code: [Select]

@inline
function test() {
   local a = 1
   return a + 1
}


@export
function hello() {
   print(test()+1)
}


In Source, the @inline directive tells the compiler to directly insert the code of the function test() into hello().


Here's what it compiles to:


Code: [Select]

#pragma mode( separator(.,;) integer(h32) )


hello();


EXPORT hello()
BEGIN
 LOCAL %TMP0:=1;
 LOCAL a:=%TMP0;
 LOCAL %TMP2:=a;
 LOCAL %TMP3:=1;
 LOCAL %TMP1:=%TMP2+%TMP3;
 LOCAL %TMP6:=%TMP1;
 LOCAL %TMP7:=1;
 LOCAL %TMP5:=%TMP6+%TMP7;
 LOCAL %TMP4:=print(%TMP5);
END;


Notice the non-existence of test(). It was inlined!

EDIT: Also, some work on simplifying compiled code is being done. However, it doesn't work perfectly yet:

Code: [Select]
@export
function hello() {
local a,b = 1,2
b,a = a,b
print(a+" "+b)
}
Code: [Select]
#pragma mode( separator(.,;) integer(h32) )

hello();
EXPORT hello()
BEGIN
 LOCAL a:=1;
 LOCAL b:=2;
 b:=a;
 a:=b;
 print(a+" "+b);
END;

30
On the other hand, if you try to store a picture-based map data with DIMGROB, then the result is atrociously large, since each pixel is like 64 bytes or so in unicode form (maybe more?).  Size-wise, every other alternative is more viable, but again this calc has a lot of memory so that is not a big issue.

This is why you use ICON, IIRC. It's better than DIMGROB, even if not by much. You can edit the contents of an ICON, just not change its size. You can even pass around the string that represents the ICON if you need to.

Pages: 1 [2] 3 4 ... 6