<FromGitter>
<watzon> There we go, that's where it's happening
<FromGitter>
<watzon> Reproducing is going to be a bitch though
<FromGitter>
<Blacksmoke16> `" " * (0 + 0) - `?
<FromGitter>
<Blacksmoke16> gl :p
<FromGitter>
<watzon> Well I mean coming up with a reproducible example with my current code haha. But they should definitely be doing some checking there to make sure the number isn't negative.
<FromGitter>
<Blacksmoke16> heres a plan
<FromGitter>
<Blacksmoke16> fix the code in the compiler, then run your code again to see what the actual error is then try to reproduce that error with a small example
<FromGitter>
<naqvis> homebrew installation should reside under `/usr/local/Cellar/crystal` folder and that should also add that path
<FromGitter>
<naqvis> aahh
<FromGitter>
<naqvis> you better upgrade OSX
<FromGitter>
<636f7374> @naqvis Yes, it cannot be installed again after uninstalling , Yes, I think Crystal or LLVM may no longer support macOS 10.12.6
<FromGitter>
<636f7374> @naqvis thank you for your help.
<FromGitter>
<naqvis> ywc 👍
<FromGitter>
<lodenos> My version of macOS is 10.13.6, I have completly uninstall Crystal and delete all cash and reinstall with homebrew
<FromGitter>
<lodenos> Doesn't work again
<FromGitter>
<lodenos> Because this file .cache/crystal/crystal-run-main.tmp doesn't exist
<raz>
why do you guys stick with these ancient OSX versions?
<FromGitter>
<lodenos> @raz my macbook pro has 10 year's old
<raz>
i'm afraid when homebrew stops supporting it, you're out of luck not just with crystal but with many things
<FromGitter>
<lodenos> And we can't update, I have try for the latest version, Impossible doesn't work for upgrade, I do upgrade the machine for going the apple store, money money lol
<raz>
if money is tight, maybe consider switching to linux ;) - easier to keep it up to date even on old hardware
<FromGitter>
<lodenos> ^^
<FromGitter>
<lodenos> But I can compile an Hello World with crystal 0.35.0
<FromGitter>
<lodenos> And that's works
<raz>
in fairness, OSX itself *does* have pretty good backwards compat story. they even still released a security update for 10.12 (Sierra) last year. but probably the last one, as that version went EOL three years ago.
<raz>
however, homebrew usually only supports the latest (and sometimes the one before it)
<FromGitter>
<lodenos> I go try compiling in Docker
<FromGitter>
<lodenos> Maybe the problem is the Crypto
<f1refly>
is there an easy way to export the crystal gitbook to epub? The whole gitbook system is somewhat confusing, gitbook itself says they abandoned the cli tool in favor of their website, but I can't find the crystal gitbook there, neither is there an option to export it on crystal-lang itself
alexherbo2 has quit [Quit: Ping timeout (120 seconds)]
alexherbo2 has joined #crystal-lang
<jhass>
I only know there's thoughts about migrating away from gitbook, I guess you found a couple of the reasons :)
<raz>
yea, gitbook is kinda a love/hate thing
<raz>
their web editor is really nice. but everything else is largely a pain
<raz>
then again, the alternatives tend to be even less pleasant. (been trying with asciidoc, mkdocs, sphinx... it's all very messy)
<FromGitter>
<Blacksmoke16> could the store getter just be `getter store : Cache::Store(String, String)`?
<FromGitter>
<Blacksmoke16> then supports custom types as well
<f1refly>
I wonder if crystal could copy whatever rust is doing with their docs. They seem to work with gitbook as well and their docs are available as epub no problem (published, but still)
<FromGitter>
<Blacksmoke16> and/or just have one initializer where the user creates it and passes it in?
<FromGitter>
<Blacksmoke16> as if i create a `PgCache` i cant use it
<FromGitter>
<Blacksmoke16> `=== "GET"` 🙈, too much JS/PHP lately :P
<FromGitter>
<Blacksmoke16> be nice if there was an API in the cache shard to stream the data back as an IO
<FromGitter>
<Blacksmoke16> then the string wouldnt have to be loaded into memory at all but :shrug:, turned out pretty nice 👍
<f1refly>
kinxer: it wouldn't be bad to use a doc system thats written in rust, would it?
<f1refly>
jhass: I built it with the npm docbook tool, yeah. Gotta say it really isn't too bad of a read on my eink device
<FromGitter>
<kinxer> I mean, I don't think we have a doc system written in Crystal, so we're gonna have to use something written in some other language anyway. I agree that a tool in Rust probably wouldn't be that bad, especially since it probably wouldn't require actually writing any Rust.
<FromGitter>
<kinxer> Certainly the primary benefit would be using something that is still maintained.
<FromGitter>
<kinxer> But it sounds like the core team has already decided on Docusaurus, which sounds fine to me.
zorp has joined #crystal-lang
<FromGitter>
<watzon> Has a compact rescue block ever been discussed? Something that would rescue an exception and just return nil?
<FromGitter>
<watzon> Being able to rescue a block is nice
<FromGitter>
<kinxer> @Blacksmoke16 I don't understand what your example is for. I thought @watzon was trying to avoid those extra `rescue\n nil` lines.
<FromGitter>
<watzon> All of these examples are nice
<jhass>
tbh I don't quite follow what you want. There's a single line. For anything more than a single line you'll at least need a block around these lines. def and do serve as an implicit begin, so it's the exact same amount of lines
alexherbo2 has joined #crystal-lang
<FromGitter>
<jwaldrip> Can you forward block to another macro?
<FromGitter>
<jwaldrip> ```macro(&block)```
<raz>
everything should be made as simple as possible. but not simpler.
<raz>
some guy said that a while ago, i think he had a point
<FromGitter>
<jwaldrip> When block is called to the other macro its a Nop
<FromGitter>
<jwaldrip> or am I still doing it wrong
<FromGitter>
<jwaldrip> I see, you can just append the block as block
maxpowa has quit [Remote host closed the connection]
maxpowa has joined #crystal-lang
rocx has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 258 seconds]
coderobe has quit [Ping timeout: 256 seconds]
<FromGitter>
<Blacksmoke16> heres a data modeling question
<FromGitter>
<Blacksmoke16> i have a table `contracts`, then i have child tables for specific "types" of contracts, like auction versus courier
<FromGitter>
<Blacksmoke16> however there are some columns that not all contracts have, depending on where the courier object originated, i.e. public versus authenticated context. public ones wont have an `assignee_id`
<FromGitter>
<Blacksmoke16> contract object*
HumanGeek has joined #crystal-lang
<FromGitter>
<Blacksmoke16> im debating what to do with these columns, since they're not included in one context but are in the other. Current plan is to just define them as nullable, and do the rest on the ORM side. I.e. have a type specific for each "origin"
<FromGitter>
<Blacksmoke16> I.e. `PublicContract` wouldnt include `assignee_id`, `PrivateContract` would and would be not nilable
<FromGitter>
<Blacksmoke16> any other ideas?
Human_G33k has quit [Ping timeout: 256 seconds]
<raz>
yup, i tend to keep it in the same table (with an enum for the type) if they're similar enough. if it gets too unwieldy it's time to split them into separate entities (owner has_many public_contracts, has_many private_contracts)
<jhass>
some check constraints in addtion to nullable fields? CHECK ( (type = 'private_contract' AND assignee_id IS NOT NULL) OR type != 'private_contract')
<FromGitter>
<Blacksmoke16> jhass: oo good idea, at least would get some DB checks in there
<raz>
which you then have to duplicate in the ORM and in the client
<raz>
programming is so much fun!
<FromGitter>
<Blacksmoke16> luckily its a backend construct, wont be any user input
<FromGitter>
<Blacksmoke16> just consuming an API and storing the data
<raz>
ah yea, that's easy then
<raz>
well, easier at least ;)
<FromGitter>
<Blacksmoke16> just feels hacky to me to have a bunch of required properties be nullable just because the other "type" of contract doesnt have it, but also feels hacky to make each one its own table
<FromGitter>
<Blacksmoke16> but i suppose its not a big deal either way, since its not user supplied so less chance for it to get borked
<raz>
ORM is always hacky. impedance mismatch
<raz>
at one point someone had a great idea to fix it, and so he went and invented mongodb
<raz>
but that was a mistake. so now we're back to ORM.
<FromGitter>
<Blacksmoke16> xD
<FromGitter>
<Blacksmoke16> and ORM that supports MTI/STI?
<FromGitter>
<Blacksmoke16> cant say iv'e seen any for the former
<raz>
well, they exist... there's rumors some poor souls even tried the whole polymorphic route
<raz>
but no one ever heard from them again
<FromGitter>
<Blacksmoke16> in crystal i mean*
<raz>
jennifer does it
<raz>
but i don't think you want to. you're too young, you still have your whole life ahead of you!
<FromGitter>
<Blacksmoke16> looks like it has STI, not MTI tho
<raz>
lol
<FromGitter>
<Blacksmoke16> ill prob just hack granite to get it to work :S
<raz>
good luck... (or shall i say "farewell" :D)
<raz>
but srsly, that way lies madness
<FromGitter>
<Blacksmoke16> i think it would be possible with a module to share the common columns
<FromGitter>
... instead of an array or slice. However, compiling for release now takes ~5-8 minutes, where it used to take ~10-20 seconds. I mentioned this before as well, but I don't remember what the conclusion was there. I'll likely stick with a staticarray because it allows me to get sdl bindings working, but the super long compile ti ... [https://gitter.im/crystal-lang/crystal?at=5ee6b8017c64f31f115f3962]
<FromGitter>
<mattrberry> Hey! I was in this channel a week or two ago sharing the weird issue I was having with passing arrays/slices to c-bindings to SDL. Last time I brought it up here, we seemed to arrive at the conclusion that it had something to do with garbage collection, but we couldn't figure out how to fix it. I've been playing around with it some more, and it seems like I've gotten it to work better by using a staticarray
<FromGitter>
<mattrberry> Maybe I could just put these staticarrays somewhere else in global scope and in their own file so that crystal won't need to recompile them every time? That could mitigate the issue, but it's definitely not a solution