<SeanTAllen>
interesting to see that you have given in the spacemacs
acarrico has quit [Ping timeout: 240 seconds]
<Schwarzbaer_>
Some more somewhat-offtopic questions: 1) What are the long words that refcap annotations abbreviate? I can guess _ref_erence and _val_ue, and *maybe* boxx and tag are just that (are they though?), but what the heck is trn? 2) What' spacemacs?
<SeanTAllen>
See the "The list of reference capabilities" section
slayful has joined #ponylang
gokr has quit [Remote host closed the connection]
<SeanTAllen>
2) https://github.com/syl20bnr/spacemacs has a good explanation of what it is. Short version from there: "A community-driven Emacs distribution - The best editor is neither Emacs nor Vim, it's Emacs *and* Vim! "
acarrico has joined #ponylang
slayful has quit [Ping timeout: 248 seconds]
jemc has joined #ponylang
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
alxs has joined #ponylang
alxs has quit [Client Quit]
alxs has joined #ponylang
<vaninwagen>
question is will spacemacs heal the eternal divide?
<Candle>
Or in other words, an IDE that I've hacked around the internals to get plugins from last decade to all play together nicely.
Schwarzbaer_ has quit [Ping timeout: 248 seconds]
Schwarzbaer has joined #ponylang
dipin has joined #ponylang
vaninwagen has quit [Ping timeout: 248 seconds]
vaninwagen has joined #ponylang
vaninwagen has quit [Remote host closed the connection]
SenasOzys__ has quit [Read error: Connection reset by peer]
Praetonus has joined #ponylang
SenasOzys has joined #ponylang
<dave24>
does anyone know of a pony CBOR implementation?
<SeanTAllen>
I dont believe one exists dave24
<dave24>
Alright, I'll make one then.
<SeanTAllen>
when you finish, please let everyone know on the mailing list.
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
<dave24>
Sure, it might be a little while.
alxs has joined #ponylang
<SeanTAllen>
it seems like someone in the ruby community did one based on messagepack as a starting point. in that case dave24, my pony message pack work might help you out. not sure if that is true or not: https://github.com/SeanTAllen/pony-msgpack
<dave24>
Ah nice, thanks. They have some similarities so this should be useful.
endformationage has joined #ponylang
samuell has quit [Remote host closed the connection]
_andre has quit [Quit: leaving]
<dave24>
So would it make sense to have a parameterised class instead of passing the reader each time?
<dave24>
or is there a reason you did it like this?
<SeanTAllen>
I wanted to start simple and with usage see what changes would need to be made
<SeanTAllen>
Also why I stuck to a very low level, functional interface for everything
aturley_ has quit [Quit: aturley_]
<dave24>
Ah ok.
Praetonus has quit [Ping timeout: 248 seconds]
Praetonus has joined #ponylang
codec1 has quit [Quit: Leaving.]
codec1 has joined #ponylang
codec1 has quit [Read error: Connection reset by peer]
SenasOzys has quit [Remote host closed the connection]
codec1 has joined #ponylang
<winksaville>
@SeanTAllen, how is ponyc built with the statically linked llvm created when releasing?
<Schwarzbaer>
Trying to grok traits and interfaces right now... Traits are sets of functions, and by using them, developers compose classes. Interfaces are sets of signature definitions, and by using them, developers insure that they don't forget to implement some function. Is that correct and complete?
nisanharamati has joined #ponylang
<SeanTAllen>
winksaville: i dont really understand the question
<SeanTAllen>
Schwarzbaer: Traits are nominal types. Interfaces are structural. Beyond that they are the same.
<SeanTAllen>
You have to declare you implement a trait, thats nominal typing
<Schwarzbaer>
SeanTAllen, what I am trying is to understand what that means. :p
<SeanTAllen>
You do not have to declare you implement an interface, that means you merely have to conform to it
<Schwarzbaer>
Oh, so interfaces are used by *other* code to check whether a type satisfies the interface?
<SeanTAllen>
yes but so are traits
<SeanTAllen>
traits and interfaces are both used to define a type that has to meet a certain combination of method signatures
<SeanTAllen>
AND
<SeanTAllen>
in order to implement a trait, the type must explicitly say it is of that type
<SeanTAllen>
err implements that trait
<Schwarzbaer>
TBH I start to feel more than a little stupid, but... What's the difference? That traits provide implementations, and that interfaces are just for checking?
samuell has quit [Quit: Leaving]
samuell has joined #ponylang
<jemc>
so if I have a trait `T` and an interface `I` that are otherwise exactly the same
<jemc>
and I have a class `C` that has all the methods required by that interface and trait
<jemc>
the class is a subtype of the interface already, even with no explicit knowledge of the interface
<jemc>
but for it to be a subtype of the trait, you have to declare it as `class C is T`
<Schwarzbaer>
So interfaces *only* check whether a classes functionality is sufficient to satisfy it, while traits provide implementations of functions, and allow for checking whether a specific trait was used?
<winksaville>
@SeanTAllen, I've looked at travis_script.bash and the critical piece looks to me to be "make .... deploy" in ponyc-build-packages.
<winksaville>
when execute "make ... deploy" llvm is dynamically linked, but if I look at the ponyc in the bintray rpm file llvm is statically linked
<winksaville>
So I'm wondering how that works?
<SeanTAllen>
can you tell me why you say "when execute make... deploy llvm is dynamically linked"
<SeanTAllen>
Schwarzbaer: you mostly have it but i think you are thinking about in a more complicated way than it needs be
<SeanTAllen>
to satisfy an interface you have to implement all the methods of that interface
<SeanTAllen>
to satisfy a trait, you have to implement all the methods of that trait AND declare that you implement the trait
slayful has joined #ponylang
slayful has quit [Client Quit]
<winksaville>
I'm looking at line 46 of .travis_script.bash:
<Schwarzbaer>
Wait... I thought that a trait's methods were implemented in the trait? Or can it provide required signatures just like an interface does?
<SeanTAllen>
Sorry winksaville, you stated that `make deploy` uses a dynamically linked llvm, why do you say that?
<SeanTAllen>
Schwarzbaer: AH! thats the source of confusion
<Schwarzbaer>
Apparently. ^^
<SeanTAllen>
No, traits do not have to implement the methods
<SeanTAllen>
in fact that is quite uncommon
<SeanTAllen>
both traits and interfaces can provide default implementations of methods, but that is generally not how most traits and interfaces work
<SeanTAllen>
im not really able to say why it happens differently on your machine. Do you have a statically linkable llvm installed?
<SeanTAllen>
if you check out the LLVM that is installed on travis, its all *.a files for LLVM, no .so files
<Schwarzbaer>
Okaaay... So both traits and interfaces *can* (but don't have to) provide default implementations of methods. I'll have to be frank here, I don't quite see yet how just specifying them will help to develop software. It seems like "One developer writes the contract, the other fulfills it" to me.
<SeanTAllen>
I dont really have a response to that Schwarzbaer. Comes off as kind of troll-y.
<Schwarzbaer>
Not at all my intention. Maybe it's because I'm coming from Python, which is so much of another world. I do see that a lot of thought went into Pony, but I can't really quite follow those lines of thought yet, but that's exactly what I'm trying to do right now.
<Schwarzbaer>
Also, the last time I was using interfaces was back at university when learning Java, and maybe it was a matter of the professor being not really good at explaining it, but "This defines a contract that needs to be fulfilled by the implementation" was pretty much the gist of it.
samuell has quit [Quit: Leaving]
khan has quit [Quit: khan]
<SeanTAllen>
Interfaces exist in Python, they are just implicit rather than explicit
<SeanTAllen>
By using interfaces and traits in Pony, you will get compile time, rather than runtime errors for a method not being implemented
<SeanTAllen>
In Python, you get those errors at runtime
<SeanTAllen>
but the interface and contract exists in both cases, its a matter of its implicit/explicit and when the type error is caught.
<winksaville>
yes if I add llvm_link_static as in: "make use=llvm_link_static ... deploy"
<SeanTAllen>
sorry, i didnt understand your answer winksaville
<SeanTAllen>
i dont know anything about your environment that you are compiling in, so its pretty impossible for me to tell you what about it being different is the reason you get a different result
<Schwarzbaer>
I see. But wouldn't I get those errors at compile time anyway, seeing how, well, functions that are being used would be missing?
<SeanTAllen>
all i can say is that you must have a LLVM so installed. The travis build machines do not winksaville
<SeanTAllen>
Schwarzbaer: wouldnt you get all of what errors at compile time? Are you referring to Python?
<Schwarzbaer>
No, Pony.
<SeanTAllen>
then I dont understand your question Schwarzbaer
<Schwarzbaer>
In Python, I can add and remove fields and methods at runtime, no problem. I'm not yet aware of whether I even can do that in Pony, and would suspect that I couldn't.
<SeanTAllen>
You can not.
<SeanTAllen>
You can provide classes that implement an interface or trait to satisfy a contract.
<Schwarzbaer>
Then whether a field or method is required to be present is defined by whether it's used in the code somewhere, isn't it?
<SeanTAllen>
I dont understand. Sorry.
<SeanTAllen>
Let me back up, I suspect I might know what is missing
<SeanTAllen>
So. your question seems to assume that if I have an interface Foo.
<SeanTAllen>
that I provide a Foo to methods, yes?
<SeanTAllen>
that isn't what you do
<SeanTAllen>
you provide something that conforms to Foo
<SeanTAllen>
`TCPConnectionNotify` has a mix of methods that come with default (do nothing!) vs ones that you are required to implement (mostly error handling ones)
<SeanTAllen>
A `TCPConnection` at key points in its lifecycle will call into my `Server` which implements `TCPConnectionNotify` in order to allow me to control the flow of what happens
<SeanTAllen>
It allows me to plug my specific implementation needs into the general framework of a TCPConnection's lifecycle
<SeanTAllen>
interfaces and traits exist to allow you to vary the implementation based on your needs.
<Schwarzbaer>
So the point here is that Listener.connected guarantees to return something that implements the interface TCPConnectionNotify, and that it'll be a new Server instance is more of an implementational detail?
<SeanTAllen>
Correct
<SeanTAllen>
that it is a new Server instance is purely my specialization
<Schwarzbaer>
Okay, I think I start getting it... It'll be quite a while until I'll be competent with it though.
<SeanTAllen>
You dont need to worry about creating interfaces and traits unless you are creating code that you want folks to specialize
<jemc>
yeah, interfaces are more or less the type-safe way of doing "duck typing" in python
<SeanTAllen>
Basically framework type code
<SeanTAllen>
For your every day code, you'll use class
<SeanTAllen>
and sometimes that class will implement a trait or an interface because you are using your class with some framework code
<SeanTAllen>
and you need to specialize how it works
<Schwarzbaer>
A while back I've written a game-playing AI, which broke down into a bunch of classes that could be composed into a specific AI that had certain properties, like "Prioritizes search tree expansion using MinMax" or "Does not expand beyond 20,000 elements". Traits felt a bit like they'd be like being made for something like that.
<SeanTAllen>
It sounds like it yes, although without seeing your specific use case, I can't say that for sure.
<winksaville>
@SeanTAllen, I think I've got it, I downloaded the debian version using wget as done in .travis_install.bash and sure enough there isn't an libLLVM-3.9.so
<winksaville>
Where as on my system executing "llvm-config --libs engine"
<winksaville>
returns the so file which is 5.0 on arch linux:
<winksaville>
-lLLVM-5.0
<winksaville>
So the summary is, the debian images do not contain "libLLVM-X.X.so" file and so on travis-ci llvm is always statically linked.
<winksaville>
I've also determined that the --link-static/link-shared parameter to llvm-config appears to be introduced in 3.9.1 its not avail in 3.7 or 3.8.
<SeanTAllen>
jemc: i'm going to try to put together docker images for each of our LLVM build types that we can use on circleci. I think it will cut down on build times AND make it so that we arent always 1 bad download away from errors. as you know, docker and i don't get along well, but I'm going to give it a go. I might end up bothering you once i reach maximum frustration. My plan is to base on Xenial ubuntu and have them
<SeanTAllen>
stored on the pony docker hub. Then try switching one of the LLVM versions over (for CI, not release builds).
<SeanTAllen>
plan would be to do it this weekend IF i don't feel like writing the backpressure blog psot.
<winksaville>
@SeanTAllen, using docker sounds like a good idea, the build times are very long and results are inconsistent.
<SeanTAllen>
the build times are pretty short for Linux. Its the wait for OSX resource that slows things down. But travis has had a lot of network related issue errors crop up lately.
<SeanTAllen>
There's a set of CI tests that do fail from time to time. There's an issue open to fix them but no one has taken it up.
<winksaville>
I've created a subset .travis.yml so I can do some verification on my travis account before doing a pull request.
<winksaville>
ok, yesterday a build didn't get canceled probably because I did something wrong :(
<winksaville>
I'll take a look at 2297
dipin has quit [Quit: dipin]
<Schwarzbaer>
This is probably a "Then your design is bad" question, but are behavior invocations guaranteed to be executed in order? If I do a.foo(); a.bar(), is that particular foo() call guaranteed to be executed before that particular bar() call?
<slfritchie>
Schwarzbaer: message delivery is in causal order, so foo()'s message would be delivered before bar()'s message. Plus you don't get to control the order of processing those messages. In sum, yes.
<Schwarzbaer>
Thanks.
<jemc>
Schwarzbaer: for `a.foo(); a.bar()` the order is guaranteed (messages with the same taget that have a causal order on a sender will also have a causal order on the receiver)
<jemc>
but that guarantee can break down when you start adding more layers, so if you have a more complex example to ask about, feel free
jemc has quit [Ping timeout: 240 seconds]
<Schwarzbaer>
I think I can already imagine a scenario where ordering becomes random, and it involves just four objects; I feel like I should try to not rely on it anyway.
<Schwarzbaer>
As for this instance, no, I was just curious.