<shepheb>
I'm having a lot of fun writing this emulator for this toy invented computer, but this is a strange bug.
<shepheb>
(see also dispose() at the bottom of the file)
amclain has joined #ponylang
aturley_ has quit [Ping timeout: 248 seconds]
bb010g has quit [Quit: Connection closed for inactivity]
Praetonus has quit [Quit: Leaving]
aturley has joined #ponylang
eliquious has joined #ponylang
<eliquious>
once ponyc is installed, where should the user packages go?
jemc has quit [Read error: Connection reset by peer]
jemc has joined #ponylang
jemc has quit [Read error: Connection reset by peer]
aturley has quit [Ping timeout: 244 seconds]
aturley has joined #ponylang
<shepheb>
eliquious: what do you mean? third-party packages separate from Pony itself?
<shepheb>
I usually install those somewhere, symlink them into my project directory, and then reference "./some_pkg"
<shepheb>
YMMV
<shepheb>
(that doesn't play very nicely with git, for example)
mcguire has joined #ponylang
jemc has joined #ponylang
<eliquious>
shepheb: I mean does it matter where I write my code or where I install 3rd party libs?
<shepheb>
nope.
<shepheb>
ponyc will be able to find its own libraries.
<shepheb>
and when you run it, the current directory is the current package. you can include a subdirectory with use "mysubdir" and a core package with eg. use "collections"
<shepheb>
from inside a local sub-package, you can use ".." to include the parent, or use "../anothersubdir" to use a sibling.
<jemc>
note that you can also add more package search paths using the `PONYPATH` environment variable (although I think this isn't terribly well documented at the moment)
<jemc>
basically, that allows you to have other directories where you put your third-party packages that you want to use in your projects without specifying absolute or relative paths to them
<jemc>
we're working on a dependency management system to make this user experience a little more friendly
adamkittelson has joined #ponylang
jemc has quit [Read error: Connection reset by peer]
jemc has joined #ponylang
<eliquious>
`PONYPATH` sounds good.
<eliquious>
coming from go, i've really enjoyed being able to use "github.com/user/repo" for my imports
<eliquious>
but of course then you also need to handle versions..
<jemc>
I wrote a little tool to fetch deps from github and set PONYPATH - as a stopgap measure until we have a better package manager in place: https://github.com/jemc/pony-stable
<eliquious>
nice
<eliquious>
i really like where this language is going. i hope it starts to pick up momentum.
<eliquious>
read through the entire tutorial last night...
<eliquious>
there's been a lot of effort put towards the docs and it appreciated.
<jemc>
yes, there's been a concerted effort to bolster the docs over the last couple of months especially, with SeanTAllen leading that charge
<jemc>
in terms of momentum, I think we've already seen a significant expansion in the last 6 months of the size of the community of folks who have a working understanding of pony and are trying to build things with it
<jemc>
so I'm definitely optimisitc about where we're going :)
<shepheb>
TIL about PONYPATH
* shepheb
deletes a bunch of symlinks
<jemc>
shepheb: yeah, we need to document that one ;)
<jemc>
(I filed a ticket saying "wouldn't it be nice if we had [...]" and the answer was "we already have [...]"
eliquious has quit [Ping timeout: 250 seconds]
juanjoc has quit [Ping timeout: 244 seconds]
<SeanTAllen>
jemc shepheb: i added an issue to tutorial to document PONYPATH. definitely a good thing to have in an appendix.
<jemc>
yes, thanks
<shepheb>
jemc: haha that happens with my team at work all the time
<shepheb>
"Have we ever thought about having feature XYZ?" "foo/bar/xyz.js" "Wait, what? [git log foo/bar/xyz.js; first committed 2013]"
<bbhoss>
Are there any plans to expand the pattern matching into function heads like erlang, or is it already there and I'm just missing it?
<bbhoss>
one of my favorite things from erlang/elixir
<jemc>
we have some rudimentary pattern matching in the function heads in the form of "case functions" - these have been around a while but I think only recently documented, let me see if I can find the docs
<jemc>
I don't think it's as feature-rich as erlang yet (and may never be in this regard), and you may encounter some usability snafoos with it, but it exists
<jemc>
some of the limitations come from the fact that it is essentially just syntax sugar for a single function with a big match statement
<ponysaurus>
I would like to know more about matching on a union type like ByteSeq. I looked at tostring.pony for some guidance. But the current problem I have is that I can't quite unify push on both subtypes of ByteSeq
<ponysaurus>
jemc: Is this closer to what you were talking about yesterday?
<jemc>
ponysaurus: yes, I don't have time for a deep review right now, but it looks like what I was personally picturing, I think (ignoring big-endian/little-endian for now)
<ponysaurus>
jemc: Thanks for the quick pass. Yes, ignoring be/le.
<jemc>
for general use, would probably be nice to have a way to pass in your own ByteSeq to the buffer
<ponysaurus>
jemc: As in, to be specific, make whatsoever ByteSeq you pass in, the _current?
<jemc>
for example, a protocol that uses length-prefixed frames would look something like this: to append a frame, add a u64() number with the length of the frame, then add the frame bytes, which I alread hold as a ByteSeq of some sort
<ponysaurus>
yea, ok. optionally either append to current or make a new one.
<jemc>
so maybe you might push the existing _current into the list, then push the user-provided ByteSeq, then start a new _current
<jemc>
so that you don't have to do any copying of the user-provided ByteSeq val
<jemc>
(because you're not mutating it, just taking it into your list)
<ponysaurus>
sure. or have the user provide an iso?
<jemc>
a consumed iso can be passed as a argument to a val parameter, so if you specify val the user can pass either one
<ponysaurus>
i can't quite get the push right onto the ByteSeq (since it's a union type). Even though I match, and then write a separate push, the compiler complains.
<jemc>
first of all, I'm surprised to hear that they're not compatible implementations - might have to look into that later
<jemc>
but regarding how to make it work with match, your problem is that you're not capturing the matched type into a separate reference
<jemc>
for example, instead of:
<jemc>
match value | String => _current.push(value) ...
<jemc>
match value | let value': String => _current.push(value') ...
<ponysaurus>
I am trying to match on type of the seq_type
<jemc>
hm, I see ... tbh I don't follow what you're trying to do with _seq_type
<ponysaurus>
i am considering the case where the user just doesn't want to pass in a new ByteSeq, and some how magically just pass in String or Array[U8] as a type.
<ponysaurus>
if that makes any sense.
<jemc>
the user can always pass a String or Array[U8] where a ByteSeq is expected, since they are both subtypes of ByteSeq
<ponysaurus>
btw, on another note, my case of fixed frame size is not a problem any more, since I can check the size of _current. So i like this implementation better, as i feel it's cleaner
<jemc>
yes, I think you came up with a cleaner solution for fixing the frame size - I like it :)
<jemc>
(or at least, assuming I understand your idea correctly)
<ponysaurus>
lol .. i think you do. but then again, i can't be sure ;)
<ponysaurus>
jemc: the problems comes from the fact that push on string returns `String ref^` where as on array `Array[A]^`
<jemc>
can you elaborate?
<ponysaurus>
sorry, when I try to push a new byte entering the buffer onto the `ByteSeq iso` that I maintain, I get an error " a member of the union type has an incompatible method signature _current.push(value)"
<jemc>
have you tried:
<jemc>
match value | let value': String => _current.push(value') ...
<ponysaurus>
I tried to get around this by doing a push after a match (which is perhaps bad for performance). I still get the same error.
<ponysaurus>
let me get back to you. just in case I may have screwed up something else.
<ponysaurus>
when I am writing a byte the value is always U8
<ponysaurus>
I am guessing you mean a match on the ByteSeq itself.
<jemc>
err.. yep
<jemc>
and yes, honestly, I would hope the match shouldn't be necessary - but I can see why they might not be compatible due to the return value
<jemc>
still, conceptually it should be possible to ignore the fact that the return values are different if you don't use the return value - but I'm not sure if this causes a problem in LLVM-land or not
<jemc>
might be worth filing an issue about that part specifically (not being able to call .push on a ByteSeq) - it seems like that's counter to the intentions of what ByteSeq is
<ponysaurus>
also i am curious: if we match on an iso variable, I obviously have to consume it, and in this one specific case, it will be a mess. I don't want to give up my _current every time.
<jemc>
yeah that would be a mess indeed
<ponysaurus>
I wonder why String method returns are ref^
<jemc>
here's a workaround for you in this case - just use an Array[U8] iso on the inside
<jemc>
for your _current
<jemc>
but continue using a List[ByteSeq] for you list
<ponysaurus>
yea
<jemc>
s/you/your/
<ponysaurus>
i was going to do that before I asked you to review. but then realized you wouldn't get my intent at all
<ponysaurus>
ok. thanks for all the advice
<jemc>
no problem - good luck!
trapped has quit [Read error: Connection reset by peer]