<gootik>
Hi Sean, was wondering if there is a release plan somwhere for Pony
docstein has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<SeanTAllen>
what do you mean by a "release plan" gootik ?
dipin has joined #ponylang
<gootik>
Like when is the next version planned to be releaseed, what can be expected to be included, etc.
<SeanTAllen>
Generally we release soon after an issue labelled as "triggers release" is merged. Otherwise, we release around the first of each month as long as it has been more than 30 days since the last release or when someone wants to do a release (which is usually me for Wallaroo Labs related reasons).
<SeanTAllen>
i plan on doing a release once the runtime backpressure work is done AND i can coordinate it with a release we need to do at Wallaroo Labs. Within a couple weeks.
<SeanTAllen>
that would be 0.21.0 as there are breaking changes
<SeanTAllen>
any particular reason for the interest?
docstein has joined #ponylang
<gootik>
Just wanted to know when we can expect a version 1.0.0 "stable" pony version :)
bitcrusher has quit [Ping timeout: 264 seconds]
<SeanTAllen>
When its ready!
<SeanTAllen>
I hope we have the runtime in good moving towards 1.0 shape by end of March next year.
Nat_ has quit [Read error: Connection reset by peer]
<SeanTAllen>
Standard library, I think that will be longer. More contributions on that front would help.
<SeanTAllen>
Ditto for documentation.
<SeanTAllen>
Ditto for tooling.
<SeanTAllen>
Ditto for some possible language features like recursive type definitions.
<SeanTAllen>
Hopefully also simple value dependent types.
aturley has quit [*.net *.split]
catern has quit [*.net *.split]
voldyman has quit [*.net *.split]
lisael has quit [*.net *.split]
voldyman has joined #ponylang
aturley has joined #ponylang
catern has joined #ponylang
lisael has joined #ponylang
voldyman has quit [Max SendQ exceeded]
voldyman has joined #ponylang
voldyman has quit [Changing host]
voldyman has joined #ponylang
nisanharamati has quit [Quit: Connection closed for inactivity]
docstein has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bitcrusher has joined #ponylang
dipin has quit [Quit: dipin]
dipin has joined #ponylang
gootik has quit [Quit: Page closed]
dipin has quit [Client Quit]
gokr has quit [Ping timeout: 248 seconds]
docstein has joined #ponylang
acarrico has quit [Ping timeout: 260 seconds]
docstein has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
endformationage has quit [Quit: WeeChat 1.9.1]
dipin has joined #ponylang
oneness has joined #ponylang
oneness has quit [Ping timeout: 260 seconds]
vaninwagen has joined #ponylang
jemc has quit [Ping timeout: 248 seconds]
vaninwagen has quit [Ping timeout: 248 seconds]
codec1 has joined #ponylang
<codec1>
Hi
<codec1>
What is the idiomatic way to write pony code that return information for functions that can fail
<codec1>
For example let's say that I am writting a function that read a file and return it in totaly as a Array[U8] and that somehow manage to detect what problem can arise (invalid path, security issue, directory not found, file not found, etc..)
<codec1>
What will be the signature of this function?
<doublec>
codec1: a union of an error type and the result maybe
<codec1>
are there any example in the standard library?
<doublec>
codec1: see the apply method in the File class of the file package
gokr has joined #ponylang
<codec1>
thanks
<codec1>
by the way doublec, aren't you the person that did some SDL2 project with Pony?
<bitcrusher>
im going to try to use sdl2 for a roguelike with pony...
<bitcrusher>
acolyte doesn't compile anymore
<bitcrusher>
uses pony 14
<bitcrusher>
also ncurse
<codec1>
acutally I managed to compile acolyte fairly easily
<codec1>
Since I was on Windows I had to moc ncurse but expect that it was quite easy
<codec1>
Of course I didn't test it
<codec1>
But if you are on Linux I guess it should be pretty easy to have something running using acolyte
bitcrusher has quit [Disconnected by services]
<doublec>
codec1: yes, that was me
<doublec>
codec1: I did it as a quick example for someone who wanted to use SDL2
samuell has joined #ponylang
codec1 has quit [Quit: Leaving.]
<SeanTAllen>
bitcrusher: i'm sure jtfmumm would appreciate a PR to get acolyte compiling again.
<SeanTAllen>
or a note that it is no long compiling in the way of an issue.
codec1 has joined #ponylang
<codec1>
doublec: If you have some time I would be interested to ask you a few questions
<codec1>
doublec: I used your code at a base to get me started but I ran into weird issues
<codec1>
doublec: among other things, I have a different behavior between release and debug, and I managed to somehow totally freeze my computer (which needed hard reboot)
<codec1>
doublec: So if you are interested in helping me, let me know how you would like to exchange information (maybe using something different since irc isn't probably the most suited tool for this)
codec1 has quit [Read error: Connection reset by peer]
codec1 has joined #ponylang
<jtfmumm>
I updated acolyte so it compiles with 0.20.0
<jtfmumm>
I experimented with using SDL2 with the game about a month ago, but ran into too many problems because of SDL2s assumptions about which thread it's running on
<jtfmumm>
I experimented with using SDL2 with the game about a month ago, but ran into too many problems because of SDL2's assumptions about which thread it's running on
acarrico has joined #ponylang
gokr has quit [Ping timeout: 240 seconds]
<codec1>
jtfmumm: Did you identify the problem? I think I run into the same thing
<codec1>
Plus I don't think this kind of problem only happen with SDL2. So if someday we want to write GUI app with Pony it may worth identifying the problems and see what solutions we can find
<SeanTAllen>
codec1: note that there is a DirectX library that works and that there was a blog post when someone did GUI programming so "we want to write a GUI app" is too broad of a brush. problems someone might have with SDL2 doesn't apply to all things GUI.
jemc has joined #ponylang
jemc has quit [Ping timeout: 255 seconds]
jemc has joined #ponylang
<codec1>
sure
<codec1>
But is a rock solid library
<codec1>
so it is not unlikely that the kind of problem that happen with SDL2 won't happen with any other lib
gokr has joined #ponylang
_whitelogger has joined #ponylang
<SeanTAllen>
i dont think that is a reasonable assumption to make codec1
<codec1>
why?
<SeanTAllen>
because you are taking something about an implementation of one library and applying it across the entire category
<codec1>
tbh it's work both way
<codec1>
you can't say for sure that any other lib won't be coded differently than SDL and just work fine
<codec1>
unless you have identified what cause problem with SDL2
<SeanTAllen>
im not going to argue this with you
<SeanTAllen>
you went with "its not unlikely"
<SeanTAllen>
i dont think that is a reasonable assumption to make
<codec1>
I didn't say it is likely
<codec1>
I just mean it can happen with other libs too
<codec1>
to which degree I don't know (and i didn't say)
<SeanTAllen>
you said "not unlikely"
<SeanTAllen>
that to me is a bold statement
<SeanTAllen>
specifically not unlikely that other GUI libraries will have the same issue
<codec1>
I said any lib
<SeanTAllen>
"Plus I don't think this kind of problem only happen with SDL2. So if someday we want to write GUI app with Pony it may worth identifying the problems and see what solutions we can find"
<SeanTAllen>
you said "we want to write a GUI app"
<codec1>
which mean for me (I am no native speaker ) it would probably happen with at least one other
<SeanTAllen>
people have already written GUI apps
<aturley>
codec1: the issue, if i recall correctly, is that SDL2 requires that you always interact with the library from a specific thread.
<SeanTAllen>
aturley: that is what folks have said
<aturley>
pony currently does not allow you to guarantee that calls will always happen from the same thread.
<codec1>
aturley: thanks
<aturley>
other libraries have this requirement.
<SeanTAllen>
unless you do ponythreads=1
<aturley>
SeanTAllen: right.
<SeanTAllen>
saying that libraries that require you to always call them from a specific thread are going to be difficult. that is a statement i can get behind.
<aturley>
right.
<codec1>
is that behavior unlikely for libraries?
<codec1>
I mean requirement
<aturley>
i've run into other libraries that require things like that.
<codec1>
right, that was I fear
<aturley>
i'm sorry to jump in, i wanted to point out that the issue itself is understood.
<codec1>
you are totally welcome
<codec1>
that the kind of stuff I searched for quite a bit actually
<SeanTAllen>
there are also libraries that use globals
<SeanTAllen>
which would be problematic
<SeanTAllen>
can fix every issue
<SeanTAllen>
cant
<aturley>
we do not talk about such things in polite company.
<codec1>
polite company?
<SeanTAllen>
its a joke he is making codec1
<aturley>
codec1: sorry, that was a joke
<SeanTAllen>
its an english phrase that basically means
<aturley>
sean and i have had many angry conversations about globals.
<codec1>
ah ok
<codec1>
sorry about my english
<SeanTAllen>
"globals are an awful thing, lets not discuss it amongst pleasant people"
<SeanTAllen>
its ok codec1
<aturley>
codec1: no problem
<codec1>
I am french and as almost all french I speak english quite badlhy
<aturley>
you seem to be doing quite well.
<aturley>
better than i would do in french :)
<SeanTAllen>
i have a habit of using lots of collequialisms which can be hard for non native speakers
<codec1>
you have seen me written french yet :)
<SeanTAllen>
yes, your french is MUCH better than my french
<codec1>
*haven't
<SeanTAllen>
err
<SeanTAllen>
your english
<codec1>
thanks, back to the subject
<codec1>
do you know what SDL2 do behind the curtain for not working properly when called in another thread ?
<SeanTAllen>
SLD2 specifically says "the main thread" but when jemc looked, i believe he saw it was specifically "the same thread"
<SeanTAllen>
which is a little different
<SeanTAllen>
if i remember correctly, it was using thread locals
<SeanTAllen>
but dont trust my memory
<codec1>
you mean locals, like local variables on the stack ?
<jemc>
I think I looked at this and just saw that it was using globals, which is actually a lot easier to deal with than "same thread" but then I think someone else found it was something worse, like thread locals
<jemc>
let me take a look through the IRC history
<jemc>
codec1: "thread locals" are different from "locals" - they are stored *in the thread* rather than on the stack
<SeanTAllen>
So if you had a variable Foo codec1, each thread would have its own copy of the variable
<SeanTAllen>
Pony uses thread locals for variables that are specific to a given scheduler thread.
<jemc>
okay, the author of that project and I are both on Linux, and we're both able to run that project with no problems
<jemc>
but there may be something a little more sneaky on Windows or OSX
<codec1>
I think that is the solution that works great on Windows too
<codec1>
To avoid blocking the garbage collection at first I tried running each iteration of the loop using timer
<codec1>
and the result was not pretty
<SeanTAllen>
jtfmumm: is on OSX so that could explain his issues as well perhaps
<jemc>
I'd be curious to know if jtfmumm or someone else on OSX could run that Stars repo successfully
codec2 has joined #ponylang
<jemc>
I think SDL is only using static "globals", so there's no reason to have a "main thread" or "same thread" restriction - you just need to keep your SDL-using stuff in a single actor or in an `iso` object, and never create more than one instance of it - then you'll never have access to the globals from more than one actor at once
<jemc>
but it could be that the platform-specific libraries on OSX or Windows that SDL is *wrapping* have more troublesome restrictions, which I think is what jtfmumm was hypothesizing
<jemc>
(last time we spoke about it in the chat history I looked up)
<codec2>
I just re run my sample
<codec2>
and in debug I cannot get the quit even for some reason
<SeanTAllen>
can you run Stars though codec2 ?
<codec2>
on Windows it will take some time
<codec2>
as the makefile cannot compile in its current form
<jemc>
yeah, there was some unix-specific stuff in there