« first day (16 days earlier)      last day (644 days later) » 

00:00
Ooh, we have to change print to os.write(1,...
Everything else should be OK though.
...that's all?
Well, there's other things.
But I think that's the one thing that'll affect us.
uh-huh
Well, maybe when we get to writing out all the functions there'll be more to consider...
By the way, idea I had in the shower: type: (or spec:) for denoting something as a type specifier. Use like type:safe(...).
Traceback (most recent call last):
  File "/home/ubuntu/workspace/src/pytek_parser.py", line 293, in <module>
    T.run()
  File "/home/ubuntu/workspace/src/pytek_parser.py", line 31, in run
    item.execute()
  File "/home/ubuntu/workspace/src/pytek_parser.py", line 199, in execute
    return self.func(self.opts,self.args,self.code)
  File "/home/ubuntu/workspace/src/pytek_functions.py", line 5, in pPrint
    if type(arg).name == "string": os.write(1,arg.val)
TypeError: 'str' does not support the buffer interface
...uhhhh...
? that should be right
I tried running it in C9.
5
A: 'str' does not support the buffer interface Python3 from Python2

ekhumoroIn Python 2, bare literal strings (e.g. 'string') are bytes, whereas in Python 3 they are unicode. This means if you want literal strings to be treated as bytes in Python 3, you always have to explicitly mark them as such. So, for instance, the first few lines of the encoding function should loo...

00:06
Ohhh
Alright, fixed that.
Somewhat annoyingly I can't find where the translator toolchain is
They've moved it
:/
I assume you're already Googling? :P
Yes
Oh, found it.
Dammit we have a problem
We can't use Python 3 for translating
It has to be Python 2
elendiastarman:~/workspace/bin $ python3 ../pypy/rpython/bin/rpython ../src/pytek_main.py
  File "../pypy/rpython/bin/rpython", line 17
    print __doc__
                ^
SyntaxError: Missing parentheses in call to 'print'
elendiastarman:~/workspace/bin $ python ../pypy/rpython/bin/rpython ../src/pytek_main.py
[translation:info] 2.7.6 (default, Jun 22 2015, 17:58:13)
[translation:info] [GCC 4.8.2]
[platform:msg] Set platform with 'host' cc=None, using cc='gcc', version='Unknown'
[translation:info] Translating target as defined by ../src/pytek_main
Traceback (most recent call last):
  File "../pypy/rpython/bin/rpython", line 20, in <module>
    main()
  File "/home/ubuntu/workspace/pypy/rpython/translator/goal/translate.py", line 217, in main
......nuuuuuuuuuuuuuu..........
00:14
:/
Well on the bright side translating Pytek to 2 won't be nearly as painful as translating PyPy to 3 :PP
Oh wait, there's such a thing as PyPy3...
!
Oh, didn't know they had ported it
OK, I'll pull that right away :P
k looks like the branch is py3.3
cloning
Err... I think this might be the wrong branch??
ER yup
Oh, maybe it's py3k
Yeah, think so.
Mercurial is so slow
it's not even funny
5-10 minutes to check out a branch jeez
Dammit, this still isn't Python 3.
What is going on
OK screw this I'll just grab a source tarball
OK ragequit
This is for sure PyPy3 but the translator shell is throwing an error
Absurd.
@El'endiaStarman OK, we're going to have to just port it to Python 2. The translation tool chain doesn't appear to support Python 3 yet
Er... that shouldn't be too problematic right?
We don't have much code yet
Actually we can just 3to2 it
@El'endiaStarman You still there?
we needz you
00:57
How much progress has been made already? (You should add a link or something to the room description)
@PhiNotPi We don't have a GitHub yet.
Do you have any example code?
Tons.
One second.
func:isPrime(n) {
  return ([1..n]~\product,n->\mod) == n - 1
}
\print("Hello, World!")
Unfortunately we haven't quite decided whether for will take an anonymous function or a code block yet :P
Anyways, the spec is (almost) done and the parser is working but only supports strings, functions and natural numbers
So Hello World works but nothing else
> [1..n]~\product,n->\mod
Yeah.
It's called a chain.
01:08
That took me a while to understand.
It's the same as \mod(\product(1..n),n)
But it looks cleaner once you understand how it works.
Also this is a thing:
{x | 0 < x <= 3 and x in \Z}
Set-builder notation.
The current planned types are: sets dictionaries lists strings tuples chains lambdas numbers and complex numbers
Here's quickref.md:
##Sequences

Sets: {1,2,3} or {x | 0 < x <= 3 and x in \Z}
Alternative: `{x | x in 1..3}`

Strings: "123", '123'

Lists: [1,2,3]
Another way: `\first[3](\N)`

Tuples: (1,2,3)

Dictionaries: {"foo":1,"bar":2,"baz":3}

##Functions

Chains: func1,func2,...->func3,func4,...->...

(Usage: args~chain)

Anonymous Functions: <args:code>

(Usage: (<args:code>)[args...])

Named Functions: func:name[options](args) {code}

(Usage: \name[options](args))

##Control Flow

<> denote anonymous functions.

\if(condition,<body>)
What is the difference between a list and a tuple?
Lists are of the same type with variable size, while tuples can be of many types but are of fixed size?
That's how I think I've seen it done before.
Lists are mutable tuples are immutable
Just like Python.
I guess I'll have to brush up on some Python 101.
Not really, Pytek won't be all that similar to Python.
01:15
One thing I've kinda wanted to do is make an actual non-golfing language.
But looking at the stuff so far, it is definitely going is a completely different direction than how I would probably take it.
01:48
@AquaTart Sorry, was chatting with parents.
Anyways the translation toolchain doesn't seem to work with Python 3 for whatever reason
I tried PyPy3 and it still didn't work
That's a bummer.
Yeah. :/
How painful will porting be?
There is a 3to2 tool.
Personally, I'm thinking about not bothering with PyPy.
Really?
01:51
@PhiNotPi Perhaps you can still benefit from the parser.
Er... is not being able to use Python 3 that big a deal?
I haven't used Python 2 in years.
I personally think that we need RPython if we want the language to be usable speed wise
We can always port what we have now and do a benchmark.
01:54
I'm not against porting it to Python 2, I just don't want to do that myself.
Speed is not a big deal for me, in large part because I know computers will continue to get faster.
And if we really cared about speed, we would be writing this in C, and I am not doing that. :P
hahaha
True enough
OK, so forget about PyPy.
I think having a way to compile it into an executable of some sort would be nice though.
cx_freeze is still a thing right?
You know, just to have it nice and bundled.
I don't know what cx_freeze is.
It (used to be) a popular module for taking a bunch of Python files and compiling them into a standalone executable.
OK, it's still a thing. Good.
That's what we were trying to do :P
02:16
So, what's happened with Pytek recently?
Quartata - excuse me, @AquaTart - tried to use PyPy to make the Pytek interpreter run faster, but it apparently doesn't support Python 3 (at least, not easily).
I'm not sure if I got that right.
Oh, bummer
Do you have an official home for the spec somewhere?
How much of the syntax has been decided upon? Like, I know you haven't decided how for loops would work, but besides that.
@ETHproductions We have one on Cloud 9. Ish. Scroll up a couple pages to see the current quickref.md.
@PhiNotPi Most of it, I think.
Any other documentation I'm not aware of?
02:27
Not really. It's basically all in the chat transcript.
I guess I can work on getting a spec up tonight.
02:46
Thanks.
No problem. ..... What are you saying Thanks for? :P
03:17
My idea for a language feature: do{}while(){} the first {} is performed before the condition is evaluated, but each iteration travels across both the first and last {}, so you can have do{take input}while(input is invalid){print "ur wrong, try again"}
^ probably doesn't fit in with Pytek at all
What does fit for sure is wanting to reduce programmer work so far as bookkeeping goes.
That particular feature might not make it in that exact notation, but I'd like to include it somehow.
Maybe you could even have do{}while(){}while(){} (or alternatively do{}while()do{}while()do{} for maybe some added consistency)
That looks like it'd be a pain to read.
probably
Naw, I'm thinking of somehow using \func[opts](args){code}.
03:26
Actually, I think my first example is equivalent to for(take input; input is valid; take input){print "ur wrong, try again"}
@PhiNotPi Mind elaborating on exactly why this feature would be useful? I can think of a couple scenarios, but I'm not sure what you have in mind.
Ehh, I don't really have any strong justification, other than a literal "try to take input from a user" example.
yeah
I know there have been situations where I want to read input in the conditional so I can leave the loop when it's empty, but that means I don't get to use it in the body.
Would that be fixed by simply allowing assignment in the conditional?
... if I understand the issue correctly
I could make assignment operators "return" the value that was assigned.
03:31
That could make sense for "chained" assignment.
while input():
    print(input())
a = b = c could be interpreted as a = (b = c) with the assignment returning the value.
An alternative is to special-case stuff, like Perl's beautifully hacky while(<>){}
That alternative doesn't sound particularly appealing to me. :P
03:48
Crazy notation idea: 1 [] 5 for [1,2,3,4,5], 1 [) 5 for [1,2,3,4], 1 (] 5 for [2,3,4,5], 1 () 5 for [2,3,4].
How do you tell the difference between [] and an empty list?
Context, maybe?
Hmm we will have to figure out how to parse binary operators
I think I'll be implementing the shunting yard algorithm, in essence.
I feel like it's easy to run out of symbols to use.
03:53
yeah
@El'endiaStarman Wouldn't it just be isPossible if two approriate nodes surrounding it and isComplete if it matches <any binary operator> followed by something?
@AquaTart Think about 2 + 5 * 3 - 4. Also, I don't have a provision for isPossible or isComplete to look backwards.
What about isPossible if matches any binary operator followed by something and always assumed to be complete?
You couldn't have = and == though hrmph
Colon for assignment? Or too weird?
04:00
I always disliked the extra shift+key for that kind of thing.
Actually wait you could have them both
But == would have to be checked first
OK, I think that works.
I'm away from C9 but I'll take a crack at that later perhaps
I'm gonna put another dict key for shunting infix operators in there.
Horrible idea, inspired by the "use colons for assignment": Since we already have {"a":val1, "b":val2, "c":val3} for dicts, but there's also the idea {a=val;b=val;c=val} where the {} is a code block, why can't the two be the same?
hmmmm
It may not be good to have two completely distinct ways of notating the same thing.
I'm saying, have them be the same, and notate them to be the same.
As in, the "keys" to a dict are like the local variables of a code block.
You could do something like data = {a=7; b=2; c=b+a} and then data is a dict where data{c} == 7
04:17
....that could be really interesting and/or backfire horribly, and I'm not sure which it'll be. :P
In Perl, objects are dicts (well, generally speaking).
So, if you really wanted to, you could turn this into a way to do OOP.
That's pretty much what they're like in JS too.
dict data = {a = 7; func:inc(){a = a +1}};
data{a} returns 7, data{inc()} modifies the object, data{a} returns 8.
except, now we have a weird nested {a=a+1} thing.
Yeah. I'll think on that.
Which, I suppose by extension of the current theme, is itself a dict with no keys (since the a isn't a local variable at that level), which is only evaluated once the function inc is called.
It's getting kinda weird at this point.
I need to catch some sleep.
IDK where I was going with the above suggestion.
04:32
haha
@Mego: want an invitation to the Cloud9 VM we're developing on?
Anonymous
@El'endiaStarman Sure
Anonymous
But if I see you've made folders for version control like VTC I'm gonna rm -rf --no-preserve-root / it
hahaha
I'll actually use GitHub releases this time. :P
Anonymous
Good
I do plan on hosting an online interface on my website like I did with Minkolang, and putting the source code up on GitHub.
Okay, you have a C9 account, right? How should I invite you?
(By which I mean, what's your username?)
Anonymous
04:45
Just mego
Alright, access granted.
Feel free to look around.
Anonymous
Neato
Anonymous
I'll do that in a little bit
Anonymous
Playing minecraft right now
 
2 hours later…
Anonymous
Pretty much, yeah. :P
 
1 hour later…
07:41
define function eval-polynomial(x, coefs)
  let sum = 0;
  for (i from 0, c in coefs)
    sum := sum + c * x ^ i;
  end;
  sum;
end;
I really like this idiom of i from 0.
Required reading: Design Patterns. A bunch of useful ideas in here.
08:48
Idea: figure out a way to let users define syntax for a new object.
Say, @polynomial[ <isPossible>, <isComplete> ]{<parsing code>}.
I have no idea how I'd make this work, but wouldn't it be cool to define the syntax for a polynomial and then just use that later in the program and it just works?
There are far too few delimiter symbols... :(
If we want to stick to ASCII, that is. Which I do.
 
6 hours later…
14:45
@El'endiaStarman OK I had a good idea last night about control flow syntax
Basically we make {} the delimiters for anonymous functions
And we make the preprocessor automatically replace {} with ({})
And we use [] args for the conditions and what not
That way \while[True]{ ... } is really \while[True({ ...})
I know this sounds weird but I've thought it through and I cannot think of a single situation where this replacement would break anything
oops I meant \while[True]({...})
too late to edit
15:11
@El'endiaStarman syntax for an object leads to an explosion of messiness. However, it you allow objects to define certain operators (and give no intrinsic meaning to those operators), then I think that approaches what you want
also, if you require all functions to start with a backslash, and you allow first class functions, then you must have static typing
or, at least, typing between functions and other variables
The syntax he proposed above appears to allow direct modification of the parser
right
and I think that leads to an explosion of messiness
I find that intriguing but a little too complex for pure objects, yea.
But perhaps for defining shorthand ways of creating certain objects...
also, one of the greatest strengths of Python is that it doesn't include certain common idioms in programming
such as do-while, switch statements, so on
having a language that does everything and anything isn't a powerful language, because it makes it difficult to build on top of preexisting code
15:27
Is this currently a c9 project? If so, my username is phinotpi
I think your inital statement says it well: "identifying and leveraging common patterns". a do-while (for example) isn't a common pattern, and support for such an idiom will hold back your language IMO
16:02
@PhiNotPi yes
 
2 hours later…
18:07
FINALLY got cxFreeze to install
Some stupid bug with Ubuntu...
oops I installed the py 2.7 version
oh wait I'm stupid
called cxFreeze wrong
18:35
OK, got it working.
18:52
The cx_freeze exe is much faster.
So that's nice.
19:36
@AquaTart I think this is essentially unnecessary, because you can just write the pLoop function to use what's inside the {}, which will be passed in to the code parameter.
@PhiNotPi I wouldn't mind inviting you, but considering that I want to avoid bloat and such, I'm just wondering how you plan on contributing.
@El'endiaStarman Oh, I wasn't really planning on changing anything.
yup, that's it
 
1 hour later…
20:54
@El'endiaStarman But this way we don't have to write special code to parse it
It can just be a normal function
Anyways I made a small build script for cxfreeze
What I'm say is that there is no extra parsing work. It's all in pLoop in pytek_functions. (At least, I think that'd work.)
Ohhh.
Oh, I see how you did that.
That's nice.
@El'endiaStarman I added a little factorial function so we can test numbers and performance
okay okay I'm on the VM now
oops syntax error
I can't Python for beans today apparently
21:07
Hmm although
Pytek's print doesn't do numbers yet
We should just screw type checking and make it alias directly to print
I noticed that yesterday and just realized why.
Well, but I'm not doing that because I want to make print more powerful/useful. Like centering text.
Oh. OK.
We should add a \str then.
(for now)
Anonymous
/me watches the language discussion going by, not following most of it
Have you had a chance to look around the code yet?
Anonymous
Not yet
21:11
I can explain its structure and answer any questions.
@El'endiaStarman it no work
outputs nothin
Oh I know why
But it has the name "number".
Oh.
So it should be number?
gimme a moment
k
Just so you know, you can do builds with bash build.sh
I presume you noticed that already
Anonymous
21:15
Why not make the building process a run conf?
YUS
Okay, I really should write an AST_tree_print function.
21:31
@Mego so that when we put it on le github other people can build
Anonymous
No I mean keep the build script, but add a run conf to build it for ezpzness
eh
not that much effort to cd out and bash build.sh
elendiastarman:~/workspace/bin $ time ./pytek ../tests/test3.pytek
3628800

real    0m0.045s
user    0m0.036s
sys     0m0.004s
hmm running with python is one millisecond faster
Hmm this bothers me
The executable version always seems to be slower
And I think I know why
Anonymous
What about PyPy?
21:43
We'd have to use Python 2
Translation toolchain doesn't work for 3
Well, we can run Python3 code with PyPy3.
21:56
Really annoying fact: we can't use AST_node constructors in pytek_functions because they're not defined yet.
Solution: shunt all the AST_node stuff into its own file.
It would be nice if we could just deal purely in either AST nodes or Python types
Unwrapping and wrapping just screams bad performance.
I'd rather stick with Pytek objects because that way, all of the capabilities are present.
OK.
So we need to make these functions return AST nodes
21:58
Hmm. Consider closures. How would you make those work solely in Python types?
Yeah.
If we make the functions return AST nodes we won't have to do all these shenanigans
but we can't construct them yet :/
Anonymous
@El'endiaStarman Decorators :P
Anonymous
lambda a: lambda b: a+b is a simple closure in Python. Its type is just function.
Not the point
The point is that it is inconsistent.
We'd have to type check for AST nodes and Python types.
No, we need to make all functions return AST nodes.
Orrrrr make it so that when we call a function with an AST node we just give the value
Two options.
The former is better obviously
But the latter is easier
floopin circularity problems...
22:05
Did you make the AST_node constructor?
AST_function needs functions, which needs to come after pFac, which needs to come after AST_node...
oh lmao
Not usually a problem in Java :P
Oh hey, worked it out.
@El'endiaStarman By the way, I hate to say this...
But I think you should give some serious thought to PyPy again
You mean porting to Python 2?
22:10
I know Python 2 isn't your forte but it isn't too big of a difference (and I know Python 2 much better than Python 3)
I'll use 3to2 to port it later and show you the benchmarks
But I'm sure it'll be faster.
I'm worried about the times we're getting right now.
I think I've said before that I don't mind if you do the work.
Anonymous
Python 2 is actually super easy coming from Python 3 in everything except Unicode
When we're done fixing this I'll make a copy, 3to2 it and see what happens
Besides, if PyPy has been used for several other languages, then why not Python 3? That just doesn't make sense.
Anonymous
22:12
@El'endiaStarman Implementation takes time
PyPy3 is a thing
Just not the toolchain
I think they wrote PyPy3 in Python 2
Anonymous
Main differences: everything returns a list unless it's in itertools, print and exec are statements, / is integer division with int arguments, backticks are repr, and longs are annoying in golf.
Oh, by the way, idea I had last night in bed: foo.{x,y,z} as a shortcut for [foo.x, foo.y, foo.z].
Anonymous
Wouldn't foo.[x,y,z] make more sense?
22:15
That'd work too, yeah.
@Mego I hate to say this but I like all of those differences :P
Having to do list( all the time kinda annoys me
Anonymous
I like Python 2 for golf, and Python 3 for real development
Anonymous
The nice thing is, a lot of the time, you don't need to cast to a list
Anonymous
Only really for printing
I know that's what they say but I always find myself casting anyways :/
Anonymous
22:17
Memory efficiency dawg
As in it always throws errors without it...
@Mego You should really join the C9 and watch us do stuff
@El'endiaStarman OK I put in an isNode call to factorial so that should work now
Yeah, it works because I moved the isNode function definition.
Yep, all good.
Passes test #4
But we will need to do something about that
This is just temporary
pFac still only returns a Python number though.
Right.
But we don't have an AST_node constructor I thought
22:25
I don't know how to AST_number it, and now that I think about it, that'd be a bit hard to do since AST_nodes expect lists. Hmm.
grrrrrr dependency issues...
? wat happened
Just in reference to the difficulty of using node constructors.
I think I have a solution, though it's a bit hacky...
Wait, is it possible to do circular imports?
In Python? Don't think so.
Should import only once.
yeah
Wait, we DO already have a circular import and it didn't barf!
Yeah.
I don't think it barfs...
22:30
It doesn't because pytek_objects is only imported with import ....
22:41
@El'endiaStarman do you have a formal definition for your syntax?
Uh, read the transcript? :P
(No, I don't, not yet.)
sorry, I read back a while, but not all of it
Yeah, there is a lot.
One of these days I'll get around to putting up a subdomain for Pytek, which will have the spec up there.
23:21
Alright. I'm off to youth group, and I'll be back within 3 hours.

« first day (16 days earlier)      last day (644 days later) »