aceluck has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amclain has quit [Quit: Leaving]
_whitelogger has joined #ponylang
aceluck has joined #ponylang
jemc has quit [Ping timeout: 240 seconds]
Matthias247 has joined #ponylang
vaninwagen has joined #ponylang
aceluck has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vaninwagen_ has joined #ponylang
aceluck has joined #ponylang
vaninwagen has quit [Ping timeout: 260 seconds]
vaninwagen_ has quit [Ping timeout: 260 seconds]
aceluck has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vaninwagen_ has joined #ponylang
vaninwagen_ has quit [Ping timeout: 260 seconds]
_andre has joined #ponylang
dougmacdoug has joined #ponylang
jemc has joined #ponylang
dougmacdoug has quit [Ping timeout: 246 seconds]
jemc has quit [Quit: WeeChat 1.4]
jemc has joined #ponylang
<ada[m]>
Morning ponyland. Having trouble understanding what adding refcap notation to a constructor means. Doesn't seem to be explained in the tutorial, but doing so is necessary to get some of my code to compile...
endformationage has joined #ponylang
<SeanTAllen>
new val create() would default to 'val' for any object created with that constructor
<ada[m]>
I thought that's what e.g. `class val Foo` did?
<SeanTAllen>
thats on a class
<SeanTAllen>
so class val Foo
<SeanTAllen>
means when you say
<SeanTAllen>
let x: Foo
<SeanTAllen>
it is
<SeanTAllen>
let x: Foo val
<SeanTAllen>
class iso Foo
<SeanTAllen>
would make
<SeanTAllen>
let x: Foo
<SeanTAllen>
be equiv to
<SeanTAllen>
let x: Foo iso
<ada[m]>
So having e.g. `class val Foo` with only one constructor `new ref create()` would be silly and pointless, right? Just checking my understanding.
<jemc>
ada[m]: not necessarily pointless - in fact I could think of some cases where that might be the only way you can make it work
<jemc>
a `ref` constructor can be lifted to `val` if you put it inside a `recover` statement
<jemc>
a `recover` statement only allows sendable references to pass into it and be used
<jemc>
a `val` constructor only allows sendable arguments to pass into it and be used
<jemc>
there's a subtle difference there that you could create non-sendable things inside the recover block and pass them to the `new ref` constructor as arguments, that you wouldn't be able to pass to a `new val` constructor
<jemc>
still, that situation would be quite rare
<jemc>
at any rate, if the receiver cap of a constructor is not documented in the tutorial, that's an oversight - would you mind filing a ticket about it?
<ada[m]>
I'd forgotten about recover. Think I understand now. Thanks for the help!
<ada[m]>
of course. Maybe I'll even PR with my newfound knowledge if I get a minute.
<SeanTAllen>
ada[m]: awesome!
Matthias247 has quit [Read error: Connection reset by peer]
amclain has joined #ponylang
tschuxxi has joined #ponylang
<tschuxxi>
hey, I'm new to pony lang and I wanted to give it a try. I'm running FreeBSD and wanted to compile the ponyc but alway run into the following error. Is this problem already known? src/libponyrt/platform/threads.c:(.text+0xd): undefined reference to `pthread_create'
felixgallo has joined #ponylang
<jemc>
tschuxxi: welcome!
<jemc>
no, that's not a known problem, and freebsd is one of the platforms we aim to maintain support for on a best effort basis
<jemc>
tschuxxi: looks like this we have special logic in the Makefile for FreeBSD to add `libpthread`, so maybe that's not getting triggered?
<felixgallo>
on line 32, I am in the apply() of a TimerNotify, which is part of an iso structure of a Timer that has been handed to a Timers actor, which is started by a Waiter actor.
<SeanTAllen>
tschuxxi: sounds like new versions of FreeBSD require a different dependency for pthreads than what previously was required. I'm not a FreeBSD user so if you can identify a fix (or we can help) that would be great. Also as jemc said, if you can file an issue that would be great.
<felixgallo>
I want to be able to return false if the Waiter actor says so, or true otherwise, but can't figure out in my head how to access a value from the Waiter actor.
<SeanTAllen>
felixgallo: you aren't going to be able to do that, for reasons i'm happy to go over. im putting a playground together for what you can do
<nadirs>
I'm on Archlinux (Linux arch 4.11.9-1-ARCH x86_64 GNU/Linux)
<SeanTAllen>
you shouldnt be getting: Warning: environment variable $CC undefined, using cc as the linker
<nadirs>
SeanTAllen: I also tried "CC=gcc ponyc" and "CC=gcc ponyc --pic", without success
<SeanTAllen>
so...
<nadirs>
I'm sorry, I think I misunderstood your sentence
<SeanTAllen>
i think i musundertood your problem
<SeanTAllen>
hold on
<SeanTAllen>
which gcc are you using nadirs?
<nadirs>
SeanTAllen: gcc (GCC) 7.1.1 20170630
<SeanTAllen>
nadirs: we aren't supporting gcc 7 yet (unless something changed and i didnt notice). work needs to be done for that. can you try gcc 6.
<nadirs>
SeanTAllen: I am sorry I missed that, thank you for taking the time to help :)
<SeanTAllen>
has gcc 7 been officially released?
<nadirs>
I'll try with gcc 6
<SeanTAllen>
look like it has
<nadirs>
I don't know, it's in the core repository
<SeanTAllen>
i missed that
<SeanTAllen>
ugh we need to update docs for that until we are supporting it
<SeanTAllen>
so really the 2nd one is useless, and you need to go with the first
<felixgallo>
hmmm
<felixgallo>
reading
<jemc>
felixgallo: the bottom line is that you can't access an actor's state (fields) from outside the actor synchronously
<SeanTAllen>
and you cant hold a non-tag reference to WaiterNotify because Timer needs an iso to it
<felixgallo>
yeah, that was the hangup. I kept wanting Timer.apply() : Bool to return true/false appropriately, but there's really no way it can in most scenarios because the iso structure can't reach outside
<felixgallo>
so Timer.apply()'s return value is limited only to the information inside the iso at the time of the iso
<jemc>
yeah, I think the async cancel call is the best you can do
<jemc>
(SeanTAllen's first playground link)
<felixgallo>
the fact that it exists kept me frustratedly thinking it was there for a reason but it probably isn't
<felixgallo>
thanks for the help @seantallen and @jemc
<jemc>
felixgallo: I think it's primarily useful in relation to the `count` parameter
<SeanTAllen>
Sylvan's async-lambda idea would be nice here. But that doesn't exist at this time.
<felixgallo>
I'm trying to reconcile the amount of extra typing and the compiler annoyance against the number of times I've ever failed to remember a function was partial and forced decoration would have helped me
<felixgallo>
so far not seeing it, but I'm sure people have way bigger pony codebases than I do
<felixgallo>
seems like something more for a -w flag or 'use strict' than a compiler error but I need to think about it some more perhaps
<SeanTAllen>
there's an RFC process, we announce everything that comes through. it was approved by everyone interested and involved.
<SeanTAllen>
everyone who participated in the RFC said they would find it very helpful in their codebase.
<SeanTAllen>
everything in a programming language is "opinionated", i believe you are using it to mean "one i dont agree with".
<SeanTAllen>
is that a reasonable reading on my part?
<felixgallo>
grant me a little more nuance and less ill will :)
<SeanTAllen>
no ill will
<SeanTAllen>
that's how im reading it
<SeanTAllen>
i could be very wrong
<SeanTAllen>
thats my interpretation of what you said
<SeanTAllen>
can you clarify where i am wrong?
<jemc>
felixgallo: one of the reasons for this change is that we've heard a lot of people complain about not being able to understand/trace the control flow of a `try` block
<felixgallo>
it's a surprising and novel addition, and at first glance I can't figure out why. I haven't formed a strong enough opinion on it yet to say whether or not I agree with it
<felixgallo>
I do understand it's supported by the RFC commenters so I'll go try to understand from them what the reasoning is
<jemc>
usually what those people ask for has been the ability to read a backtrace out of the error object, which is something that we don't want to support for various other reasons
<jemc>
but requiring a `?` to mark function calls where the control flow can jump to the `else` block is another solution to the problem of debugging error paths
<jemc>
for the reader it provides a clear indication of everywhere a control flow jump can happen
<jemc>
for the writer it provides a constant reminder of all the control flow paths they have to be concerned with, to be sure their error handling has the proper semantics
<felixgallo>
ok, I have read all the RFCs and listened to the explanation, and have now formed the start of an opinion. I agree that exceptions screw up try blocks, but I (a) disagree that the writer gets enough info from just scattered ? symbols at call sites, and (b) think there has to be some less heavyweight solution
<felixgallo>
maybe I don't understand the problem with stack traces
<jemc>
regarding (a) - what information is the code writer missing, and how do you suggest we support them getting it?
<felixgallo>
the case I'm thinking about is the case where the coder is thinking, 'I now want to refactor/redesign X, where are all of the places that X is called such that making the function partial-or-not will cause problems'
<SeanTAllen>
my requiring ? on methods that throw errors, it allows me to look at a local block of code and know which methods might change the control flow. that to me is a big win.
<felixgallo>
the thought process is 'for all X', not 'for all X that I witness in my editor', which is what you get with ? marks
<felixgallo>
I agree it has that benefit Sean
<jemc>
> where are all of the places that X is called such that making the function partial-or-not will cause problems
<jemc>
this is actually directly addressed by this RFC
<jemc>
you can get that info by changing the method signature to include the `?`
<jemc>
then the compiler will give you a list of all the places where it's being used
<jemc>
(because they will now be errors)
<felixgallo>
yeah, I guess you could do that.
<felixgallo>
I still wonder if that's a lot more question marks than are needed.
<SeanTAllen>
as someone who works in what might be the largest pony code base, i'm very happy this is arriving, even if it is going to be a pain in the ass when we upgrade, then again we are still on 0.9.x until sometime in october or november so... ¯\_(ツ)_/¯
<felixgallo>
as someone who works in what is absolutely the smallest pony code base, I'm sympathetic
<SeanTAllen>
i bet there is smaller.
<SeanTAllen>
unless you want to be the smallest in which case i take that back
<SeanTAllen>
;)
<jemc>
> a lot more question marks than are needed
<jemc>
I'm not sure what you mean by that - can you elaborate?
Matthias247 has joined #ponylang
Lleutch has joined #ponylang
Lleutch has quit [Client Quit]
endformationage has quit [Quit: WeeChat 1.7]
<SeanTAllen>
jemc: i just manually updated pony-playground, i think that is the final 0.16.0 release task
<SeanTAllen>
it didnt update on its own ¯\_(ツ)_/¯
<SeanTAllen>
good thing paul gave us access
<jemc>
great, thanks
<SeanTAllen>
and "last week in pony" is updated so hopefully nothing happens tonight or tomorrow to deserve being included
_andre has quit [Quit: leaving]
<jemc>
I'll take that as a challenge to hurry up and finish lambda/array inference then :D
<jemc>
I can't tell you how excited I am for that one
<cquinn>
I'm excited for that one
<SeanTAllen>
lol
<SeanTAllen>
ok
<SeanTAllen>
cquinn: is the CLI in a place where we should deprecate Options yet? or do you want to hold off?
<cquinn>
I think it is now a super-set. Adding in the string_seq allows people to grab the command line tail as the trailing args.
<SeanTAllen>
CLI is a superset?
<SeanTAllen>
so is that a "yes, we can announce it is being deprecated" and then remove for next release?
<felixgallo>
@jemc - re: more question marks than needed -- I feel like the problem (hard to infer vs. partials) is important, i just don't know it's question-marks-on-method-and-at-the-call-site-and-compiler-errors-always important
<felixgallo>
having a hard time qualifying that and clearly I need to come up with a better idea to have a meaningful discussion
<jemc>
for whatever it's worth, among the pony core team I'm probably the most sensitive to concerns about succinctness in syntax, but I see the burden as being very light compared to the benefits
<jemc>
that is, I think it solves a major pain point from pony in a way that doesn't have any runtime costs, and improves readability
<felixgallo>
I wonder if optionality would make it feel better. So if you included ?s for readability and safety reasons, you could get your compiler errors
<SeanTAllen>
that makes it meaningless from a reading standpoint
<jemc>
but the main motivating use case for this RFC was guarding against the problem of unknowingly introducing a new control flow path when you refactor some method to be partial (action at a distance)
<SeanTAllen>
now i have to know what sort of codebase i'm in
<jemc>
if leaving out the `?` means no errors, it means that the compiler can't issue an error in that motivating use case
<SeanTAllen>
so felixgallo thing i love
<SeanTAllen>
now if i have 3 statements in a try
<SeanTAllen>
and the else only deals with 1 of the statements (only 1 to throw an error)
<SeanTAllen>
and one of the other 2 is changed to throwing errors, then i get an error
<SeanTAllen>
because i need to update
<SeanTAllen>
and now i can make my else handle this case
<jemc>
yeah, exactly
<felixgallo>
I get it. Definitely does make sense
<SeanTAllen>
this to me is very much in line with the pony philosophy point: "Aim to reduce common programming bugs through the use of restrictive syntax."
<felixgallo>
on the other hand, we have 'try env.out.print(env.args(0)?) end
<felixgallo>
'
<SeanTAllen>
thats true
<SeanTAllen>
life is tradeoffs
<jemc>
because Pony has no state or information carried in the error, it's critical to sane Pony programs / best practices that errors are handled close to the source of raising, and that the `else` clause is written with the specific kind(s) of errors that could be raised there in mind
<felixgallo>
and there are many cases where people will have accidental partials. I'm just yet unconvinced (although, please don't take this as an assertion that I _need_ to be convinced) that the tradeoff is the right side of grey
<felixgallo>
I expect I will be typing blah(foo) a lot, and then cursing when the compiler tells me I really meant blah(foo)?
<felixgallo>
I suspect I will be doing 10x as much cursing and typing on that as I will trying to deal with refactoring partials in a try, but again, I am the world record smallest pony codebase champion
<jemc>
come on, it can't be more cursing than with reference capabilities :D
<felixgallo>
true
<felixgallo>
which, I am proud to say, I briefly understood in their totality from 3:14 to 3:18 today, July 28
<SeanTAllen>
god bless them rcaps, they have stopped me from introducing several subtle bugs!
<felixgallo>
4 complete and uninterrupted minutes of understanding them, and then I tried to use generics at the same time
<SeanTAllen>
felixgallo: not sure if that is a joke or not but if you ever want to do a zoom sometime to pair and work on rcaps and generics, i can make myself available
<felixgallo>
now I am back to square(0), or should I say square(0)? ...
<felixgallo>
@SeanTAllen having bounced harmlessly off pony about 5 times by now I may take you up on your generous offer at some point
<SeanTAllen>
although sometimes i struggle to get my generics working correctly rcap wise. so be forewarned, it might involve me cursing some.
<jemc>
SeanTAllen: if there's anything I've learned in the past few years it's that limitations => freedoms, and cursing => blessings :D
<SeanTAllen>
limitations lead to freedoms, cursing leads to blessings ?
<SeanTAllen>
am i reading that => correctly?
<felixgallo>
I think my problem is I come from erlang and functional languages, where the true freedom comes from the fact that everything is always val :D
<jemc>
yeah, I was slow in typing it, but referencing your "god bless them rcaps" comment
<jemc>
felixgallo: that's a pattern you can do in pony if you like
<felixgallo>
not if you want to call a method on an actor
<SeanTAllen>
?
<jemc>
jtfmumm__ is fond of the everything-is-a-val paradigm I think, and he has a very impressive pony codebase: https://github.com/jtfmumm/acolyte
Matthias247 has quit [Read error: Connection reset by peer]
<SeanTAllen>
the work codebase is more impressive
<SeanTAllen>
but we use mutable references all over the place in it
<jemc>
I imagine so - I'd love to see it when you guys release it :D
<SeanTAllen>
mid september i think
<SeanTAllen>
then everyone can he horrified by the tradeoffs we made and shortcuts we took
<felixgallo>
having multiple large professionally written pony codebases is going to be pretty helpful
<SeanTAllen>
we should also be releasing a kafka pony client around then too
<jemc>
ah, great - I thought I was going to have to write one
<SeanTAllen>
dipin has a good chunk of one done
<jemc>
thanks for mentioning it before I actually went down that path
<SeanTAllen>
he's working on error handling like leader changes now
<jemc>
pure Pony, or FFI using librdkafka?
felixgallo has quit [Quit: Page closed]
<SeanTAllen>
pure pony
<SeanTAllen>
librdkafka we looked at but we were worried about performance impact on us of it starting its own threadpool
<jemc>
I hate FFI on libraries that have their own threads
<SeanTAllen>
me too
<SeanTAllen>
i have from before pony
<jemc>
me too (in Ruby)
<SeanTAllen>
ok
<SeanTAllen>
i am off to take a end of work day walk
* jemc
waves
<jemc>
thanks for doing the release! you freed up my night's pony time for lambda inference
<doublec>
I should probably revisit my old blog posts and update for the partial syntax and less-recent lambda syntax changes.
<doublec>
One thing I disliked about learning Rust was all the old blogs with outdated Rust version examples
<jemc>
thank you!
<jemc>
I am a little bit worried about that in general, so I really appreciate you taking the time to update
<jemc>
(because your blog posts have been frequently cited)
<doublec>
thanks, I think it's worthwhile. It makes it less of a pain point for new users.
nadirs has quit [Remote host closed the connection]