<doublec>
yonkeltron: If you don't know which actor you want you probably don't know what to do with it...
<yonkeltron>
i am learning pony and taking a crack at a CSV parser
<yonkeltron>
i want to be able to specify an actor which will be a CsvLineHandler of some sort
<yonkeltron>
so i need to be able to write one and then pass it around...
<yonkeltron>
and have one for each line
<yonkeltron>
i feel like i'm not making sense
<doublec>
yonkeltron: let me write some pseudo code foryou
<yonkeltron>
well what i'm trying to say is that you can pass around a class and instantiate it whenever, wherever. so can you do the same with an actor?
<doublec>
yonkeltron: yes
<doublec>
yonkeltron: an actor is pretty much exactly like a class
<doublec>
yonkeltron: except it has asynchronous methods
<yonkeltron>
is there an Actor type?
<yonkeltron>
is there a Class type?
<doublec>
yonkeltron: and the handle is a tag so that it can passed around
<doublec>
Instead of handler.create().line(line), do "handler.line(line)"
<doublec>
The method already has an instantiated actor passed in
<yonkeltron>
does it have to?
<yonkeltron>
i wanted n actors for n lines
<doublec>
Why is Line an Array[String] and not just String?
<yonkeltron>
because at some point i need to do line.split(",")
<yonkeltron>
sorry
<yonkeltron>
this is pseudocode
copy` has quit [Quit: Connection closed for inactivity]
<doublec>
yonkeltron: you would need to pass in some form of factory class/actor if you want to create N actors of a type that is defined by the caller
<yonkeltron>
ah
<yonkeltron>
ok
<yonkeltron>
that makes sense
<yonkeltron>
could i trouble you for an example of what that might look like?
<TwoNotes>
If you compile with --debug, then run it under gdb, you can see where it failed.
<Jbbouille>
okay
<TwoNotes>
The backtrace (bt) will be most helpful
jemc has joined #ponylang
<SeanTAllen>
Jbbouille: what ponyc commit are you at?
<SeanTAllen>
does it crash on compile on when its running?
copy` has joined #ponylang
<SeanTAllen>
with latest compiler, master of multi-barber has compilation errors for me Jbbouille
<SeanTAllen>
when i fix the compilation error I get it running to completion. i think you might be on an older version of the compiler/runtime and your issue has already been fixed.
<Jbbouille>
SeanTAllen: It crash wen it runs and I am on ponyc 0.2.1-98-g1ff3d90
<Jbbouille>
when*
<Jbbouille>
SeanTAllen: you where on master on the sleeping-barber project
<SeanTAllen>
yes
<SeanTAllen>
i was on master, latest, just cloned
<Jbbouille>
SeanTAllen: I got segmentation fault when I run on multi-barber branch
<SeanTAllen>
if you use the latest ponyc, you should be fine
<SeanTAllen>
you will need to change
<SeanTAllen>
ok
<SeanTAllen>
let me check that
<SeanTAllen>
that doesnt compile for me either
<SeanTAllen>
will fix and run
<SeanTAllen>
its running
<SeanTAllen>
finished
<SeanTAllen>
upgrade to latest compiler Jbbouille
<SeanTAllen>
you'll need to change your U64 to USize here: new create(env: Env, waitingRoomSize: USize, barbersNumber: USize) =>
<SeanTAllen>
and you should be good
<Jbbouille>
Okay, thanks and sorry for disturbing !
<SeanTAllen>
its fine
<SeanTAllen>
we've been fixing a number of bugs so tracking master closely is a good idea right now
<jemc>
Jbbouille: hopefully real soon we'll get some new stable releases out
<SeanTAllen>
indeed
<jemc>
I'm giving a talk on Pony next saturday, so it would be super great if we could have them out by then :)
<Jbbouille>
The date for a new release is planned ?
<jemc>
Jbbouille: unfortunately no - we're dealing with a build pipeline issue that's preventing us from doing an automated release
<jemc>
basically, the next release is planned for as-soon-as-we-get-the-build-pipeline-fixed
<SeanTAllen>
looking for volunteers to help with that...
<SeanTAllen>
*hint* *hint* to everyone
<SeanTAllen>
i'm known the world over for being subtle
<jemc>
SeanTAllen: do we have a description of the issue with the build pipeline somewhere where folks can read it?
<SeanTAllen>
jemc: i do not. sylvanc knows much more about it.
<jemc>
k
DanC_ has quit [Ping timeout: 252 seconds]
DanC_ has joined #ponylang
SilverKey has joined #ponylang
Praetonus has quit [Ping timeout: 250 seconds]
puzza007 has quit [Read error: Network is unreachable]
trapped has quit [Ping timeout: 250 seconds]
trapped has joined #ponylang
puzza007 has joined #ponylang
SilverKey has quit [Quit: Halted.]
<Jbbouille>
Okay and does someone knows what's the issue with build pipline ? Or how do we know there is a issue ?
jemc has quit [Ping timeout: 250 seconds]
jemc has joined #ponylang
Praetonus has joined #ponylang
<SeanTAllen>
sylvanc: appear!
<SeanTAllen>
let's see if i am a good magician.
<sylvanc>
why hello there
<sylvanc>
so
<sylvanc>
it's about generating releases via travis (and ideally appveyor as well, for windows)
<sylvanc>
and distributing them via some platform (bintray?)
<sylvanc>
it's not so much a question of it being broken as a question of "we need help from someone who is good at this"
<sylvanc>
the goal being
<sylvanc>
anyone with push access to github
<sylvanc>
could do somthing like:
<sylvanc>
make release version=0.3.0
<sylvanc>
and packages would be auto-released, and the homebrew formula updated
<jemc>
another project I'm affiliated with recently did something similar with tags - you git-tag a release number and push to github, then when travis succeeds, the release script is run
<jemc>
I'll see if I can "borrow" some ideas from how they're doing it
<jemc>
totally not volunteering for anything windows-related though :P
SilverKey has joined #ponylang
<jemc>
specifically, the question of coordinating between travis and appveyor is a weird one
<jemc>
if the travis build succeeds, but appveyor fails - what happens? the linux/OSX releases are performed, but the windows release is not?
<jemc>
that has weird implications for versioning, I think
<Jbbouille>
I am not "good at this", but I agree to spend some times on it, if needed.
aturley has joined #ponylang
<jemc>
sylvanc: how were the current releases (for example, dpkg and rpms) built?
Jbbouille has quit [Quit: Page closed]
aturley has quit [Ping timeout: 264 seconds]
aturley has joined #ponylang
Praetonus has quit [Quit: Leaving]
Jbbouille has joined #ponylang
rurban has joined #ponylang
_whitelogger has joined #ponylang
kushalp has joined #ponylang
russelldb has joined #ponylang
DanC_ has quit [*.net *.split]
mitchellvanw has quit [*.net *.split]
Guest40426 has quit [*.net *.split]
|jemc-bo1 has quit [*.net *.split]
Corwin_ has quit [*.net *.split]
juanjoc has joined #ponylang
c355e3b has quit [Ping timeout: 257 seconds]
Corwin_ has joined #ponylang
jtfmumm has joined #ponylang
tlockney__ has joined #ponylang
jeremyheiler has quit [Ping timeout: 260 seconds]
|jemc-bo1 has joined #ponylang
mitchellvanw has joined #ponylang
SilverKey has quit [Read error: Connection reset by peer]
Fuuzetsu has joined #ponylang
Fuuzetsu is now known as Guest78709
SilverKey has joined #ponylang
bb010g has joined #ponylang
jonrh has joined #ponylang
jeremyheiler has joined #ponylang
c355e3b has joined #ponylang
aturley has joined #ponylang
amclain has joined #ponylang
juanjoc has quit [Ping timeout: 252 seconds]
SilverKey has quit [Read error: Connection reset by peer]
<TwoNotes>
Shows how long it has been since I refreshed...
<TwoNotes>
Only 6 places I have to fix...
<TwoNotes>
oops, and UDPSocketAuth is new...
<doublec>
Yes, there's a TCP one too
<TwoNotes>
groan. Is there doc on how to create them? I assume they work sort of like for FilePath
<TwoNotes>
UDPAuth doesn't seem to do anything. Is it a place-holder?
SilverKey has joined #ponylang
<SeanTAllen>
yes
<TwoNotes>
To make a UDPAuth I need a NetAuth. To make a NetAuth I need an AmbientAuth. To get that I need access to Env, which I never needed before down in my network code.
<doublec>
TwoNotes: it's obtained from env
<SeanTAllen>
env.root as AmbientAuth for UDPAuth as well right now
<SeanTAllen>
will get you what "it was before"
<TwoNotes>
And an 'as' clause can fail, correct?
<SeanTAllen>
yes
<TwoNotes>
It used to be that creating a network socket could not fail. Now it can.
<SeanTAllen>
because you might not be allowed to
<TwoNotes>
So all my Socket fields have to become unions with None, which then I have to defend against at each use. I need to lie down...
rurban1 has joined #ponylang
<TwoNotes>
Under what circumstances might env.root NOT be an AMbientAuth?
aturley has quit [Ping timeout: 264 seconds]
rurban has quit [Ping timeout: 260 seconds]
<jemc>
TwoNotes: you can create a new `Env` via `Env.create`, which may or may not be given an `AmbientAuth`
<jemc>
you could use this to run `Main.create` of a sub-application, or merely to pass an `Env` somewhere arbitrary with more limited capabilities
<TwoNotes>
Ok. But the one received at "Main" will always be one, correct?
<TwoNotes>
always be an AMbientAuth I mean
<jemc>
the one received by the "main" `Main` of an executable, yes
<jemc>
for example, `packages/stdlib/test.pony` creates many sub-`Main`s for applications it wants to test
<jemc>
it doesn't pass them a different `Env`, but it could
SilverKey has quit [Quit: Halted.]
<jemc>
regarding needing object caps now to do network operations - yes, it's a bit of a pain, but Pony aspires to be a capabilities-secure language, and this is part of that
<jemc>
regarding having to replace all your socket fields with None unions - the change probably won't be as invasive as that - you can resolve the `(AmbientAuth | None)` to an `AmbientAuth` near the start of your application and simply print a failure message and exit if it didn't get the auth
<jemc>
then all your downstream code should be safe - you just have to refactor it to pass the object cap down
<jemc>
you might also consider only passing down the smallest cap you actually need (like UDPAuth, or whatever) instead of the full AmbientAuth.
* DanC__
should file that bug about (AmbientAuth | None) in Env
<DanC__>
there's no reason for Env to not have an AmbientAuth. AmbientAuth is about static properties of a program, not runtime. It means "whatever ambient authority main was given"
<DanC__>
wait... you can create an Env?
<DanC__>
I thought its constructor was private. looking...
<jemc>
there is a private constructor and a public one
<DanC__>
and why would socket fields become unions with None? I'm missing something there.
<doublec>
DanC__: constructors can't fail so if you're creating a socket in one and need to assign to a field...
<DanC__>
why have a public Env constructor? I can't see any benefit, as noted above, there's lots of cost
<DanC__>
can constructing a socket fail?
<doublec>
DanC__: if the socket creation fails (due to the ambient auth change) a quick fix is to make your field (socket | none)
<doublec>
DanC__: you need to pass an Auth and using env.root as AmbientAuth can fail
<doublec>
The other solution is to do what jemc recommended
<doublec>
pass the auth down, not the env
<DanC__>
well, in my preferred world, AmbientAuth cannot fail
<doublec>
and fail early
<doublec>
DanC__: but you might have an env with no ambientauth if you want to pass down a restricted environment
<DanC__>
let me put it another way: is constructing a socket just allocating some memory and scribbling in it? Or is it a kernel call that can fail?
<DanC__>
in my preferred world, every env has an ambientauth.
<doublec>
DanC__: it's not actually that socket that's failing, it's getting the auth to pass to the sockets constructor
<DanC__>
I maintain there is _no_ benefit to `let root: (AmbientAuth | None)`; it should just be `let root: AmbientAuth`
<doublec>
DanC__: the issue only comes up because of fixing bitrot with the ambientauth change - changing the approach removes the need for having socket|none fields.
<jemc>
DanC__: obviously sylvanc saw some benefit in being able to run other `Main`s inside your application, but not sharing with them ambient authority if you choose not to
<DanC__>
it's not at all obvious to me
<DanC__>
I keep asking him and he keeps not answering
<DanC__>
but I suppose I haven't opened an issue for this particular point, so I better do that
<doublec>
Couldn't you do similar by having an Env trait that doesn't expose the AmbientAuth and have a MainEnv that has it?
<DanC__>
you're not asking me, are you?
<jemc>
doublec: wouldn't you then just be doing Env as MainEnv at the start of your application?
<doublec>
Oh right, you still can't call existing Main's without passing it the full MainEnv
<doublec>
DanC__: just talking to myself really :)
<jemc>
doublec: yeah, either way you'd have to use `match` or `as` to whittle down the failure - if you want to keep the ability for the `Main.create` caller to deny that cap
<DanC__>
"On error, -1 is returned, and errno is set ..." -- socket(2)
<DanC__>
so you can't create a socket in a constructor anyway. (unless there's some other meaning of "socket" being used here)
<DanC__>
hmm... net/udpsocket.pony seems to attempt to create a socket and then run a callback to say how it went
<doublec>
DanC__: it's creating a TCPConnection (or UDP)
<doublec>
DanC__: the notify you pass it gets the callback of the system call fails
<doublec>
s/of/if/
<DanC__>
right
<doublec>
Maybe the constructor could accept an AmbientAuth|None
<doublec>
And the notify gets an no_auth failure if it's none
<doublec>
just to avoid the 'as' and resuting try/end needed
<doublec>
meh, better just to detect the auth abscence earlier
<jemc>
I can't say whether that's more or less desirable, but it would certainly work
<jemc>
you could also make a wrapper class with that behavior if you want it though
<doublec>
right
<jemc>
heck, you can even fork your own socket library that doesn't use an object cap at all if you like
<doublec>
I think this is only coming up because of existing design being retrofitted with the auth change
<doublec>
In reality you'd design it such that it can only get an auth and use the type safety
<DanC__>
sigh. accepting AmbientAuth|None would be missing the point. In fact, the AmbientAuth is an exception that shouldn't form precedent. NetAuth is a bad idea. Each capability should represent authority to do what you need to do.
aturley has joined #ponylang
<DanC__>
The only reason for AmbientAuth is that unix and such are not ocap systems.
<doublec>
Isn't that the idea of NetAuth though? Having a capability that represents authority to do network access?
<doublec>
(referring to "Each capability should represent authority to do what you need to do"
<DanC__>
"you can even fork your own ... that doesn't use an object cap". well, sure. and you can just write C code.
<DanC__>
No. If NetAuth worked right, it would have methods to create UDP sockets.
<DanC__>
NetAuth would be an interface (or trait).
<doublec>
true
<DanC__>
and you could take the "real" NetAuth and attenuate it to, say, only work between 4 and 5pm, and pass that to anybody who was expecting a NetAuth
<jemc>
DanC__: with the current state of the networking library, can't you write your own 3rd party package that works as you describe, with a `NetAuth` composed inside a `MyNetAuth`, where `MyNetAuth` has methods to create sockets?
<doublec>
Or have a fake netauth for testing without requiring a network that simulates failures, etc
<DanC__>
exactly, doublec
<jemc>
what I'm saying is, doesn't the current system allow you to build that abstraction on top of it?
<doublec>
Similar to how Mirage (the unikernal in ocaml) paramerizes everything for sockets, console, etc to allow posix implementations or bare-metal implementations.
aturley has quit [Ping timeout: 264 seconds]
<DanC__>
sure, I can write 3rd party packages to do whatever. But why? extensibility has a cost.
<DanC__>
that would be a failure to standardize when the opportunity is right there.
<jemc>
it's not a "failure to standardize" when people don't agree on how things should work
<jemc>
I'm a big advocate of having diverse, competing approaches
<DanC__>
you're aware of the costs, though, right? the loss of network effects?
<DanC__>
witness scheme vs common lisp?
<jemc>
I'm an advocate because I believe the benefits outweight the costs
<DanC__>
if there is _a tangible reason_ for extensibility, very well. otherwise, it's just friction for no reason.
<jemc>
you're free to disagree with me on that assessment of cost vs benefit (which is me respecting your right to have a diverse, competing approach)
<DanC__>
you believe the benefits *always* outweigh the costs?
<DanC__>
even if the competing apporaches are only arbitrarily different?
rurban1 has quit [Quit: Leaving.]
<jemc>
obviously not *always* - of course you can construct an artificial situation where they do not - and I'm sure there are real situations as well - but yes, as a general rule, I believe diversity is better at acheiving interesting and useful outcomes
<DanC__>
I see
<jemc>
(better than top-down uniformity, that is)
<DanC__>
I have quite a few extensibility scars from ~15 years of web standards work. I was usually on the side of extensibility and I was often just wrong.
<jemc>
we're all influenced by our experiences to believe the things we believe - and I certainly have no right to question the foundations of your beliefs
<jemc>
I'm just telling you where I stand, not where you should stand
<DanC__>
I'm kinda freaking out because I think it's absolutely critical that pony (and other ocap approaches) go mainstream soon. I don't want to see it wallow in obscurity any longer than it must.
<DanC__>
I made a small attempt to get rust to adopt ocap discipline in its stdlib, but I didn't have the bandwidth to make the case.
<doublec>
DanC__: did you used to be involved with W3C?
<DanC__>
and we all totally missed the boat with node.js
<doublec>
DanC__: I used to work for Mozilla, I've seen your name around.
<DanC__>
I was at W3C when HP came to us with eSpeak and I totally missed it and now we have Web Services. For this war crime, I am sentenced to spend my nights working on ocap projects. :)
<doublec>
haha :)
<DanC__>
yeah... ha ha only serious
<DanC__>
so... jemc... is there a level playing field on which I can compete?
<DanC__>
i.e. can we have packages net1 and net2?
<DanC__>
it's not exactly democratic when I wrote up one approach and he wrote up another and he merged his and closed my PR without merging it.
<jemc>
in my ideal world, yes, there would be a level playing field to compete because we'd (1) finish a package manager and (2) jettison the standard library into packages that you can choose to install (but may be included in a "default" installation)
<jemc>
I would absolutely love to separate compiler/runtime development from package development
<DanC__>
meanwhile, I suppose my level playing field is github. or the web. oh well.
Matthias247 has joined #ponylang
trapped has quit [Read error: Connection reset by peer]
<DanC__>
I can't afford to market a competitor. I don't even want to; I don't want to split the market.
<jemc>
I'm pretty anti-stdlib in the current sense for reasons exactly like this - you shouldn't have to ask for permission or convince anyone that your idea is a good one - you should be able to simply implement and attract mindshare if your package is a useful one to other people
<jemc>
this is what a believe, though I know not everyone feels this way (including other pony core members)
<jemc>
developing good packages is a separate concern from developing a compiler/runtime, and takes a different set of skills that often makes people good at one and bad at the other
<DanC__>
maybe I could convince you to try some A/B testing? just change `let root: (AmbientAuth | None)` to `let root: AmbientAuth` for 10% of the pony downloaders and see which ones are happier? ;-)
<jemc>
you bring up the good point that how the `Env` works would not be changeable in a user package, as it's part of the runtime
<jemc>
but it's not me you need to convince
<DanC__>
yup; I hope to collect my thoughts in an issue (or maybe a PR) soonish.
<DanC__>
thanks for bouncing ideas around
<jemc>
(I wouldn't want undo something sylvanc did on purpose without convincing him of the benefit first, especially when I'm not necessarily sold on the benefits of either approach)
<jemc>
yeah, thanks for the dialog!
<jemc>
I hope you can reach a satisfying enough outcome to stick around and stay a part of the community
<SeanTAllen>
i'm not in favor of jettisoning the standard library nor will i ever be.
<jemc>
SeanTAllen: we can talk later about the specifics of what I mean - I think we can probably reach some agreement about what should be done
<jemc>
for now the point is moot because there is no package manager
aturley has joined #ponylang
<jemc>
anyway, there's a reason I said "in my ideal world" to preface that statement - I recognize that we have to agree on a course of action that we can all be comfortable with
<SeanTAllen>
pretty sure by now i understand the specifics of what you mean jemc but, i'm still willing to listen
<SeanTAllen>
im a big fan of large, robust standard libraries. you aren't. perhaps someday we'll find a middle ground.
aturley has quit [Ping timeout: 264 seconds]
<jemc>
it may not be an outcome as unsatisfying as finding "middle ground" (where we both have to "give up ground") - I think it's likely that our respective concerns can be met simultaneously under the right conditions, depending on what the specifics of those concerns are - if not, of course I'm also willing to "give up ground"
<jemc>
anyway, let's revisit after we have a package manager
Matthias247 has quit [Read error: Connection reset by peer]