Guest75513 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
acarrico has quit [Ping timeout: 255 seconds]
jemc has quit [Ping timeout: 248 seconds]
acarrico has joined #ponylang
jemc has joined #ponylang
Nat has joined #ponylang
Nat is now known as Guest97999
Guest97999 has quit [Client Quit]
nisanharamati has quit [Quit: Connection closed for inactivity]
docstein has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Nat has joined #ponylang
Nat is now known as Guest14200
chamar has quit [Read error: Connection reset by peer]
dipin has joined #ponylang
Guest14200 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
endformationage has quit [Quit: WeeChat 1.9.1]
jemc has quit [Ping timeout: 250 seconds]
dipin has quit [Quit: dipin]
Robdor has quit [Ping timeout: 268 seconds]
Robdor has joined #ponylang
samuell has joined #ponylang
gokr has joined #ponylang
codec1 has joined #ponylang
vaninwagen has joined #ponylang
SirRolin has joined #ponylang
<SirRolin>
thanks for the help @seanTAllen, I figured out if I used the Timer only as a delayer that called a function to reconnect, which would call the timer again if it failed, was the way to go ^^
<codec1>
Hi,
<codec1>
I just wanted to know, is there any reason why the pony compiler compile by default pony programs in release instead of debug beside because one of the 2 had to be the default one?
<SeanTAllen>
codec1: why would you default to debug? that seems odd and wrong to be as the default.
<codec1>
to enable more options to catch issues in debug mode
<codec1>
like integer overflow/underflow division by 0, overflow/underflow on type casting and such
<codec1>
Moreover I don't what is the current workflow for most Pony programmers but I tend to compile my code more often in debug than release (and not just in Pony btw)
<wig>
all compilers i know of, debugging symbols are by default off
<codec1>
not in Rust
<SeanTAllen>
so all compilers but Rust
<codec1>
They went for a debug with more checks than it Release as a default
<codec1>
I am not sure that is valid argument to count the number of compiler deciding to go as release as default
<codec1>
most mainstream languages (especially the "old" ones) don't have null safety
<codec1>
that doesn't mean it is great that way
<SeanTAllen>
you also rambled off issues that compiling a program with debug symbols isnt going to catch
<SeanTAllen>
i dont really understand how that relates to what is the default
<codec1>
in the current state
<wig>
its six in one hand half a dozen on the other in any case
<codec1>
but hopefully that can change
<codec1>
sorry?
<SeanTAllen>
its an intentional decision. you can try to convince folks but i doubt you are going to succeed given that you can do --debug
<wig>
looks to be a contentious issue in rust community as well
<SeanTAllen>
so are you also saying you think that when you install `ponyc` via a package manager that you should get a version of the runtime with debug symbols?
<codec1>
no
<codec1>
I am not talking about the compiler
<SeanTAllen>
i didnt say compiler codec1
<SeanTAllen>
i said "runtime"
<wig>
thats the main argument the rust folks have against it, dependencies by default with debug symbols slows general case down
<codec1>
yes but the problem is not that simple
<wig>
what problem?
<SeanTAllen>
you can do --debug codec1. that doesn't seem like a high bar.
<codec1>
it indeed make sense to have dependecies as release but I would argue that most compilation on the user code would be in debug
<SeanTAllen>
that to me makes no sense
<SeanTAllen>
if there is value in the user code being debug as a default
<SeanTAllen>
then the dependencies should be as well
<SeanTAllen>
if its only my code that is debug then i can easily turn it on with a flag.
<SeanTAllen>
if anything part debug, part not, strikes me as very odd.
<codec1>
why do you find it odd?
<wig>
its bikeshedding in anycase
<SeanTAllen>
if there is value in running with debug in order to find possible errors then it seems to me that applies to my entire program which in the case of pony includes the runtime.
<SeanTAllen>
if its only **my code** that gets compiled as debug, there's a simple easy flag for that
<SeanTAllen>
so
<codec1>
well speaking of probabilities there usually less chance that there is a bug in an extrenal dependencies than in the code someone is developping right now
<SeanTAllen>
with how Pony works
<SeanTAllen>
That's quite a statement that I think demands numbers to back up
<SeanTAllen>
Also
<SeanTAllen>
this is very handwave with talk of "bugs"
<SeanTAllen>
What bugs exactly
<SeanTAllen>
you mentioned some earlier, like divide by zero
<wig>
debugging is also already an opt in behavior, the debug symbols arent used unless you are using a debugger so you already changes your workflow
<codec1>
yeah basically I can think of only arithmetic stuff
<SeanTAllen>
well, Pony doesn't catch divide by zero in either debug or non-debug
<codec1>
neither oveflow/underflow right ?
<SeanTAllen>
correct
<codec1>
that is my point catching these (by default) would be a great thing
<wig>
how would debug symbols ever help for that case?
<codec1>
these kind of errors are probalby not happening very often
<codec1>
well they have a runtime cost
<codec1>
and you probably don't want that in a relase
<SeanTAllen>
codec1 and they are as likely to happen in many programs at runtime in production as elsewhere because they can be triggered by user input
<SeanTAllen>
if you want checks for that, you need to have it on in "production"
<codec1>
for release sure
<codec1>
but for debug it make sense to enable them I think
<SeanTAllen>
im not sure what you think "debug" does
<SeanTAllen>
so you asked a question about what Pony does and why
<SeanTAllen>
but you seem to have expanded the idea of "debug" to a class of issues that Pony does not try to catch.
<codec1>
today yes, that is what I wanted what you think of it and if it something pony may consider changing
<SeanTAllen>
if you want to open an RFC with ideas for classes of bugs that programmer could introduce and how those could be caught with opt-in checks, that is awesome
<SeanTAllen>
but that is not compile with debug
<SeanTAllen>
if i want to check for divide by zero
<SeanTAllen>
i would do that in my code by checking if i was dividing by zero
<codec1>
yes but you would end up adding check everywhere
<SeanTAllen>
if i want to pay the cost of checking underflow and overflow, i could do that as well
<codec1>
it makes sense to do it when you know it is probable than it happen
<SeanTAllen>
sorry, you dont know that i will end up adding checks everywhere
<codec1>
but sometime someone can think "it won't happen there" so no need to check here
<SeanTAllen>
we have not discussed any actual solutions so its not reasonable to say that
<SeanTAllen>
if you have concrete, implementable ideas that can be discussed, open an RFC
<SeanTAllen>
otherwise its a lot of handwaving
<SeanTAllen>
saying things like "you with end up adding checks everywhere" isnt true
<SeanTAllen>
because there's no specific implementation being discussed
<SeanTAllen>
there's no magic here
<codec1>
I don't understand
<SeanTAllen>
i dont know how to make you understand
<SeanTAllen>
you are making statements that have no basis
<codec1>
I mean about the check
<SeanTAllen>
"i will need to have checks everywhere"
<SeanTAllen>
that's not true
<SeanTAllen>
its not false either
<codec1>
well if the runtime doesn't do it
<codec1>
you have to put check in the code right ?
<SeanTAllen>
this is a pointless conversation codec1
<SeanTAllen>
this becomes a meaningful conversation if there's an idea for an implementation to discuss
<SeanTAllen>
that is why the RFC process exists
<codec1>
but I don't know enough to open an RFC
<SeanTAllen>
then im not sure what you want?
<SeanTAllen>
you want to say "pony should do X"
<SeanTAllen>
and someone else should come up with the idea for how?
<codec1>
I mean if I just open an RFC to say "it would be great to find a way to catch numeric issue such as division by zero/underflow/overflow" and nothing more. Is it okay to that?
<SeanTAllen>
no
<SeanTAllen>
thats not ok
<SeanTAllen>
you can open an issue on the RFC repo and say "i think this would be cool"
<SeanTAllen>
and then someone maybe someday might decide
<SeanTAllen>
"i think that is cool and i have an idea how to do it"
<SeanTAllen>
but pony is a volunteer project
<SeanTAllen>
no one is going to put down the work they think is important to solve that problem simply because someone else thinks its important
<SeanTAllen>
btw, if its "catch divide by zero" or something of that ilk
<codec1>
ilk ?
<SeanTAllen>
i think there is little value to that if it isnt always on
<SeanTAllen>
ilk: a type of people or things similar to those already referred to
<SeanTAllen>
im not trying to discourage you codec1, but there needs to be something concrete to discuss
<SeanTAllen>
otherwise you end up with statements like "there will be checks everywhere"
<SeanTAllen>
which is pretty meaningless because you've assumed an implementation but there's no implementation actually being discussed
<codec1>
I think you misunsterdood what I mean by that
<SeanTAllen>
maybe
<SeanTAllen>
also
<SeanTAllen>
if you want to open up a discussion like this
<SeanTAllen>
i would suggest addressing each thing
<SeanTAllen>
like "how can we check integer overflow/underflow"?
<SeanTAllen>
"how can we catch divide by zero"?
<SeanTAllen>
and discuss specific implementations with specific tradeoffs
<codec1>
but this isn't the place to do that in a RFC isn't it ?
<SeanTAllen>
RFCs have specific implementations
<SeanTAllen>
you can open an issue on the RFC repo and say "i would like someone to write an RFC for this"
<codec1>
That is where I get lost
<SeanTAllen>
which is basically saying "i dont know how to do this but i think it would be cool, maybe someone else will think its cool and come up with an idea"
<codec1>
If I got no idea how to solve it, it is still OK to open an RFC about something I feel is a "paint point" ?
<SeanTAllen>
basically "i think existing case methods are bad in how they currently work, i think we should remove them but i don't have a good specific implementation for pros and cons"
<SeanTAllen>
no
<SeanTAllen>
you can not open an RFC
<SeanTAllen>
you can open an issue with a description of what you want solved and then someone else might write the RFC
<codec1>
ah right
<SeanTAllen>
**might** being the operative term
<codec1>
I think issue on the RFC where meant to be tied to RFC
<codec1>
* I thougt
<SeanTAllen>
i need to leave for a dr appointment
<SeanTAllen>
sorry got to run
<codec1>
np problem
<codec1>
thanks for the answer once again
vaninwagen has quit [Ping timeout: 255 seconds]
codec1 has quit [Quit: Leaving.]
SirRolin has joined #ponylang
gokr has quit [Ping timeout: 240 seconds]
SirRolin has quit [Ping timeout: 260 seconds]
jemc has joined #ponylang
gokr has joined #ponylang
gokr has quit [Ping timeout: 240 seconds]
ShalokShalom has joined #ponylang
endformationage has joined #ponylang
codec1 has joined #ponylang
user10032 has joined #ponylang
aturley has joined #ponylang
nisanharamati has joined #ponylang
jemc has quit [Ping timeout: 255 seconds]
xllndr has joined #ponylang
jemc has joined #ponylang
vaninwagen has joined #ponylang
markmarkmark has quit [Ping timeout: 260 seconds]
acarrico has quit [Ping timeout: 255 seconds]
markmarkmark has joined #ponylang
acarrico has joined #ponylang
ShalokShalom has quit [Remote host closed the connection]
<SeanTAllen>
you're welcome codec1
xllndr has quit [Quit: Leaving]
<endformationage>
jemc: Nice presentation! I thought the recap overview was quite clear.
<vaninwagen>
hi, is there some kind of "automatic" consume for the last expression in a function?