<FromGitter>
<mattrberry> I'm mostly curious if there's a way to do it without updating my path ^
<straight-shoota>
what do you mean by use it with shards?
<FromGitter>
<mattrberry> I build my project with `shards build`. I know shards is effectively a wrapper around `crystal build`, so I was hoping to just point shards to the version of crystal that I built locally
<FromGitter>
<mattrberry> I also figured I could just `crystal build`, but that doesn't seem to work
<straight-shoota>
shards just calls crystal
<straight-shoota>
so whatever crystal is in your path
<straight-shoota>
but you can really just call "crystal build" directly
<straight-shoota>
that's exactly what "shards build" does. Only thing it adds is that you can configure source and output paths in shard.yml
<straight-shoota>
if "crystal build" doesn't work, then "shards build" wont either
<FromGitter>
<mattrberry> Yeah that was my understanding as well
<FromGitter>
<mattrberry> What should I set CRYSTAL_PATH to?
<straight-shoota>
to the location of the standard library
<straight-shoota>
src folder in crystal repo
<straight-shoota>
the compiler binary doesn't know where these files are stored
<straight-shoota>
that's why there's a bin/crystal helper which automatically adds the path and calls the binary
<straight-shoota>
usually you would not call the binary directly but the wrapper
<FromGitter>
<mattrberry> Ahh, it wasn't clear to me that that's what bin/crystal is. I just saw that bin/crystal hadn't been updated after I ran `make`, so I assumed something else was wrong. That makes more sense now
<straight-shoota>
yeah, that's just a simple helper that sets up env vars so the compiler knows where to find stuff
<FromGitter>
<mattrberry> Perfect, thank you
<FromGitter>
<mattrberry> Separate question:
<straight-shoota>
to use your custom build compiler you can call bin/crystal with CRYSTAL env set to your custom compiler path
<FromGitter>
<mattrberry> I was previously receiving this warning and didn't think much of it ⏎ ⏎ ``` code paste, see link``` ⏎ ⏎ Now that I'm on the master build, this is failing. However, it's failing because my implementation *does* specify the return type of `===` to be `Bool`. Why is that an error now? [https://gitter.im/crystal-lang/crystal?at=5fc447e19af4396683caa35b]
<straight-shoota>
what exactly is the error message from master?
<straight-shoota>
and can you share reproducible code?
<straight-shoota>
this warning is farely new
<straight-shoota>
but it should really be just a warning, not an error (for now)
<FromGitter>
<mattrberry> ``` code paste, see link``` ⏎ ⏎ Should happen by just building https://github.com/mattrberry/CryBoy. I don't think my local changes affect it. However, for the master compiler build you'll need to replace the one call to `Deque#delete_if` with `reject!` as well as comment out the `require "stumpy_png"` and body of the `write_png` method in the Display class. I can work on trying to create a smaller
<FromGitter>
<mattrberry> The `===` is in abstract_channels.cr, specifically as `abstract def ===(value) : Bool`. If I remove the ` : Bool`, the master compiler is happy
<straight-shoota>
oh I see
<straight-shoota>
so you're declaring a method as abstract which is already defined in a supertype
<straight-shoota>
that might be confusing the compiler
<FromGitter>
<mattrberry> Hmm yeah makes sense. My intention was that I require all subclasses to implement it explicitly. I guess that is potentially weird though. I'll check what java does
<FromGitter>
<naqvis> @j8r Thanks, I just saw that issue :P
<straight-shoota>
simple solution: let === delegate to a custom method and make that abstract
<FromGitter>
<mattrberry> That seems like the best workaround for now, thanks for the idea
<straight-shoota>
I have reduced the code and it triggers a warning
<straight-shoota>
but I don't figure how it turned into an error for you
<straight-shoota>
do maybe pass --error-on-warnings ?
<FromGitter>
<Blacksmoke16> pretty sure a error in master
<FromGitter>
<Blacksmoke16> sure its an*
<straight-shoota>
doh
<straight-shoota>
my crystal-nightly was pointing to crystal-latest
<FromGitter>
<Blacksmoke16> that would do it
<straight-shoota>
yep
<FromGitter>
<mattrberry> In case people were curious, java handles this in the way I'd have expected
<FromGitter>
<mattrberry> Classes that extend the abstract class just need to implement the `.equals` method
<FromGitter>
<mattrberry> Understandable that that's an edge-case in the crystal compiler though
<FromGitter>
<perfecto25> hello, questin re YAML handling, how do i convert yaml:Any into a hash?
<FromGitter>
<mattrberry> Just out of curiosity, what's the driving force behind the push to 1.0? I feel like there are still a number of things that should be worked out before the release. Crystal is totally stable enough for my daily use, and I'd even totally be open to using it at work if the company allowed it, but I feel like it's not quite ready for 1.0 yet. I had the compiler segfault for me a couple times the other day when
<FromGitter>
... I wasn't even using c bindings. That's just my opinion from a distance though, so I'd be super interested to know if there's more that I'm not considering
<straight-shoota>
well, current behaviour is obviously not ideal. Either that abstract def should enforce subtypes to implement that method or it should be an error to redefine an existing method as abstract
<FromGitter>
<perfecto25> getting
<FromGitter>
<perfecto25> Error: undefined method 'as_h' for YAML::Any.class (compile-time type is (YAML::Any | YAML::Any.class))
<FromGitter>
<mattrberry> > *<straight-shoota>* well, current behaviour is obviously not ideal. Either that abstract def should enforce subtypes to implement that method or it should be an error to redefine an existing method as abstract ⏎ ⏎ Do you want me to open an issue?
<FromGitter>
<Blacksmoke16> try just using `YAML.parse`, unless there really is more than one document in that file
<FromGitter>
<Blacksmoke16> also might want to move the `yaml = ` into the `File.open` block
<straight-shoota>
mattrberry, I'm currently throwing stuff at the compiler to see how it currently handles those abstract defs
<straight-shoota>
it seems your thing actually works because the abstract method's return type is different from Object
<straight-shoota>
so if a subtype doesn't implement the method, the compiler complains
<FromGitter>
<mattrberry> Sounds good. Lmk if you want me to do anything else for this. Happy to cut an issue for it, but I feel like yours would be better anyway :p
deavmi has quit [Read error: Connection reset by peer]
<straight-shoota>
well it only works because Object#=== doesn't have a return type
<straight-shoota>
regarding push towards 1.0, the idea was that many people see Crystal stable enough to use it, even though we know that it's certainly not finished
<straight-shoota>
having a 1.0 release would give people that want to use it some gurantees that their code will be supported and not randomly break in the next relases
sagax has joined #crystal-lang
<straight-shoota>
makes further development harder, obviously because breaking changes will need to wait for 2.0
<FromGitter>
<mattrberry> I feel like the purpose of hitting 1.0 is to make people see it as stable enough to use, but since people already think it's stable enough to use, doesn't that primarily serve to limit the language's progression?
<FromGitter>
<mattrberry> And if people's code breaks, they could theoretically just use an older version of the compiler?
<straight-shoota>
theoretically, yes
<straight-shoota>
and the compiler probably isn't that much of a problem really. You can easily compile code written for an old compiler version with exactly that compiler version
<FromGitter>
<mattrberry> Is the hope that 1.0 will make more people use it, and in turn there's a chance larger companies / groups start backing the project?
<FromGitter>
<mattrberry> It's understandable to me if it's a funding issue
<straight-shoota>
but stdlib and shards probably wouldn't provide bugfixes for older versions
<straight-shoota>
so if I have a program written for say crystal 0.20.0, it won't compiler with current compiler, but I can use an old one.
<straight-shoota>
But I also have to use 0.20.0 stdlib and shards at version where this compiler/stdlib is supported
<FromGitter>
<mattrberry> Gotcha, the bugfixes concern makes sense
<FromGitter>
<mattrberry> Have you received lots of requests from users / potential users to move to 1.0? Or was that done more as a decision for what you think users want?
<straight-shoota>
of course, 1.0 should also help with publicity and make companies consider to use for production
<straight-shoota>
communication with companies mostly goes trough manas, so I don't know any specific
<straight-shoota>
but it seems there are companies that would like to see a 1.0 to start using Crystal
<FromGitter>
<mattrberry> Interesting. Well either way, I'm excited to see where Crystal goes in the future :)
<FromGitter>
<naqvis> jhass, if `Proc(Nil)` returns the nil, then how come `meth2` is being invoked in the first place? shouldn't the return type of `meth1` be treated as `nil` as well?
<FromGitter>
<naqvis> this discrepancy is causing confusion
<jhass>
meth1 returns a proc calling meth2, before that meth1 is printed. This proc is invoked, meth2 is invoked and thus printed. This proc is however returning nil now
<jhass>
and not the return value of meth2
<FromGitter>
<naqvis> my point is both meth1 and meth2 are returning a Proc
<FromGitter>
<naqvis> we are not concerned with the return value of block
<FromGitter>
<naqvis> but return value of meth1,meth2
<jhass>
yes we are, that's what gets assigned to m
<FromGitter>
<naqvis> as block is being invoked in `run` method
<FromGitter>
<naqvis> or as soon as one return the `Proc` block it contains get executed?
<jhass>
and its return value is assigned to m, not the return value of the method it calls
<jhass>
no
<FromGitter>
<naqvis> got your point. Thanks jhass
<FromGitter>
<Blacksmoke16> `[0_i64] of Int32 | Int64` you say it can be either, but it cant know it should also allow int32 since theres only an int64 in it
<FromGitter>
<ImAHopelessDev_gitlab> grrr
<FromGitter>
<ImAHopelessDev_gitlab> with puts,it doesn't error (and it's only an int64) in there. i don't get tht
<FromGitter>
<ImAHopelessDev_gitlab> `Array(Int32 | Int64)` is the value in the array could be an Int32, or a Int64?
<FromGitter>
<Blacksmoke16> right
<FromGitter>
<ImAHopelessDev_gitlab> what about multiple?
<FromGitter>
<ImAHopelessDev_gitlab> Int32 and a Int64 type
<FromGitter>
<Blacksmoke16> right
<FromGitter>
<Blacksmoke16> could be all int32, all int64, or a mixture of both
<FromGitter>
<Blacksmoke16> but even if its all int32, you could still add an int64 onto it
<FromGitter>
<Blacksmoke16> right, now since there are both types in the array it fits with the type of the ivar
<FromGitter>
<Blacksmoke16> whereas before the int32 wasnt there so it was compatible
<FromGitter>
<ImAHopelessDev_gitlab> well i'm stumped now. on my code, `pp zone.extra_game_update` shows `[]`. but on crystal playground, `pp zone.extra_game_update` shows `[[0, [0]]]`
<FromGitter>
<Blacksmoke16> theres prob more going on
<FromGitter>
<ImAHopelessDev_gitlab> :(
<FromGitter>
<ImAHopelessDev_gitlab> im thinking how can an array go to `[]` right after i added something to it
<FromGitter>
<Blacksmoke16> it was a copy of an array, or did .clear on it, or is related to that other bug i found
<FromGitter>
<ImAHopelessDev_gitlab> so i did `pp zone.extra_game_update.size` and it shows `1`
<FromGitter>
<ImAHopelessDev_gitlab> so i just stuck a random `0` in there
<FromGitter>
<ImAHopelessDev_gitlab> and works fine
<FromGitter>
<ImAHopelessDev_gitlab> if i had to re-write my code and db design. i'd use all int64 or string. this tinyint bs makes me want to blow my brains out
<FromGitter>
<ImAHopelessDev_gitlab> to_i16 casting, all over fing hell
<FromGitter>
<Blacksmoke16> what are you using Int16 for?
<FromGitter>
<Blacksmoke16> cant you convert them into the enum types on read?
<FromGitter>
<ImAHopelessDev_gitlab> this was created back in 2014 or so when i was designing db
<FromGitter>
<ImAHopelessDev_gitlab> Bool, Int64, and String
<FromGitter>
<ImAHopelessDev_gitlab> is all i ever want in life, god damn it's so hard to achieve
<FromGitter>
<ImAHopelessDev_gitlab> only reason i did the small int types and stuff, is because i was scared/thinking about storage size
<FromGitter>
<ImAHopelessDev_gitlab> but it's truly a PITA
<FromGitter>
<Blacksmoke16> i mean ideally if they are enum values, you should work with the enum types not the numbers themselves
<FromGitter>
<ImAHopelessDev_gitlab> then those types get transcended into arrays, then i ended up with `alias ExtraGameUpdate = Array(Array(Int32 | Array(Int32)) | Array(Int32 | Array(Int32 | Int64)) | Array(Int32 | Array(Array(Int32))) | Array(Int32 | String) | Array(Int32) | Array(Int32 | NamedTuple(lootid: Int32, pos: String)))`
<FromGitter>
<ImAHopelessDev_gitlab> and to_xxx castings all over
<FromGitter>
<Blacksmoke16> thats also your problem, should use records
<FromGitter>
<Blacksmoke16> or at least tuples
<FromGitter>
<j8r> you have approached the problem in the wrong side
<FromGitter>
<j8r> keep in mind that dynamic data structures are only for things you can't know at compile time
<FromGitter>
<ImAHopelessDev_gitlab> this array thing has been doing fine until i realized the .size was printing `1`, when it was outputting `[]` in console.
<FromGitter>
<j8r> every piece con can know, move it to objects/structs
<FromGitter>
<j8r> what is ExtraGameUpdate?
<FromGitter>
<Blacksmoke16> an alias to a giant ass array :p
<FromGitter>
<Blacksmoke16> type*
<FromGitter>
<j8r> sure, but what it has inside?
<FromGitter>
<j8r> I'm also making a game, not such problem so far
<FromGitter>
<Blacksmoke16> he pasted it, is up a few lines
<FromGitter>
<Blacksmoke16> is what it would expand to
<FromGitter>
<Blacksmoke16> neat
<FromGitter>
<Blacksmoke16> id totally update the docs on that then
<FromGitter>
<Blacksmoke16> > converter: specify an alternate type for parsing and generation. The converter must define from_json(JSON::PullParser) and to_json(value, JSON::Builder) as class methods. Examples of converters are Time::Format and Time::EpochConverter for Time.
<FromGitter>
<Blacksmoke16> makes it seem like instance methods wont work
<straight-shoota>
yeah, the docs are misleading
<straight-shoota>
an example would probably help
<FromGitter>
<Blacksmoke16> indeed
HumanG33k has quit [Quit: Leaving]
<raz>
does anyone know anything about the performance of JSON::Any and parsing unstructured json? is it comparable to dealing with hashes in ruby or much faster/slower?
<raz>
(i would expect still faster or at least equally fast, but wonder if anyone has benched it)
<raz>
background: gonna deal with some less than structured APIs which may change under my feet. so that seems the only reasonable way to parse
<FromGitter>
<Blacksmoke16> main overhead is the casting, parsing it is the same as serializable stuf
<FromGitter>
<Blacksmoke16> i.e. `.as_s` does `.as(String)`
<FromGitter>
<Blacksmoke16> so prob not *too* much overhead?
<raz>
sounds good. and yea, that's my thinking as well. it essentially has to do the stuff that ruby does all the time
<raz>
but since crystal is much faster in general, i kinda expect it's likely still heaps faster anyway
<FromGitter>
<Blacksmoke16> ofc if you are able to still generating structs out of the data that would be. best
<FromGitter>
<Blacksmoke16> even if there is a step before hand to like normalize the data when/if it changes
<FromGitter>
<Blacksmoke16> might not be possible tho if there aren't any smaller types that are stable enough
<raz>
yea, not sure about that. i might be able to in some areas. but the first step will likely have to be an unstructured parse still
<straight-shoota>
you can also combine defined structures and JSON::Any (to catch the moving parts)
<FromGitter>
<j8r> Will see if people like it or not
<oprypin>
i dont like D:
<FromGitter>
<j8r> ha? please say
<FromGitter>
<j8r> maybe some useful methods lack, yes
<FromGitter>
<j8r> nothing is impossible to do as done before, and it is a lot faster
<oprypin>
j8r, u just turn the library into a `Hash`
<FromGitter>
<j8r> as done before?
<FromGitter>
<j8r> also, why is was possible to be thread safe before and not now?
<oprypin>
your api is not possible to make thread-safe for obvious reasons
<oprypin>
before it was also nto thread safe but u can make it thread safe without breaking changes
<FromGitter>
<j8r> how?
<oprypin>
e.g. just add a lock around every method
<FromGitter>
<j8r> for write?
<FromGitter>
<j8r> It can be done so for the new implementation
<FromGitter>
<j8r> Each time a write is done, lock, and when finished, unlock?
<oprypin>
but i dont want to do it myself lol
<FromGitter>
<j8r> no, inside the class
<FromGitter>
<j8r> as you said
<FromGitter>
<j8r> obviously it impacts people not needing this feature
<oprypin>
people not needing this feature can use a Hash
<FromGitter>
<j8r> exactly like the memory cache with expires
<FromGitter>
<j8r> I think we can store both the expiration and the creation date
<oprypin>
just publish under a new repo
<oprypin>
(without using github fork feature)
<FromGitter>
<j8r> the issue with expires is that you *will* have expired still stored in memory,
<FromGitter>
<j8r> I don't see the diff of specifying the max period when creating, of when fetching the key?
<FromGitter>
<RespiteSage> @j8r Also, `it "read_entry?" do` isn't very descriptive.
<FromGitter>
<j8r> yeah, I have posted a comment if there is a better idea
<oprypin>
j8r, u will still have it stored in memory even with your approach
<FromGitter>
<j8r> yeah, but the performance difference is obvious
<oprypin>
what, have you benchmarked it?
<FromGitter>
<j8r> For example, redis does like that, it randomly get keys and check for their TTL
<FromGitter>
<j8r> not every time it is fetched
<FromGitter>
<j8r> I can benchmark, but it is obvious that `Time.local; some_operations; @cache[key]?` will be slower than `@cache[key]?`
<oprypin>
pls
<oprypin>
like,... the reason that i'm using this library is that i need those exact time measurements
<oprypin>
so 1) i'll have to just write out those operations anyway and 2) there's still no benchmark and 3) if a time check isn't negligible compared to calculating what you're caching, you dont need a cache in the first place
<FromGitter>
<j8r> the purpose of a cache is to be fast. Faster, better for the user
<FromGitter>
<j8r> as said before, even Redis cache is not very deterministic
<oprypin>
in any case, u can just go and replace a 5 years old library with a completely different library
<oprypin>
can't ** excuse me
<FromGitter>
<j8r> Yes I gues
<FromGitter>
<j8r> Anyway I will have need to do the work. So, I try a PR, that how OSS work
<FromGitter>
<j8r> if not, the fork still lives
<oprypin>
then i have to fork lol
<FromGitter>
<j8r> you already did
<oprypin>
a github fork presumes eventual upstreaming. if not doing that, it's not that kind of fork
<oprypin>
needs to be an unassociated repo
<oprypin>
well it doesn't *need* to be, but there are no upsides to keeping it a github fork, and a few downsides
<FromGitter>
<j8r> I'll create an other library, I guess
<FromGitter>
<j8r> I use it for a session store, the time expiration is not a big requirement
<straight-shoota>
j8r but is performance such a big requirement that you need that little extra you get for not doing a simple time comparison on retrieval?
<FromGitter>
<j8r> It is not needed for my case, a simpler logic is enough
<FromGitter>
<j8r> I have already a GC to check this anyway (like oprypin also has BTW)
<FromGitter>
<j8r> as said in the PR, I already have an implementation (I didn't know this project existed)
<FromGitter>
<j8r> Just trying to be useful for the OSS community
<oprypin>
my gc is purely to conserve memory
<straight-shoota>
yeah that's great. And it's totally fine to push ideas and maybe they get rejected.
<straight-shoota>
I'm just questioning what you gain by making your own shard when you don't really need what it does differently
<straight-shoota>
besides already having the impl ready. but there's more to that, like maintaining it, fixing bugs etc. which works better on a single project than two separate ones