<zamith>
I think everything under src goes to the crystal_path, and then you can require it from there
<zamith>
not sure there is a convention (or requirement) that has to be met
<jhass>
it's doing git clone git://github.com/#{@author}/#{@repository}.git #{@target_dir}; ln -sf ../#{@target_dir}/src libs/#{name} essentially from the looks at it
<jhass>
so project structure would be things like src/library.cr src/library/file.cr I'd say
<jhass>
mmh, no, that would cause require "library/library/file"
<zamith>
you could have that
<zamith>
then require "library"
<zamith>
which you require all the other files
<zamith>
that's how ruby does it
<jhass>
yes except that rubygems adds each individual libraries lib dir to the load path
<zamith>
and crystal adds every library (shard?) src dir to the crystal path, right?
<jhass>
while crystal on a require "foo", if it finds a directory foo in the load path it tries foo/foo.cr
<jhass>
no
<zamith>
oh
<zamith>
really?
<jhass>
really
<jhass>
so that sort of achieves the same behavior if you do above mentioned structure and want a require "library" load the entire thing
<jhass>
but for partial library loading it ends up being require "library/library/whatever"
<naps62>
Yes I noticed that
<jhass>
which also means you always want to use relative loading inside the library ( require "./library/whatever")
<naps62>
I actually just submitted a pull request related to that
<naps62>
adding "local" dependencies in addition to github
<naps62>
but doing a similar thing with the symlink
r20 has quit [Ping timeout: 252 seconds]
<naps62>
actually no. I just noticed I missed the "/src" part :(
<zamith>
require "library/library/whatever" is not very good
<zamith>
what can we do about it?
<zamith>
from where I stand, we can either change the loading mechanism or change the convention for naming
<zamith>
or do nothing
<zamith>
:P
r20 has joined #crystal-lang
<jhass>
I do wonder if it would be feasible to make the load path compile time dynamic
<jhass>
so that deps or whatever could add stuff to it
<jhass>
since I think following rubygems idea here and adding stuff to the load path is the cleanest approach
<jhass>
and I'd even consider removing libs from the default load path then
<jhass>
or maybe just add all subdirectories of libs to the load path by default, though I could imagine that has non-obvious issues
<naps62>
That seems like it introduces a lot of issues, particularly name conflicts
<zamith>
let's defer this for when Ary get's here :P
<jhass>
with the current scheme project structure should be src/library.cr src/file.cr
<zamith>
yeah, but that's not very clean
<jhass>
which has the issue with having inconsistent requires
<zamith>
and you're probably want to modularize it a bit
<jhass>
in library development vs library usage situations
<zamith>
adding directories at will
<zamith>
yes, that as well
<zamith>
I was wondering, though, how can you tell a crystal library from some random crystal code with a src folder?
<zamith>
you really, can't
<zamith>
just that the later won't work/require as expected
seb_ has quit [Quit: seb_]
leafybasil has joined #crystal-lang
<naps62>
Is there a way for me to run just a spec file instead of the whole suite?
<naps62>
It's been a while since i've looked at a Makefile, but I don't see that option in there
leafybasil has quit [Ping timeout: 245 seconds]
<jhass>
just run it
<jhass>
crystal spec/foo/bar_spec.cr
<jhass>
naps62: ^
asterite has joined #crystal-lang
<asterite>
hi zamith. Sleeping already? :)
<zamith>
not yet
<zamith>
:)
<asterite>
How did the live coding go?
<asterite>
I saw your slides, I really like them
<zamith>
thanks
<zamith>
:)
<zamith>
it went well
<asterite>
If you don't mind, I have a few observations
<zamith>
I showed an example of http/server, websockets and frank
<zamith>
sure
<zamith>
go ahead
<asterite>
Wow, those are good examples to show off what can (could) be done :)
<zamith>
I'm up for improvements
<asterite>
It's probably because of the disorganized docs we have, or the lack of them
<asterite>
First, did you compile the fib program with the --release flag?
<zamith>
yeah, I encouraged people to contribute to the docs
<zamith>
no, I didn't
<zamith>
does it make a difference?
<zamith>
I just wanted to show it was faster, with the same code
<zamith>
the bechmark is not the most precise, I'm sure there are other variants
<asterite>
Yes. It's just twice faster. But of course 20x or 40x doesn't make much difference to the audience, so it's ok
<zamith>
btw, is it possible to contribute to the docs?
<zamith>
what does release do?
<asterite>
I just wanted to let you know about the --release flag, just in case you didn't know it
<asterite>
Well, it turns on LLVM optimizations
<zamith>
oh ok
<zamith>
I was not aware of it
<zamith>
nice
<zamith>
:)
<asterite>
so basically for development you would do `crystal file.cr`
<asterite>
but then you can do `crystal build file.cr --release` and that creates an optimized executable
<asterite>
:)
<asterite>
Other things
<asterite>
Single quoted strings: we have a Char type, so 'a' is a Char, etc. But 'foo' is a syntax error (similar to Java, C, etc.)
<asterite>
We could have copied Ruby's ?a, but we don't like it that much
<asterite>
require_relative: you can do `require "./bar"` to get the same
<zamith>
yeah, I said that about the single quoted strings
<zamith>
those were more thinks that are not exactly the same
<zamith>
not that are not possible
<asterite>
Oh! So just ignore me. I'm probably missing what you said regarding those slides :)
<zamith>
maybe it didn't come out as that
<jhass>
naps62: still there in 2.2
<zamith>
without me speaking
<zamith>
:P
<asterite>
Ah, I understand
<naps62>
jhass: Ok my mistake then
<asterite>
Yes, you can do `?????:??` for fun in Ruby ;)
<zamith>
asterite: I didn't know about named arguments though
<zamith>
that is cool
<asterite>
Well, those are all my comments about your slides. Again, I just wanted to comment in case you didn't know those things (so you can use them in your programs), not as a critique to the slides
<zamith>
oh, it's fine
<zamith>
I'm just learning the language
<zamith>
any feedback is awesome
<zamith>
when we have time though, me and naps have opened a few prs with ideas for new stuff
<zamith>
I understand it must be hard to juggle the time to look over everything
<zamith>
;)
<asterite>
Hehe, I was going to say something about that
<asterite>
I don't know what happened, but I came back from vacations and it's like, boom, lots of (small) issues and (big) pull requests
<asterite>
I think I need to clone myself to have the time to do that :-P
<zamith>
hahahaha
<asterite>
And I usually ask @waj for advice, I don't like to take decisions just myself
<zamith>
makes sense
<asterite>
but he's a bit busy these days... so I'm a bit slower than usual
<zamith>
np, I was just curious, because some of my prs were suggestion/personal preferences, not exactly bugs
<asterite>
I'm actually very surprised that you gave a talk so soon after learning the language
<asterite>
and that naps62 made that super pull request with local dependencies after you told him about Crystal just a few days ago
<asterite>
:)
<zamith>
yeah, we are both having fun with it
<zamith>
:)
<naps62>
I'm still working on other fixes, actually :P
<asterite>
Just now I was going to review/merge some PR, but then I saw your tweet, saw the slides, etc., so maybe I'll do that tomorrow
<zamith>
sure
<zamith>
the most critical thing, imo, to attract more people is to improve the docs and the README on how to get from 0 to a working program
<zamith>
are the docs open source?
<asterite>
Yes
<asterite>
There's a gh-pages branch on the same repo
r20 has quit [Ping timeout: 272 seconds]
<asterite>
All the site's source code is there
<zamith>
cool
<asterite>
and in the `docs` directory there's the source code of the documentation
<asterite>
We are using GitBook
<zamith>
thanks
<asterite>
so you can edit that with their apps
<zamith>
as someone just coming to the language that was the biggest issue I faced
<asterite>
Yes, docs is one of the most important things we need right now
<zamith>
I'll try to work on that as much as I can, then
<zamith>
;)
<asterite>
I was telling @waj the other days that people using Rust can use it because: 1. They can read about the language, 2. They can install packages with Cargo and 3. They can read a package's docs
<asterite>
So I think we need those 3 things to get people to contribute more easily
<zamith>
completely agree!
<zamith>
the resistance to entry must be removed as much as possible
<zamith>
or at least moved to later moment when the user has gotten some wins (running code)
<asterite>
Oh, there was a point 4: easily install Rust. That was point 0, actually, and where we started (and I think it worked as we don't hear many complaints about "I can't install it")
<asterite>
zamith: definitely
<zamith>
yeah, the language itself is good enough to be used, imo
<naps62>
I was actually interesting in looking at the installation process
<naps62>
And I guess we could easily do something like Rust has
<zamith>
installing the actual language is easy, at least in mac
<zamith>
doesn't get easier than brew install crystal
<zamith>
naps62: what are you referring to, precisely?
<naps62>
well, nothing actually, since I just saw in the docs that it already exists :P
<naps62>
Didn't see that the first time I went there
<zamith>
asterite: actually, we were discussing something about the loading of dependencies, and how to require a specific file from a lib you would have to do require "library/library/file.cr". assuming that the follows the common structure for a lib in ruby, like frank does, for instance
<zamith>
do you see this as an issue?
<zamith>
is there a solution for this?
<asterite>
Ah. In Ruby, why would you want to require just a part of a library?
<jhass>
because your library might just be a collection of useful things
<jhass>
like higher level threading primitives or whatever
<jhass>
or think ActiveSupport
<asterite>
I see. Well, we can make `require "foo/bar/baz"` to check for "foo/foo/bar/baz.cr" if it can't find "foo/bar/baz.cr"
<asterite>
In any case, there's no difference in terms of performance in the final executable: what you don't invoke or use doesn't get compiled
<jhass>
why again don't you like load path modifications?
<asterite>
and parsing files is super fast
<jhass>
rubygems adds each library's lib dir to the load path
<jhass>
I think that leads to the cleanest and most consistent structure
<jhass>
since you can then easily have the same behavior for library development and library usage
<jhass>
I actually find the on dir foo do foo/foo.cr thing a bit counter-intuitive already tbh
<asterite>
I don't know, I'd like to remove things from the language, not add them. Having a changing load path makes users need to know about it. The way things are right now is: put your code in "src", put dependencies in the "libs" directory inside a directory, that's it
<jhass>
what I don't like about the current approach is that I can't add src to the loadpath and have the same behavior as when using the library in another project
<asterite>
And because of `require "foo"` looking only for "foo.cr" (under libs, which won't exist) or "foo/foo.cr" (which will exist if you have a library named foo), the conflicting thing about rubygems disappears
<asterite>
Ah, you mean, in a spec inside the project you need to do `require "../src/..."`?
<jhass>
and I think it's actually easier to reason about loadpath than when require is "smart" and rewrites things so I can use "pretty" requires
<jhass>
for example
<asterite>
But who and how will change the load path?
<asterite>
Is it a compiler flag, or is it code?
<jhass>
potentially both
<asterite>
So crystal will first load something like rubygems, which will manage the load path?
<asterite>
Is anyone fiddling with $LOAD_PATH besides rubygems?
<jhass>
instead of crystal deps doing some symlinking into the loadpath, crystal build could look for a Projectfile and set things up
<jhass>
things=the loadpath
<asterite>
I understand. But I prefer convention over configuration
<asterite>
If you can't change the load path, it means all projects will have the same structure: src, libs
<asterite>
(or lib, we need to review that)
<asterite>
But in Ruby you have to do that if you want to be nice with rubygems. You can do otherwise, but you are in for trouble
<zamith>
asterite: how can you tell a crystal lib, from a repo with some crystal files and maybe a src dir?
<jhass>
I'm not sure I follow, you say you want a consistent structure for all crystal projects, but then it's a contra argument that rubygems requires a consistent structure to play nice?
<jhass>
and just because I can add things to the loadpath via ie. crystal build -Ifoo, doesn't mean crystal can support and encourage a convention by automatically adding stuff when it finds it's present
<jhass>
*can't support
<asterite>
zamith: why do you need to tell the difference? It's probably said in the readme (this is a library for, this is an app for...)
<asterite>
About the consistent structure: who else is fiddling with $LOAD_PATH besides rubygems?
<zamith>
hum... I wanted to be able to generate a list from github, for instance
<zamith>
:s
<jhass>
the programmer
<asterite>
Ah!
<asterite>
Maybe it's just that right now projects are too small for me to understand the real problem
<zamith>
maybe it's not a problem
<zamith>
we can just list everything, and let the community flag repos, or whatever
<zamith>
I would like to have that list in a nice website, though
<zamith>
having a decentralized dependency system does not mean we cannot have a central list of libs
<zamith>
:)
<asterite>
It's true
<asterite>
We might have a centralized repo some day
<zamith>
I actually like the decentralized thing
<zamith>
it's definitely cheaper, servers wise
<zamith>
any downside?
<jhass>
I just find it inconsistent that installing a library changes the path relative to the load path as opposed to developing the lib itself, specs is just the example we currently have, who can imagine what tools that want to work with the libraries source tree might come in the future. And I think adding more magic to require is not easier to understand
<asterite>
zamith: maybe that we lack a list of libs, as you say. But yes, one of the reasons we don't want to have a centralized server (for now) is that someone would have to pay that :)
<zamith>
I have to agree with jhass, that this is kind of "magic". I was not aware of it, until he pointed it out to me
<zamith>
yeah, it might be harder to track downloads as well, and such, but I'd roll with this decentralized thing as much as possible
<zamith>
asterite: I meant "magical" in the sense that I was not expecting it. But maybe because I didn't read the docs and was expecting it to behave as ruby
<jhass>
rubygems.org is btw just the biggest repository, rubygems itself supports multiple sources just fine ;)
<asterite>
Let's wait until somebody wants to change the load path for a reason, and then we'll have a use case and see how we can solve it
<zamith>
jhass: yeah, I know, but other than rails-assets, rubygems is pretty much the source
<jhass>
and some companies seem to do something similar on their own infra
<zamith>
yeah, internal stuff excluded
<zamith>
most oss gems are in rubygems, that's what I meant
<asterite>
This means: I don't disagree withy you both, I just can't find convincing reasons to change the current way. An idea would be for you (jhass) to submit an issue in github explaining the alternative (complete idea, including syntax and a detail of the implementation similar to an RFC)
<asterite>
Maybe we could have RFCs like Rust, or D DIPs, or Python's PEPs... no?
<zamith>
asterite: I'm not completely one way or the other. I'm just more used to the ruby way...
<zamith>
personally I prefer regular issues an prs, even for language ideas
<zamith>
another repo just for that seems too much overhead, imo
<zamith>
especially while we are few
<zamith>
maybe when/if the community grows, it will make more sense?
<jhass>
for local paths I'm currently doing a/src/a, b/src/b, c/libs/a -> ../../a/src/a, c/libs/b -> ../../b/src/b to workaround that
<jhass>
asterite: can recommend loomio.org if you seek a democratic decision process
<jhass>
should then have some policy writeups sooner than later though
<zamith>
jhass: going with what asterite said, maybe opening an issue (or pull request) with the summary of what was discussed and the rest of your ideas, and maybe a real example would be nice and easier to reason about than IRC
<zamith>
what do you think?
<zamith>
design wise loomio looks nice :)
<jhass>
not sure I'll find the time to write up in detail soon, and my main issue is not a technical one atm, but the feeling of inconsistency there, which makes it not really pressing ;)
<asterite>
Yes. Maybe I say no (well, language designers tend to say no as a first answer... not that I consider myself one, Matz did most of the job :-P) because I can't imagine how that load path management would work in code
<zamith>
do we have a decision on where to talk about this stuff though? Or at least where it can be stored in a more persisent way?
<asterite>
Got to go now. Thanks for all the love you are giving to Crystal!! <3 <3 <3
<zamith>
Is it a new repo, github issues, loomio?
<asterite>
zamith: GitHub issues is the way to go, I think