<FromGitter>
<vegai> we don’t really have an install command everywhere, do we? By this I mean a single command that would download an app shard, build it and install it to some default location
<FromGitter>
<vegai> would such a thing be useful as a new shards subcommand or rather as a new tool?
alex`` has quit [Ping timeout: 244 seconds]
alex`` has joined #crystal-lang
ashirase has quit [Ping timeout: 256 seconds]
ashirase has joined #crystal-lang
mindcrimes has quit [Quit: ZNC 1.7.x-git-930-d6bfe504 - https://znc.in]
<FromGitter>
<rishavs> How can I downgrade to crystal 25?
<FromGitter>
<j8r> By experience, better to avoid downgrading with package managers in general, you may encounter conflicts. ⏎ The .local/bin way will allow you to have the latest version and another one
francisl has joined #crystal-lang
<FromGitter>
<sclee15> Hmm.. it seems like I cannot install the latest Crystal with brew just yet.
DTZUZU has joined #crystal-lang
return0xe has quit [Quit: Leaving]
return0e has joined #crystal-lang
<FromGitter>
<fridgerator> I dont know how brew works, but apparently since other libraries depend on Crystal (Amber) brew cant update Crystal until those other libraries are working as well ?!?
<FromGitter>
<fridgerator> something like that
<FromGitter>
<paulcsmith> Oh interesting. Maybe Amber could be moved out of core Crystal so it doesn't block Crystal releases?
<RX14>
perhaps ask the amber guys nicely if they'd remove their package from the core homebrew repository
<RX14>
or at least upgrade amber timely...
<FromGitter>
<bcardiff> A couple of options I can think of: ⏎ ⏎ 1) allow versioned versions of crystal in brew so amber can use specific crystal versions. disclaimer: not sure how multiple crystal versions work in the context of brew. ⏎ ⏎ 1) We switch back to a custom tap managed by us and let brew be able to update it eventually, but that will lead to less public using brew oficial formula since everybody is eager to use
<FromGitter>
<asterite> In my opinion amber should use a tap. Crystal is not 1.0 and being able to quickly advance versions is a good thing right now, and having crystal depend on amber just slows things down
<RX14>
2 is kinda dumb when it'd be better to have amber be the tap
<RX14>
1 is maybe worth investigating
<FromGitter>
<asterite> For example lucky has a homebrew tap
<RX14>
someone just needs to ask the amber guys and whoever submitted the original formula
<RX14>
then ask for it to be removed together
<FromGitter>
<paulcsmith> I'd be happy to ask them
<FromGitter>
<paulcsmith> I think it's ok to have breaking changes and not worry too much about deprecation warnings while Crystal is < 1.0
<FromGitter>
<paulcsmith> It would be *nice* to have intermediary releases, but I don't think it is worth the time that the core team would have to spend to make that work.
<FromGitter>
<paulcsmith> I would love version Crystal packages in brew, but I don't know how hard that would be
<RX14>
amber doesnt seem to be very active recently
<RX14>
@paulcsmith have you looked into using the new shards features to compile the lucky cli and place it in bin/lucky without the user having to install any packages?
<FromGitter>
<paulcsmith> Yeah I think that is a great idea! I just haven't had time to implement. Been prioritizing some other stuff (better authentication, encrypted secrets, and some new API features)
<RX14>
the main issue it working out the workflow around project initialization i guess
<FromGitter>
<paulcsmith> I want to totally refactor Lucky CLI and the generators so it can be used without Lucky CLI at all if that's what you want, but it'll take a decent amount of time to move everything around
<RX14>
since the lucky CLI won't be available for the initial init
<RX14>
i havent looked into lucky too much but it looks pretty promising
<FromGitter>
<paulcsmith> Yeah I think the default would be to install the CLI still, but people could use it without. I'm imaging you'd initialize a regular old Crystal project, add Lucky to the shards, shard install and then run `bin/lucky init` or something like that
<RX14>
i'm glad it's... less-railsy
<RX14>
@paulcsmith yeah
<RX14>
that was my thought, it'd be 3 steps instead of one
<RX14>
and bin/lucky instead of lucky after
<RX14>
but I like that and it allows you to have per-project versions of the lucky CLI and such
<RX14>
which i imagine simplifies some things
<FromGitter>
<paulcsmith> Yeah I like it too
<RX14>
perhaps having the installed lucky "cli" be a simple program which dispatches to crystal init or bin/lucky as required
<FromGitter>
<paulcsmith> Well right now Lucky CLI doesn't do a ton. It allows using per-project versions of the CLI because all running `lucky <task>` does it call the `src/tasks.cr` with some args
<FromGitter>
<paulcsmith> Yeah exactly
<RX14>
ah cool
<RX14>
i imagine the lasks are fixed though
<RX14>
so compiling the CLI for speed makes more sense
<RX14>
tasks*
<RX14>
also it'd be nice if lucky's readme wasn't just a link to external docs
<FromGitter>
<paulcsmith> Some tasks are, some aren't. This is the one thing Lucky CLI does a bit differently. You can precompile tasks with `post install` hooks. This works well for generators like `lucky gen.action`, but doesn't work as well for tasks that rely on the app code. Those can't really be compiled into `bin`. So what Lucky CLI does right now is it checks for a matching task in `bin/lucky/task/name` if found, it'll use
<FromGitter>
... that. If not, it'll call `tasks.cr` and run build and run the appropriate task. This makes it so you use the same command for "precompiled" tasks and ones that need to be compiled every time they're run
<FromGitter>
<paulcsmith> It also makes it so you can run `lucky --help` and see everything you can run
<FromGitter>
<paulcsmith> What would you like to see in the README instead of in the guides?
<RX14>
a basic example and introduction/design justification
<FromGitter>
<paulcsmith> I think that is a good idea
<RX14>
the first thing I look for when evaluating a project is the code example
<FromGitter>
<paulcsmith> But I could/should add those to the README as well
<RX14>
that'd be nice
<RX14>
how easy is it to use lucky without the ORM?
<FromGitter>
<paulcsmith> @jwoertink is doing that right now. There is no way to remove it completely (right now), but you basically set the url to "" and don't LuckyRecord and you're good to go
<RX14>
cool
<RX14>
i need more time to experiment with my own micro-ORM
<FromGitter>
<paulcsmith> You also can't use the form input helpers since they are tied to LuckyRecord forms, but you can use regular `input name: "whatever"` if you want to use it with some other ORM or if you just want to access the params manually
<RX14>
why is form input tied to the ORM?
<FromGitter>
<paulcsmith> It's not. The form helpers are because it extracts errors, values, etc. from the form fields. It also does something that is (IMO) super cool. It disallows using fields that aren't whitelisted
<FromGitter>
<paulcsmith> It does this at compile-time so you can't accidentally use fields that aren't marked as "fillable"
<FromGitter>
<paulcsmith> But if you don't use LuckyRecord you can use `input name: "whatever", value: "my value"`. Nothing stopping you from doing that if you don't use LuckyRecord
<RX14>
looks like i'd need to investigate more to understand where these input helpers fit in
<RX14>
but i'm really impressed by lucky
<RX14>
it looks a lot more crystally than other frameworks which appear to me to be closer to rails ports
<FromGitter>
<bcardiff> @paulcsmith maybe it would make sense to allow crystal init to have a bit of flavors to support kind of projects. not sure how to frame it other than add a url to do something like `$ crystal init my_app -as github:luckyframework/lucky' and fetch something from the repo. Something that would help frameworks and users to initialize the structure in a common way. It could evolve separate from the compiler and
<FromGitter>
... then replace the current init.
<FromGitter>
<paulcsmith> I'm glad you like it :) Yeah that was my main goal. Write a framework that embraces the advantages of Crystal. You simply can't do Rails in Crystal *and* take advantage of a lot of the niceties of Crystal, like type-safety.
<RX14>
@paulcsmith :+1:
<FromGitter>
<paulcsmith> @bcardiff I was thinking the same thing! I would *love* something like that. I'm not exactly sure how it would work but I know npm does something similar: `npx create-react-app my-app` temporarily downloads create react app
<RX14>
@bcardiff i'd imagine `init` would add it as a shard dependency, and then invoke some special shards command to ask shards to investigate lucky's shards.yml and run a special "init hook" command
<FromGitter>
<paulcsmith> https://github.com/zkat/npx I'm not sure how much of that would work with Crystal, but something similar would be incredible
<RX14>
perhaps here's something better seperated in concerns:
<RX14>
any shard can register an init hook in it's shard.yml which is run by a special shards run-init-hooks command
<RX14>
and then crystal init adds two new features:
<RX14>
- ability to preinstall shard(s) with the init command
<RX14>
- always run the init hooks after init
<FromGitter>
<paulcsmith> I ❤️ this idea
<RX14>
we already have some hook commands in the shards.yml for postinstall
<RX14>
so postgenerate would perhaps be a good name
<RX14>
@paulcsmith just compile the present lucky CLI to bin/lucky
<FromGitter>
<paulcsmith> Maybe `postinit` since you only want it when the project is initialized for the first time and never after that
<RX14>
and you're fine, surely?
<FromGitter>
<paulcsmith> Right, I mean, I could just not even have `bin/lucky` if there was something like it in Crystal
<RX14>
I think that's definitely worth investigating
<RX14>
worth pinging ysbaddaden for his thoughts
<RX14>
he'll definitely have some good ideas
<RX14>
perhaps type this up into an issue so it doesn't get lost
<FromGitter>
<paulcsmith> Yeah that is a good idea. I also have an idea for making a common interface for defining and running tasks in Crystal. It's kind of what Lucky CLI does now, but it would be much better to have it in Crystal so everyone can take advantage of it. I know people say to *just* use `crystal my_task.cr` but it falls apart in a number of scenarios. I'll write an issue for both illustrating the problems and potential
<FromGitter>
... solutions
<RX14>
that seems closer to something a shard could provide
<RX14>
and install itself into bin
<RX14>
keeping the crystal/shards toolchain light is pretty important
<FromGitter>
<paulcsmith> Sometimes that works, but sometimes it doesn't for example, LuckyMigrator does that for generating migrations, but it can't *run* them because it relies on Crystal files in `db/migrations`. That can't be done without re-running `shards build` and requiring files in `db/migrations`. That is not ideal so instead if uses a task that is not precompiled
<RX14>
even getting the init stuff in will be difficult to design while respecting separation of principles
<FromGitter>
<bcardiff> There needs be some limitation if each shards can add hooks. So potentially multiple shards can initialize. It's simpler if there is only one shard that performs the init. ⏎ Multiple shards initialization could be a headache with regards dependencies and versions. ⏎ ⏎ I would suggest to check solutions outhere to compare (yeoman is something worth to check i think). ⏎ ...
<FromGitter>
<paulcsmith> Yeah whatever it is needs to be super lightweight. And I agree. allowing multiple packages in `init` could lead to some crazy overlaps and hard to diagnose bugs
<RX14>
i meant that the "task runner tool" would be a shard
<RX14>
not part of the crystal toolchain
<FromGitter>
<paulcsmith> Oh I see, yeah it could definitely do that
<FromGitter>
<paulcsmith> That's what `lucky` would be in this case. But maybe a different name since it would be so generic at that point that it would have basically no ties to Lucky itself
<RX14>
@bcardiff i don't think its a big deal
<FromGitter>
<paulcsmith> But yeah that would work for sure
<RX14>
it'd run just the same as the existing postinstall hooks
<RX14>
and there's one of those per shard
<RX14>
all shards get installed then all hooks are run
<RX14>
two-phase
benharri has joined #crystal-lang
<RX14>
9at least that was the idea i'm not sure if thats the reality currently)
<RX14>
in fact I think that wasn't implemented in shards yet
<RX14>
also @bcardiff have you talked to ysbaddaden about what he's working on regarding concurrency because I know you were planning to work on that too
<FromGitter>
<paulcsmith> Also, I've got a number of idea for improving readability of Crystal errors, but I don't have time to implement them myself. Worth opening an issue, or would that be better to post in the mailing list?
<FromGitter>
<bcardiff> @RX14. No, I've only seen his public twitter activity.
<RX14>
i think mailing list would be nice
<RX14>
then i'll have a look at the ideas and give my thoughts
<RX14>
then we can move it to multiple focussed github issues
<FromGitter>
<paulcsmith> 👍 I'll see if I can do that in the next day or two
<RX14>
it actually might be worth removing crystal init and making it shards init
<RX14>
since I think it fits a lot better with seperation of concerns
<RX14>
crystal init already generates shards stuff and runs shards - copying all the `crystal init` code to `shards init` would be something I support
<RX14>
and would definitely make the whole installing shards and running shard init code stuff easier to implement
<FromGitter>
<paulcsmith> I think that makes sense. You're initializing a shard, so using `shards` to do it seems intuitive
<FromGitter>
<straight-shoota> sounds fair
<RX14>
glad there's some consensus on that
Raimondii has joined #crystal-lang
Raimondi has quit [Ping timeout: 272 seconds]
Raimondii is now known as Raimondi
<FromGitter>
<jwoertink> @RX14 Yes, I used Luck without using LuckyRecord. I had to change a few small things, but it's pretty simple, and works great. Though, my usecase is that my site is a read-only, so there's no forms.
<FromGitter>
<jwoertink> also +1 to some of the stuff talked about above ^ I dig it
<FromGitter>
<drum445> doesn't support embedded classes (aka Joins) atm
<FromGitter>
<drum445> I'm still working on it
<FromGitter>
<drum445> Seems to work ok atm, or can you see something wrong with it?
<RX14>
I kinda want to play with the concept myself
<RX14>
but it looks good
<RX14>
it's close to some of my ideas
<FromGitter>
<drum445> Ah nice, would be good to see what you come up with
<FromGitter>
<drum445> I didn't like the idea of making the class overly verbose with mappings
<RX14>
basically inserts should be via objects with no writing of sql
<RX14>
selects should be sql
<RX14>
i'd play around with the idea of macroed partial objects
<RX14>
where you can dynamically create a partial object from a baseclass which copied the class but removed some of it's properties
<RX14>
i'm not sure I can get that to work...
<FromGitter>
<drum445> That would be nice, ha yeah sounds tough
<FromGitter>
<drum445> Couldn't quite get it straight in my head how you'd add querying to the select though.
<RX14>
I'd quite like for the library to dynamically create records from your SQL queries
<FromGitter>
<drum445> How would that look?
<FromGitter>
<paulcsmith> @RX14 I may be misunderstanding, but I *think* you can do that similarly to how LuckyRecord does it. There is macro (the `table` macro. The generates base classes that you can inherit from. So `User` would have a `User::BaseQuery` and `User::BaseForm` that you can use and inherit from. Is that what you mean?
<RX14>
for each sql query it'd macro generate a result struct for the query
<FromGitter>
<drum445> oh, so you wouldn't need to predefine classes?
<RX14>
you would for inserts
<FromGitter>
<drum445> Indeed. Woudln't that be similar to a NamedTuple though, can't see how you would be able to use that class
<RX14>
the class wouldn't travel far in the code
<RX14>
like named tuples
<RX14>
custom queries tend to be quite common for one or a few specific views
<RX14>
either way this is all concepts
<FromGitter>
<drum445> It's true, add work we've got a load of either pointless classes or anon objects flying around
<RX14>
i'd want to write a typed SQL
<FromGitter>
<drum445> ofc you would, you work on Crystal ;)
<RX14>
just SQL strings with each SELECT column annotated with the type
<RX14>
and the rest of the query left as-is
<RX14>
it could generate the result struct from that
<FromGitter>
<drum445> Yeah that's nice actually
<RX14>
and then eventually be able to infer the SELECT types from the table names and definitions for the full classes
<RX14>
realistically, it'd require a macro run() for each query though
<RX14>
which probably wouldn't scale
<RX14>
for larger projects with more people you probably want to limit yourself to a traditional ORM though
<FromGitter>
<drum445> Sounds like it could get heavy, although I'm not too great at macros yet so you never know
<RX14>
well it's possible to jit LLVM IR
<FromGitter>
<drum445> Mate you should see ours, using python means you can get away with writing utter garbage
<RX14>
so in the future macro run() could be jitted
<RX14>
the jit is already used for the spec suite
<FromGitter>
<drum445> What is jit sorry?
<RX14>
just in time compiler
<RX14>
i'm thinking of methods to speed up the macro run stuff
<RX14>
actually it probably wouldn't be that heavy
<FromGitter>
<drum445> ah yes my bad
<RX14>
it'd compile once then cache
<RX14>
then it's the time to start up a crystal binary
<RX14>
it's probably one of those ideas i'll never quite get around to implementing
<FromGitter>
<drum445> Fair enough, kinda of off-topic but do you rate NoSQL over SQL
<FromGitter>
<drum445> ?
<RX14>
postgres is the only database worth anyone's time lol
<FromGitter>
<drum445> haha, I'll have to give it more of a look, been on Maria these days. Is there any reason to switch>
<RX14>
at least in the start
<RX14>
yes
<RX14>
mysql has basically none of the features
<RX14>
and it's typing is fuzzy
<FromGitter>
<drum445> Yeah the typing is pretty poor
<RX14>
and it doesn't catch errors as well
<RX14>
postgres is a lot stronger typed
<FromGitter>
<drum445> You can change the default behaviour but nobody does
<RX14>
it has *more* types
<RX14>
the thing I like the most about postgres is that you can specify your constraints inside the database
<RX14>
and have the database enforce them
<FromGitter>
<drum445> oh?
<RX14>
and that's not just constraints as in this key refers to this primary key
<RX14>
thats stuff like the database can enforce that all your points are within x km of some other point
<RX14>
it's really nice
<FromGitter>
<drum445> Crikey, I didn't know that
<RX14>
if you actually go through the postgres manual and learn to use all the features
<FromGitter>
<drum445> Sounds like it's worth putting the time in
<RX14>
it's less error-prone to specify something declaritively in postgres constraints than it is to write the same code in your application
<RX14>
you can essentially do all your form validation inside the CREATE TABLE
<RX14>
and it's great
<FromGitter>
<drum445> Cool, the problem I have with NoSQL is it seems 99% of the time your data will have relationships
<FromGitter>
<drum445> So the amount of duplicated data you end up with isn't worth it
<RX14>
nosql people tend to imply that in nosql you can do without schemas
<RX14>
but you always have a schema
<RX14>
it's just inside your code
<RX14>
and i'd prefer to tell postgres my schema
<RX14>
so it can tell me when i fuck up
<FromGitter>
<vegai> come on, sqlite is pretty good as well :P
<RX14>
sqlite is alright for certain applications
<RX14>
i was tempted to write postgres and sqlite are the only DBs :P
<FromGitter>
<paulcsmith> Also, Postgres has a nice jsonb type that you can use if you truly do have "schema less" data. I think it's rare to have that but it's possible
<RX14>
sqlite is even fuzzier than mysql though
<FromGitter>
<drum445> +1
<RX14>
also you can have arrays in your table
<FromGitter>
<paulcsmith> One problem with constraints in Postgres is that they can be tricky to do conditional validation. It is nice for stuff that *always* has to be done though
<RX14>
so, for certain usecases, instead of having a join table you can just keep an array inside one of the keys
<FromGitter>
<drum445> So it solves what nosql tried to lol
<RX14>
yeah, conditional validation is best left for code
<RX14>
the constraints are basically for "my code CANNOT make sense of this data if this isn't true"
<RX14>
which is fairly common
<FromGitter>
<vegai> some nosqls solve problems that something like postgres cannot
<FromGitter>
<drum445> The use-cases are so rare though
<FromGitter>
<vegai> like cassandra with its linear horizontal write scalability
<FromGitter>
<drum445> We use cass, I think it's a glorified log store
<RX14>
thing is, do you need linear horizontal write scalability?
<RX14>
if you do, you probably have 100+ engineers and aren't listening to me complain on IRC :P
<FromGitter>
<vegai> we do at $work, but yeah, 99,999% of people don’t need that
<FromGitter>
<drum445> We thought we did, and our team is < 10
<RX14>
my point is that you should start with postgres
<RX14>
and then keep scaling it
<RX14>
keep trying to stay on postgres
<FromGitter>
<drum445> That right there, is exactly what I tried to tell our sa
<RX14>
and treat any other DB as a last resort
<RX14>
usually you don't need it
<FromGitter>
<vegai> After experiencing Cassandra, I fully agree with that sentiment
<FromGitter>
<vegai> it’s probably a better idea to turn paying clients away than go there most of the time
<FromGitter>
<drum445> "Premature optimisation is the root of all evil"
<FromGitter>
<drum445> @vegai haha, I wish our guys saw it like that
<RX14>
by the time you need more scalability than postgres can provide, you probably have the manpower or the time to try two or three different DBs and evaluate them properly in production
<RX14>
which is the best way to evaluate enginering choices
<RX14>
well
<RX14>
s/production/test with production workload
<FromGitter>
<paulcsmith> What's wrong with testing in production 🙃
<FromGitter>
<paulcsmith> It's the only way to know it *really* works
<RX14>
and the answer usually is it doesn't :P
<RX14>
or maybe thats just me
<FromGitter>
<paulcsmith> Personally I just ssh into prod and edit live with vim
<FromGitter>
<Prutheus> ok how long can this take until merged?
<FromGitter>
<asterite> I think it depends on when amber updates their homebrew formula
<FromGitter>
<Prutheus> why is this dependent of amber ... a shame, amber is not crystal, its just a framework which uses crystal. wow, i have a library ... wait, do not update, i need to update my library first!!! -.-
<FromGitter>
<Prutheus> what a bullshit
<FromGitter>
<asterite> yup
<FromGitter>
<asterite> it's how homebrew works
<FromGitter>
<Prutheus> pfff -.- ^^
<FromGitter>
<asterite> the only thing we can do is to politely ask the amber guys (and everyone) to use a tap until crystal reaches 1.0
<FromGitter>
<Prutheus> what is a tap? I dont know exactly how brew is "styled"
<FromGitter>
<paulcsmith> A tap is like a third party repo for installing packages
<FromGitter>
<asterite> it's like another source for libraries, but you can manage it without homebrew's permission
<FromGitter>
<paulcsmith> I'm probably going to fork it and release a new version of Lucky that uses the forked version because I can't be sure when that will be merged in
francisl has quit [Quit: francisl]
<oprypin>
WTF is amber doing in homebrew?
alex`` has quit [Ping timeout: 260 seconds]
<oprypin>
someone should send a PR to delete it
alex`` has joined #crystal-lang
<FromGitter>
<paulcsmith> I think it's understandable why it would be in there, especially if they didn't know it would block Crystal. I didn't know it would block Crystal until today. I opened an issue for them to remove it though
<oprypin>
no it's not understandable
<FromGitter>
<paulcsmith> If someone removes it without their team then it will break installing Amber for anyone until the Amber team updates their docs. Which could be fairly problematic
<oprypin>
the executable is useless on its own
<oprypin>
it's a source-based crystal library
<FromGitter>
<paulcsmith> Chill out. It was an honest mistake that will be corrected
<FromGitter>
<fridgerator> seriously
<oprypin>
like, the amber executable just produces a bunch of source files, and then you need to run `shards` and actually install the library from github
<oprypin>
and i'm not even talking about the breakage, it just shouldn't be in homebrew
<FromGitter>
<paulcsmith> Yeah, it definitely doesn't need to be in Homebrew core, and can be it's own tap, but if someone deletes Amber from Homebrew before the docs are updated, people on macOS will not know how to use Amber.
<oprypin>
if it ends up in a tap, it will probably be more steps to install it with brew than without
<FromGitter>
<paulcsmith> Probably not. It's what is done with Lucky. It is easier to do with Brew than without
<FromGitter>
<paulcsmith> And is easier to upgrade when new releases come out
francisl has joined #crystal-lang
<FromGitter>
<paulcsmith> Just `brew upgrade lucky`
alex`` has quit [Quit: WeeChat 2.2]
alex`` has joined #crystal-lang
<FromGitter>
<stronny> Hi! So how do I use #defines from libc header files?
<FromGitter>
<stronny> So if they change in the header I should track the changes?
<RX14>
if they're #defines thats the only wahy to do it
<RX14>
hope they dont change
<FromGitter>
<stronny> Right, I see
<FromGitter>
<straight-shoota> A lib declaration is essentially just the relevant parts of a header file transcoded to Crystal. If the header changes, you need to change the lib def.
<RX14>
but when you pass to C functions, the to_unsafe can be omitted
<RX14>
and the compiler will call to_unsafe for you
<FromGitter>
<straight-shoota> This is actually all explained very nicely in the docs =)
<FromGitter>
<stronny> Well, I was looking at this instead: ⏎ ⏎ > Note: The C char type is UInt8 in Crystal, so a char* or a const char* is UInt8*. The Char type in Crystal is a unicode codepoint so it is represented by four bytes, making it similar to an Int32, not to an UInt8.
<FromGitter>
<stronny> thanks for the help!
<FromGitter>
<straight-shoota> Yeah, maybe that could use a mention of using `String` as equivalent of `UInt8`
<FromGitter>
<straight-shoota> It always helps looking at existing code. The stdlib has quite a number of C bindings.
<FromGitter>
<straight-shoota> Maybe it's easier to look at some shards, though. There are many bindings for C libs
<FromGitter>
<stronny> My immediate problem is solved now, thanks =)
hightower4 has quit [Remote host closed the connection]
alex`` has quit [Quit: WeeChat 2.2]
alex`` has joined #crystal-lang
benharri has quit [Quit: i'll probably be back soon]
<oprypin>
stronny, so it seems like .bytes made a separate non-null-terminated array. while .to_unsafe (implied) just gets a pointer to the data of the crystal string which happens to be utf-8 and null-terminated. and yeah, C expects strings to be null-terminated.
francisl has quit [Quit: francisl]
alex`` has quit [Ping timeout: 272 seconds]
<FromGitter>
<asterite> Ideally we should bind directly to headers, maybe do something like cgo. But it's hard and it must be designed
<FromGitter>
<paulcsmith> On Crystal 0.26 I'm getting a strange error I can't figure out: ```Error in /usr/share/crystal/src/string.cr:139: can't declare variable with Self ⏎ include Comparable(self)```