<BlaXpirit>
crisward this is what they wanted to prevent. an invalid string with a zero pointer or whatever, just because that constructor zeroes all bytes https://carc.in/#/r/1fon
pawnbox_ has quit [Read error: Connection reset by peer]
<FromGitter>
<crisward> Ah, ok thanks.
mentero has joined #crystal-lang
soveran has quit [Remote host closed the connection]
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/v1Ed0
<crystal-gh>
crystal/master 988005c Luis Lavena: Includes debug flag when compiling in debug mode...
matp has quit [Max SendQ exceeded]
matp has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
<akwiatkowski>
A few months ago I've had talk at local ruby group about crystal. Even when I summarized most of language problems as being early - some braking changes, and lack of libs - both theese problems are normal for young ecosystems. I wonder why ruby/web devs see crystal like an experiment, cool project but better not to touch it too much, and I'm thinking what must happen to change this pattern.
pawnbox has joined #crystal-lang
<akwiatkowski>
I think elixir/phoenix community steal people. Then see rails ruby/rails is stagnant/stable and want to get into something new and fresh, and there is elixir backed with Jose Valim, if I'm correct he was doing a lot in rails and near rails libs.
<akwiatkowski>
I'll put this on reddit. Hope to start discussion.
<BlaXpirit>
crystal needs code, not marketing, for now
<akwiatkowski>
by code what do you mean?
<akwiatkowski>
libs, samples, language/api code?
Philpax has quit [Ping timeout: 260 seconds]
pawnbox has quit [Read error: Connection reset by peer]
pawnbox has joined #crystal-lang
<BlaXpirit>
all
<akwiatkowski>
as a guy who moved his all scripts/tools from ruby to crystal, and is more than a happy from it, I think I'm doing proper job
<akwiatkowski>
I can write libs, but what is missing? Which lib i should write next which can benefit community better than my another tool doing "my stuff"
<BlaXpirit>
as long as it's not a web framework lol
<akwiatkowski>
I understand this joke ;]
<akwiatkowski>
but the questions remains
<BlaXpirit>
if i tell you what i'm missing, that doesn't mean you'll be interested in it
<BlaXpirit>
a library to manipulate mouse, keyboard , read pixels from the screen
<BlaXpirit>
good GUI framework
<akwiatkowski>
yes, it's not "my thing"
<BlaXpirit>
that's the problem i see
<akwiatkowski>
but there area more people than you and me
<BlaXpirit>
almost all people come from ruby and are interested only in web
<akwiatkowski>
I'm interesting in data processing
<akwiatkowski>
api, db, scrapping, scripts, server tools
<BlaXpirit>
there is nothing to offer to the scientific community
<akwiatkowski>
I know they already has the tools
<BlaXpirit>
i'm sure they regularly curse at Python's slowness
<akwiatkowski>
but rewriting existing gem to crystal without need to use, or group people who would like to use, is work without motivation, art for art's sake
<BlaXpirit>
if you're making the only library for some use case, then it'll find users
<BlaXpirit>
better that than writing the 100th library for a popular language
bjz_ has joined #crystal-lang
bjz has quit [Ping timeout: 246 seconds]
muelleme has joined #crystal-lang
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/v1EhO
<crystal-gh>
crystal/master ed790ae Ary Borenszweig: Fixed #3647: incorrect codegen for dispatch with union and module
soveran has joined #crystal-lang
soveran has quit [Remote host closed the connection]
soveran has joined #crystal-lang
soveran has quit [Changing host]
soveran has joined #crystal-lang
<akwiatkowski>
I'm thinking of creating lightweight jekkyll bloggin engine in crystal and maybe I'll try to upgrade markdown generator in the meantime
<RX14>
BlaXpirit, well i'm using crystal for satellite prediction so it's not all web
<RX14>
I just need to add pass prediction using root finding to predict.cr
<FromGitter>
<asterite> what's your goal with your projects? what's a use case? (I ask because I have zero knowledge about that)
<RX14>
well NOAA polar orbiting satellites transmit their weather images in the clear
<RX14>
then I'll use a SDR to recieve their weather transmissions on 137mhz
<RX14>
decode it using a program using wxtoimg
<RX14>
and display the processed weather images on a website
<RX14>
using vue.js and an API server in crystal probably
<RX14>
i'm building a tracking antenna rotator for keeping the antennas pointed to the satellites
<FromGitter>
<asterite> amazing
<crystal-gh>
[crystal] MakeNowJust opened pull request #3651: Add --time flag to show real execution time of crystal run (master...feature/time-flag) https://git.io/v1ukM
<RX14>
i'm not as good at the hardware as the software so the tracking platform may never materialize
<RX14>
but we already have static antennas good enough for the job
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
<FromGitter>
<luislavena> Late chime in, I'm using Crystal to process huge CSV and log files and matching against mysql database records and update counters on them.
<FromGitter>
<luislavena> Ruby implementation took 4-6 hours for 7 million records, new one in Crystal takes 2 hours, uses channels to batch process these records and less than 10% of CPU
<FromGitter>
<luislavena> RAM varies between 300MB and less (it depends on the batch size of the CSV or the log files)
<FromGitter>
<luislavena> We also use it for an HTTP API that translates some requests into Elasticsearch queries and return normalized/reduced JSON
<FromGitter>
<asterite> Super nice!
<FromGitter>
<asterite> What are you using for parsing CSV? (I guess the CSV module? If so, what API? There are several ways to parse CSV)
<FromGitter>
<luislavena> @asterite `CSV.new` with `headers` and #each on the IO. We also use `CSV.build(io)` and `csv.row` for logging into a CSV the task results
<FromGitter>
<luislavena> We looked at the different options and the iterator one (`#next` behind `#each`) is the best to avoid allocating lot of memory for the entire CSV
<FromGitter>
<bcardiff> In Ruby implementation do you know how was the CPU/Ram load?
<FromGitter>
<luislavena> @bcardiff don't remember the RAM part, but the CPU was 60%+
matp_ has quit [Quit: ZZzzzZz...]
mgarciaisaia has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
soveran has quit [Remote host closed the connection]
<akwiatkowski>
We often look at CPU when comparing, but RAM is often much more important. If we started where we use Crystal I could tell how I use it: geotag images using GPX file and jpeg exiv, parse and store weather data from METAR and by html scrapping, download static webcams and allow to create timelapses using mencoder.
<akwiatkowski>
I often ride bicycle by myself and I'd like to have app which announce that I'm "here" and wverything is ok "alive". I need some time to create android application, backend api is alpha ready.
vivus-ignis has joined #crystal-lang
<FromGitter>
<fridgerator> I've seen similar functionality using Tasker
pawnbox has joined #crystal-lang
gloscombe has quit [Ping timeout: 260 seconds]
gloscombe has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
<akwiatkowski>
I'm going to add referenced links to markdown.
<BlaXpirit>
great
<BlaXpirit>
akwiatkowski, one thing that i noticed some time ago. multiline list items don't work
<BlaXpirit>
not even proper multi-paragraph ones, just * abc\ndef breaks out from the list so you must write everything in one line
<akwiatkowski>
if you run spec you will see 7 errors :)
mgarciaisaia has left #crystal-lang [#crystal-lang]
<akwiatkowski>
I'll do it as a introduction and I'm sure that current implementation is not 100% spec correct, probably my referenced would also not be 100% accurate.
soveran has joined #crystal-lang
soveran has joined #crystal-lang
soveran has quit [Changing host]
matp has joined #crystal-lang
soveran has quit [Ping timeout: 268 seconds]
vivus-ignis has quit [Ping timeout: 246 seconds]
<FromGitter>
<asterite> @BlaXpirit I fixed that in the last release
<sp4rrow>
I guess I am curious why you would use one over an array
<sp4rrow>
that is kind of the typing question
<sp4rrow>
I am trying to figure out the ideal use for this
<Papierkorb>
you would not
<Papierkorb>
asterite, do I read the changelog right of 0.20.1 that the T in Slice(T) may now only be a pritimitive type and not a lib struct anymore?
<BlaXpirit>
Papierkorb, that is incorrect, i was a bit angry at this change before checking what it actually is
<BlaXpirit>
Papierkorb, this is what they wanted to prevent. an invalid string with a zero pointer or whatever, just because that constructor zeroes all bytes https://carc.in/#/r/1fon
<BlaXpirit>
T can still be anything, only this one constructor is limited
<Papierkorb>
Good then
<Papierkorb>
Else it'd broken `torrent` big time
<Papierkorb>
sp4rrow: You'll see it much more when you're doing some kind of low-level-y thing, like binary (network, file, ..) protocols, or interfacing with C libs
<Papierkorb>
sp4rrow: If you do neither, chances are you won't have much use for it :)
<sp4rrow>
I am still trying to understand it though
<sp4rrow>
trying to figure out with some things that I am doing if it is a better tool
<sp4rrow>
but I was putting chars and ints into an array
<Papierkorb>
An Array is basically like a dynamically sized Slice
<sp4rrow>
but I am wondering why a slice would be better
<RX14>
sp4rrow, the difference is that with slice, you control the memory allocation much more
<sp4rrow>
ah
<RX14>
and multiple slices can point to the same parts of memory
<RX14>
intersecting in any way
<sp4rrow>
that makes a lot of sense
<RX14>
whereas with array, array OWNS the memory
<RX14>
it uses realloc on it
<RX14>
moves it around
<RX14>
resizes it etc
<RX14>
array is a collection, slice is a bit of memory
<sp4rrow>
interesting
mark_66 has quit [Remote host closed the connection]
<RX14>
that details should probably be in the docs
<sp4rrow>
that actually makes what what I have read make a lot more sense
<sp4rrow>
thanks :)
<Papierkorb>
sp4rrow: Slice is also useful if you have a chunk of (binary) data which will not change in size, like if you read a file, that goes into a Slice
<RX14>
yes because you usually think of reading a file as a "bit of memory"
<RX14>
instead of "a list of bytes"
<sp4rrow>
ok that makes sense
<Papierkorb>
If you come from Ruby or another scripting language, you use Slice instead of stuffing binary data into a String in Crystal.
<sp4rrow>
same with networking traffic
<RX14>
yep
<RX14>
string is unicode only
<RX14>
binary data usually goles in a slice
<RX14>
and arrays are for actual collections
fcmod has quit [Ping timeout: 260 seconds]
<RX14>
but it's all a bit fuzzy and up to disgression really
<RX14>
it makes sense once you get the hang of it
<sp4rrow>
hmm still thinking about it all but the examples really helped
<Papierkorb>
sp4rrow: Another thing is giving an intention. Arrays are mutable collections, strings is human-readable unicode data, slice is a "bunch of bytes". Compare it to how there's Symbol and String in ruby (well, and in Crystal too), both are readable, but their intention is totally different
<sp4rrow>
ok awesome I can totally understand that
olbat has quit [Ping timeout: 250 seconds]
gloscombe has quit [Ping timeout: 260 seconds]
gloscombe has joined #crystal-lang
maxpowa has quit [Quit: Ahh! My head is on fire!]
maxpowa has joined #crystal-lang
muelleme has quit [Ping timeout: 250 seconds]
gloscombe has quit [Client Quit]
<RX14>
I think crystal really should allow preceeding zeroes
<RX14>
Time.new(2016, 02, 11) looks much nicer to me
<FromGitter>
<asterite> We can probably add it, because for octal we have 0o...
<RX14>
yep
<RX14>
the error errors out saying use the octal syntax
<RX14>
but its been long enough
<RX14>
i think it's a good idea to allow it
<FromGitter>
<asterite> On the other hand, if people come from other languages they might get a surprise if they expect a leading zero to mean octal... for example one writes 0666 and it's not what you expect. So we should think about it a bit more
<RX14>
sure but I don't think octal is particulary oft used
<RX14>
BTW @asterite, did you see my suggestion of a feature freeze to focus on multi-threading?
<FromGitter>
<asterite> Just for permissions, I guess. We can discuss it in an issue, for formatting/alignemnt/readablity I agree that it's nice
<FromGitter>
<asterite> Mmm... no, didn't see it. What is it about? Just a feature freeze?
<RX14>
yeah basically
<RX14>
just stop implementing new features to focus on parallelism
<FromGitter>
<asterite> Sure, we can do that
<RX14>
is the GC the first hurdle?
<FromGitter>
<asterite> The problem is, waj was the one who was mainly working on that, but now he's on honey moon
<RX14>
hmm
<RX14>
well congratulations to him
<FromGitter>
<asterite> No, making the scheduler support multiple threads, do job stealing and balance stuff is the hard part
<FromGitter>
<asterite> He began work on that, but it's super hard... you are basically dealing with segfaults and random crashes all the time
<RX14>
well if the GC doesn't work over multiple threads, then we need to get that working before we can test the scheduler
<FromGitter>
<asterite> He said he wants to implement it super well, super efficient, from the go, because otherwise there's not much point to it: it will make everything slower than now otherwise
<FromGitter>
<asterite> The GC already works over multiple threads, he patched it
<FromGitter>
<asterite> The problem is that it's a patch to GC, so now we won't be able to use libgc as is, we'll need to provide it ourselves
<RX14>
is this a patch which should make it's way upstream?
<FromGitter>
<asterite> which touches the Makefile and how to distribut things
<FromGitter>
<asterite> I don't know, maybe waj should send a PR. But it might take a while until they merge it and release it
<RX14>
yeah, and then add another 2 years until debian gets it
<BlaXpirit>
optimistic
<FromGitter>
<asterite> lol
<FromGitter>
<asterite> Anyway, we'll soon (when waj comes back and we sit to discuss this and other stuff with others) release a roadmap of the most important things we want to tackle before 1.0. A sneak preview of that is that parallelism, and most probably windows support, will be on the roadmap. We just need to focus all our efforts on those things, so yeah, a feature-freeze of everything else is a good idea
<FromGitter>
<asterite> Then we'll review the std, how macros work (I'd really like to improve them, let them be more like what Elixir or Lisp have), and think about any remaining breaking changes
<RX14>
hmm
<RX14>
the current macros I feel are very good for getting simple stuff done
<RX14>
and limiting the scope and power of macros seems like a good idea to stop their overuse
<RX14>
so I think macro changes at least should be handled with care
<RX14>
but yes a concrete roadmap would be amazing
<FromGitter>
<asterite> Yes, I totally agree with that. On one hand they do have limits so they aren't super super powerful, and that might be good. So yeah, should be handled with care :-)
bjz has joined #crystal-lang
bjz_ has quit [Ping timeout: 256 seconds]
<BlaXpirit>
isnt it too late to redesign macros
<RX14>
it might seem sp
<BlaXpirit>
so many crucial projects will break
sp4rrow has quit [Quit: The Internet needs a break and I need a cookie]
soveran has joined #crystal-lang
<RX14>
macros are a mess though
<BlaXpirit>
generally they're the best macros i know
<RX14>
maybe, but they're still a mess
<BlaXpirit>
when are macros ever not a mess
<FromGitter>
<asterite> lol, true
<tilpner>
Racket seems to do fine c.c
<FromGitter>
<asterite> I like one thing that waj said, is that for example Rust changed a lot, but *a lot* of times and dramatically in successive versions before reaching 1.0. They wanted to get mostly everything right. I think we should take the chance that we are still 1.0 to do those breaking changes. We are always careful to provide a happy upgrade path, though, so existing macros won't suddenly stop working
<FromGitter>
<asterite> (and I agree with what BlaXpirit says, even though macros aren't as pure as lisp or elixir, they are pretty intuitive, I think, in that they are almost like erb/django templates)
soveran has quit [Ping timeout: 265 seconds]
<RX14>
yes
<RX14>
i like that macros are easy to read
<RX14>
that they're text-based instread of AST-based
<RX14>
because developers read text
<RX14>
not the AST
<RX14>
also time's .inspect method really should print out to full precision
<FromGitter>
<asterite> That's what I'm not sure about: text based. In Elixir it's almost the same, they look like text, but they operate on syntax. The difference is that elixir can use erlang's vm (beam) so it's much easier... they interpret stuff, but fast
<RX14>
hmm
<FromGitter>
<asterite> One thing I don't like about current macros is that because code is pasted and then re-parsed, the location of the passed nodes is lost
<RX14>
taking a deep dive into rust, swift, elixir I think would really help crystal
<RX14>
i'm hardly familiar with any of them so I don't know when they've already solved a problem crystal has
muelleme has joined #crystal-lang
<BlaXpirit>
what problem
<FromGitter>
<asterite> Rust macros are more like pattern matching. I think swift doesn't have macros. And elixir have them, but elixir has the erlang vm, so... Nim also has macros, they interpret them, I think the language author (Araq) made a VM for them
<RX14>
any problem
<RX14>
just taking ideas from the rust, swift, elixir communities seems like a really good idea
<RX14>
depending on their applicability of course
<FromGitter>
<asterite> Sure! We always do that :-)
<FromGitter>
<asterite> In fact in specs we use a jit unless the full prelude is included... I should probably try and see if now they fixed the issues
<RX14>
@asterite I saw some code referencing jit in the compiler
<RX14>
but I couldn't really trace it
<FromGitter>
<asterite> Another thing I'd like to try in the future is generating C code without going through LLVM... LLVM is nice, but it's so slow
<BlaXpirit>
wait what, is C code involved?
<RX14>
hmm, well you would have to use a C compiler eventually, no?
<RX14>
BlaXpirit, not at the moment
<RX14>
and C compilers are as slow as LLVM I think
<BlaXpirit>
yeah
<RX14>
I think abandoning LLVM is a mistake
<BlaXpirit>
yes
<RX14>
I think before we ever took that decision we should have a chat with the LLVM team
<RX14>
and see how LLVM can be optimized
<tilpner>
FWIW, crystal compile times compare very favorably to those of Rust :/
<FromGitter>
<asterite> I actually don't know if it'll get faster. I know nim generates C and it compiles really fast
<RX14>
well doesn't crystal cache LLVM files
<RX14>
well generated object per llvm module
<RX14>
also, how does whole-program optimization work in respect to that
<RX14>
do release builds not do that?
<RX14>
becaude i've definitely seen massive cross-class inlining when profiling microbenchmarks
<FromGitter>
<asterite> release build generates everything in a single module, so when you optimize llvm can see everything
<RX14>
ah, I thought so
<FromGitter>
<asterite> if we generate multiple modules you can only optimize them one by one... I think there's link-time optimization, but I know nothing about it, that might be a solution
<FromGitter>
<asterite> In any case, I always worry way too much about compile times :-)
<RX14>
LTO for gcc basically stores the AST in the object file
<RX14>
so the linker becomes a whole-project compiler
<RX14>
it seems messy to me
<BlaXpirit>
asterite, my memory is foggy but i'm pretty sure Crystal compiles faster than Nim
<RX14>
yeah crystal is pretty nice
<RX14>
for predict.cr, specs are run usually within 1s of me hitting save
sp4rrow has joined #crystal-lang
<RX14>
i'm amazed at all the work I see rust doing with their multiple levels of intermediate representation
<RX14>
whereas crystal just seems to go ast -> ir -> object
<RX14>
and crystal doesn't seem to be slower than rust significantly
<FromGitter>
<asterite> Yes! In fact, we also started working on something like that even before Rust announced it... but stopped because it's no high priority right now, it's basically an optimization
<RX14>
and has much faster compile times iirc
<FromGitter>
<asterite> RX14 are you on linux?
<RX14>
so I wonder whats the real utility of all those multiple IR levels
<RX14>
@asterite yes
<RX14>
i havent tested
<RX14>
but I assume rust is slower
<RX14>
i mean it took me a good 57 mins to compile servo that one time
<tilpner>
RX14 - Rusts MIR exists to simplify further higher-level optimizations and allow certain borrow-checking details
<RX14>
yes I get the borrow-checking thing
<tilpner>
Servo is quite big though, are there similarly big Crystal projects?
<RX14>
hmm
<RX14>
well
<RX14>
i have dinner
<RX14>
brb
<FromGitter>
<asterite> Yes, intermediate representation is really nice. With it, we could really easily add support for `retry` in exceptions, it's just a graph edge to add. But right now every new semantic bit has to be processed from scratch
<RX14>
well it'll add to the compile times
<RX14>
but on the other hand will it let us add incremental compilation?
<RX14>
from my perspective as a non-compiler developer it seems like a crystal IR is a loss for me: longer compile times, but we already have comparable performance to rust
<RX14>
to my eye crystal essentially leaves all optimizations to LLVM
<RX14>
and does very well off that
AckZ has joined #crystal-lang
optikfluffel has joined #crystal-lang
soveran has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
<RX14>
HEADER is essentially a tuple representing the data layout of the class
<RX14>
HEADER_SIZE is sizeof(HEADER)
<FromGitter>
<splattael> For fun I changed `class String` to `struct String` but the compiler failed with `String is not a sturct, it's a class` :D
<RX14>
so you just malloc HEADER_SIZE + string.bytesize + 1
<BlaXpirit>
splattael, that's just because it's probably reopened to add methods in countless places
<RX14>
where the +1 is for the null terminator
<BlaXpirit>
but it's has no chance to work anyway
Philpax has quit [Ping timeout: 260 seconds]
<FromGitter>
<splattael> @BlaXpirit well, I changed all `class String` occurrences... but still
<BlaXpirit>
it's so beautiful
<FromGitter>
<splattael> @RX14 Thanks for the explanation!
<BlaXpirit>
is there currently any way to execute code only if the class is ever used?
<BlaXpirit>
and only once
<BlaXpirit>
i want some runtime sanity check
<FromGitter>
<splattael> @luislavena ⏎ > Ruby implementation took 4-6 hours for 7 million records, new one in Crystal takes 2 hours, uses channels to batch process these records and less than 10% of CPU ⏎ We have a similar use case. We replaced a Ruby-based ranking server with a Crystal version. It's loading a 3 million CSV file in 11 secs and consumes 1.5 GB. Ruby did it in 15 minutes with > 6 GB!
<FromGitter>
<splattael> @luislavena ⏎ > Ruby implementation took 4-6 hours for 7 million records, new one in Crystal takes 2 hours, uses channels to batch process these records and less than 10% of CPU ⏎ ⏎ We have a similar use case. We replaced a Ruby-based ranking server with a Crystal version. It's loading a 3 million CSV file in 11 secs and consumes 1.5 GB. Ruby did it in 15 minutes with > 6 GB!
<FromGitter>
<splattael> (Gitter is weird sometimes)
fcmod has quit [Ping timeout: 260 seconds]
<BlaXpirit>
RX14, one thing I don't understand - in the string, where is the first int needed for the type id?
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<BlaXpirit>
HEADER_SIZE = sizeof({Int32, Int32, Int32}) - so presumably these are typeid, size, bytesize, i forgot that the pointer doesnt need to go there
optikfluffel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<BlaXpirit>
ok, so it is making a little bit of an assumption that the integer type for typeid is int32
optikfluffel has joined #crystal-lang
optikfluffel has quit [Client Quit]
optikfluffel has joined #crystal-lang
optikfluffel has quit [Client Quit]
optikfluffel has joined #crystal-lang
<RX14>
well
<RX14>
yes I guess
optikfluffel has quit [Client Quit]
optikfluffel has joined #crystal-lang
<BlaXpirit>
oohh i forgot one thing
<RX14>
when would you need more than 2^32 types?
<BlaXpirit>
what about subclassing
<RX14>
for string?
optikfluffel has quit [Client Quit]
<BlaXpirit>
for any type that would use such a trick
<RX14>
I imagine that just wouldn't go too well
<RX14>
try it
optikfluffel has joined #crystal-lang
<RX14>
as soon as you add an instance variabe you're all out of whack
optikfluffel has quit [Client Quit]
<BlaXpirit>
i understand that this would happen by default, but any way to prevent it?
<mussela>
I'm working on a shard, but I'm kinda lost as to how to distribute binaries with it
<mussela>
does shards support this already?
<BlaXpirit>
no
<BlaXpirit>
do you mean platform-specific binaries that your code depends on, but not made by you?
<mussela>
no, I mean a binary with my lib
<mussela>
I made a lib to stuff a bunch of files into just one (for ease of distribution) and I want to ship a binary with it to create said "tar" files
Philpax has joined #crystal-lang
optikfluffel has joined #crystal-lang
<RX14>
mussela, so this is a standalone application?
<mussela>
RX14: no, it's a lib to open files created in a certain format. the bin to accompany it is to read said files
<mussela>
sorry, I mean create said files
<RX14>
no but the fie you want to distribute is a standalone application
<RX14>
you're distributing it with a lib, sure
<mussela>
yes
<BlaXpirit>
i think you can put it anywhere in the git repository and shards will just copy everything
<mussela>
cool
<mussela>
I'll try that
<RX14>
there currently isn't a way to install executables in a dependants project
<RX14>
you can use a postinstall script
<RX14>
in shards
<BlaXpirit>
what's that gonna do
<RX14>
then you get them to use lib/shard/executable
<mussela>
postscript to place it in /usr/local/bin?
<RX14>
no
<BlaXpirit>
D:
<RX14>
don't install dev tools globally
<mussela>
ok
<RX14>
anything distributed alongside a library should be compiled locally to each project
<BlaXpirit>
well yeah, distributing binaries is not a good idea, but you're just avoiding the question
<RX14>
how?
<RX14>
you compile the binary in the postinstall
<RX14>
then get them to use libs/shard/executable
<RX14>
what's that going to do? let them use the tool
<BlaXpirit>
mussela didn't say they wanted to compile a binary; they want to distribute a binary
<RX14>
but this is the way to distribute it
<RX14>
you distribute it as source and get people to compile it on their dev machines
<RX14>
if it's a generic tool which you want people who don't use crystal to install you work out your own distribution system that works for you
<RX14>
but for the "i want to provide a CLI with my lib" usecase this is how you do it
<RX14>
soon shards will be able to specify that they want an executable installed to bin/whatever in the developer's directory
<RX14>
bin/foo is nicer than libs/foo/foo after all
<RX14>
lib*
<mussela>
yeah
<RX14>
but for tools which aren't developer tools for crystal, we have the same binary distribution model as C
<RX14>
work it out yourself
<RX14>
any large executable project will eventually create a curlbash so in the end the result's the same :)