<Shad0wCore>
Hey Sean, you know about this data isolation stuff in Java by doing getters/setters?
<Shad0wCore>
Would you say that's something that you should do in Pony too?
<Shad0wCore>
or use bare vars/lets
<SeanTAllen>
something sylvan and i have talked about is having properties for public fields so you can start with direct access but override at the class without having to rewrite the callers if you want to do something more than provide direct access
<SeanTAllen>
the boilerplate of a "getter" that only returns the value of the field is pretty blah
<SeanTAllen>
the style of programming i do doesn't usually involve getters and setters, i'm more of a "tell rather than ask" person with my approach to classes
<SeanTAllen>
so rather than getting data from a field, i ask the class to do something and never ask for the value
<Shad0wCore>
Hm okay
<SeanTAllen>
the exception would be when i use a class similar to a c struct where its all data
<Shad0wCore>
Before I take a look on this... Is it gonna be caps again?
<SeanTAllen>
the default refcap for a method is box
<SeanTAllen>
yes
<Shad0wCore>
ffs
<SeanTAllen>
and you are saying "this is a method i can call on a ref or a val"
<SeanTAllen>
but "it returns a ref"
<SeanTAllen>
that isn't allowed
<SeanTAllen>
a val can't return a ref
<SeanTAllen>
if you want BlueprintSpecs that is returned to be mutable then.. you want
<SeanTAllen>
fun ref box get_spects()
<Shad0wCore>
I guess Pony at all is not gonna slow me down learning, I guess it's gonna be those damn caps
<SeanTAllen>
which says "i can only call this method on a mutable Blueprint
<SeanTAllen>
do you want BlueprintSpecs that you return to be mutable?
<Shad0wCore>
Yes
<SeanTAllen>
ok so
<SeanTAllen>
fun ref get_specs(): BlueprintSpecs ref
<Shad0wCore>
I mean I'm progressing real fast with learning Pony but those damn caps.. Jesus.
<SeanTAllen>
It takes some getting used to
<SeanTAllen>
You'll get there
<SeanTAllen>
you seem to be doing quite well
<Shad0wCore>
There are some things I'd like to complain about but I guess it's just my lack of knowledge
<SeanTAllen>
Well, Pony is pre 1.0. There are plenty of things we complain about that we want to fix
<SeanTAllen>
Some of your complaints are probably 100% valid
<SeanTAllen>
Some are probably tradeoffs
<SeanTAllen>
Some are probably more of an ignorance thing
<SeanTAllen>
That was the case with my early complaints
<SeanTAllen>
Keep asking questions, we will keep answering and we do observe as best we can what folks have a hard time with and think about how things can be improved
<Shad0wCore>
My complains would be about caps, unsatisfying compiler error messages which drive me just nuts because they lack so much detail. I mean for a pro it wouldn't be that of a problem because he's used to it but for noob/newbie/beginner it's just "hell"
acarrico has joined #ponylang
<Shad0wCore>
I'd like to see just the error with as much detail you can give me. Like, give me a description what went wrong and how to fix it. The whole "info" section that's printed is for me totally redundant
<Shad0wCore>
imho
<SeanTAllen>
well refcaps are the heart of Pony. without them, there's not much there that would be a reason to use. refcaps let you do unsafe things safely. without them, you'd be doing lots of safe things safely and it would be much closer to erlang.
<Shad0wCore>
Also, the formatting is weird too
<SeanTAllen>
if you have error messages that you think would be more helpful, please do open messages.
<Shad0wCore>
I'll create some sample messages tomorrow
<SeanTAllen>
i would say that the compiler messages are giving a description of what went wrong, its just not one that you understand at this point in time. so there are certainly improvements that can be made.
<Shad0wCore>
The thing I'm porting to Pony is a server orchestration software for Minecraft. Quite a task tbh
<SeanTAllen>
if you came from an OCaml background the syntax would probably be rather familiar. F# folks and other folks from that general ML branch quickly feel at home.
<Shad0wCore>
OCaml?
<SeanTAllen>
Well, we'll be here to help as you run into issues
<Shad0wCore_>
The funny thing is, as soon as I get into learning a new programming language the thing I think about the most time is "Omg, you're writing so much shit code right now. How are gonna the pros react to this"
<Shad0wCore_>
lol
Shad0wCore has quit [Ping timeout: 256 seconds]
<SeanTAllen>
I think you will find that we are very non judgemental
<Shad0wCore_>
Yeah
<SeanTAllen>
You should see my Python code
<Shad0wCore_>
But also, to improve my skills in writing *good* Pony code, please let me know the mistakes I've made / I make
<Shad0wCore_>
Feedback is the most important thing for me
<SeanTAllen>
yup
<SeanTAllen>
will do
<Shad0wCore_>
What was the rule you were talking about? Let the function decide what to do with the field?
<Shad0wCore_>
Another thing: Classes, Interfaces, Traits etc. were addressed in the tutorial. Why no Struct types? I just had a look at the "pointer.pony" file and there was class of type "Struct"
<Shad0wCore_>
was a class of*
<SeanTAllen>
struct is like class without the object header. you'd want to use to when calling into C
<SeanTAllen>
generally discouraged others
<Shad0wCore_>
Oh oka
<Shad0wCore_>
okay
<SeanTAllen>
FYI, when I have some time, I am going to be opening an RFC to remove Traits from the language
<SeanTAllen>
leaving just Interfaces
<SeanTAllen>
assuming its accepted
<SeanTAllen>
I know Sylvan is on board, we'll see about the rest of the community
<Shad0wCore_>
I didn't get the concept of traits and interfaces. It's just about this naming thingy
<SeanTAllen>
At the moment, there is nothing you can do with traits that you cant do with interfaces
<Shad0wCore_>
Exactly
<SeanTAllen>
there's a small difference in one area but...
<SeanTAllen>
i wont even bother explaining it because well, it would take a long time to walk through it all
<Shad0wCore_>
It's kinda irritating. I'd vote for the interface because it is the most recognizable buzz-word
<SeanTAllen>
well, interfaces are structual typing
<SeanTAllen>
and traits are nominal typing
<SeanTAllen>
do you know the difference between the two?
<Shad0wCore_>
I had a look at the tutorial and still don't get the differences
<SeanTAllen>
ok
<Shad0wCore_>
and I still*
<SeanTAllen>
are you familiar with the term "duck typing"?
<Shad0wCore_>
No
<SeanTAllen>
"if it quacks like a duck and walks like a duck, it must be a duck"
<emilbayes>
I guess it is trying to say that I cannot access length.size() because it is later consume, however, I didn't think the reference was consumed until the later consume call?
<vaninwagen>
Let me check emilbayes
<vaninwagen>
Yeah, that is interesting
<vaninwagen>
Possibly due to desugaring
<vaninwagen>
But you can live without that consume in that case
<vaninwagen>
When i have some time tonight, im gonna look into it and report back
<emilbayes>
vaninwagen: Ah, the consume ended up there from trying to fix other errors. Okay so this works. Thanks vaninwagen !
<vaninwagen>
I know that journey. You just try to escape, but you just bury yourself deeper in compiler errors
<vaninwagen>
Only a chainsaw attached to your arm can help there
_whitelogger has joined #ponylang
Foaly has joined #ponylang
<emilbayes>
vaninwagen: Haha wat
<vaninwagen>
Sorry, getting into the christmas spirit over here
<emilbayes>
Haha enjoy!
srenatus has joined #ponylang
rjframe has joined #ponylang
acarrico has joined #ponylang
<emilbayes>
Made my first pony package! Not sure I did it right, or duplicated the effort of someone else, but it's mine and it's my first; https://github.com/emilbayes/pony-endianness
<emilbayes>
Constructive critique welcome
<emilbayes>
Like, if I should restrict the ref caps on the Array[U8]
<emilbayes>
I guess it is `Array[U8 val] val` by default?
<vaninwagen>
It is ref actually, box is enough, so you can cover both ref and val
<emilbayes>
vaninwagen: So I should have `Array[U8] box` to be the most flexible?
<vaninwagen>
Yep
<emilbayes>
So box is sufficient because the data contained by the array is val? Eg. I don't care someone else "writes" to the array (whatever that means) because the U8's contained within are immutable?
<emilbayes>
(just making sure I get this right=
<vaninwagen>
Because you only access the read_*() methods which only require a box receiver
<emilbayes>
Ahhh ok
<emilbayes>
So the receiver is whatever you call on? I was a bit confused by the terminology
Foaly has quit [Quit: Now 'mid shadows deep falls blessed sleep.]
<emilbayes>
vaninwagen: Are you mfelsche on github?
<vaninwagen>
Now you uncovered my secret identity
<vaninwagen>
Now i need to kill you
<emilbayes>
lol, wasn't so hard
<vaninwagen>
Yeah, the receiver is the object that you call methode on
<vaninwagen>
*methods
<emilbayes>
vaninwagen: Are you going to CCC by the way?
<emilbayes>
That makes sense now
<emilbayes>
learning so much
acarrico has quit [Ping timeout: 246 seconds]
_whitelogger has joined #ponylang
<SeanTAllen>
Nice evil dead reference vaninwagen
<vaninwagen>
emilbayes: no, untortunately not.
<vaninwagen>
emilbayes: i am thinking, would it make sense to add methods for reading different endianness numbers from byte arrays, like read_u32_be()
Foaly has joined #ponylang
<vaninwagen>
SeanTAllen: that reminds me, i still need to watch the first two die hards until christmas!
<emilbayes>
vaninwagen: you mean to Array[U8] directly?
<emilbayes>
vaninwagen: im too new here to have an opinion. Unless it gives some kind of performance benefit I do like having it externally better since it gives me more freedom and agility
<emilbayes>
But I guess reading different byteorders is so fundamental that it wouldn’t change anyhow
<vaninwagen>
Yeah, emilbayes, analog to the read_u*() methods
<vaninwagen>
Bur having your package releases us from the pressure
<emilbayes>
I don’t know what the feeling is pony community. Lots of small packages or large libraries
OtakuSenpai has joined #ponylang
<vaninwagen>
My feeling is, as long as we dont have no leftpad, small packages are fine
<SeanTAllen>
vaninwagen is the best person to answer that. my ignorant statement would be "that sounds like a good idea".
<emilbayes>
SeanTAllen: Alright cool :) Seems like intrinsics should be faster than doing that other stuff (guessing that there is a carry/overflow register)
<vaninwagen>
emilbayes: agree with you and SeanTAllen
<emilbayes>
vaninwagen: Alright I will try!
<emilbayes>
big pony day for me
acarrico has joined #ponylang
srenatus has quit [Quit: Connection closed for inactivity]
<SeanTAllen>
big pony day!
<emilbayes>
Is `make test` sufficient to run tests for builtin?
<emilbayes>
Is that because I have a wrong llvm or something?
<emilbayes>
That is, latest master then `make` then `make test`
<SeanTAllen>
that's...
<SeanTAllen>
ummm
<SeanTAllen>
wow
<SeanTAllen>
ummm
<SeanTAllen>
can you try a `make clean` then try again?
<emilbayes>
SeanTAllen: Yes. On a old macbook 1.3GHz, so will take a little while
<SeanTAllen>
how old is that macbook?
<SeanTAllen>
system76 has the meerkat's on sale. i am going to be getting one i think.
<SeanTAllen>
i have 2 older macbook pros that are slowly dying.
<emilbayes>
2016, but it's a macbook, not pro, not air
<SeanTAllen>
i bought a system76 laptop last year but i never use it because i hate the trackpad. i forgot that before a window of macbook pros that i never bought laptops because i hate all the trackpads
<SeanTAllen>
the surface book trackpads are really nice though
<emilbayes>
I want a thinkpad next :)
<SeanTAllen>
emilbayes: i cant reproduce your proble,
<SeanTAllen>
btw, you can do less than `make test` to run the unit tests.
<SeanTAllen>
that does a lot of other stuff
<SeanTAllen>
`make test-stdlib` is probably what you want?
<emilbayes>
SeanTAllen: Yes, thanks!
<emilbayes>
compiling the stdlib is the bulk of the time tho
<SeanTAllen>
Some ponybench and updating the commit comment (in git rather than github) would be awesome. So we can refer back to it in the future when spelunking through the history
<SeanTAllen>
I'm one of the people who ends up doing bisecting and figuring stuff out from history so i really value good commit comments.
<SeanTAllen>
Some of ours are really good. Some are not so good.
<SeanTAllen>
Some committers have really good commit message habits. Some have pretty bad commit comment message habits. Some fall in between.
<SeanTAllen>
Thanks theodus !
<emilbayes>
SeanTAllen: I did look at your commit guide. What do you suggest instead of that message then?
<SeanTAllen>
Rationale for the change. "There's now builtin in support for this" sort of thing.
<SeanTAllen>
I think that unto itself is a reason to do it
<SeanTAllen>
performance ¯\_(ツ)_/¯
<emilbayes>
I will change it later then. I do think what I wrote is says the same as your example but is more precise. I'm off to bed
<SeanTAllen>
With the introduction of partial arthimetic, we no longer need this extra code.
<emilbayes>
see you later
<emilbayes>
:)
<SeanTAllen>
enjoy bed!
<SeanTAllen>
where do you live emilbayes ?
<SeanTAllen>
that it is bed time.
<SeanTAllen>
re: commit comment, that really applies if performance is a reason for doing it
theodus has quit [Quit: Page closed]
<emilbayes>
SeanTAllen: On holiday in Thailand, eating great food, diving and learning pony
<emilbayes>
Well performance was not my primary objective, more that the old check seemed unreasonable with what I know llvm will do on some architectures
<emilbayes>
(ie setting the carry register on overflow)
<emilbayes>
And mostly trying to do a PR against pony itself :)
<SeanTAllen>
Yeah, I think its a good PR without performance as a consideration.
<SeanTAllen>
Something in PR comment like: "suspect this should have no negative impact on performance but not tested" would be reasonable if there is any concern at all (or if you think it should help, noting that but that it wasn't tested")
<SeanTAllen>
and in the end perf isnt really the reason for the change
<SeanTAllen>
this is all just me thinking about what i might want to know if i ended up on this commit while spelnking at some point in the future